Web Components Eliminate JavaScript Framework Lock-In
jakelazaroff.com
Web Components Eliminate JavaScript Framework Lock-In
1–10 of 300 posts
Re: Web Components Eliminate JavaScript Framework Lock-In
#2Thank you for the great read!
The last few weeks have seen a lot of thought on HTML web components, and I'm really happy about it.
Re: Web Components Eliminate JavaScript Framework Lock-In
#3My 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-user. If you're using three overlapping frameworks to build one web service frontend purely because someone in your team likes Svelte and someone else likes React... that's a problem. You'll be pushing more bytes than you should to your end-users, and that cost doesn't scale the right way; in fact, the more popular your app, the more redundant bytes you'll be passing.
We don't want to enable multiple frameworks in the UI. We should be settling on one and committing everyone on the frontend team to using it (ideally lock-stepped to the same version of it) within each app-shaped thing we create as a frontend team.
Re: Web Components Eliminate JavaScript Framework Lock-In
#4i did this back in 2019 to make the transition smoother between angular.js and react
> there are ways to build a web app other than writing the entire thing with a single JavaScript framework
totally agree, and reducing rewrites or making converting them into "strangler" rewrites is a huge win
on the other hand, it reminds me of the microservices hype a few years back. Just because you can, doesn't mean you should. Uniform languages, frameworks, coded patterns make things SO much smoother for an organisation.
I would repeat the author's words of warning: "you should not build a real app like this!". you should seriously think hard before adding this level of complexity to any production app
Re: Web Components Eliminate JavaScript Framework Lock-In
#5I've seen the entire industry move towards React/Angular type frameworks and it's invariably been a really bad thing. Large projects end up with front end specialists and backend specialists and very few actual full stack devs. What ends up happening is that no one person can do an entire feature anymore.
I'm all for web components!
Re: Web Components Eliminate JavaScript Framework Lock-In
#6One 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 build on React are doing it largely out of habit.
I'm going to withhold my own thoughts about that quote, cause I'm curious what everyone else thinks.
Wrt. Web Components, I played around with Web Components about half a decade ago and they felt promising but not ready for prime time yet. They were pretty messy and felt like they did a poor job of encapsulation. (At least at the time.) I haven't looked at them recently, but the code examples in these articles look much better (and cleaner) than what I remember.
Re: Web Components Eliminate JavaScript Framework Lock-In
#7I've seen the entire industry move towards React/Angular type frameworks and it's invariably been a really bad thing. Large projects end up with front end specialists and backend specialists and very few actual full stack devs. What ends up happening is that no one person can do an entire feature anymore. I'm all for web components!
This is not my experience at all. Why can't a full stack dev know react or angular?
Re: Web Components Eliminate JavaScript Framework Lock-In
#8lit.dev is awesome.
I am a backend dev so I don't really want to get into the intricates of React or Angular. But if I need some reactivity for some complex element, I use lit. It's awesome
Re: Web Components Eliminate JavaScript Framework Lock-In
#9They don't.
When your tech needs 20 more web specs [1] to fix stuff that literally no one has issues with, it means that you will be locked in to frameworks that solve these issues.
Literally right now Web Component SSR is a framework-specific barely working non-solution. Even the most ardent web component proponents have given up and advocate a framework lock-in with lit-html and others.
Re: Web Components Eliminate JavaScript Framework Lock-In
#10I've seen the entire industry move towards React/Angular type frameworks and it's invariably been a really bad thing. Large projects end up with front end specialists and backend specialists and very few actual full stack devs. What ends up happening is that no one person can do an entire feature anymore. I'm all for web components!
The concerns, constraints, and behavior of server-side headless software and a viewer that fetches and renders data from a remote backing store are entirely different.
Is it a bad thing that organizations specialize on those concerns? Seems like the most obvious place to slice responsibility, even if it means every feature is split across two teams. After all, the performance of the backing store is impacted not by neigbhoring logic in the UI infrastructure but by neighboring state in the backing store; it should be someone's job to be looking at the backing infrastructure holistically and not sliced as "frontend-backend feature A, frontend-backend feature B, etc."