Lots to unpack here. Modern JS going just great.

This situation is avoidable

https://dev.to/thejaredwilcurt/bun-hype-how-we-learned-nothing-from-yarn-2n3j

Bun hype. How we learned nothing from Yarn

Here we go again, making the same mistake. I'm constantly reminded that every 5 years the amount of...

DEV Community

@brianleroux I really liked the fork of io.js what we got in the end was so much better node v4 was way beyond 0.12 the previous release. I’m also not convinced and npm would’ve gotten as good as it did without yarn. The tribalism and the incompatibilities are troubling. But the years it took npm to catch up are probably why yarn never shut down. Deno on the other hand has made node better, but I’m not tapped into its trajectory. It’s absolutely not like io.js.

Bun seems like a toy tbh

@reconbot diversity good overall. Treating open source as a competition instead of a scientific collaboration probably my biggest gripe. That and lying about performance and tradeoffs. React community has been particularly misleading and bad faith actors on this regard and Bun learned a lot from that.

@brianleroux @reconbot io.js worked because it was a true oss fork.

My deep concern is these new projects are pointing to examples like io.js as why we should trust them, but we’re seeing private companies with VC funding being spun up behind them. The pressures VC funding produces is a worrying new element that makes some of the lock in aspects of bun more concerning than they otherwise would be. If there’s money to be had, why isn’t it funding existing oss rather than greenfield projects?

@brianleroux @reconbot these don’t feel like OSS projects anymore they feel like loss-leaders. I’m open to there being new funding models rather than ā€œpassion project turned contracting opportunitiesā€ or ā€œlarge blue chip patronā€. But ā€œsell the service give away the softwareā€ starts to feel gross when there already exists an underfunded truly open project that is more than just a direct competitor.
@dcousineau @reconbot biggest irony being io.js was a fork of the venture backed private company joyent owned codebase known at that time as 'node'.
@brianleroux @dcousineau That’s kind of wonderful tbh
@brianleroux @dcousineau I agree, I just spent a good chunk of time looking at a venture backed terraform/k8s competitor (tbh not sure which they want to compete with) and like I can’t identify why it’s basically not closed source, other than you get better bug reports when the source is open. - which is sort of what hashicorp is doing
@reconbot @dcousineau oh man, that whole debacle made me extra happy we decided to go all in on cloudformation. someday, when azure catches up, a port to bicep is in my future.
@brianleroux @dcousineau CDK has been my goto for novel infra setups, it's far from perfect but the best abstraction I've played with for complicated things.
@reconbot @dcousineau yeah. idk. between the version 1 - 2 upgrade, typescript breaking in minors, and just the whole idea of executing transpiled js to generate a cloudformation document…none of that speaks to reliability to me which is exactly what i want from IaC. To each their own of course. I think Architect does a lot right for most use cases to make CFN more palpable but ack its not comprehensive.
@brianleroux @dcousineau All true! and technically you can eject but def cloudformation is the winner here
@brianleroux @reconbot I mean, Yarn was the one who didn't want to play with the rest of us. The NPM CLI team always had a pretty healthy relationship with the PNPM folks and we had pretty open channels with them. They even used a lot of our libraries for stuff like packing etc. Yarn refused to touch anything we wrote. They were 100% NIH-or-bust and insisted on figuring things out on their own, and it was incredibly frustrating because I'm very much a collaboration kind of person, and "competition" just stresses me out.
@reconbot @brianleroux whooooosh! I'd totally forgotten about iojs. ....am I.... old?
@morgan @brianleroux remember that rails fork around the same time? Forced rails to get better iirc, the merges of these projects were amazing times.
@reconbot @brianleroux thankfully no, I was already so fed up with rails at that point in time I was paying no attention to its ongoings. Then thankfully node came along saved me from my homegrown jetty/bayeux/rhino abomination.
@reconbot @morgan didn't remember that but looking around I did find this which is way awesome anyways http://www.openrails.org/
Open Rails - Free train simulator project

Write an awesome description for your new site here. You can edit this line in _config.yml. It will appear in your document head meta (for Google search results) and in your feed.xml site description.

Your awesome title
@brianleroux @morgan that's much more interesting - I found a blog post about
"Merb" https://yehudakatz.com/2020/02/19/together-the-merb-story/ but I'm gonna read your link instead
Together: The Merb Story

I'll never forget the day that I became a member of the Rails core team. For all of 2008 (and the better part of 2007), I was working on a competitor to Ruby on Rails called Merb. I loved Merb, and was excited to share it with anyone who'd listen,

Katz Got Your Tongue
@reconbot @morgan oh THAT. Merb was many years before io.js thing and the merge was a complete disaster so...idk. it's why I left rails community.
@brianleroux @morgan oh lol I was on the edges of it, I remember thinking "oh I have new features that people are happier about? great"
@reconbot @morgan that 2.3 to 3 migration was exactly when I became serious about stability šŸ˜‚šŸ˜­
@brianleroux @reconbot dang! C#, no linux builds!
@morgan @reconbot fun weekend project šŸš‚āœØ
@brianleroux @reconbot my winter project has already been settled on, completely over engineering converting my n-scale trains to DCC

@reconbot @brianleroux NPM Inc was internally in a certain kind of shape when Yarn came out. Its release shook things up in a very serious way and caused me and others a LOT of stress, and some of the most regrettable overworking I've done in my entire career, but it did directly lead to NPM@5 and subsequent perf improvements.

I think the thing that Yarn really did for us (us being the NPM team) is that it taught us that what people actually give a shit about is performance, not things being bug-free, or featureful, or cross-platform. As long as you can say your thing goes really really fast, people basically go ga-ga over it and forget all the other things that matter. They will put up with absolute trash in order to get those speed gainz (and, frankly, Yarn was a broken piece of shit when it first launched and you can't convince me otherwise). Heck, even Yarn's "ergonomics" being an improvement seems like bullshit to me.

All people actually wanted was a faster package manager, and as soon as they got that, they stopped caring about Yarn, except for the folks who had already made the switch and didn't really have a reason to bother switching back.

@reconbot @brianleroux anyway https://orogene.dev is faster than bun sometimes, and uses way less memory, and is actually built by someone who knows what they're doing.

Don't use it, though.

orogene

`node_modules/` package manager and utility toolkit.

@zkat @brianleroux I would never try to convince you otherwise, yarn is still a pita
@zkat @brianleroux I do appreciate the work that brought us the speed and lock files. Sorry it came at a cost.

@reconbot @brianleroux it’s the worst burnout I’ve experienced in my entire career and the most stressful several months where I felt there was an existential threat to my job if I didn’t work 12-15 hour days to get npm5 out.

Never again

@zkat @reconbot @brianleroux I'm still sore about the whole "yarnpkg registry aliasing the public registry at the CDN level" thing.

The teapot outage happened because of that proxy: our CDN had to add an exception to allow proxying between the yarnpkg domain and registry.npmjs, since they hosted both. Our CDN recommended we add strict host header checks to our worker. To my (dis-)credit, I flubbed this.

One yarn maintainer was publicly unkind about this in a way that still gets me angry.

@isntitvacant @zkat @brianleroux nothing makes me more annoyed when people put a proxy in front of my cdn, it makes life so much harder and forces some really arcane exceptions - but my customers have app level considerations I understand, what they did to you was sus af
@reconbot @isntitvacant @brianleroux they also made a big fuss about this proxy and cast some pretty serious aspersions about our intentions with the registry???
@reconbot @isntitvacant @brianleroux like, Yarn’s release was 90% FUD 10% benchmarks
@zkat @isntitvacant @brianleroux I had plenty of misgivings about npm.inc vs the volunteer group, but y'all put those to bed for me.. a lot earlier than yarn iirc. (And I recall the other companies trying to do the power grab to own npm and all that drama) It's still weird me out that github/ms has it but I guess it doesn't bug me too much.
@reconbot @isntitvacant @brianleroux afaict GitHub just don’t care about NPM anymore beyond just owning it. It’s barely even a skeleton crew at this point

@zkat @reconbot @isntitvacant it's stable, and been so for a long time now, so I'm happy. We just started dabbling with workspaces and its seems useful sometimes.

Ultimately for me the core features have been great (read: boring) for like decade now which is pretty epic foundation to built on.

@reconbot @brianleroux it has somehow gotten worse and more complicated. What the hell is up with Berry?!
@zkat @reconbot @brianleroux Absolutely. People, often treat performance as an afterthought. A really fast system can be a feature in and of itself. I think Linus Torvalds once talked about this when discussing #git. @git branching and merging were blazingly fast compared to SVN and that alone changed the way people worked.
@sumanthvepa @reconbot @brianleroux @git case in point. We ended up with an incredibly obtuse and user hostile version management system missing some key features because all people cared about was common case perf

@brianleroux everyone posting 'javascript' jobs needs to read this, cause from where I'm sitting (jarb hunting), TypeScript is alive and well.

Also affirming that I was right to ignore yarn and I'll be right to ignore bun (except for the two cute ones here at home)

@brianleroux in a recent project I let people talk me into using Bun (0.7.x) (which obviously led me to patch libraries to support Bun, subscribe to still open issues even now in oven/bun, and write workaround scripts) when they are not as well-versed in the culsterfuck that is the history of JS ecosystems.

I need to do better. :(

@brianleroux

> But Bun isn't doing that. It isn't taking something hard, and making a simpler abstraction for it. It's taking ESBuild and abstracting it just like how Vite is. It's not an improvement, it's basically the same thing.

šŸ‘ šŸ‘ šŸ‘ šŸ‘ šŸ‘

My bitching about like 9 out of 10 "cool new JS things" is mostly that.

Like, I just had someone ask last week "what do you think about Bun? it can start a http server in one line of code!"

I like to imagine there was at least some disbelief when I said in vanilla Node with no dependencies it takes two.

@brianleroux Bun, I remember there being a Peter thiel connection somehow that’s why it was immediately eliminated from my radar. Reading this looks like I haven’t missed anything.

@brianleroux OK I'm in like broad agreement, but also there's no reason to believe npm would have gained those features or gotten so much faster if yarn were not around, and plenty of reason to believe the opposite.

I can buy the conclusion, but also I think the author should have considered that idea.

Bun has got some traction because it is attacking real problems that people are suffering from - I hope the same thing happens and the mainline improves after seeing that.

@llimllib respectfully disagree. npm didn't have big problems as I remember it, but the fb marketing team certainly made it sound like it, and there is lots of evidence that technology trends to faster/cheaper (aka industrialization)