Skip to content

Node Rewrite #11

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
danprince opened this issue Oct 10, 2022 · 1 comment
Open

Node Rewrite #11

danprince opened this issue Oct 10, 2022 · 1 comment

Comments

@danprince
Copy link
Owner

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).
@danprince
Copy link
Owner Author

Rewrite is pretty much done in the node branch, but still need to port the tests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant