github.com
A while back, I wrote a templating engine (MIT License), which I mostly use for small side projects, either static or ssr generated. Simplicity is one of the main goals.
I'll be happy to answer any questions. The main goal for sharing it is to simply get some feedback.
Best, Emil
Except it’s missing the ability to hydrate components on the client and re-render.
I use htmx for as much of my network requests and UI updating as possible as it’s faster to implement features, faster the render and easier to reason around than a SPA front end and JSON response backend - there’s a chance the OP is in a similar boat.
The downside to a JS SSR driven app is the backend templating situation isn’t as expressive as JSX and can feel a bit limiting.
Hopefully OP will chime in and correct of confirm my assumptions.
I've been using it for small projects and I didn't want to be bothered with all of the setup required to get jsx/tsx transpilation in place.
Another important reason was that I wanted a tool that would let me reach high results in lighthouse, and that's not something you'd get with other tools quickly. Critical css out of the box seemed to be approach that worked for me in this scenario.
[0] I documented the compiler options and the reasoning behind them in if you expand the Explanations section of this Getting Started document: https://worldmaker.net/butterfloat/#/getting-started
[1] https://github.com/WorldMaker/butterfloat/blob/main/jsx.ts
[2] https://github.com/snabbdom/snabbdom/blob/master/src/jsx.ts
lib.dom.ts is one of the many lib files shipped with Typescript itself. I mention @types/react mostly as an example of probably what not to do, but it is a simple Node package maintained by DefinitelyTyped and easy to lookup if you did want to do things the brute force way (as many have, because it is easy to do). I also linked to two different examples of the type definition work, they are small files that are maybe not easy to follow in the way they used advanced concepts of Typescript's type system, but show that you can do a lot without copy and pasting thousands of lines from @types/react. You can replace most of the complex types in either file with `any` and get a quick and dirty minimalist type definition file. (If you go far enough back in the commit history of either the files I posted you can find examples of that, too.)
For what it is worth, I test Butterfloat with JSDOM entirely in Node (after Typescript building) and SSR/SSG/progressive enhancement and other backend support has always been on its roadmap, parts of it exist today and other parts were architected with it in mind, but it just hasn't yet been prioritized (because so far it is admittedly a solo project). I also wanted something that was simple to setup and use, backend or frontend, and would score well on lighthouse but also might score well in Web Components and also make sense replacing old Knockout.JS code from a decade or two ago.
Also, for some of us, no client side rendering is a feature not a deficiency.
I fully understand how to do everything the parent poster said, I just don’t want to do it and don’t think it’s the best dev experience in my use cases.
The functions in Boxwood are so close already to the necessary shape for a JSX function (it's just `jsx(tagNameOrComponentFunction, properties, children)`) there's not a lot you actually need to do to get nearly "free" JSX support even if you didn't want to put the work into a .d.ts file to get nice Types back out and just did `export type JSX.InternalElements = any`.
That said, the point about `lib.dom.d.ts` is that building the types can be a lot easier than it seems and need only a couple dozen lines to support a lot of rich typechecking including MDN documentation links in hover tooltips.
From personal experience, with multiple libraries, it is a really nice developer experience to have good TSX type checking and type documentation. Auto-complete along speeds up template development and the number of times I've used the MDN link in a property (attribute) hover to check support statistics or edge case notes in the documentation is surprisingly high.
Not every webapp needs client side hydration. It’s very often wasted CPU cycles on a page that’ll be unloaded three seconds later. Personally I’m happy to see projects like this that live outside the monoculture.
(I do that for my framework mininext https://github.com/spirobel/mininext would be happy to receive feedback, other view points on this :-)
I like my tools to have as much types generated from context as possible (types from OpenApi, from graphql or from sql queries) and was looking to build a tool like that for handlebars. Idea being that it would tell you which types the template variables used so you could avoid stupid errors at compile time.
It seamed handlebars could provide an AST, but it was kinda hard to used so I scrapped the effort.
Maybe this would be more condusive?
1. You could add a jsdoc comment per component, let your tool read it and treat it as the source of truth 2. The template is just a js file, so you could parse it, get the params of the fn and try to deduce the types based on the usage 3. You could use typescript and export types 4. Serialize/normalize data before passing to the templating engine
This looks like what I wanted in a templating language
It is mature and feature rich. I like that the expressions can be plain js and it is not coupled with html.
Another project on the HN homepage at the moment happens to do this: https://www.val.town/v/maxm/staticChess
const { renderToString } = require('react-dom/server')
renderToString(<ul>{[1, 2, 3].map(n => <li>{n}</ul>)}</div>)
Could this also work in the browser?
Otherwise you might end up reimplementing those.
The intentions of the tool were the server side and static use cases and I didn't plan to use it on the client side.