13 ms·

What We Need Instead of "Web Components"

132 points by nalgeon 3y ago

facu17y 3y ago
Browser vendors are (or should be) managing the abstractions for their own needs, with developer needs expected to be met by framework/library developers. Who says web components are meant for use directly by the developer? Maybe they're primarily meant for the browser developers (those who build browser features), not for use directly by web app developers.
- WA 3y ago
  No. Browser vendors implement specs, defined by the W3C. To quote the W3C‘s tagline: > The World Wide Web Consortium (W3C) develops standards and guidelines to help everyone build a web based on the principles of accessibility, internationalization, privacy and security. Web Components are a standard to be used by web devs.
  - kabes 3y ago
    And who defines the W3C specs? Browser vendors! And if they don't agree with the non browser vendors within W3C, they create another standard org (WHATWG).
  - lloydatkinson 3y ago
    Anyone not under a rock knows W3C simply copies whatever WHATWG come up with and then stamp W3C on it.
    - pests 3y ago
      Kind of the point. WHATWG is descriptive not prescriptive. It describes things as they are. W3C is a standards body, sometimes they use the existing solutions and standardize them.
  - tannhaeuser 3y ago
    FYI: the last time W3C, Inc. endorsed a WHATWG HTML snapshot as a recommendation was in 2021 ([1]), for the WHATWG snapshot published January, 2020 whereas the 2021 and 2022 snapshots were rejected, with no new review process having started since. Reasons for rejection include a reporting API seen as privacy-invading and related disagreement over whether W3C's HTML WG could augment/redact WHATWG spec text like they used to be doing until 2017 when the previous HTML recommendation was published, or has to go through WHATWG process for any change according to the W3C/WHATWG "memorandum of understanding" which thus hasn't resulted in common understanding after all ;) Another reason was objection against the so-called HTML5 outlining algorithm, which Steve Faulkner actually has gone to great lenghts removing in WHATWG HTML upstream (cf. [2] for details). Unfortunately, the removal also brought incompatible change to HTML (the content model of hgroup, among other incompatibilities), rendering existing content invalid, which WHATWG set out not to be doing but which they lack the methodology of preventing and for which the spec derived from Ian Hickson's work frankly lacks formal qualities to support. Even more unfortunate is that this change has already spilled to derived standards such as EPUB3 which hence makes existing EPUB3 content using compound headings going back to 2011 invalid, and EPUB3 writers lacking a tool for actually verifying what readers can support (epubcheck was blindly updated without consideration for the installed base). Technically, Review Draft January 2022 and newer should then already be called HTML 6. Since nobody gives a rat's ass (including W3C, Inc.'s dormant HTML WG) anyway, and gross misconceptions about HTML specs prevail, like in your post, I'm not sure whether we should call it a day with WHATWG/W3C's HTML specs already. [1]: https://www.w3.org/blog/2021/whatwg-review-drafts-of-html-and-dom-endorsed-as-w3c-recommendations/ https://www.w3.org/blog/2021/whatwg-review-drafts-of-html-an... [2]: https://sgmljs.net/blog/blog2303.html https://sgmljs.net/blog/blog2303.html
- troupo 3y ago
  > with developer needs expected to be met by framework/library developers. You can't implement stuff efficiently if there's no required functionality in the platform > Who says web components are meant for use directly by the developer? The people who develop them
- austin-cheney 3y ago
  This is why I abandoned my career writing JavaScript. It’s an industry of people hopelessly in need of frameworks and tools to do their job for them because they cannot program.
  - baz00 3y ago
    Yes that. Lines up with the meme going around. They call me 007. 0 coding skills. 0 social skills. 7 Udemy certificates.
  - jeroenhd 3y ago
    I think that's unfair. There are a lot of Javascript programmers that are perfectly competent. Unfortunately, the trash "become a programmer in three days" bootcamps and scam courses all target web development, flooding the market with people who were taught one or two tricks and told they're the cream of the crop and should definitely not ask for their money back if nobody wants to hire them. It's the same problem PHP and Python have suffered from: when your programming language and API is accessible and easy to use, you'll attract a lot of beginners and people who skipped the hard parts. For some reason, the frontend world seems intent on reinventing itself every five years or so. The backend world works in cycles of 10 to 20 years, but it's going through the same motions. Everything became C, then C++ and Delphi came along, then everything became Java and DotNet, mow everything is becoming Go and Rust, and every iteration brings about new design concepts and paradigms.
    - austin-cheney 3y ago
      Find me common JavaScript employment without use of a framework or to merely put text on screen and you will prove me wrong.
      - jeroenhd 3y ago
        What business doesn't use some kind of framework, even for the backend? I've never heard of a successful business building everything from scratch, usually you'll have something like Qt for GUI construction, or Django/Ktor/ASP.NET for a web server. I believe Wikipedia uses mostly frameworkless Javascript, but, as you might expect from any sufficiently sized project, they have come up with their own frameworks instead.
DeathArrow 3y ago
Do we need text (HTML is text) and Javascript? Why can't be browsers used only to run native binary apps? Wouldn't that be more efficient? And even easier to develop for?
- 8organicbits 3y ago
  WebAssembly already exists. It's easier for certain use cases, but not most. It gives good performance, but worse than native software outside the browser.
  - wewxjfq 3y ago
    WebAssembly only gives better performance for things that shouldn't be done in the UI main-thread. As long as you don't do number crunching in the mouse move event handler, I doubt WebAssembly can beat vanilla JavaScript for reactive UIs.
    - flohofwoe 3y ago
      Once you work with the DOM, the (small) overhead of calling from WASM into a JS shim or any performance difference between WASM and JS doesn't matter. The internal DOM implementation will dominate the performance profile unless you do really dumb things.
  - pjmlp 3y ago
    And after a decade the tooling still sucks, comparing with the development experience of native code.
    - flohofwoe 3y ago
      That's why you develop and debug a native target, and then just flip a build system option to compile to WASM, it's really not much different from regular cross-compiling. (DWARF debugging in VSCode is now actually possible via https://marketplace.visualstudio.com/items?itemName=ms-vscode.wasm-dwarf-debugging https://marketplace.visualstudio.com/items?itemName=ms-vscod..., but the native debugging workflow still makes more sense, unless you need to debug the WASM-specific parts of the code)
troupo 3y ago
I agree with all the points, and I want to add that all the effort and literally hundreds of millions of dollars spent on web components could be spent more wisely by: - actually listening to developers and looking at how the space develops instead of chasing own vanity projects. Literally the extensible web manifesto many authors of web components espoused and then completely forgot. - putting more effort into https://open-ui.org/ https://open-ui.org/ (somewhat ironically created and originally driven by Microsoft, of all orgs)
- zer00eyz 3y ago
  >> actually listening to developers and looking at how the space develops instead of chasing own vanity projects. This is what WHATWG is. It is also why everything is "worse" and "better" than when it was just the w3c. I don't think we have had clear, cohesive, design intent for the front end/browser in more than a decade, and it isn't getting better. I spent years working in PHP, and my life is better in Go and C... I would rather work in circa 2004 PHP code than what modern JS looks like. The whole stack of framework, tooling, linting/ts, node/bun, build/transpile... SO. Many. Dependencys... I had a 10 minute conversation on what the fuck a "thunk" is and why I would want to use it yesterday, this is the front end of 2023/4 And I give credit to front end engineers for keeping it all going, frankly there isn't enough cocaine in Columbia to get me to do it. But I'm not sure any of the people who think that this is OK or its how to build a web page are the ones we should be letting ADD features to a stack we want to be backwards compatible. Its how we end up with stray stuff like web components and shadow dom that never live up to the promise and then we drag them around for the rest of time cause space jam and what ever comes after still needs to render. I'm gonna go back to the back end, I would rather face down the expensive foot gun of autoscaling than risk my sanity working in the front end.
  - Izkata 3y ago
    > I had a 10 minute conversation on what the fuck a "thunk" is and why I would want to use it yesterday, this is the front end of 2023/4 I believe I remember hearing thunks were old-school and nowadays it should be done with sagas... Like 4-5 years ago.
  - 3y ago
Vinnl 3y ago
While I agree with the general gist of the article (and please, yes, it seems like a minor thing, but give us resizable iframes), except that "reactivity" does not meet the bar of developers collectively having landed on a solution to a common problem. There are a couple of frameworks with similar, but different, approaches to it, and yet none of them is truly widespread. I'm very sceptical that standardisation would hit the right mark at this point in time. But yes, that is basically what we saw with Web Components. People took drew the wrong conclusions about what problems React solved ("everything is a component"), and then tried to retrofit Web Components as a native solution to the problem - with the added assumption that just because it was built-in, it was better.
- aatd86 3y ago
  Agreed. It's true that reactivity is needed but I also don't think it's time to standardize yet. There has already been attempts in the past too such as mutation observers. Too early.
- azangru 3y ago
  > except that "reactivity" does not meet the bar of developers collectively having landed on a solution to a common problem Now that everyone seems to be in love with signals, there is work going on in the web components community group to prepare a spec for a signal (or observable, not sure what they are trying to call it) primitive [0]. It seems that they are getting ready to bring it to TC39 as a proposal. (In the meantime, the Observable primitive from rxjs has been given a go-ahead for browser implementation. There is a proposal ready [1], and I think I heard that it may already be in Chrome behind a flag [2]). So yeah; it's gonna be fun. Especially if both groups call their primitive Observable :-) 0 - https://github.com/webcomponents-cg/community-protocols/issues/43 https://github.com/webcomponents-cg/community-protocols/issu... 1 - https://github.com/WICG/observable https://github.com/WICG/observable 2 - https://nitter.net/BenLesh/status/1737174784406933599 https://nitter.net/BenLesh/status/1737174784406933599
  - jauntywundrkind 3y ago
    I'm pretty stressed out about the proliferation of standards here. It's indistinct to me why we need so many ways of hearing about a new thing; they seem the same general idea, but everyone has some insular notion, it feels like, and I don't get the value add, don't get why we'd have another. We already have a streams API that tells us of new things. Adding observables, adding signals, feels like a lot of totally different ideas that do mostly the same thing. What is missing from streams to make it cover these other cases? I suspect not a lot. But these are isolated cultures each possessed of their own idea, their own mentality, and there's not much binding glue forces to pull these disparate worlds together, even though it feels like the overlap is overwhelming. I feel like we are making a huge mistake letting these people chip more shit into the language, that we gain only more modes that don't work with each other. I love these communities, but not like this.
QuentinCh 3y ago
[dead]
- Erazal 3y ago
  big fan of any work in this area - just checked out your website might use it for our company
eviks 3y ago
> This is the ideal scenario for the evolution of the web: developers worked collectively over a series of years The ideal scenario is when you design something well so that you don't need to waste a series of year of that collective work solving for the lack of design
- sfn42 3y ago
  That's the unrealistic ideal.
  - jauntywundrkind 3y ago
    Big Cathedral philosophy. Someone just build it right! Kick ass build big and make it excellent! Just trust that one gal and let them soar! Versus Bazaar mentality. It takes time. Let there be a competition of ideas. Figure out strengths and weaknesses over time. Adapt and keep building better. You see this soooo much in the anti-Wayland troll-camps. That the idea isn't fully sprung meeting every need in every way is a huge fault, is unforgivable. The slow integration of ideas has been going to slow, and the Wayland protocol folks have finally recently started admitting it; they have a point. But being an official protocol is not the be all end all. So much protocol development has been just one camp, then two camps. That organic spread has been so beautiful, has allowed both innovation & deliberation at the same time. But people expect a world of consumer software, where someone has made all the decisions and now we're there, and we live with it. The Cathedral and it's authority & singularness appeals to so many, is closest to the rest of the world & commercial software. But the Bazaar has many advantages, has a cautiousness & explorativeness that hopefully delivers, long term.
mjburgess 3y ago
With the addition of a jsx syntax to js, they'd make more sense. Presently, if I have something for the web to create I have a set of component files, and, const tpl = (id, title) => html`<div id="${id}"><h1>${title}</h1></div>`; export default class extends HTMLElement { connectedCallback() { const t = tpl(this.getAttribute...); t.onclick ... //t is now a dom node this.replaceChildren(tpl); } } with additional simple component-specific helper functions defined in the file, after the class export -- I find this is covering all of what I need. And I think it's what's most basic apps need: a way of seamlessly moving between html/js reprs, and a way of seamlessly composing templates. It's an incredibly weird way of solving some strange fraction of the problem. But combining it with es6 modules, with string template processors, and so on -- you can create a really simple system of components.
- pjmlp 3y ago
  You just reinvented lit.
  - mjburgess 3y ago
    actually, looking at it (https://lit.dev/ https://lit.dev/), i do exactly that. I also define a `render()` and extend my own parent, which does a `replaceChildren()` with the render. And, strangely, I also call the processor `html` I'll still stick with mine however, my 'framework' is half-page of code. I dislike dependencies greatly. I'd need to be saving thousand+ lines at least. Here, I don't want a build system to make a website; that's mad. So I don't want lit. I want the 5 lines it takes to invoke a dom parser, and the 5 lines it takes do define a webcomp parent. It seems all these frameworks invent abstractions on top of how the browser works ('reactive properties', etc.) -- i'd prefer just writing code that works according to the abstractions inherent in the tool -- not half-baked ones invented by a framework author.
    - troupo 3y ago
      > i'd prefer just writing code that works according to the abstractions inherent in the tool -- not half-baked ones invented by a framework author. The abstractions in the browser are extremely bad, and you have to be very careful coding around them to get good performance out of them. But by that time you will hve invented your own framework.
selectnull 3y ago
I really don't understand the hate for Web Components (this article is certainly not the first one to hate on it). To me, WebComponents are great (as far as anything related to the web can be). Let's say you need a custom favorite/like button in your app? Cool, define `<myapp-like>` tag with `customElements.define('myapp-like', MyAppLike)` and `class MyAppLike extends HTMLElement {}` gives you a way to really make it work for you. It works in any modern browser (I've been using it natively for 2 years now). It works in React, Vue, Solid, whatever... because it doesn't care for your frontend or backend stack the same way that you use `<div>` anywhere. In my case, I'm using web components natively and with Lit framework. Very happy with the choice. And yes, web components are not the solution for everything. Semantic tags? Nope, it doesn't work that way.
- troupo 3y ago
  > I really don't understand the hate for Web Components (this article is certainly not the first one to hate on it). - They completely ignore any and all developments in the user space - They are bad for any of their stated purposes (of which there have been several) - They require complex specs that make the platform more and more brittle, and impossible to reason about or implement. Most of those specs exists only because web components are so poorly designed they introduce problems no other tech in the space has. - After over a decade in development they still need 20 more complex web specs to fix issues that, again, no one else has: https://w3c.github.io/webcomponents-cg/2022.html https://w3c.github.io/webcomponents-cg/2022.html And yes, this list only appeared in 2022 because it took the people who push them 10 years to finally come together and discuss what is needed to mark them as more-or-less complete They will claim that "web coponents is 'use the platform'" even though it's trivial to show that web components are the worst citizens on said platform. I can't think of any tech that has been as ill-suited to the platform as web components [1] - The previous bullet point exists because the entire development has been purely ad-hoc haphazard "we'll fix issues later" by people who continuously make a suprised pikachu face when stuff doesn't work even in the most simplest of scenarios that others have pointed out from miles away. - Don't forget the complete arrogance of most people driving all this. They will deflect and ignore all questions and criticism, they will blame you, users, React, God, or anyone for not understanding their grand vision (that they themselves cannot explain) and for not using this. They will stoop as low as borderline gaslight even the people who work with them on developing this (reading through discussions on Constructible Stylesheets made me lose faith in humanity) --- [1] https://threadreaderapp.com/thread/1717580502280867847.html https://threadreaderapp.com/thread/1717580502280867847.html
jackhalford 3y ago
I’m new to the webdev game, been doing mostly cloud and infra so the fast moving pace of js is dizzying. But recently I’ve been working with webcomponents in alpinejs, coupled with tailwindcss means I’m writing mostly html, breaking out to js for special cases only.
morrvs 3y ago
Thanks for this, gives my intuition some words to back it up! I find especially compelling how the author separates concrete problems like reconciliation (hard to argue against) from the abstract principle of "everything should be a component" (can be argued more easily IMO). Shamelessly plugging https://github.com/morris/vanilla-todo https://github.com/morris/vanilla-todo here; in this try-hard-to-stay-vanilla case study there are similar conclusions: Reconciliation is hard, CSS global namespace is problematic, etc. - I also did not use web components, but could not explain/justify that decision well (until now!).
oknoorap 3y ago
Since we are talking about web components, I just drop my web-components-based framework here: https://realm.codes https://realm.codes
- dtagames 3y ago
  What great looking documentation! A very nice site.
brainzap 3y ago
What shocked me to find out that web components start to replace the input field. And my tooling broke.
DonHopkins 3y ago
>... and you get all the benefits of Shadow DOM with none of the goth language about “light DOM styles piercing the shadow root” and whatnot. Goth Talk! https://www.youtube.com/watch?v=wR2dsEZv578 https://www.youtube.com/watch?v=wR2dsEZv578 Let's have a funeral to mourn the Loss of the Living Web Components!
zubairq 3y ago
Really good points, let browsers implement natively what developers are already doing
sleepyhead 3y ago
> Custom elements aren’t “semantic” because search engines don’t know what they mean. Lots of good points in this article but I don't think this is an issue. IMHO custom elements shouldn't be used to define content, we have standard elements for that, it should be used for rich interactive components. For example a datepicker. If there is content in the element then I do not see how search engines would interpret it any different than a normal div, or even better the custom elements should define content appropriately such as <my-component><article>text</>
proc0 3y ago
I can't help but feel web dev is reinventing the wheel when it comes to UI. It's basically game, there is a game loop, and all the actors/components may need updating on every frame. I'm not saying websites should be done in Unreal (although it's possible but probably overkill), but the patterns and abstractions in single page interactive applications has a lot to learn from patterns in game engines.
- ath92 3y ago
  That “game loop” exists in the browser too. It’s just the main event loop, and it’s been there since the inception of JavaScript. Not saying everything that web developers aren’t reinventing the wheel, but I think the reason for it isn’t a lack of tools, it’s a combination of poor ergonomics of the existing tools and (perhaps more importantly) people not understanding those tools and building frameworks for things that are included by default.
  - proc0 3y ago
    That's mainly my point. The browser is the game engine, the web app is a game running it, but the way UI interactivity, components, etc, are abstracted in such a way that the tools end up creating a lot of problems instead of solving them. It's hard to summarize in short form but I think tools would be much better if the underlying abstraction was better. HTML and CSS is a crude way of specifying elements rendering in a viewport, and its main usefulness is really in the past when computers were much less powerful.
- kaba0 3y ago
  That’s hardly the whole picture. There are endless possibilities within that - e.g. the design of a text editor will look nothing like that of an AAA game’s ECS.
  - proc0 3y ago
    Text editor is probably not the best example. I'm thinking of the typical web app with "data lifecycle" as the article calls it, where there is rich interactivity and content is updated frequently based on interactions. In those cases you have components listening on local and global scope, updating of state, and updating of the rendering frame (handled by the browser).
epolanski 3y ago
My biggest beef with web components is actually the lack of "real" isolation. You still have shadow-piercing props and settings that will bite and break your components (font size is a simple example). If web components provided the kind of isolation that iframes provide I'd use them more. But so far my experiments into having a set of components I could easily reuse on different websites has failed.
fevangelou 3y ago
That's a great writeup. As someone who's worked primarily on news/media sites for the last 15 years, I can totally relate and agree on all your points. I would also argue that there are non-code issues that could easily be resolved. Bundling fonts for example. Decide on the top 100 with support for all or almost all characters, based on usage etc., and bundle them in the browser. That would shave possibly hundreds of KBs of each page's size. On the flip side, stuff like lazy loading could become standard and use the attribute only to force-load content. Or stuff that is used on every freaking site (eg togglers as native html tags). I'm hopeful though.

132 points by nalgeon 3y ago

Browser vendors are (or should be) managing the abstractions for their own needs, with developer needs expected to be met by framework/library developers. Who says web components are meant for use directly by the developer? Maybe they're primarily meant for the browser developers (those who build browser features), not for use directly by web app developers.

WA 3y ago
No. Browser vendors implement specs, defined by the W3C. To quote the W3C‘s tagline: > The World Wide Web Consortium (W3C) develops standards and guidelines to help everyone build a web based on the principles of accessibility, internationalization, privacy and security. Web Components are a standard to be used by web devs.
- kabes 3y ago
  And who defines the W3C specs? Browser vendors! And if they don't agree with the non browser vendors within W3C, they create another standard org (WHATWG).
- lloydatkinson 3y ago
  Anyone not under a rock knows W3C simply copies whatever WHATWG come up with and then stamp W3C on it.
  - pests 3y ago
    Kind of the point. WHATWG is descriptive not prescriptive. It describes things as they are. W3C is a standards body, sometimes they use the existing solutions and standardize them.
- tannhaeuser 3y ago
  FYI: the last time W3C, Inc. endorsed a WHATWG HTML snapshot as a recommendation was in 2021 ([1]), for the WHATWG snapshot published January, 2020 whereas the 2021 and 2022 snapshots were rejected, with no new review process having started since. Reasons for rejection include a reporting API seen as privacy-invading and related disagreement over whether W3C's HTML WG could augment/redact WHATWG spec text like they used to be doing until 2017 when the previous HTML recommendation was published, or has to go through WHATWG process for any change according to the W3C/WHATWG "memorandum of understanding" which thus hasn't resulted in common understanding after all ;) Another reason was objection against the so-called HTML5 outlining algorithm, which Steve Faulkner actually has gone to great lenghts removing in WHATWG HTML upstream (cf. [2] for details). Unfortunately, the removal also brought incompatible change to HTML (the content model of hgroup, among other incompatibilities), rendering existing content invalid, which WHATWG set out not to be doing but which they lack the methodology of preventing and for which the spec derived from Ian Hickson's work frankly lacks formal qualities to support. Even more unfortunate is that this change has already spilled to derived standards such as EPUB3 which hence makes existing EPUB3 content using compound headings going back to 2011 invalid, and EPUB3 writers lacking a tool for actually verifying what readers can support (epubcheck was blindly updated without consideration for the installed base). Technically, Review Draft January 2022 and newer should then already be called HTML 6. Since nobody gives a rat's ass (including W3C, Inc.'s dormant HTML WG) anyway, and gross misconceptions about HTML specs prevail, like in your post, I'm not sure whether we should call it a day with WHATWG/W3C's HTML specs already. [1]: https://www.w3.org/blog/2021/whatwg-review-drafts-of-html-and-dom-endorsed-as-w3c-recommendations/ https://www.w3.org/blog/2021/whatwg-review-drafts-of-html-an... [2]: https://sgmljs.net/blog/blog2303.html https://sgmljs.net/blog/blog2303.html
troupo 3y ago
> with developer needs expected to be met by framework/library developers. You can't implement stuff efficiently if there's no required functionality in the platform > Who says web components are meant for use directly by the developer? The people who develop them
austin-cheney 3y ago
This is why I abandoned my career writing JavaScript. It’s an industry of people hopelessly in need of frameworks and tools to do their job for them because they cannot program.
- baz00 3y ago
  Yes that. Lines up with the meme going around. They call me 007. 0 coding skills. 0 social skills. 7 Udemy certificates.
- jeroenhd 3y ago
  I think that's unfair. There are a lot of Javascript programmers that are perfectly competent. Unfortunately, the trash "become a programmer in three days" bootcamps and scam courses all target web development, flooding the market with people who were taught one or two tricks and told they're the cream of the crop and should definitely not ask for their money back if nobody wants to hire them. It's the same problem PHP and Python have suffered from: when your programming language and API is accessible and easy to use, you'll attract a lot of beginners and people who skipped the hard parts. For some reason, the frontend world seems intent on reinventing itself every five years or so. The backend world works in cycles of 10 to 20 years, but it's going through the same motions. Everything became C, then C++ and Delphi came along, then everything became Java and DotNet, mow everything is becoming Go and Rust, and every iteration brings about new design concepts and paradigms.
  - austin-cheney 3y ago
    Find me common JavaScript employment without use of a framework or to merely put text on screen and you will prove me wrong.
    - jeroenhd 3y ago
      What business doesn't use some kind of framework, even for the backend? I've never heard of a successful business building everything from scratch, usually you'll have something like Qt for GUI construction, or Django/Ktor/ASP.NET for a web server. I believe Wikipedia uses mostly frameworkless Javascript, but, as you might expect from any sufficiently sized project, they have come up with their own frameworks instead.

DeathArrow 3y ago

Do we need text (HTML is text) and Javascript? Why can't be browsers used only to run native binary apps? Wouldn't that be more efficient? And even easier to develop for?

8organicbits 3y ago
WebAssembly already exists. It's easier for certain use cases, but not most. It gives good performance, but worse than native software outside the browser.
- wewxjfq 3y ago
  WebAssembly only gives better performance for things that shouldn't be done in the UI main-thread. As long as you don't do number crunching in the mouse move event handler, I doubt WebAssembly can beat vanilla JavaScript for reactive UIs.
  - flohofwoe 3y ago
    Once you work with the DOM, the (small) overhead of calling from WASM into a JS shim or any performance difference between WASM and JS doesn't matter. The internal DOM implementation will dominate the performance profile unless you do really dumb things.
- pjmlp 3y ago
  And after a decade the tooling still sucks, comparing with the development experience of native code.
  - flohofwoe 3y ago
    That's why you develop and debug a native target, and then just flip a build system option to compile to WASM, it's really not much different from regular cross-compiling. (DWARF debugging in VSCode is now actually possible via https://marketplace.visualstudio.com/items?itemName=ms-vscode.wasm-dwarf-debugging https://marketplace.visualstudio.com/items?itemName=ms-vscod..., but the native debugging workflow still makes more sense, unless you need to debug the WASM-specific parts of the code)

troupo 3y ago

I agree with all the points, and I want to add that all the effort and literally hundreds of millions of dollars spent on web components could be spent more wisely by: - actually listening to developers and looking at how the space develops instead of chasing own vanity projects. Literally the extensible web manifesto many authors of web components espoused and then completely forgot. - putting more effort into https://open-ui.org/ https://open-ui.org/ (somewhat ironically created and originally driven by Microsoft, of all orgs)

zer00eyz 3y ago
>> actually listening to developers and looking at how the space develops instead of chasing own vanity projects. This is what WHATWG is. It is also why everything is "worse" and "better" than when it was just the w3c. I don't think we have had clear, cohesive, design intent for the front end/browser in more than a decade, and it isn't getting better. I spent years working in PHP, and my life is better in Go and C... I would rather work in circa 2004 PHP code than what modern JS looks like. The whole stack of framework, tooling, linting/ts, node/bun, build/transpile... SO. Many. Dependencys... I had a 10 minute conversation on what the fuck a "thunk" is and why I would want to use it yesterday, this is the front end of 2023/4 And I give credit to front end engineers for keeping it all going, frankly there isn't enough cocaine in Columbia to get me to do it. But I'm not sure any of the people who think that this is OK or its how to build a web page are the ones we should be letting ADD features to a stack we want to be backwards compatible. Its how we end up with stray stuff like web components and shadow dom that never live up to the promise and then we drag them around for the rest of time cause space jam and what ever comes after still needs to render. I'm gonna go back to the back end, I would rather face down the expensive foot gun of autoscaling than risk my sanity working in the front end.
- Izkata 3y ago
  > I had a 10 minute conversation on what the fuck a "thunk" is and why I would want to use it yesterday, this is the front end of 2023/4 I believe I remember hearing thunks were old-school and nowadays it should be done with sagas... Like 4-5 years ago.
- 3y ago

Vinnl 3y ago

While I agree with the general gist of the article (and please, yes, it seems like a minor thing, but give us resizable iframes), except that "reactivity" does not meet the bar of developers collectively having landed on a solution to a common problem. There are a couple of frameworks with similar, but different, approaches to it, and yet none of them is truly widespread. I'm very sceptical that standardisation would hit the right mark at this point in time. But yes, that is basically what we saw with Web Components. People took drew the wrong conclusions about what problems React solved ("everything is a component"), and then tried to retrofit Web Components as a native solution to the problem - with the added assumption that just because it was built-in, it was better.

aatd86 3y ago
Agreed. It's true that reactivity is needed but I also don't think it's time to standardize yet. There has already been attempts in the past too such as mutation observers. Too early.
azangru 3y ago
> except that "reactivity" does not meet the bar of developers collectively having landed on a solution to a common problem Now that everyone seems to be in love with signals, there is work going on in the web components community group to prepare a spec for a signal (or observable, not sure what they are trying to call it) primitive [0]. It seems that they are getting ready to bring it to TC39 as a proposal. (In the meantime, the Observable primitive from rxjs has been given a go-ahead for browser implementation. There is a proposal ready [1], and I think I heard that it may already be in Chrome behind a flag [2]). So yeah; it's gonna be fun. Especially if both groups call their primitive Observable :-) 0 - https://github.com/webcomponents-cg/community-protocols/issues/43 https://github.com/webcomponents-cg/community-protocols/issu... 1 - https://github.com/WICG/observable https://github.com/WICG/observable 2 - https://nitter.net/BenLesh/status/1737174784406933599 https://nitter.net/BenLesh/status/1737174784406933599
- jauntywundrkind 3y ago
  I'm pretty stressed out about the proliferation of standards here. It's indistinct to me why we need so many ways of hearing about a new thing; they seem the same general idea, but everyone has some insular notion, it feels like, and I don't get the value add, don't get why we'd have another. We already have a streams API that tells us of new things. Adding observables, adding signals, feels like a lot of totally different ideas that do mostly the same thing. What is missing from streams to make it cover these other cases? I suspect not a lot. But these are isolated cultures each possessed of their own idea, their own mentality, and there's not much binding glue forces to pull these disparate worlds together, even though it feels like the overlap is overwhelming. I feel like we are making a huge mistake letting these people chip more shit into the language, that we gain only more modes that don't work with each other. I love these communities, but not like this.

QuentinCh 3y ago

[dead]

Erazal 3y ago
big fan of any work in this area - just checked out your website might use it for our company

eviks 3y ago

> This is the ideal scenario for the evolution of the web: developers worked collectively over a series of years The ideal scenario is when you design something well so that you don't need to waste a series of year of that collective work solving for the lack of design

sfn42 3y ago
That's the unrealistic ideal.
- jauntywundrkind 3y ago
  Big Cathedral philosophy. Someone just build it right! Kick ass build big and make it excellent! Just trust that one gal and let them soar! Versus Bazaar mentality. It takes time. Let there be a competition of ideas. Figure out strengths and weaknesses over time. Adapt and keep building better. You see this soooo much in the anti-Wayland troll-camps. That the idea isn't fully sprung meeting every need in every way is a huge fault, is unforgivable. The slow integration of ideas has been going to slow, and the Wayland protocol folks have finally recently started admitting it; they have a point. But being an official protocol is not the be all end all. So much protocol development has been just one camp, then two camps. That organic spread has been so beautiful, has allowed both innovation & deliberation at the same time. But people expect a world of consumer software, where someone has made all the decisions and now we're there, and we live with it. The Cathedral and it's authority & singularness appeals to so many, is closest to the rest of the world & commercial software. But the Bazaar has many advantages, has a cautiousness & explorativeness that hopefully delivers, long term.

mjburgess 3y ago

With the addition of a jsx syntax to js, they'd make more sense. Presently, if I have something for the web to create I have a set of component files, and, const tpl = (id, title) => html`<div id="${id}"><h1>${title}</h1></div>`; export default class extends HTMLElement { connectedCallback() { const t = tpl(this.getAttribute...); t.onclick ... //t is now a dom node this.replaceChildren(tpl); } } with additional simple component-specific helper functions defined in the file, after the class export -- I find this is covering all of what I need. And I think it's what's most basic apps need: a way of seamlessly moving between html/js reprs, and a way of seamlessly composing templates. It's an incredibly weird way of solving some strange fraction of the problem. But combining it with es6 modules, with string template processors, and so on -- you can create a really simple system of components.

pjmlp 3y ago
You just reinvented lit.
- mjburgess 3y ago
  actually, looking at it (https://lit.dev/ https://lit.dev/), i do exactly that. I also define a `render()` and extend my own parent, which does a `replaceChildren()` with the render. And, strangely, I also call the processor `html` I'll still stick with mine however, my 'framework' is half-page of code. I dislike dependencies greatly. I'd need to be saving thousand+ lines at least. Here, I don't want a build system to make a website; that's mad. So I don't want lit. I want the 5 lines it takes to invoke a dom parser, and the 5 lines it takes do define a webcomp parent. It seems all these frameworks invent abstractions on top of how the browser works ('reactive properties', etc.) -- i'd prefer just writing code that works according to the abstractions inherent in the tool -- not half-baked ones invented by a framework author.
  - troupo 3y ago
    > i'd prefer just writing code that works according to the abstractions inherent in the tool -- not half-baked ones invented by a framework author. The abstractions in the browser are extremely bad, and you have to be very careful coding around them to get good performance out of them. But by that time you will hve invented your own framework.

selectnull 3y ago

I really don't understand the hate for Web Components (this article is certainly not the first one to hate on it). To me, WebComponents are great (as far as anything related to the web can be). Let's say you need a custom favorite/like button in your app? Cool, define `<myapp-like>` tag with `customElements.define('myapp-like', MyAppLike)` and `class MyAppLike extends HTMLElement {}` gives you a way to really make it work for you. It works in any modern browser (I've been using it natively for 2 years now). It works in React, Vue, Solid, whatever... because it doesn't care for your frontend or backend stack the same way that you use `<div>` anywhere. In my case, I'm using web components natively and with Lit framework. Very happy with the choice. And yes, web components are not the solution for everything. Semantic tags? Nope, it doesn't work that way.

troupo 3y ago
> I really don't understand the hate for Web Components (this article is certainly not the first one to hate on it). - They completely ignore any and all developments in the user space - They are bad for any of their stated purposes (of which there have been several) - They require complex specs that make the platform more and more brittle, and impossible to reason about or implement. Most of those specs exists only because web components are so poorly designed they introduce problems no other tech in the space has. - After over a decade in development they still need 20 more complex web specs to fix issues that, again, no one else has: https://w3c.github.io/webcomponents-cg/2022.html https://w3c.github.io/webcomponents-cg/2022.html And yes, this list only appeared in 2022 because it took the people who push them 10 years to finally come together and discuss what is needed to mark them as more-or-less complete They will claim that "web coponents is 'use the platform'" even though it's trivial to show that web components are the worst citizens on said platform. I can't think of any tech that has been as ill-suited to the platform as web components [1] - The previous bullet point exists because the entire development has been purely ad-hoc haphazard "we'll fix issues later" by people who continuously make a suprised pikachu face when stuff doesn't work even in the most simplest of scenarios that others have pointed out from miles away. - Don't forget the complete arrogance of most people driving all this. They will deflect and ignore all questions and criticism, they will blame you, users, React, God, or anyone for not understanding their grand vision (that they themselves cannot explain) and for not using this. They will stoop as low as borderline gaslight even the people who work with them on developing this (reading through discussions on Constructible Stylesheets made me lose faith in humanity) --- [1] https://threadreaderapp.com/thread/1717580502280867847.html https://threadreaderapp.com/thread/1717580502280867847.html

jackhalford 3y ago

I’m new to the webdev game, been doing mostly cloud and infra so the fast moving pace of js is dizzying. But recently I’ve been working with webcomponents in alpinejs, coupled with tailwindcss means I’m writing mostly html, breaking out to js for special cases only.

morrvs 3y ago

Thanks for this, gives my intuition some words to back it up! I find especially compelling how the author separates concrete problems like reconciliation (hard to argue against) from the abstract principle of "everything should be a component" (can be argued more easily IMO). Shamelessly plugging https://github.com/morris/vanilla-todo https://github.com/morris/vanilla-todo here; in this try-hard-to-stay-vanilla case study there are similar conclusions: Reconciliation is hard, CSS global namespace is problematic, etc. - I also did not use web components, but could not explain/justify that decision well (until now!).

oknoorap 3y ago

Since we are talking about web components, I just drop my web-components-based framework here: https://realm.codes https://realm.codes

dtagames 3y ago
What great looking documentation! A very nice site.

brainzap 3y ago

What shocked me to find out that web components start to replace the input field. And my tooling broke.

DonHopkins 3y ago

>... and you get all the benefits of Shadow DOM with none of the goth language about “light DOM styles piercing the shadow root” and whatnot. Goth Talk! https://www.youtube.com/watch?v=wR2dsEZv578 https://www.youtube.com/watch?v=wR2dsEZv578 Let's have a funeral to mourn the Loss of the Living Web Components!

zubairq 3y ago

Really good points, let browsers implement natively what developers are already doing

sleepyhead 3y ago

> Custom elements aren’t “semantic” because search engines don’t know what they mean. Lots of good points in this article but I don't think this is an issue. IMHO custom elements shouldn't be used to define content, we have standard elements for that, it should be used for rich interactive components. For example a datepicker. If there is content in the element then I do not see how search engines would interpret it any different than a normal div, or even better the custom elements should define content appropriately such as <my-component><article>text</>

proc0 3y ago

I can't help but feel web dev is reinventing the wheel when it comes to UI. It's basically game, there is a game loop, and all the actors/components may need updating on every frame. I'm not saying websites should be done in Unreal (although it's possible but probably overkill), but the patterns and abstractions in single page interactive applications has a lot to learn from patterns in game engines.

ath92 3y ago
That “game loop” exists in the browser too. It’s just the main event loop, and it’s been there since the inception of JavaScript. Not saying everything that web developers aren’t reinventing the wheel, but I think the reason for it isn’t a lack of tools, it’s a combination of poor ergonomics of the existing tools and (perhaps more importantly) people not understanding those tools and building frameworks for things that are included by default.
- proc0 3y ago
  That's mainly my point. The browser is the game engine, the web app is a game running it, but the way UI interactivity, components, etc, are abstracted in such a way that the tools end up creating a lot of problems instead of solving them. It's hard to summarize in short form but I think tools would be much better if the underlying abstraction was better. HTML and CSS is a crude way of specifying elements rendering in a viewport, and its main usefulness is really in the past when computers were much less powerful.
kaba0 3y ago
That’s hardly the whole picture. There are endless possibilities within that - e.g. the design of a text editor will look nothing like that of an AAA game’s ECS.
- proc0 3y ago
  Text editor is probably not the best example. I'm thinking of the typical web app with "data lifecycle" as the article calls it, where there is rich interactivity and content is updated frequently based on interactions. In those cases you have components listening on local and global scope, updating of state, and updating of the rendering frame (handled by the browser).

epolanski 3y ago

My biggest beef with web components is actually the lack of "real" isolation. You still have shadow-piercing props and settings that will bite and break your components (font size is a simple example). If web components provided the kind of isolation that iframes provide I'd use them more. But so far my experiments into having a set of components I could easily reuse on different websites has failed.

fevangelou 3y ago

That's a great writeup. As someone who's worked primarily on news/media sites for the last 15 years, I can totally relate and agree on all your points. I would also argue that there are non-code issues that could easily be resolved. Bundling fonts for example. Decide on the top 100 with support for all or almost all characters, based on usage etc., and bundle them in the browser. That would shave possibly hundreds of KBs of each page's size. On the flip side, stuff like lazy loading could become standard and use the attribute only to force-load content. Or stuff that is used on every freaking site (eg togglers as native html tags). I'm hopeful though.