17 ms·

Web components will outlive JavaScript frameworks

310 points by cdme 3y ago

diob 3y ago
But will the JavaScript Framework I'm using outlive my application? Most folks would answer yes I think. The lifetime of apps is surprisingly short.
- EliasToft 3y ago
  I dont know about that. The very first project I worked on after graduating is still very much alive last I checked, and I was actually promised that it should only have a lifetime of a few years as it was an incredible fast developed prototype - the feature set and scope considering. I actually left the company because we were two devs and the owner of the company constantly wanted us to work on new features instead of improving the foundation of the obviosuly rushed prototype, but here we are almost 15 years later and the core of it is pretty much still the same thing as when I left (SaaS).
  - namtab00 3y ago
    I've recently found out stuff I've built 16 years ago, in ColdFusion and Classic ASP (anybody remember Macromedia Dreamweaver, later Adobe?) is still in use, never mind more "recent" WebForms + jquery stuff...
deleted 3y ago
[deleted]
very_good_man 3y ago
Is this a joke? html and css as one big JS string?
- hyperhello 3y ago
  Well, yea. All pointless frameworking is based on the fact that HTML doesn’t natively nest in other HTML or natively color in JavaScript editors. So we have ridiculous bloat, when that was all we had to fix: the ability to put HTML in JavaScript in a satisfyingly official way. Instead, we have everything in fragments that have to be mechanically transformed, and fight over which giant IDE is best.
punyearthling 3y ago
web components are nice, but not perfect and i get tired of web component proponents neglecting to mention the trade-offs when using them. enabling shadow DOM renders that component completely inaccessible to users using assistive tech like screen readers. without a shadow DOM enabled, you lose the encapsulation benefit devs seem to love. js framework components, for all their faults, can at least be accessible. i just don't think web components are quite there yet.
franciscop 3y ago
Which web components, the ones that were deprecated and no browser implements anymore? Ah wait no, you mean the new ones that virtually no one uses, right? While the point of view that ESM and DOM APIs live long-term is pretty good, the specific example is maybe the most infamous for how not true this has been and many call web components Dead On Arrival. Newer technology on the web does break more often than old JS (maybe, Flash?), for example I have a project that for security reasons doesn't work anymore, Cookies famously also had a big change for security like that, fetch() defaults changed, and AFAIK even performance.now() was capped for Spectre.
- fassssst 3y ago
  Bing Chat is built entirely with Web Components. (I work at Microsoft on it. You can verify with F12.)
  - tuzemec 3y ago
    AFAIK - also the browser version of Photoshop.
    - spankalee 3y ago
      And Chrome OS, Firefox, Reddit, Internet Archive, YouTube, and a long list of others...
      - franciscop 3y ago
        I checked a couple of those quickly; Reddit doesn't seem to use web components at all? https://imgur.com/a/kzLoGnV https://imgur.com/a/kzLoGnV Youtube seems to use 1 web component for every 10 normal components, which is fair: https://imgur.com/a/YIBhLh8 https://imgur.com/a/YIBhLh8
        megaman821 3y ago
        Reddit has a whole other site if you go there without being logged in. That one is built with web components.
gedy 3y ago
Maybe, but while I love UI components, I really dislike that "web components" conflate and combine multiple things like custom elements, and shadow DOM, etc. So working with them in real apps, you get a mess of opinions and assumptions like completely isolated styles (no I don't want this! let me use my site's Bootstrap theme!), etc. Also dealing with string-based attributes/props is a pain. I greatly prefer React/Svelte/Vue for not having to deal with all this.
- zaphar 3y ago
  It's an umbrella term for a set of technologies. Each of them can be used in isolation from the others if you want though. You don't have to use shadow DOM if you don't want it. You don't have to use custom elements if you don't want to either. You are correct though that almost every tool that works with them sort of assumes you are going to use both.
  - tuzemec 3y ago
    I kinda like this approach. You can change the combination of used APIs for different cases. "Widget" that you provide for partners to put on their web pages? Of course you'll use shadow DOM, because you don't know the page context, surrounding styles, etc. A component to share on different parts of your site - you can skip the shadow DOM, because you share common styles everywhere, and probably you want to inherit some of them.
    - zaphar 3y ago
      I think in terms of the implementation keeping them separate and composable is very useful. I think the marketing around it could have emphasized it a little more but that's water under the bridge really.
- jjcm 3y ago
  It's fairly easy to choose between style isolation and no style isolation though. Just change the `this.shadow.innerHTML` in the render to `this.innerHTML`. The encapsulation aspect provides some really nice benefits in many scenarios, so having the option of this is quite nice. A classic example of why this is beneficial is when creating design system components - you typically want these to not be affected by styling on the page, and if you do want them to be styled, you only want them to be styled in specific ways which you can build in via css custom property values (see the accent example the author provides).
ramesh31 3y ago
They will also require a cobbled together list of dependencies to make useful, and those dependencies will probably not be maintained as well as React. I worked in a shop that followed this philosophy. Every single UI component was a web component with its own npm package to install. It worked fine. There was zero benefit. There's still zero benefit today 6 years later. You're optimizing for a future which will most likely never come.
Devasta 3y ago
And jQuery will likely outlive both.
- klysm 3y ago
  I wouldn't really consider it alive in the grand scheme of things.
  - caseyohara 3y ago
    According to https://w3techs.com/technologies/details/js-jquery https://w3techs.com/technologies/details/js-jquery: > jQuery is used by 94.5% of all the websites whose JavaScript library we know. This is 77.5% of all websites. This appears to be current data too (Oct 2023). I'm not sure how reliable the data is, but it is congruent with my experience that _a lot_ of websites still use jQuery. It's easy to forget the HN crowd is also in a bubble. If you only read articles here, you'd think everyone is using the latest JS framework du jour, but lots of the web still runs on PHP and jQuery.
    - Kiala 3y ago
      Not that surprising actually, since jQuery is bundled with WordPress.
    - klysm 3y ago
      yes, but why on earth would you pick it for something greenfield? The only justification I could see is it being a tool you are personally familiar with.
- recursivedoubts 3y ago
  as i pass through my incarnations at every conference & youtube influencer king, i make my proper prostrations to the gods of the hot new thing peering through reverent fingers I watch them flourish and fall, and reliable silent old jquery, I notice, outlasts them all
  - joelfried 3y ago
recursivedoubts 3y ago
just because htmx (which is a library, not a framework) was mentioned, I'm going to respond to some stuff in the article first and foremost, the article doesn't talk about synchronizing state w/a server, which is what htmx is focuses on (via hypermedia exchanges), so htmx is orthogonal to WebComponents in this regard > There’s a cost to using dependencies. New versions are released, APIs change, and it takes time and effort to make sure your own code remains compatible with them. This is why htmx is dependency-free and focuses intensely on backwards compatibility (e.g. it is IE11 compatible). intercooler.js, which was htmx 1.0 and has one dependency, jQuery, was released in 2013 and is still supported. A lot of other javascript libraries have a culture of API rewrites and difficult upgrades, but htmx is explicitly not like that and shouldn't be heaped into that general culture. In htmx 2.0, our only breaking change is likely to be dropping IE support. Will web components outlive htmx? Well, they are part of the browser, so presumably yes. But, insofar as I can help it, htmx should be very stable and churn free going forward. The API is basically correct (yes, w/ a few warts and mistakes) and I see no need to rewrite everything for the sake of purity or sexiness. And, most importantly, htmx answers a different question than Web Components: how should I synchronize state w/ the server.
- jakelazaroff 3y ago
  Author here — I’ll remove that sentence since it looks like it’s being received in a way I didn’t intend. Sorry about that! I actually mentioned on Twitter [1] that web components are a natural fit for hypermedia-friendly scripting as described in your essay [2] (which I like a lot). [1] https://x.com/jlazaroff/status/1717176726248108469 https://x.com/jlazaroff/status/1717176726248108469 [2] https://htmx.org/essays/hypermedia-friendly-scripting/ https://htmx.org/essays/hypermedia-friendly-scripting/
  - recursivedoubts 3y ago
    Well, I think that the article (and sentence) is correctly pointing out an issue w/many JS frameworks, I just don't think it applies to htmx necessarily. I don't mind you keeping it up and having a debate around the topic: in as much as htmx does cause upgrade pain that's a burden of using it that deserves to be called out. I don't think you need to change the article, I just want to give my perspective as the author of htmx. It isn't realistic to expect everyone to write perfectly precise articles at all times, especially when the htmx reference in the article isn't a focus (likely included just because you kinda like htmx :)
wg0 3y ago
not to mention, web components come with their own complexity around shadow tree and the question of how to style/interact within the component tree from outside etc.
- miguelxt 3y ago
  Not mandatory to use the Shadow DOM. And you can easily add public methods to the component for external interaction.
- megaman821 3y ago
  You don't have to use the shadow DOM, you can use the light DOM, but then you lose slots. I think they should really prioritize using slots with the light DOM as it would make it easier to incorporate web components into existing sites.
  - coxmi 3y ago
    I don’t see how light DOM slots could work since it’s just replacing element.innerHTML, but a non-style-encapsulating shadow DOM option would be great. That, and some progress on template instantiation, reactive DOM primitives or DOM partials, so we don’t have to concatenate strings and overwrite el.shadowRoot.innerHTML, or do direct DOM manipulation for any updates. Until that all exists, and there’s a simple API to bring it all together, other frameworks will eat this space completely.
bastawhiz 3y ago
> But Markdown has a secret weapon: you can write HTML inside of it! That means any fancy interactive diagrams I wanted to add would be just as portable as my the rest of my Markdown as long as I could express them as plain HTML tags. You can also use MDX and achieve exactly the same thing. Web components the technology don't actually help here; what the author cares about is the interface between their markup and some piece of code that applies runtime functionality. Web components are an implementation detail here: whether you're referencing a React component or an Astro thing or a web component when you type a name between some angle brackets, it really doesn't matter: the point is that _some other thing_ is invoked. The downside to web components here is that they can only be run on the client, for all intents and purposes. There's no way to pass server-rendered shadow dom content on the server to the client, so even if your web component is fully non-interactive, you still need JS on the client in order to render it. That's not the case with other frameworks. I'll say that the author's point isn't wrong: web components as a way to codify interfaces between chunks of code is quite possibly the best, most durable way to accomplish that goal. BUT! On the server, web components do you no favors. They don't render, they are a cumbersome interface, and your code is already entirely written in a way that you can (hopefully!) work with. Which is to say, if you have Astro on the server, please keep using Astro! Or react, or vue, or whatever. Where web components shine is on the client, when you have a component from a third party that might not be written in your framework of choice. You don't need to know about the framework the component you're putting on the page was built with. You just use a HTML tag and it works. The mechanism of the interface is uplifted to the browser level, so you don't need two frameworks to speak each others' implementation details.
- ElevenLathe 3y ago
  >> But Markdown has a secret weapon: you can write HTML inside of it! That means any fancy interactive diagrams I wanted to add would be just as portable as my the rest of my Markdown as long as I could express them as plain HTML tags. > You can also use MDX and achieve exactly the same thing. I would like to point out that plain HTML also has this property.
  - bastawhiz 3y ago
rglover 3y ago
I was excited for web components, but the API was lacking (the final tipping point that led me to build Joystick [1]). I just couldn't get on board with a web-standard that eschewed HTML in favor of stuff like this [2] where list items are attributes. The hyphenated namespace thing has always made my eye twitch, too (silly, I know). [1] https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick [2] https://github.com/mdn/web-components-examples/blob/main/editable-list/index.html https://github.com/mdn/web-components-examples/blob/main/edi...
- spankalee 3y ago
  [2] Is just a bad example that you could build with anything, and had nothing to do with the spec. They could have chosen to take data as child elements, or as a JS object. Individual attributes like that is a bizarre choice and shouldn't reflect on web components. The web component APIs are low-level and what you need to achieve interop with the browser. Most developers use something like https://Lit.dev https://Lit.dev
  - troupo 3y ago
    > Is just a bad example that you could build with anything This is the go to "defense" I often hear from web component proponents. If even MDN cannot come up with a better example, something's wrong with tech, not with how people use it. > The web component APIs are low-level It's not. It only got labeled low-level after the initial failure to attract any developer mindshare. And then it got rebranded as "aimed at library and framework developers". Though it barely got traction there either because it offers nothing lib and framework developers want. > Most developers use something like https://Lit.dev https://Lit.dev The irony of writing this under "Web Components will outlast your framework"...
    - spankalee 3y ago
      > This is the go to "defense" I often hear from web component proponents. > > If even MDN cannot come up with a better example, something's wrong with tech, not with how people use it. It's not a "defense" it's a very wacky demo and I can't think of a single reason why you'd ever design a component this way. You could also design a React component or Angular component this way, and just like with web components, no one does, because it doesn't make sense. I can't say why MDN decided to do this, but this is literally the only time I've ever seen a list represented as individual attributes. > It's not. It only got labeled low-level after the initial failure to attract any developer mindshare This... just isn't true. Web component APIs are things like customElements.define(), HTMLElement.attachShadow(), HTMLElement.connectedCallback(). These are objectively low-level compared to things that frameworks give you. Branding (whose?) has nothing to do with it.
otikik 3y ago
An adult mayfly will outlive most Javascript frameworks.
- nfRfqX5n 3y ago
  React is 10 years old
  - klysm 3y ago
    I enjoy and use react, but I wouldn't call the modern react api (hooks etc) 10 years old.
    - s-lambert 3y ago
      Even hooks are almost 5 years old, there's been some changes to the hooks API but it's largely the same.
  - otikik 3y ago
    It is good that I wrote "most" and not "all", then.
jjcm 3y ago
I wrote all of non.io with vanilla webcomponents - it's a full SPA built on them. A few learnings I'll share with going beyond just a simple nested blog component: State management is still unanswered. You'll end up having to do a lot of this yourself if you aren't using a wrapper framework. One nice thing about React is state management is mostly solved and there are existing patterns for it. There's expectations of how it's done. With web components it's the wild west, and since you can't pass complex objects as attributes like you can in jsx, you end up doing a mix of attributes, events, and calling class functions directly. Performance isn't as big of a win as I'd have hoped. I actually reverted some smaller atomic elements (i.e. icons) away from being web components as their instantiation cost wasn't worth it when I had hundreds of these elements on the page. Static elements, despite the readability they provide in code (i.e. <nonio-icon glyph="hamburger">), just aren't worth using web components for, which was fairly disappointing. That said, there are things I REALLY enjoy about web components. As the author shared, it's incredibly easy to add a component to new pages, regardless of the framework being used. If something is built using web components, you can truly use it anywhere. This has been really nice when building supporting sites like api docs for nonio, where I can easily pick and choose what components I want despite having a different stack. Need to embed a <nonio-user> component? Import the js, add the html, you're golden. Style encapsulation of shadowroots is quite nice. I really love not having to worry about breaking styling of any component as I work on a page. It means less guesses and checks of clobbering styling of other elements, and less of a need for a visual diff framework to ensure this hasn't happened. The other aspect I enjoy is how slim the package sizes are. No libraries or anything extra to load, everything is baked in. Because you can pick and choose components you need so easily as well, it's incredibly easy to keep package sizes down. If anyone is curious, source components for nonio are here: https://github.com/jjcm/nonio-frontend/tree/master/components https://github.com/jjcm/nonio-frontend/tree/master/component...
- mdhb 3y ago
  Regarding the point you mentioned about not being able to pass objects via attributes, you can however pass them via properties on the element. Also as for the state management side of things there is nothing at all stopping you from hooking up whatever state management solution you want. I’ve even seen a bunch of solutions that use the browsers built in event model as well if keeping dependencies to a minimum is your goal. Finally, the last thing I would suggest is that writing an entire app in vanilla web components is kind of crazy talk in my opinion. For 5kb you can have a super nice developer experience using Lit (https://lit.dev https://lit.dev)
HatchedLake721 3y ago
No they won't. Because React is a view library, not a framework. Yes, web components might outlive React. But no, they will not outlive my JavaScript framework, because web components don't replace routing, data layer, testing, authz, server-side rendering, rehydration and whatever else frameworks like Angular/Ember/Next.js/etc do these days. Rendering a view is a small part of what front-end frameworks do.
- spankalee 3y ago
  React is a framework because it calls into the the components to make them go, not the other way around - the Holywood Principle. This shows up with restrictions like that you can't mix and match components with different versions of React in the same tree.
  - HatchedLake721 3y ago
    Even React homepage calls itself a library, and mentions Next.js/Remix/Gatsby/Expo as React frameworks you can use.
    - edgyquant 3y ago
      Doesn’t change that framework has a definition that react meets. The renderer runs your code, that’s a framework
      - a_wild_dandan 3y ago
        Your definition is very...unintuitive to me. Control inversion (the Hollywood Principle) isn't relevant -- many systems which use it aren't remotely frameworks. Most people view libraries as tools which target narrowly scoped sub-problems of a given solution/application. In React's case, it's a view library -- the V in MVC, for instance. Frameworks are generally considered holistic set of tools which tightly integrate together to form a structured & opinionated approach to the larger solution, e.g the entire MVC approach. React is widely considered a library. React doesn't tell you how to structure your project, manage its backend communication, handle application state, routing, etc. React is just...not a framework. For any standard notion of what engineers mean when using the term. If you use IoC to distinguish libs/frameworks, you're going to confuse the hell outta people. There are certainly technologies which straddle the line between these terms, but React is not one of them.
shadowgovt 3y ago
Probably not as long as there's a reason to transpile my project into minified, consolidated JavaScript, no. As long as I'm doing that, I can stick any framework I choose to into the pipe.
- spankalee 3y ago
  That's all orthogonal to web components. Like frameworks, there are some web components libraries that require a build step and some that don't.
skybrian 3y ago
ES modules have a problem: do they import the source code or the "binary" (minified code). As long as you're writing demos where the source code is the executable, it's fine. This is great for browser demos. But when you start using Typescript or npm modules that export minified code, or there's a CDN involved, finding the original source for a function gets increasingly difficult, the type definitions are in a different file, and breakpoints don't work. It's almost like debugging a binary. Compiled languages like Go do a better job of making sure you can actually read the source code, because imports always import source code.
- spankalee 3y ago
  I don't understand the problem here, or why it's JS module specific. Source maps with pretty great, and if you're in a development setup where you say only compile out types and resolve import specifiers, they work spectacularly well, including in debuggers.
  - skybrian 3y ago
    Source maps are indeed very helpful when they work, but in my experience, often they don’t for third-party modules. This seems to be an ecosystem thing. The documentation for package.json doesn’t mention sourcemaps? According to this bug [1], even the typescript compiler’s npm doesn’t include source or sourcemaps. [1] https://github.com/microsoft/TypeScript/issues/32207 https://github.com/microsoft/TypeScript/issues/32207
  - brainbag 3y ago
    Yeah, other than a project that was still on webpack, I can't think of any time in the last few years where this was a problem. Vite has made JavaScript apps nearly effortless for years now.
superkuh 3y ago
HTML/CSS sites will outlive it all. Because they're actually the text, images, layout all in static things that can live forever without being touched and without any need for complicated execution of code or mantaining of obscure rapidly changing pseudo-standards. (*1) If you want to make sites and have a skillset that last, learn how to make progressively enhanced HTML websites. Anything like Web Components (where you invent useless non-defined HTML-elements-with-hyphens and then define them after executing a bunch of Javascript), Javascript frameworks (where you don't even pretend to involve HTML) will last only a handful of years. (1*: at least until HTTP/1.1 support is removed from browsers)
- mdhb 3y ago
  What part of web components don’t meet the definition of progressively enhanced?
  - superkuh 3y ago
    You might be able to do progressive enhancement with web components but the vast majority, every web components site I've ever encountered, just end up with blank gray areas when the JS is not run to define them. That is far from progressive enhancement. It's a bit like "communism". You can say web components can be great or whatever, but everyone's every experience with it is very bad.
- jakelazaroff 3y ago
  Did you see what I used them for, though? How would you make a tutorial article with interactive demos without JavaScript?
  - superkuh 3y ago
    I didn't see it. All I see is "JavaScript is required to run this demo." but the rest of your text is visible and that's pretty exceptional for a web components site. Usually even the text doesn't exist unless javascript is run. So thanks. To address your point: the vast majority of web sites are text and images, not executable applications. Interactive tutorials are niche. Cool, but not something I'd base my entire web design ethos around.
strogonoff 3y ago
I often see novice developers making the mistake of comparing React to Web Components, to htmx, to Qwik, etc. React is not an equivalent of Web Components, but neither it is a front-end Web framework: it is neither a framework, nor it is specifically for the Web. What it is is a fairly small and general reactive GUI library[0]. Together with ReactDOM—a separate library—it can be used on the Web, but React itself can be used to render anything anywhere if you provide a suitable reconciler. As such, React (itself as old as Web Components) may well still be there whether or not the state of the art in front-end Web development moves on to whatever the next stack might be. [0] The distinction between frameworks and libraries, which tends to be lost on many fresh developers as well, is out of scope here but vital when it comes to software architecture.
- azangru 3y ago
  > React is not an equivalent of Web Components, but neither it is another web framework. What it is is a tiny and very general reactive GUI library. As for tiny, react-dom currently stands at 42kb minified gzipped. A tiny library would be about 1/10th the size (compare with preact or svelte). Also, react has nasty rerendering habits, which makes if feel not so tiny at times. But more importantly, have you read React docs recently? Have you seen how the official position of the core team is that if you are starting out with react, you should just pick a framework (Next or Remix)? Have you seen the extra complexities that these frameworks start to introduce (client-side state management in the age of server components, anyone)? React is no longer a tiny and very general reactive GUI library. For a tiny and general reactive GUI library, look at Lit. React, meanwhile, is attempting to become a kitchen-sink.
  - steve_adams_86 3y ago
    React promoting the use of frameworks by default is especially problematic because these frameworks are maintained by people who have profit incentives (either due to investor funding and/or because they sell products based around the framework). They aren’t just open source React frameworks; they’re open source products for companies using them as business engines.
  - 3y ago
pier25 3y ago
Yeah. The JS world is still so hung up about fat clients having all the control that it's missing all the interesting stuff happening in the server world. Rails Hotwire, Phoenix Liveviews, Laravel Livewire, etc. These solutions can solve 80% of your front end with minimal JS and almost no DX complexity.
- TheCapeGreek 3y ago
  Preach! I'm still keen to learn more on the Inertia side of Laravel, but Livewire (and especially with Filament in the mix) just feels insanely productive as a Laravel dev.
- metadaemon 3y ago
  Complexity has to exist somewhere, either in the engineer's hands, or swept under the rug for the framework to perform its magic on (really thinking about the Rails ecosystem here). When things go wrong, it's nicer, in my opinion, to have more control, especially in this fast paced clients-want-it-now environment.
  - bob1029 3y ago
    In my experience, the complexity with most frontend development is accidental by way of splitting state between client & server. If you manage to consolidate nearly all state to the server, complexity reduces by an entire dimension. There is nothing to synchronize anymore. You don't need these universes of delta-detection tools, frameworks, protocols, etc. In most of our modern SSR apps, the only state the client needs to hold onto is a session token. If we find the client has a wrong session token, correcting this is quite simple. Everything else happens on the server. Certainly there are holes with SSR (latency), but we haven't run into a real-world scenario where this actually matters enough to introduce entire new universes of hell into our lives.
  - worthless-trash 3y ago
    > Complexity has to exist somewhere, What is the complexity you are talking about here, is this the human (programmers) understanding of the system or the design of a complex system itself ?
demondemidi 3y ago
If a framework can support a major revision for longer than 6 months--more like 6 years--they will survive. Otherwise, the road to JavaScript madness is paved with frameworks that never learned LTS is a real thing.
- morbicer 3y ago
  There's no LTS in React but the components you wrote 10 years ago still works today in latest React. (there are some deprecations but very few)
onion2k 3y ago
I don't expect my preferred JS framework to remain the same though. I know that it's short-lived. I like that. Moving forwards, making progress, and improving are why I use React, Vue, Svelte, etc. I don't want something that's static right now, because none of the available frameworks (including Web Components) solve problems particularly elegantly. If the argument is that a site made with Web Components will outlast a site built with a JS framework then I'd be tempted to take that bet. I honestly think it's more likely that some part of the Web Components tech stack will be removed from Chrome, Safari, and Firefox in the next 20 years, consequently breaking apps built with them, than JavaScript will change in a way that means a React 16 app I wrote 2 years ago will break.
- owjofwjeofm 3y ago
  Correct me if I'm wrong, but I think running old code and not updating the dependencies might make your site vulnerable to security vulnerabilities that get discovered over time and fixed with new versions of libraries. So if you want to keep your code secure you will need to update libraries. But those old versions of those libraries will stop being supported, and known vulnerabilities will start to accumulate that have no fix. And attackers will probably have programs scan the web for websites with known vulnerabilities and automatically attack them. Versus if you use a library or platform (like Web Components) that cares a lot about backwards-compatibility, they will maintain the security while also supporting your old code for longer.
- troupo 3y ago
  > I honestly think it's more likely that some part of the Web Components tech stack will be removed from Chrome, Safari, and Firefox in the next 20 years, consequently breaking apps built with them That already happened. HTML Imports got deprecated (in favor of a JS-only solution), though Firefox already implemented them. Custom Elements v0 was deprecated even though Chrome implemented it and hastily re-wrote Youtube with it. They had to wait ~4 years to remove the implementation because it took Youtube that much to switch.
  - mdhb 3y ago
    The v0 part of it should mean none of that was a big surprise. It was an early prototype, it’s stable now.
miohtama 3y ago
Why Web Components have not yet taken off? They always sounded like a beautiful solution how to make all the various web frontend frameworks to live peacefully on the same page.
- rk06 3y ago
  Because they don't come with router, state management and other support. When you start adding them, you will be writing enough glue code that will offset a lot of benefits of web components.
- klysm 3y ago
  because they have a shitty API
- troupo 3y ago
  Because they don't offer a lot of things that matter to a lot of folks. This is still true 4 years later: https://x.com/Rich_Harris/status/1198332398561353728?s=20 https://x.com/Rich_Harris/status/1198332398561353728?s=20
Pesthuf 3y ago
Web components might be better for writing isolated and reusable components, but for gluing stuff together to make your application work, the DOM API is just garbage. It was made to edit XML documents and it shows. Also, one reason I don't make web components even for isolated, reusable components: No editor properly picks them up for things like autocompletion of attributes and event names or checks for typos.
sebringj 3y ago
IMO Web Components generally suck in developer experience but are good for bridging different js projects or web frameworks as the web components are very compatible between js frameworks. You can literally make a thin wrapper to expose your js flavored framework-based component such as react for example and expose it as a web component to another system such as angular 1 for example and it will work pretty well. You could potentially use this strategy to have parallel tracks of development where you can create an entirely new framework from scratch and start to share that functionality in the legacy project while you're in the process of upgrading which could take a long long time in some cases. At least you won't be continually working on the old one and adding more tech debt... although one could argue this wrapper approach is tech debt.
mark242 3y ago
[Insert the "now you have 16 standards" joke here]
- troupo 3y ago
  Web Components is at least 10 already, and will need at least 20 more. No, this is not a joke.
- tubthumper8 3y ago
  Tools and standards aren't really the same thing
troupo 3y ago
The only reason web components are alive is because Google is pouring literally millions into them. A technology that cannot submit forms without Javascript, still can't create a submit button and whose proponents agree that it still needs 20 more standards to be generally working [1] would be dead within a year. And yet we're here in year 12 of this dumpster fire. [1] Instead of producing a report every year, Web Component Group seems to just update the same document in place, so now it inly lists "4 standards we agreed need to be done ASAP"
locallost 3y ago
The title is probably correct, but not sure it matters. Most applications will not live that long. I recently tried using Web Components, and something that is very simple in any framework like using a <slot> was, um, eh, incredibly confusing and complicated to setup. This maybe doesn't matter if your component is just a <pixelart-demo>, but if you're building an application in JS then using slots is for me a critical feature because it allows me to have composable components. Debugging with "shadow dom" was also really confusing in dev tools.
- mmis1000 3y ago
  > incredibly confusing and complicated to setup. And some being almost impossible to work correctly without MutationObserver or some polyfill of it. The renderProp in react (or scoped slot in vue) is so commonly used to inject data from the parent component into child component. But replicate such behavior in webcomponent is simply... impossible without MutationObserver hacks. The assumption of web component that child/parent component never need to know the info of each other just don't make sense in real world. And the assumption that child component is always loaded and initiated regardless of parent component is also falsy in most frameworks. In most frameworks, the parent component decided whether child should be actually loaded or initiated.
morbicer 3y ago
I would like to love web components but they are still quite sucky to use (stringy attributes, bleh), especially if it's not your team who produces them. And some super basic stuff like buttons in forms is still an unsolved problem: > Form-associated custom elements: being a submit button https://github.com/WICG/webcomponents/issues/814 https://github.com/WICG/webcomponents/issues/814 opened 4 years ago and representatives of major browsers still don't have an answer
- mdhb 3y ago
  That form issue is actually resolved with full cross browser support already https://developer.mozilla.org/en-US/docs/Web/API/ElementInternals https://developer.mozilla.org/en-US/docs/Web/API/ElementInte... Also you don’t need to pass objects as HTML attributes, I think people pick that up coming from React but the browser lets you pass around objects between components just fine by using properties
  - morbicer 3y ago
    Can you provide me with an example please? I've seen the ElementInternals api but still don't understand how it should help with the case of being able to submit the form by hitting enter in one of the inputs (which is standard html behavior). I wasn't able to find working example anywhere and all the discussions around the issue are still open which leads me to an assumption that this is in fact, still unsolved. https://lit.dev/playground/#project=W3sibmFtZSI6InNpbXBsZS1ncmVldGluZy50cyIsImNvbnRlbnQiOiJpbXBvcnQge2h0bWwsIGNzcywgTGl0RWxlbWVudH0gZnJvbSAnbGl0JztcbmltcG9ydCB7Y3VzdG9tRWxlbWVudCwgcHJvcGVydHl9IGZyb20gJ2xpdC9kZWNvcmF0b3JzLmpzJztcblxuQGN1c3RvbUVsZW1lbnQoJ215LWJ1dHRvbicpXG5leHBvcnQgY2xhc3MgU2ltcGxlR3JlZXRpbmcgZXh0ZW5kcyBMaXRFbGVtZW50IHtcbiAgc3RhdGljIGZvcm1Bc3NvY2lhdGVkID0gdHJ1ZTtcblxuICBAcHJvcGVydHkoKVxuICBuYW1lID0gJ2Zvbyc7XG4gIFxuICBjb25zdHJ1Y3RvcigpIHtcbiAgICBzdXBlcigpO1xuICAgIHRoaXMuYXR0YWNoSW50ZXJuYWxzKCk7XG4gIH1cblxuICByZW5kZXIoKSB7XG4gICAgcmV0dXJuIGh0bWxgPGJ1dHRvbiB0eXBlPVwic3VibWl0XCI-JHt0aGlzLm5hbWV9ITwvYnV0dG9uPmA7XG4gIH1cbn1cbiJ9LHsibmFtZSI6ImluZGV4Lmh0bWwiLCJjb250ZW50IjoiPCFET0NUWVBFIGh0bWw-XG48aGVhZD5cbiAgPHNjcmlwdCB0eXBlPVwibW9kdWxlXCIgc3JjPVwiLi9zaW1wbGUtZ3JlZXRpbmcuanNcIj48L3NjcmlwdD5cbiAgPHN0eWxlPmJ1dHRvbiB7Y29sb3I6cmVkfTwvc3R5bGU-XG48L2hlYWQ-XG48Ym9keT5cbiAgPGZvcm0gb25zdWJtaXQ9XCJhbGVydCgnd29ya3MhJylcIj5cbiAgICAgIDxpbnB1dCBuYW1lPVwiYmFyXCI-XG4gICAgICA8aW5wdXQgbmFtZT1cImJhelwiPlxuICAgICAgPG15LWJ1dHRvbiBuYW1lPVwic2hvdWxkIHN1Ym1pdCBvbiBlbnRlciBidXQgZG9lc24ndFwiPjwvbXktYnV0dG9uPlxuICA8L2Zvcm0-XG48L2JvZHk-XG4ifSx7Im5hbWUiOiJwYWNrYWdlLmpzb24iLCJjb250ZW50Ijoie1xuICBcImRlcGVuZGVuY2llc1wiOiB7XG4gICAgXCJsaXRcIjogXCJeMy4wLjBcIixcbiAgICBcIkBsaXQvcmVhY3RpdmUtZWxlbWVudFwiOiBcIl4yLjAuMFwiLFxuICAgIFwibGl0LWVsZW1lbnRcIjogXCJeNC4wLjBcIixcbiAgICBcImxpdC1odG1sXCI6IFwiXjMuMC4wXCJcbiAgfVxufSIsImhpZGRlbiI6dHJ1ZX1d https://lit.dev/playground/#project=W3sibmFtZSI6InNpbXBsZS1n...
ent101 3y ago
We wrote Puter.com in vanilla js and it's been pretty straight forward. tbh most of the complexity is coming from the backend rather than the frontend.
taeric 3y ago
But will Web Components of tomorrow be the same as the ones today? I see that, in today's parlance, this is 3 core ideas. Custom elements, shadow DOM, and templates. I fully expect things to be added to that list as time goes on. Not the least because of so many obvious things that are not covered there. To that end, the question will have to be if you can run the same web components of today on a browser of tomorrow. With the very notable fact that though you can't run components on browsers of yesterday, you can run that old jquery site on browsers of today.
DrScientist 3y ago
The web component idea originally had something like 4 basic components. - custom elements - shadow DOM - html imports ( now dead or at the very least 'resting' ) - html templates I think it's important to note that you can build/use custom elements ( defining your own tags with encapsulated behaviour ) without having to use shadow DOM nor html templates. So a simple way to start, in my view, is plain custom elements, mixed in with ES modules and import maps. Shadow DOM and html templates are not compulsory to get your <custom-tag></custom-tag>
raspo 3y ago
I think the author was referring about the specific use-case of building a website using static file generators. In that context I 100% agree with him that if you want to sprinkle some interactivity while keeping your content "portable" and be able to move to the next "CMS" of the future, sticking with web components is a much wiser choice, rather than embracing whatever fancy convenient feature your tool provides (like Astro's islands). (It is good advice and a well written article btw, thank you for sharing) I don't think he was suggesting to build your next SPA entirely with web components..
- jakelazaroff 3y ago
  Author here — yes, this is exactly correct (and thank you for the kind words). I think the maintenance cost of dependencies is important to consider, and with web components we have a "native" solution for encapsulating HTML, CSS and JS. That doesn't mean that every project needs to have that as its top priority! Sometimes development velocity/shared patterns/ease of finding other developers is more important, and that's perfectly fine.
btbuildem 3y ago
I find it interesting that the author's premise seems motivated by a self-inflicted churn. Having migrated a simple blog across a dozen of technologies, their conclusion is that <basic building blocks> will outlast any trend? Surely, yes. But I'd like to observe that a blog like this, one of the simplest web-based entities, could have remained implemented in some of the decades-old technologies and delivered the same experience to the end user.
nathias 3y ago
There are so many downsides of choosing web components you really need a very rare usecase to justify them. They are an artefact of a time we're all glad to be done with, they force you into OOP so you're doing inheritance acrobatics, add TS and now you're feeding two hierarchies of inheritance that don't quite match and bloat to a 80% of your codebase, making it unreadable, prone to hacks and bugs, impossible to maintain etc. The point of web components was to make components more shareable between frameworks, and code more reusable, but now code written in any of the major FE frameworks is more reusable (a component looks pretty much the same in React, Vue, Svelte, but not with web components).
yellow_lead 3y ago
My problem with web components is the jitter they introduce when rendering the page. Sure, you can hide this or fade it with CSS, but it's kind of a dealbreaker for me. Maybe someone can suggest a better workaround? For instance, on the submitted page, I see a jitter for the pixelart-demo component.
merelysounds 3y ago
I also like reducing dependencies, but I’ve picked a different approach. When I use an external library, I link to static production scripts, without webpack or other bundler. I do use babel to handle jsx if needed, but I do it by linking babel via a script tag in dev mode (and with a simple shell script in production). It’s more radical, not recommended for production use and impractical for anything other than a hobby project. But it’s a way to limit adding new dependencies, or limit reliance on package managers. Additionally, the project can work with as much as a static file server, also for development - so I won’t get stuck on an “npm update” when I return to a project after a break. Most recent website I’ve built like this is: https://merely.xyz/lenses https://merely.xyz/lenses , list of Sony E Mount FF lenses. Again, for most cases web components sound like a more practical approach, I plan to explore that long term too.
- iamcreasy 3y ago
  That's exactly what I've been trying to do for the last few days but get frequently hit by simple JS errors such as import failures, and currently I don't have the time to properly learn the language. Looking for a way to learn enough to get something up and running. Do you know any source that explains using React this way? I've looked into the source of merely.xyz but I am looking for something simpler that holds your hand.
npteljes 3y ago
I shifted my focus from technology to people. If I'm starting a new project, I'll look at what the people who'll work on the project know. If there's a common denominator or best practice, like how React is nowadays for frontends, I'll just go with that. I don't really sweat these technical decisions, because the team composition, or the job seekers' market, or StackOverflow's technology top list answers there questions with ease.
- josephg 3y ago
  I get that and I think it’s pragmatic. But if everyone thinks like you’re suggesting, we’ll all be using react forever, even if there are better answers out there for how to build our software. If you want to use whatever is popular, that means you depend on others to find good technology solutions and make them popular in order to improve your tech stack. Put another way, this strategy puts you firmly in the “mid to late adopter” part of the adoption curve. Articles like this (and indeed much of this discussion) is largely targeting people who are earlier adopters.
  - npteljes 3y ago
    I think you hit the nail on the head on the adoption curve point. I indeed am a later adopter, and lately consciously so.
sandreas 3y ago
If you combine native WebComponents with scss and JSX/TSX, it gets even better. As an example you could take a look at an older project on github: https://github.com/cyco/WebFun/ https://github.com/cyco/WebFun/ Here is some example code: https://github.com/cyco/WebFun/blob/ec42d59b99d62daafea3ccce5caa254c5e99b600/src/app/webfun/ui/ammo.tsx#L4 https://github.com/cyco/WebFun/blob/ec42d59b99d62daafea3ccce... https://github.com/cyco/WebFun/blob/ec42d59b99d62daafea3ccce5caa254c5e99b600/src/app/webfun/ui/error-view.tsx https://github.com/cyco/WebFun/blob/ec42d59b99d62daafea3ccce...
joduplessis 3y ago
In adjacent news, I love that typeface.
- esafak 3y ago
  It's Peachi: https://www.mycreativeland.com/peachi-serif-font-family https://www.mycreativeland.com/peachi-serif-font-family Apparently based on https://en.wikipedia.org/wiki/Souvenir_(typeface) https://en.wikipedia.org/wiki/Souvenir_(typeface) See also https://fly.io/ https://fly.io/
zubairq 3y ago
Great article. Really made me think. But don’t webcomponents lack properties and functions that can be embedded in tooling ?
wg0 3y ago
I just got to know that svelte components can be complied into web components. If so, then probably using svelte as a compiler for web components can be one way to do things. Not sure about routing though. Maybe page.js or something. Even for vanilla js, till might need vite, postcss, tailwind in some cases.
gitaarik 3y ago
From the comments I see here, it seems like many people expect the Web Components API to be a complete replacement for a JS framework. The thing is, our frameworks should start making more use of modern web APIs, so the frameworks will have to do less heavy lifting themselves, so they can become smaller, so our projects are dependent on less framework code. Lit [0] for example is doing this. It's a very small library, making use of the Web Components APIs. Using Lit is very similar to using React. Some things work different, and you have to get used to some web component specific things, but once you get it, I think it's way more pleasant to work with than React. It feels more natural, native, less framework-specific. For state management, I created LitState [1], a tiny library (really only 258 lines), which integrates nicely with Lit, and which makes state management between multiple components very easy. It's much easier than the Redux/flux workflows found in React. So my experience with this is that it's much nicer to work with, and that your total project size is much smaller. [0] https://lit.dev/ https://lit.dev/ [1] https://github.com/gitaarik/lit-state https://github.com/gitaarik/lit-state
- troupo 3y ago
  > The thing is, our frameworks should start making more use of modern web APIs, so the frameworks will have to do less heavy lifting themselves They already do that wherever possible. However, web componens provide almost exactly zero value to frameworks. You could ask a simple question: why did the authors of Vue, Svelte and Solid started as staunch supporters of web components (and even modeled early versions of their frameworks after them), and why are they now at best indifferent and at worst actively hostile towards web components? > It feels more natural, native, less framework-specific. If you ignore all the framework-specific things like custom template DSL, custom JS DSL, custom functionality like contexts and the new custom compiler, it's very native.
nojvek 3y ago
Webcomponents will outlive React 13? Sure. Will they outlive React entirely or its cousins like Solid and Svelte? Perhaps not. Webcomponents and React look like they solve the same problem but they do not. Webcomponent api is pretty shallow. You get connected/disconnnected/attributeChanged call back but gotta write your own property setter and getters, slots, template, shadow dom and that’s mostly it. Shadow dom becomes a pain to work with if something needs to pierce it. No built-in webcomponent api for efficiently applying state changes to dom. All attributes have to be strings and other types need to be parsed. Mixpanel went all in on webcomponents. They made their own framework on top of webcomponents. https://github.com/mixpanel/panel https://github.com/mixpanel/panel Worked on panel lib and webcomponent UI for many years. Webcomponents are not a silver bullet. The issue with webcomponents is there are a ton of libraries that fill in the missing gaps. There’s not a lot you can do with pure vanilla webcomponent api. Google has their own thing, Microsoft had multiple internal libs across orgs, Reddit does their own thing. The most standard thing for frontend with wide adoption right now is React. vanilla webcomponents are good for simple widgets in a vanilla html/css page. To build complex single page applications, would not recommend it. You’d be building you’re own bespoke framework to fill in the gaps.

310 points by cdme 3y ago

diob 3y ago

But will the JavaScript Framework I'm using outlive my application? Most folks would answer yes I think. The lifetime of apps is surprisingly short.

EliasToft 3y ago
I dont know about that. The very first project I worked on after graduating is still very much alive last I checked, and I was actually promised that it should only have a lifetime of a few years as it was an incredible fast developed prototype - the feature set and scope considering. I actually left the company because we were two devs and the owner of the company constantly wanted us to work on new features instead of improving the foundation of the obviosuly rushed prototype, but here we are almost 15 years later and the core of it is pretty much still the same thing as when I left (SaaS).
- namtab00 3y ago
  I've recently found out stuff I've built 16 years ago, in ColdFusion and Classic ASP (anybody remember Macromedia Dreamweaver, later Adobe?) is still in use, never mind more "recent" WebForms + jquery stuff...

deleted 3y ago

[deleted]

very_good_man 3y ago

Is this a joke? html and css as one big JS string?

hyperhello 3y ago
Well, yea. All pointless frameworking is based on the fact that HTML doesn’t natively nest in other HTML or natively color in JavaScript editors. So we have ridiculous bloat, when that was all we had to fix: the ability to put HTML in JavaScript in a satisfyingly official way. Instead, we have everything in fragments that have to be mechanically transformed, and fight over which giant IDE is best.

punyearthling 3y ago

web components are nice, but not perfect and i get tired of web component proponents neglecting to mention the trade-offs when using them. enabling shadow DOM renders that component completely inaccessible to users using assistive tech like screen readers. without a shadow DOM enabled, you lose the encapsulation benefit devs seem to love. js framework components, for all their faults, can at least be accessible. i just don't think web components are quite there yet.

franciscop 3y ago

Which web components, the ones that were deprecated and no browser implements anymore? Ah wait no, you mean the new ones that virtually no one uses, right? While the point of view that ESM and DOM APIs live long-term is pretty good, the specific example is maybe the most infamous for how not true this has been and many call web components Dead On Arrival. Newer technology on the web does break more often than old JS (maybe, Flash?), for example I have a project that for security reasons doesn't work anymore, Cookies famously also had a big change for security like that, fetch() defaults changed, and AFAIK even performance.now() was capped for Spectre.

fassssst 3y ago
Bing Chat is built entirely with Web Components. (I work at Microsoft on it. You can verify with F12.)
- tuzemec 3y ago
  AFAIK - also the browser version of Photoshop.
  - spankalee 3y ago
    And Chrome OS, Firefox, Reddit, Internet Archive, YouTube, and a long list of others...
    - franciscop 3y ago
      I checked a couple of those quickly; Reddit doesn't seem to use web components at all? https://imgur.com/a/kzLoGnV https://imgur.com/a/kzLoGnV Youtube seems to use 1 web component for every 10 normal components, which is fair: https://imgur.com/a/YIBhLh8 https://imgur.com/a/YIBhLh8
      - megaman821 3y ago
        Reddit has a whole other site if you go there without being logged in. That one is built with web components.

gedy 3y ago

Maybe, but while I love UI components, I really dislike that "web components" conflate and combine multiple things like custom elements, and shadow DOM, etc. So working with them in real apps, you get a mess of opinions and assumptions like completely isolated styles (no I don't want this! let me use my site's Bootstrap theme!), etc. Also dealing with string-based attributes/props is a pain. I greatly prefer React/Svelte/Vue for not having to deal with all this.

zaphar 3y ago
It's an umbrella term for a set of technologies. Each of them can be used in isolation from the others if you want though. You don't have to use shadow DOM if you don't want it. You don't have to use custom elements if you don't want to either. You are correct though that almost every tool that works with them sort of assumes you are going to use both.
- tuzemec 3y ago
  I kinda like this approach. You can change the combination of used APIs for different cases. "Widget" that you provide for partners to put on their web pages? Of course you'll use shadow DOM, because you don't know the page context, surrounding styles, etc. A component to share on different parts of your site - you can skip the shadow DOM, because you share common styles everywhere, and probably you want to inherit some of them.
  - zaphar 3y ago
    I think in terms of the implementation keeping them separate and composable is very useful. I think the marketing around it could have emphasized it a little more but that's water under the bridge really.
jjcm 3y ago
It's fairly easy to choose between style isolation and no style isolation though. Just change the `this.shadow.innerHTML` in the render to `this.innerHTML`. The encapsulation aspect provides some really nice benefits in many scenarios, so having the option of this is quite nice. A classic example of why this is beneficial is when creating design system components - you typically want these to not be affected by styling on the page, and if you do want them to be styled, you only want them to be styled in specific ways which you can build in via css custom property values (see the accent example the author provides).

ramesh31 3y ago

They will also require a cobbled together list of dependencies to make useful, and those dependencies will probably not be maintained as well as React. I worked in a shop that followed this philosophy. Every single UI component was a web component with its own npm package to install. It worked fine. There was zero benefit. There's still zero benefit today 6 years later. You're optimizing for a future which will most likely never come.

Devasta 3y ago

And jQuery will likely outlive both.

klysm 3y ago
I wouldn't really consider it alive in the grand scheme of things.
- caseyohara 3y ago
  According to https://w3techs.com/technologies/details/js-jquery https://w3techs.com/technologies/details/js-jquery: > jQuery is used by 94.5% of all the websites whose JavaScript library we know. This is 77.5% of all websites. This appears to be current data too (Oct 2023). I'm not sure how reliable the data is, but it is congruent with my experience that _a lot_ of websites still use jQuery. It's easy to forget the HN crowd is also in a bubble. If you only read articles here, you'd think everyone is using the latest JS framework du jour, but lots of the web still runs on PHP and jQuery.
  - Kiala 3y ago
    Not that surprising actually, since jQuery is bundled with WordPress.
  - klysm 3y ago
    yes, but why on earth would you pick it for something greenfield? The only justification I could see is it being a tool you are personally familiar with.
recursivedoubts 3y ago
as i pass through my incarnations at every conference & youtube influencer king, i make my proper prostrations to the gods of the hot new thing peering through reverent fingers I watch them flourish and fall, and reliable silent old jquery, I notice, outlasts them all
- joelfried 3y ago

recursivedoubts 3y ago

just because htmx (which is a library, not a framework) was mentioned, I'm going to respond to some stuff in the article first and foremost, the article doesn't talk about synchronizing state w/a server, which is what htmx is focuses on (via hypermedia exchanges), so htmx is orthogonal to WebComponents in this regard > There’s a cost to using dependencies. New versions are released, APIs change, and it takes time and effort to make sure your own code remains compatible with them. This is why htmx is dependency-free and focuses intensely on backwards compatibility (e.g. it is IE11 compatible). intercooler.js, which was htmx 1.0 and has one dependency, jQuery, was released in 2013 and is still supported. A lot of other javascript libraries have a culture of API rewrites and difficult upgrades, but htmx is explicitly not like that and shouldn't be heaped into that general culture. In htmx 2.0, our only breaking change is likely to be dropping IE support. Will web components outlive htmx? Well, they are part of the browser, so presumably yes. But, insofar as I can help it, htmx should be very stable and churn free going forward. The API is basically correct (yes, w/ a few warts and mistakes) and I see no need to rewrite everything for the sake of purity or sexiness. And, most importantly, htmx answers a different question than Web Components: how should I synchronize state w/ the server.

jakelazaroff 3y ago
Author here — I’ll remove that sentence since it looks like it’s being received in a way I didn’t intend. Sorry about that! I actually mentioned on Twitter [1] that web components are a natural fit for hypermedia-friendly scripting as described in your essay [2] (which I like a lot). [1] https://x.com/jlazaroff/status/1717176726248108469 https://x.com/jlazaroff/status/1717176726248108469 [2] https://htmx.org/essays/hypermedia-friendly-scripting/ https://htmx.org/essays/hypermedia-friendly-scripting/
- recursivedoubts 3y ago
  Well, I think that the article (and sentence) is correctly pointing out an issue w/many JS frameworks, I just don't think it applies to htmx necessarily. I don't mind you keeping it up and having a debate around the topic: in as much as htmx does cause upgrade pain that's a burden of using it that deserves to be called out. I don't think you need to change the article, I just want to give my perspective as the author of htmx. It isn't realistic to expect everyone to write perfectly precise articles at all times, especially when the htmx reference in the article isn't a focus (likely included just because you kinda like htmx :)

wg0 3y ago

not to mention, web components come with their own complexity around shadow tree and the question of how to style/interact within the component tree from outside etc.

miguelxt 3y ago
Not mandatory to use the Shadow DOM. And you can easily add public methods to the component for external interaction.
megaman821 3y ago
You don't have to use the shadow DOM, you can use the light DOM, but then you lose slots. I think they should really prioritize using slots with the light DOM as it would make it easier to incorporate web components into existing sites.
- coxmi 3y ago
  I don’t see how light DOM slots could work since it’s just replacing element.innerHTML, but a non-style-encapsulating shadow DOM option would be great. That, and some progress on template instantiation, reactive DOM primitives or DOM partials, so we don’t have to concatenate strings and overwrite el.shadowRoot.innerHTML, or do direct DOM manipulation for any updates. Until that all exists, and there’s a simple API to bring it all together, other frameworks will eat this space completely.

bastawhiz 3y ago

> But Markdown has a secret weapon: you can write HTML inside of it! That means any fancy interactive diagrams I wanted to add would be just as portable as my the rest of my Markdown as long as I could express them as plain HTML tags. You can also use MDX and achieve exactly the same thing. Web components the technology don't actually help here; what the author cares about is the interface between their markup and some piece of code that applies runtime functionality. Web components are an implementation detail here: whether you're referencing a React component or an Astro thing or a web component when you type a name between some angle brackets, it really doesn't matter: the point is that _some other thing_ is invoked. The downside to web components here is that they can only be run on the client, for all intents and purposes. There's no way to pass server-rendered shadow dom content on the server to the client, so even if your web component is fully non-interactive, you still need JS on the client in order to render it. That's not the case with other frameworks. I'll say that the author's point isn't wrong: web components as a way to codify interfaces between chunks of code is quite possibly the best, most durable way to accomplish that goal. BUT! On the server, web components do you no favors. They don't render, they are a cumbersome interface, and your code is already entirely written in a way that you can (hopefully!) work with. Which is to say, if you have Astro on the server, please keep using Astro! Or react, or vue, or whatever. Where web components shine is on the client, when you have a component from a third party that might not be written in your framework of choice. You don't need to know about the framework the component you're putting on the page was built with. You just use a HTML tag and it works. The mechanism of the interface is uplifted to the browser level, so you don't need two frameworks to speak each others' implementation details.

ElevenLathe 3y ago
>> But Markdown has a secret weapon: you can write HTML inside of it! That means any fancy interactive diagrams I wanted to add would be just as portable as my the rest of my Markdown as long as I could express them as plain HTML tags. > You can also use MDX and achieve exactly the same thing. I would like to point out that plain HTML also has this property.
- bastawhiz 3y ago

rglover 3y ago

I was excited for web components, but the API was lacking (the final tipping point that led me to build Joystick [1]). I just couldn't get on board with a web-standard that eschewed HTML in favor of stuff like this [2] where list items are attributes. The hyphenated namespace thing has always made my eye twitch, too (silly, I know). [1] https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick [2] https://github.com/mdn/web-components-examples/blob/main/editable-list/index.html https://github.com/mdn/web-components-examples/blob/main/edi...

spankalee 3y ago
[2] Is just a bad example that you could build with anything, and had nothing to do with the spec. They could have chosen to take data as child elements, or as a JS object. Individual attributes like that is a bizarre choice and shouldn't reflect on web components. The web component APIs are low-level and what you need to achieve interop with the browser. Most developers use something like https://Lit.dev https://Lit.dev
- troupo 3y ago
  > Is just a bad example that you could build with anything This is the go to "defense" I often hear from web component proponents. If even MDN cannot come up with a better example, something's wrong with tech, not with how people use it. > The web component APIs are low-level It's not. It only got labeled low-level after the initial failure to attract any developer mindshare. And then it got rebranded as "aimed at library and framework developers". Though it barely got traction there either because it offers nothing lib and framework developers want. > Most developers use something like https://Lit.dev https://Lit.dev The irony of writing this under "Web Components will outlast your framework"...
  - spankalee 3y ago
    > This is the go to "defense" I often hear from web component proponents. > > If even MDN cannot come up with a better example, something's wrong with tech, not with how people use it. It's not a "defense" it's a very wacky demo and I can't think of a single reason why you'd ever design a component this way. You could also design a React component or Angular component this way, and just like with web components, no one does, because it doesn't make sense. I can't say why MDN decided to do this, but this is literally the only time I've ever seen a list represented as individual attributes. > It's not. It only got labeled low-level after the initial failure to attract any developer mindshare This... just isn't true. Web component APIs are things like customElements.define(), HTMLElement.attachShadow(), HTMLElement.connectedCallback(). These are objectively low-level compared to things that frameworks give you. Branding (whose?) has nothing to do with it.

otikik 3y ago

An adult mayfly will outlive most Javascript frameworks.

nfRfqX5n 3y ago
React is 10 years old
- klysm 3y ago
  I enjoy and use react, but I wouldn't call the modern react api (hooks etc) 10 years old.
  - s-lambert 3y ago
    Even hooks are almost 5 years old, there's been some changes to the hooks API but it's largely the same.
- otikik 3y ago
  It is good that I wrote "most" and not "all", then.

jjcm 3y ago

I wrote all of non.io with vanilla webcomponents - it's a full SPA built on them. A few learnings I'll share with going beyond just a simple nested blog component: State management is still unanswered. You'll end up having to do a lot of this yourself if you aren't using a wrapper framework. One nice thing about React is state management is mostly solved and there are existing patterns for it. There's expectations of how it's done. With web components it's the wild west, and since you can't pass complex objects as attributes like you can in jsx, you end up doing a mix of attributes, events, and calling class functions directly. Performance isn't as big of a win as I'd have hoped. I actually reverted some smaller atomic elements (i.e. icons) away from being web components as their instantiation cost wasn't worth it when I had hundreds of these elements on the page. Static elements, despite the readability they provide in code (i.e. <nonio-icon glyph="hamburger">), just aren't worth using web components for, which was fairly disappointing. That said, there are things I REALLY enjoy about web components. As the author shared, it's incredibly easy to add a component to new pages, regardless of the framework being used. If something is built using web components, you can truly use it anywhere. This has been really nice when building supporting sites like api docs for nonio, where I can easily pick and choose what components I want despite having a different stack. Need to embed a <nonio-user> component? Import the js, add the html, you're golden. Style encapsulation of shadowroots is quite nice. I really love not having to worry about breaking styling of any component as I work on a page. It means less guesses and checks of clobbering styling of other elements, and less of a need for a visual diff framework to ensure this hasn't happened. The other aspect I enjoy is how slim the package sizes are. No libraries or anything extra to load, everything is baked in. Because you can pick and choose components you need so easily as well, it's incredibly easy to keep package sizes down. If anyone is curious, source components for nonio are here: https://github.com/jjcm/nonio-frontend/tree/master/components https://github.com/jjcm/nonio-frontend/tree/master/component...

mdhb 3y ago
Regarding the point you mentioned about not being able to pass objects via attributes, you can however pass them via properties on the element. Also as for the state management side of things there is nothing at all stopping you from hooking up whatever state management solution you want. I’ve even seen a bunch of solutions that use the browsers built in event model as well if keeping dependencies to a minimum is your goal. Finally, the last thing I would suggest is that writing an entire app in vanilla web components is kind of crazy talk in my opinion. For 5kb you can have a super nice developer experience using Lit (https://lit.dev https://lit.dev)

HatchedLake721 3y ago

No they won't. Because React is a view library, not a framework. Yes, web components might outlive React. But no, they will not outlive my JavaScript framework, because web components don't replace routing, data layer, testing, authz, server-side rendering, rehydration and whatever else frameworks like Angular/Ember/Next.js/etc do these days. Rendering a view is a small part of what front-end frameworks do.

spankalee 3y ago
React is a framework because it calls into the the components to make them go, not the other way around - the Holywood Principle. This shows up with restrictions like that you can't mix and match components with different versions of React in the same tree.
- HatchedLake721 3y ago
  Even React homepage calls itself a library, and mentions Next.js/Remix/Gatsby/Expo as React frameworks you can use.
  - edgyquant 3y ago
    Doesn’t change that framework has a definition that react meets. The renderer runs your code, that’s a framework
    - a_wild_dandan 3y ago
      Your definition is very...unintuitive to me. Control inversion (the Hollywood Principle) isn't relevant -- many systems which use it aren't remotely frameworks. Most people view libraries as tools which target narrowly scoped sub-problems of a given solution/application. In React's case, it's a view library -- the V in MVC, for instance. Frameworks are generally considered holistic set of tools which tightly integrate together to form a structured & opinionated approach to the larger solution, e.g the entire MVC approach. React is widely considered a library. React doesn't tell you how to structure your project, manage its backend communication, handle application state, routing, etc. React is just...not a framework. For any standard notion of what engineers mean when using the term. If you use IoC to distinguish libs/frameworks, you're going to confuse the hell outta people. There are certainly technologies which straddle the line between these terms, but React is not one of them.

shadowgovt 3y ago

Probably not as long as there's a reason to transpile my project into minified, consolidated JavaScript, no. As long as I'm doing that, I can stick any framework I choose to into the pipe.

spankalee 3y ago
That's all orthogonal to web components. Like frameworks, there are some web components libraries that require a build step and some that don't.

skybrian 3y ago

ES modules have a problem: do they import the source code or the "binary" (minified code). As long as you're writing demos where the source code is the executable, it's fine. This is great for browser demos. But when you start using Typescript or npm modules that export minified code, or there's a CDN involved, finding the original source for a function gets increasingly difficult, the type definitions are in a different file, and breakpoints don't work. It's almost like debugging a binary. Compiled languages like Go do a better job of making sure you can actually read the source code, because imports always import source code.

spankalee 3y ago
I don't understand the problem here, or why it's JS module specific. Source maps with pretty great, and if you're in a development setup where you say only compile out types and resolve import specifiers, they work spectacularly well, including in debuggers.
- skybrian 3y ago
  Source maps are indeed very helpful when they work, but in my experience, often they don’t for third-party modules. This seems to be an ecosystem thing. The documentation for package.json doesn’t mention sourcemaps? According to this bug [1], even the typescript compiler’s npm doesn’t include source or sourcemaps. [1] https://github.com/microsoft/TypeScript/issues/32207 https://github.com/microsoft/TypeScript/issues/32207
- brainbag 3y ago
  Yeah, other than a project that was still on webpack, I can't think of any time in the last few years where this was a problem. Vite has made JavaScript apps nearly effortless for years now.

superkuh 3y ago

HTML/CSS sites will outlive it all. Because they're actually the text, images, layout all in static things that can live forever without being touched and without any need for complicated execution of code or mantaining of obscure rapidly changing pseudo-standards. (*1) If you want to make sites and have a skillset that last, learn how to make progressively enhanced HTML websites. Anything like Web Components (where you invent useless non-defined HTML-elements-with-hyphens and then define them after executing a bunch of Javascript), Javascript frameworks (where you don't even pretend to involve HTML) will last only a handful of years. (1*: at least until HTTP/1.1 support is removed from browsers)

mdhb 3y ago
What part of web components don’t meet the definition of progressively enhanced?
- superkuh 3y ago
  You might be able to do progressive enhancement with web components but the vast majority, every web components site I've ever encountered, just end up with blank gray areas when the JS is not run to define them. That is far from progressive enhancement. It's a bit like "communism". You can say web components can be great or whatever, but everyone's every experience with it is very bad.
jakelazaroff 3y ago
Did you see what I used them for, though? How would you make a tutorial article with interactive demos without JavaScript?
- superkuh 3y ago
  I didn't see it. All I see is "JavaScript is required to run this demo." but the rest of your text is visible and that's pretty exceptional for a web components site. Usually even the text doesn't exist unless javascript is run. So thanks. To address your point: the vast majority of web sites are text and images, not executable applications. Interactive tutorials are niche. Cool, but not something I'd base my entire web design ethos around.

strogonoff 3y ago

I often see novice developers making the mistake of comparing React to Web Components, to htmx, to Qwik, etc. React is not an equivalent of Web Components, but neither it is a front-end Web framework: it is neither a framework, nor it is specifically for the Web. What it is is a fairly small and general reactive GUI library[0]. Together with ReactDOM—a separate library—it can be used on the Web, but React itself can be used to render anything anywhere if you provide a suitable reconciler. As such, React (itself as old as Web Components) may well still be there whether or not the state of the art in front-end Web development moves on to whatever the next stack might be. [0] The distinction between frameworks and libraries, which tends to be lost on many fresh developers as well, is out of scope here but vital when it comes to software architecture.

azangru 3y ago
> React is not an equivalent of Web Components, but neither it is another web framework. What it is is a tiny and very general reactive GUI library. As for tiny, react-dom currently stands at 42kb minified gzipped. A tiny library would be about 1/10th the size (compare with preact or svelte). Also, react has nasty rerendering habits, which makes if feel not so tiny at times. But more importantly, have you read React docs recently? Have you seen how the official position of the core team is that if you are starting out with react, you should just pick a framework (Next or Remix)? Have you seen the extra complexities that these frameworks start to introduce (client-side state management in the age of server components, anyone)? React is no longer a tiny and very general reactive GUI library. For a tiny and general reactive GUI library, look at Lit. React, meanwhile, is attempting to become a kitchen-sink.
- steve_adams_86 3y ago
  React promoting the use of frameworks by default is especially problematic because these frameworks are maintained by people who have profit incentives (either due to investor funding and/or because they sell products based around the framework). They aren’t just open source React frameworks; they’re open source products for companies using them as business engines.
- 3y ago

pier25 3y ago

Yeah. The JS world is still so hung up about fat clients having all the control that it's missing all the interesting stuff happening in the server world. Rails Hotwire, Phoenix Liveviews, Laravel Livewire, etc. These solutions can solve 80% of your front end with minimal JS and almost no DX complexity.

TheCapeGreek 3y ago
Preach! I'm still keen to learn more on the Inertia side of Laravel, but Livewire (and especially with Filament in the mix) just feels insanely productive as a Laravel dev.
metadaemon 3y ago
Complexity has to exist somewhere, either in the engineer's hands, or swept under the rug for the framework to perform its magic on (really thinking about the Rails ecosystem here). When things go wrong, it's nicer, in my opinion, to have more control, especially in this fast paced clients-want-it-now environment.
- bob1029 3y ago
  In my experience, the complexity with most frontend development is accidental by way of splitting state between client & server. If you manage to consolidate nearly all state to the server, complexity reduces by an entire dimension. There is nothing to synchronize anymore. You don't need these universes of delta-detection tools, frameworks, protocols, etc. In most of our modern SSR apps, the only state the client needs to hold onto is a session token. If we find the client has a wrong session token, correcting this is quite simple. Everything else happens on the server. Certainly there are holes with SSR (latency), but we haven't run into a real-world scenario where this actually matters enough to introduce entire new universes of hell into our lives.
- worthless-trash 3y ago
  > Complexity has to exist somewhere, What is the complexity you are talking about here, is this the human (programmers) understanding of the system or the design of a complex system itself ?

demondemidi 3y ago

If a framework can support a major revision for longer than 6 months--more like 6 years--they will survive. Otherwise, the road to JavaScript madness is paved with frameworks that never learned LTS is a real thing.

morbicer 3y ago
There's no LTS in React but the components you wrote 10 years ago still works today in latest React. (there are some deprecations but very few)

onion2k 3y ago

I don't expect my preferred JS framework to remain the same though. I know that it's short-lived. I like that. Moving forwards, making progress, and improving are why I use React, Vue, Svelte, etc. I don't want something that's static right now, because none of the available frameworks (including Web Components) solve problems particularly elegantly. If the argument is that a site made with Web Components will outlast a site built with a JS framework then I'd be tempted to take that bet. I honestly think it's more likely that some part of the Web Components tech stack will be removed from Chrome, Safari, and Firefox in the next 20 years, consequently breaking apps built with them, than JavaScript will change in a way that means a React 16 app I wrote 2 years ago will break.

owjofwjeofm 3y ago
Correct me if I'm wrong, but I think running old code and not updating the dependencies might make your site vulnerable to security vulnerabilities that get discovered over time and fixed with new versions of libraries. So if you want to keep your code secure you will need to update libraries. But those old versions of those libraries will stop being supported, and known vulnerabilities will start to accumulate that have no fix. And attackers will probably have programs scan the web for websites with known vulnerabilities and automatically attack them. Versus if you use a library or platform (like Web Components) that cares a lot about backwards-compatibility, they will maintain the security while also supporting your old code for longer.
troupo 3y ago
> I honestly think it's more likely that some part of the Web Components tech stack will be removed from Chrome, Safari, and Firefox in the next 20 years, consequently breaking apps built with them That already happened. HTML Imports got deprecated (in favor of a JS-only solution), though Firefox already implemented them. Custom Elements v0 was deprecated even though Chrome implemented it and hastily re-wrote Youtube with it. They had to wait ~4 years to remove the implementation because it took Youtube that much to switch.
- mdhb 3y ago
  The v0 part of it should mean none of that was a big surprise. It was an early prototype, it’s stable now.

miohtama 3y ago

Why Web Components have not yet taken off? They always sounded like a beautiful solution how to make all the various web frontend frameworks to live peacefully on the same page.

rk06 3y ago
Because they don't come with router, state management and other support. When you start adding them, you will be writing enough glue code that will offset a lot of benefits of web components.
klysm 3y ago
because they have a shitty API
troupo 3y ago
Because they don't offer a lot of things that matter to a lot of folks. This is still true 4 years later: https://x.com/Rich_Harris/status/1198332398561353728?s=20 https://x.com/Rich_Harris/status/1198332398561353728?s=20

Pesthuf 3y ago

Web components might be better for writing isolated and reusable components, but for gluing stuff together to make your application work, the DOM API is just garbage. It was made to edit XML documents and it shows. Also, one reason I don't make web components even for isolated, reusable components: No editor properly picks them up for things like autocompletion of attributes and event names or checks for typos.

sebringj 3y ago

IMO Web Components generally suck in developer experience but are good for bridging different js projects or web frameworks as the web components are very compatible between js frameworks. You can literally make a thin wrapper to expose your js flavored framework-based component such as react for example and expose it as a web component to another system such as angular 1 for example and it will work pretty well. You could potentially use this strategy to have parallel tracks of development where you can create an entirely new framework from scratch and start to share that functionality in the legacy project while you're in the process of upgrading which could take a long long time in some cases. At least you won't be continually working on the old one and adding more tech debt... although one could argue this wrapper approach is tech debt.

mark242 3y ago

[Insert the "now you have 16 standards" joke here]

troupo 3y ago
Web Components is at least 10 already, and will need at least 20 more. No, this is not a joke.
tubthumper8 3y ago
Tools and standards aren't really the same thing

troupo 3y ago

The only reason web components are alive is because Google is pouring literally millions into them. A technology that cannot submit forms without Javascript, still can't create a submit button and whose proponents agree that it still needs 20 more standards to be generally working [1] would be dead within a year. And yet we're here in year 12 of this dumpster fire. [1] Instead of producing a report every year, Web Component Group seems to just update the same document in place, so now it inly lists "4 standards we agreed need to be done ASAP"

locallost 3y ago

The title is probably correct, but not sure it matters. Most applications will not live that long. I recently tried using Web Components, and something that is very simple in any framework like using a <slot> was, um, eh, incredibly confusing and complicated to setup. This maybe doesn't matter if your component is just a <pixelart-demo>, but if you're building an application in JS then using slots is for me a critical feature because it allows me to have composable components. Debugging with "shadow dom" was also really confusing in dev tools.

mmis1000 3y ago
> incredibly confusing and complicated to setup. And some being almost impossible to work correctly without MutationObserver or some polyfill of it. The renderProp in react (or scoped slot in vue) is so commonly used to inject data from the parent component into child component. But replicate such behavior in webcomponent is simply... impossible without MutationObserver hacks. The assumption of web component that child/parent component never need to know the info of each other just don't make sense in real world. And the assumption that child component is always loaded and initiated regardless of parent component is also falsy in most frameworks. In most frameworks, the parent component decided whether child should be actually loaded or initiated.

morbicer 3y ago

I would like to love web components but they are still quite sucky to use (stringy attributes, bleh), especially if it's not your team who produces them. And some super basic stuff like buttons in forms is still an unsolved problem: > Form-associated custom elements: being a submit button https://github.com/WICG/webcomponents/issues/814 https://github.com/WICG/webcomponents/issues/814 opened 4 years ago and representatives of major browsers still don't have an answer

mdhb 3y ago
That form issue is actually resolved with full cross browser support already https://developer.mozilla.org/en-US/docs/Web/API/ElementInternals https://developer.mozilla.org/en-US/docs/Web/API/ElementInte... Also you don’t need to pass objects as HTML attributes, I think people pick that up coming from React but the browser lets you pass around objects between components just fine by using properties
- morbicer 3y ago
  Can you provide me with an example please? I've seen the ElementInternals api but still don't understand how it should help with the case of being able to submit the form by hitting enter in one of the inputs (which is standard html behavior). I wasn't able to find working example anywhere and all the discussions around the issue are still open which leads me to an assumption that this is in fact, still unsolved. https://lit.dev/playground/#project=W3sibmFtZSI6InNpbXBsZS1ncmVldGluZy50cyIsImNvbnRlbnQiOiJpbXBvcnQge2h0bWwsIGNzcywgTGl0RWxlbWVudH0gZnJvbSAnbGl0JztcbmltcG9ydCB7Y3VzdG9tRWxlbWVudCwgcHJvcGVydHl9IGZyb20gJ2xpdC9kZWNvcmF0b3JzLmpzJztcblxuQGN1c3RvbUVsZW1lbnQoJ215LWJ1dHRvbicpXG5leHBvcnQgY2xhc3MgU2ltcGxlR3JlZXRpbmcgZXh0ZW5kcyBMaXRFbGVtZW50IHtcbiAgc3RhdGljIGZvcm1Bc3NvY2lhdGVkID0gdHJ1ZTtcblxuICBAcHJvcGVydHkoKVxuICBuYW1lID0gJ2Zvbyc7XG4gIFxuICBjb25zdHJ1Y3RvcigpIHtcbiAgICBzdXBlcigpO1xuICAgIHRoaXMuYXR0YWNoSW50ZXJuYWxzKCk7XG4gIH1cblxuICByZW5kZXIoKSB7XG4gICAgcmV0dXJuIGh0bWxgPGJ1dHRvbiB0eXBlPVwic3VibWl0XCI-JHt0aGlzLm5hbWV9ITwvYnV0dG9uPmA7XG4gIH1cbn1cbiJ9LHsibmFtZSI6ImluZGV4Lmh0bWwiLCJjb250ZW50IjoiPCFET0NUWVBFIGh0bWw-XG48aGVhZD5cbiAgPHNjcmlwdCB0eXBlPVwibW9kdWxlXCIgc3JjPVwiLi9zaW1wbGUtZ3JlZXRpbmcuanNcIj48L3NjcmlwdD5cbiAgPHN0eWxlPmJ1dHRvbiB7Y29sb3I6cmVkfTwvc3R5bGU-XG48L2hlYWQ-XG48Ym9keT5cbiAgPGZvcm0gb25zdWJtaXQ9XCJhbGVydCgnd29ya3MhJylcIj5cbiAgICAgIDxpbnB1dCBuYW1lPVwiYmFyXCI-XG4gICAgICA8aW5wdXQgbmFtZT1cImJhelwiPlxuICAgICAgPG15LWJ1dHRvbiBuYW1lPVwic2hvdWxkIHN1Ym1pdCBvbiBlbnRlciBidXQgZG9lc24ndFwiPjwvbXktYnV0dG9uPlxuICA8L2Zvcm0-XG48L2JvZHk-XG4ifSx7Im5hbWUiOiJwYWNrYWdlLmpzb24iLCJjb250ZW50Ijoie1xuICBcImRlcGVuZGVuY2llc1wiOiB7XG4gICAgXCJsaXRcIjogXCJeMy4wLjBcIixcbiAgICBcIkBsaXQvcmVhY3RpdmUtZWxlbWVudFwiOiBcIl4yLjAuMFwiLFxuICAgIFwibGl0LWVsZW1lbnRcIjogXCJeNC4wLjBcIixcbiAgICBcImxpdC1odG1sXCI6IFwiXjMuMC4wXCJcbiAgfVxufSIsImhpZGRlbiI6dHJ1ZX1d https://lit.dev/playground/#project=W3sibmFtZSI6InNpbXBsZS1n...

ent101 3y ago

We wrote Puter.com in vanilla js and it's been pretty straight forward. tbh most of the complexity is coming from the backend rather than the frontend.

taeric 3y ago

But will Web Components of tomorrow be the same as the ones today? I see that, in today's parlance, this is 3 core ideas. Custom elements, shadow DOM, and templates. I fully expect things to be added to that list as time goes on. Not the least because of so many obvious things that are not covered there. To that end, the question will have to be if you can run the same web components of today on a browser of tomorrow. With the very notable fact that though you can't run components on browsers of yesterday, you can run that old jquery site on browsers of today.

DrScientist 3y ago

The web component idea originally had something like 4 basic components. - custom elements - shadow DOM - html imports ( now dead or at the very least 'resting' ) - html templates I think it's important to note that you can build/use custom elements ( defining your own tags with encapsulated behaviour ) without having to use shadow DOM nor html templates. So a simple way to start, in my view, is plain custom elements, mixed in with ES modules and import maps. Shadow DOM and html templates are not compulsory to get your <custom-tag></custom-tag>

raspo 3y ago

I think the author was referring about the specific use-case of building a website using static file generators. In that context I 100% agree with him that if you want to sprinkle some interactivity while keeping your content "portable" and be able to move to the next "CMS" of the future, sticking with web components is a much wiser choice, rather than embracing whatever fancy convenient feature your tool provides (like Astro's islands). (It is good advice and a well written article btw, thank you for sharing) I don't think he was suggesting to build your next SPA entirely with web components..

jakelazaroff 3y ago
Author here — yes, this is exactly correct (and thank you for the kind words). I think the maintenance cost of dependencies is important to consider, and with web components we have a "native" solution for encapsulating HTML, CSS and JS. That doesn't mean that every project needs to have that as its top priority! Sometimes development velocity/shared patterns/ease of finding other developers is more important, and that's perfectly fine.

btbuildem 3y ago

I find it interesting that the author's premise seems motivated by a self-inflicted churn. Having migrated a simple blog across a dozen of technologies, their conclusion is that <basic building blocks> will outlast any trend? Surely, yes. But I'd like to observe that a blog like this, one of the simplest web-based entities, could have remained implemented in some of the decades-old technologies and delivered the same experience to the end user.

nathias 3y ago

There are so many downsides of choosing web components you really need a very rare usecase to justify them. They are an artefact of a time we're all glad to be done with, they force you into OOP so you're doing inheritance acrobatics, add TS and now you're feeding two hierarchies of inheritance that don't quite match and bloat to a 80% of your codebase, making it unreadable, prone to hacks and bugs, impossible to maintain etc. The point of web components was to make components more shareable between frameworks, and code more reusable, but now code written in any of the major FE frameworks is more reusable (a component looks pretty much the same in React, Vue, Svelte, but not with web components).

yellow_lead 3y ago

My problem with web components is the jitter they introduce when rendering the page. Sure, you can hide this or fade it with CSS, but it's kind of a dealbreaker for me. Maybe someone can suggest a better workaround? For instance, on the submitted page, I see a jitter for the pixelart-demo component.

merelysounds 3y ago

I also like reducing dependencies, but I’ve picked a different approach. When I use an external library, I link to static production scripts, without webpack or other bundler. I do use babel to handle jsx if needed, but I do it by linking babel via a script tag in dev mode (and with a simple shell script in production). It’s more radical, not recommended for production use and impractical for anything other than a hobby project. But it’s a way to limit adding new dependencies, or limit reliance on package managers. Additionally, the project can work with as much as a static file server, also for development - so I won’t get stuck on an “npm update” when I return to a project after a break. Most recent website I’ve built like this is: https://merely.xyz/lenses https://merely.xyz/lenses , list of Sony E Mount FF lenses. Again, for most cases web components sound like a more practical approach, I plan to explore that long term too.

iamcreasy 3y ago
That's exactly what I've been trying to do for the last few days but get frequently hit by simple JS errors such as import failures, and currently I don't have the time to properly learn the language. Looking for a way to learn enough to get something up and running. Do you know any source that explains using React this way? I've looked into the source of merely.xyz but I am looking for something simpler that holds your hand.

npteljes 3y ago

I shifted my focus from technology to people. If I'm starting a new project, I'll look at what the people who'll work on the project know. If there's a common denominator or best practice, like how React is nowadays for frontends, I'll just go with that. I don't really sweat these technical decisions, because the team composition, or the job seekers' market, or StackOverflow's technology top list answers there questions with ease.

josephg 3y ago
I get that and I think it’s pragmatic. But if everyone thinks like you’re suggesting, we’ll all be using react forever, even if there are better answers out there for how to build our software. If you want to use whatever is popular, that means you depend on others to find good technology solutions and make them popular in order to improve your tech stack. Put another way, this strategy puts you firmly in the “mid to late adopter” part of the adoption curve. Articles like this (and indeed much of this discussion) is largely targeting people who are earlier adopters.
- npteljes 3y ago
  I think you hit the nail on the head on the adoption curve point. I indeed am a later adopter, and lately consciously so.

sandreas 3y ago

If you combine native WebComponents with scss and JSX/TSX, it gets even better. As an example you could take a look at an older project on github: https://github.com/cyco/WebFun/ https://github.com/cyco/WebFun/ Here is some example code: https://github.com/cyco/WebFun/blob/ec42d59b99d62daafea3ccce5caa254c5e99b600/src/app/webfun/ui/ammo.tsx#L4 https://github.com/cyco/WebFun/blob/ec42d59b99d62daafea3ccce... https://github.com/cyco/WebFun/blob/ec42d59b99d62daafea3ccce5caa254c5e99b600/src/app/webfun/ui/error-view.tsx https://github.com/cyco/WebFun/blob/ec42d59b99d62daafea3ccce...

joduplessis 3y ago

In adjacent news, I love that typeface.

esafak 3y ago
It's Peachi: https://www.mycreativeland.com/peachi-serif-font-family https://www.mycreativeland.com/peachi-serif-font-family Apparently based on https://en.wikipedia.org/wiki/Souvenir_(typeface) https://en.wikipedia.org/wiki/Souvenir_(typeface) See also https://fly.io/ https://fly.io/

zubairq 3y ago

Great article. Really made me think. But don’t webcomponents lack properties and functions that can be embedded in tooling ?

wg0 3y ago

I just got to know that svelte components can be complied into web components. If so, then probably using svelte as a compiler for web components can be one way to do things. Not sure about routing though. Maybe page.js or something. Even for vanilla js, till might need vite, postcss, tailwind in some cases.

gitaarik 3y ago

From the comments I see here, it seems like many people expect the Web Components API to be a complete replacement for a JS framework. The thing is, our frameworks should start making more use of modern web APIs, so the frameworks will have to do less heavy lifting themselves, so they can become smaller, so our projects are dependent on less framework code. Lit [0] for example is doing this. It's a very small library, making use of the Web Components APIs. Using Lit is very similar to using React. Some things work different, and you have to get used to some web component specific things, but once you get it, I think it's way more pleasant to work with than React. It feels more natural, native, less framework-specific. For state management, I created LitState [1], a tiny library (really only 258 lines), which integrates nicely with Lit, and which makes state management between multiple components very easy. It's much easier than the Redux/flux workflows found in React. So my experience with this is that it's much nicer to work with, and that your total project size is much smaller. [0] https://lit.dev/ https://lit.dev/ [1] https://github.com/gitaarik/lit-state https://github.com/gitaarik/lit-state

troupo 3y ago
> The thing is, our frameworks should start making more use of modern web APIs, so the frameworks will have to do less heavy lifting themselves They already do that wherever possible. However, web componens provide almost exactly zero value to frameworks. You could ask a simple question: why did the authors of Vue, Svelte and Solid started as staunch supporters of web components (and even modeled early versions of their frameworks after them), and why are they now at best indifferent and at worst actively hostile towards web components? > It feels more natural, native, less framework-specific. If you ignore all the framework-specific things like custom template DSL, custom JS DSL, custom functionality like contexts and the new custom compiler, it's very native.

nojvek 3y ago

Webcomponents will outlive React 13? Sure. Will they outlive React entirely or its cousins like Solid and Svelte? Perhaps not. Webcomponents and React look like they solve the same problem but they do not. Webcomponent api is pretty shallow. You get connected/disconnnected/attributeChanged call back but gotta write your own property setter and getters, slots, template, shadow dom and that’s mostly it. Shadow dom becomes a pain to work with if something needs to pierce it. No built-in webcomponent api for efficiently applying state changes to dom. All attributes have to be strings and other types need to be parsed. Mixpanel went all in on webcomponents. They made their own framework on top of webcomponents. https://github.com/mixpanel/panel https://github.com/mixpanel/panel Worked on panel lib and webcomponent UI for many years. Webcomponents are not a silver bullet. The issue with webcomponents is there are a ton of libraries that fill in the missing gaps. There’s not a lot you can do with pure vanilla webcomponent api. Google has their own thing, Microsoft had multiple internal libs across orgs, Reddit does their own thing. The most standard thing for frontend with wide adoption right now is React. vanilla webcomponents are good for simple widgets in a vanilla html/css page. To build complex single page applications, would not recommend it. You’d be building you’re own bespoke framework to fill in the gaps.