101–110 of 180 posts
Lit maintainer here. I should be going to bed, but I'll answer any questions if people have any! Not sure why Lit showed up on the front page tonight :)
https://news.ycombinator.com/item?id=45107388
I assume someone else looked it up and liked it enough to submit it.
Earlier quoted context omitted.
I don't know if there is a particular benefit, it's just different. On the consumer side there is no difference, because they consume Web Components, and that is what both solutions deliver. On the implementation side, I can think of a few differences: 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 lea…
Vue can be used as an ordinary JS library without special build setup. You can even load the library from a CDN as a global variable like the old jQuery days.
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/
I made a state management lib for Lit, that's just as lightweight (258 lines) and intuitive: 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 r…
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.
Earlier quoted context omitted.
That’s also why I really like Aurelia framework. Its component model feels very intuitive, and it embraces standards like custom elements and decorators instead of inventing new patterns. Compared to Angular’s boilerplate or React’s hook gymnastics, Aurelia lets you write less code that looks more like plain JS/HTML. Too bad Aurelia never got the same traction as the big frontend names, because the DX is really solid…
I thankfully migrated or left all Aurelia projects, but every time someone mentions it, I remember new horror stories. Its .html temples were shipped unmodified directly to the client (yes, including comments). Except they weren't actually html, and sometimes the browser would try to clean them up, breaking the template. Reactivity was achieved through all kinds of weird mechanisms (eg monkey-patching arrays to watch…
And yeah, probably they monkey-patched arrays and such, but that was just the way of the world before proxies and native signals. The cool part is Aurelia stuck to web standards, and those “weird mechanisms” were basically polyfills, so even old versions still run solid today, sometimes even faster by leveraging native features.
Does Lit have a good component library? Like, a complete web template (eg. Bootstrap/Ant), datepicker, color picker, virtual scroll, data tables, typeahead, tab, etc. I shipped a project with Lit and I liked it, but I didn't like that I'd need to know the complete project scope up front that I could write everything from the ground up. I know I could use React component for some of the harder stuff but at that point…
DaisyUI and HyperUI, which are both full component libraries based on tailwind, play well with lit. You either opt out of using the shadow dom or import the global styles into the component. Both methods have official lit support.
Earlier quoted context omitted.
Vue can be used as an ordinary JS library without special build setup. You can even load the library from a CDN as a global variable like the old jQuery days.
Thought I'd add an example: 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?
Earlier quoted context omitted.
Same here. I have actually wrote a few web components by hand in an environment where I didn't want any external dependencies and when that requirement was dropped I really liked how easy was to convert them to LitElement (and how much nicer it is to work with them). I also have embraced the shadow DOM which is a default, but I think it's more trouble than it's worth. Now I use LitElement without shadow DOM and it wo…
Same about the shadowDOM. The only criticism I have about Lit is that the creators think shadowDOM is amazing and people not liking it are using it wrong. Lit lacks a good direction and someone with vision leading it but it became the technical pet project of a few.
It's trivially easy to create Lit components without shadow DOM so I don't really care and use both.
Lit maintainer here. I should be going to bed, but I'll answer any questions if people have any! Not sure why Lit showed up on the front page tonight :)
I had lit in a project at work and not having to deal with it anymore is just great. We already have another heavier component framework to do the actual application stuff anyway, so having two just because somebody wanted to optimize their resume was such a drag. It all looked nice in theory, but one thing shadow DOM makes worse is A11y, because element ids are now scoped and all the missing describe-by, label-for f…
Shadow DOM is optional in Lit - you can just disable it on a per-component basis.
Earlier quoted context omitted.
I think web components already compete extremely well for application development, and you see very complex apps built with Lit out there: Photoshop, Firefox, Chrome OS, Chrome DevTools. Apps are well served because they have more control about how components are used: they can import the same shared styles into every component, take are to not double-register elements, etc. But I think there are some important stand…
> - Open styleable shadow roots 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.