stencil VS lit

Web component browser APIs aren't that many, and not that hard to grasp (if you don't know about them, have a look at Google's Learn HTML section and MDN's Web Components guide); but creating a web component actually requires taking care of many small things. This is where web component libraries come in very handy, freeing us of having to think about some of those things by taking care of them for us. Most of the things I'll mention here are handled one way of another by other libraries (GitHub's Catalyst, Haunted, Hybrids, Salesforce's LWC, Slim.JS, Ionic's Stencil) but I'll focus on Google's Lit and Microsoft's FAST here as they probably are the most used web component libraries out there (ok, I lied, Lit definitely is, FAST not that much, far behind Lit and Stencil; but Lit and FAST have many things in common, starting with the fact that they are just native web components, contrary to Stencil that compiles to a web component). Both Lit and FAST leverage TypeScript decorators to simplify the code even further so I'll use that in examples, even though they can also be used in pure JS (decorators are coming to JS soon BTW). I'll also leave the most apparent yet most complex aspect for the end.

Look into https://stenciljs.com/ .

We used https://stenciljs.com/ for web components to be consumed by angular, AEM and react at a previous employer. It uses tsx/jsx. Components are easy to write and it has good documentation.

For the creation of web components, even though writing in vanilla js is an option, we have chosen to do it via a dedicated framework, which will solve many potential integration/bundling problems. The choice of the framework will be made according to different factors that are not part of the scope of this article.

Maybe have a look at Stencil (+ Ionic). https://stenciljs.com/

Pro:

- Simple to learn

- Doesn't change all the time

- First-class TypeScript support

- Good default UI via Ionic

- Compiles to Web Components (although to be honest, this doesn't really matter)

- Easy testing

- Ionic as a company invests in Ionic the framework + Stencil the compiler. Might be around in 10 years, altough things could change. But this is true for all frameworks.

- You basically get an iOS/Android app for free, if you just dump the output in Capacitor (also developed by Ionic the company).

Cons:

- Stencil is not very widespread as a frontend framework.

because react-native is only reactlike. I may or may not want to stick with that. I think something like this is leading us towards a better and less UI lib specific approach. https://github.com/ionic-team/stencil/ . I don't think is 100% where we end up, but it is based on web components, so it's moving the entire ecosystem forward, not just a slice of it.

The app is built using vanilla Web Components without using any component publishing libraries like Stencil, Lit and so on. The reason being I met with some roadblocks in building a drag-n-drop editor using these libraries. Actually the Crayons Team itself is using Stencil to build the Crayons components using TypeScript and React-like component semantics and finally publish them as platform native Web components and React wrappers for the same. You can find out more about this in the Stencil documentation.

Stencil

This might sound very similar to the work the Ionic team did with Stencil. The one main difference is that we're not just outputting web components. Rather full framework-ready JavaScript. You can even compile the output to Stencil as well.

While you can build components directly from the supporting Web APIs, you might find it productive to use a library that's been built to support this task. Lit and StencilJS are two of several libraries with acompanying tooling to help you build web components. And because they compile to the same 'target', they give you an additonal advantage: if you choose to switch web component libraries at some point in the future, you can make the switch for new components without having to rewrite the old ones, and use both in the same application.

, Shoelace, Lit, etc.). Wrapping Up In part one of this series, we described what Kredis can and cannot do, and developed an example use case for storing ephemeral UI state using a bespoke Redis key. In this second and final part, we identified the drawbacks of this approach. We developed a generalized solution to apply to any DOM node whose state of attributes we want to track on the server side. Finally, let me point out that these considerations inspired me to develop a library called solder, which I would be happy to receive feedback on! Happy coding! P.S. If you'd like to read Ruby Magic posts as soon as they get off the press, subscribe to our Ruby Magic newsletter and never miss a single post!

npm test > [email protected] test > tsc && wtr --coverage dist/test/testing-components.test.js: 🚧 Browser logs: Lit is in dev mode. Not recommended for production! See https://lit.dev/msg/dev-mode for more information. Chrome: |██████████████████████████████| 1/1 test files | 4 passed, 0 failed Code coverage: 100 % View full coverage report at coverage/lcov-report/index.html Finished running tests in 9s, all tests passed! 🎉

Web component browser APIs aren't that many, and not that hard to grasp (if you don't know about them, have a look at Google's Learn HTML section and MDN's Web Components guide); but creating a web component actually requires taking care of many small things. This is where web component libraries come in very handy, freeing us of having to think about some of those things by taking care of them for us. Most of the things I'll mention here are handled one way of another by other libraries (GitHub's Catalyst, Haunted, Hybrids, Salesforce's LWC, Slim.JS, Ionic's Stencil) but I'll focus on Google's Lit and Microsoft's FAST here as they probably are the most used web component libraries out there (ok, I lied, Lit definitely is, FAST not that much, far behind Lit and Stencil; but Lit and FAST have many things in common, starting with the fact that they are just native web components, contrary to Stencil that compiles to a web component). Both Lit and FAST leverage TypeScript decorators to simplify the code even further so I'll use that in examples, even though they can also be used in pure JS (decorators are coming to JS soon BTW). I'll also leave the most apparent yet most complex aspect for the end.

Depending on your needs, a "vanilla" JS option is also entirely possible using Web Components. You can use them on their own, or if you need a little more behind it, you can use something like Lit. https://lit.dev/

Looks very much like Lit (https://lit.dev/), which is not a bad thing.

> I’d love more tips for no-build-system javascript

1. MDN has a comprehensive guide on JavaScript modules [0]

2. A build system free way to build interactive websites could be to combine libraries like htmx[1] and or lit[2] or just the sub package lit-html[3]. Or just go with native web components and a bit of AJAX.

[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...

[1] https://github.com/bigskysoftware/htmx

[2] https://github.com/lit/lit

[3] https://github.com/lit/lit/tree/main/packages/lit-html

Ninja Keys uses Lit while command-pal uses Svelte. I don't have any experience with either, so.... Both of them can bind any command on the palette to a hotkey thanks to hotkeys.js. Both are MIT licensed. Command-pal is larger in size, but it also bundles all the libraries it needs. It looks like Ninja Keys loads libraries/modules on demand from CDNs on the internet. Being able to use the library without internet access is a nice feature.

My head is already coming up with use-cases such as JS template literals (think lit [0] for HTML and CSS templates), and the recently-shared Expr [1]. This is really neat. Thanks for sharing.

[0] https://lit.dev/

My go-to front end these days is Lit with web components, rollup, and web dev server.