Our great sponsors
-
cami.js
Cami.js is a simple yet powerful toolkit for interactive islands in web applications. No build step required.
-
htm
Hyperscript Tagged Markup: JSX alternative using standard tagged templates, with compiler support.
-
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.
-
select2
Select2 is a jQuery based replacement for select boxes. It supports searching, remote data sets, and infinite scrolling of results.
-
-
marimo
A reactive notebook for Python — run reproducible experiments, execute as a script, deploy as an app, and version with git.
-
-
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.
-
-
-
Filestash
🦄 A modern web client for SFTP, S3, FTP, WebDAV, Git, Minio, LDAP, CalDAV, CardDAV, Mysql, Backblaze, ...
-
Preact requires a build step otherwise you don't get JSX and you have to build applications a la mithril.js mode:
> const app = h('h1', null, 'Hello World!');
With Web Components no build step is required and you're still able to build JSX'ish code. See the code below this section: https://github.com/kennyfrc/cami.js#key-concepts--api
You can use the htm library as a pure client-side jsx: https://github.com/developit/htm
It is not completely the same, but far better than that h function madness.
For me, that's the beauty of Web Components. You can find (or build) a base class that works the way you need it. I like a React class component style class with an XState-inspired state machine built in.
https://github.com/codewithkyle/supercomponent/blob/master/s...
Most people using react aren't building SPAs. Vue/React can be used the same way as jquery, which is to add enhanced UI functionality that server-side HTML views simply can't offer.
The best example is a multi-select box, or a searchable select box with autocomplete (what W3 calls the combobox pattern https://www.w3.org/WAI/ARIA/apg/patterns/combobox/) which in jquery was usually via https://select2.org/
For example, on my company website there's a timezone select box with are 151 options. Asking a user to simply scroll through 100+ to find theirs is annoying vs typing a few characters and hitting enter.
There's many examples of select boxes like that and there really is no static server-side way to solve this problem (I tried hard to think of one)... without creating a multi-page Wizard for what should be a single field on a larger form.
If you're building a SaaS product there are many highly-interactive components that demand JS and there's really no better mainstream solution atm than static-first sites with small "islands" of Vue/React style components (ideally with hydration) where interactivity is required.
People still abuse React/Vue of course, but the trend is 100% moving back to "mostly static" rather than slow SPAs and IMO JS-powered components are not never going away unless browsers start offering these complex components built-in.
Am I misreading this or is it what https://htmx.org/ provides?
We use web components in our project (a reactive Python notebook that, among other things, lets users build simple web apps [1]) to make it easy for the user to instantiate and compose our UI elements. Users can easily interpolate these elements into markdown, for example, since their representation is just HTML.
[1] https://github.com/marimo-team/marimo
I am more a fan of the augmented style because it doesn't entrap you in dev lock-in to platforms.
The problem with frameworks, especially web frameworks, is they reimplement many items that are standard now (shadowdom, components, storage, templating, base libraries, class/async, network/realtime etc).
If you like the component style of other frameworks but want to use Web Components, Google Lit is quite nice.
Google Lit is like a combination of HTML Web Components and React/Vue style components. The great part is it is build on Web Components underneath.
[1] https://lit.dev/
I've recently just started playing with Web Components without a build environment. Meaning, no npm, no bun, no webpack, etc, and no dependencies; in typescript. Intellij can autocompile down to js and the browser view injects a small onchange handler for live updates when developing. So far no problems.
The only thing holding web components back seems to be HTML Modules; being able to link to a .html file instead of a .js file to import a web component. Because of this if you want to use templates or anything more complicated you need to do the ugly inject of .innerHtml = `...`, which I thought would be a problem but the IDE parses the template string very nicely. It would be great to make a component in HTML and any javascript you would put in a tag. It seems like there a lot of bureaucracy involved in getting HTML Modules out the door since its been eight years.<p><a href="https://github.com/WICG/webcomponents/blob/gh-pages/proposals/html-modules-explainer.md#high-level-summary">https://github.com/WICG/webcomponents/blob/gh-pages/proposal...</a>
Web Components are extremely powerful. I built a chat app with authentication with 2 different blockchains, GitHub OAuth login and access control using only 120 lines of HTML on a single page with no framework:
https://github.com/Saasufy/chat-app/blob/main/index.html#L23...
You can try the app here (if you have GitHub): https://saasufy.github.io/chat-app/
The backend is serverless built using Saasufy.com - The platform/startup I'm working on currently: https://saasufy.com/
> This feature of web components encourages a design of composability.
I am not a React, Vue (and friends dev) at all. Heck, I haven't done front-end or full stack for a long time now.
However, taking React as an example, where does it not encourage composability?
I like Web Components. I even spent the last couple of weeks playing only with the vanilla APIs (no Lit, etc.) just to see what is like:
https://lpedrosa.github.io/blog/web-components-part-3/
https://github.com/lpedrosa/webcomponents-blog-examples
Like many other people have pointed out in this post, it is great that you can leverage the platform. All the things you will learn e.g. DOM APIs, native elements and events, etc., are things you can carry over to React and Vue.
However, I believe articles like this fail to acknowledge the contribution React and friends brought to developer experience.
Building complex desktop like UIs was no longer impossible to maintain. You can easily make components and compose them, customise them, etc.
The general complaint is more around "you don't need Next.js" to build a news/marketing/blog website. The pendulum is swinging, especially with things like HTMX gaining traction.
IMO, people do it because:
- It's easier to hire developers that know the framework du jour
- Custom Elements are very flexible, so it's hard to enforce a particular style
- There aren't enough examples of people using vanilla Web Components (and I mean vanilla, not Lit and friends), so why use a web component framework when I can use a react based one?
Write more about how we can combine things like Custom Elements and "traditional" server side templating.
Write more about how a native element reacts to changes to its attributes or how it communicates user interaction and how that helps building a good custom element.
Or how building a good custom element is similar to building a good React component, and where it differs.
Antagonising existing knowledge or even the status quo, is not constructive and leads to poor discussions e.g. Web Components is a failed technology or articles like OP
I do use them on my OSS work (https://github.com/mickael-kerjean/filestash/tree/master/pub...) which is used by many thousands of people
There is a polyfill for customiziing built-ins on Safari.
https://github.com/ungap/custom-elements