8 ms·

Great idea, very much welcome in the fragmented JS community. However, I am sceptical about performance of a tool written in TypeScript/JavaScript. We've seen

Great idea, very much welcome in the fragmented JS community. However, I am sceptical about performance of a tool written in TypeScript/JavaScript. We've seen that tools written in compiled languages like Rust or Go can be much faster, e.g. https://swc-project.github.io/ https://swc-project.github.io/, https://packem.github.io/ https://packem.github.io/, https://github.com/nathan/pax https://github.com/nathan/pax, https://github.com/evanw/esbuild https://github.com/evanw/esbuild. On the other hand, Yarn is written in JS and it is considered fast enough. Facebook has a good track record for writing well designed tools.

sebastianmck 7y ago
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 7y ago
  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 7y ago
  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?
  - deleted 7y ago
    [deleted]
  - cormacrelf 7y ago
    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.)
    - jiofih 7y ago
      Node has three different ways of running parallel work: workers, threads, and multi-process.
      - oblio 7y ago
        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 7y ago
        Does not apply since this project is being written from scratch with zero library dependencies?
    - davedx 7y ago
      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.
- crazypython 7y ago
  Is Rome currently suitable for writing a transpiler?
eropple 7y ago
Using those languages comes at a tradeoff: the community isn't as a whole likely to know them or want to use them. For example, I'm a pretty prolific TypeScript developer these days. And I do know Rust and C++ and Java and a bunch of other languages, but I'm unlikely to contribute to JavaScript-ecosystem stuff written in them because the cognitive overhead is too high--the context switching kills me. And while I do know Golang, having to write it makes me want to chuck my computer in a lake and I'll within epsilon of never contribute to a tool written in it. You can swap in whatever languages in whatever slots in the above that you want, and you'll probably cover some chunk of the community. The intersection of all of them is JavaScript (and, for this project, TypeScript). I think that's wise. If you need to optimize certain parts of your runtime or your toolchain once it's correct and does what it's supposed to and you can call the solution set understood, that's one thing. But until it is, defaulting to something that isn't self-hosting is bad for your prospects of community building.
- Touche 7y ago
  > Using those languages comes at a tradeoff: the community isn't as a whole likely to know them or want to use them. You don't have to use Rust or Go to use a tool written in it.
  - eropple 7y ago
    If you read my post, one needs to use them to contribute to them. Past a certain point that matters less; early on, it matters a lot.
    - munificent 7y ago
      This is true, but for a compiler project, I think compiler expertise is a much bigger gating factor than language expertise. If you want to maximize effective contribution, you're probably better off picking a language that lots of compiler hackers know.
      - eropple 7y ago
deleted 7y ago
[deleted]
Cthulhu_ 7y ago
Would compiling it to native using e.g. GraalVM do much for performance?
namelosw 7y ago
It's much better to be self-enclosed than just to be faster at constant times. Just like most Emacs functionalities are written in Emacs-lisp, and most Elixir functionalities are written in Elixir. It's more consistent for open source projects, and people would be more familiar and motivated when building and consuming at the same time.
no_wizard 7y ago
On the topic of other languages taking over these tools, fundamentally it comes down to this: At the end of the day, these javascript tools (beyond just npm/yarn, which I think could be written in any language much more easily), like webpack, babel, or rollup etc., create very hard to replicate advanced ASTs. Even microsoft hasn't bothered to port typescript compilation to say, C# or F#, and I think largely because its a lot more complex to create the foundations for those languages to understand javascript on that kind of level. You could argue (and I can see the validity of it, see the Closure Compiler for a counter example), that it can just as well be done, but it seems like its far easier to implement in JavaScript these kind of tools.

sebastianmck 7y ago

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 7y ago
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 7y ago
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?
- deleted 7y ago
  [deleted]
- cormacrelf 7y ago
  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.)
  - jiofih 7y ago
    Node has three different ways of running parallel work: workers, threads, and multi-process.
    - oblio 7y ago
      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 7y ago
        Does not apply since this project is being written from scratch with zero library dependencies?
  - davedx 7y ago
    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.
crazypython 7y ago
Is Rome currently suitable for writing a transpiler?

eropple 7y ago

Using those languages comes at a tradeoff: the community isn't as a whole likely to know them or want to use them. For example, I'm a pretty prolific TypeScript developer these days. And I do know Rust and C++ and Java and a bunch of other languages, but I'm unlikely to contribute to JavaScript-ecosystem stuff written in them because the cognitive overhead is too high--the context switching kills me. And while I do know Golang, having to write it makes me want to chuck my computer in a lake and I'll within epsilon of never contribute to a tool written in it. You can swap in whatever languages in whatever slots in the above that you want, and you'll probably cover some chunk of the community. The intersection of all of them is JavaScript (and, for this project, TypeScript). I think that's wise. If you need to optimize certain parts of your runtime or your toolchain once it's correct and does what it's supposed to and you can call the solution set understood, that's one thing. But until it is, defaulting to something that isn't self-hosting is bad for your prospects of community building.

Touche 7y ago
> Using those languages comes at a tradeoff: the community isn't as a whole likely to know them or want to use them. You don't have to use Rust or Go to use a tool written in it.
- eropple 7y ago
  If you read my post, one needs to use them to contribute to them. Past a certain point that matters less; early on, it matters a lot.
  - munificent 7y ago
    This is true, but for a compiler project, I think compiler expertise is a much bigger gating factor than language expertise. If you want to maximize effective contribution, you're probably better off picking a language that lots of compiler hackers know.
    - eropple 7y ago

deleted 7y ago

[deleted]

Cthulhu_ 7y ago

Would compiling it to native using e.g. GraalVM do much for performance?

namelosw 7y ago

It's much better to be self-enclosed than just to be faster at constant times. Just like most Emacs functionalities are written in Emacs-lisp, and most Elixir functionalities are written in Elixir. It's more consistent for open source projects, and people would be more familiar and motivated when building and consuming at the same time.

no_wizard 7y ago

On the topic of other languages taking over these tools, fundamentally it comes down to this: At the end of the day, these javascript tools (beyond just npm/yarn, which I think could be written in any language much more easily), like webpack, babel, or rollup etc., create very hard to replicate advanced ASTs. Even microsoft hasn't bothered to port typescript compilation to say, C# or F#, and I think largely because its a lot more complex to create the foundations for those languages to understand javascript on that kind of level. You could argue (and I can see the validity of it, see the Closure Compiler for a counter example), that it can just as well be done, but it seems like its far easier to implement in JavaScript these kind of tools.