Web Components Eliminate JavaScript Framework Lock-In • Hacker News Board

Re: Web Components Eliminate JavaScript Framework Lock-In

#251

Post by troupo » Tue, Nov 28, 2023, 5:00 AM UTC

spankalee wrote: post #53

veeti wrote: post #30

Earlier quoted context omitted.

How do we know this won't be killed off by Google in six months?

Honestly, you don't. It's used for many Google projects like Chrome, parts of YouTube, Maps APIs, Collab, the Google Store, and a ton of internal things, so I think it's unlikely, but I understand Google's reputation. This is one reason why we care so much about low coupling and lock-in, and a small, easy-to-understand codebase. You should be able to migrate away from Lit very easily, and fork or maintain it if neces…

> 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 Angular can all be compiled to web components. How easy do you think it would be to convert app code between each of these frameworks? Convert that code to and from lit?

Re: Web Components Eliminate JavaScript Framework Lock-In

#252

Post by aitchnyu » Tue, Nov 28, 2023, 5:01 AM UTC

socketcluster wrote: post #220

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

Is there a comparison between light and shadow dom for webcomponents? I kinda want the simplicity of applying light dom css. Svelte doesnt support slots in light dom, I want to know the other caveats of light dom.

Re: Web Components Eliminate JavaScript Framework Lock-In

#253

Post by switchbak » Tue, Nov 28, 2023, 5:33 AM UTC

brlewis wrote: post #150

switchbak wrote: post #69

I haven't been in the frontend world for many years now, but I come from the mid-90's world of GUI development / game engines / old school desktop stuff. I look at this stuff, and just think how sad it is that we haven't progressed beyond the state of gluing together freakin low level divs and spans within some JS code with callbacks galore. For some reason I thought we'd have made it beyond that by 2023, and we coul…

From the article, This is talking declaratively at a high level about the kind of interface to render. Lots of component frameworks look like this example. Thinking "how sad it is that we haven't progressed beyond the state of gluing together low level divs and spans" sounds like a preconceived idea rather than a response to this article. By the way, I come from mid-80's BASIC on 8-bit home computers. You get off my…

You can make the calling interface look like that (that’s definitely good), but the implementations in the example were still very document centric inline html. It all just seems like it’s a lot more low level work than it ought to be. I feel much the same way when using a (bad) orm: there’s just a vague feeling that the solution isn’t quite an appropriate fit to the problem. Maybe this gets better when you’re composing from a library of core components, I don’t know. Again, I’m very much an outsider here.

I’m not saying that old GUI component frameworks are vastly superior either. I just imagined that we’d have progressed well past the kind of approach the article is mentioning.

It’s a side rant, but I don’t think it’s entirely without merit.

Re: Web Components Eliminate JavaScript Framework Lock-In

#254

Post by TheHiddenSun » Tue, Nov 28, 2023, 8:03 AM UTC

menssen wrote: post #39

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…

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

Solid.js comes to mind

- not a framework, but a library

- can do fine gained state updates without unnecessary re-renderings (reactivity)

- uses dom instead of vdom to produce best in class SPA performance

- uses jsx like react

Performance claim / proof: https://krausest.github.io/js-framework-benchmark/

Re: Web Components Eliminate JavaScript Framework Lock-In

#255

Post by gitaarik » Tue, Nov 28, 2023, 9:30 AM UTC

menssen wrote: post #39

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…

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

The reason React uses a virtual DOM is because when React started, there were no (advanced) HTML templates yet. And it made it easy to setup listeners on elements, instead of manually adding it with `addEventListener()` and possibly remove them again with `removeEventListener()`. So the virtual DOM was really a game changer.

But Lit templates solve these problems in a more browser integrated way, without the need of a virtual DOM. How you manage the state is free to your choice, that is also not something exclusive to React and your favorite pattern can also be used with Lit. I wrote a tiny state management library (LitState [0]) which makes it very easy for multiple components to share the same state and stay in sync. I personally find it much more convenient and cleaner than any other state library I've used before. And it integrates very nicely with Lit.

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

Re: Web Components Eliminate JavaScript Framework Lock-In

#256

Post by gitaarik » Tue, Nov 28, 2023, 9:40 AM UTC

vitaflo wrote: post #74

wayfinder wrote: post #14

Earlier quoted context omitted.

As someone who does remember why because they've been building sites since the 90s, it's because the React team created a preprocessor (JSX) to let you embed HTML tags in JavaScript. This fixed the problem that other languages like Java, Python, etc. don't have because those languages has assemblies/packages so they can put HTML templates in separate files and load them in your app. There is zero standard way to do t…

100% agree. Like you I’ve been building sites since the mid 90s and always was pulling my hair out at all the convoluted ways we would attempt to handle HTML in these JS frameworks. As someone who knows HTML and CSS and vanilla JS, as soon as I saw React all I could think of when I saw JSX was “finally!”. Yeah it’s another framework with its own quirks but it lets me think about the UI in the same way I’ve thought ab…

Then you would love Lit [0]. It is like JSX, but then using more native html template technologies.

[0]: https://lit.dev/

Re: Web Components Eliminate JavaScript Framework Lock-In

#257

Post by pests » Tue, Nov 28, 2023, 9:40 AM UTC

menssen wrote: post #39

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…

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

useEffect is overused. People use it to compute derived values when that is not its intended use.

How many times have you seen the equivelent to a fullname = firstName + lastName inside a useEffect? Its outstanding. :(

Re: Web Components Eliminate JavaScript Framework Lock-In

#258

Post by zelphirkalt » Tue, Nov 28, 2023, 11:58 AM UTC

tubthumper8 wrote: post #182

zelphirkalt wrote: post #34

Earlier quoted context omitted.

Interesting. Yet I find that React HTML—that is not actually HTML, but a look-alike, a dialect if you want—to be exactly what I dislike about React. That is because it still encourages people to put JS in their HTML in their JS in their ... And we are almost back to crazy PHP land of "I treat HTML as a string and blend everything together into one big lump.", instead of using a templating engine, that treats HTML in…

> 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 a usual templating engine valid HTML is also valid template. One does not have to use templating engine specific things. A HTML snippet can simply be HTML. No harm done. But in JSX one cannot use normal HTML, as shown by the `class` case.

Re: Web Components Eliminate JavaScript Framework Lock-In

#259

Post by zelphirkalt » Tue, Nov 28, 2023, 12:00 PM UTC

nightski wrote: post #77

zelphirkalt wrote: post #34

Earlier quoted context omitted.

Interesting. Yet I find that React HTML—that is not actually HTML, but a look-alike, a dialect if you want—to be exactly what I dislike about React. That is because it still encourages people to put JS in their HTML in their JS in their ... And we are almost back to crazy PHP land of "I treat HTML as a string and blend everything together into one big lump.", instead of using a templating engine, that treats HTML in…

Except it's not half baked. Because guess what - now you need a new template language that supports constructs like conditionals, loops, etc... You basically end up implementing a half-baked version of javascript with an unfamiliar syntax. Even worse they need to interact with state. Many template engines introduce some sort of "data binding" abomination which is a complex way of saying how you want the state to inte…

> React is simple. Here is your data, and here is a function that transforms that data into a view.

Is that aspect so much different from templating engines? In templating engines the rendering step is simply abstracted one step further: You get a generalized render function, that you pass data to and a template to render with that data. That is also a function to turn your data into a view. I don't see how React is better in that aspect.

Re: Web Components Eliminate JavaScript Framework Lock-In

#260

Post by earthboundkid » Tue, Nov 28, 2023, 12:10 PM UTC

jakelazaroff wrote: post #246

earthboundkid wrote: post #245

Earlier quoted context omitted.

You could use srcdoc="..." to simulate a component, except that iframes don't have automatic height adjustment, which is the thing they should actually fix. In any event, shadow DOM is just a worse version of scope selectors. There's not really a good use for it now that you can just do a style reset on a donut selector inside an import layer. It can all be done declaratively with CSS instead of using an imperative J…

There are a lot of things you can do with shadow DOM that you can’t with iframes or scope/donut selectors: - transclude other elements (technically you can with iframes, but hopefully it’s clear why making something like this breadcrumb component would be extremely awkward [1]) - control and react to the display of child elements via s - call methods on custom element objects etc etc. It’s fine if it doesn’t solve an…

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.