Tegan is right, I have too many repositories, but the best part is that none of my repositories is redundant: they are all about new, or different, ways to develop client/server applications.
The list of my FE Web related libraries
- hyperHTML is the most mature project I have. It’s a “first of a kind” that reached awesome cross browser stability, and it works in every browser you can imagine, from old desktops, to old mobiles, and their modern version, transpiled or not. This project is the one with the best documentation or examples in either its dedicated site, or in Stack Overflow.
- HyperHTMLElement is a glorified Custom Elements wrapper, based on hyperHTML for rendering its content with, or without, Shadow DOM. We use this project in production, reaching almost 100 million users and their browsers, thanks to hyperHTML rendering performance and reliability.
- lighterhtml is based on the same hyperHTML parsing and diffing engine, but it offers a deadly simple API compared to its predecessor. Using the same engine means performance, as well as reliability, are there, but there’s also quite some experimentation around this project, where most successful added features would land in hyperHTML too, when appropriate. You can consider lighterhtml the best prototyping RAD utility I’ve ever written, but also a good spot to propose new features, or experiment new patterns. This project also has its own SO tag, but it’s probably so simple to use that nobody ever asked anything about it.
- heresy is one of my latest wonder, which is based on lighterhtml simplicity and performance, and it brings both builtin and regular Custom Elements to every old to modern browser, surpassing most common limits of the platforms, such as nested Custom Elements definition, automatic scoped-like styles declarations, without needing CSS-in-JS, and much more.
- wickedElements is a completely different progressive enhancement paradigm, that works best with any sort or server-side rendered layout, but it could be enhanced to work with other libraries too, such as lighterhtml, to populate registered elements. It enables Custom Elements like API for any sort of element you can select via CSS queries, but it has nothing to do with custom elements themselves, hence it doesn’t need any polyfilling at all, and it works down to IE9 and older mobile browsers, for a total size of 2K.
- hypersimple is a runtime model driven hyperHTML based development, it’s likely the easiest way to use hyperHTML with or without other tools
… but how can one chose between these libraries?
- for enterprise-grade production reliability, hyperHTML, or HyperHTMLElement if Custom Elements are a desired tarrget, would be my pick, for the simple reason that bug-fixing has a close-to-realtime priority lane, and there are dozens of examples and projects out there to counter validate fixes and no regressions whatsoever
- for better DX, lighterhtml, and eventually heresy if Custom Elements are a desired target, would surely suit your needs.
- for RAD and prototyping, hypersimple might be the killer of them all
- for an out of the box progressive enhancement paradigm that doesn’t need polyfills bloat and works on everything already live, wickedElements would be your best pick.
Me? … if I am going to start anything new, heresy would likely be my pick.
The list of my BE Web related libraries
- viperHTML, as hyperHTML BE counter part, because the ability to share the same views/components is awesome, as shown in viper-news HNPWA.
- heresy-ssr, as heresy BE counter part, because manipulating DOM documents on the server, through same Custom Elements that will be automatically hydrated on the client, is the best thing from all worlds. I still need to find time to publish some concrete usage/result through this framework, but what it can do so far is impressive, and it competes with latest Svelte, still using 100% native JS, without needing any transpiled, or compiled, indirection.
Needless to say that today I’d personally pick heresy-ssr over anything else I’ve ever created.
… but what about “this” or “that” ?
There are various 3rd parts libraries that either complement, enrich, or are used as dependencies for my projects, most notably:
- Haunted, able to bring React’s Hooks API to both hyperHTML and lighterhtml.
- basicHTML, which is the most lightweight and fast DOM-like implementation for Node.JS you can find out there, capable of defining even Custom Elements, built-ins included.
- workway, which brings to literally every browser asynchronous namespaces driven via Web Workers, without using Proxy, eval, or any other incompatible, or non CSP friendly, practices.
- ungap, which is the one-stop place for polyfills, where everything could be nullified via degap so that not a single byte would be wasted on specifically targeted browsers. This public namespace also includes the only polyfill you really need for modern Web development with Custom Elements.
- flatted, which is one of the fastest, surely smallest, circular JSON parser, with 16 millions per month npm downloads and steady adoption growth.
- lazytag, to automatically hydrate live Custom Elements and their eventual styles, without penalizing users with tons of components they might not even encounter while surfing the web
And yes, I have many other projects and experiments in GitHub, like the most recent one QuiGonJS, but I dare you say that’s even close to similar to anything else described in here 😜