The Failed Promise of Web Components

Here's what killed web components: lack of native databinding on the web. That's the reason the standard is useless without JS. Any modular, dynamic, modern UI requires databinding, which means it's going to bring in a framework anyway, which means that self-contained widgets are all going to bring in their own frameworks, which means that instead of one large framework on the page you have five or six, all of them stitched together through rickety HTML-attribute APIs and custom value-parsing strategies because HTML attributes are just strings.

I fail to grasp why databinding hasn't made it into a web standard yet. The web has a long tradition of feeling out features in the JS world before adopting the successful ones into the platform. jQuery turned into querySelector() and fetch(), CommonJS modules blazed the trail that led to ES modules, etc. And this next paradigm is more than ready to get standardized. Not only would it make the dream of web components possible, it would eliminate the need for a whole lot of the JavaScript out there and even make UIs faster, since reactivity logic would be implemented natively.

It's such an obvious, ubiquitous improvement to the web that I can only assume there's some fundamental implementation roadblock I'm missing.

I'm not an authority in this area, but I seem to recall that because React uses a synthetic event system, it won't interoperate with Web Component bindings and emitted events. (I know React doesn't work well with Webcomponents, the part I'm unsure of is whether it's specifically due to this).

React also doesn't have an easy means of turning React components into Web Components for publishing and consuming. (Preact does though, they put a lot of work into it).

Svelte, Vue, and (I believe) Angular can all emit web components.

In Vue, you can use the framework's standard data-binding and event capture syntax to interact with custom web components. You wouldn't be able to tell the difference between a Vue component and a Web Component you imported from a package.

(I can't speak for Angular, maybe someone could chime in here.)

To me, it represents a huge failure on the part of the developer community not to make publishing web components the standard.

It seems silly to write a wildly popular component/component-library, and vendor-lock it to a single framework. Why not just publish a web component version as well?

https://cli.vuejs.org/guide/build-targets.html#web-component

https://preactjs.com/guide/v10/web-components/

https://dev.to/silvio/how-to-create-a-web-components-in-svel...

https://angular.io/guide/elements

The problem is that if you're writing a Vue app, and you import a web component that was written in Preact, you're now loading both Vue and Preact onto your page. That means your app will take twice as long to load. That is a huge downside to weigh against the inconvenience of having to find a version of that widget that's built specifically for your framework, or even just building one yourself. The compatibility layer doesn't matter if nobody's going to use it.

> To be frank, I think in large part this is due to React

I'm not sure. I think React saw that the web components model was broken and didn't waste the effort trying to stick to it, and built their own separate React world that wasn't broken and that's why they've been so successful. It's a shame and an indictment of the web platform, but I think from their perspective it was the right decision.

The real shame would be if React's mindshare is the thing now holding us back from finally solving this at a platform level. I can only speculate about that, but it doesn't seem out of the question.

Preact is like 3k minzipped. Just loading it will not make your app take twice as long to load.

Yes, this is what I meant when I said the post is too snarky, but I don't think it's fair to take that as representative of all "webcomponents supporters". That JS exists to fill a gap left by the platform, and it's a gap that should be filled by the platform, but it's also a gap that isn't filled by the platform.

> I actually hold the opinion that it was never even a good idea, because it’s simply the wrong abstraction layer to be extending on

I disagree. HTML is a profoundly intuitive and accessible standard which reaches far outside the normal bounds of software developers. This is evidenced by the thriving diversity the web has experienced (before everything moved to closed platforms, that is). For static content it already provides an exceptional balance between expressiveness and accessibility, and the dream of web components was to bring that over to apps as well. And I really do think that idea is still a good one.

How does "blaming the customer" help here?

It's not the first time that a standard doesn't fit the people it was created for...

Everyone is worse off for it. It may be that a spec/implementation does not exist which can satisfy these needs but it would be beneficial for all.

Of course it's a framework, it provides a data-binding system that is incompatible with other frameworks, and which isn't simply a polyfill.

Svelte is the outlier here, where the end-product is fully compiled to standard API's without a runtime. Maybe we'll see more frameworks adopt this approach in the future.

I tend to agree with this broad idea. Although I don't think it's because it was left out or someone didn't do it. I think it's because it's REALLY HARD™. This is certainly the problem that React/Vue/etc are trying to solve. But I think web components never lived up to the promise because as an industry we simply haven't solved that problem yet. OOP possibly came as close as we've come. The various JS frontend frameworks have also been a decent attempt, but I just don't think it's good enough yet.

If I had to guess I'd say that FRP, functional programming's take on it, has the best chance at succeeding here. But I don't think it's quite there yet either. And even if it was, you still also have to confront the fact that the HTML/CSS split doesn't completely live up to the goal of the style being completely independent from the markup.

> This is certainly the problem that React/Vue/etc are trying to solve. But I think web components never lived up to the promise because as an industry we simply haven't solved that problem yet...The various JS frontend frameworks have also been a decent attempt, but I just don't think it's good enough yet.

I think the territory has been thoroughly explored at this point, and simply taking one of the established approaches and implementing it in C++ would be the right way forward. Now, back when web components were really making waves the landscape was different. This new wave of reactive frameworks was still fairly immature, and maybe in hindsight that's why they didn't standardize databinding at that time: it wasn't yet obvious what to standardize on, exactly. But I think in 2020 we're now past that point.

With some minimal JS, you can update each web component already. Is writing nameField.innerText = response.name really that difficult? What problem does it solve to make a standard for it? As for (de)serialization, JS has built-in support for JSON and XML. HTML attributes are everything but rickety in my opinion, as any decent parser will allow you to access them as if they are a normal dictionary. Put JSON in them if you really want to encode complex data in attributes, although you probably shouldn't.

I strongly believe the abhorrent overuse of React and other such libraries on the web is the sole reason our computers have gotten hundreds of times faster but the web is only slightly as quick. I don't see a place in web standards for a React-style functional design because of the specific rules each of these libraries have.

Definitely agreed. If you want an example of Web Components working cross-framework, look at Ionic and Stencil tbh.

The observable proposal has existed for years. It's still in stage 1 and was last presented in to the TC39 in 2017 [1].

There seems to be an almost total disconnect between the needs of web developers and what the TC39 is working on. Data binding and reactivity are two important points, but also the need of optional static types which should be obvious by looking at the meteoric success of TypeScript. This is nothing new, it has been discussed since ES4 times 10+ years ago.

[1] https://github.com/tc39/proposals/blob/master/stage-1-propos...

If browsers provided data binding and reactivity out of the box, frameworks and applications would be much faster and lighter.

Separation of languages is a silly way to separate things. You're building components: logic, structure and style are coupled. SwiftUI adopts the React model, and it succeeds because of it. One can build an app in React/SwiftUI in about 1/2 the time spent "separating concerns", and build systems still extract things out to be clean and performant, there's no sacrifice being made there. CSS is a shitshow and a total mess especially on large teams.

React has nothing to do with how performant an app is and if anything speeds them up compared to anything previously, you may be confusing the power and ease with which it enables development as getting some drunk on building larger apps, but that's only because of how effective it is. Twitter is a good example, great performance. It's way more about the team than the tool, though certainly it will get easier over time to have the defaults be better at optimization for smaller teams who are ambitious.

Most of the super bloated websites I see are basically news sites and other less-techy sites that are stuffed with ad tracking and have no tree shaking. The majority of React apps build with Webpack which supports tree shaking and lazy loading out of the box, plus React makes it possible to pre-render your entire app and deliver it as HTML that hydrates.

Whenever a feature gets added to standard HTML, web frameworks and "polyfills" keep implementing their own versions because the standards don't fit them and they don't want to rewrite (or keep their own implementation as a mere fallback).

Even if a data binding framework would be standardized today, it would take years for browsers to catch up and gain critical mass. There'd only be more polyfills and Javascript to help support people running IE11 or whatever.

I'm glad many JS features have been implemented natively in HTML5, but this specific case feels overkill to me. HTML templates have been introduced and then ignored by frameworks already and I doubt any framework would switch over to a new data binding API if it became a standard today.

Most (all?) of what is enabled by observable should be possible with Proxy, right?

Good React is fine for large applications, but not for websites. Even in applications a few lines of Javascript and a rendering backend can replace entire JS frameworks. Try disabling Javascript for a day and you can see how many pages just become a white screen because whatever is replacing the browser's renderer isn't loading.

> Twitter is a good example, great performance.

I agree that it's a great example, but it performs horribly for me. I use their website on my phone and videos rarely play back properly, content jumps around while navigating, empty screens and loading bars are everywhere. Sometime I just have to reload because the Twitter website decided it doesn't want to load images anymore. Nitter links, on the other hand, load instantly, including image and video content, because of its minimalist approach.

Server side rendering is a welcome improvement because it means the developer doesn't offload the website's calculations to their visitors. I'm fine with whatever framework people pick on the server, as long as my browser doesn't get its rendering engine replaced by the fancy framework for the week.

I mean... maybe in some legacy plugins that budget-shops drop into a Wordpress site without thinking. This stuff doesn't really happen anymore in real projects; there's not much point.

> Whenever a feature gets added to standard HTML, web frameworks and "polyfills" keep implementing their own versions because the standards don't fit them and they don't want to rewrite (or keep their own implementation as a mere fallback).

I think you misunderstand what polyfills are. Polyfills exist as an implementation of the standard, before the standard has been fully supported. They get stripped out when possible. In no way are they "their own version" of the standard.

> Even if a data binding framework would be standardized today, it would take years for browsers to catch up and gain critical mass.

It definitely wouldn't. All major browsers get silent auto-updates now, and Chromium alone has over 75% of the market share now that Edge is based on it. Google was the one pushing web components in the first place, and today Firefox and Safari would face pressure to keep up lest they lose ground when more sites become "just for Chrome". The silver lining of the browser monoculture is that features get implemented quickly.

> There'd only be more polyfills and Javascript to help support people running IE11 or whatever.

Possibly. But in today's world polyfills are less and less necessary (see my previous statement). Most companies these days just write off IE and outdated browsers as not worth bothering with. And for all those other browsers, there would be a dramatic drop in the amount of Javascript.

> HTML templates have been introduced and then ignored by frameworks already

HTML templates are the prime example of how useless the web component standard is in its current form: they literally just hold DOM nodes. Those DOM nodes can't appear on the page without being cloned by JavaScript. They gain no special functionality. They just sit there. Templates without databinding are hardly better than an HTML string.

It's the same reason I prefer a structured MVC project over a PHP file with the contents echo'd in with <?= ?> statements. Both get the job done in the end, but one is clear about where what responsibilities lie.

Downloading 500kb of js and processing this is just a nogo. The best advice to anyone interested in page speed, dont use this crap.

https://youtu.be/plt-iH_47GE

Maybe in some experimental project, but I've never seen this in any video site.

> input elements such as calendar controls are rewritten

Yes, because the native browser widgets are totally insufficient and can't be styled.

> animations are done in JS instead of smooth CSS transitions

JS animation can be super fast (see GSAP) and it seems you're talking about jQuery.animate() which I agree was terrible. But these days most people use CSS animations.

> drag and drop support is manually rewritten in JS

Again, because the browser does not have a proper drag and drop API to do it. I know because I've had to implement drag and drop many times. From vanilla, to jQuery, to React... for mouse and touch UIs.

Here's another huge thing lacking in the browser world: touch gestures.

That's the idea, but many projects never actually remove the polyfills once browsers catch up to a given standard. In theory they solve the problem, but in practice I'm still ending up downloading polyfills on Firefox and Chrome because Safari doesn't support a particular API. Sure, the code barely executes, but the bandwidth is wasted regardless.

> It definitely wouldn't. All major browsers get silent auto-updates now [..]

Tell that to mobile Safari. Updates are packed into OS updates and features regularly take ages to be implemented. One day we'll get WebP and notification support. One day...

> Templates without databinding are hardly better than an HTML string.

Templates without databinding provide everything you need to render a component; structured elements that can be filled out with code. With class names and query selectors they can be filled and rendered very quickly with little code and no need for a framework.

Using the API properly can ensure that inserted text is never seen as code, making it free of the injection attacks that HTML string replacing often exposes. Content and structure are clearly separated and provide no challenges for the browser to parse. Generated components are always well-formed, which string replacement also doesn't guarantee, modification of contents is no different from regular DOM updates.

Except this barrier has never existed. Every HTML input is interactive: text fields, checkboxes, radio buttons. They not only remember their value, but your cursor position within them and the segment of text you've highlighted. The browser knows how far each scrollable element is scrolled, which element is in focus as you tab through the page. Forms have validation state, and can be interacted with to send an HTTP request. These days you can even do autocomplete with nothing but HTML: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...

The magic of HTML has never been about static layout, but about having a declarative language for building out an interface (not just a static view, but an interface). This idea that it should be nothing but a dumb view-layer is a new one, popularized by the very frameworks you're railing against. Data binding is a way to stay in that declarative space, while dramatically expanding what use-cases can be covered within it. JavaScript (in the browser) was, and always should have remained, a trapdoor for working around HTML's shortcomings. It's a Turing-complete language for doing things that can't be done any other way. Anything that can be neatly siphoned off from that more complex imperative world, should be. For the sake of complexity, for the sake of accessibility, for the sake of performance, and for the sake of compatibility.

I would have expected something more akin to RXJS, MobX, or even the Svelte reactivity system.

And we still separate concerns on the desktop. The model/view/viewmodel paradigm is pretty good.

With 150 years of evolution (at current W3C standards pace) you might get an HTML spec that is capable of expressing the behavior that users expect from present-day applications. Until then we have React et al.

HTMLElement have properties too, and custom elements can accept any non-string data via properties instead of attributes.

I don't want them to be styled, thank you very much.

> JS animation can be super fast (see GSAP) and it seems you're talking about jQuery.animate() which I agree was terrible. But these days most people use CSS animations.

GSAP is giving me stuttery animation when I scroll through their website on my phone, presumably because it's constantly updating the DOM to keep control of the animation. It's not as bad as the state of JS animation was 10 years ago, but I can think of very few use cases where such a library would actually be necessary instead of using pre-calculated CSS transitions and such.

> Again, because the browser does not have a proper drag and drop API to do it.

I haven't had that much trouble when I had to use the HTML5 DnD API. Well, not more than with the frameworks I've seen; touch screen DnD support sucks on all platforms I've tried.

Secondary languages are a bad idea, so hopefully this templating language would be something like jsx/ejs.

The proposal really is to bake applications support in to the browser. That seems right to me. The browser is more and more an os, and it should support rich applications out of the box.

React is derivative of windows application development, so there is precedent for something like it to be baked in to an OS.

Takes 4kb to full page render (1 file - static only - JavaScript disabled).

That’s smaller than most any html+css especially if using some css library.

Of course once that is loaded and if JavaScript is enabled, then it will start to load interactive stuff and prefetch (which is around 100kb - but I have a lot of interactive stuff - including a zork style adventure Easter egg in the site header).

https://developers.google.com/web/updates/2019/02/rendering-...

I think WebComponents have left a horrible taste in the mouth because they came well after React and others existed, didn’t take any inspiration or provide any abstractions that would help, did basically everything worse and seemingly without any discussion with real world devs, and then were hyped and pushed on everyone for years while they basically lacked all necessary features. Now, years later they have evolved and added libraries on top to smooth over all the weirdness, and if you squint they look similar, but the web would have been a better place if they had just provided some VDOM abstractions, style containment in a simple way, and so on rather than master-planned a High Modernist dystopia and then slowly painted over it until it resembled something like the organic cities that already existed.

The nitpicks you have on Twitter are on specific behaviors (video and jumping and slow fetch) that have nothing to do with React. The site itself is lightweight and runs fast.

This is comparable to hacker news home page (which is purely static), but my first contentful paint was slightly faster (probably because my site is slightly smaller).

Both sites were about 4 times faster (TTI) than google home page and typescript home page.

"Modern Frameworks like React/Vue/Angular and Web Components are built to solve different problems. Web Components provide strong encapsulation for reusable components, while Frameworks provides a declarative library that keeps the DOM in sync with your data. The two goals are complementary. As a developer, you are free to use a Framework in your Web Components, or to use Web Components in your Framework, or both."

https://reactjs.org/docs/web-components.html

I have a side project for selling reusable HTML blocks/sections, some people advised me to convert it into Web Components since it can be reused between different Frameworks (React, Vue, Angular, etc) at the same time.

After reading this discussion, I think we should build a native components for each Framework.

Current low level DOM API has something that fancy reactive data binding techniques will never have: ability to efficiently be used for an extremely wide range of data binding techniques and philosophies.

You go ahead and require implement something like virtual DOM as a standard, then what is everyone who doesn't want virtual DOM, or even this particular flavor of virtual DOM supposed to do? Virtual DOM designs are high level and not extensible. That is not something we need to be forced onto us for decades to come.

That might be hard to understand if you like React and its virtual DOM, and assume something like that will be made the standard, and will remain in fashion forever. How about: Angular v1 bindings are now the standard built into the DOM. How do you feel about that? That's how standardized virtual DOM will feel like in 10-20 years even to those who like it today. No matter what kind of data binding design you choose, React, Angular, some variation of observables or what, it will suck for a lot of people, and increasingly so as time goes by and fashions change.

Data binding is a solved problem on the frontend. It's just solved by libraries in many different ways depending on the developer's preferences. There is nothing wrong with that. The long term cost to centralizing all this diversity into a single opinionated high level API blessed by W3C is completely unacceptable. The low level API is working just fine today.

1) Classes for writing components. Yuck. React's function component feels much more elegant.

2) @property decorator. Double yuck! I want a reactive way of updating my component's state without having to declare this piece of state as a property accessible by the outside world.

3) this.requestUpdate(). Triple yuck compared to something like React's setState or useState hook.

4) In order to create children components, I need to create more customElement-decorated classes? Yuck again!

React + react-dom is under 40kb minified gzipped. The other 460kb are your responsibility.

I strongly disagree.

Form/<input> fields are one of the areas that a native app can slaughter HTML, even if using a WebView within an app. For example, just showing the correct keyboard layout is a nightmare, and heaven help you if you need to do something slightly custom. Another example: browsers do funky shit with scrolling and zooming on input focus. Try using the best HTML code-editor from a tablet: the editing experience sucks.

Another example is swiping, where browsers like Safari Mobile (and the old Edge) decide to navigate back/forward if the user happens to swipe from the edge by mistake - killing page state. Overriding pinch-zoom for say a photo app is doable, but sometimes ends up with invalid UI states (especially if you mix in viewport sizing changes due to orientation/ua-zoom/virtual keyboard show/tab bar show).

Disclaimer: I have spent many man-months working only on making user friendly custom <input>s in HTML, and the experience blows chunks. I have developed a custom Web UI that required too many compromises in UX.

Here is a post that explains some of the content that is interesting: https://ricklove.me/cool-stuff

Let me know how it does on a slow connection.

It’s literally just an attribute on the input element?

Look at the new default "razor pages" web project for .NET core. While it it is a little bit fancier, it basically brings back the same mental model that PHP has been using for decades. That is, cram all of the logic into a single file, and use a "service locator" pattern (I know it's actually DI under the hood) to "inject" extra functionality. In this way it is easy to trace where all of the pieces are coming from. Why abstract your `UserRegistrationView` to accept any `UserRegistrationModel` from a `UserRegistrationController` in a "decoupled" manner when the reality is that only one of any of that actually needs to exist ever? Might as well have the orchestration right next to the use-case!

The above applies to (what I believe to be) a significant majority of use-cases. At least the interesting ones.

Popular browsers such as Firefox and Safari don't have native date controls: https://caniuse.com/input-datetime

JavaFX bindings are a joy to work with and everything "just works". You have FXML for Mark up, you have controllers for logic, and you have the freedom to create your own beans or database classes or use Spring or whatever you want to do. JavaFX is arguably an external library, but since it is packaged with Java I would say it is closer to being part of the standard library (certainly more so than React is part of JS).

There needs to be a dead simple way to tie the properties of a Web component to a JSON object. That's all it would need for now. I could develop some great small-medium Web apps without a single line of external JS with that alone. No more event triggers followed by queries followed by DOM manipulation. I just want to update a JSON object, and have that immediately reflected on the UI, for both built in and custom components.

I agree! And this is something we plan to address in a future version of https://braid.news!

One problem with standardizing this now is that we don't have a standard for "data that changes." Braid is adding that to HTTP so that you can subscribe to a changing URL. Once that works, we just need a standard way to bind a UI widget to the URL.

No it really shouldn't. Just look at JS. It's a complete mess. And HTML would get there in a short time if they were to adopt "anything that can be neatly siphoned". The problem is that data binding is actually quite complex. I have seen data binding done 10 different ways in different languages and they all had their flaws. It will be very difficult indeed to come up with such a standard that is actually being used universally.

If it is not, what sense does it make to add it to the standard? But for it to be used a lot, it would actually need to solve most problems in most businesses for the forseeable future.

Given the fact that the Web apparently still hasn't figured out quite how UI development is supposed to work (judging by the 1 new language feature, 10 new frameworks, 100 new libraries developed each day), it will be a very poor idea to start baking half baked stuff into a standard.

Sure, and in a single project at a single company that's probably fine. You've all agreed to standardize on a single version of Lit-Element and compile the whole project at once, so no worries.

But if the goal is to make Web Components standard units of UI across the web, such that you can grab a `color-picker` component and a `webcam-video` component and put them together into your `video-color-filter` component... well, if color-picker depends on vue and webcam-video depends on lit and you write video-color-filter in LWC, your project now depends on three web component libraries.

It’s ironic that this is done in the name of “Separation of concerns“ -

You know what separates concerns: having everything that affects this component - in one place. That’s true separation of concerns.

I’ve worked in multiple frameworks in multiple languages and nothing does it better than modern react (especially with webhooks).

Wait, what? Web browsers have only recently implemented standards underlying Web Components, such as Shadow DOM. Microsoft has only recently announced the end-of-life of IE11, which doesn't support Web Components. Web Components have only just gotten started!

> lack of native databinding on the web ... it's going to bring in a framework anyway

Here's a lib for data binding Web Components using JSX: https://github.com/wisercoder/uibuilder This is a 200-line lib, hardly a "framework".

Not really — unless React is the only library you use.. MVC is still the best pattern. If you are an iOS developer you may already be familiar with MVC in Cocoa. Most UI frameworks, including ASP.NET Core, JSP and JSF (Java based frameworks), Ruby on Rails, and Django (Python) are all based on MVC. That's no accident. These disparate platforms — mobile and Web — all converged on MVC because it is the best architectural pattern for developing user interfaces.

I build very large and complex apps for my clients using lit-html and vanilla web components.

Mostly just stay in the light dom unless there's a reason to hide in the shadow.

Works great.

Even within the frontend world and not in React you have all sorts of new state systems and structures that are in my opinion far more intuitive, less code, less cross cutting concerns, easier to change and grow more naturally. The gist of it is either a global state store with cursors and namespaces (I like this less than most) or a global state system with state split out (see Recoil) or an entirely tree based reactive state system (see mobx-state-tree or mobx-store) or even just nesting reducers or any simple nesting state container (pure react, zustand). I’ve recently put together gqless[0] with a state system similar to recoil but simpler (sort of like use-atom). It’s wonderful.

Your data is a tree/graph, you app is a tree, your file system is a tree, everything matches. You just slot in state with corresponding actions and at the level of the view hierarchy where it first becomes relevant (router at top, view controllers are spread in the middle layers however needed, and leafs get their own state as needed). And all data level things stay up in the graph, which I guess you could argue is an M sitting above it all, the VC are blurred together with more C at the top of the tree and pure V at the leafs. Even styling is all encapsulated where it’s used. Each piece is a lego block that can be moved around. And yes, it works, and works well, even without all the handlebars of Rails.

Wouldn’t dream of going back. It’s perhaps not a mature enough ecosystem for most to navigate their way to getting a good DX on a stack like that. Many pieces have rough edges if you don’t know what to avoid, it’s not like these huge mature frameworks that keep you away from scary stuff but also box you into a rigid structure. But of course it means you can do all sorts of things unimaginable in MVC land.

We have one, and it's called DOM, and XSLT to expand XML data into full fledged documents.

It's just browsermakers collectively conspired to sabotage declarative features to push their numerous JS based "bicycle reinventions."

We also had XForms, but this is an even longer story.

Just check the stats here: https://perf-track.web.app/react

Is there any other kind?

Seriously wondering if there’s something specific you had in mind ...

My take is that it’s a harder solution space than can be solved gracefully with a single technology. It’s always easier to take a more convoluted approach. I think what confuses us is the visual nature of these apps; we think we should be able to describe them visually, and maybe you can, but it’s seldom worth the time and effort.

Type “dir” in the header (or other activities in the “cool-stuff” post).

Moreover, I can build anything I want very quickly - with great engineering - and still get performance comparable to a static site.

I guess I’ll know if someone finds the Bitcoin.

Update: I added a few more nerd lore passwords - thanks for the idea!

Overall, it was a very refreshing experience.

I did notice that for some components I need to show a loading indicator while they are loading async (for a slow connection).

Thanks for letting me know!

This statement alone invalidates your arguments, because evidently you never once tried opening Twitter on an underpowered machine, be that desktop or a phone.

In any case, my critique is not levied against MVC the pattern, rather, how it is manifest. One can logically follow MVC without the physical separation of concerns (files). It's a continuum: You start by defining your state, view, and orchestration all in the same place. Should any one piece of the above suddenly need to be reused elsewhere, you then abstract as necessary.

I was pushing back against the idea that "inlining" CSS/JS with HTML is poor practice. What React achieves, because it demands you inline JS (and CSS if you want) with the HTML, is a simple, declarative development paradigm. It's like reading a function. No procedural ad-hoc `let el = document.querySelector('#id')` garbage getting in the way. The behavior is with the component, not around the component. In many ways, this is how OOP was supposed to work.

For my own experience with things that were specifically MVC or MVVM:

In C#: Asp.net MVC, WPF (with/without Prism)

In Typescript: Knockout, Angular 2.0+ (I guess it wasn’t mvc really - I disliked it for other reasons)

React (with hooks) on the other hand is the embodiment of a pure Functional Programming UI.

I can literally write a component with a single import and a single function.

For every reason functional patterns beats OOP patterns, react beats mvc - and achieves true separation of concerns (feature aligned concerns).