5 ms·
I've got mixed feelings about Rome. There's so much room to cover with ridiculously slow tools today. But I'm sick and tired of these people in the industry dro
by andrewmcwatters 3y ago
I've got mixed feelings about Rome. There's so much room to cover with ridiculously slow tools today. But I'm sick and tired of these people in the industry dropping their toys because they're tired of working on stuff people actually use instead of just improving what they currently have.
Would it have been impossible to nudge Node.js in the direction of where Deno is today?
Would it have been impossible to replace Babel with a Go implementation?
I also don't want tools that want to be literally everything.
Imagine if Daniel Stenberg was like, "You know what I'm tired of cURL, let me rebuild literally the same thing in another language and give it a new name, and entirely different opts."
- badrequest 3y agoThere's this incredible phenomenon on this website where someone posts "Show HN: <tool>, but modern" where <tool> is something used by nearly every Linux machine in the last 40 years, and what makes it "modern" is Rust, inexplicably.
- scns 3y agoHow much time do you spend improving those tools you use? Honest question , zero snark intended.
- jupp0r 3y agoWho knows if curl would have ever existed if Stenberg would have invested his time in improving existing tools.
- muglug 3y agocURL is written in C, and also (definitionally) IO-bound so the benefits of rewriting aren’t obvious perf-wise. JS linters running in Node are mostly CPU-bound. You can get an order-of-magnitude improvement from writing those tools in Rust.
- andrewmcwatters 3y agoThis is being pedantic. That's not the point: do you have to literally abandon the project instead of rewriting it and leaving all your users out to dry? Would you get divorced from your spouse if something minor wasn't working out, too?
- scns 3y agoWaiting minutes for your JS based toolchain, several time each day is not something minor! I learned Reason with ReasonML and got spoiled. Builds there took fractions of a second. First time with TypeScript made we wanna cry. Some teammates disabled the pipeline before pushing, guess what happened.
- awestroke 3y agoWho's abandoning their project? Did all eslint and prettier maintainers abandon those projects to work on Rome?
- muglug 3y agoNobody is married to Node.
- makapuf 3y agoYou can't rewrite something complex. If you try to rewrite it you'll not achieve feature parity so it will be something different at least when you're building it. And you will perpetually chase your target. You MAY try to build something somewhat compatible starting small (not a replacement) or you can fork and gradually diverge
- 12345hn6789 3y agoThis is typical FE tech stack engineering. Invent new solutions to solved problems and sell solution as next hot thing. And what proceeds is what causes people to dread FE work.
- re-thc 3y ago> Would it have been impossible to nudge Node.js in the direction of where Deno is today? It's not the 1st time NodeJs required "forking". And so what if we do nudge Node yet again? It will just keep repeating itself unless there are bigger changes. > Would it have been impossible to replace Babel with a Go implementation? More like the world has changed since IE left the chat. We need less / different set of polyfills.
- jahewson 3y agoI think you’re underestimating the politics of open source and the thanklessness of making disruptive changes to something where a large and vocal portion of the user base just wants the thing to keep working as it is. Without breaking compatibility it’s impossible to fix the design mistakes of the past, so the most worthy changes are necessarily disruptive.
- deleted 3y ago[deleted]
- elteto 3y agoI think, in part, it’s because people want shiny tools and lots of new features but nobody wants their code to break when upgrading to a new version. Such is the duality of backwards compatibility. That leads to lots of churning with people working on scratching their own itches instead of “fixing” existing tools, because a lot of times that fixing implies breaking compatibility and upstream won’t merge the changes.
- throwaway894345 3y agoMoreover, whenever I’ve offered up a solution that scratches my itch, people complain that I should have focused on improving the current thing, but typically the maintainers of the current thing aren’t interested and have different priorities (probably very understandably!). When I can fix my problem by contributing upstream, I do so but it’s often prohibitively difficult.
- chromakode 3y agoIf Node.js changed rapidly towards Deno we'd be back to folks complaining about JS fatigue. Both Node.js and Deno have strong reasons to exist. Node has a massive installed base that values slightly more stability at this point. Deno benefits from being able to boldly explore big changes.
- WirelessGigabit 3y agoIt could have to do with the massive usage of JavaScript. But, I only see this happening in the JavaScript space. There seems to be something intrinsically wrong with JavaScript and NodeJS that a lot of the tools used to manipulate the language is written in other languages.
- dorfsmay 3y agoReally? How many ways exist to manage your dev env in Python?
- vacekj 3y agoToo many, I believe for the same reasons as Javascript. It's not a bad thing when the target language is simply unfit for developer tooling, but in case of Javascript and Python it's simply the speed. Doing massive AST manipulation in a language that is both slow and unsafe like Javascript just seems like madness, and it's strange that we've been kind of okay with it for the longest time.
- noahtallen 3y agoI wouldn’t discount all-in-one tooling. Look at a language like Rust — its std toolchain includes a doc generator, package creation, type system, linter, formatter, compiler, dependency management, etc. This makes for a very pleasant developer experience. JS has literally none of that, and yet has more strict runtime constraints. (E.g. if your user has to download your software every time they use it, it better download and be ready to use very fast.) JS has nothing like that, and it has been cool to see more experiments around this type of approach. Many disparate tools and versions are hard to manage because there are so many permutations of options!
- andrewmcwatters 3y agoI'm fine with it if it's the first-party language utility itself, but otherwise I'd prefer third-party tools to limit their scope.
- ovao 3y ago> Would it have been impossible to nudge Node.js in the direction of where Deno is today? I don’t think anything necessarily prevents Node from being nudged in that direction — and I think we’re seeing the first signs of that with Node 20 — but the implication in nudging is that it takes a comparatively much longer amount of time. Deno has its own set of challenges as a result of it being an independent project with its own sets of breaking differences, but I think the goal with Deno was try to push the JavaScript server ecosystem forward rather than to slowly nudge it forward (with the sizable resistance that entails). cURL is more singular here in comparison; there’s no rapidly-changing ecosystem that dictates the pace at which it changes or improves, but that’s not the case for the JavaScript ecosystem (see: Node’s many problems in keeping pace with the adoption of modules over the last several years).
- progx 3y agoCreate something new is always funnier as maintaining something old. The other problem with existing and working projects is, that they have maintainer and a community and you can't change things radically. That is a really long process. And sometimes competetive projects improve each other.
- conaclos 3y ago> But I'm sick and tired of these people in the industry dropping their toys because they're tired of working on stuff people actually use instead of just improving what they currently have. I have sometimes the same feeling. I often dream of a "united community" working on a "perfect tool". But there are so many differences in the community. In reality – as in most human systems – people create their own "dream tools". And the success of new tools influences earlier tools trying to catch up. Because Deno has some traction, this forces Nodejs to catch up. I think Bunjs has accelerated some changes in Deno's Nodejs compatibility. In the process, a lot of efforts seem lost. However, this is the way humans and communities are working: people learn by imitating others, changes are often pushed by new tools and systems that have more freedom to evolve.
- toastercat 3y agoThe Node/JS/React world is full of thought leaders who gain reputation and clout by releasing new tools/libraries, convincing the masses to adopt them and pay for expensive consulting/courses on them (instead of just having adequate documentation to begin with), and then abandoning it altogether to move onto their next "product" to "sell". Rinse and repeat. It's why if you're not paying attention, JS best practices will seem completely different in one year's time. Kind of a pessimistic view, but I do think this is what happens.
- sph 3y ago> The Node/JS/React world is full of thought leaders who gain reputation and clout by releasing new tools/libraries You call them thought leaders, Jamie Zawinsky used to call them attention-deficit teenagers, in his CADT model theory of open-source. www.jwz.org/doc/cadt.html
- qbasic_forever 3y ago> Would it have been impossible to nudge Node.js in the direction of where Deno is today? Yes, do you not remember the whole nodejs vs. IOjs split? The community is already pulling node in tons of different directions. > Would it have been impossible to replace Babel with a Go implementation? Again, yes it would be impossible by dint of the fact babel is made to be a framework where you process JS ASTs using JavaScript. Rewriting it in Go removes the whole ecosystem of JS plugins it built, which is kind of the entire point of the project. A Go rewrite of certain transforms is a new project.
- chaosharmonic 3y agoAlso Deno (along with Bun) did pull Node in its general direction -- the latter has finally started to ship things like test runners, a watch mode, and Fetch
- uhryks 3y agoThis. Same happened with npm starting to offer new features (like lockfiles) only after yarn had them. History has shown competition is only way to make them move.
- Waterluvian 3y agoThis reminds me of when npm was very slow and had some issues. So Yarn was awesome. Then npm got fixed and I don’t see a need for Yarn anymore. There’s a ton of value of everyone using the same tool even if it isn’t perfect for every specific use case. Now install readme files regularly explain both yarn and npm installs and the community needs to be aware of the existence of two basically identical tools.
- scns 3y agoAnd pnpm fixes a flaw both of them have (had?).
- satvikpendem 3y agoYarn 3 is still better than npm these days due to PnP, if you choose to use that, but even if not, it's also much faster at installing node dependencies than npm.
- silverwind 3y agoYarn is actually slower than npm these days. Here's some current benchmarks: https://github.com/orogene/orogene/blob/main/BENCHMARKS.md https://github.com/orogene/orogene/blob/main/BENCHMARKS.md As you can see, both bun and orogene beat the js implementations by miles.
- re-thc 3y agoNpm is still slow compared to yarn and pnpm.
- inglor 3y agoNode literally implemented every Demo complaint except TS which was easy enough. It's part of why Debi is still without significant market share.
- IshKebab 3y agoPure nonsense. Has it implemented: * Single file scripting with dependencies * No node_modules folder * Typescript built in. You might dismiss it as easy, but it's only easy in the sense that it's not a lot of work if you've done it. It's still a massive faff and paper cut. Whatever the next thing up from a paper cut is. Toe stub? * Guaranteed type hints. * A good standard library
- inglor 3y ago1) yes (sea) 2) yes (experimental http imports and import maps) All the others are subjective (and wrong :))
- re-thc 3y agoIt hasn’t even caught up in performance…