Live data from Hacker News

Web Components Eliminate JavaScript Framework Lock-In

jakelazaroff.com

21–30 of 300 posts

Re: Web Components Eliminate JavaScript Framework Lock-In

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

It sounds like the common thing that someone in the Frontend space would say, that a technology less than 5 years old says the technology is old.

I prefer the terms stable, mature, or hardened.

People use React/Angular because large products are forced to have a way to organize things across multiple developers and time. Now don't get me wrong I think these JS bloated websites are an abomination that have largely made the web worse and not better, especially since UX "engineers" feel a compulsive need to change the layout every 6 months and now even simply scrolling through a page involves 50 web requests, and takes a full 3 minutes to load the next page... but I digress.

Re: Web Components Eliminate JavaScript Framework Lock-In

#22
post #16

I've been fought by people insisting that if we're using a framework, we should be using it for everything, if it has it, even when both agree that doing it natively is actually less cumbersome. All that in the name of consistency. I think middle ground is a good solution. On topic: I don't think WebComponents are going to "make it" until someone builds a nice framework on top of them. React, Vue, Svelte, etc. solve…

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 Firefox, Reddit, Photoshop Web...

https://lit.dev if you're interested.

Re: Web Components Eliminate JavaScript Framework Lock-In

#23

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

Author here — I feel like I addressed this point in the article, no? Obviously using a zillion frameworks in your app is a bad idea, but there are a bunch of actual reasons that encapsulating and/or mixing frameworks might be useful:

- Gradually migrating from one framework to another

- Including interactive "islands" within a static or server-side rendered page

- Using a dependency only available in one framework from within another (this works best if the dependency framework has a small footprint — e.g. using Svelte within React is better than vice versa)

Re: Web Components Eliminate JavaScript Framework Lock-In

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

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…

What if you could have the best of both worlds? What if you could use JSX templates and use standards-based web components? You can.

Here's an example of using a web component in a JSX template (look for zx-listeditor): https://github.com/wisercoder/uibuilder/blob/master/WebCompo...

Here's how the web component is implemented, also using JSX: https://github.com/wisercoder/uibuilder/blob/master/WebCompo...

Re: Web Components Eliminate JavaScript Framework Lock-In

#25

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…

What if you could have the best of both worlds? What if you could use JSX templates and use standards-based web components? You can. Here's an example of using a web component in a JSX template (look for zx-listeditor): https://github.com/wisercoder/uibuilder/blob/master/WebCompo... Here's how the web component is implemented, also using JSX: https://github.com/wisercoder/uibuilder/blob/master/WebCompo...

Not saying that you can't. I'm just explaining why React won and how it was blatantly obvious that it was going to win when it came out (that is, if you were there in the before-times).

Re: Web Components Eliminate JavaScript Framework Lock-In

#26

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 mistake React did was to keep reactivity on component level (hence all the hooks and their weird rules) when most people moved on to more granular reactivity. Hell, even Angular did.

Re: Web Components Eliminate JavaScript Framework Lock-In

#27

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

Forgot to mention, the knock-on effect of this thought process is that if you want to adopt web components, you still need a templating approach. And you'll find that most of your code is templates, and only a few are really components.

Re: Web Components Eliminate JavaScript Framework Lock-In

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

Fascinating that React simultaneously receives criticism as being

1) boring, old technology that has been around for so long that no one even remember why it was chosen in the first place, and

2) extremely fast-churning, bleeding edge software that is constantly changing and breaking because the JS community is more interested in chasing trends than building robust stuff.

Re: Web Components Eliminate JavaScript Framework Lock-In

#29
post #16

I've been fought by people insisting that if we're using a framework, we should be using it for everything, if it has it, even when both agree that doing it natively is actually less cumbersome. All that in the name of consistency. I think middle ground is a good solution. On topic: I don't think WebComponents are going to "make it" until someone builds a nice framework on top of them. React, Vue, Svelte, etc. solve…

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.

Re: Web Components Eliminate JavaScript Framework Lock-In

#30
post #16

I've been fought by people insisting that if we're using a framework, we should be using it for everything, if it has it, even when both agree that doing it natively is actually less cumbersome. All that in the name of consistency. I think middle ground is a good solution. On topic: I don't think WebComponents are going to "make it" until someone builds a nice framework on top of them. React, Vue, Svelte, etc. solve…

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…

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