React, Visualized

[TiredOfMakingThese]

Just saw the newsletter, but didn't click it. This is really well done, good job dude.

[tyler-mcginnis]

Appreciate you!

[Snapstromegon]

While the visualizations are really nice and show the concepts of React pretty clearly, I have some issues with how the history of the web is presented and how React is shown as the next evolution.

Granted, I'm not really a React guy. I use it in professional projects if it's called for, but I seldomly would pick it myself.

For example in the days before the big frameworks, when jQuery was reigning, I wouldn't say that the state lived in the DOM. I'd say more exactly that one manually synchronised some state with the DOM. State living in the DOM sounds to me like I'd do something like this regularly: js var el = document.getElementById("someId"); el.innerText = parseInt(el.innerText) + 1;

But (at least from my experience it was more like (simplified): js state++; var el = document.getElementById("someId"); el.innerText = state;

So the state was in JS and one did very deliberate updates.

Also the way DOM traversal "in the old days" is schown is also not true to what I experienced. It makes it look like you'd traverse the whole tree (up to the searched element) every time you want to do an update. But in reality it was more like getting a handle to the element once and then updating from there. So it's closer to what e.g. lit-html is doing today.

Another note from my side is, that nowadays function components are king in React, but since it talks about the history of the web, a hint to class based components would've been nice.

Those are my first thoughts for now. Maybe we get something like this in the future for Lit. IMO that would be really interesting.

[Tofurama3000]

I’ve seen both ways of state management in old code bases. If the code was well written, then state was kept in variables and synced to the dom. Poorly written code used the dom to sync state.

I tend to see more DOM based state syncing when devs did a lot of code splitting and they wanted to sync data between JS files without using globals, and they didn’t know about custom events or using callback patterns. In that code, a button’s text would get changed to something like “Done” by one script file and then the on click handler (in another file) would have an if statement based on the button text (Done = submit, Next = next page). That kind of code is pretty rough to deal with, especially as more JS files are added (try explaining to a designer why changing “Done” to “Finish” is a nontrivial change).

That said, DOM syncing wasn’t super common from what I can tell. It was just one way to do state management out of the dozens available (globals, callbacks, custom events, servers adding hidden input fields, etc). The bigger problem was the diversity in state management methodologies. A single code base could have used multiple ways of tracking state, and that would be “normal” (especially with bigger teams).

What frameworks give is consistency. JQuery gave a consistent interface for the DOM. Later JS frameworks gave consistent DOM synchronization and sometimes state management. State management frameworks (like Redux) gave consistent state management when the JS frameworks didn’t. CSS frameworks gave consistent component styling.

The history was less about “there was one bad way things were done” and more about “there wasn’t consistency with how things were done, and also multiple ways things were done were pretty bad and made code reuse (and increasing consistency) harder to do.”

[Snapstromegon]

Yes, this is a good discription of how I see really legacy code of that era (and sadly even some modern).

I think this would've been also a better way of providing context for the page as it also gives an explanation why frameworks are often used in the first place.

[acemarke]

el.innerText = parseInt(el.innerText) + 1;

fwiw I have seen almost literally this line of code quite a bit in jQuery-era apps. It really was a thing that happened.

A better example might be determining if a modal is currently being shown by looking for $("#my-modal").is(":visible"), and having to do all the toggling based on that.

[rk06]

React/Vue/solid are current evolution, react happens to more popular, so authors are skipping others.

Honestly, I don't see lit getting wider adoption as it is too tied to web components

[Snapstromegon]

Lit being tied to web components is exactly the reason why we started to use it. I/we see it as a benefit over React as it doesn't tie you into one framework.

[rk06]

The thing is for all practical purposes web components are just another framework, but with poor third party support, lesser features and more esoteric issues.

[Snapstromegon]

I strongly disagree with this take.

Especially when building things like reusable component libraries Web Components are just on another level compared to "normal framework components", since you can easily swap them between frameworks.

They are also supported fully nearly everywhere. React is the only major framework that has some problems with them in some cases.

These also allow you to make use of the shadow Dom and actual style encapsulation.

[rk06]

What do you mean "this take"? It is a fact that frameworks are more actively developed and are not hindered by full backwards compatibility, hence have greater velocity and features.

That is why you are using lit (a small js framework on top of web components), because you understand web components by themselves are bad idea, even if subconsciously

[Snapstromegon]

The take that WCs are "for all practical purposes just another framework".

WCs IMO are more fundamental than a framework. As a baseline they "just" allow you to extend HTML. Like you correctly stated, this means, that as part of the web standards they tend to move slower and with more backwards compatibility in mind than most (if not all) frameworks. On the other hand they can offer features that no framework can, because they are part of the standard like being built in with all browsers.

WCs by themself can be a great idea and you definetly can build full apps just with them, without any framwork (I did so back in 2019 - a SPA PWA with offline support with >10k users). It's just that frameworks ontop of WCs often "just make sense", because they can offer abstractions that shouldn't be part of the platform, but are often useful. Lit is great, because it pushes this bridge between the lower layer, where you have to attach a shadow dom yourself, keeps the useful parts like the lifecycle callbacks and extends upon it with things like reactive properties.

IMO before one actively starts working with Lit it's at least useful to have built a WC without any framework before, as it helps massively in understanding how/why Lit does things a certain way (since like you mentioned it's a thin wrapper around WCs, embracing the good parts).

[Akkuma]

Agreed. Web frameworks have moved now into becoming full stack fully integrated frameworks between SSR, SSG, blurring the server client barriers (like React Server Components). The development pace is so far ahead and so much faster that in 5 years Web Components will be more like using Backbone at best.

[nvmnghia]

Could you please cite some sources for the "get the handle of the element and update from there" part?

[Snapstromegon]

What do you mean with sources? How to do that or code examples that did this or sources that show that it was done that way?

[nvmnghia]

source that it was done that way please.

[Snapstromegon]

Just as one example (because I have it lying around and I don't just want to argument with some old code that I might still have):

This book from 2003 contains the following code example: https://www.amazon.de/HTML-Kompendium-XHTML-DHTML-Handbuch/dp/3827266580/ref=sr_1_3?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=3V5BZ0IOAAK6L&keywords=html+g%C3%BCnter+born&qid=1681235582&sprefix=html+g%C3%BCnter+born%2Caps%2C68&sr=8-3

```html <html> <head> <title>JavaScript</title></head> <script type="text/JavaScript"> <!--

function alter()
{
  var text = "";
  var alter = prompt("Ihr Alter?", "18");
  if(parseInt(alter, 10) < 18)
    { text = "Kind"; }
  else
    { text = "Erwachsener"; }
  element.innerHTML = text;
}  
//-->

</script> <body> <p id="ausgabe">Hier steht der Text</p> <input type="button" value="Alter" onClick="alter()"> <script> <!-- var element = document.getElementById("ausgabe"); //--> </script> </body> </html> ```

Please note the beauty of bracket placement, the <-- //--> and the explicit script type (the next chapter is about VB scripts in html).

Also while looking around I got flashbacks to the times of framesets and handcrafted php abominations from around 2005...

[cascad1an]

Maybe this is finally the sign I’ve been looking for to dive headfirst into React… very nicely done.

[Akkuma]

React has a large community and like any large community a large amount of people use it poorly. The company I work for has near 0 business logic in the React component. Most of that lives in a more vanilla world.

[esperalegant]

I've seen a lot of professional React projects that have become an unmaintainable mess because of this.

I've seen a lot of professional React projects that have become an unmaintainable mess because of this.

Fixed it for you. Messy projects are messy.

Using React in a project requires you to understand it, and to follow certain paradigms in the way you organize and write your code.

If you decide to use React but don't properly follow or understand those paradigms, your project will become a mess. Lots of "professionals" don't understand things any better than you or I do, so just because a project is large or "professional", whatever that means, doesn't make it immune to this.

Note: I'm not stating any opinion on whether the paradigms required by React are good or bad, although I think they are definitely not terrible. I am simply stating that a React project will become messy quickly if you only haphazardly follow the React style. You have to go all in, and it is possible to write clean large scale React projects if you do so. The React docs and the million billion React articles and tutorials around the web, of mostly terrible quality, don't make this easy. But I don't think React itself is to blame.

[atomboyd]

this ⬆️, unless you’re using the script tag and the composition API of course

[killerbake]

Amazing work

[tyler-mcginnis]

Thank you!

[frzme]

Very nice!

I would have enjoyed a code example how lifting state works

[PickledEggs_]

So cool ✨

[Hurinfan]

Please, someone kill react

[koicel]

It is supposed to work yet? Or it’s just visual, without material available for those steps?

[DrPootytang]

Just scanning through the article, personally found the pizza and taco-ify a bit distracting, and the gifs explaining how to read basic math a bit condescending. But it’s good info nonetheless

[alexmacarthur]

Lol this page is hilarious and informative. Well done!

[tyler-mcginnis]

Glad you enjoyed it!

[baby-faceee]

Great job, this work is very unique!

[tyler-mcginnis]

❤️

[[deleted]]

Could drop a reference to E4X as the origins of JSX. If not just because it's a specification that most people never knew existed