> I don't want to learn a complex framework. I don't want to learn magic that I don't understand without reading the documentation (useState, createSignal et al).

I can't really parse this sentence. It seems to have a lot of ideas in it. Do you want to learn a framework at all, or have one that is so magical that it feels like it doesn't need to be learned? Do you want to read documentation or not? Do you think the problem with React is that its primitives are unsuited to the work you do in it? Or to the work anybody needs to do?

I've spent most of my professional career in Vue, so I don't have a great perspective on the React ecosystem. But Vue feels like it must be included in your "complex framework" statement. I've definitely felt some pain from overuse of the framework, or poor understanding of various features, libraries, etc. The ecosystem around full-on SPAs is indeed complex. I'm just not sure what other systems would let me personally, and us broadly, manage a complex stateful client-side app.

(This is entirely separate to overuse of SPAs for things that shouldn't be SPAs.)

One aspect of this is how you think about UI. The underlying pattern of jQuery is fully side-effects -- you select an element and make some changes to it. Frameworks like React and Vue.js allows to create UI components whose states are completely determined by data, i.e. what the UI looks like is the value of a pure function, mathematically speaking. It also updates the UI with minimum DOM changes when the data changes. (Although you don't have to make them pure, and arguably you can achieve the same thing with jQuery.) Depending on where you are, it makes UI widgets much more readable and maintainable. These frameworks are innovative in terms of state management compared to "old approaches" (of course, with additional benefits like reusability etc)

Bear in mind that today's websites and web based desktop applications are much, much more complicated than two decades ago, and has a much higher requirement for scalability and maintainability. If you just want to create simple UI, indeed they may not be your best choice.

You do not need to know how `useState` works to understand how to use it to write a React application, it is fairly intuitive to understand how to apply the pattern.

If I look at your library, it seems to me like it requires a much more complex mental model to begin to use.

Of course, it is better in theory for a developer to thoroughly understand the details of their framework, but empirically, React has been very successful in allowing people to build relatively sophisticated applications while understanding very little of the underlying model.

> The current state of Front-end frameworks is an absolute mess. Speaking for myself, I don't want to learn a complex framework.

It's really not that hard. I was able to pick up Angular to a level where I could create complex sites with it, or submit acceptable PRs that involved in, in week or so.

Granted, I am an experienced developer (C# since beta, HTML/JS/CSS from the start) but it seemed to just make sense quickly.

So when I was asked by a company to replace their aging, complex portal to manage critical infrastructure, I chose Angular for the front end.

That was smooth sailing. It was stable, performant, looked good and everyone was happy.

People often avoid it because it has a "steep learning curve" but that mainly seems to come from developers who came into the industry knowing only JavaScript and maybe a little React. If you are more experienced, you can pick it up right away.

And it helps, a lot, to use such frameworks on large complex sites. For various reasons.

> I don't want to learn magic that I don't understand without reading the documentation (useState, createSignal et al).

Really now. Most devs who think to themselves "man I wonder how useState works internally" will arrive at the logical and correct answer within seconds. It's not complicated or magic. There are bare-bones implementations of react hooks (-ish) with a couple hundred lines of code. Implementing a basic "useState" and "runFunctionComponent" is easier than most third-semester CS assignments.

If that's the bar for magic, I'm surrounded by 20th level Warlocks coming up with new Eldritch Invocations for fun over breakfast.

I'm building my most recent project with web components + htmx, and it's mind-blowing how much better all of this feels to me than the typical React/Angular stack. I think there's a place for React and Angular and technologies like them, but 90% of the projects that currently use them would be better off with a much simpler stack.

> In my view the only thing we should retain from the React era is JSX

honestly lit-html is much better and based on existing browser APIs. We should make it part of the webcomponents spec! Which is a work in progress:

https://github.com/WICG/webcomponents/issues/1069

Have you tried the Lit library? Using lithtml to write web components based on Lit Component is DREAMY imo, if you’re into web components. It really reminds me of using jquery’s helper methods for ajax - like why wasn’t it just this way by default all along.

I work with web components within a FAANG company, it was a huge mistake and everyone hates it. If your argument for web components is that they're "so intuitive you don't have to learn" then you're lying to yourself.

Yeah. I know React quite well, there are legitimate use cases where it shines, but...

What we've lost is the ability to say "let's make a website today" and just start making UI without build tools or crazy install trees or massive libraries that need maintenance and security updates, and drop it on a server somewhere.

I keep thinking I can have that back... ES6 imports are fully supported now, modern CSS is amazing, all we really need is an SSR/a11y-friendly way to do some kind of nestable HTML macro/component, and we can party like it's 2007 (but with grid, and import statements, and all the other new shiny objects).

In my admittedly little experience with shadow DOM, it doesn't isolate as much as it claims. CSS variables pierce the boundary, so if your styles are built around that, you can still run into trouble.

I just haven't seen any benefit whatsoever once you have CSS modules. And CSS layers help too.

For the specific point about useState, I agree about it being too magical. These days when I do write frontend code I use Reagent in Clojurescript. (I use Clojurescript partly for other reasons like its elegant syntax that's better than JSX, and built-in immutable data structures.) Its implementation of (r/atom) is a whole lot more intuitive: you can even think of it as a mutable pointer where the dereferences are tracked. On the other hand useState just feels like a hack for people who really want to avoid writing both classes and closures, and it is a roundabout way of doing things that could have been done in a much more standard and familiar way.

How does your library deal with state management and data flow? What primitives does your library offer for optimization?

JSX is the worst part of react so I find that to be a pretty wild take.

> In my view the only thing we should retain from the React era is JSX

How do you deal with the non-existing difference between attributes and properties in JSX? Is every attribute a property and vice versa? Do properties reflect back as attributes?

If you use web components enough you realize why tools like useState exists then you have to bring in another library like alpine to offer the functionality.

The whole point of web components is the ability to offer class encapsulation within the browser without anything other than a file server.

JSX has much nicer syntax but I’d rather not have to deal with the overhead of launching a node server. Makes developing time quicker when working with smaller codebases.

Well, there is a project to convert react components to native ones[1]... this way you can write react and use it everywhere. I think this is the way to go, similar to svelte's approach. Write what you want but compile it to native standards.

1: https://github.com/bitovi/react-to-web-component

> I don't want to learn a complex framework.

Completely agree. As a casual programmer, I just want something simple, inspired in VB6.

You implied but didn't say explicitly, are you doing your front-end development with web components now personally?

> I don't want to learn a complex framework. I don't want to learn magic that I don't understand without reading the documentation (useState, createSignal et al)

I'm always suprised reading statements like that. No offence, but maybe you're in wrong career if you don't want to learn how most popular and important tools of today work... Not to mention that its so simple you can learn everything required to be efficient during lunch break

> In my view the only thing we should retain from the React era is JSX (for many reasons, true type-safety, autocomplete etc)

Warning: opinion incoming.

JSX is one of two reasons that I never liked React at all and wish it would go away.

I've been developing "web applications" since the latter half of the 90s. I've worked with everything from an in-house built dynamic template language (very similar to what PHP did in the early days) developed in C++ and served using CGI in Apache, to developing with PHP to Java Spring MVC to Django to modern frontend frameworks including both React and Angular.

JSX reminds me of what PHP was like in the 90s and early 00s. People adopted it widely because the barrier to entry was extremely low. We had all of these static HTML websites and "developers" could just go in and start adding control flow to those documents in order to add dynamic functionality. It was easy ... and it quickly turned into a complete mess so big that PHP ended up with a reputation as being a toy language that "serious programmers" wouldn't be caught dead touching. That reputation was a bit unfair but also kind of earned.

With the rise of PHP's popularity, the PHP "community" itself came to realize that they had a decent turing-complete programming language that they were working with, but that this idea of mixing business logic within HTML documents was a massive anti-pattern. It's ironic that what began its journey as a template language eventually realized that the best thing for the language was to stop using it as a template language, and to adopt different template languages such as Smarty in order to promote a separation of concerns between view / presentation concerns and business logic.

React was never created as a "framework." There are actual frameworks that are starting to come out that use React for its view layer, such as NextJS, but React itself is just a library that allows you to create custom components and then choose your adventure when it comes to what other libraries you want to mix and match. But because people reach for React to start throwing together dynamic frontends quickly, everything is compononent-first. So it actively encourages you to put business and integration concerns in what really ought to be your view / presentation "layer."

And JSX magnifies that problem by just being JavaScript. So, again, it's PHP all over again. You've got a very powerful turing-complete programming language that you intersperse with your markup and you get messes. Even in the most well-written, concern-separated React projects I still see a lot of "ugliness" that comes through with JSX.

I did mention that it was one of two reasons I'm not a fan of React, the other is that - again because it was only conceived of as a component / view library - there is no inbuilt view encapsulation / scoped styles. This problem is somewhat mitigated by CSS modules these days. But view encapsulation is something that I've always seen as Angular's killer feature - the ability to just style your tags directly and create component markup that is completely devoid of class="" attributes. Angular and VueJS actually trained me to hate 99% of class="" attributes and to think of them as a type of code smell... just because it is possible to create higher-level components that don't have any at all but still styling when needed.

[dead]

> I never had to guess what "useState" does behind the scenes.

It's weird to me that React hooks are always dragged out in these arguments as some kind of bogeyman. If you understand the idea of a virtual DOM and a render loop, then it is only a tiny step from there to understand hooks. And you can understand all of these concepts in about 15 minutes: https://www.youtube.com/watch?v=1VVfMVQabx0

I just don't get all the hand wringing regarding frontend frameworks. I've been using React since 2014 and in 10 years, there has been exactly one big change to the framework: hooks. When they came out, I spent 15 minutes to understand them. It didn't kill me.

And React has been undisputed king the frontend frameworks hill for at least 9 years, but people still act like it's some sort of ever-changing, confusing landscape of options. If you want boring, stable front-end development, choose a super popular, well documented tool like React. Or if you don't like frameworks, use vanilla JS. It's not a crisis.

Sometimes I don't understand this argument because theres nobody forcing you to always be on the latest version of a framework. You could have just stayed on the version of Vue you were using without issues. Unless theres some compelling reason you could use it into the end of time and be just fine.

Thats not to say that maybe for your use case you could have not used it in the first place or that removing the dependency was a bad idea - just that if you do like Vue there doesn't seem to be anything forcing you to always be on the latest version.

If you can rewrite to remove all dependencies except for d3js, why couldn’t you do the same thing, but also retain a dependency on Vue? What is it about Vue that requires the extra dependencies - is it built system things? (I’ve never used Vue)

I'd argue that if you get the hang of it, development in Web components won't be slower than in any frameworks.

So I don't understand why VC ecosystem can't get by without frameworks.

I doubt you're authoring all web components by hand. I doubt you're not using any external dependencies.

even Rich admits this is not a top priority goal of svelte, so do not be surprised if the reality falls short of the promise.

Vue also does this! https://vuejs.org/guide/extras/web-components

There are two models of the "web", where HTML is a document and where HTML is the scenegraph of a more complicated app.

If you're using HTML as a document you can use web-components to include fancier interactive real-time feature

* A terminal emulator web component that attaches to a websocket * A date picker web component, add features like checking if a date is already taken * Custom form elements in general, a search-box that takes a URL for auto-completion suggestions * A map, but not a full mapping application * A data table, like the jquery plugin of old * Lightweight interactivity like tab widgets * Basically any of the custom components that jquery-ui provided

Yes you can do all of these without webcomponents, but the HTML is a lot cleaner and a lot more document like if it's a custom component. Mixing the model and scenegraph views of the web is not my favorite. It sure would be nice if there was a consistent library of web components available.

You can actually do pretty decent live-chat with something like HTMX and server-sent-events, I think. But it's sort of a progressive-enhancement view of HTML as a document model.

Full native isolation. HTML, CSS, JS, the whole thing, no tricks, the browser isolates it for you. It's really nice to be able to make a web component, clearly define the JS, HTML and even CSS API in terms of variables, and then throw it into any environment without it breaking, or without creating a complex maze of CSS name spaces and framework dependencies.

They are very good for progressive enhancement, for example you could have a web component that wraps a <table> to add fancy features like filtering or drag-and-drop reordering. If JS is disabled or fails to load, the user just gets a plain table, but they still get the content. When this stuff was new, that was much better for the user than what would happen with a front-end framework (they would get a white page), but now server-side rendering is widely available in those frameworks it’s less of a selling point.

They are also good for style encapsulation, i.e. you could drop someone else’s component in your page and not worry about it affecting or being affected by your CSS. Anecdotally I feel like that is less of a common desire now than it was ~10 years ago, with the rise of both “headless” UI libraries (behaviour without dictating appearance) and the prevalence of scoped styles in front-end frameworks.

What does annoy me about the standard is that to use slots you must opt into the shadow DOM, which means that if you’re trying to create reusable components for your own stuff, you can’t style them just by dropping a stylesheet into the page. I’m sure there’s a technical reason why this is the case, but annoying nonetheless.

the examples probably avoid talking about the dynamic APIs because they are super ugly and very stateful. It's hard to say that Web Components are the future when your demo shows 200 lines of manual DOM reconciliation.

Web Components let you use a UI component made in a different framework than yours. That's it. For most other purposes they're pretty awful.

Also they let you publish a UI component that works in every framework, without having to build 7 versions of it (or just exclude everyone who's not on React, or something like that)

IMO the slots that allow a component to have children are the difference. You can compose indepent components that way. Also the styles are scoped to the component by default, and you can only break the scope with custom vars (css vars)

Web components are a standard and built into the browser, Handlebars is a separate library. Web components are a way to encapsulate and isolate structure (html), appearance (css) and behaviour (js) into components, extending HTML.

It's like jquery widgets but without dependencies.

Are you genuinely asking as a professional? Seems like a big ask for someone to go over all you are misunderstanding if you think they are equivalent to a template language.

This. User agent configurability is the killer feature of web.

I use shadow DOM every day, but yes, it is often the part of WCs that baffles people – probably because they don't need it.

Alternative approaches that may work for your use case:

- "HTML web components" [1] - light DOM only, SSR-first, good as a replacement for "jQuery sprinkles"

- "Shadow gristle" [2] - use as little shadow DOM as possible. If you need styling or composition, put it in the light DOM!

[1]: https://adactio.com/journal/20618

[2]: https://glazkov.com/2023/03/02/shadow-gristle/

> I've been building apps with native WCs for a long time now, I should get off my keister and write a guide on how to make your life easier with WCs, something like "The Good Parts".

If you consider writing about this I'd like to read it. Or listen! Do you have a blog? In the process of gathering various comments about this technology as it appears there are blessings and curses, depending on how you use it.

In my last gig we had exactly the same stack (WC without the shadow dom part + just lit-html) and it's great.

The best part is not having a dependency hell situation every other week.

That's exactly it. We are just missing slots for lightDOM

I cover this in another post [1], but broadly:

- Not every web app is perf-sensitive to every extra kB (eCommerce is, productivity tools typically aren't)

- Plenty of frameworks have tiny runtimes, e.g. Svelte is 2.7kB [2]

- I wouldn't advocate for 100 different frameworks on the page, but let's say 5-6 would be fine IMO

No one is arguing that this is ideal, but sometimes this model can help, e.g. for gradual migrations or micro-frontends.

BTW React 17 actually introduced a feature where you could do exactly this: have multiple versions of React on the same page [3].

[1]: https://nolanlawson.com/2021/08/01/why-its-okay-for-web-comp...

[2]: https://bundlephobia.com/package/svelte@4.2.19

[3]: https://legacy.reactjs.org/blog/2020/10/20/react-v17.html

While this is true I think the multiple libraries problem is a rounding error when you look at the majority of web apps created today. React and react-dom combined are over 100KB. Svelte and Lit are in the single digits. So you could embed a lot of frameworks before you get close to the bloat people use every single day without even thinking about it.

A more broad observation, I'm being pointed in the parent comment - web components need to win over framework authors. The signs are not trending well here from what I've seen consistently. That community is on X and web components are not addressing their problems and they're not used in optimal scenarios. I hope web components can win them over but they're mostly saying they've been a failure, arguably on balance bad for the web.

I don't really understand this argument, to be frank. Most runtimes are pretty small, and there's not much of a performance overhead to both runtimes running at the same time. It's not like these are two realtime engines both purring along in the background or something like that. All modern web frameworks are reactive, and won't do anything unless something needs responding to. If one part of the page is built with React, another part is built with Lit, and a third part with Svelte, I don't see how that will have noticeably worse UX (or battery consumption) than a page made with just one framework, even when reactive triggers are frequently exchanged between them.

The tweet you quote is about whether web components are "useful primitives on which to build frameworks". I doubt many web component fans (who actually really used them) would say that they are. They're a distribution mechanism, and the only alternative I've seen from these framework authors is "just make the same library 7 times, once for React, once for Preact, once for Svelte, once for Solid, once for Vue, once for vanilla JS". This is awful.

The only way to get out of the current front end hell IMO is if we get client side import:

https://github.com/whatwg/html/issues/2791

I looked at your docs:

- renders very weird on my iPhone iPhone 15 Pro Max in Safari 18.0. Consider responsive design for smaller screen sizes to restyle the sidebar and set a body max-width instead of a width. You might not expect your users to develop on phones, but you might have a hard time with adoption if the docs are mobile hostile.

- the “explore components” button at the bottom of the home page seems to link to nowhere

- site claims “Learn from well-structured, accessible component implementations” as an advantage but I didn’t find any links to the implementation from the docs

- site claims “No dependencies to manage or update” but isn’t astra-ui a dependency? It has a changelog (https://www.astra-ui.com/changes/). Likewise “Full control over the code and styling” I don’t understand how I can both have full control but also be taking a dependency on implementations provided by a library.

I’m curious why you’ve decided to release this library? I’ve come to view open-sourcing internal software as useful to the company for a few specific reasons but to generally be a time-sink without much return unless it’s accomplishing a goal. Component libraries need to fight for general ecosystem adoption or there’s no audience and you might as well not publish at all.

Why would I used them over something like a Vue component?

Why aren't web components there/more popular yet? They seem like a fantastic solution

I just rewrote my company's frontend ad code in webcomponents

> I started by refactoring into web components, because I had to do it piecemeal.

Yes. The key to making an old and arcane code base understandable to yourself, is to refactor one small part of it at a time. That you're redoing with web components is just one way that would achieve this. I applaud you for not just throwing everything it away and starting anew.

On risk of this approach is that you get some way though and then move on to some other project, and someone else comes along and inherits the old project and starts refactoring in their own style, and so now you have an old arcane code base in three different styles... it still beats a rewrite of a 250.000 line code base in one go.

> they can work without JS enabled (at least in theory).

I wonder what makes you say that. All that I've seen seems to indicate[1] that Javascript is needed in order to register the template with a specific tag.

[1] https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...

How is this supposed to work?

With reactJS I know I can server render a component or template and I’ll say JSX makes a pretty good tempting language.

With web components as far as I understand there is no good templating language built in anyways (so you have to bring your own) I’m not aware of a standard mechanism in which I can take some chunk of JS for a component associated with a tag and have it render out HTML that does not require JS to run.

Author here. I cover this in another post [1], but basically the interop benefits you get on the client just aren't there (yet) on the server. My north star:

> Maybe in the future, when you can render 3 different web component frameworks on the server, and they compose together and hydrate nicely, then I’ll consider this solved.

[1]: https://nolanlawson.com/2023/08/23/use-web-components-for-wh...

Oh? So anyone writing applications, PWAs, healthcare software, responsive mobile web apps, or a billion other business domains where the web makes sense as a UI is doing a bad job?

Guess I've been doing a bad job for a long time now.

It's a herding cats problem. Not practical for new actors to propose one and have it adopted; current principals are no longer trusted. No one else with deep pockets cares enough to donate the resources it would take and/or do the hard coordination work. We don't see viable new Operating Systems either, for example.

That leaves minor feature additions as the only way forward.

There are probably many reasons. The history of technology development teaches us there are a lot of non-core factors that affect the adoption of alternative designs (influential entities and agendas, network effects, business models of those involved etc.)

But there seems to be also an interesting intrinsic reason: The versatility of the digital "Document" paradigm itself. Text in its digital incarnation (a sequence of human readable strings) is not just your usual text. While printed text on a page involves the encoding and annotation of human language sentences you can encode a lot more things in human readable HTML/SVG/XML formats (e.g. numerical data, visual geometries, declarative UI etc.).

The HTML family of documents is in this sense a sort of "super text". Its structure reflects already its huge dynamic (rich text) potential. But clearly you cannot solve everything in a declarative manner (though you should probably push it as far as possible). At some point the flexibility of code is important and the question then is what is the optimal way to do this (as in: easy, performant, versatile etc.). Alas at the moment we seem to be almost at the extreme opposite: everything as code.

Ideally one would refactor all these declarative formats that have proven their utility and resilience and rethink the role of code / frameworks, taking into account all the developments and learnings of the past decades (web assembly, mobile, pwa etc.).

> With every programming language, you can do

There are plenty of programming languages where you can't do that. If you really need that, can't you just register it as "my-thing-1" and then register the other one as "my-thing-2"?

I don't think we components were intended as a complete "framework" for writing web apps, but more for the rendering of reusable UI components.

So trying to do MVC with just web components feels a bit weird, at least to me. You'd need something extra I think

Stencil has a way better DX. Especially if you’re doing a whole library of components. You pay a slightly higher perf tax for their auto loader and light vdom. Lit is the way to go if you have opinions and want no magic

Thanks for sharing this view. I relate a lot.

There’s a pretty thorough post covering this here - https://infrequently.org/2022/03/cache-and-prizes/

So just more AI comment spam, huh? It's unfortunately ruining my favorite communities.

As someone who uses all of web components, react and Vue, depending on the project I really feel like to give such aggressive and opinionated takes you should consider doing it in a mature and professional way that goes into the "why" you feel like that.

What a weirdly aggressive comment. I could just as well say you should stop trying to (ab)use programming to make web pages and learn markup instead.

React is a comedy of errors and imho should not be held up as aspirational https://medium.com/@fulalas/web-crap-has-taken-control-71c45...

Honestly I would be fine if classes didn't exist. This means no methods, no "this". Namespaces, data structures and functions are enough to do everything.

I started to like React when we could write components with functions.

I disagree, I would prefer light web-components, rather that react.js + the compilers and state managers.

This make me into a bad programmer, I agree to disagree