lit-state
lit-style
lit-state | lit-style | |
---|---|---|
3 | 1 | |
137 | 9 | |
- | - | |
0.0 | 10.0 | |
over 1 year ago | over 1 year ago | |
JavaScript | JavaScript | |
GNU Lesser General Public License v3.0 only | GNU Lesser General Public License v3.0 only |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
lit-state
-
Web Components Eliminate JavaScript Framework Lock-In
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
- Web Components Will Outlive Your JavaScript Framework
- Litstate Simple Shared App State Management For
lit-style
-
Web Components Eliminate JavaScript Framework Lock-In
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
What are some alternatives?
lit - Lit is a simple library for building fast, lightweight web components.
WebComponentFactory - Make use of JavaScript web components while keeping your code in .html for LSP features
kor - User Interface Component Library based on LitElement / lit-html
butterfloat - The greatest view engine for the modern web
panel - Web Components + Virtual DOM: web standards for powerful UIs
lrnwebcomponents - HAXTheWeb monorepo of elements and apis
Kiss! - :hash: :wrench: Shareable agnostics templates (Keep It Stupid Simple) / Integrated with Atom IDE #cli #nodejs #atom
cable-shared-worker - ActionCable and AnyCable Shared Worker support
nonio-frontend
router - Small and powerful client-side router for Web Components. Framework-agnostic.