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

281–290 of 300 posts

Re: Web Components Eliminate JavaScript Framework Lock-In

#281

Post by gitaarik »

troupo wrote: post #279
gitaarik wrote: post #277

Earlier quoted context omitted.

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 fi…

I will read those links you referenced later. But what I think about the Shadow DOM is that that is for me actually the killer feature. That prevents a lot of weird issues. But it also brings limitations to methods of how web developers are used to do things, like applying styles globally, or having some sort of dependency between deeply nested elements, crossing the Shadow DOM when using Web Components.

What people usually try to do is to somehow open up the Shadow DOM for certain things, to make some things allowed to pass, or global. But I think might be a bit holding on to an old familiar habit. And I think there are better ways of structuring a project with Web Component in mind.

For example, you can create a base class from which all your components extend, and put the base style in that base class, and have your components add style on top of that. I implemented this method in a tiny library which makes it easy to use [0].

But yeah it is hard for most developers to adopt a new way of thinking. And as long as the new way doesn't provide that much improvement over the old way, it won't get adopted. But I think the idea of Web Components still needs to be integrated more in the web dev community. And maybe they will manage to make some changes to make the adoption easier.

And besides that, of course Web Components still have lots of other issues. But for me it has reached a point where I don't feel the need for React anymore. I rather live with some quirks in Lit than doing things with React, which just feels clumsy to me now.

[0]: https://github.com/gitaarik/lit-style

Re: Web Components Eliminate JavaScript Framework Lock-In

#282

Post by gitaarik »

troupo wrote: post #276
gitaarik wrote: post #262

Earlier quoted context omitted.

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 o…

Well, any popular framework has all these things, and most frameworks have a lot more. Lit is really the littlest amount of tools you would want. With less than that, you can just as well directly use the web component APIs, and not use a framework / library at all. I don't know what you imagine would be a less opinionated way without having to chip in on usability.

Re: Web Components Eliminate JavaScript Framework Lock-In

#283

Post by earthboundkid »

jakelazaroff wrote: post #264
earthboundkid wrote: post #260

Earlier quoted context omitted.

Transclusion can totally be done with CSS now. That’s a donut selector. The other things are just plain old JavaScript and have nothing to do with Shadow DOM. Yes, they can be done with customElement, but they can also just be done without it.

I think I’m going to bow out because it’s clear this discussion isn’t going anywhere, but you should look up what transclusion means because it makes no sense to say that you can do it in CSS.

Transclusion means that .a in this can escape the Shadow DOM: Transcluded content

To do the same thing in CSS you would do Transcluded content @scope (.myelement) to (.slot) { /* rules that apply to .myelement but not .a */ }).

Re: Web Components Eliminate JavaScript Framework Lock-In

#284

Post by troupo »

gitaarik wrote: post #280
troupo wrote: post #275

Earlier quoted context omitted.

> 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…

> 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.

Literally everything that's on the web is using "native technologies and strategies". Because there's nothing else.

So, extraordinary claims require extraordinary proofs. I eagerly await a description, with examples, of how much work there is to convert a non-trivial lit component to Stencil.

Why non-trivial? Because trivial components are easy to convert from anything to anything. You could convert a trivial React component into knockout.js, then to Angular, and then to Lit, and back, in under half a day even if you've never worked with those technologies before.

> And there are actually not that many things specific to Lit

I've listed a few of them. They are opinionated enough that lit code and stencil code are completely different and incompatible.

Besides, there are a dozen or so libraries and frameworks that can, or do, compile to web components. Their code is also different from lit's.

> But their main npm package [0] is 47.8 MB

This is completely beside the point. We're not discussing Stencil, or the opinions its authors may or may not have taken.

Re: Web Components Eliminate JavaScript Framework Lock-In

#285

Post by troupo »

gitaarik wrote: post #281
troupo wrote: post #279

Earlier quoted context omitted.

> 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 fi…

I will read those links you referenced later. But what I think about the Shadow DOM is that that is for me actually the killer feature. That prevents a lot of weird issues. But it also brings limitations to methods of how web developers are used to do things, like applying styles globally, or having some sort of dependency between deeply nested elements, crossing the Shadow DOM when using Web Components. What people…

> But yeah it is hard for most developers to adopt a new way of thinking.

It's not "a new way of thinking". Things like functioning inputs, buttons, and ARIA are basic browser functionality.

> And as long as the new way doesn't provide that much improvement over the old way, it won't get adopted.

Not only it doesn't provide improvment, it needs 20+ new web standards to fix the issues that literally nothing else has. I've gone ahead and quoted directly from the report made by people who keep developing these specs.

And yet you've ignored literally everything I wrote and keep answering something entirely else.

> of course Web Components still have lots of other issues.

Indeed, they do. I listed a bunch of them. And yet you keep pretending that I'm talking about "React workflows" or something.

This is pointless until your read what I write, and not what you think that I write. Until then, adieu.

Re: Web Components Eliminate JavaScript Framework Lock-In

#286

Post by troupo »

gitaarik wrote: post #282
troupo wrote: post #276

Earlier quoted context omitted.

> 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 o…

Well, any popular framework has all these things, and most frameworks have a lot more. Lit is really the littlest amount of tools you would want. With less than that, you can just as well directly use the web component APIs, and not use a framework / library at all. I don't know what you imagine would be a less opinionated way without having to chip in on usability.

> Lit is really the littlest amount of tools you would want.

- reactivity. Specific to lit

- declarative templates. Specific to lit

- SSR. Specific to lit.

- context. Specific to lit.

- tasks. Specific to lit

- directives. Specific to lit

"littlest amount of tools"

Re: Web Components Eliminate JavaScript Framework Lock-In

#287

Post by tubthumper8 »

zelphirkalt wrote: post #258
tubthumper8 wrote: post #182

Earlier quoted context omitted.

> Also there are issues with that custom HTML-look-alike preprocessor, because you cannot write class="...", because then somehow it gets syntactically confused, because "class" is now a keyword in JS. > This all feels rather half-baked. Why can't the parser/prprocessor distinguish between that "class" and "class" in JS source code? Remember that React is "just JavaScript", JSX is a syntax transformation of JavaScrip…

However, that means, that now one has something, that is neither looking like HTML, nor is it looking like JS, even if it may be JS through some pre-processing (but then actually it is not really JS?). The result is, that one has to learn some different syntax that is specific to React. If there is already a preprocessing step, why not preprocess `class` instead of `className`, to get closer to normal HTML syntax? In…

I think you're hung up on JSX being HTML - it isn't HTML and doesn't try to be. The "JS" stands for "JavaScript" and the "X" stands for XML, not HTML.

> However, that means, that now one has something, that is neither looking like HTML, nor is it looking like JS, even if it may be JS through some pre-processing (but then actually it is not really JS?).

Yes, it's not HTML or JS, it is JSX. It's an XML-based syntax to declaratively write JavaScript. It's optional too - one can write the function calls directly in JS, and indeed that's what people did before JSX existed. `React.createElement("div", React.creatElement("span"),...)`. It could be worth using a REPL [1] to gain an intuition of the JavaScript that is produced from transforming different JSX examples.

> The result is, that one has to learn some different syntax that is specific to React.

JSX was originally created for React, but now is not specific to React, other libraries and frameworks use it as well. It's a general purpose XML-based syntax for writing JavaScript declaratively.

And yeah, if you want to use JSX you have to learn it. It's easy to learn if you know JavaScript and XML and shouldn't take very long. It's XML and then anything inside curly braces is a JavaScript expression.

If you're using TypeScript replace everything "JS" I'm saying with "TS", it's the same result. And obviously type checking works without issue because it's a syntactic transformation to TS, not a semantic transformation.

> In a usual templating engine valid HTML is also valid template. One does not have to use templating engine specific things.

JSX is not an HTML templating engine [2]. JSX is a way to write JavaScript declaratively using an XML-based syntax.

> But in JSX one cannot use normal HTML, as shown by the `class` case.

Yes, as expected. JSX is not an HTML templating engine, it's a way to write JavaScript declaratively using an XML-based syntax. In JavaScript, you use the DOM APIs [3], not HTML attributes [4].

[1]: https://babeljs.io/repl

[2]: https://legacy.reactjs.org/docs/introducing-jsx.html

[3]: https://developer.mozilla.org/en-US/docs/Web/API/Document_Ob...

[4]: https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes

Re: Web Components Eliminate JavaScript Framework Lock-In

#288

Post by gitaarik »

troupo wrote: post #285
gitaarik wrote: post #281

Earlier quoted context omitted.

I will read those links you referenced later. But what I think about the Shadow DOM is that that is for me actually the killer feature. That prevents a lot of weird issues. But it also brings limitations to methods of how web developers are used to do things, like applying styles globally, or having some sort of dependency between deeply nested elements, crossing the Shadow DOM when using Web Components. What people…

> But yeah it is hard for most developers to adopt a new way of thinking. It's not "a new way of thinking". Things like functioning inputs, buttons, and ARIA are basic browser functionality . > And as long as the new way doesn't provide that much improvement over the old way, it won't get adopted. Not only it doesn't provide improvment, it needs 20+ new web standards to fix the issues that literally nothing else has.…

Any technology has issues and limitations. Many basic browser functionalties also don't work with the React workflow, and Lit brings those things back again, making it more native, and less need for framework code.

It seems you are only focussing and zooming in on the issues and limitations. And there are issues and limitations in any technology. I think it has to do with adopting a different way of thinking and structuring. All those issues you listed are either non-issues with the correct workflow, or are easy to work around.

And hey, I'm not saying you or anyone should use web components; if you like React better then just keep using that. But I don't see why you would critizice this technology so much. Remember that creating new web specs and standards takes a lot more time than to build an independent framework like React. So yeah the development and adoption is slow, and that might frustrate you. And as long as you think it's not good enough yet, you can just keep using React. But I personally find that it is mature enough for me to use it in combination with Lit instead of React. And I'm very satisfied about it. It does take some investment to learn a bit about how Web Components work.

Re: Web Components Eliminate JavaScript Framework Lock-In

#289

Post by gitaarik »

troupo wrote: post #284
gitaarik wrote: post #280

Earlier quoted context omitted.

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…

> 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. Literally everything that's on the web is using "native technologies and strategies". Because there's nothing else. So, extraordinary claims require extraordinary proofs. I eagerly await a description, with examp…

Sorry but I think it is quite obvious that a large framework will create much more lock-in and dependency than a tiny library. The more specific stuff you use, the more you are locked in. And yeah Lit still does some things for you so there's always some lock-in, with any library that you use. So it's not about simply whether it is a lock-in or not, but the amount of lock-in.

Lit doesn't need JSX and a virtual DOM, which are React specific technologies. You have to design your React components with these technologies in mind. With Lit there are much less dependencies like that, so your code will be less designed for a specific framework, making it easier to move to another framework that doesn't impose a specific workflow.

Re: Web Components Eliminate JavaScript Framework Lock-In

#290

Post by gitaarik »

troupo wrote: post #286
gitaarik wrote: post #282

Earlier quoted context omitted.

Well, any popular framework has all these things, and most frameworks have a lot more. Lit is really the littlest amount of tools you would want. With less than that, you can just as well directly use the web component APIs, and not use a framework / library at all. I don't know what you imagine would be a less opinionated way without having to chip in on usability.

> Lit is really the littlest amount of tools you would want. - reactivity. Specific to lit - declarative templates. Specific to lit - SSR. Specific to lit. - context. Specific to lit. - tasks. Specific to lit - directives. Specific to lit "littlest amount of tools"

SSR, context and tasks are all separate packages, not in the Lit core package. The others are very basic functionalily for what you expect from a framework like Lit. It has to do something ultimately :D
Post reply on HN