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

The Failed Promise of Web Components

lea.verou.me

Post reply on HN
Print view View original

101–110 of 235 posts

Re: The Failed Promise of Web Components

#101

Post by jeroenhd »

pier25 wrote: post #89
jeroenhd wrote: post #77

Earlier quoted context omitted.

Web browsers provide many features out of the box but frameworks rarely use them. Web components are one thing; HTML templates are another. Streaming video is being decoded by Javascript even though every browser supports H.264, input elements such as calendar controls are rewritten, animations are done in JS instead of smooth CSS transitions, drag and drop support is manually rewritten in JS... Whenever a feature ge…

> Streaming video is being decoded by Javascript even though every browser supports H.264 Maybe in some experimental project, but I've never seen this in any video site. > input elements such as calendar controls are rewritten Yes, because the native browser widgets are totally insufficient and can't be styled. > animations are done in JS instead of smooth CSS transitions JS animation can be super fast (see GSAP) and…

> Yes, because the native browser widgets are totally insufficient and can't be styled.

I don't want them to be styled, thank you very much.

> JS animation can be super fast (see GSAP) and it seems you're talking about jQuery.animate() which I agree was terrible. But these days most people use CSS animations.

GSAP is giving me stuttery animation when I scroll through their website on my phone, presumably because it's constantly updating the DOM to keep control of the animation. It's not as bad as the state of JS animation was 10 years ago, but I can think of very few use cases where such a library would actually be necessary instead of using pre-calculated CSS transitions and such.

> Again, because the browser does not have a proper drag and drop API to do it.

I haven't had that much trouble when I had to use the HTML5 DnD API. Well, not more than with the frameworks I've seen; touch screen DnD support sucks on all platforms I've tried.

Re: The Failed Promise of Web Components

#102

Post by sergeykish »

Web Components were crafted for jQuery world.

    $("#datepicker").datepicker()
Custom elements resolves problem we had with XHR HTML response, it instantiates automatically. Problem solved. Widgets were popular and easily broken by CSS, solved by Shadow DOM.

Re: The Failed Promise of Web Components

#103

Post by nkingsy »

brundolf wrote: post #20

This post is needlessly snarky, but I don't disagree with the basic premise. Here's what killed web components: lack of native databinding on the web. That's the reason the standard is useless without JS. Any modular, dynamic, modern UI requires databinding, which means it's going to bring in a framework anyway, which means that self-contained widgets are all going to bring in their own frameworks, which means that i…

The web components under the hood would still need a way to program themselves in response to that data, so a templating language would need to be baked in along with data binding.

Secondary languages are a bad idea, so hopefully this templating language would be something like jsx/ejs.

The proposal really is to bake applications support in to the browser. That seems right to me. The browser is more and more an os, and it should support rich applications out of the box.

React is derivative of windows application development, so there is precedent for something like it to be baked in to an OS.

Re: The Failed Promise of Web Components

#104

Post by throw1234651234 »

la_fayette wrote: post #88
nwienert wrote: post #75

Earlier quoted context omitted.

Web Components are a total mess and impossible to build anything of significance with. I can't even imagine how anyone would get anything done with them. It's like an Angular developer, an artist, and a mid-2010s neural net walked into a bar and sketched out a spec by taking shots and passing it clockwise. Separation of languages is a silly way to separate things. You're building components : logic, structure and sty…

React is a nightmare when it comes to performance or energy efficiency... Downloading 500kb of js and processing this is just a nogo. The best advice to anyone interested in page speed, dont use this crap. https://youtu.be/plt-iH_47GE

Use Gatsby and generate a static site w/ React? At least React is faster than Angular, which I strongly prefer.

Re: The Failed Promise of Web Components

#105

Post by aazaa »

> The other day I was looking for a simple, dependency free, tabs component. You know, the canonical example of something that is easy to do with Web Components, the example 50% of tutorials mention. I didn’t even care what it looked like, it was for a testing interface. I just wanted something that is small and works like a normal HTML element. Yet, it proved so hard I ended up writing my own!

I was looking for some examples of the better approach the author seems to want, but didn't find them.

Found some in the article linked near the bottom:

https://www.smashingmagazine.com/2017/02/designing-html-apis...

The author gives an example of a list-type component. It can be initialized in one of two ways:

- JS-first: an empty list element is added and a JS initializer populates the children from data

- HTML-first: the full markup for the list is added, including children, and the JS works in the background to build the right internal data representation

The rest of the article gives specific, actionable advice on building HTML-first components. For this reason, I think it's a better article to start with.

Re: The Failed Promise of Web Components

#106

Post by runawaybottle »

Animats wrote: post #92

What's so embarrassing is that the HTML/CSS/Javascript mess does roughly the job Visual Basic did. But worse.

Is that true? If I download Visual Basic right now, could I make a sensible visual app vs React?

I’m tempted to see if the truth is really out there.

Re: The Failed Promise of Web Components

#107

Post by cdata »

This article is tailored to attract the web components haters. IMO it does not foster a constructive thread of discussion, and some of the critique just as easily applies to the JavaScript ecosystem overall.

Web components have some distance to go before they are ideal for all of their envisioned use cases. In particular, I am awaiting declarative shadow roots, declarative custom elements and template instantiation ("data binding").

That said, the work that has been done so far on them is impressive. Web components by and large have survived the needless antagonism they have received from some corners and proved themselves in production scenarios from companies big and small. If you have interacted with a Salesforce application, you have used web components. If you have visited Github, you have used web components. If you watch videos on YouTube, you have used web components.

The ground truth is that web components are solving problems and making headway. They only stand to get better as new capabilities begin to land. I'm excited for what the future holds.

Re: The Failed Promise of Web Components

#108

Post by stevebmark »

If you work in the Salesforce ecosystem, you know they are doubling down on their use of web components in their "modern" development process. This has lead to a very poorly designed ecosystem. It's infuriating they continue to double down on a system that the rest of us are rightfully abandoning.

Re: The Failed Promise of Web Components

#109

Post by ricksharp »

la_fayette wrote: post #88
nwienert wrote: post #75

Earlier quoted context omitted.

Web Components are a total mess and impossible to build anything of significance with. I can't even imagine how anyone would get anything done with them. It's like an Angular developer, an artist, and a mid-2010s neural net walked into a bar and sketched out a spec by taking shots and passing it clockwise. Separation of languages is a silly way to separate things. You're building components : logic, structure and sty…

React is a nightmare when it comes to performance or energy efficiency... Downloading 500kb of js and processing this is just a nogo. The best advice to anyone interested in page speed, dont use this crap. https://youtu.be/plt-iH_47GE

My website which is entirely built in react (and uses Gatsby).

Takes 4kb to full page render (1 file - static only - JavaScript disabled).

That’s smaller than most any html+css especially if using some css library.

Of course once that is loaded and if JavaScript is enabled, then it will start to load interactive stuff and prefetch (which is around 100kb - but I have a lot of interactive stuff - including a zork style adventure Easter egg in the site header).

Re: The Failed Promise of Web Components

#110

Post by isochronous »

nwienert wrote: post #75
jeroenhd wrote: post #61

Earlier quoted context omitted.

I'm a strong proponent of separation of duties on the web (style and visuals in CSS, layout in HTML, anything interactive in JS). Enabling data binding in HTML would only serve to blur those lines. With some minimal JS, you can update each web component already. Is writing nameField.innerText = response.name really that difficult? What problem does it solve to make a standard for it? As for (de)serialization, JS has…

Web Components are a total mess and impossible to build anything of significance with. I can't even imagine how anyone would get anything done with them. It's like an Angular developer, an artist, and a mid-2010s neural net walked into a bar and sketched out a spec by taking shots and passing it clockwise. Separation of languages is a silly way to separate things. You're building components : logic, structure and sty…

Weird, because we're using web components at my workplace to build complex web applications. We use Lit-Element as a base class and have come up with a top-down functional state pattern for data that removes the need for two-way binding. If a sub-component needs to update its state due to DOM interaction, it just fires off an event with info about that DOM interaction, and the data store for that component (another web component) does the necessary state modification, then fires off a "state-changed" event that tells all associated components to update their state from the "master" store (one line of code). All of the data elements use pure functions to do state modification, so doing complex operations is simply a matter of composing the appropriate functions. I've not used react myself other than playing with a few demos, but another developer on my team says the pattern is very similar to how react stores work, and the core modules that drive it are like 100 lines of code.
Post reply on HN