News for hackers. Stuff that matters.
Re:Rome: An experimental JavaScript toolchain by throwaway894345 on Monday April 13, 2020 @12:23PM (#22857183)
Maybe this is intuitive to JS devs, but what are the advantages of "zero third-party dependencies" and "being a comprehensive tool for the processing of anything JS related" or any of the other selling points of Rome? It seems like an impressive project, but it's not obvious to me what its actual benefits are.
Re:Rome: An experimental JavaScript toolchain by lucideer on Monday April 13, 2020 @12:45PM (#22857427)
Dependency bloat is a problem in all popular programming language ecosystems, but has proven to be statistically a bigger deal in the JS ecosystem than in others.

Real problems this causes:

1. security surface area. Running npm audit in many large projects is going to give you scary results. And that's just the known advisories.

2. 3rd-party support. How many of the 1000+ packages you've ended up pulling into your node_modules will continue to be actively maintained throughout the life of your project, what stability pains will dead subdependencies cause, and what will the long-term maintenance cost of rooting them out (and finding equivalent replacements) be? Will it cause forced deprecation of features in your app?

So with all the above, low-dependency/no-dependency projects are attractive. Many go to extreme and repeat the old mistakes of NiH. Rome seems to me to be this extreme kneejerk (and liable to some serious lock-in).

The sensible thing here is moderation: just choose dependencies carefully.

Re:Rome: An experimental JavaScript toolchain by protonimitate on Monday April 13, 2020 @01:39PM (#22857992)
I like the idea of simplifying the tool chain, but I'm curious how flexible Rome will be in terms of settings/customization.

Like, if it "replaces webpack", am I locked into Rome's idea of what an "optimal bundler config" looks like? If I need more from a bundler, do I have to completely replace Rome with the "old" toolchain? How extendible is Rome on its own?

I'm wondering if it will have something like CRA's "eject" that allows you to override the defaults, without having to replace entire portions of it.

Re:Rome: An experimental JavaScript toolchain by dschnurr on Monday April 13, 2020 @12:32PM (#22857282)
Starting a new JS project these days can be a huge hurdle for many users because they have to manually set up all the compilation/linting/testing/formatting etc infrastructure, each of which have multiple possible libraries, versions, and non-trivial configurations. You could spend a week configuring webpack alone to get code splitting, css compilation, etc to work. Projects like create-react-app and next.js have helped remove some of this fatigue, and you can see by their adoption just how much of an impact this has. Seems like Rome should be similarly beneficial without being inherently tied to an application framework like create-react-app or next.js – the challenge will be avoiding a confusing mess of 1000 configuration options to fine-tune each subsystem.
Re:Rome: An experimental JavaScript toolchain by hn_throwaway_99 on Monday April 13, 2020 @01:36PM (#22857962)
This is exactly it for me. Just setting up my project took well over a week (not like I couldn't do anything before that week was over, but getting everything how I wanted it was very non-trivial). Granted, a lot of it was because I was new to TypeScript, but I also got into a bunch of version hell trying to get TypeScript/Prettier/ESLint/VSCode to all work together on my machine because there were a bunch of version incompatibilities when tslint was essentially deprecated in favor of eslint for TypeScript.
Re:Rome: An experimental JavaScript toolchain by lxe on Monday April 13, 2020 @12:34PM (#22857295)
Less dependencies = less layers of indirection and complexity making feature addition, iteration, testing, and debugging easier and much faster. If you need to change or tweak a function that a dependency usually covers, it's much easier to do if you're dealing with one single codebase (using same style, idioms, build structure, etc...). You don't have to worry about pinning or unpinning dependency versions and keeping track of their security issue, patches, and minor/major bumps.
Re:Rome: An experimental JavaScript toolchain by ratww on Monday April 13, 2020 @02:28PM (#22858506)
This is the big one for me. Just looking at the Create-React-App dependencies I can count 17 dependencies dedicated to interconnecting Webpack/Babel/ESLint/Jest/Terser/Typescript.

Plus there's the cost of having plugin-infrastructure and/or maintaining a public API inside the six tools themselves. Plus all of them have dependency on a parser.

Having it all in one single tool will tremendously reduce the amount of code necessary.

Re:Rome: An experimental JavaScript toolchain by gear54rus on Monday April 13, 2020 @12:28PM (#22857245)
It's not intuitive to me as a JS dev too... Are you guys gonna re-implement typescript for example? Where does 'no deps' line get drawn?
Re:Rome: An experimental JavaScript toolchain by koboll on Monday April 13, 2020 @12:52PM (#22857503)
"No dependencies" isn't quite accurate. There are a couple, and they are TypeScript and related packages: https://github.com/facebookexperimental/rome/tree/master/nod...

But everything else is on track to be reimplemented within Rome.

Re:Rome: An experimental JavaScript toolchain by coolwhit on Monday April 13, 2020 @01:52PM (#22858123)
Note that the TypeScript dependency is not used at runtime. It's only used to type check the Rome source code.

Source https://news.ycombinator.com/item?id=22431169

Re:Rome: An experimental JavaScript toolchain by kkio on Monday April 13, 2020 @12:34PM (#22857298)
Echoing this sentiment. I think there's value in consolidating parts of the JS toolchain as there's a lot of variability there with how you can adjust your build system and pick your flavor of the week linter/formatter/bundler/etc. I'm not sure how 'no deps' is a a feature though, aside from (potentially) less packages to download during development.
Re:Rome: An experimental JavaScript toolchain by kevmo314 on Monday April 13, 2020 @12:38PM (#22857348)
Same, I don't mind having an alternative to webpack, but competing against prettier is going to be an uphill battle.
Re:Rome: An experimental JavaScript toolchain by ratww on Monday April 13, 2020 @02:38PM (#22858600)
I don't know. The whole point of using Prettier is that you're delegating your style choices to someone else.

And there were already some (very small) breaking changes between Prettier v1 and v2.

Changing from Prettier to something else doesn't sound like that big of a change, as long as Rome's formatter is not too ugly or changes are too drastic.

Re:Rome: An experimental JavaScript toolchain by kevmo314 on Monday April 13, 2020 @05:25PM (#22860210)
It's more of a network effect though that keeps me using prettier. These days I end up using prettier in codebases so my code looks like everyone else's, not just so it's self-consistent. It just makes it easier to read.

You're right though if Rome has a formatter that looks nice I suppose I wouldn't care, but at that point it's sort of like why not just use prettier?

Re:Rome: An experimental JavaScript toolchain by ratww on Tuesday April 14, 2020 @03:51AM (#22863606)
> You're right though if Rome has a formatter that looks nice I suppose I wouldn't care

Well, then I guess it wouldn't be an "uphill battle" :)

Re:Rome: An experimental JavaScript toolchain by thinkloop on Monday April 13, 2020 @12:29PM (#22857260)
It's a common story: monolith or microservices? Linux do one thing well or holistic cohesion? Mega repo or many small ones? There are pros and cons. Nothing in the universe is currently more fragile than a modern js toolchain tho.
Re:Rome: An experimental JavaScript toolchain by capableweb on Monday April 13, 2020 @12:33PM (#22857289)
This is all expanded on in the README:

> No external dependencies. This allows us to develop faster and provide a more cohesive experience by integrating internal libraries more tightly and sharing concepts and abstractions. There always exist opportunities to have a better experience by having something purpose-built.

See more of the technical reasons behind Rome here: https://github.com/facebookexperimental/rome#technical

Re:Rome: An experimental JavaScript toolchain by austincheney on Monday April 13, 2020 @01:22PM (#22857805)
> what are the advantages of "zero third-party dependencies"

Dependencies are great for solving problems you are not willing or capable of solving. They are great when you need them, but most software includes dependencies that aren't needed or even directly requested. That is bloat. For example the Angular JS framework requests nearly 1100 NPM dependencies. That is a tremendous amount of code for an insignificant value add.

Re:Rome: An experimental JavaScript toolchain by komali2 on Monday April 13, 2020 @01:26PM (#22857867)
For example when webpack 4 came out, A bunch of loaders broke, but other ones depended on it, and I had to spend a full week trying out different numbers after my packages in my packages.json (the dependency file for node projects) until everything worked again. And then 2 weeks later shit started breaking again when we needed to add another library.
Re:Rome: An experimental JavaScript toolchain by baddox on Monday April 13, 2020 @12:27PM (#22857231)
I think the implicit benefit to doing it this way is that it will just work because there are likely few options and all combinations of those options will likely be tested and supported by the developers.
Re:Rome: An experimental JavaScript toolchain by canacrypto on Monday April 13, 2020 @12:40PM (#22857373)
Greatly reduce the likelihood of supply-chain attacks.
Re:Rome: An experimental JavaScript toolchain by choward on Monday April 13, 2020 @12:39PM (#22857360)
Have you used npm before? It's a complete mess.
Re:Rome: An experimental JavaScript toolchain by heleninboodler on Monday April 13, 2020 @01:07PM (#22857651)
Prerequisites: npm