
Rome: An experimental JavaScript toolchain - vvoyer
https://github.com/facebookexperimental/rome
======
warpech
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
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.

~~~
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.)

~~~
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?

------
bogidon
It's refreshing to see a JavaScript project with a mature tone and no emoji
bullet lists in its readme. I'm very eager for JS culture to mature along with
the tooling, and to prioritize content over sugar.

~~~
x3haloed
The Readme doesn't take itself too seriously. It even says the name of the
project started a joke, and pokes fun at its logo. I have a suspicion that
emojis just make you upset.

~~~
bogidon
I use emoji when texting sometimes. I have nothing against them. I used emoji
as a symbol for excessive and distracting behavior, that feels similar to how
memes feel – which to me has an almost mob/cult-like quality to it.

I’m not sure what other examples to use to describe the tone I’m referring to
without offending anyone. But, I’d personally be really interested in an
anthropologist writing about the internet culture of JS development. Edit:
hackernews unsurprisingly did not let me use an emoji at the end there.

------
fireattack
>Rome has a logo of an ancient Greek spartan helmet. It's not very relevant
since it's not Roman, but it looks cooler than a Galea.

I chuckled.

~~~
tasogare
Javascript devs now transpiling history.

~~~
tiborsaas
This is just business as usual :)

------
kevsim
It has no external dependencies but supports compiling typescript, flow, etc.
Does this mean compilers for those will be re-reimplemented inside Rome? Not
really looking forward to build tool-specific bugs with those languages.

~~~
sebastianmck
It does. And it's a risk not keeping up with their pace of development.
Supporting those "compilers" is just supporting their syntax, which both
fortunately already have very good compliance test suites because other tools
like Babel already reimplement their syntax anyway.

~~~
playpause
Interesting. Do you mean that Rome won’t perform type-checking in
TypeScript/Flow, it just strips their type annotations (like their respective
Babel plugins do today)? If so, is the idea that people might continue to use
the tsc/flow binaries in parallel with Rome (e.g. if they want to validate
types in a commit hook, or for in-editor linter-style warnings)?

I've been really looking forward to this source release since reading your
tweets about it. Sorry it got posted to HN before you wanted it to, but thanks
for making the code public at this stage.

~~~
dan15
> is the idea that people might continue to use the tsc/flow binaries in
> parallel with Rome

I think so, in the same way that people use both Babel and TypeScript (or
Flow) today. TypeScript/Flow check the types, while Babel simply strips them
out when compiling the code.

------
ivankolev
Sounds interesting, coming from Facebook and initiated by the guy who also
started Yarn and Babel, so a good chance to achieve its lofty goals.

------
gunn
There's quite a lot of code in the packages dir - 76,000 lines of typescript.

It was all added in the first commit 45 mins ago. Why would they hide their
commit history?

Also I found this funny - comments in package.json:

    
    
      "//": "Look! No deps!",
      "dependencies": {},
      "///": "Only used for static type checking",
      "devDependencies": {

~~~
sebastianmck
> Why would they hide their commit history?

I'm the only author at the moment. The project started off years ago as a side
project without any commit history, and what little history there was over the
years wasn't very thorough. Prior to the open sourcing I've been working on it
internally and still did pretty massive diffs that changed thousands of files,
still without good history. It's something I'm working on though and will
obviously need to be accountable for now that the project is public.

~~~
gunn
Thanks for the reply. It looks well organized now. I'll be keeping my eye on
it.

------
chris_engel
Its amazing how there can be such a long readme file and it still does not
communicate what this actually does...

~~~
sebastianmck
Considering this is just a source code dump and call for possible contributors
I'm disappointed it was even posted to Hacker News. Rome is not ready at all
for public consumption. I wanted it open sourced so I could work with other
tooling authors and contributors.

~~~
oefrha
Would you mind commenting on what it intends to be and what its value
propositions would be when it's eventually ready for public consumption? An
opinionated all-in-one platform?

~~~
pts_
It says so right in the readme. It's a formatter, linter, bundler,
compiler(transpiler?) all in one.

~~~
oefrha
I’m looking for something more specific than that. To go to such great
lengths, the value propositions have to be more than just bundling a few
things together. (And I did read the project philosophy section.)

~~~
jiofih
If you’ve used Metro or Webpack before there is very little explaining to do.
The existing tooling is bloated, fragmented (think 40k deps) and slow, and the
experience of sewing it all together and keeping it in one piece extremely
frustrating.

~~~
oefrha
I have, but there’s still a lot of explaining to do. E.g., what’s the
extensibility story? To do anything remotely useful with webpack you need to
install a million loaders and plugins, but the plugin architecture also lets
you do a lot that can’t be done with opinionated bundlers. So, what’s Rome’s
approach to this? Enumerating existing tooling’s problems does not
automatically guarantee something better.

~~~
hn_throwaway_99
The author has commented that this isn't yet ready for public consumption, but
is instead just a call for other possible contributors to the project. So:

1\. Everything you seem to be asking for seems like it is not relevant at this
point in the project's lifecycle. 2\. IMO people who _are_ capable of
providing good contributions don't actually need what you are asking for. They
can review the README as is, review the source code, etc.

In short, patience.

------
andrewjones_
I don't really understand what it does? It replaces webpack, eslint, maybe the
typescript compiler... etc, and puts it all in one library? What is the
benefit to end-users? To reduce the number of bugs, make it easier for people
to contribute (only need to contribute to one library), and increase the speed
of development?

------
namelosw
Wow, I hope this could make current JavaScript workflow more slick and
simplified.

Also the readme is doing a good job for answering my doubt at a first glance -
why a Corinthian helmet rather than a Roman one :)

> Rome has a logo of an ancient Greek spartan helmet. It's not very relevant
> since it's not Roman, but it looks cooler than a Galea.

------
foray1010
I worry this is a start for a toolchain monopoly, I don't like the idea of
all-in-one, how can a single toolchain be the best of all fields? Will it
suppress innovation like jslint -> jshint -> eslint? Just because the new and
better tool is not part of the toolchain!

~~~
oblio
In the Java world 99% of the code is compiled with javac.

In the .NET world 99% of the code is compiled with csc (or whatever it's
called, don't remember that well)

In the C world, with one of the biggest ecosystems and a fragmented history
going back half a century, 99% of the code is compiled with GCC/Clang/VS CL
(of which VS CL is there just because Microsoft insists on it being there).

Similar things happen with interpreters, CPython, Yarv, etc.

Javascript should innovate at higher levels. And it should have a linker and
tree shaking compiler as default for every project, everywhere, so that people
can stop making silly small libs and instead can use big ones that get
compiled to small code bits that are distributed by websites.

~~~
lotwxyz
> Javascript should innovate at higher levels

Until that level takes the problem of in-browser, persistent file/blob storage
seriously, the JS ecosystem will _not_ be able to truly progress, particularly
when it comes to the question of linking evolving code bases with more stable
libraries. But I digress. (I'm not going to "pimp" for my project now... see
my comments!)

------
stellalo
> The only way to use it is to build from source.

However, that will likely require more than 24 hours (ba-dum-tss)

------
Karupan
I am really excited for this project and hope it is opinionated enough and
doesn’t go down the rabbit hole of endless customisable options in a
Rome.js|json|rc file. I also hope this is as painless as Go and Elm’s default
tooling.

------
overtowed
author's tweets about its history -
[https://twitter.com/sebmck/status/1108407803545214977](https://twitter.com/sebmck/status/1108407803545214977)

------
z3t4
Make it run in the browser, using web workers to not block main thread. Most
tooling is assumed to be used in a terminal... Make libraries instead of
terminal applications, so that the tools can be used anywhere. Most people,
including most developers, are not comfortable working in a terminal emulator.
Even if _you_ are, you probably google for, copy/paste the commands into the
terminal... terrible inneficient and unfriendly for beginners. Instead provide
easy to use libraries, that can be used in monolith apps with some minor glue
code.

------
pcj-github
I'm not seeing a ton a tests in this repo, did I miss them? Seems like it will
be very hard project to maintain and gather community support without better
test coverage.

------
no_wizard
I just wish one of the key authors of this wasn't such a jerk to the yarn
development team just because they disagreed with their decisions. Makes me
very hesitant to want to collaborate with such people.

edit: well, looks like they took down the offending tweets, but I can link out
to this discussion:
[https://github.com/yarnpkg/berry/issues/766](https://github.com/yarnpkg/berry/issues/766)

~~~
dgellow
Looks like a normal discussion thread. Not sure what you’re pointing to here.
Do you have some evidence of bad behavior? otherwise your comment is the one
that looks petty IMHO.

------
paxys
A Facebook project written in TypeScript...interesting

~~~
dstaley
Jest is written in TypeScript!

~~~
matdehaast
Jest support from Facebook recently has been poor lately. One of the outside
maintainers took weeks to find someone at FB to even help push a release.

------
spooklogical
The number of times I've created conflicting rules between my linter, editor,
and bundler.... I'd use it just to ditch that mess.

------
nojvek
This is cool. Facebook does open source better than Google (things aren’t
abandoned left and right) but I’m afraid the experimental would mean it’s
future is unsure.

The other point is, why is Rome better than any existing tooling ? Webpack,
typescript, prettier, eslint, mocha are all pretty popular and mature tools.
Why would I use Rome over it ?

------
egypturnash
_Rome has a logo of an ancient Greek spartan helmet. It 's not very relevant
since it's not Roman, but it looks cooler than a Galea._

“Galea” links to the much cooler Roman helmet, disproving this statement. Also
given that this is a build environment, perhaps an icon incorporating, I
dunno, a Roman building might be appropriate?

------
markknol
I am using Haxe, which is a complete different ecosystem, which compiles to
JS. It has a fast optimizing compiler, a strict-typed language. Has features
like meta programming /syntax-transformation (macros), conditional
compilation, inlined calls etc. These are great tools to create high
performance apps. You can find all the features on its website. It has a
formatting tools and a linter, but has build-in deadcode elemination and a
static analyzer so it only includes everything you use (so no need to strip it
off afterwards as seen in some JS tools). Also could be a good candidate for
WASM, since it compiles to C++. One thing that is great about Haxe is that is
also compiles to other languages; you can reuse same code for different
compiler targets. I mean, why does Rome only target JavaScript? For Haxe
that's just one option.

[disclaimer, I am a big Haxe fanboy]

------
kesava
A little curious why TyepScript was chosen instead of Facebook's own ReasonML.

~~~
k__
I thought about the same thing, especially since people already started
questioning performance here.

------
brigandish
I love the README. I wish more more projects had things like this:

> Transparency. No back-channel project management. Project conversation and
> decisions will take place only on public forums such as GitHub, the Rome
> Discord, and Twitter. The only exception to this is moderation decisions
> which will be strictly done in private.

The whole document is full of good ideas. I still want more, but that's a
league better than many "top" projects I use.

------
thecupisblue
This seems great. As far as I can tell, it will be take input in *Script - AST
it, link it, lint it, bundle it up. Finally a whole toolchain in one place.

~~~
anonytrary
Hold on -- this sentence could essentially describe Webpack. The only
difference is that you plug your own transpiler and linter into webpack. It
sounds like Rome will let you integrate external tools, so what is Rome
really? A webpack that ships with a default linter and transpiler? There must
be more to it than that, otherwise I don't see the value add.

~~~
jannes
Even if it has the same features as webpack, this is better because it does
not have external dependencies. Webpack (webpack and webpack-cli) depends on
312 npm packages.

~~~
anonytrary
I'm sorry but I just can't take this viewpoint seriously. I'm going to assume
you're being sarcastic.

------
zaplobitogu
Just an observation... The batteries included model of Rome where it handles
ESNext, JSX, Typescript and Flow out of the box without configuration appears
to be a marked departure from the Babel preset/plugin model. Customization is
all fine and good, but most people don't want to configure anything and are
happy using defaults, even if it's suboptimal in some cases.

------
dmitriid
The "Project Philosophy" section is just brilliant. I wish more projects
consciously adopted it.

~~~
warpech
I agree. I especially like the goals about errors.

~~~
dmitriid
Approach to errors is what clearly distinguishes "old tech" from "new tech".
Most recent tools, compilers, linkers, bundlers etc. go out of their way to
provide clear human-readable errors.

------
hgl
Is it a good opportunity to make it work in deno since everything is self-
contained?

------
RcouF1uZ4gsC
> Rome is experimental and in active development. It's open for contributors
> and those interested in experimental tools. It is not ready for production
> usage.

This is because, unlike the historical Rome, this Rome may fall in a day.

------
_bxg1
> Rome is not a collection of existing tools. All components are custom and
> use no third-party dependencies.

This seems enormously (and needlessly?) ambitious. Why not just bundle up the
standard tools in a ready-to-use package?

~~~
steve_adams_86
One reason could be that this tends to require a lot of fiddling. If you take
the Rome approach, you can (theoretically) have the community do the necessary
fiddling collectively and have it work for everyone. If they're alright with
the standard it provides.

I know from experiences in the last few days that even things like standardjs
and xo, despite being described as zero-config linting/fixing solutions, don't
reliably work out of the box.

~~~
dan15
In addition to this, one reason the JS tools of today are relatively slow is
because they all need to parse the code. Babel parses it to compile it, then
ESLint parses it again to lint it, then Webpack/Rollup/Parcel parses it again
to bundle it. A single tool that reuses the same AST representation for all
three tasks has the ability to become a lot faster.

~~~
_bxg1
Yes and no. ESLint doesn't need to run at build time, and I assume that if you
integrate Babel and Webpack via webpack "loaders", some amount of work is
saved (just guessing though). That said, yours is the only good argument I've
seen for building a monolithic solution.

~~~
dan15
> I assume that if you integrate Babel and Webpack via webpack "loaders", some
> amount of work is saved (just guessing though)

The Webpack babel-loader just calls Babel with the source code, it doesn't
reuse Webpack's AST: [https://github.com/babel/babel-
loader/blob/master/src/index....](https://github.com/babel/babel-
loader/blob/master/src/index.js#L204)

It has to do it that way, since Babel could parse some syntax that Webpack
doesn't recognise (like Flow or TypeScript annotations). Webpack loaders can
even take non-JS input and produce JS output (eg. "svgr" takes SVG images and
produces React components) so I don't think Webpack can even assume that the
input is JS at that point.

~~~
_bxg1
And yet when it comes time for Webpack to crawl import statements, it can do
so across all different kinds of files coming in through their own loaders. So
I'm wondering if Webpack gets presented with some kind of structured "imports
manifest" by the loaders, in which case I think it could skip its own parsing
step.

------
peternicky
It is interesting that even Facebook employees prefer typescript to flow when
starting a project from scratch. I’d love to hear sebastian explain why he
didn’t use flow.

------
thundergolfer
I'm curious whether the Rome authors devote attention to 'compatibility' with
the principles and requirements of build systems like Buck (and Bazel). Our
company is in the process of migrating a large Typescript codebase to Bazel,
and there's a non-negligible amount of reconfiguring and re-tooling that needs
to be done that would be less necessary if key ecosystem components were
designed early to be hermetic, deterministic, modular, and incremental.

Edit: Facebook wrote Buck and uses it extensively internally, so there being a
desire for compatibility doesn’t seem far-fetched.

~~~
lhorie
Rome having no runtime dependencies seems like it would go a long way towards
that goal

------
zaplobitogu
Any metrics on time saved bundling a project from source with Rome versus
other bundlers? Is there any minification support in Rome?

------
tekknolagi
The ReadMe isn't clear and I'm on my phone: what does it compile to? It just
says it has a compiler.

~~~
imvetri
Same here

------
lyovson
Why not use ReasonML for this though?

------
keithasaurus
Why not start with dependency-less standard lib? Then toolchain?

~~~
52-6F-62
I've been watching [https://deno.land/](https://deno.land/)

------
tobr
I’m sure this will be very useful, but I’m very sad that it’s from Facebook. I
really don’t want anything to do with that company.

~~~
jeswin
That's silly.

Unlike Oracle, Facebook has embraced the OSS community adopting their tech,
and hasn't wielded the patent threat ever.

~~~
tobr
Is this what you’re saying: it’s silly to not want anything to do with a
company because another company is worse in one specific way?

~~~
anonytrary
No, this is what he's saying: Facebook has shown that they contribute good OSS
and want people to use it with no strings attached.

His quip about Oracle was completely irrelevant to the content of his comment.
In my opinion, Facebook proved themselves champions of OSS when they relaxed
their license on React (which is now vanilla MIT with no stupid patent
clauses).

~~~
tobr
The quality of the product is usually not the main concern in a boycott. They
make some great software, but they are a detestable company.

~~~
anonytrary
You don't punish a naughty dog when they get something right. You punish them
for the things they do wrong. People should just grow up.

------
iddan
Why not incrementally share code with the current Facebook supported stack?
Create PRs to Babel, Webpack and ESLint

~~~
thrawhn
> Create PRs to Babel, Webpack and ESLint

Why should anyone contribute to projects that have a completely different
philosophy from what they would write? I doubt that the authors of those three
projects would welcome any PR removing all dependencies of their tools with or
merging all 3 tools into one.

Also, what's the problem with creating new things and fostering competition
and advancing the state of our profession? Why is experimenting so frowned
upon by some people here in Hacker News?

By the way, the author of Rome is also the author of Babel. So I guess he has
made his share of Pull Requests.

------
dilipray
Won't be built in a day

~~~
kitd
And not with a Greek helmet either!

------
mnsc
Choosing a name is hard. Facebook might have committed a small freudian slip
here.

[https://www.history.com/news/8-reasons-why-rome-
fell](https://www.history.com/news/8-reasons-why-rome-fell)

------
tjholowaychuk
Facebook pays for this kind of stuff? Why not spend the time incorporating a
decent language instead of trying to fix the fragmented hot mess that is js

~~~
hombre_fatal
The same reason they still use PHP via Hack.

Throwing all the baby out with the bath water is something engineers
consistently overvalue in business when there are other middleground trade-
offs to choose from.

~~~
tjholowaychuk
I suppose it depends, but throwing out node and migrating everything to Go was
one of the better choices we made at Segment, before the platform grew too
large.

------
iamleppert
Claiming no dependencies while not reducing complexity (76k SLOC mono-commit
with no incremental history) isn't a win. No mention of test coverage, no
documentation besides the readme. No performance numbers of regression suite.

~~~
sebastianmck
The claim of no dependencies isn't there as some grandiose statement about
reduction of complexity, it's there to describe how self contained the project
is and our ability to change things. I'm going to refer to a comment I already
made elsewhere in this thread:

> Considering this is just a source code dump and call for possible
> contributors I'm disappointed it was even posted to Hacker News. Rome is not
> ready at all for public consumption. I wanted it open sourced so I could
> work with other tooling authors and contributors.

Those things you are asking will come at a time when Rome is actively being
marketed as a tool for users rather than an experimental project for
contributors.

------
seemslegit
At this point any sensible engineering manager should be committed to
prejudicially dismiss any new js tooling, preprocessor or package manager. The
current trash fire state of affairs needs to be let to extinguish itself
first.

------
robinduckett
Uh, I found some external deps. Sorry seb!

[https://github.com/facebookexperimental/rome/blob/master/pac...](https://github.com/facebookexperimental/rome/blob/master/packages/%40romejs-
web/frontend/package.json)

~~~
ryannevius
That appears to be for the optional web frontend...not the tool itself.

~~~
robinduckett
I am aware, apparently I should make more use of /s

~~~
hombre_fatal
fwiw, an /s doesn't save you from overestimating the comedic impact of your HN
jokes.

------
lotwxyz
You can't compile the code of scripting languages, so please stop using that
term. You may be doing _something_ to the "source code", but it is _not_
compiling! And I would argue that the thing you are doing to that code is
_never_ a good thing.

~~~
dan15
> You can't compile the code of scripting languages

Of course you can. Compiling is a process that takes some code as input and
produces other code as output. The output code doesn't have to be at a lower
level of abstraction (like assembly or machine code).

A compiler that produces code at the same level on abstraction (eg. going from
TypeScript to JavaScript, or newer JS to ES3 JS) is often called a
"transpiler" but a transpiler is just a type of compiler, and it's totally
valid to call it such.

~~~
lotwxyz
You can use all the fancy terms for the mangling and intentional obfuscation
of crappy code that you want. Sure, you might think that minification is a
valid use for such tools, but really, there is no alternative to just sitting
down and writing the right code so that it may eventually become a standard
thing, and so we won't need to keep reinventing the wheel over and over again.

I know of what I speak. I am in the process of turning the world of web
development upside down with Linux on the Web
([https://dev.lotw.xyz/desk.os](https://dev.lotw.xyz/desk.os)).

