danprince / sietch Goto Github PK

Still on the fence about supporting React. The good arguments for using it are mostly to do with the ecosystem, and that's potentially something that could be patched over with an esbuild plugin that aliases preact/compat.

It works out of the box in a verbose way, inside vanilla components.

/** @jsxImportSource react */
import { useState } from "react";
import { hydrate as _hydrate } from "react-dom/client";

// https://github.com/anonyco/FastestSmallestTextEncoderDecoder/issues/18
import "fastestsmallesttextencoderdecoder/EncoderDecoderTogether.min";
import { renderToString } from "react-dom/server.browser";

let Counter = ({ count: init = 0 }) => {
  let [count, setCount] = useState(init);
  return <button onClick={() => setCount(count + 1)}>{count}</button>;
}

export function render(props) {
  return renderToString(<Counter {...props} />);
}

export function hydrate(props, element) {
  hydrate(<Counter {...props} />, element);
}

And a lot of the mess here could be cleaned up with a framework definition, like there is for Preact.

/** @jsxImportSource react */
import { useState } from "react";

export default ({ count: init = 0 }) => {
  let [count, setCount] = useState(init);
  return <button onClick={() => setCount(count + 1)}>{count}</button>;
}

I'm just not sure whether the complexity of apps where React becomes a better option than Preact is something to encourage in a SSG that's designed for tiny interactive blocks.

Part of the initial draw for Go with Sietch was the appeal of the standard library, using esbuild natively, faster compiled output, and cross platform binaries without headaches.

In practice, a number of those either haven't worked out, or other factors have diluted the benefits that Go ends up having over Node.

• Having a standalone binary has some appeal over needing the Node/npm ecosystem, but without that, you need some way to get dependencies and the natural way for Sietch has been through esm.sh. That part of the tooling is more flakey than I would like
• Building cross platform binaries is actually kind of complicated as soon as I added V8 to the build. So far haven't been able to automate those builds because cross platform/cross architecture CGO compilation is actually a bit of a pain.
• A JavaScript runtime is still important for server side rendering and many libraries don't quite work when evaluated directly inside V8.
• The ecosystem for markdown is a long way behind JavaScript. Sometimes this just means I need to write my own extensions (no problem) but other times its far less forgiving. Syntax highlighting is a huge bottleneck but there's only really one library with decent support (Chroma) and that feels like a pretty significant regression in flexibility when compared with projects like Shiki and Twoslash.
• Almost all esbuild plugins are authored in JavaScript and use esbuild's native bridge for communicating, but this means that there isn't really an esbuild ecosystem on the Go side, and you spend a lot of time writing plugins.

So, unfortunately, I'm considering rewriting Sietch in Node (although still open to Deno/Bun depending on ecosystem compatibility). Here's the rough estimation on what I expect to change throughout this process.

• Sietch will almost certainly get slower
• The concurrency model will be simpler (but probably still slower)
• Sietch will no longer run as a standalone binary
• It will become easier to distribute Sietch in a cross platform way
• The Sietch codebase should get a decent bit smaller
• I'll probably drop support for bundling remote imports
• It's more likely that there will be some escape hatches for customising the build (easier to offer extension points for remark etc).
• The islands APIs should mostly stay the same
• The syntax for templating will likely change to handlebars/liquid/tsx
• JavaScript will be evaluated server side under Node, rather than V8 directly (I/O APIs will be available to islands).

As of evanw/esbuild@4bd03f3 esbuild gives me a much nicer way to stitch together JS/CSS files that belong together. Should be able to clean up some of the brittle code that relies on bundles having names based on ids.