Considering implementation in system language like C++ or Rust

[mucsi96]

First of all thanks a lot for coming up with idea of improving the developer experience for frontend community. All of us spend tremendous amount of time with setting it up and waiting until it does it's job. I wanted to come up with a crazy idea. I saw that one of the key ideas is to not use any dependency. In that case maybe it would worth to think about choosing some system programming language like C, C++ or Rust to deliver best possible user experience. Speed of tool is the most important factor of entire experience. Many developers would appreciate this decision and would be very eager to switch to it just because of speed. I know it much harder to do and much harder to get similar community of contributors, but still I think it would definitely pay back the effort.

What do you think?

[zinyando]

A systems programming language would definitely bring a lot of speed improvements to the tool but that might be at a cost. There might be a drop in the number of contributors since this is mostly a build tool for the "web", most people looking to contribute are more proficient in JS/TS. Switching to c++/rust might push contributors away.

At the same time, Rome has been in the making for years now, switching languages won't be a simple refactor. It might delay a stable release coming out by a long while. Just my thoughts :)

[mattcompiles]

I believe the vision for Rome was to bring speed improvements via its architecture. Rome will do a lot less work than a combination of tools (typescript, eslint, webpack, babel) will do collectively. Also, the consistently running server will be able to cache this work much more intelligently than other tools.

[sebmck]

My comments on the Hacker News thread here summarize my thoughts on the topic:

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.

[sebmck]

We should first release Rome and see how the performance is for most people. Then we can experiment with possibly moving out expensive pieces. My optimistic hope is that eventually Rome's type system would allow compiling straight from the existing source into wasm, avoiding the requirement for porting to another language completely.

[sebmck]

I don't think there's a lot more to add here and "rewrite in another language" isn't really a goal we can even consider doing now. I'll make sure to reference this issue in any future conversations on partial implementation in another wasm language, but it would be in the extreme future.

[devongovett]

Stumbled on this issue by accident. We're definitely starting to hit the performance walls of JS in Parcel too. We've started porting some expensive parts to C++ where it makes sense. For example, we just moved to a C++ library for source maps, which improved perf by ~70% vs. the prior JS implementation (~25% of overall build time in one benchmark).

I've started thinking of working on a C++ parser/traverser/generator for JS too after seeing esbuild recently. The arguments about limiting contributions are true to an extent, but in my experience, the barrier to entry is usually not the language but the background in compilers you need to contribute. Obviously doing this would be a huge undertaking though, and not really something I have time for at the moment. Would love to collaborate with everyone here at some point if that ends up becoming of interest to Rome.

[sebmck]

We've had pretty good luck so far with contributions, including those from people who are not familiar with compilers and ASTs. Other languages would make these abstractions more complex and difficult. So I do think that language matters and can make these concepts harder than they would otherwise be in JavaScript.

At the point when Rome is hitting the walls of JavaScript performance, Rome will be sufficiently smart enough to compile itself to WebAssembly or some other bytecode.

[devongovett]

Rome will be sufficiently smart enough to compile itself to WebAssembly or some other bytecode.

That would be very exciting indeed. 😲

[mucsi96]

https://twitter.com/devongovett/status/1261379312898306048?s=12

[abihf]

Since it's already written in typescript, maybe migrating it to AssemblyScript is easier than rust/c++?

[hronro]

that there's some future flexibility using another wasm language that other JS tools don't have.

I don't think it's a good option to use WASM for improving performance, bacause WASM is much slower than native code (at least for now).

And here's a comparison from dprint. The dprint-cli uses WASM, and deno fmt uses drpint by compiling it to native code.

Formatted 590 TypeScript files.
dprint fmt 7.82s user 3.05s system 326% cpu  3.334 total
deno fmt   4.41s user 2.49s system 748% cpu  0.921 total

As you can see, WASM version is 3.62 times slower than the native code version.

[trusktr]

Just for reference, AssemblyScript allows JS/TS users to write TypeScript code that can be compiled to four targets:

• regular JS (tsc compiler)
• asm.js (asc compiler)
• Wasm (asc compiler)
• native (asc compiler plus some additional tools)

[mucsi96]

Today discovered esbuild. Which is at least 100x faster than the other JavaScript bundlers because it's written in Go.

Details: https://github.com/evanw/esbuild#benchmarks

[MaxGraey]

because it's written in Go.

No, not just because written in Go. And that's menthoned in why-is-it-fast section. esbuild has monolith architecture with minimal intermediate passes

[heyitsarpit]

Using go is not the only reason for its speed, the esbuild FAQ, lists explains it well.

[vjpr]

As of 2021/08/03, Rome is being re-written in Rust.

We are evaluating using swc inside Rome for parsing JS.
from Reddit.

The main SWC developer was hired by Vercel to work on adding SWC support to Next.js, which makes SWC look like the future of TS parsing in Rust. Naturally, Rome appears to be considering it.

It would be great for the community to converge on one TS parser/transpiler, so we can have a single plugin/config system.