Web Components Eliminate JavaScript Framework Lock-In

• webcomponents

  34 4,314 4.4 HTML

  Web Components specifications

  

- Scoped styling (Shadow DOM + User defined stylesheets + CSS parts)

It is definitively not a templating engine. It doesn't provide any new APIs for creating DOM nodes, or mutating them a la React or handlebars or lit-html. Templating is basically the "next step up the stack". Using shadowDom.innerHTML = `...`; is basically a stand-in for having an actual templating engine.

There is work going on, developing a native templating system in the browser which may interest you. It's called the DOM Parts proposal and you can find info on it here: https://github.com/WICG/webcomponents/blob/gh-pages/proposal...

• lit

  141 17,535 9.4 TypeScript

  Lit is a simple library for building fast, lightweight web components.

  

I work on Lit, which I would hesitate to call a framework, but gives a framework-like DX for building web components, while trying to keep opinions to a minimum and lock-in as low as possible.

It's got reactivity, declarative templates, great performance, SSR, TypeScript support, native CSS encapsulation, context, tasks, and more.

It's used to build Material Design, settings and devtools UIs for Chrome, some UI for Firefox, Reddit, Photoshop Web...

https://lit.dev if you're interested.

• SurveyJS

  surveyjs.io sponsored

  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.

  

• joystick

  49 194 9.7 JavaScript

  A full-stack JavaScript framework for building stable, easy-to-maintain apps and websites.

  

There is. I was frustrated by all of the chaos and built a solution [1]. Not too far of from an RC1 and then a 1.0 (which is being done slowly so I can freeze APIs and avoid the typical JS rug pulls).

[1] https://github.com/cheatcode/joystick

• WebComponentFactory

  1 0 4.2 JavaScript

  Make use of JavaScript web components while keeping your code in .html for LSP features

  

Rather than putting the HTML in JS, you can fetch HTML in the JS.

E.g. https://github.com/g-utils/WebComponentFactory

• nano

  5 1,411 5.6 TypeScript

  🎯 SSR first, lightweight 1kB JSX library. (by nanojsx)

  

• React

  1,694 221,803 9.9 JavaScript

  The library for web and native user interfaces.

  

You can render the view from scratch on every user interaction, even in MVC. In fact, you can use React for that purpose. "Lots of people use React as the V in MVC." See: https://github.com/facebook/react/tree/015833e5942ce55cf31ae...

Personally, I have not run into large amounts of bugs of this type, and I have written plenty of MVC code using VanillaJS.

• butterfloat

  4 6 9.2 TypeScript

  The greatest view engine for the modern web

Just because on most modern hardware file I/O has millisecond latency and feels synchronous doesn't mean it is synchronous. It might feel like overkill to use Observables instead of Promises and I/O event loops or even thread-blocking faux synchronous file system calls, but there is still an asynchronous world there where it can be nice to have the full power of Observables. To be fair, my love affair with Observables started in C# in "backend" applications, so that's always been the natural fit for me and frontend and UI work has been the "side hustle" of taking stuff that I love in the backend side of the house and putting it to even more use.

I'm calling my view engine Butterfloat, and I only just finished the first documentation pass, so be gentle, but feedback is very welcome: https://github.com/WorldMaker/butterfloat

• InfluxDB

  www.influxdata.com sponsored

  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.

  

• lit-state

  3 129 0.0 JavaScript

  Simple shared component state management for LitElement.

The reason React uses a virtual DOM is because when React started, there were no (advanced) HTML templates yet. And it made it easy to setup listeners on elements, instead of manually adding it with `addEventListener()` and possibly remove them again with `removeEventListener()`. So the virtual DOM was really a game changer.

But Lit templates solve this problems in a more browser integrated way, without the need of a virtual DOM. How you manage the state is free to your choice, that is also not something exclusive to React and your favorite pattern can also be used with Lit. I wrote a tiny state management library (LitState [0]) which makes it very easy for multiple components to share the same state and stay in sync. I personally find it much more convenient and cleaner than any other state library I've used before. And it integrates very nicely with Lit.

[0]: https://github.com/gitaarik/lit-state

• lit-style

  1 9 10.0 JavaScript

  Shared component styles for LitElement

I will read those links you referenced later. But what I think about the Shadow DOM is that that is for me actually the killer feature. That prevents a lot of weird issues. But it also brings limitations to methods of how web developers are used to do things, like applying styles globally, or having some sort of dependency between deeply nested elements, crossing the Shadow DOM when using Web Components.

What people usually try to do is to somehow open up the Shadow DOM for certain things, to make some things allowed to pass, or global. But I think might be a bit holding on to an old familiar habit. And I think there are better ways of structuring a project with Web Component in mind.

For example, you can create a base class from which all your components extend, and put the base style in that base class, and have your components add style on top of that. I implemented this method in a tiny library which makes it easy to use [0].

But yeah it is hard for most developers to adopt a new way of thinking. And as long as the new way doesn't provide that much improvement over the old way, it won't get adopted. But I think the idea of Web Components still needs to be integrated more in the web dev community. And maybe they will manage to make some changes to make the adoption easier.

And besides that, of course Web Components still have lots of other issues. But for me it has reached a point where I don't feel the need for React anymore. I rather live with some quirks in Lit than doing things with React, which just feels clumsy to me now.

[0]: https://github.com/gitaarik/lit-style

Suggest a related project