butterfloat
lit-style
butterfloat | lit-style | |
---|---|---|
4 | 1 | |
6 | 9 | |
- | - | |
9.2 | 10.0 | |
3 months ago | over 1 year ago | |
TypeScript | JavaScript | |
MIT License | 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.
butterfloat
-
JSR: The JavaScript Registry
You can just use npm and ship node_modules on your website. It's probably "huge" so you probably want to clean out dev dependencies first (`npm prune --omit=dev` is one way to clean that) and you might find it useful to search for big binaries to filter out and redundant directories that you don't need (libraries that still include all of UMD and CommonJS and ESM builds even though you only need one), and there may still be libraries that don't directly load in the browser and you need to spot bundle with a tool like esbuild to a vendor directory.
Mostly the only other glue you need after that is an import map.
I find this flow useful (ship an optionally pruned node_modules, spot build specific vendor libraries, add import map), especially for lightweight development/testing, and so I did document it specifically from start to finish for one of my projects, it includes a vendor build one-liner:
https://worldmaker.net/butterfloat/#/getting-started?id=setu...
(The Example section after the Dev Environment one shows the import map at the top of the example HTML if you are looking for that. I forgot that's where it was when re-reading this.)
-
You Don't Need React
Vanilla JS is better these days than when React first arrived. ES Modules are natively supported in browsers now and give you much of a component system.
Though to be fair, rather than using Vanilla JS alone I did recently write my own React-looking but not React-like view engine: https://worldmaker.net/butterfloat/#/
-
Let's learn how modern JavaScript frameworks work by building one
I've been taking a similar, but somewhat different approach to upgrading some old Knockout projects to mostly Vanilla JS+RxJS.
Here's one example app: https://github.com/WorldMaker/compradprog/blob/main/main.tsx
One of the obvious differences is that I'm still using TSX, but it is very different from React, it just looks a lot like React at first glance.
Also, because I was doing it across at least a couple of projects, I started it from the beginning as its own small framework and have been trying to document it: https://github.com/WorldMaker/butterfloat/tree/main
It's still very much in early "prerelease" stages, but feedback is welcome.
-
Web Components Eliminate JavaScript Framework Lock-In
Just because on most modern hardware file I/O has millisecond latency and feels synchronous doesn't mean it is synchronous. It might feel like overkill to use Observables instead of Promises and I/O event loops or even thread-blocking faux synchronous file system calls, but there is still an asynchronous world there where it can be nice to have the full power of Observables. To be fair, my love affair with Observables started in C# in "backend" applications, so that's always been the natural fit for me and frontend and UI work has been the "side hustle" of taking stuff that I love in the backend side of the house and putting it to even more use.
I'm calling my view engine Butterfloat, and I only just finished the first documentation pass, so be gentle, but feedback is very welcome: https://github.com/WorldMaker/butterfloat
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?
apprun - AppRun is a JavaScript library for developing high-performance and reliable web applications using the elm inspired architecture, events and components.
WebComponentFactory - Make use of JavaScript web components while keeping your code in .html for LSP features
pota - pota is a small and pluggable Reactive Web Renderer. https://pota.quack.uy/
lit-state - Simple shared component state management for LitElement.
Filestash - 🦄 A modern web client for SFTP, S3, FTP, WebDAV, Git, Minio, LDAP, CalDAV, CardDAV, Mysql, Backblaze, ...
webcomponents - Web Components specifications
compradprog - Composite Radial Progress Demo
capable-js - An effect system for building multi-stage UIs, powered by async generators.
materialite - Differential Dataflow & Incremental View Maintenance for JavaScript
nano - 🎯 SSR first, lightweight 1kB JSX library.