8 ms·
I like this tech "fights" (evolutions). Even if bun will not overtake node, it will make node better. We see this many times with other projects (js/coffeescrip
by progx 4y ago
I like this tech "fights" (evolutions). Even if bun will not overtake node, it will make node better. We see this many times with other projects (js/coffeescript/typescript/..., php/HHVM/HPHPc, webpack/vite/...)
- adam_arthur 4y agoHappened with node via io.js back in the day too
- culi 4y agoHadn't heard of io.js before but from reading up on it it seems to be a unique case since they had the explicit goal of merging back into node eventually. Can't really find what the main benefits of io.js are though...
- shard972 4y agoIt actually had developers. It was a political move by the devs against joynet who were refusing to give up full control of nodejs.
- gcoguiec 4y agoI would also mention io.js in Node's lifetime and Merb in Rails’
- dmix 4y agoHaven't heard the name Merb in forever.
- nesarkvechnep 4y agoAlso Elixir made Erlang better.
- ithrow 4y ago,npm/yarn
- ignoramous 4y ago> Even if bun will not overtake node... Why wouldn't bun, if it keeps its performance promises on its way to 100% node compatibility? I am intently keeping tabs on bun's progress because a better-engineered, faster, and leaner node-compatible runtime means $$ saved in server costs. Besides, from the effort going into bun, it looks like the node community has its work cut out.
- christophilus 4y agoAlso, a big reduction in dependencies could make hardening a Bun application something that’s realistic. It’s unimaginable with the typical node stack that I’ve seen.