Setting up typescript can be hard. Same goes for webpack, s3, postgres, jest and more. I also find the simplified file and stream access quite interesting.
Lets wait and see how a distributed deployment provider turns out.
Node just enabled it by default. You still need the dev dependency for manual compilation and checks, but at runtime it should "just work". https://nodejs.org/en/blog/release/v23.6.0
Maybe when it doesn't use WASM and there's proper integration. Otherwise it's just like npm and people still need to look for alternatives.
But yeah, there's progress, and once this gets solid traction (which I'm sure it will) it might finally be the last drop in the bucket to convince TC39 to stop being so antagonistic to having some notion of type-support directly in Javascript.
https://lwn.net/Articles/776239
That said, Python's 'mistake' also made it one of the most used languages ever. For nearly 2 decades, you could just type `python` in terminal and get rolling, and that was invaluable.
The only real 'mistake' that Python did was breaking backwards compatibility so spectacularly that single greatest feature was rendered useless.
Which feature are you referring to?
With compatibility break there was a decade of confusion, even the simplest print statement wouldn't work. I understand there were real reasons to do all that, but it did cause damage.
Steve Yegge put it better than I can[0]:
> the thing is, every single developer has choices. And if you make them rewrite their code enough times, some of those other choices are going to start looking mighty appealing. They’re not your hostages, as much as you’d like them to be. They are your guests. Python is still a very popular programming language, to be sure — but golly did Python 3(000) create a huge mess for themselves, their communities, and the users of their communities’ software — one that has been a train-wreck in progress for fifteen years and is still kicking.
> How much Python software was rewritten in Go (or Ruby, or some other alternative) because of that backwards incompatibility? How much new software was written in something other than Python, which might have been written in Python if Guido hadn’t burned everyone’s house down? It’s hard to say, but I can tell you, it hasn’t been good for Python. It’s a huge mess and everyone is miserable.
[0] https://steve-yegge.medium.com/dear-google-cloud-your-deprec...
No there weren't. It's just pure idiocy and incompetence.
I think there's a simple solution to all this. Libraries targeting third party protocols get an expiration date and have to forcefully be replaced by name after a given number of versions. Even if they keep the same underlying code, still change the name to force developers to look up its usage and legacy. How many versions? However many equates to the threshold you use to call most systems "legacy". I don't mind some job security and some timebomb punishment aimed at dinosaurs. I have bigger and more consistent issues with that than with weter or not C++ let's me crack a .rar without extra libs.
This is a curious take to me. I've spent the last 10 years seeing people claim again and again that if JS just had common stuff built in like <other lang>, we wouldn't have all this library churn, node_modules bloat, and left-pad silliness. That the mistake was not including a standard library.
Standard libs can be great, but they should really be reserved for baseline features, especially in a language like JS where all changes must be backward compatible. The standard JS has now is not at all what it was in the early 2010s, it's a very good set of baseline features.
Whereas the best solution in the galaxy might only work in a few selected planets, in other ecosystems without batteries.
I prefer batteries included, and not having a culture with a function per package.
It's cool that they're doing the mainstream thing now, but it's something for them to think about.
Regardless, the switch shows they pay attention and are willing to change.
They want to make bun an all in one runner in order to vendor lock you in somehow. But I might be wrong. It indeed does not make sense to put such dependencies in the core/std lib
Also.. I don't quite know how they're going to lock me in unless they mess with the license. I can deploy my own bun server anywhere, no? I'd be stuck on bun I guess but still not paying anything.
It’s a misguided approach according to me. And I feel Jared has become way too ambitious. But what can I say, it’s his passion project.
From the engineering standpoint, sure, it's a disaster.
But it's also the lost magic of TurboPascal and friends, where you could just be immediately productive, with no dependencies, no external tooling, on an old computer gathering dust in the school library.
They can easily provide official extensions/packages clearly namespaced and avoid all this mess. But I fear that they're more focused on a "headline-driven-development" approach, the more different from the status quo, the better
A set of "blessed" known good packages would be wonderful to have in any language, I wonder why it's not a thing.
It has just been a pretty low effort drop in replacement for me. It's definitely not a complete game changer, but quick iteration is just that bit more convenient since it's faster and I don't need to remember all the flags I normally have for my setup (Typescript, .env file, etc...)
Of the "batteries included" features, the `Bun.serve` web server and the `HTMLRewriter` HTML5 SAX API thing are very powerful, saving a lot of node_modules space.
Running TypeScript without a build step is neat. (I know there's `node --experimental-transform-types`, and it's great to see this feature propagated "upstream")
That said, for large established Node.js projects, I don't really see the pull to switch over to Bun. There's cost associated with it (for one, the built-in test runner works a bit differently, so if you're using `node --test` it'll require some fiddling)
Totally agree.
In their words, "Bun aims to be a cloud-first JavaScript runtime. That means supporting all the tools and services you need to run a production application in the cloud". This doesn't give me a lot of confidence.
This particular design choice seems even worse than Node.
We could argue that it's worse/better, but in the end it's just different. NodeJS when it appeared had the vibe and "marketing" to be something lightweight, fast and event-driven (compared to the alternatives at the time at least), where the 3rd party ecosystem provided the tooling for what Bun now tries to bundle into their "all-in-one" tool.
We've seen the same cycle multiple times. Developers need flexibility to configure something so a flexible solution appears, everyone gets excited and starts migrating. Eventually, more developers are tired of the flexibility and don't understand why there are so many configuration-options, so eventually a "all-in-one" solution appears, everyone gets excited and starts migrating. Eventually, people need to be able configure more things so....
Hypothetical example: S3 client built in, enable a flag and now get a dashboard seeing analytics around file downloads, download latencies etc
Just pure hypothesis on my end given they have to make money somehow at some point
I kinda like the idea of not having to import potentially very slow JS code to do things that I need in basically all my projects.
IMHO a stdlib should mainly provide standardized interface types, but not necessarily the implementations behind those interfaces. But that's probably not a very popular opinion since it falls between the two existing options of having a very bare bones and a batteries-included stdlib ;)
I think any competent company would be savvy enough to avoid lock in for a technology with adoption this low. I don't think that's what these features are aiming for. I think they're aiming for the young dev starting side projects that wants to get up and running quick. Or imagine teaching a bootcamp class and you want a tool that will do some magic for you so you can focus on explaining other complex aspects of web development
I feel like HN is on cognitive dissonance, they complain JS projects having too many dependencies and they also complain now when things are more integrated into the runtime because it increases vendor-lock and few extra megabytes (actually kilobytes according to the devs) to the binaries :/.
Lastly, big companies also prefer less dependencies, it is not just devs.
I'm all for it, and lots of Bun APIs are purely practical. Bun.stringWidth, for example, exposes code Bun already has internally. Nodejs probably has the same thing, but instead of us being able to use it, it gets reimplemented in 10 different versions in node_modules. How is that better?
I doubt the Bun team will have to change the S3 code very much over the years. The test runner, bundler, Postgres client, sure, I can see those being harder to maintain. But I'm also tired of everyone assuming everything needs to change all of the time. DX aside, my team is still on Webpack and we've only needed one new feature from it in the last ~5 years. Why can't Bun's bundler reach maturity and only receive a few updates?
So was XML before, and SGML before it. De-facto changes over time, and backwards compatibility means your decisions are cast in stone.
In 20 years, you could see s3 being abandoned for newer formats, but bun will have to keep those packages.
Ongoing maintenance burden. Ever increasing API, mistakes set in stone, subpar performance or properties.
"Standard library is where libraries go to die." exists as a saying for reason.
Finding documentation on that standard (particularly the edge cases) is very difficult
It would be better if the libraries were not the most optimal or good enough. In bun's case it is not just the minimal they are basically making everything as good as it can be.