Our great sponsors
-
-
SurveyJS
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.
-
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
I use Lit and have a tiny bit of MS/FAST in one project. You're right. Neither site gets updated. I think both have terrible doc, really. I didn't learn anything from the Lit starter or the intro doc. Only the interactive tutorial was of any use.
I think FAST is dead because MS doesn't want to play keep-up with it. In fact, all of the component libraries that Lit advertises on their home page (https://lit.dev) seem be Thanksgiving leftovers put out on a buffet. No one is seriously updating a set of web components for public use.
But... perhaps that is because Lit isn't really great for making components for others? It doesn't get you out of the work of documenting them, for example, which is already done with canned component libraries. It certainly puts all the fixes back on you.
In my experience, Lit is terrible for green sheet projects and ones where you can keep everything in-house. But there is no "Lit community" or resources for people getting into it who want a jump start. And no great tutorial doc.
Unsurprisingly, you don't see Lit discussed too much anywhere!
React works well for simple, non-interactive components. Complex, interactive components are going to have state. Stateful components don't work so well in React. If you want to update props in a stateful component, the recommendation is to replace the component entirely by changing its key. At the point all of the benefits of React (preservation of selection, caret position, scroll position etc.) vanish. You might as well use vanilla js instead of React.
What does using Vanilla JS look like? Here's an example: https://github.com/wisercoder/eureka It uses two tiny 500-line libs. It uses TSX files, just like React. It has components, just like React. It doesn't have incremental screen update, but neither does React, if your components are interactive and stateful.
Come on over rovers: https://github.com/cheatcode/joystick.
I promise you'll love it if you're switching from React. And it's full-stack so no more stitching together frankenstacks. Good ol' isomorphic JS for devs who value their time/productivity.
I also went this route and used d3 for the math but my own hand-made SVGs for the rendering so that the DOM is all in "react land".
You may want to check out this library: https://airbnb.io/visx/ They converted a ton of d3 features into proper React components
My next goal would be to discard snabbdom (and virtualdom) and use custom elements. For that I'm evaluating a library like https://github.com/WebReflection/uhtml and all it's ecosystem of utility
I avoid using them, except when having to expose a component to a third party. Then I'd use something like https://github.com/preactjs/preact-custom-element, https://stenciljs.com/docs/custom-elements or https://github.com/solidjs/solid/tree/main/packages/solid-el....
As far as I see, there is nothing that WCs provide which isn't already solved, in a better way, both for devs and users.
And making a framework that use custom elements and shadow DOM for component-based logic and encapsulation seems like a purely philosophical approach to adhere to some vision of "platform purity".
I avoid using them, except when having to expose a component to a third party. Then I'd use something like https://github.com/preactjs/preact-custom-element, https://stenciljs.com/docs/custom-elements or https://github.com/solidjs/solid/tree/main/packages/solid-el....
As far as I see, there is nothing that WCs provide which isn't already solved, in a better way, both for devs and users.
And making a framework that use custom elements and shadow DOM for component-based logic and encapsulation seems like a purely philosophical approach to adhere to some vision of "platform purity".