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

141–150 of 235 posts

Re: The Failed Promise of Web Components

#141

Post by systemvoltage »

ChrisMarshallNY wrote: post #134
pembrook wrote: post #130

Earlier quoted context omitted.

> It leaves a bad taste - statements like this. I don't know why. Probably because those statements are logical fallacies, this one specifically is known as argumentum ad verecundiam in Latin, or "an appeal to authority." The fact that the arguer holds a prestigious title (or wears a fancy crown) cannot prove or disprove any given statement. The inability of humans to think logically has bothered people for thousands…

Just to set the record straight, here's why I mentioned it: I like her writing style. She writes in a pithy vernacular that belies her educational credentials. She writes like a cranky old man (takes one to know one). I think we need more writing like that, as opposed to the usual buzzword bouillabaisse that makes up a significant chunk of the tech WordSphere. When someone writes like that, it can be easy to dismiss…

I empathize with you in strongest way possible. I think we all should stop being offended so damn much.

I don’t know why I felt the way I did but you’re right - take it easy, we need to be a bit more flexible and allow for room of interpretation. Sorry I felt that way in my initial comment.

I think the offending word was “def”.

> This lady has a Masters from MIT. She probably knows her way around things

Sounds much better and less authoritative :) I know what you meant in the general sense.

Side note about the author's credibility: Some of the writing from this article is stolen without credit: https://twitter.com/brucel/status/1305820902903382016

The whole flugelhorn sentence.

Re: The Failed Promise of Web Components

#142

Post by azangru »

isochronous wrote: post #110
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…

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

I've tried LitElement (still using it in a small project), and wanted to like it; but the whole experience was so cumbersome compared to something like React.

1) Classes for writing components. Yuck. React's function component feels much more elegant.

2) @property decorator. Double yuck! I want a reactive way of updating my component's state without having to declare this piece of state as a property accessible by the outside world.

3) this.requestUpdate(). Triple yuck compared to something like React's setState or useState hook.

4) In order to create children components, I need to create more customElement-decorated classes? Yuck again!

Re: The Failed Promise of Web Components

#143

Post by withinboredom »

ricksharp wrote: post #126
la_fayette wrote: post #117

Earlier quoted context omitted.

Check the time to interactive. Rehydration creates a massive cpu increase. https://developers.google.com/web/updates/2019/02/rendering-...

In lighthouse, I see a score of 100 performance and time to interactive at 1.8secs. This is comparable to hacker news home page (which is purely static), but my first contentful paint was slightly faster (probably because my site is slightly smaller). Both sites were about 4 times faster (TTI) than google home page and typescript home page.

I’d be interested in checking out your site. I normally only have a 2G connection on my phone, I’d love to be able to read something that’s NOT HN. This site is the only site I know that takes less than 5-10 mins to load, if it loads at all.

Re: The Failed Promise of Web Components

#144

Post by azangru »

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

> Downloading 500kb of js and processing this is just a nogo.

React + react-dom is under 40kb minified gzipped. The other 460kb are your responsibility.

Re: The Failed Promise of Web Components

#145

Post by cletusw »

> "I just wanted something that is small and works like a normal HTML element"

My first stop when looking for a web component is always https://component.kitchen/elix because of their commitment to the Gold Standard (https://github.com/webcomponents/gold-standard/wiki), which is basically to imitate native elements wherever possible.

Re: The Failed Promise of Web Components

#146

Post by robocat »

stickfigure wrote: post #98
brundolf wrote: post #91

Earlier quoted context omitted.

> anything interactive in JS Except this barrier has never existed. Every HTML input is interactive: text fields, checkboxes, radio buttons. They not only remember their value, but your cursor position within them and the segment of text you've highlighted. The browser knows how far each scrollable element is scrolled, which element is in focus as you tab through the page. Forms have validation state, and can be inte…

I built lots of HTML form UIs in the early 2000s. They were garbage. Many modern web UIs are on par with native apps, so much so that folks are now using web technologies to build actual native apps. With 150 years of evolution (at current W3C standards pace) you might get an HTML spec that is capable of expressing the behavior that users expect from present-day applications. Until then we have React et al.

> Many modern web UIs are on par with native apps

I strongly disagree.

Form/ fields are one of the areas that a native app can slaughter HTML, even if using a WebView within an app. For example, just showing the correct keyboard layout is a nightmare, and heaven help you if you need to do something slightly custom. Another example: browsers do funky shit with scrolling and zooming on input focus. Try using the best HTML code-editor from a tablet: the editing experience sucks.

Another example is swiping, where browsers like Safari Mobile (and the old Edge) decide to navigate back/forward if the user happens to swipe from the edge by mistake - killing page state. Overriding pinch-zoom for say a photo app is doable, but sometimes ends up with invalid UI states (especially if you mix in viewport sizing changes due to orientation/ua-zoom/virtual keyboard show/tab bar show).

Disclaimer: I have spent many man-months working only on making user friendly custom s in HTML, and the experience blows chunks. I have developed a custom Web UI that required too many compromises in UX.

Re: The Failed Promise of Web Components

#147

Post by cdata »

c-smile wrote: post #67

> Can we fix this? Sure, by returning to basics. Let's assume that Web Component is a DOM element with a code associated with it + lifecycle events. Here is how Components are done in Sciter ( https://sciter.com ) 1. CSS has got `prototype` property: div.my-component { prototype: MyComponent url(script/components.js); } where MyComponent is the name of class in JS, url (optional) is an URL where this MyComponent can…

This is literally what a custom element is. Assuming your @event decorator is built upon the EventTarget interface:

  class MyComponent extends HTMLElement {
    // lifecycle event/method
    connectedCallback() {}
    
    // lifecycle event/method
    disconnectedCallback() {}
    
    @event("mousedown")
    onMouseDown(evt) { }
    
    @event("click", "button#submit")
    onSubmit(evt, button) { }
      
    @event("change", "input.name")
    onNameChange(evt, input) { }
  }
That said, custom elements don't cost $310 for an indie license. Instead, they are free and available in every web browser.

Re: The Failed Promise of Web Components

#148

Post by mlvljr »

runawaybottle wrote: post #119
devit wrote: post #114

Earlier quoted context omitted.

No, Visual Basic 6 can only place controls by X/Y position, has no databinding and no VDOM or way to create controls other than placing them in the designer or manually creating and destroying them in code. It's pretty terrible unless you want to make UIs with a fixed size and set of controls.

So then I’ll keep the question open. What is the dopest UI framework across any language with great paradigms, design language, developer experience, and of course, dope results? Right now I’ll say the best iOS/android apps put web to shame. Is Flutter and SwiftUI where we should be looking? The question is specific to semi complex apps (typical crud), not websites.

QML might be.

Re: The Failed Promise of Web Components

#149

Post by ralphc »

cdata wrote: post #107

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

I do work in Salesforce, and I find Lightning Web Components easier to use and understand than the popular frameworks. Yes they require JavaScript, but the alternatives don't?

Re: The Failed Promise of Web Components

#150

Post by arkis22 »

dheera wrote: post #7
blurbleblurble wrote: post #3

I recently stumbled across "shoelace", which at a glance seems like an example of what the article is hoping for. It's a thoughtfully designed library of UI web components. https://shoelace.style/

... and it suffers from the same oversight every other web component library (polymer, mdl) suffers from: - I can't swipe left/right between the tabs - I can't pull the menu out from the left by swiping the entire page right Two of the most basic touch navigation metaphors aren't supported. To be fair, Polymer and MDL don't support the above either. But this is why HTML5 apps are still not up to par with native apps.…

I don't think I've ever used an app I wouldn't have preferred as a web app
Post reply on HN