Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web Components Eliminate JavaScript Framework Lock-In

jakelazaroff.com

Post reply on HN
Print view View original

271–280 of 300 posts

Re: Web Components Eliminate JavaScript Framework Lock-In

#271

Post by gitaarik »

djrenren wrote: post #143

Please remember that Web Components are much more akin to an ABI for web projects and not a full-featured framework. Any web component easily plugs into React, svelte, lit, etc. Existing components written in those frameworks can pretty easily be wrapped in a web component. It's a common base-layer we can all use. If you attempt to build a web app using just web components and no libraries, you'll quickly find that y…

That is why we have a library to make it easier to work with these low level functions: Lit. And because Lit uses these functions, it can be a lot more lightweight compared to React & Angular etc.

Re: Web Components Eliminate JavaScript Framework Lock-In

#272

Post by gitaarik »

davetron5000 wrote: post #70

Web Components are not a replacement for React. They are a thing you would use to build React if you were to do so today. To use only Web Components, you will be writing a lot of low-level code using the browser's API, or you will have to use a framework built on Web Components

For me it's a perfect replacement for React. I've been using it for years, and I'm much more happy about it than React. And I was already very happy with React compared to before that. I think it's the logical next step, but you need to unlearn some React concepts and relearn some Web Component concepts before you are really comfortable with it. But when you know how to work with it it's really super nice, and you'll appreciate better understanding the powerful browser and DOM APIs.

Re: Web Components Eliminate JavaScript Framework Lock-In

#273

Post by troupo »

gitaarik wrote: post #269
troupo wrote: post #174

Earlier quoted context omitted.

> Can you elaborate further ? As you read the following, keep in mind that at this time Web Components have been in development for almost 12 years. The core is just three standards, CustomElements, Shadow DOM and HTML Imports (already deprecated and removed in favor of JS-only imports). And people will go out of hteir way to sell you the idea that this is lightweight, all that you need etc. However . They've already…

I think you are trying to impose a React workflow on Web Components. Some things that work in React indeed don't work in Web Components / Lit, but that is usually for good reasons. There are a lot of quirks with React too, for example I find it very cumbersome the way you reference elements in React. That's a lot nicer with Lit. But in Lit, input fields can't communicate to a form in a different Shadow DOM. In React…

Literally none of the issues I listed have to anything with React.

> But in Lit, input fields can't communicate to a form in a different Shadow DOM

Indeed. They break the most basic functionality that exists in the browser. This issue doesn't exist in anything else. And they need a separate new web spec to barely fix it.

Does it have to do anything with React? No.

> That's logical of course because Lit is made to work with modern Web Component APIs

Yup, so modern that they creak basic browser functionality and need 20+ new web specs to fix issues that don't exist in literally anything else.

Re: Web Components Eliminate JavaScript Framework Lock-In

#274

Post by troupo »

meiraleal wrote: post #263
troupo wrote: post #249

Earlier quoted context omitted.

> Do Angular and React components talk to each other? You can make them talk to each other. Depends on what exactly you need, how components and projects are structured etc. > Lit and other Web component frameworks can share components. To refactor Lit components into other web component framework or raw web component is orders of magnitude easier than converting Angular React. You're putting a false equivalency betw…

> You can make them talk to each other. you can make almost whatever you want with code but they weren't build for that. Besides that, both angular and react are bloated software, adding another layer to create web components version of their components is just more bloat. It took some time for chariots to be considered a legacy way of transport but you can't fight its obsolescence just by saying that chariots will a…

All that is beside the point.

Re: Web Components Eliminate JavaScript Framework Lock-In

#275

Post by troupo »

gitaarik wrote: post #265
troupo wrote: post #166

Earlier quoted context omitted.

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…

What a vendor lock-in basically means is that your integration with the vendor is so specific, that it's very hard to transfer to another vendor. Lit is basically a library that makes use of the native Web Components APIs in modern browsers. If someone else would make a similar library, it would most probably have similar functionality. So I don't really see the issue with vendor lock-in here. Most logic regarding yo…

> your integration with the vendor is so specific, that it's very hard to transfer to another vendor.

Indeed.

> Lit is basically a library that makes use of the native Web Components APIs in modern browsers. If someone else would make a similar library, it would most probably have similar functionality.

Maybe, similar, perhaps.

The meat of the matter is this. There are a lot of things in lit that are specific just to lit. They have nothig to do with web components. Custom DSL. Tasks. Reactivity. etc. etc.

So yes, when you're buying in to lit, you're locking yourself to lit, and the way lit does things.

For example, Stencil, another popular web component library, is completely different from lit: it uses a different templating mechanism, a different data binding mechanism etc. etc.

> So Lit basically just gives you easy access to powerful browser APIs

No, it doesn't give access to those APIs. It goes out of its way to hide those APIs and provide a different, ore ergonomic API on top.

Re: Web Components Eliminate JavaScript Framework Lock-In

#276

Post by troupo »

gitaarik wrote: post #262
troupo wrote: post #251

Earlier quoted context omitted.

> It's used for many Google projects like Chrome, parts of YouTube... so I think it's unlikely, When Custom Components v0 was barely released Google re-wrote Youtube with Polymer. Where's Polymer now? > You should be able to migrate away from Lit very easily And that should comes from which part of lit? Custom DSL? Custom decorators? Custom data bindings? Custom tasks? As I wrote elsewhere, Preact, Svelte, Vue, and A…

I never used Polymer but as far as I understand it was always an experimental project for the then very young technology of Web Components. And it was a rather opinionated framework also. Lit is just a very lightweight layer on top of the now matured Web Component API. And you are not really dependend on a strong community releasing occational security updates and new features and bugfixes, because it's very small an…

> as far as I understand it was always an experimental project for the then very young technology of Web Components

So experimental that Google even had a Polymer Conference and was promoting it heavily, like it promotes lit now.

> because Lit doesn't want to be a opinionated framework

For a "non-opinionated" framework it sure does have a lot of opinions: custom DSL, custom directives, custom decorators, custom way of building elements...

Re: Web Components Eliminate JavaScript Framework Lock-In

#277

Post by gitaarik »

troupo wrote: post #273
gitaarik wrote: post #269

Earlier quoted context omitted.

I think you are trying to impose a React workflow on Web Components. Some things that work in React indeed don't work in Web Components / Lit, but that is usually for good reasons. There are a lot of quirks with React too, for example I find it very cumbersome the way you reference elements in React. That's a lot nicer with Lit. But in Lit, input fields can't communicate to a form in a different Shadow DOM. In React…

Literally none of the issues I listed have to anything with React. > But in Lit, input fields can't communicate to a form in a different Shadow DOM Indeed. They break the most basic functionality that exists in the browser. This issue doesn't exist in anything else. And they need a separate new web spec to barely fix it. Does it have to do anything with React? No. > That's logical of course because Lit is made to wor…

They don't break semantics, input fields work just fine within a single Shadow DOM. You have to understand that a different library has a different workflow. If you addopt the correct workflow, you won't have any of the issues you're having. But it takes some time to learn something new.

Re: Web Components Eliminate JavaScript Framework Lock-In

#278

Post by octagon2023 »

meiraleal wrote: post #175
dbingham wrote: post #6

One of the linked articles [1] makes an interesting claim that feels like a reach to me, but I'd be interested in hearing HN's take on it: > At this point React is legacy technology, like Angular. Lots of people are still using it, but nobody can quite remember why. The decision-makers in organisations who chose to build everything with React have long since left. People starting new projects who still decide to buil…

Yes, I agree with him. What's the reason to use React? It is over-engineered and too complicated for no clear benefit. It takes longer to build an app using react just because you have to deal with things that are exclusive to react

Try next.js. We have seen massive improvements in code quality and development velocity using v13/14. Our codebase is a mix of typical server rendered crud web and client only logic (web3). It feels like php without the bad parts. In particular react actions proved to be a major quality of life improvement.

Re: Web Components Eliminate JavaScript Framework Lock-In

#279

Post by troupo »

gitaarik wrote: post #277
troupo wrote: post #273

Earlier quoted context omitted.

Literally none of the issues I listed have to anything with React. > But in Lit, input fields can't communicate to a form in a different Shadow DOM Indeed. They break the most basic functionality that exists in the browser. This issue doesn't exist in anything else. And they need a separate new web spec to barely fix it. Does it have to do anything with React? No. > That's logical of course because Lit is made to wor…

They don't break semantics, input fields work just fine within a single Shadow DOM. You have to understand that a different library has a different workflow. If you addopt the correct workflow, you won't have any of the issues you're having. But it takes some time to learn something new.

> They don't break semantics, input fields work just fine within a single Shadow DOM.

Yes, yes they do break semantics.

1. If you just put the input in a web component, it will not appear in the form. You have to manually add it. https://web.dev/articles/more-capable-form-controls

2. If you have an input in Shadow DOM, it cannot be referenced with a label from outside that shadow DOM. That breaks ARIA, and will be fixed god knows when with a new cross-root ARIA spec.

This has nothing to do with libraries, or React, or whatever you imagine. These are basic browser behaviours that everyone expects to work out of the box, and they are broken.

> that a different library has a different workflow.

This has nothing to do with libraries. This is basic browser functionality.

> If you addopt the correct workflow, you won't have any of the issues you're having.

No "correct workflow" can cover the fact that these behaviours are broken, and need 20+ new specifications to fix.

There's no correct workflow that will make cross-shadow ARIA work. There's no correct workflow that will make a custom component participate in forms if the author didn't add that functionality. There's no correct workflow that will make your custom button be able to work as a submit button. And so on, and so on, and so on, and so on.

Edit. Note: if you took the time to actually read the report from people who shove webcomponents into the browser, you will see that even they admit how much of an issue all this is, and it has nothing to do with React or libraries, and everything to do with self-inflicted wounds by a badly thought-out design: https://w3c.github.io/webcomponents-cg/2022.html (emphasis mine).

Note how none of these are issues for anything built for the browser. These are issues only for the half-baked, badly-designed web components.

--- start quote ---

This document tries to highlight the main features that are lacking from the web components spec that either block adoption for more developers and frameworks, or cause pain points for existing developers.

It's worth noting that many of these pain points are directly related to Shadow DOM's encapsulation. While there are many benefits to some types of widely shared components to strong encapsulation, the friction of strong encapsulation has prevented most developers from adopting Shadow DOM.

...

Shadow boundaries prevent content on either side of the boundary from referencing each other via ID references. ID references being the basis of the majority of the accessibility patterns outlines by aria attributes, this causes a major issue in developing accessible content with shadow DOM.

...

The form-associated APIs currently have no way for a developer to behave as a custom submit button.

It is currently unclear how form-associated custom elements should participate in the autocomplete lifecycle despite there being an API for that purpose.

...

Many web components could be implemented without JavaScript, taking advantage of encapsulated DOM and styles. However, web components cannot currently be rendered by users who have JavaScript disabled.

... ad infinitum ...

--- end quote ---

Re: Web Components Eliminate JavaScript Framework Lock-In

#280

Post by gitaarik »

troupo wrote: post #275
gitaarik wrote: post #265

Earlier quoted context omitted.

What a vendor lock-in basically means is that your integration with the vendor is so specific, that it's very hard to transfer to another vendor. Lit is basically a library that makes use of the native Web Components APIs in modern browsers. If someone else would make a similar library, it would most probably have similar functionality. So I don't really see the issue with vendor lock-in here. Most logic regarding yo…

> your integration with the vendor is so specific, that it's very hard to transfer to another vendor. Indeed. > Lit is basically a library that makes use of the native Web Components APIs in modern browsers. If someone else would make a similar library, it would most probably have similar functionality. Maybe, similar, perhaps. The meat of the matter is this. There are a lot of things in lit that are specific just to…

Well, if Stencil is a Web Component framework using native Web Component technologies and strategies, transferring from Lit to Stencil will probably be a lot easier than from React to Angular or something.

And there are actually not that many things specific to Lit, and it's only things that would need to be solved in some kind of (opinionated) way anyway. But I think Lit does it in an elegant, intuitive and flexible way. You might like it or you might not.

I don't know Stencil, but looks nice. But their main npm package [0] is 47.8 MB, whereas Lit [1] is only 105 KB. So I would say that there are a lot more things specific in Stencil then there are in Lit. Which would probably make it harder to move from Stencil to Lit, than it is to move from Lit to Stencil.

[0]: https://www.npmjs.com/package/@stencil/core

[1]: https://www.npmjs.com/package/lit

Post reply on HN