[sebastianmck]

I'm skeptical too (I'm the author of Rome). I know it can be at least performance neutral compared to existing JavaScript tools which is the baseline for most people. However I do think that since Rome is an enclosed system, without external dependencies and pretty good TS typing, that there's some future flexibility using another wasm language that other JS tools don't have.

[tybit]

Awesome to hear you’re open to this in the future. I hope WASM gets some real traction in those sort of use cases.

[vijaybritto]

I was thinking tools would start replacing their typescript code with assemblyscript and build wasm modules for hot paths. Do you have any similar thoughts?

[cormacrelf]

For a compiler, it's probably much more valuable to have parallelism than cherry-pick slow code. You'd have to pick a pretty big hot path for the data conversion to be worth it. JS is pretty darn fast sequentially thanks to the ridiculous effort spent on its VM implementations, and there is next to zero number-crunching in a compiler, which is the main reason people have been cherry-picking with WASM on the web so far. We're talking pretty minimal speedups, compared to giving an embarassingly parallel problem the threading it deserves.

Having written codebases that take a couple of minutes to compile, it seems like a bit of a waste to write a whole new full-stack-no-dependencies compiler in a language that can't be parallelised.

You can usually get behind a self-hosting compiler for language evolution purposes, but for JS there is zero value in having yet another project to try it out on. For a transpiler to work on itself, maybe, but Rome is a CLI tool, not a web bundle, so it will never need to exercise the most demanding features of a transpiler/bundler. JSX, minification, code splitting, async loading, legacy browser support, etc. You can innovate on those things in any other language just as easily.

At the end of the day, the only advantage is that people who want to contribute will already know the language. Is that important enough to deal with another ten years of slow JS transpilation, forcing people to run huge, un-optimised code blobs in development (real life, very annoying problem), and 800MB node processes? I don't see that changing in JS-world for a long time.

(This is snarky, but you might actually be better off without importing the unfortunate churn habits of the JS community.)

[davedx]

This is very true. C++ developers have been using distributed builds (where when you hit "Build" in VS or run "make", it splits your build up and sends different source modules to different build workers on your local network - typically other developer machines or CI servers, then links the results together at the end), for decades now; I remember testing one back in 2005 or so and it worked pretty well.

[jiofih]

Node has three different ways of running parallel work: workers, threads, and multi-process.

[oblio]

Especially for threads, how well does this mesh with libraries? I'd assume that most of these are either meant to run in a single-threaded manner or async.

[jiofih]

Does not apply since this project is being written from scratch with zero library dependencies?

[crazypython]

Is Rome currently suitable for writing a transpiler?