Our great sponsors
-
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
web-components-examples
A series of web components examples, related to the MDN web components documentation at https://developer.mozilla.org/en-US/docs/Web/Web_Components.
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
From the comments I see here, it seems like people expect the Webcomponents API to be a complete replacement for a JS framework. The thing is, our frameworks should start making use of modern web APIs, so the frameworks will have to do less themselves, so can be smaller. Lit [0] for example is doing this. 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 the libraries are way smaller.
[0] https://lit.dev/
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
[2] https://github.com/mdn/web-components-examples/blob/main/edi...
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
[2] https://github.com/mdn/web-components-examples/blob/main/edi...
> 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)
I 100% agree with this. For me it was more of a question of "can I do it", and that was something I wanted to find out. You notice that I ended up having to recreate a significant chunk of lit-like functionality on my own via a base class: https://github.com/jjcm/nonio-frontend/blob/master/component...
I would very much recommend not going full vanilla. Using a library like lit will definitely help making things easier/more polished, and will integrate better with existing tooling.
One approach I don’t mind is to just make a HTML file per screen in the application and route like the rest of the web.
When you bring in modern things like service workers and the prefetch API you can still very much keep the speed that is traditionally associated with SPAs.
Otherwise I’ve seen good things said about both of these options:
1. https://github.com/vaadin/router
Webcomponents will outlive React 13, mostly likely. 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, and that’s mostly it. Shadow dom becomes a pain to work with if something needs to pierce it. Can’t pass nested objects in attributes, gotta encode as string.
Mixpanel went all in on webcomponents, but had to build a whole bunch of lib tooling around it. They made their own framework on top of webcomponents. https://github.com/mixpanel/panel
Worked on panel lib and webcomponent UI for many years. It is 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 since browsers don’t provide efficient dom updating mechanism. 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.
So the way I see it, is that React has already outlived webcomponents.
Since you mention that state management is an unsolved problem with Web Components, I thought I would share a project that aims to bring a solution: https://github.com/launchscout/live_state. The basic pattern and idea of LiveState is "dispatch events, subscribe to state". The events and state updates are sent over a websocket connection, and the front end and back end libraries are a thin layer over Phoenix Channels. Currently, event handler functions are written in Elixir, but work is underway to allow them to be written in any language that compiles to WebAssembly.