Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web Components could replace frontend frameworks?

dannymoerkerke.com

Post reply on HN
Print view View original

191–200 of 248 posts

Re: Web Components could replace frontend frameworks?

#191

Post by greenyouse »

Browser specifications are not nearly as transient as proprietary frameworks. Web components will be here next year, five years from now, ten, and thirty years from now. We should focus on how we can take advantage of the new spec to enhance existing frameworks.

Popular projects like React use templates but require you to bundle the entire framework and the speed of the vDOM diffing happens at the speed of JS. What if it could take advantage of HTML templates to work at the speed of C++ by leveraging built-in browser support?

One of my hopes is that we can stop the bad trend of rewriting the same front-end components over and over again. Instead there could be a set of canonical components that people use for different web site types. If you're building an e-commerce checkout system, you could pull in the email address input built by Twitter, Stripe's credit card input, and the address input built by some person on GitHub that has 5,000 stars. Authors could leverage CSS properties and ShadowDOM for nice style hooks so developers could customize the branding.

The job of web frameworks could shift from "how do people build UI components" to "how do people build SPAs with routing, cookie auth, service worker caching, etc.". Not that current frameworks don't try to handle app level things but there is a lot more that could be done to make this easy for developers.

It would be nice to see web components as orthogonal to framework UI styling. We should be able to pull in web components from anywhere and frameworks should be smart enough to co-opt the components by treating them as native DOM elements (like div or span).

Sorry if this was sort of a rant I didn't have much time before work...

Re: Web Components could replace frontend frameworks?

#192

Post by spankalee »

dmitriid wrote: post #88
spankalee wrote: post #36

Earlier quoted context omitted.

There's nothing wrong with using a DOM templating library to give you declarative DOM updating. There are a number of solutions, many even JSX-based, and this is also why I created lit-html, which offers extremely light weight template expressions, similar to JSX but in standard syntax, and very fast updates. There's no requirement that you use web components without helper libraries. That was never their intent.

> That was never their intent. No one remembers what the intent was. Just two years ago the whole narrative from the proponents of web components was “the future is here, no need for frameworks, get rid of your reacts and angulars and... and...” But then people actually tried using them. So, curiously, the narrative quickly shifted to “oh, these are just primitive APIs never intended for direct use, and only intended…

No one working on web components had ever said that they're intended to be used with absolutely no helpers.

Re: Web Components could replace frontend frameworks?

#193

Post by bobske4 »

wasm and wasi will eventually take over enabling higher level languages such as C#, Java and Python to be used at frontend (Blazor project is an example).

As Mr. Bernhardt says: JavaScript had to be bad for the evolution to happen. (https://www.destroyallsoftware.com/talks/the-birth-and-death...)

Re: Web Components could replace frontend frameworks?

#194

Post by plopz »

jbwyme wrote: post #63
ssorallen wrote: post #11

Web Components don’t offer a declarative way of updating the DOM; it’s still `innerHTML` and using DOM APIs to edit the state of the live DOM. Backbone was a hassle to manage in any sizeable app because updating the view was left up to every dev to figure out themselves. React brought a declarative wrapper around the statefulness of the DOM, and that is the killer feature that Web Components does not offer at all. Vu…

We have been using a small bit of glue code to write Web Components declaratively with Snabbdom for a couple of years at Mixpanel: https://github.com/mixpanel/panel . Happy to talk further about our experience!

Thats what lichess uses as well.

Re: Web Components could replace frontend frameworks?

#195

Post by petilon »

lstamour wrote: post #23
ssorallen wrote: post #11

Web Components don’t offer a declarative way of updating the DOM; it’s still `innerHTML` and using DOM APIs to edit the state of the live DOM. Backbone was a hassle to manage in any sizeable app because updating the view was left up to every dev to figure out themselves. React brought a declarative wrapper around the statefulness of the DOM, and that is the killer feature that Web Components does not offer at all. Vu…

There is lit-html and lit-element, though you can get tripped up by the difference between props and attributes coming from React JSX where everything is props because it’s all native JS until the DOM render... It’s tricky to recommend them because I’m using web components at work and find the transition from React especially rocky. But they are native and standard, and other frameworks are slowly moving in that dire…

You can use JSX syntax for building web components using this tiny library: https://github.com/wisercoder/uibuilder

Re: Web Components could replace frontend frameworks?

#196

Post by spronkey »

greenyouse wrote: post #191

Browser specifications are not nearly as transient as proprietary frameworks. Web components will be here next year, five years from now, ten, and thirty years from now. We should focus on how we can take advantage of the new spec to enhance existing frameworks. Popular projects like React use templates but require you to bundle the entire framework and the speed of the vDOM diffing happens at the speed of JS. What i…

Forms are where web standards are most lacking. HTML5 took us from the stone age to the bronze age by adding some still-basically-useless inputs for e.g. colours and dates.

Everyone is reinventing the wheel over and over here and it's infuriating. I recently tried to find a good component to provide an internationalised currency input - it's incredibly difficult to find a quality implementation for this, yet it's something that the vast majority of web applications will need to use at least once. Same goes for phone numbers.

It would be nice to see web components take these roles away from frameworks. It would be nicer to see web standards identify the importance of many of these inputs in the first place.

Re: Web Components could replace frontend frameworks?

#198

Post by ravenstine »

This article, the HN comments here, as well as comments on /r/javascript, are helping to solidify my view that way too many frontend developers don't know enough about what they're talking about.

I really don't get the disdain against Web Components and their related APIs. Why even fewer people are excited about custom elements alone sort of baffles me.

WC's aren't intended to replace frameworks and libraries. It's there to provide some universal primitives for writing components, and a lot of components aren't actually complex enough to warrant all the heavy lifting that comes with things like React and Vue. Those tools are great, but I also really love the idea that I can write useful components without having to import a bunch of extras(eventually the polyfills will be obsolete).

The innerHTML function can be slow if your code is sloppy and you're applying it to the wrong problem. Yes, you might need a data-aware renderer like the one in React, but often times you might not. For a lot of simple things, you can render elements without it by using createElement(), append(), insertBefore(), insertAdjacentElement(), cloneNode(), etc. They're not hard to use, but they're not pretty like a templating language, and they're not going to surround you in bubble wrap. I'm not saying that those tools scale for bigger projects, but there are plenty of small things you could write using Web Component technology. It has its place.

If you do things like call innerHTML multiple times in a loop, when you really could concatenate your HTML and call innerHTML once, is fundamentally going to perform badly, but web developers seem to write that kind of terribly-performing code in all sorts of cases and when it runs like crap they just assume that they need to import a library that will use tricks to cover up their lousy code. It reminds me of how folks will write a pile of garbage with Rails, switch to Phoenix because their Rails app is slow, and then claim that Rails sucks at performance. That's not to say that Phoenix doesn't have clear performance advantages, but the claim that Rails is slow often comes from a place of ignorance. A lot of jobs warrant useful tools like Vue, but then again, maybe your code just isn't very good. It's really embarrassing how many of us don't write code to be efficient, opting to always stand on the shoulders of giants who do the hard work to make our lousy code appear to run fast.

Re: Web Components could replace frontend frameworks?

#199

Post by spankalee »

dmitriid wrote: post #85
spankalee wrote: post #64

Earlier quoted context omitted.

The lit-plugin VS Code extension provides type-checking and code-completion for lit-html temptlates. The approach can be adopted for a tsc plugin.

It’s still opaque string blobs no matter how you try to dress them up. —- I should probably edit this: It’s still string blobs that are totally opaque to the browser, and that are parsed with regular expressions[1] at runtime[2] and dumped into DOM via innerHtml[3]. [1] https://github.com/Polymer/lit-html/blob/61c08a615abadbe58bc... [2] http://exploringjs.com/es6/ch_template-literals.html [3] https://github.com/Polym…

Yeah, lit-html scans template strings to determine what kind of markers to join them with - comments for text expressions, {{}} for attributes. This is before handing to the browsers HTML parser.

So what? You always pop up to complain about this, like it should be some obvious fatal flaw, but you never explain why it bothers you personally so much.

Does it make lit-html slower? No. lit-html scanning + native HTML parsing is faster than native JavaScript parsing of transformed JSX.

Are lit-html templates "opaque"? That's arguable. Tagged template literals were invented and added to browsers for a reason. lit-html takes advantage of a very nice browser feature, and then hands the result to the native HTML parser, which does understand them. I'd say it's no more opaque than compiled JSX: the browser has no way of knowing that those nested function calls represent HTML, so they're "opaque".

I'm going to continue to shrug every time you complain about this until you explain why it's even bad.

Re: Web Components could replace frontend frameworks?

#200

Post by spankalee »

Vinnl wrote: post #141
lstamour wrote: post #23

Earlier quoted context omitted.

There is lit-html and lit-element, though you can get tripped up by the difference between props and attributes coming from React JSX where everything is props because it’s all native JS until the DOM render... It’s tricky to recommend them because I’m using web components at work and find the transition from React especially rocky. But they are native and standard, and other frameworks are slowly moving in that dire…

But at that point the headline is "framework x could replace framework y"? Web Components are great for reusable components like date pickers that you might want to re-use regardless of framework. If they're just the technology backing the implementation of some framework, than that framework is only worth switching to if it provides something fundamentally better than the framework you and many others already know,…

Templating libraries are far from frameworks. lit-html doesn't have a component model, and it's use in a web component doesn't leak outside of that component. You could switch from lit-html to something else and it wouldn't be a breaking change to users.

Try thinking about writing a React component that doesn't use React to render. Or seamlessly intermixing React and Vue commoners. Then you see the difference.

Post reply on HN