Readit NewsTax on income is not the problem, it's tax on wealth gained through asset value increase.
What people using web components want is to get rid of shadowDOM and not feel like they are deviating from the correct path. shadowDOM sucks, stop trying to convince the world that we are using it wrong. shadowDOM is the whole reason web components did not become mainstream (yet?).
All frontend "frameworks" do have some sort of solution to scope CSS to individual components, and without a similar solution, a native component system would not be viable. The implementation has its quirks, but it is a core capability that is necessary for some use cases. For third-party widgets or cross-application components like design systems, the ability to isolate your component from the site it is embedded in is very useful.
Think of shadowDOM as the web component alternative to scoped styles in Vue components (as an example). You don't have to use it, but it would be incredibly inconvenient if it wasn't included in the framework.
https://github.com/SaleCar/Quasar-UMD-Template
You can do sophisticated things as well eg. Stream half a million Kafka records into the browser- anything available from unpkg or other cdns.
A good cdn UI lib turns out to be https://quasar.dev/
Vue _does_ have some sort of build step, because components use special macros that aren't imported, and the compiler (vite) even complains when you actually import them saying it's not necessary. The build also rewrites your code to some other format that I assume is more optimized because it can do some sort of static analysis.
Are these the main reasons for Vue to use a compiler if it's not necessary? Injecting dependencies and rewriting some code to allow better performance while retaining the nice syntax?
https://github.com/gitaarik/lit-state
I've used it extensively myself, for creating complex web apps with many (nested) components interacting with each other.
I don't understand why Lit hasn't gained more popularity, because for me it is basically React, but then more browser-native, much less boiler plate, and much faster rendering. There are some things you have to get used to, but when you do it doesn't limit you in any way.
I made this alternative implementation of lit-html to use as a research bed a long time ago when I was actively contributing to lit: https://github.com/ruphin/lite-html
Judging from this thread, many people have their own implementations, which is great to hear. I think there's a lot of value in solutions that are so simple that anyone can reproduce them.
I guess for most people the standard is to install things from NPM
replace 'lit' with something like this:
https://unpkg.com/lit@3.3.1/index.js?module
That isn't a criticism of projects that don't use npm, and it doesn't make them less valid, but it makes sense for the documentation to match the average developer's experience.
https://unpkg.com/lit@3.3.1/index.js?module
You can even dynamically import that in the a running browser console and use it directly on any webpage.
Looking at the first example:
First I had to switch it from TS to JS. As I don't consider something that needs compilation before it runs to be lightweight.
Then, the first line is:
import {html, css, LitElement} from 'lit';
And when I use the "download" button on the playground version of the first example, I get a "package.json" which defines dependencies. That is also certainly not something a browser can handle.
So do I assume correctly that I need to set up a webserver, a dependency manager, and a serverside runtime to use these "light weight" components?
Or am I missing something? What would be the minimal amount of steps to save the example and actually have it run in the browser?
https://unpkg.com/lit@3.3.1/index.js?module
You can even dynamically import that in the a running browser console and use it directly on any webpage.
What would be the benefit of rebuilding these components in Lit over using Vue to build them?
https://vuejs.org/guide/extras/web-components#building-custo...
Vue is more of a "framework" solution and has more things built-in. You can do the same things with Lit, but the implementation would look different, because you'd lean more on native APIs. A good example of that is the event model, Vue has some event model built in, but with Lit you would use EventTarget.dispatchEvent().
Lit is a runtime solution, it doesn't require a build and you can load your source directly in the browser. Vue on the other hand requires some form of compiler stage to produce something your browser can use. Compilers these days are fast, and Lit is specifically engineered to not have runtime performance overhead, so in practice this difference is rather minor. It is a very fundamental difference, so I think it's worth pointing out.
Vue can compile to other targets. If you are only delivering Web Components, this is mostly irrelevant, but in theory a consumer might be able to use the Vue components directly in their Vue project, which might give them a better DX. On the other hand, Lit is specifically designed to produce Web Components, so you'll probably have a bit less friction compares to using Vue, e.g when some Vue concept doesn't compile cleanly to Web Components.
Is there a major benefit to choosing one implementation over the other? I don't think so, unless you have a very particular requirement that one of them addresses that the other doesn't. For nearly all cases, it is just a different implementation syntax.
In most cases the only relevant metric in deciding between them is what technology your developers are more familiar/comfortable with.
You can find the logo here, along with the excellent soundtrack: https://alexanderbrandon.bandcamp.com/album/tyrian-original-...