13 ms·

Rome: An experimental JavaScript toolchain

370 points by vvoyer 7y ago

peternicky 7y ago
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.
ivankolev 7y ago
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.
fireattack 7y ago
>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 7y ago
  Javascript devs now transpiling history.
  - tiborsaas 7y ago
    This is just business as usual :)
- mhd 7y ago
  If only they weren't wrong in three ways (taste, nomenclature, artistry).
- bilekas 7y ago
  For every comment there is a tweet ! :D https://twitter.com/sebmck/status/1108412555922268161?s=20 https://twitter.com/sebmck/status/1108412555922268161?s=20
  - abacadaba 7y ago
    Honestly not sure if I can get past this. It's wrong and he should care.
namelosw 7y ago
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.
warpech 7y ago
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.)
paxys 7y ago
A Facebook project written in TypeScript...interesting
- dstaley 7y ago
  Jest is written in TypeScript!
  - matdehaast 7y ago
    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.
tekknolagi 7y ago
The ReadMe isn't clear and I'm on my phone: what does it compile to? It just says it has a compiler.
- imvetri 7y ago
  Same here
tobr 7y ago
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 7y ago
  That's silly. Unlike Oracle, Facebook has embraced the OSS community adopting their tech, and hasn't wielded the patent threat ever.
  - tobr 7y ago
    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 7y ago
      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 7y ago
        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 7y ago
        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.
      - dan15 7y ago
        > which is now vanilla MIT with no stupid patent clauses Except a patent clause actually gives you more protection, not less. That's why some other licenses explicitly include a patent grant, like the Apache license. I think the patent clause was a misunderstanding more than anything else. In any case, Facebook responded to what the community wanted.
gunn 7y ago
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 7y ago
  > 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.
  - deleted 7y ago
    [deleted]
  - siwatanejo 7y ago
    Good way to hide the shit under the rug indeed.
    - domlebo70 7y ago
      What exactly do you think they are hiding?
      - siwatanejo 7y ago
        Bad engineering practices. He mentioned them himself.
        gitgud 7y ago
        Unless I'm mistaken, It's a privilege to view the source not a right
chris_engel 7y ago
Its amazing how there can be such a long readme file and it still does not communicate what this actually does...
- harikb 7y ago
  This only replaces about 325 js dependencies. So you are right, it doesn’t do anything. To get to the point of having any functionality, we have to wait till it replaces 7,967
  - chris_engel 7y ago
    Where did I say it doesnt do anything?
    - harikb 7y ago
      Nm. That was my poor attempt at some js humour
      - IshKebab 7y ago
        I laughed inside. I mean cried...
- sebastianmck 7y ago
  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 7y ago
    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?
dmitriid 7y ago
The "Project Philosophy" section is just brilliant. I wish more projects consciously adopted it.
- warpech 7y ago
  I agree. I especially like the goals about errors.
  - dmitriid 7y ago
    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.
kevsim 7y ago
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.
- Waterluvian 7y ago
  Well, Typescript is literally checked in to the repo under node_modules. So I imagine the author just means "forget lockfiles, let's check this all in."
  - sebastianmck 7y ago
    The TypeScript type checker is only used to type check the Rome source code. The compiler is not used at all.
    - gonzus 7y ago
      Do you plan to self-host at some point, and get rid of the dependency on the (external) TS compiler?
      - Vinnl 7y ago
        As I understand it, the goal is not for Rome to do type-checking, but just for it not to choke on TypeScript's syntax (i.e. what Babel does): > 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.
- sebastianmck 7y ago
  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.
Karupan 7y ago
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.
iamleppert 7y ago
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 7y ago
  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.
keithasaurus 7y ago
Why not start with dependency-less standard lib? Then toolchain?
- 52-6F-62 7y ago
  I've been watching https://deno.land/ https://deno.land/
andrewjones_ 7y ago
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?
_bxg1 7y ago
> 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 7y ago
  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 7y ago
    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 7y ago
      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 7y ago
        > 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.js#L204 https://github.com/babel/babel-loader/blob/master/src/index.... 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.
stellalo 7y ago
> The only way to use it is to build from source. However, that will likely require more than 24 hours (ba-dum-tss)
- deleted 7y ago
  [deleted]
thecupisblue 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      I'm sorry but I just can't take this viewpoint seriously. I'm going to assume you're being sarcastic.
thundergolfer 7y ago
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 7y ago
  Rome having no runtime dependencies seems like it would go a long way towards that goal
overtowed 7y ago
author's tweets about its history - https://twitter.com/sebmck/status/1108407803545214977 https://twitter.com/sebmck/status/1108407803545214977
z3t4 7y ago
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.
iddan 7y ago
Why not incrementally share code with the current Facebook supported stack? Create PRs to Babel, Webpack and ESLint
- thrawhn 7y ago
  > 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.
robinduckett 7y ago
Uh, I found some external deps. Sorry seb! https://github.com/facebookexperimental/rome/blob/master/packages/%40romejs-web/frontend/package.json https://github.com/facebookexperimental/rome/blob/master/pac...
- ryannevius 7y ago
  That appears to be for the optional web frontend...not the tool itself.
  - robinduckett 7y ago
    I am aware, apparently I should make more use of /s
    - hombre_fatal 7y ago
      fwiw, an /s doesn't save you from overestimating the comedic impact of your HN jokes.
tjholowaychuk 7y ago
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
- frou_dh 7y ago
  They've already done exactly that in other quarters of Facebook towers: ReasonML
- lhorie 7y ago
  Old habits die hard. Not many people are interested in learning new languages
- hombre_fatal 7y ago
  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 7y ago
    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.
bogidon 7y ago
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.
- beart 7y ago
  I see emojis in business emails regularly, and I work in a non tech sector. I don't think this says anything about the JavaScript ecosystem.
- philjackson 7y ago
  I was thinking about this in the context of Tesla and their competitors the other day. Tesla have some little hints of good humour throughout their cars/marketing which I endear them to me. Everything is way too serious these days and injecting a little fun - with the disclaimer it doesn't get in the way - is a great thing. Keep the emojis and witty copy coming, I say.
- x3haloed 7y ago
  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 7y ago
    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.
- namelosw 7y ago
  Then you'll be pissed when you take a look at the issue list... Again, like others said it's more likely you are just upset about the emoji.
dilipray 7y ago
Won't be built in a day
- kitd 7y ago
  And not with a Greek helmet either!
spooklogical 7y ago
The number of times I've created conflicting rules between my linter, editor, and bundler.... I'd use it just to ditch that mess.
deleted 7y ago
[deleted]
foray1010 7y ago
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 7y ago
  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 7y ago
    > 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!)
  - foray1010 7y ago
    Having a good sensible default is one thing, bundling everything together is another. If I prefer jest over the test suite provided by Rome, I would have to install two test suites in the same project. Why not split them into different packages and let user pick what they want?
mnsc 7y ago
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
lotwxyz 7y ago
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 7y ago
  > 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 7y ago
    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).
deleted 7y ago
[deleted]
seemslegit 7y ago
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.
markknol 7y ago
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]
pcj-github 7y ago
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 7y ago
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
- hitekker 7y ago
  You mean the original decision to deprecate yarn and replace it with an a new package manager for a set of experimental features?
- dgellow 7y ago
  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.
- NateEag 7y ago
  The only quoted tweet I see (https://github.com/yarnpkg/berry/issues/766#issuecomment-578434425 https://github.com/yarnpkg/berry/issues/766#issuecomment-578...) is not offensive, to my mind.
egypturnash 7y ago
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?
kesava 7y ago
A little curious why TyepScript was chosen instead of Facebook's own ReasonML.
- k__ 7y ago
  I thought about the same thing, especially since people already started questioning performance here.
nojvek 7y ago
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 ?
RcouF1uZ4gsC 7y ago
> 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.
zaplobitogu 7y ago
Any metrics on time saved bundling a project from source with Rome versus other bundlers? Is there any minification support in Rome?
zaplobitogu 7y ago
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.
lyovson 7y ago
Why not use ReasonML for this though?
brigandish 7y ago
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.
hgl 7y ago
Is it a good opportunity to make it work in deno since everything is self-contained?

370 points by vvoyer 7y ago

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.

ivankolev 7y ago

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.

fireattack 7y ago

>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 7y ago
Javascript devs now transpiling history.
- tiborsaas 7y ago
  This is just business as usual :)
mhd 7y ago
If only they weren't wrong in three ways (taste, nomenclature, artistry).
bilekas 7y ago
For every comment there is a tweet ! :D https://twitter.com/sebmck/status/1108412555922268161?s=20 https://twitter.com/sebmck/status/1108412555922268161?s=20
- abacadaba 7y ago
  Honestly not sure if I can get past this. It's wrong and he should care.

namelosw 7y ago

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.

warpech 7y ago

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

paxys 7y ago

A Facebook project written in TypeScript...interesting

dstaley 7y ago
Jest is written in TypeScript!
- matdehaast 7y ago
  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.

tekknolagi 7y ago

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

imvetri 7y ago
Same here

tobr 7y ago

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 7y ago
That's silly. Unlike Oracle, Facebook has embraced the OSS community adopting their tech, and hasn't wielded the patent threat ever.
- tobr 7y ago
  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 7y ago
    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 7y ago
      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 7y ago
        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.
    - dan15 7y ago
      > which is now vanilla MIT with no stupid patent clauses Except a patent clause actually gives you more protection, not less. That's why some other licenses explicitly include a patent grant, like the Apache license. I think the patent clause was a misunderstanding more than anything else. In any case, Facebook responded to what the community wanted.

gunn 7y ago

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 7y ago
> 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.
- deleted 7y ago
  [deleted]
- siwatanejo 7y ago
  Good way to hide the shit under the rug indeed.
  - domlebo70 7y ago
    What exactly do you think they are hiding?
    - siwatanejo 7y ago
      Bad engineering practices. He mentioned them himself.
      - gitgud 7y ago
        Unless I'm mistaken, It's a privilege to view the source not a right

chris_engel 7y ago

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

harikb 7y ago
This only replaces about 325 js dependencies. So you are right, it doesn’t do anything. To get to the point of having any functionality, we have to wait till it replaces 7,967
- chris_engel 7y ago
  Where did I say it doesnt do anything?
  - harikb 7y ago
    Nm. That was my poor attempt at some js humour
    - IshKebab 7y ago
      I laughed inside. I mean cried...
sebastianmck 7y ago
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 7y ago
  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?

dmitriid 7y ago

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

warpech 7y ago
I agree. I especially like the goals about errors.
- dmitriid 7y ago
  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.

kevsim 7y ago

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.

Waterluvian 7y ago
Well, Typescript is literally checked in to the repo under node_modules. So I imagine the author just means "forget lockfiles, let's check this all in."
- sebastianmck 7y ago
  The TypeScript type checker is only used to type check the Rome source code. The compiler is not used at all.
  - gonzus 7y ago
    Do you plan to self-host at some point, and get rid of the dependency on the (external) TS compiler?
    - Vinnl 7y ago
      As I understand it, the goal is not for Rome to do type-checking, but just for it not to choke on TypeScript's syntax (i.e. what Babel does): > 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.
sebastianmck 7y ago
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.

Karupan 7y ago

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.

iamleppert 7y ago

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 7y ago
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.

keithasaurus 7y ago

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

52-6F-62 7y ago
I've been watching https://deno.land/ https://deno.land/

andrewjones_ 7y ago

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?

_bxg1 7y ago

> 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 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      > 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.js#L204 https://github.com/babel/babel-loader/blob/master/src/index.... 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.

stellalo 7y ago

> The only way to use it is to build from source. However, that will likely require more than 24 hours (ba-dum-tss)

deleted 7y ago
[deleted]

thecupisblue 7y ago

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 7y ago
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 7y ago
  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 7y ago
    I'm sorry but I just can't take this viewpoint seriously. I'm going to assume you're being sarcastic.

thundergolfer 7y ago

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 7y ago
Rome having no runtime dependencies seems like it would go a long way towards that goal

overtowed 7y ago

author's tweets about its history - https://twitter.com/sebmck/status/1108407803545214977 https://twitter.com/sebmck/status/1108407803545214977

z3t4 7y ago

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.

iddan 7y ago

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

thrawhn 7y ago
> 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.

robinduckett 7y ago

Uh, I found some external deps. Sorry seb! https://github.com/facebookexperimental/rome/blob/master/packages/%40romejs-web/frontend/package.json https://github.com/facebookexperimental/rome/blob/master/pac...

ryannevius 7y ago
That appears to be for the optional web frontend...not the tool itself.
- robinduckett 7y ago
  I am aware, apparently I should make more use of /s
  - hombre_fatal 7y ago
    fwiw, an /s doesn't save you from overestimating the comedic impact of your HN jokes.

tjholowaychuk 7y ago

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

frou_dh 7y ago
They've already done exactly that in other quarters of Facebook towers: ReasonML
lhorie 7y ago
Old habits die hard. Not many people are interested in learning new languages
hombre_fatal 7y ago
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 7y ago
  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.

bogidon 7y ago

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.

beart 7y ago
I see emojis in business emails regularly, and I work in a non tech sector. I don't think this says anything about the JavaScript ecosystem.
philjackson 7y ago
I was thinking about this in the context of Tesla and their competitors the other day. Tesla have some little hints of good humour throughout their cars/marketing which I endear them to me. Everything is way too serious these days and injecting a little fun - with the disclaimer it doesn't get in the way - is a great thing. Keep the emojis and witty copy coming, I say.
x3haloed 7y ago
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 7y ago
  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.
namelosw 7y ago
Then you'll be pissed when you take a look at the issue list... Again, like others said it's more likely you are just upset about the emoji.

dilipray 7y ago

Won't be built in a day

kitd 7y ago
And not with a Greek helmet either!

spooklogical 7y ago

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

deleted 7y ago

[deleted]

foray1010 7y ago

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 7y ago
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 7y ago
  > 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!)
- foray1010 7y ago
  Having a good sensible default is one thing, bundling everything together is another. If I prefer jest over the test suite provided by Rome, I would have to install two test suites in the same project. Why not split them into different packages and let user pick what they want?

mnsc 7y ago

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

lotwxyz 7y ago

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 7y ago
> 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 7y ago
  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).

deleted 7y ago

[deleted]

seemslegit 7y ago

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.

markknol 7y ago

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]

pcj-github 7y ago

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 7y ago

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

hitekker 7y ago
You mean the original decision to deprecate yarn and replace it with an a new package manager for a set of experimental features?
dgellow 7y ago
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.
NateEag 7y ago
The only quoted tweet I see (https://github.com/yarnpkg/berry/issues/766#issuecomment-578434425 https://github.com/yarnpkg/berry/issues/766#issuecomment-578...) is not offensive, to my mind.

egypturnash 7y ago

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?

kesava 7y ago

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

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

nojvek 7y ago

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 ?

RcouF1uZ4gsC 7y ago

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

zaplobitogu 7y ago

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

zaplobitogu 7y ago

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.

lyovson 7y ago

Why not use ReasonML for this though?

brigandish 7y ago

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.

hgl 7y ago

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