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

51–60 of 300 posts

Re: Web Components Eliminate JavaScript Framework Lock-In

#51

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…

> Make a convincing argument that a different design pattern is better.

Simple Model-View-Controller pattern works well for JavaScript, just as it does for ASP.NET Core, JSP and JSF, Ruby on Rails, Django and so on.

Want proof? Browse this code:

https://github.com/wisercoder/eureka/tree/master/webapp/Clie...

This is the application: https://github.com/wisercoder/eureka

Re: Web Components Eliminate JavaScript Framework Lock-In

#52

Post by menssen »

breadwinner wrote: post #44
menssen wrote: post #39

Earlier quoted context omitted.

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

It is possible with React to write an application where components have no internal state, every component is "read only," and all UI changes are state transitions in (something like) a redux store.

This is rarely done, because there are pragmatic reasons (e.g., animations) not to, but it is possible.

The other mistake alternatives make is to try to make components having internal state "easier." It should not be easier! Every single useX() is a statement that "I am violating the proper design pattern of this application," and it's a feature not a bug of React that you have to be obvious and intentional about it.

Re: Web Components Eliminate JavaScript Framework Lock-In

#53

Post by spankalee »

veeti wrote: post #30
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…

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 necessary. We're also trying to build up our non-Google contributors.

Re: Web Components Eliminate JavaScript Framework Lock-In

#54

Post by menssen »

tyingq wrote: post #46
menssen wrote: post #39

Earlier quoted context omitted.

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

There is always space for options for "fast and easy" vs "robust and maintainable."

Nothing will ever beat the following as tech demo for how easy it is to make interactive UIs, but anybody who ever tried to reason through a large Angular 1 application would seriously hesitate to want to use it for something much more complicated.

{{ inputValue }}

Re: Web Components Eliminate JavaScript Framework Lock-In

#55

Post by OJFord »

preommr wrote: post #43

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

I think we're going in the opposite direction though - everyone wants to hide what's going on and use some magic CLI that just takes care of everything for you, don't worry about how or when or what to do if it goes wrong, just run `flyctl deploy`, `wrangler publish` (Cloudflare), `npx wizzle wazzle` :sparkles: :tada: never `git commit -m '(chore): [...]'` again!

Oh and here's a readme example of how to set that up if you're using pnpm v42 with sveltekit v2 and webpack v99. For any other combination of the 5 packagers, 19 bundlers, and 56 frameworks commonly in use and giving examples like this recommending each other - have fun.

Re: Web Components Eliminate JavaScript Framework Lock-In

#56

Post by MrPatan »

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…

Preach. Angular 2+, btw, can (and should) be used the same way. V=f(S) is the only sane way to live.

Just don't change application state from a component lifecycle function and you're golden.

Re: Web Components Eliminate JavaScript Framework Lock-In

#57

Post by r3trohack3r »

For folks looking for a lightweight JS class that manages the lifecycle of Web Components, I have this little Template class I use in many of my front-end projects. It's able to manage the application state by pushing the state down through the application and bubbling changes up.

It's a 161-line file that's easy to reason about and modify as needed.

https://github.com/retrohacker/template

Re: Web Components Eliminate JavaScript Framework Lock-In

#58

Post by austin-cheney »

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…

As a full time JavaScript developer of 15 years it boils down to 2 reasons.

1. Eases candidate selection. There is no uniform baseline of competence in software generally and certainly nothing exists for web development. Its often the blind leading the blind, so outsource everything to a tool. At the very least, people that cannot use that tool are then not qualified to be there if you discount absolutely everything else. After all, it isn't as though employers are willing to train new developers to perform as required, so they need to turn this into a commodity as much as possible.

2. Composition. Most of the people who do web development cannot write original software, plan, or organize at the level required by modern applications. Employers still need people to do trivial things to get text to appear on screen. As the demand for these trivial tasks still exists employers still need to hire people to do this work, and so they attempt to outsource the parts that require higher intelligence.

These beg the obvious question: What will happen when employers realize they don't need to overpay developers to do this work when half of it can be pushed into content management systems and the other half can be pushed into AI?

Re: Web Components Eliminate JavaScript Framework Lock-In

#59

Post by runarberg »

tannhaeuser wrote: post #49

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

For me, being able to offer my library as a web component is kind of neat. Sure I can ask users of my library to import it then query select math inputs, then apply my library on these, and remember to apply it also on DOM change.

    
      import lib from "/path/to/my/lib.js";
      for (const target of document.querySelectorAll(".target")) {
        lib(target);
      }
      // TODO: Watch for DOM change and apply lib.
    

    Some Input
Or I can simply ask them to import my web component module and use the custom element:

    

    Some input
The latter certainly feels like a superior API for my users.

Re: Web Components Eliminate JavaScript Framework Lock-In

#60

Post by beebeepka »

toasted-subs wrote: post #36
oblak wrote: 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…

Svelte compiles into WebComponents.

That's good to know. I really liked what I saw last time I played with it but it's hard to find many job listings where people are using svelte. Almost everything is react and surprisingly, at from what I can tell, it's getting even bigger share in job postings I used to see. Hooray for uniformity, I guess.
Post reply on HN