Every once in a while I'm reminded that I'm mostly disconnected from the way "most" people build things. Thanks for this insight. It finally explains why I hear people talking down about "jQuery developers", if that was something that people actually did.

But wow. I've been building javascript-heavy web stuff since the mid 90's and it had never occurred to me to do that. You have your object model, and each thing had a reference back to its DOM node and some methods to update itself if necessary. All jQuery did was make it less typing to initially grab the DOM node (or create it), and give you some shorthand for setting classes on them.

It also explains why people liked React, which has always seemed completely overcomplicated to me, but which probably simplified things a lot if you didn't ever have a proper place to keep your data model.

I can't imagine I was the only one who had things figured out back then, though. The idea you're talking about sounds pretty terrible.

The thing that changed to make frontend development improve dramatically was hash based routing with ajax, and later the introduction of the history API. That caused frontend development to have a need to retain state between 'pages', so then was a need to find a better way to store it than using DOM attributes.

    $(function(){
      var myState = 123;
      var myElem  = $('<span>' + myState + '</span>');
      $('#myParent').append(
        myElem,
        $('<button text="Increment" />').click(function(){
          myState = myState + 1;
          myElem.text(myState + '');
        }));
    });

I think that what's changed is simply that people realized that it's way less messy to use the backend only as a data source (with ajax calls), and leave everything else to the frontend. The cognitive overhead of having the server producing html with some implicit state, then updating that state interactively, and then losing everything again by posting the whole page to the server, was simply unbearable.

When I started building web applications in 2004 I had some experience in writing desktop apps: I simply created a js library to create and destroy UI elements, and wrote "desktop" apps running in the browser.

I mean, it's better than having to maintain both server- and client-side logic and state (and having to sync all that), and definitely better than the days where we also had to manage DOM diffing manually.

But I still get headaches from the NPM/node ecosystem, the build steps, having to decide whether logic goes on the client, server, or both, and to some extent javascript itself. And you can never fully let go of the server-side of things.

I'm very intrigued by the alternative idea of moving (almost) everything to the backend, and maintaining the dynamic bits by sending all events to the server and sending back diffs based on that which update the page. Phoenix'/Elixir's LiveView made some great progress in this area, and from what I hear other ecosystems are experimenting with the same thing.

It's not a panacea: if you need offline functionality you're gonna have to deal with js and everything that comes with it. But in many projects that's not a deal-breaker, and in practice the approach actually leads to smaller payloads sent between client and server, and significantly simpler codebases.

https://elixirforum.com/t/phoenix-liveview-is-now-live/20889...

I don't know JSF so I can't really argue this point, but I'd really love to hear what you think about the argument Jose put forward and where you might disagree!

I learned a good lesson, though: no logic in template files! Ever!

I come from having done pretty much no Web development and this seems like a hateful way to do development.

And this is why I've been developing all my modern web applications as essentially an S3 bucket of flat HTML with vanilla javascript and jquery sprinkled in sitting behind cloudfront, connected to a fast API built of cloud functions / lambdas written in crystal/rust/etc. I use a custom routing system (I have S3 set up to respond with a 200 at the index in the event of a 404, so I have unlimited control over pathing from within my js logic) and I never let node touch anything at all. And I'm super happy about it. Never has it been easier to get things done. I don't have to fight with any system because there is no system to get in my way.

This gives me:

1. 2-4 second deploys

2. full control over assets pipeline (I call html-minifier, etc., manually in my build script)

3. literally serverless -- S3 or lambda would have to go down for there to be an issue (ignoring db)

4. caching at the edge for everything because of cloudfront

5. zero headaches because I don't have to do battle with node or react or anyone's stupid packages

6. (surprisingly) compatibility with googlebot! It turns out that the googlebot will index js-created content if it is immediate (loaded from a js file that is generated by a lambda and included in the document head tag as an external script, for example)

7. full control over routing, so I don't have to follow some opinionated system's rules and can actually implement the requirements the project manager asks me to implement without making technical excuses.

This does not give me:

1. A magical database that has perfect automatic horizontal scaling. Right now there is no magic bullet for that yet. Some come close but eschew the transactional part of ACID, making themselves basically useless for many applications.

And the parent post exactly matches my usage of jQuery :D

Firestore has a free tier: https://firebase.google.com/docs/firestore/quotas#free-quota

TBH I lean more towards google cloud services in general, so as long as they had very good ping times between each other, I'd consider it.

If your cloud functions return "pure" data, then the client-side JS is doing the rendering: do you manually create the DOM nodes or do you use some templating engine?

Nothing is perfect, but aws aurora serverless auto scales compute and storage for MySQL https://aws.amazon.com/rds/aurora/serverless/

Does that than really fit the "auto" bit of the term?

https://aws.amazon.com/blogs/aws/new-amazon-dynamodb-transac...

Of course, your game can run entirely "in memory" without a render function, which is basically what the game server does.

So I guess, many people have figured it out but didn’t transfer the knowledge from one area to the other.

Thanks for the insight, because I also always wondered what’s considered so new about React, although I have to admit that I still wrote my fair share of jQuery Spaghetti code.

I mean retained by contrast with immediate, as in the early DirectX jargon.

By retained model, I mean the source of truth as to the current state of the UI. Games normally use an immediate mode API, but they still render the UI from a model; it's just that they own the model, whereas with UI toolkits, you generally manipulate a model the UI toolkit maintains and the UI toolkit renders from that model.

Retained mode UIs are much easier to start with. You can get something that looks good up and running very quickly, because you don't need to think through the best representation for your UI - skilled designers and engineers have already done the work, and developed composition and drawing routines so that it all hangs together.

The trouble starts in more sophisticated applications, where the internal model has grown more complex, and UI code is increasingly an exercise in duplicating changes from one model to the other, via reactive techniques like data binding, or more imperatively from events. Having components denormalize state is a recipe for desynchronization bugs.

The problem doesn't totally go away if you move wholesale to immediate mode where the app owns the model, though. There are UI concerns that don't really belong in most application models; things like focus, selection, non-local UI idioms like radio buttons, caret position in text, etc. Doing these things right involves a lot of subtle design. Most app developers are better off handing these concerns to experts who focus on them.

The trick here is how do you reconcile those two states when both have a copy of the data. For instance, the <input type="text" /> holds its own state and you hold the value in the global state. When a user types a character into the input, the input hold a copy of the letter in its "value", and the state is updated with the same value, which then triggers the input to compare its state with that of the global state for equality before attempting to render the value in the global state. Tricky stuff.

Ultimately the ground truth in both instances is that you have potentially many data models that the UI has to aggregate, and the source model, layout, display properties and hitboxes of elements are usually but not totally related and can change due to many kinds of events. Any formal structure you might come up with is bound to run into exceptions. As a result I tend to have this policy:

* I don't trust the framework

* But I leverage the framework to produce early results, and both immediate and retained modes offer ways of doing that

* I expect long-term maintenance to involve a customized framework design regardless

I always thought this is basically the MVC pattern. And it's obviously the only sane way to do things.

Edit: I don't mind the donwvotes, but am I wrong? The MVC pattern simply seems to mandate, at its core, the separation between the model, its graphical representation, and the input from the user. Input -> model -> view. So a game loop where the user input is gathered, the model is updated by calculating the next state, and the view is displayed seems to me an instance of MVC.

(one example of this, while not very graphical, might be a withdrawal from a bank account;the program stores a transaction - the user sees a "Change" in amount available in the account - in the user's mind there's 300 dollars in the account before withdrawing 100 dollars, and 200 after - but this view is a (beneficial lie - the "account" is merely a sum of transactions).

In short mvc wasn't really about a tight mapping between widgets and internal state of the data model - but about translating between the users idea of the domain model and the implementation.

But certainly implementing mvc in a object/message oriented language like smalltalk leads to data flow of input event > controller translation > model update > view update.

More at:

http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html

I recommend reading the paper, it's short and an easy read.

And each has their own use cases and challenges.

Traditionally, however, most well known GUIs (most of the apps people use on the desktop) were done with retained mode libraries (GTK, Qt, Cocoa, and so on).

>So a game loop where the user input is gathered, the model is updated by calculating the next state, and the view is displayed seems to me an instance of MVC.

There's nothing preventing the view being a retained mode UI widget tree -- which is how MVC was commonly implemented iirc.

Nowadays I'd still do simpler components this way. For anything heavier I'll grab React from the beginning, because of it's enforcement of modularity and state-management.

I'm interested in the way of architecting things you described, since I used to try similar ways, but always ended up state-in-dom. Would you have examples or literature on this?

These days I avoid putting state in my markup even for small stuff. I remember some good articles on the topic, but sadly can't find them.

But at its most basic, I just make sure that any jQuery/dynamic component/widget, from the start, is essentially a render function that takes a bunch of data and updates the markup with this data (triggered via some event handler or setInterval(), or something like that). In many cases this doesn't have to be complex or efficient. Sometimes just an .innerHTML() or whatnot is fine. The crucial bit is that I always start with a js data structure and treat it as the single source of truth.

In most cases I just use Preact from the beginning, but I've worked on projects where that wasn't possible and I had to use jQuery or plain javascript. Whatever I used, I usually ended up regretting state in my markup.

For instance if you have a chat, you could have a list of message objects as a normal variable and also show those messages in the dom.

there are things that are massively annoying to do without sneaking a data-uuid and data-type here and there, like drag&drop or specific customer requests - if anyone has ever written a cms, imagine the customer coming and telling "I want this product image in black and white" - if you had data attributes around, it's a css two liners, if you didn't because you're trapped into a either-or mindset, you have to also add the image-bw class on the rendering code with "customer ==" and "product ==" checks

Where these frameworks really come into their own is when you want to create reusable components and share them outside a team. jQuery did a good job with their plugins back in the day but Angular 2 (and React, and soon native Web Components) so that far better.

As far as I remember there are some attempts from Chrome and Mozilla but not sure I saw a real cross-platform spec out, so I stopped tracking the news around it really.

Can you provide some references maybe?

v1 shipped with Chrome 53, Safari 10 and Firefox 63. (And there's a polyfill.)

It's not "soon", it's very much "been in production for a while".

A base class like LitElement https://lit-element.polymer-project.org is all you need to achieve a sort of "react-like" development style (components with unidirectional data flow) WITHOUT build tools() and WITHOUT dom diffing! :)

() if you want to use npm dependencies instead of just plain files with a bundled version of lit, you still need to rewrite import paths, until https://github.com/WICG/import-maps becomes a thing at least. I wrote a tiny dev server that does that: https://github.com/myfreeweb/es-module-devserver

Yes. It seems that most of the frameworks people are so enthusiastic about are invented just to prevent bad developers from writing their awful code. Which they end up doing anyway.

Anecdote: years ago, when he decided moving to Angular.js, my boss justified it with "following best practices". Then he proceeded to rewrite all the application components as controllers quering the context to decide how to behave, and talking to everything else through global events. Took me weeks to rewrite everything in a sane way. (Years later it was decided everything was too slow, and it was rewritten in good vanilla js, with a huge performance boost).

If React was not by Facebook, it would not have gotten popular at all except as a 'cool hack/experiment' - Nobody would have seriously tried to incorporate it into a production application.

As soon as you scratch the surface, you understand that it's one of those tools that tries to take away complexity by adding complexity on top.

The story has gotten more complicated though because now React has so many components and there is all this conveninent tooling and boilerplate around it but still I would never choose it over VueJS.

Anything that comes out of Facebook is just pure manipulation.

Surely a more reasonable perspective is that React actually solved a real problem, and the fact that there's a big company backing it is actually a benefit because 1) there's a lot of money and experience poured into the project, 2) it's likely to be supported even if the lead dev gets hit by a bus, 3) it's an easier sell to management over <insert alternative by random dev>?

I'm no fan of Facebook the company and product, and I avoid client-side code as much as possible (yay Phoenix LiveView), but I think React is quite neat and made my client-side work easier. I'd also argue that it paved the way for an important shift in how front-end frameworks do their thing, and we're all better off for it.

You have components with a render method, and in that render method you return other components which you can pass data to via "props" - that's basically react in a nutshell.

I've noticed React is often conflated with the wider ecosystem it is a part of (Webpack, Redux, Babel) - perhaps this is the complexity you are referring to, but to be clear React can be used without any of these things.

And sure React being developed by Facebook couldn't have hurt in terms of it gaining popularity - but the real reason it took off is that in contrast to what you said it removed a huge amount of complexity by alleviating the burden of developers having to manipulate the DOM directly in ad hoc ways. Instead of having to manually add classes, add elements, remove elements, append children, you could just say given this piece of state, give me this.

> Anything that comes out of Facebook is just pure manipulation.

This just shows that your issue lies with facebook the company, which is biasing you against react - the technology.

I disagree with this. Everyone claims that you can use React without JSX but no one does it. Aside from ugliness, the main reason why no ones does this is because you would be missing the most useful aspect of React which is compatibility and consistency with the rest of the React ecosystem. So you cannot separate React from its ecosystem. All this complexity has become tightly intertwined.

If you use VueJS without a bundler (which is actually feasible), you will be surprised how much simpler and elegant the whole development experience is. Once HTTP servers start supporting static push of scripts, we will not even need bundling in production.

This is just plain wrong. Firstly using JSX or not will have 0 impact on compatibility with other libraries in the ecosystem because they are not coded against JSX they are coded against what JSX is compiled down to. The main reason people use JSX is because people like it.

Also you say the complexity has become intertwined but I don't hear any examples of how that is the case?

> it's one of those tools that tries to take away complexity by adding complexity on top

It's one of those tools that purposely abstracts unproductive, inefficient complexity that we were not aware of before into a higher-level one, forcing us to be more mindful of how we do things. A matter of tradeoffs, I would say, and there's gotta be a limit to how 'simple' one thing can be. Also, you're conflating React the library with the ecosystem around it.

On a sidenote, all the tooling and boilerplate React came hand-in-hand with was markedly a net positive for me. It was in picking up React, during my career, that I learned why tooling is important, picked up tools like Webpack and grunt, learned myself how to do CI/CD and other stuff.

https://en.wikipedia.org/wiki/Parity_of_zero#Education

Claims made by students:

    "Zero is not even or odd."
    "Zero could be even."
    "Zero is not odd."
    "Zero has to be an even."
    "Zero is not an even number."
    "Zero is always going to be an even number."
    "Zero is not always going to be an even number."
    "Zero is even."
    "Zero is special."

We need more old coders around!

Old coders never die, they just get frozen until their favorite programming languages come back into fashion.

https://medium.com/@donhopkins/cobol-forever-1a49f7d28a39

What is-odd does is to throw an exception if you pass anything that isn't a safe integer or a string representation of a safe integer. Otherwise it just returns n % 2 === 1 (after converting string to int if necessary)

Isn't the parameter always floating point in Javascript? (which does mean a package like isOdd will have to incorporate some level of mysticism...)

I can understand how fundamental education teachers don't grasp modern Algebrism and believe that Math is formed by fundamental, sacred definitions. But programmers ought to know better.

By some people, sure, but separating state and business logic from presentation and rendering logic was a well-known idea many, many years before React was around.

I think the basic premise of the article here is correct. The important development with React that hadn’t previously been widely seen in front-end, JS-based web development wasn’t the virtual DOM, it was the declarative description of the rendered content — building it in absolute terms from the current state, not in relative terms from the current and previous state. The virtual DOM is a means to that end: it makes that approach fast enough that it can be used with acceptable performance for a lot of realistic applications.

This doesn’t change the fact that the declare-and-diff strategy is extremely expensive compared to actively observing only necessary changes in the underlying state and making only necessary local updates in the (real) DOM. In a typical web app, if there is such a thing, that might not matter very much. In more demanding cases, say when you’ve got tables with thousands of cells or you’re drawing a complicated diagram with SVG, it’s still all too easy to run into performance lag with any library that uses this strategy. Then you start using escape hatches like shouldComponentUpdate or using lifecycle methods to manipulate the (real) DOM directly rather than rendering through React, at which point you’re not really benefitting from React at all for that particular component (though of course you might still be benefitting from it for the other 90% of your UI code and incorporating the rest into the same overall design using those escape hatches might make sense in that situation).

My claim is that this isn't a good representation of the FE culture as a whole - even if there were islands of enlightment out there. Hell, just about all of the enterprise codebases I get contracted to work on are STILL do state management the old way.

So no - I don't agree the basic premise of the article is correct.

>The important development with React that hadn’t previously been widely seen in front-end, JS-based web development wasn’t the virtual DOM, it was the declarative description of the rendered content — building it in absolute terms from the current state, not in relative terms from the current and previous state.

You are ignoring that fact that the VDOM was the imperative implementation they used under the hood to make the declarative api work. It's the VDOM that allowed them to take state management out of the DOM - and thus why they claimed that the VDOM was faster than the DOM.

Sure - if other folks are finding other implementation approaches that allow one to keep state out of the DOM in even better ways - that's great. That doesn't mean it wasn't reasonable at the time to identify the VDOM with that central innovation since there wasn't many other people doing it in other ways.

>This doesn’t change the fact that the declare-and-diff strategy is extremely expensive compared to actively observing only necessary changes in the underlying state and making only necessary local updates in the (real) DOM.

I'm not arguing this case one way or another... I don't claim to know. The OP is certainly welcome by me to try to continue making that case. I think that's a good contribution to make.

I'm saying that OP could do this without crapping all over React's contribution - which tbh honest smells like a status move in order to obtain more market share. Wanting more market share is fine - but it should be enough to just compare the performance between the two to make that case. Don't straw man a "meme" to attack a competitor's status.

I can’t really dispute that since I don’t have any useful statistical evidence. All I can say is that in my experience there were mostly two types of people working on front-ends to run in browsers in the early days: Web designers who learned programming, and programmers who learned the basic Web technologies and/or plugins. (Today, with the industry being somewhat more mature, I’d say there’s a third group, who come straight into full-on front-end programming of JS-based web UIs at the same time as they’re learning HTML and CSS.)

Crucially, this means you have some web developers who have broader programming experience and/or formal training, and others whose knowledge mostly comes from online tutorials and QA sites and from the knowledge and culture passed on by their peers. The former type probably have some understanding of software architecture for more substantial applications, and might well have had a reasonably systematic data model, separated business rules from the rendering(s) of the underlying data, and so on. The latter type often aren’t aware of these concepts and tend to write much more hacky code — such as keeping application state in the DOM — because they don’t know any better.

Adopting a comprehensive framework can mitigate that lack of knowledge to some extent, which I suspect is a big part of why the heavyweight frameworks caught on in front-end work just as they did in desktop UI work earlier, but ultimately there’s still no substitute for knowing what you’re doing. Today the same type of people who used to keep their application state in an ad-hoc mix of scattered variables and the DOM are trying to build their entire application architecture with React components and either scattering the state and business logic throughout those components or, in some cases, adopting a heavyweight data management architecture like Redux instead.

What are some specific quotes from the article that you feel are "crapping all over React's contribution"? Genuinely curious, because I don't take the tone of the article that way at all.

Do you have a reference to this claim?

I think the parent was referring to something different. When you work directly with the DOM your _view_ logic is stateful. In the old days (jQuery, Bootstrap, Knockout, etc) you were spending a time simply keeping your data and your view in sync -- and god forbid you were trying to re-use some of that view logic in multiple places.

Sure, and we had the era of one-way or two-way data binding libraries as a response to doing that manually, which at least provided a quick, simple solution to that problem in the relatively common case where you were presenting a set of mostly independent data points.

However, we also had designs that were based on ideas like MVC (the original one, not the server-side framework style that hijacked the term later) where you had part of your code storing the real state, event handlers triggering updates to that state in response to user actions, and rendering code that was triggered in turn to redraw the relevant parts of the UI or update the contents of any affected form fields. This sort of architecture was using essentially the same set of software architecture ideas that we’d been using in desktop or more traditional client-server software for a long time and applying them in the context of JS (or Flash, Java, etc.) running the browser.

this is absolutely the 'revolution' that React brought front end centre - declarative UI's for the web. This is why people that enjoy working with react enjoy it so much, whether they know it or not.

Implementing a virtual DOM and VDOM diffing is just one way to manipulate the DOM more efficiently and intelligently. At my work, we've chosen a different path without the overhead and leaky abstraction of a virtual DOM.

We built our own component-based SPA framework and recently open sourced it ( https://github.com/ElliotNB/nimbly ). Each component must have a definition of what state mutations should trigger what portions of the component DOM (via CSS selectors) to refresh. There's no extra overhead for a VDOM and VDOM diffing at all. The only overhead is accrued ahead of time by the developers who must write a definition of how their component should update in response to state changes. When state does change, the framework bundles up the queued DOM changes between all components on the page, identifies/eliminates any redundant changes and refreshes the DOM in one go.

For one thing, all the frameworks at the time we’re doing 2 way bindings. Which meant that the smallest change could end up triggering a bunch of computeds and observables, to the point where any change would trigger a bunch of re renders.

React bundled all of those into a single rerender. Further, and I may be mistaken about this, react helped dispel 2 way binding and show that 2 way binding was a performance and reasoning disaster. If that was the case, I’d suppose eliminatin g 2 way binding also likely played a large role in the performance improvements which may potentially have been incorrectly attributed to the VDom.

I tried 2-way binding in ExtJS and it seemed to work well at first then I started adding more and more binds to the component and at certain point performance just tanked.

And it was after I started with React already so I just didn't bother to investigate, issue actually was some kind of loop being formed and things aborting due to hitting limits. Which I guess means I used it somewhat incorrectly but I never had that issue with react.

I was involved in that, mostly from when my paycheque involved throwing together websites in Drupal 6. Holding that architecture together was trouble enough without having to also care about the frontend, we were only scripting it. The idea of the HTML being considered an 'app' was utterly alien to me and my colleagues at that time.

I fondly remember the short period of time where we had post after post attempting to explain what a closure is, because for most of the authors back then the concept of a function pulling outside variables into its scope was utterly alien to us. Even now this practical meme persists[0].

Ten years later and I find closures more intuitive than half the stuff we've concocted in OOP land.

More than that, jQuery was a means to an end and to shove low-effort animation and UI into an app to make it look snazzy and 'Web 2.0' like (glass effect banners, drop shadows and all). If it wasn't jQuery it was script.aculo.us.

Then we got Backbone and Coffeescript at around the same time, by which time I was a Ruby dev. Backbone contributed to a fundamental shift in how we build a frontend, and we had Knockout, Sencha, ExtJS, etc. following along. And then the concept of 'comet' (keeping an HTTP connection alive for long polling) and MeteorJS.

The impact of React and its concept of the VDOM has been phenomenal. It may be overhead as the Svelte authors say, but the experience of working with React, and any similar library in the ecosystem, is a boon to anyone who wants to do serious work in the browser. Without being hyperbolic this feels like the legacy of smalltalk: programming in a dynamic environment, only you're not actually aware that you are.

There has to be a fantastic retrospective on the progression of JS since that initial ten-day genesis.

[0] https://medium.com/dailyjs/i-never-understood-javascript-clo...

The VDOM is cool, but React (& co's) appeal is the streamlined development tooling, approaches, and ecosystem where there's a mostly agreed upon way to do things.

>I fondly remember the short period of time where we had post after post attempting to explain what a closure is, because for most of the authors back then the concept of a function pulling outside variables into its scope was utterly alien to us. Even now this practical meme persists[0].

My favorite was actually when we needed a groundswell movement to make people realize that $() wasn't a variable, but a function call, and for complex selectors (before querySelectorAll, when Sizzle was a far more complex beast) you really wanted to cache it. Or, getting people to stop attaching event handlers to every row in a 10k row table, and to just match the click to the row once.

It really does feel like people have forgotten just how rough the gap was back then.

For real though. I feel comfortable building something in VanillaJS... e.g, building up a fragment before shoving it into the DOM, architecting how updates are applied, etc. This is all stuff that was hard learned, and became easier the more I stepped outside JS later on. I would in no way want a junior trying to do this without learning the better practices found in React - _not_ because they need the crutch, but because I learned those some lifecycle methods and such from Cocoa/UIKit and you need a frame of reference to internalize it all.

I disagree with this. I think the major key insight and innovation with React, which this article fully acknowledges, is that it is much easier to think about declarative UI as solely a function of the current state without having to think about the transitions to arrive at that state, and, importantly, the virtual DOM lets you do that performantly.

In other words, to take the example from the article, it would be great if we could have an "onEveryStateChange() { document.body.innerHTML = renderMyApp(); }" function, but doing that would be much too slow because it would recreate the full, real DOM. Using the virtual DOM lets you write essentially the same code, but in a performant manner, and I think the article is clear on this fact.

I'm not familiar with Svelte, but the article has peaked my interest because it is making it sound like it lets you write declarative UI but without needing to do the full virtual DOM diffing.

and LitElement gives you a base class for Custom Elements that uses lit-html with Shadow DOM: https://lit-element.polymer-project.org

I agree that a large part of the problem is the lack of proper architecture and general poor quality of practice but that’s also a problem for the distinction which you’re attempting to draw. I think the core React team likely meant what you meant but the community’s love of both fads and crapping on whatever isn’t new and shiny meant that nuance was deeply buried under the “it’s go-faster magic from Facebook!!!” marketing train.

I remember having absolutely surreal experiences where it was like “why are you saying it’s faster? Here’s a benchmark showing it’s 5 orders of magnitude slower.” “It uses a virtual DOM” “I know, but don’t you have a benchmark where it’s actually faster?” “You just don’t get it”.

I do think React helped bring some improvements around architecture but I think an under-appreciated part of that was that since it required a full compiler toolchain, 100% of projects could use the latest JavaScript features (notably ES6 classes and arrow functions), data structures, modules rather than rewriting everything, etc. which noticeably reduced the number of complex things people had to get right, tune, and reason about.

StimulusJS is a modern approach that uses the DOM to manage state. In my experience it has proven to be quite simple and performant.

https://stimulusjs.org/handbook/managing-state

You could say that we should just optimize our JQuery, and you'd be right. We just don't have structured way of figuring out everything that touches a "component". (What is a component anyway, when it's all adhoc).

Components are a very powerful concept that goes way beyond the common scenario of building a web page and updating it with some data.

It wasn't a toddler mistake, but it was repeated over and over to convince people to move to React.

Don't care and I am guessing you didn't read the article. Ignorance of the DOM does not redefine what it is. This is just as true for jQuery stupidity as it is for React virtual DOM nonsense. Fortunately, the DOM is defined in a standard specification so there is a document of truth that you can go read.

> In short - the DOM was often used to store state. And this just isn't a very efficient approach.

Again, don't care. Other people's misuse and stupidity is their problem. That stupidity does not alter the technology specification.

If you really want to know what the DOM is I wrote a very brief summary with links to the specifications: https://prettydiff.com/2/guide/unrelated_dom.xhtml