I wrote a response to this article, Lea was kind enough to respond to it by the way: https://medium.com/swlh/the-failed-criticism-of-web-componen...
The Failed Promise of Web Components
201–210 of 235 posts
Re: The Failed Promise of Web Components
#202I love her description of using a dependency-laden component: > Using a custom element from the directory often needs to be preceded by a ritual of npm flugelhorn, import clownshoes, build quux, all completely unapologetically because “here is my truckload of dependencies, yeah, what”. Many steps are even omitted, likely because they are “obvious”. Often, you wade through the maze only to find the component doesn’t w…
This is just the reality of the current JS world and just how it continues to get done for practical and profressional reasons. The dream is having small self-contained web components and can just drop in to your site (the whole whole anti-JS stuff is a whole other beast and IMO unrelated to practical shortterm goals of getting web components at the browser. What the components end up doing is still heavily dependent…
)
Re: The Failed Promise of Web Components
#203Earlier quoted context omitted.
We had XUL at one stage which is I think what you’re talking about. It just never took off. I think you’re pointing out that the premise itself is flawed given the clunky nature of html, which could be why ...
I'm pointing out that HTML as it exists right now doesn't solve the big problems around this. I still think it could be extended to do so, but what's important here is that it hasn't been.
> HTML as it exists right now
Is there any other kind?
Seriously wondering if there’s something specific you had in mind ...
My take is that it’s a harder solution space than can be solved gracefully with a single technology. It’s always easier to take a more convoluted approach. I think what confuses us is the visual nature of these apps; we think we should be able to describe them visually, and maybe you can, but it’s seldom worth the time and effort.
Re: The Failed Promise of Web Components
#204> I’m not sure if this is a design issue, or a documentation issue. Perhaps for many of these web components, there are easier ways to use them. Perhaps there are vanilla web components out there that I just can’t find. Perhaps I’m looking in the wrong place and there is another directory somewhere with different goals and a different target audience.
I did a deep dive into web components for a client recently. I tried to see if we could translate an entire Angular component library into Web Components we could share with the entire org and they could use them regardless of wrapping framework. I ran into the same discoverability issues the author did. After finding a new package, I'd spend some time with it, hit its limitations and then by magically finding the right article I'd find an entirely different project. In total I ended up sampling: plain JS web components, Svelte, Stencil, lit-element, Angular -> WC, and probably a few more. None ever really seemed to work, and the jank I encountered in them all via slotting seemed to preclude using them-- I could never get rid of a very noticeable Flash of Un-styled Content.
The end goal the author talks about sounds really nice, a simple script tag to get more HTML. I think in practice though, that end goal isn't so rosy. If your web page is just web components + html/css then perhaps it's performant enough . But if you're working on a truly massive application (think design collaboration tools, etc), then probably you'll just want to keep it all in the framework, you're already paying a size penalty, might as well not pay a complexity penalty as well.
If we can get a simple, useful, and popular web component library as an accepted standard, I think it will be useful to a certain sliver of developer who needs more power than HTML/CSS but doesn't want to learn lots of JS, but I think that will be a sliver of developers, not many. For the rest, I can imagine single-file-per-component compilation based frameworks like Svelte will obviate the need for web components. Remember, html is for the authors, not the consumers of web pages, and if your app is suitably large enough you'll probably need complexity managed in several ways (global state, UI components, data fetching, etc) and in that sense a framework will likely serve you better.
Re: The Failed Promise of Web Components
#205The death of HTML imports killed web components for me. With HTML imports, you would import a HTML file. In that file would be css, html and the js to make the component. Then you’d use HTML as usual in your main file. Finally you could create custom components easily while keeping yourself dealing primarily with HTML. Instead, you were forced to use bizarre js import systems. And at that point you were in JS land. F…
> In that file would be css, html and the js to make the component. You can do that. Here's an example Web Component that contains the css, html and javascript: https://github.com/wisercoder/uibuilder/blob/master/WebCompo...
I'm talking about how you import that into your main HTML file.
Re: The Failed Promise of Web Components
#206The death of HTML imports killed web components for me. With HTML imports, you would import a HTML file. In that file would be css, html and the js to make the component. Then you’d use HTML as usual in your main file. Finally you could create custom components easily while keeping yourself dealing primarily with HTML. Instead, you were forced to use bizarre js import systems. And at that point you were in JS land. F…
What's the point though to bake that into HTML if you need tons of JavaScript to make it happen anyway? You can just as well use the flexibility of JavaScript to build up component graphs. HTML, or rather SGML, has an established method of syntactically composing fragments using SGML entities that is well integrated into the process of editing HTML using plain text editors, not to speak of extending the vocabulary wi…
Because with HTML you would use HTML to structure your elements. Javascript was never designed to structure element s we get things like JSX, to compensate, adding further complexity. HTML Imports was an attempt to keep with the existing platform.
Re: The Failed Promise of Web Components
#207Earlier quoted context omitted.
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.
That is really a great website. Why didn't you built that site with HTML? Just check the stats here: https://perf-track.web.app/react
It’s not a static site.
Type “dir” in the header (or other activities in the “cool-stuff” post).
Moreover, I can build anything I want very quickly - with great engineering - and still get performance comparable to a static site.
Re: The Failed Promise of Web Components
#208Earlier quoted context omitted.
Ok, here it is https://ricklove.me Here is a post that explains some of the content that is interesting: https://ricklove.me/cool-stuff Let me know how it does on a slow connection.
I'm quite sad that hunter2 isn't in your passwords.txt
Good idea :) I’ll add that.
I guess I’ll know if someone finds the Bitcoin.
Update: I added a few more nerd lore passwords - thanks for the idea!
Re: The Failed Promise of Web Components
#209Earlier quoted context omitted.
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.
Ok, here it is https://ricklove.me Here is a post that explains some of the content that is interesting: https://ricklove.me/cool-stuff Let me know how it does on a slow connection.
It took 30s to 60s to fully load, but the content was available very quickly. The most entertaining thing was the stripe example. I didn’t realize it was supposed to load the card form, so I hit subscribe and it caused an error (because the card form wasn’t loaded yet) but the app handled it appropriately. It would be better if the subscribe button were disabled before the component loaded (which took at least a minute), but it’s still pretty good.
Overall, it was a very refreshing experience.
Re: The Failed Promise of Web Components
#210Earlier quoted context omitted.
Ok, here it is https://ricklove.me Here is a post that explains some of the content that is interesting: https://ricklove.me/cool-stuff Let me know how it does on a slow connection.
It took 30s to 60s to fully load, but the content was available very quickly. The most entertaining thing was the stripe example. I didn’t realize it was supposed to load the card form, so I hit subscribe and it caused an error (because the card form wasn’t loaded yet) but the app handled it appropriately. It would be better if the subscribe button were disabled before the component loaded (which took at least a minu…
Ah, makes sense on the stripe component.
I did notice that for some components I need to show a loading indicator while they are loading async (for a slow connection).
Thanks for letting me know!