Great idea, very much welcome in the fragmented JS community.<p>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.
<a href="https://swc-project.github.io/" rel="nofollow">https://swc-project.github.io/</a>, <a href="https://packem.github.io/" rel="nofollow">https://packem.github.io/</a>,
<a href="https://github.com/nathan/pax" rel="nofollow">https://github.com/nathan/pax</a>, <a href="https://github.com/evanw/esbuild" rel="nofollow">https://github.com/evanw/esbuild</a>.<p>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.
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.
>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.<p>I chuckled.
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.
There's quite a lot of code in the packages dir - 76,000 lines of typescript.<p>It was all added in the first commit 45 mins ago. Why would they hide their commit history?<p>Also I found this funny - comments in package.json:<p><pre><code> "//": "Look! No deps!",
"dependencies": {},
"///": "Only used for static type checking",
"devDependencies": {</code></pre>
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?
Wow, I hope this could make current JavaScript workflow more slick and simplified.<p>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 :)<p>> 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 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!
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.
author's tweets about its history - <a href="https://twitter.com/sebmck/status/1108407803545214977" rel="nofollow">https://twitter.com/sebmck/status/1108407803545214977</a>
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 <i>you</i> 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.
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.
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.<p>edit: well, looks like they took down the offending tweets, but I can link out to this discussion: <a href="https://github.com/yarnpkg/berry/issues/766" rel="nofollow">https://github.com/yarnpkg/berry/issues/766</a>
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.<p>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 ?
<i>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><p>“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?
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.<p>[disclaimer, I am a big Haxe fanboy]
I love the README. I wish more more projects had things like this:<p>> 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.<p>The whole document is full of good ideas. I still want more, but that's a league better than many "top" projects I use.
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.
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.
> 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.<p>This is because, unlike the historical Rome, this Rome may fall in a day.
> Rome is not a collection of existing tools. All components are custom and use no third-party dependencies.<p>This seems enormously (and needlessly?) ambitious. Why not just bundle up the standard tools in a ready-to-use package?
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.
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.<p>Edit: Facebook wrote Buck and uses it extensively internally, so there being a desire for compatibility doesn’t seem far-fetched.
Choosing a name is hard. Facebook might have committed a small freudian slip here.<p><a href="https://www.history.com/news/8-reasons-why-rome-fell" rel="nofollow">https://www.history.com/news/8-reasons-why-rome-fell</a>
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
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.
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.
Uh, I found some external deps. Sorry seb!<p><a href="https://github.com/facebookexperimental/rome/blob/master/packages/%40romejs-web/frontend/package.json" rel="nofollow">https://github.com/facebookexperimental/rome/blob/master/pac...</a>
You can't compile the code of scripting languages, so please stop using that term. You may be doing <i>something</i> to the "source code", but it is <i>not</i> compiling! And I would argue that the thing you are doing to that code is <i>never</i> a good thing.