Recent and related:
Web components will outlive JavaScript frameworks - https://news.ycombinator.com/item?id=38012662 - Oct 2023 (244 comments)
Web Components Eliminate JavaScript Framework Lock-In
221–230 of 300 posts
Re: Web Components Eliminate JavaScript Framework Lock-In
#222My hair always bristles a bit when I see plans to "eliminate JavaScript Framework Lock-in." For a backend service, it doesn't matter if you use no framework or one or five, other than pain for your developers having to learn the complexity; storage is so cheap it's nearly free, executable RAM slightly less so, and the end-user doesn't care how complex your server is. Frontend code gets pushed over a wire to your end-…
It isn't a standard HN post if it isn't claiming $new_technology will eliminate $old_technology.
Re: Web Components Eliminate JavaScript Framework Lock-In
#223Earlier quoted context omitted.
"Lots of people are still using it, but nobody can quite remember why." I can remember why. This, and every other article I've ever read arguing to replace React with Web Components, completely misunderstands the point of React. It isn't about JSX. It isn't about encapsulation. It isn't about reusability. It is about enabling a design pattern where *the user interface is a pure functional transformation of the applic…
I would say SolidJS does everything better than React while keeping with the same general mindset. React spent way too much time worrying about DX to the point that now DX is really bad. Fine grained granularity is such a breath of fresh air to work with after the very large and very heavy brush that is the React “render the world every time anything changes” method (yes they try to be smart about it, but so far have…
Thank you. Finally someone mentions Solid, it got all the good part of React, and none of the bloated parts.
Personally, JSX is the mainly thing that makes React attractive. As JSX is just modern E4X. It really ought to be put into the ES standard again instead of this Web Component stuff.
Another good JSX implementation (SSR) is: https://nanojsx.io
If you just want something light JSX, then this seems the way to go for now.
Re: Web Components Eliminate JavaScript Framework Lock-In
#224Earlier quoted context omitted.
Lit's features are internal to each component (except context which is being developed as an open community protocol with the Web Components Community Group) and there is no coupling between components written in Lit. So you can port from Lit to something else component-by-component. Lit is also modular. The template library, lit-html, is usable independently and used by other web component and non-web component libr…
This is just splitting hairs in an attempt to pretend that lit isn't a framework (or framework-like lib), or that it's somehow unopinionated, or that it somehow prevents you from lock-in. Almost all of the things you listed are specific to lit, and lit only. So, people who will develop with lit will be locked in to lit. Because it's not like you can just pop the code you wrote with lit into stencil or ionic, and will…
I mean they have to be for now - you're just being semantic for the sake of it a bit. I will say as a team that utilizes Lit for our design system web components (which none of our users even need to know or care about no matter their framework btw). The Lit team are huge advocates of aligning with native standards (now or what they might be in the future) and working to establish or push them forward. The goal of the project for a lot of these issues truly seems to be to eventually not need them to be a part of Lit at all.
Re: Web Components Eliminate JavaScript Framework Lock-In
#225I've found webcomponents to be really good at encapsulating anything that doesn't directly query application state. Specifically there are two type of components that really thrive as web components (as opposed to react): 1. Highly interactive components - Components that implement complex interaction management (but sort of agnostic to application state) are ideal web components. You don't need to mess around with `…
I find that they can work very well with state but since state is typically passed via attributes (downstream), it means that components can only share state with each other via strings. I found this to be an advantage, not a drawback because simple interfaces are at the core of my coding philosophy and strings make it infeasible to pass complex instances or functions to other components.
Well, this is only sort of true. When you’re writing HTML you’re restricted to attributes but custom elements are JavaScript objects and are free to respond to property updates on the object. Relying solely on strings is a limitation of your templating engine.
For example lit-html templates support syntax like:
Re: Web Components Eliminate JavaScript Framework Lock-In
#226The main problem with the Shadow DOM which makes people avoid it is the inability to use CSS externally to style the elements which are generated internally by the component... This is unfortunate because the Shadow DOM is essential if you want to work with child components slotted into it from the outside. This opens up many use cases. There is one alternative which is not being considered; it's possible for compone…
This is a great approach for components that want to inherit all styling from their context.
In cases where you want to introduce just a little styling, the CSS Parts API is really cool: https://developer.mozilla.org/en-US/docs/Web/CSS/::part
Re: Web Components Eliminate JavaScript Framework Lock-In
#227Earlier quoted context omitted.
I got the same itch. Here's my thing. https://mutraction.dev/
Interesting, thanks. Your mutation tracker isn't enough like "pure" RxJS Observables for my tastes and what I've been doing with my itch, but you captured a few of the things I'm covering in my system and are probably the next closest I've seen to what I've been doing (and I tried to research a deep dive). I think the only other thing is that I took an approach that observable change bindings look different from stat…
I was also influenced quite a bit by knockout. SSR was explicitly not a goal of mine. To me, SSR as a feature in a framework like this is mostly interesting in the context of server/client continuity like rehydration. But I have a feeling the constraints imposed by anything like this aren't going to be worth it. If I was doing pure server rendering, flat text templates seem like the sweet spot, since it's fundamentally not interactive. Render to html string and ship it. And if I was doing that, I probably would not choose to use javascript or observables/signals.
Re: Web Components Eliminate JavaScript Framework Lock-In
#228Earlier quoted context omitted.
Hard disagree, web won because of the deploy story. Users don't have to install anything. Html and css is a terrible API for app layout, because it wasn't designed for that
> Html and css is a terrible API for app layout, because it wasn't designed for that And yet it's so easy and forgiving that millions of 13 year olds learned it for their myspace and tumblr pages over the last 15 or so years. Somehow, despite all the CS graduates and 20 year software engineering veterans bemoaning it, more and more people learn HTML, CSS, and Javascript every day while the number of people learning n…
Those aren't apps, they're closer to documents, which is what it was designed for.
Re: Web Components Eliminate JavaScript Framework Lock-In
#229As far as I can see, web components take only strings as arguments. That alone disqualifies them from being a serious component framework. I've looked at them only for a short time last month, because I was excited about a web native component framework, but they provide basically nothing I would expect from such a framework. They are not even in the same arena as React.
Strings as _attributes_, yes. But that's par for the course when it comes to html (boolean attributes aside). However, anything can be passed as a _property_. React operates on properties by default (hence `htmlFor` and `className`, not `for` and `class`). In fact, react's upcoming improved WC support will first do an `in` check on a property name before falling back to attribute. This is similar in vue etc. So yes i…
I see, interesting. That's certainly helpful. Still, I don't see what problem web components solve. New custom html tags? Nice, but useless. And if I have to use a framework or WC lib on top of web components... Well. Nothing gained, it is just switching one framework for another. I am not against that at all, in fact I am writing my own framework for specific reasons. But let's not pretend that web components are a solution to anything, or that there are specific reasons why it needs to exist.
Re: Web Components Eliminate JavaScript Framework Lock-In
#230Earlier quoted context omitted.
Why would it be different? The concept of Models is the same whether it is client-side or server-side. These are objects that encapsulate business logic. The concept of Views is also the same. These are responsible for rendering the screen. The concept of controllers? That too is the same. Controllers determine application flow from one screen to the next.
The server is typically not a retained-mode kind of abstraction. Incremental view maintenance in retained-mode MVC systems is the main source of bugs. If you render the view from scratch on every request, it's more similar to React style immediate-mode UI than something like UIKit where you end up handling many UI events and keeping little bits of the UI up-to-date with model changes incrementally.
You can render the view from scratch on every user interaction, even in MVC. In fact, you can use React for that purpose. "Lots of people use React as the V in MVC." See that quote on this page: https://github.com/facebook/react/tree/015833e5942ce55cf31ae...
Personally, I have not run into large amounts of bugs of this type, and I have written plenty of MVC code using VanillaJS.