I feel so torn on this project. On the one hand, I want to root for sebmarkbage, who has done so much for the field.
On the other, as someone who used to do some "JS platform" work at a tech company, I really don't want Rome to catch on. Yet Another Standard is really painful for the ecosystem, and while it's obnoxious that you need so many tools, at least we've finally settled (mostly) on good answers for each vertical. TS, ESlint, Prettier, Webpack, Babel.
Now, would it be nice if there were an underlying engine/server that all tools could use to share an AST without reparsing everything? Sure, I guess. Would it also be nice to have one tool that wraps the others, at least when you're getting started? Yes, though I think create-react-app has blazed that trail pretty well.
The thing is, all those tiny little details from Prettier and ESLint and Webpack really matter – Rome will take years to achieve the number of lints that ESLint has, and even more years for the community to agree on which ones matter. Similarly, every corner-case of prettifying will have to be considered anew, and every edge case of bundling rebuilt or reimagined.
I love to see a talented person take on something insanely ambitious, so I wish him luck and hope he proves me wrong. But if Rome succeeds, it'll be a big pain for a lot of people as they try to port everything over, and for the community as they grapple with dueling standards for how things should be done.
The ecosystem is already fragmented and dueling. When it says it replaces those tools it means it aims to replace the functionality of those tools, not make them obsolete.
Rome being successful doesn't mean eliminating those tools, it's providing something valuable and giving people an option. If it's not for you then that's okay. Rome is early and is still evolving, including possible areas for extensibility.
I think a lot of people don't realize the sort of capabilities that they're missing out on by not having their tools work together, or sticking with old tooling that cannot innovate for legacy reasons (like Babel). I don't think it's harmful to the ecosystem to advocate for more consolidation, especially around tooling that not a lot of people either like to deal with, or have few maintainers in the first place.
I also think you have me (Sebastian McKenzie) confused with Sebastian Markbage from the React team.
Hey there – I do mix the two of you up, but Babel is nothing to scoff at. I've used its internals in the past, and read a good chunk of its source code, so I think I've seen your blames all over. I'm quite appreciative of your past contributions! (and his)
Reading your comment, it sounds like you expect some people might use Rome for some things (say, linting and compilation) and preexisting tools for others (say, formatting and bundling). Is that your intent?
Welcome to web development, where change has been the only constant since—checks notes—the early 90s!
My way of coping with the appearance of yet another new-and-hyped thing, is to not complain and resist, nor to try to immediately learn the thing, but rather the much easier task of learning the why of the thing. Equipped with this knowledge, I can grok the JS ecosystem as a whole, and make better choices when it's time to choose a tool.
I do agree it's super exciting to see Sebastian McKenzie launch out with something new. I think I understand the why of this, and wish him every success!
Your comment says to me anxiety largely just at violating conventions of popularity. Your only hesitation is an appeal to authority. There is no consideration of merit or anything technical.
I read the anxiety as far less being about popularity than past trauma from the Javascript ecosystem and the whiplash it went through before it settled on the React/Vue/Typescript world we have today. When you go through that much change in the past, you really need a good argument to be convinced to try something new.
As a developer, I haven't had any qualms with ESLint, so I wouldn't really have any reason to pick up Rome. Now if the full tool set offers lots of things, then I might consider replacing my current Vue template / create-react-app, but that's a big step.
All of this to say, no, it's not an appeal to authority. It's sounds like a "I'm not sure I can imagine this being worth switching to because we have something that works and is stable now, and we haven't had a great track record with tooling churn in JS world". It's a value add question.
Even if it somehow manages to succeed at its mission and become the defacto toolchain for all of frontend, I feel its improvements over the status quo will be short lived, and over the long run having a monolithic toolchain dominate will prove to be a net-negative for the frontend tooling ecosystem.
Having a single defacto monolithic toolchain greatly raises the barrier to entry for new competing tools, as they'd no longer be able to just compete on the merits of doing any individual task better than its direct competition to gain adoption.
Having different single purpose tools that can people can pick and choose from independently of each other is a crucial part of what has enabled rapid innovation in the JS tooling ecosystem up till now, since it keeps implementation/switching costs for any individual tool as low as it can reasonably be for that specific use-case.
This comes at the cost of making it harder for any individual to keep up with all the latest innovations (as critics of the JS tooling ecosystem are often quick to point out), but projects like create-react-app have been fairly successful at addressing this through sourcing collective wisdom from the community to create a collection of best-in-class tools configured to work effectively together out of the box.
I can also totally emphasize that there are many low-hanging fruits in terms of efficiencies to be gained through unifying tooling to avoid wasted work and maintenance overhead, but I'm of the opinion that the gains in efficiency isn't going to be worth the cost in potential for stifled innovation, and that those efficiencies are better achieved through shared specs and shared low-level libraries that individual tools can choose to adopt if they become compelling enough.
I'm personally still going to be rooting for single purpose tools + curated collections over any monolithic toolchain.
With all that said, I for one would totally welcome something new in the formatting space to challenge prettier that decouples the line-length based autoformatting from the opinionated default styling presets.
JavaScript kind of always had this problem, and on the whole, it’s a good problem. Nobody forces new tools to become widely adopted. It happens because they improve enough stuff to convince us that switching is worth it.
When the web moved from jQuery to React, the details developers cared about changed. Opening modals got harder, but thats okay because React made so many other things better.
React is good enough to force us to adopt compilers for a language that doesn’t need them. When people complain about JavaScript on Hacker News, it’s usually about the build tools – and Rome has a shot at being an answer to that.
The web is more mature now, but that doesn’t mean the time for new tools is over.
sebmarkbage is one of the architects of React and a TC39 member. He's known for the Fiber architecture, among other things.
sebmck/kittens wrote 6to5 as a teenager in Australia, eventually landed a job doing JS infra at Facebook, and now works at Discord. He's a founder Babel, Lerna, Yarn, and now Rome.
Same, but I wouldn't say I'm happy with it. Everything's interdependant and that makes it such a pain to configure and maintain:
- Prettier has to be integrated with ESLint to avoid conflicting formatting and for good devX
- TS config interferes with ESLint config ("this file is not part of any project" or conflicting unused var warnings)
- Webpack has to be integrated with TS to compile down to JS
- ESLint, TS and Webpack all need configuring to know about absolute imports
If you throw babel into the mix, complexity just explodes. Thankfully it's feasible to have a stable config that "just works", but it can be quite the time sink. I wouldn't be against something that takes this pain away
I cannot deal with these kind of statements and that's probably why I never use linters for my own projects. And yes, my code is good enough, a linter won't make it any better. It just blocks me time and time again and litters the codebase with: // eslint-disable-next-line
I never really understood why these tools are so popular and who really needs them. In the end it's all about the result of the code you've written, how easy it can be maintained and how good it works. No linter can help me with that.
I think the benefits of linting are similar to writing tests.
Initially the practice is detestable, especially if you've already developed some hard-fought coding chops without them. But after some time the practice itself influences your ability to write better code to start with, and successive tests become terser and more useful.
I think the same is true for linting. I found being involved in projects that enforce linting rules on commit to be insufferable, so I installed Prettier and configured it to format on save. Over time the auto-formatter did less because of the habits I was picking up.
I did have to confront the idea of being less precious and attached to my own coding-style, but frankly I still have pretty strong opinions despite having an automaton do my thinking for me in some of the projects I work on.
Of course, neither tests nor linting are a panacea, but so long as you give a hoot to start with you won't be able to avoid writing better code after using them.
Agreed. Creating a one-tool-to-rule-them-all is unlikely to help matters much.
To me, (and with the conversation restricted to applications, not websites or anything that is primarily a document for consumption), we should be going in exactly the opposite direction; reducing the number and scope of the extra tools we need to use.
We should be making bundlers unnecessary (javascript modules plus smart http 2 servers are one way, service workers are another), we should write code that targets the js that modern browsers understand so that babel is unnecessary as part of our main workflow and is only run if you want old-browser compatibility, we should look at folding the key parts of react into the DOM (firefox used to have something really not all that different from JSX, and the core functionality of react is pretty small - the DOM is a virtual DOM). Linting and source code formatting should primarily be part of your IDE/Editor workflow. Testing needs vary, and I want to be able to use the right framework for testing for the project without having to bring along all the other cruft.
What I loved about the web when I first started building apps for it was that I could start with a single file in an editor and grow from there. Making a change, pressing F5 and seeing the change immediately was so liberating compared to long compile times and complex build systems. With your code carefully written so as to fail fast, you could often see failures in the live application faster than my Java IDE would pick up a type error in Java code (anyone remember the white menu bar of doom?).
I think it's a great pity that we've taken one of the web platforms major strengths - fast iteration times, and added so much tooling. We used to scoff at the fake stackoverflow question where someone asked 'how to do addition in jquery', but the sheer quantity of tooling that is normally used for projects has put us in a similar position.
Honestly, I think your thinking is totally backwards.
Wanting a project to be successful because of the person who started it is a terrible reason and has had (unsurprisingly) terrible results wherever I've seen it in the OSS community.
I feel the exact opposite: things like Rome (and Deno) are exactly the kind of projects that are needed in order to sort out a horribly fractured eco-system. I don't care who built them as long as they work well to solve the problems that so clearly exist.
> Wanting a project to be successful because of the person who started it is a terrible reason and has had (unsurprisingly) terrible results wherever I've seen it in the OSS community.
I somehow misinterpreted pipenv being an official python project. My usecase was pretty simple, I wanted a requirements.txt that only included the things I explicitly installed with perhaps a requirements-lock.txt with the actual list of things installed. :/
I didn’t even realize poetry existed until I talked to people who do python full time.
> Yet Another Standard is really painful for the ecosystem, and while it's obnoxious that you need so many tools, at least we've finally settled (mostly) on good answers for each vertical. TS, ESlint, Prettier, Webpack, Babel.
Have we? I have 2019 projects I have worked on that dont use TypeScript and while I dont mind TypeScript I have a YAGNA attitude about it still. My coworkers seem to hate it despite never having used it. I think of TS as almost irrelevant if you can do JSHint but thats just me coming from Python 3 where type hinting is valid and doesnt require additional tooling to make it work.
Sadly I understand why JS syntax doesnt expand too much over the years and you need something like Babel.
But on the other hand if we stopped allowing legacy web clients we could probably push modern JS to more mature stages including type hinting (optional of course) as was done in Python 3.
You don't need to use any of these verticals - you can just write a .js file and serve it without any modifications, linting, etc.
But if you want to? Each vertical has a de-facto community standard at this point. If you want typechecking, it's TS. If you want formatting, it's Prettier. Etc.
And of course, nobody's captured 100% of any of these verticals - there are plenty of people who use Flow o Reason for typechecking, or "StandardJS" for formatting.
But a new person setting up a JS project can just install the community standards at this point and be fine (albeit bothered at configuring things, if they don't use c-r-a).
I don't see it this way; I see Rome as the Apple of front-end tooling. You use an opinionated service to do most of the work. No brainer!
If you want more configuration, build your own, and most people will do. But for the novice, people who do multiple new projects a year, or people who don't care about details, Rome will be great.
For homemade projects, I use CodeKit, and I think Rome will be the same without the friendly and refined GUI.
the prevailing consensus esp in the JS world is that 1 tool should do 1 thing. This is fine under the Unix philosophy, but challenges arise due to the combinatorial explosion of config needs, bad errors, and overhead from crossing module boundaries. There are a number of attempts at challenging this status quo:
- ESbuild (100x faster than webpack in part due to focus on doing a single parse (but also shipping a Go binary))
- Deno
- Rome
As we consolidate on the jobs to be done we expect out of modern tooling, it makes sense to do all these in a single pass with coherent tooling. It will not make sense for a large swathe of legacy setups, but once these tools are battle tested, they would be my clear choice for greenfield projects.
After spending way too much time debugging issues with frontend tooling, I am all on board for this glorious monotool future. We’ve definitely gotten some progress out of the massively micropackage approach that Webpack/Babel/etc use, but these days it really feels like we’re passing a complexity limit and we need a new approach. The fact that CRA will refuse to startup if you have another version of Babel installed anywhere in the tree, is a pretty good clue that the current approach isn’t scaling.
Yes, time spent on tooling is time not spent solving real problems. The ability to make unpopular decisions necessary to move a product forward is what separates an expert from an expert beginner.
Wow! I've been trying to put my thoughts about this into a blog post, but it would have ended up (or will end up) almost exactly like yours (except I didn't know about "Worse is Better"). Great to see someone with such similar ideas!
Man, the performance benchmarks that esbuild publishes are pretty remarkable. I know it's common to cherry-pick favorable benchmarks, but even if these are misleading by two orders of magnitude esbuild would be best in class.
I also found them unbelievable so I did some quick tests with a couple of large projects that I'm working on, currently using Rollup. From these, I'd say their benchmarks are completely accurate.
I think maybe what's missing is one tool which the "one thing" it does well is put all the other tools together seamlessly and make sure they work right. My guess is that's what an IDE is supposed to do (I say "my guess" because I've always done my development in Vim).
I just know that every time I revisit any JS front-end stuff, I end up punting and just manually adding script/stylesheet includes for Vue and Bootstrap or whatever so I don't need to deal with half that crap. As an outsider it's always so daunting, and I feel like whatever I learned 6-12 months ago last time I needed to do something doesn't necessarily apply anymore.
* create-react-app serves as a very basic frontend template for a React project. It eliminates worrying about Babel, webpack, polyfills, etc
* next.js / nuxt.js solve both front-end and backend for React / Vue. Likewise they package webpack, Babel, typescript, etc, and also help with bundle splitting, routing, and server-side rendering that used to take 30 different packages and 6 think-piece blog posts. It’s good stuff (I can speak for Next, dunno about Nuxt)
Huge ambitious project and I hope it delivers. If anyone can lead this one to fruition is Sebastian. So this project is in good hands.
Undeniably, it's technically ambitious to build all these pieces under a single umbrella. And then, convincing people who are honestly scared to touch their Webpack config to switch to a new tool might not be easier.
But if Rome booms, it'll truly benefit the community.
I'm almost convinced by snowpack, especially because it has an escape hatch to webpack. (But that escape hatch is of course yet another opaquely managed webpack config, so hence some of the remaining reservations.)
There's something that scares me about Rome: it's lack of plugins.
I really like Babel because of its plugins. My project typecheck.macro, could not exist without Babel plugins.
How will Rome support compile time transformations like graphql.macro or typecheck.macro?
Compile time plugins allow JavaScript to evolve super rapidly & make the creation of frameworks that act as compilers instead of traditional frameworks possible.
I spoke in this post about how rushing into a plugin system hurt the longevity of Babel and it's ability to innovate. We aren't going to make the same mistake again. Rome will likely eventually have a plugin system, but what that would look like isn't clear.
This is the first release and until there's some actual usage, there's no real way to realistically predict what sort of things people will feel is missing. You can always supplement your project with multiple linters if you feel like it is currently a blocker.
Without plugins at first, how open are you to contributions that would normally go into a plugin and not into core?
As someone who works on libraries that don't use JSX, and therefore have to rely on compiler and linter plugins to get support (tagged template literals in my case) I worry that React's dominance will mean that it gets a place in Rome, while other systems are locked out, which only increases React's dominance.
Would you consider an internal plugin system as a first step, where plugins have to be part of the codebase, but intentionally get a restricted API surface? This would allow you to try out and refactor the plugin API over time before committing to it publicly.
Isn't this the reason why it is called Rome? In JavaScript history, we are past Babel (and the Greek city states) and a centralized tooling will allow for an unprecedented language economy?
Constantinople and Moscow are waiting, as well as Venice and London. A plugin system that wants to incorporate everything will risk having to maintain Byzantine diplomatic relations. On the other hand, restricting the plugin system to its core will create a local powerhouse that will utterly fail to adapt once new ventures become available.
I am waiting for the TypeScript / JavaScript split.
It's a good thing. It should get the defaults right first before rushing into plugins. Webpack had everything delegated to plugins without a single sane default for years which only contributed to its complexity. As thebiggest example: it had a several-thousand word article on consistent caching that used three different plugins for three or four years before that became default behaviour in version 5.
I, for one, welcome a future of build tools without plugins.
They are not the same thing. Despite not supporting plugins, I think you can definitely expect Rome to support some form of macros, thought it might look different from the existing API in babel.
Sebastian keeps mentioning how all these different kind of tools could re-use the same infrastructure for the things they all do, but... It's still not quite clear to me what benefit that brings to me as a non-contributor? I can see how it could be beneficial if the entire ecosystem would rally around the same tools and then be able to move faster, but given that that has not yet happened... Why would I use this to lint my code? The nicer error messages?
I don’t work on Rome and haven’t looked at their code much, but if I were to guess: performance and better error messages
If you can do the same work in fewer passes, it will often be faster
So instead of every file change, webpack runs its own parser, then Babel runs its own parser, then ESLint, etc — Rome probably just runs the parser once and sends the AST to other plugins
And then if you invest in making the parsing stuff really good, that makes the linter better, the Babel-equivalent better, etc
- Many tools revolve around parsing your code and generating an AST, then manipulating / processing that AST (Prettier, ESLint, Babel, TS, Webpack, ....). That's a lot of extra processing that has to be done. In theory, doing all that processing _once_, and reusing the AST, would potentially run a lot faster.
I'm not an expert in the internals of these things, but presumably Prettier, Webpack, TypeScript, Babel, Istanbul, and ESLint each build their own separate, private ASTs from scratch. Maybe a project like this could pipeline a sequence of ASTs one to the next, and skip some of that overhead?
Why a focus on frontend only?
I am using Typescript, Babel, Jest and a bundler for any app/library on the frontend/backend.
If you got to do it, do it all the way!
I can already see the GH issues, “sorry, this is a backend use case”.
So now my tooling would end up being more complex with the addition of another tool since it will never support all my use cases.
Seemed promising but this alone makes me question its utility.
TypeScript is a frontend language. "Frontend" is the category of languages we plan on supporting. It doesn't say anything about your usage of those languages. Where you run the code does not matter.
Could you expand on why you think TypeScript is a "front-end" language? I was under the impression that it just compiles to Javascript and while Javascript used to be a front-end language, it's nowadays bravely used for backend projects as well, for some reason.
I want to somehow make the point, which seems to be somewhat out of fashion this season (it was a focus a few years ago), that one of the features of Javascript is that it's universal/isomorphic. And that the average computer (and even smartphone) is very powerful, so if storage is abstracted, the distinction blurs. To me, this means features like browser based tools, which are gradually becoming more user friendly, don't really need a "server," except perhaps as a way to coordinate and for long term storage. Eventually, I think a non technical user should be able to create content that contains open-ended dynamic formatting and distributed data based views, without a round trip to a server. If they want to dip into arbitrary Javascript, maybe just re-using a module, fine. Ultimately, the same code might be used in the browser as that in a development process. Current markdown tools and notebooks are headed in this direction. However, trying to use something like mdx-js shows we are far from reasonable bundle sizes when taking this approach. One-tool-per-application might yield the small bundle sizes and dynamism for this goal. Wondering if Rome has this goal in mind. Thanks!
Why start this from scratch ? Why not build on top of TypeScript ?
I get the single pass rationale but isn't it possible to integrate a bundler into TypeScript compiler ?
I'm just wondering because Microsoft has a decently sized team of paid engineers working on TS for years now - what are the odds an OSS project outperforms them at implementing their own language (which they also evolve with every release)
The TypeScript compiler API[1] is beta, underdocumented, and not really designed to support use-cases other than working with an abstract AST. It’s OK for transpiling, but would be a bit awkward for writing a linter and not at all suitable for a formatter.
As an example of the sort of problems you might run into with the API in its current state, trying to parse and then pretty-print code can cause comments to vanish[2] under certain circumstances. This is fine for transpiling, but is a major issue when you’re trying to prettify and overwrite the original source file.
I think the odds are pretty good. The TypeScript compiler's performance is not optimal: https://twitter.com/evanwallace/status/1275945317045657602. Microsoft's TypeScript team has a lot of priorities and other things likely take precedence over performance work.
Also it's pretty trivial to build a faster compiler if you don't have to worry about type checking. You can still have type checking with a bundler that ignores types by running the official TypeScript type checker in parallel with your bundler.
But without typechecking I still have to run a separate tool during development (which is where single pass performance matters the most me) - so suddenly it's not a single parse all-in-one solution.
esbuild does not type check. TypeScript type checks and then emits code. Better performance can be achieved by just stripping types and emitting code.
It would be great to improve the performance of type checking, but that’s more complicated.
Some project are trying, the Deno maintainers have asserted that TypeScript should be rewritten in Rust for better performance. swc is trying to do that - https://github.com/swc-project/swc/issues/571
I just don't see the use case for RomeJS and I'm not sure people will want to wait several years for this project to mature. esbuild seems to hit the sweet spot for ESNext/TS/JSX/bundling - it's 100 times faster than current tooling and works today with with next to no configuration.
Readit News
On the other, as someone who used to do some "JS platform" work at a tech company, I really don't want Rome to catch on. Yet Another Standard is really painful for the ecosystem, and while it's obnoxious that you need so many tools, at least we've finally settled (mostly) on good answers for each vertical. TS, ESlint, Prettier, Webpack, Babel.
Now, would it be nice if there were an underlying engine/server that all tools could use to share an AST without reparsing everything? Sure, I guess. Would it also be nice to have one tool that wraps the others, at least when you're getting started? Yes, though I think create-react-app has blazed that trail pretty well.
The thing is, all those tiny little details from Prettier and ESLint and Webpack really matter – Rome will take years to achieve the number of lints that ESLint has, and even more years for the community to agree on which ones matter. Similarly, every corner-case of prettifying will have to be considered anew, and every edge case of bundling rebuilt or reimagined.
I love to see a talented person take on something insanely ambitious, so I wish him luck and hope he proves me wrong. But if Rome succeeds, it'll be a big pain for a lot of people as they try to port everything over, and for the community as they grapple with dueling standards for how things should be done.
Rome being successful doesn't mean eliminating those tools, it's providing something valuable and giving people an option. If it's not for you then that's okay. Rome is early and is still evolving, including possible areas for extensibility.
I think a lot of people don't realize the sort of capabilities that they're missing out on by not having their tools work together, or sticking with old tooling that cannot innovate for legacy reasons (like Babel). I don't think it's harmful to the ecosystem to advocate for more consolidation, especially around tooling that not a lot of people either like to deal with, or have few maintainers in the first place.
I also think you have me (Sebastian McKenzie) confused with Sebastian Markbage from the React team.
Reading your comment, it sounds like you expect some people might use Rome for some things (say, linting and compilation) and preexisting tools for others (say, formatting and bundling). Is that your intent?
My way of coping with the appearance of yet another new-and-hyped thing, is to not complain and resist, nor to try to immediately learn the thing, but rather the much easier task of learning the why of the thing. Equipped with this knowledge, I can grok the JS ecosystem as a whole, and make better choices when it's time to choose a tool.
I do agree it's super exciting to see Sebastian McKenzie launch out with something new. I think I understand the why of this, and wish him every success!
As a developer, I haven't had any qualms with ESLint, so I wouldn't really have any reason to pick up Rome. Now if the full tool set offers lots of things, then I might consider replacing my current Vue template / create-react-app, but that's a big step.
All of this to say, no, it's not an appeal to authority. It's sounds like a "I'm not sure I can imagine this being worth switching to because we have something that works and is stable now, and we haven't had a great track record with tooling churn in JS world". It's a value add question.
Even if it somehow manages to succeed at its mission and become the defacto toolchain for all of frontend, I feel its improvements over the status quo will be short lived, and over the long run having a monolithic toolchain dominate will prove to be a net-negative for the frontend tooling ecosystem.
Having a single defacto monolithic toolchain greatly raises the barrier to entry for new competing tools, as they'd no longer be able to just compete on the merits of doing any individual task better than its direct competition to gain adoption.
Having different single purpose tools that can people can pick and choose from independently of each other is a crucial part of what has enabled rapid innovation in the JS tooling ecosystem up till now, since it keeps implementation/switching costs for any individual tool as low as it can reasonably be for that specific use-case.
This comes at the cost of making it harder for any individual to keep up with all the latest innovations (as critics of the JS tooling ecosystem are often quick to point out), but projects like create-react-app have been fairly successful at addressing this through sourcing collective wisdom from the community to create a collection of best-in-class tools configured to work effectively together out of the box.
I can also totally emphasize that there are many low-hanging fruits in terms of efficiencies to be gained through unifying tooling to avoid wasted work and maintenance overhead, but I'm of the opinion that the gains in efficiency isn't going to be worth the cost in potential for stifled innovation, and that those efficiencies are better achieved through shared specs and shared low-level libraries that individual tools can choose to adopt if they become compelling enough.
I'm personally still going to be rooting for single purpose tools + curated collections over any monolithic toolchain.
Specifically motivated by this popular issue: https://github.com/prettier/prettier/issues/5814
:)
When the web moved from jQuery to React, the details developers cared about changed. Opening modals got harder, but thats okay because React made so many other things better.
React is good enough to force us to adopt compilers for a language that doesn’t need them. When people complain about JavaScript on Hacker News, it’s usually about the build tools – and Rome has a shot at being an answer to that.
The web is more mature now, but that doesn’t mean the time for new tools is over.
sebmarkbage is one of the architects of React and a TC39 member. He's known for the Fiber architecture, among other things.
sebmck/kittens wrote 6to5 as a teenager in Australia, eventually landed a job doing JS infra at Facebook, and now works at Discord. He's a founder Babel, Lerna, Yarn, and now Rome.
I cannot deal with these kind of statements and that's probably why I never use linters for my own projects. And yes, my code is good enough, a linter won't make it any better. It just blocks me time and time again and litters the codebase with: // eslint-disable-next-line
I never really understood why these tools are so popular and who really needs them. In the end it's all about the result of the code you've written, how easy it can be maintained and how good it works. No linter can help me with that.
Initially the practice is detestable, especially if you've already developed some hard-fought coding chops without them. But after some time the practice itself influences your ability to write better code to start with, and successive tests become terser and more useful.
I think the same is true for linting. I found being involved in projects that enforce linting rules on commit to be insufferable, so I installed Prettier and configured it to format on save. Over time the auto-formatter did less because of the habits I was picking up.
I did have to confront the idea of being less precious and attached to my own coding-style, but frankly I still have pretty strong opinions despite having an automaton do my thinking for me in some of the projects I work on.
Of course, neither tests nor linting are a panacea, but so long as you give a hoot to start with you won't be able to avoid writing better code after using them.
Then you're perfect or your environment is perfect. Or you work alone?
To me, (and with the conversation restricted to applications, not websites or anything that is primarily a document for consumption), we should be going in exactly the opposite direction; reducing the number and scope of the extra tools we need to use.
We should be making bundlers unnecessary (javascript modules plus smart http 2 servers are one way, service workers are another), we should write code that targets the js that modern browsers understand so that babel is unnecessary as part of our main workflow and is only run if you want old-browser compatibility, we should look at folding the key parts of react into the DOM (firefox used to have something really not all that different from JSX, and the core functionality of react is pretty small - the DOM is a virtual DOM). Linting and source code formatting should primarily be part of your IDE/Editor workflow. Testing needs vary, and I want to be able to use the right framework for testing for the project without having to bring along all the other cruft.
What I loved about the web when I first started building apps for it was that I could start with a single file in an editor and grow from there. Making a change, pressing F5 and seeing the change immediately was so liberating compared to long compile times and complex build systems. With your code carefully written so as to fail fast, you could often see failures in the live application faster than my Java IDE would pick up a type error in Java code (anyone remember the white menu bar of doom?).
I think it's a great pity that we've taken one of the web platforms major strengths - fast iteration times, and added so much tooling. We used to scoff at the fake stackoverflow question where someone asked 'how to do addition in jquery', but the sheer quantity of tooling that is normally used for projects has put us in a similar position.
Wanting a project to be successful because of the person who started it is a terrible reason and has had (unsurprisingly) terrible results wherever I've seen it in the OSS community.
I feel the exact opposite: things like Rome (and Deno) are exactly the kind of projects that are needed in order to sort out a horribly fractured eco-system. I don't care who built them as long as they work well to solve the problems that so clearly exist.
I somehow misinterpreted pipenv being an official python project. My usecase was pretty simple, I wanted a requirements.txt that only included the things I explicitly installed with perhaps a requirements-lock.txt with the actual list of things installed. :/
I didn’t even realize poetry existed until I talked to people who do python full time.
Have we? I have 2019 projects I have worked on that dont use TypeScript and while I dont mind TypeScript I have a YAGNA attitude about it still. My coworkers seem to hate it despite never having used it. I think of TS as almost irrelevant if you can do JSHint but thats just me coming from Python 3 where type hinting is valid and doesnt require additional tooling to make it work.
Sadly I understand why JS syntax doesnt expand too much over the years and you need something like Babel.
But on the other hand if we stopped allowing legacy web clients we could probably push modern JS to more mature stages including type hinting (optional of course) as was done in Python 3.
But if you want to? Each vertical has a de-facto community standard at this point. If you want typechecking, it's TS. If you want formatting, it's Prettier. Etc.
And of course, nobody's captured 100% of any of these verticals - there are plenty of people who use Flow o Reason for typechecking, or "StandardJS" for formatting.
But a new person setting up a JS project can just install the community standards at this point and be fine (albeit bothered at configuring things, if they don't use c-r-a).
Deleted Comment
If you want more configuration, build your own, and most people will do. But for the novice, people who do multiple new projects a year, or people who don't care about details, Rome will be great.
For homemade projects, I use CodeKit, and I think Rome will be the same without the friendly and refined GUI.
Deleted Comment
https://2019.stateofjs.com/javascript-flavors/#javascript_fl...
- ESbuild (100x faster than webpack in part due to focus on doing a single parse (but also shipping a Go binary))
- Deno
- Rome
As we consolidate on the jobs to be done we expect out of modern tooling, it makes sense to do all these in a single pass with coherent tooling. It will not make sense for a large swathe of legacy setups, but once these tools are battle tested, they would be my clear choice for greenfield projects.
recommended related reads:
- https://medium.com/@Rich_Harris/small-modules-it-s-not-quite...
- (mine) https://www.swyx.io/writing/js-third-age/
https://amasad.me/disintegrated
I just know that every time I revisit any JS front-end stuff, I end up punting and just manually adding script/stylesheet includes for Vue and Bootstrap or whatever so I don't need to deal with half that crap. As an outsider it's always so daunting, and I feel like whatever I learned 6-12 months ago last time I needed to do something doesn't necessarily apply anymore.
* create-react-app serves as a very basic frontend template for a React project. It eliminates worrying about Babel, webpack, polyfills, etc
* next.js / nuxt.js solve both front-end and backend for React / Vue. Likewise they package webpack, Babel, typescript, etc, and also help with bundle splitting, routing, and server-side rendering that used to take 30 different packages and 6 think-piece blog posts. It’s good stuff (I can speak for Next, dunno about Nuxt)
Undeniably, it's technically ambitious to build all these pieces under a single umbrella. And then, convincing people who are honestly scared to touch their Webpack config to switch to a new tool might not be easier.
But if Rome booms, it'll truly benefit the community.
If someone can offer me a convincing alternative to webpack I will switch in a heartbeat.
Basically, Rome will most likely need somewhat of a Typescript moment. Where it's just transitioning to the new normal for (many) JS projects.
I really like Babel because of its plugins. My project typecheck.macro, could not exist without Babel plugins.
How will Rome support compile time transformations like graphql.macro or typecheck.macro?
Compile time plugins allow JavaScript to evolve super rapidly & make the creation of frameworks that act as compilers instead of traditional frameworks possible.
[1] https://github.com/vedantroy/typecheck.macro
This is the first release and until there's some actual usage, there's no real way to realistically predict what sort of things people will feel is missing. You can always supplement your project with multiple linters if you feel like it is currently a blocker.
As someone who works on libraries that don't use JSX, and therefore have to rely on compiler and linter plugins to get support (tagged template literals in my case) I worry that React's dominance will mean that it gets a place in Rome, while other systems are locked out, which only increases React's dominance.
Would you consider an internal plugin system as a first step, where plugins have to be part of the codebase, but intentionally get a restricted API surface? This would allow you to try out and refactor the plugin API over time before committing to it publicly.
Constantinople and Moscow are waiting, as well as Venice and London. A plugin system that wants to incorporate everything will risk having to maintain Byzantine diplomatic relations. On the other hand, restricting the plugin system to its core will create a local powerhouse that will utterly fail to adapt once new ventures become available.
I am waiting for the TypeScript / JavaScript split.
I, for one, welcome a future of build tools without plugins.
If you can do the same work in fewer passes, it will often be faster
So instead of every file change, webpack runs its own parser, then Babel runs its own parser, then ESLint, etc — Rome probably just runs the parser once and sends the AST to other plugins
And then if you invest in making the parsing stuff really good, that makes the linter better, the Babel-equivalent better, etc
- Only one tool to configure, instead of many
- Many tools revolve around parsing your code and generating an AST, then manipulating / processing that AST (Prettier, ESLint, Babel, TS, Webpack, ....). That's a lot of extra processing that has to be done. In theory, doing all that processing _once_, and reusing the AST, would potentially run a lot faster.
(And it would be good to put something to that extent prominently on the website, if it isn't yet.)
They also just recently released Heft which is the rushstack repo build/lint/dev-server stack.
It’s a promising project
I get the single pass rationale but isn't it possible to integrate a bundler into TypeScript compiler ?
I'm just wondering because Microsoft has a decently sized team of paid engineers working on TS for years now - what are the odds an OSS project outperforms them at implementing their own language (which they also evolve with every release)
As an example of the sort of problems you might run into with the API in its current state, trying to parse and then pretty-print code can cause comments to vanish[2] under certain circumstances. This is fine for transpiling, but is a major issue when you’re trying to prettify and overwrite the original source file.
[1] https://github.com/Microsoft/TypeScript/wiki/Using-the-Compi... [2] https://github.com/microsoft/TypeScript/issues/39620
Also it's pretty trivial to build a faster compiler if you don't have to worry about type checking. You can still have type checking with a bundler that ignores types by running the official TypeScript type checker in parallel with your bundler.
A lot more than you imagine. Esbuild can already transpile 100x faster than typescript.(Note: esbuild does not typecheck).
If they use similar technique as esbuild, they can easily surpass typescript compiler in all functional areas
It would be great to improve the performance of type checking, but that’s more complicated.
Some project are trying, the Deno maintainers have asserted that TypeScript should be rewritten in Rust for better performance. swc is trying to do that - https://github.com/swc-project/swc/issues/571