Live data from Hacker News

Rome: An experimental JavaScript toolchain

romejs.dev

91–96 of 96 posts

Re: Rome: An experimental JavaScript toolchain

#91
post #73

Earlier quoted context omitted.

Nobody says a C file has a "dependency" because you have to compile it.

Like that point is fair, but almost no C code has no dependencies. Like just a basic application that returns 0 and nothing else from main will need to link to crt0. https://en.wikipedia.org/wiki/Crt0 However, you can compile C code as a bin file (just instructions). More common in the embedded world or you need to bootstrap an OS ect...

Static binaries do not have any dependency, and those that are not static typically depend on libc etc., regardless of the language being C, JavaScript (the browser) or anything else. So we don't count them as "dependencies".

But my point above was to counter the "C compiler is a dependency" claim. Nobody counts that way when discussing running programs, and that was my point.

Re: Rome: An experimental JavaScript toolchain

#92
post #41

I have been following the progress of this project on Twitter for months. However I'm very skeptical to see this project used in a production app. Re-implementing the entire JS toolchain for a modern SPA is a HUGE task, just checkout CRA dependencies : https://github.com/facebook/create-react-app/blob/master/pac...

I feel it is driven by Facebook security. Third party NPMs or "poisoning the watering hole" attack is feasible against big tech giants. Some cryptocurrency projects have already been hit by this.

Re: Rome: An experimental JavaScript toolchain

#93
post #73

Earlier quoted context omitted.

Like that point is fair, but almost no C code has no dependencies. Like just a basic application that returns 0 and nothing else from main will need to link to crt0. https://en.wikipedia.org/wiki/Crt0 However, you can compile C code as a bin file (just instructions). More common in the embedded world or you need to bootstrap an OS ect...

Static binaries do not have any dependency, and those that are not static typically depend on libc etc., regardless of the language being C, JavaScript (the browser) or anything else. So we don't count them as "dependencies". But my point above was to counter the "C compiler is a dependency" claim. Nobody counts that way when discussing running programs, and that was my point.

There are dependencies to build a program, and dependencies to run it. Sure a static binary can run without any run time dependencies if written to run on bare metal (without an OS). Although, you could go further down that rabbit hole and say the hardware is a dependency. (better start writing stuff in VHDL and Verilog /s)

Both types of dependencies do come up. However, most people don't consider language dependencies. However, if you for instances need to port your code to a lot systems such dependencies can suddenly be very important. Especially if you have to do the porting. So to say: "Nobody says a C file has a "dependency" because you have to compile it." is a bit disingenuous. There is a lot of C code that require features only available in certain compilers. At which point that code now depends on that compiler.

However, JS seems to have problem with too many dependencies, at times these dependencies can be trivial that is makes someone ask why...

Re: Rome: An experimental JavaScript toolchain

#94
post #90

Earlier quoted context omitted.

Same, I don't mind having an alternative to webpack, but competing against prettier is going to be an uphill battle.

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.

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

#95
post #90

Earlier quoted context omitted.

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.

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?

> 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

#96
post #3

This is a really exciting idea to me, but this website is pretty anemic (guessing it's a work in progress?). Kinda surprising to me, given the 7K stars on github. Maybe it should be submitted when it's a little more filled in?

As a person who’s getting ready to drop a project: what about the docs site is “anemic”? It’s using docusaurus which is pretty snazzy as far as docs sites go. Do you mean the amount of content on the site?

Content. It had like a single page, which didn't give me too much information...
Post reply on HN