You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: