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

41–50 of 300 posts

Re: Web Components Eliminate JavaScript Framework Lock-In

#41

Post by djrenren »

troupo wrote: post #26
djrenren wrote: post #20

I'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 `…

> You don't need to mess around with `useEffect` or `useMemo`. You get really tight control of rendering and state updates. You don't need those in React either. Whatever you do in Web Components can probably (most likely) be done in React. After all, Web Components are a solidified 2010-era design. The reason React has hooks now because people have moved on, and are exploring other ways of building stuff. The only m…

> You don't need those in React either.

I mean... sometimes you do, that's why they exist. But yeah, most of the time you don't.

> Whatever you do in Web Components can probably (most likely) be done in React.

Of course! React is a good and powerful framework. But everything you do in React can be done in Angular 1.0 or even backbone.js. As always with frameworks it's about the productivity / performance ratio for your team (or for libraries, the ratio for your consumers).

> After all, Web Components are a solidified 2010-era design.

A lot of the web components related APIs are being actively developed including constructable stylesheets, shadow DOM APIs and more. Regardless, the era of design is not a great point in either the "pro" or "con" column, and is usually an ambiguous shorthand for the actual quality being critiqued.

Re: Web Components Eliminate JavaScript Framework Lock-In

#42

Post by JamesSwift »

robin_reala wrote: post #31
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…

React “won” because Facebook spent three years flying devrel to every web conference on earth to persuade other people that Facebook’s problem space was applicable to small agencies. Back in reality, React is slow and massively overbuilt for the majority of stuff that most people are building. If you played around with Web Components a long time ago then you probably played with the v0 spec, which was somewhat differ…

React "won" I think because it trojan horsed itself as being "just the view" but then morphed into a hand-rolled kitchen-sink solution, and inertia kept people around.

Re: Web Components Eliminate JavaScript Framework Lock-In

#43

Post by preommr »

Web components are a half-baked solution. It only becomes useful with another framework (even if it's very lightweight) like lit. At which point I might as well use vue/react/svelte since I am already brining in a library. Tech like preact is really lightweight as well, and given the popularity of react, is enough to offset any benefits web components have.

I would really like it if we reached a point where a web project only had a single dependency that's a bundler like vite that you point to an index file, and that's it.

Re: Web Components Eliminate JavaScript Framework Lock-In

#44

Post by breadwinner »

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…

> It is about enabling a design pattern where the user interface is a pure functional transformation of the application state.

This is only true for read-only components.

There is no "pure functional" when you introduce state and interactivity. See here: https://mckoder.medium.com/why-react-is-not-functional-b1ed1...

Re: Web Components Eliminate JavaScript Framework Lock-In

#45

Post by mustaflex »

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…

Web components are a bit verbose by themselves but used with a library like lit.js you can build a framework agnostic component library. Angular and Vue support WC out of the box and they have a wrapper for React. I think the only thing missing(or not mature enough right) now is SSR. There are probably libraries other than lit.js that take the pain out of writing WC.

I was skeptical at first but I've seen in production a lit.js/WC component library used with React and Angular successfully in the banking sector and it works surprisingly well.

Re: Web Components Eliminate JavaScript Framework Lock-In

#46

Post by tyingq »

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…

Fair, though you can find plenty of stuff on the internet using React, but where the app/page itself performs abysmally. Meaning maybe there is some merit in approaches that are easier for lesser skilled teams to deliver in.

Re: Web Components Eliminate JavaScript Framework Lock-In

#47

Post by robin_reala »

troupo wrote: post #35
robin_reala wrote: post #31

Earlier quoted context omitted.

React “won” because Facebook spent three years flying devrel to every web conference on earth to persuade other people that Facebook’s problem space was applicable to small agencies. Back in reality, React is slow and massively overbuilt for the majority of stuff that most people are building. If you played around with Web Components a long time ago then you probably played with the v0 spec, which was somewhat differ…

> React “won” because Facebook spent three years flying devrel to every web conference You do know that Google sponsored and ran things like Polymer conf? That it builds lit? That Google's devs have literally overrun and overruled most web specs committees? That Google has spend hundreds of millions of dollars promoting Web Components? And yet here we are.

Polymer was incredibly even slower that React and even more overbuilt, and it had the added negative that it tried to enforce a visual style as well, which was too much for most people. Google couldn’t spend its way out of that hole.

As for Web Component specs, we got v1 because of Apple and Mozilla: Google would happily have stayed with v0.

Re: Web Components Eliminate JavaScript Framework Lock-In

#48

Post by spankalee »

troupo wrote: post #29
spankalee wrote: post #22

Earlier quoted context omitted.

I work on Lit, which I would hesitate to call a framework, but gives a framework-like DX for building web components, while trying to keep opinions to a minimum and lock-in as low as possible. It's got reactivity, declarative templates, great performance, SSR, TypeScript support, native CSS encapsulation, context, tasks, and more. It's used to build Material Design, settings and devtools UIs for Chrome, some UI for F…

> lock-in as low as possible. As in: - reactivity. Specific to lit - declarative templates. Specific to lit - SSR. Specific to lit. - context. Specific to lit. - tasks. Specific to lit "minimal" and "low lock-in". Please do not hesitate to call it a framework. If you call React a framework, then lit is definitely a framework.

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 libraries. The reactive custom element base class ReactiveElement can be used to build web components with a different template system like Preact.

So yes, "lock-in as low as possible".

Re: Web Components Eliminate JavaScript Framework Lock-In

#49

Post by tannhaeuser »

In case anyone was wondering, JavaScript per se isn't replaced at all. All mentioned examples still use event listeners, querySelectorAll, ES modules, and what not. Most importantly, you need to subclass HTMLElement and register your custom element using JavaScript in the first place eg:

    class MyElement
      extends HTMLElement {
    }
    
    window.customElements
      .register('my-element', 
        MyElement)
(the hyphen in the name is idiosyncratically required by the custom element spec).

As such, "HTML web components" (aka custom elements, which have be around for many years) are targeted at developers not hypothetical web users/authors. Then what is the point? When you're relying on JavaScript anyway, you have already much greater freedoms - syntactically and otherwise.

Custom element declarations and custom vocabularies can make sense as a means to organize and isolate authoring concerns when you're creating hypertext documents. The fact alone that you have to use JavaScript for registering custom elements make them a non-starter though (ie consider an authoring tool which surely doesn't want to execute arbitrary JavaScript in client docs).

It's not that there's no precedent either. SGML has a mechanism for parametric macro expansion where your element is syntactically replaced into an arbitrary markup fragment, with type-checked arguments (= attributes at the call site, just as with custom elements), and with type-checking the resultant expansion in context (ie. checking whether the expansion adheres to the content model at the expansion site), also having of course the capability to include JavaScript. Moreover, SGML actually can serialize/re-parse such markup whereas HTML's preliminary APIs for fragment parsing won't deal with contextual tag inference at all.

Re: Web Components Eliminate JavaScript Framework Lock-In

#50

Post by megaman821 »

I don't feel like web components and React should compete for most people. Web components feel pretty good at making leaf components, especially when they will be used with multiple technologies. I tried using React to only make a single component for use within a larger React app and within a Django site, and it was not as smooth as a web component. Also, I tried to make a web component app and there was way more friction and less tooling than a React app. As it stands now, I wouldn't use React for single component nor web components for an entire app.
Post reply on HN