4 ms·

It's weird their promotional video repeats "you can do <million things> without installing dependencies", if I want headless browser testing is that wrong to in

• Jcampuzano2 2mo ago
  Its strange how flip floppy the JS ecosystem is, because go back literally 1-3 years or so and the BIGGEST complaint was the lack of a standard library and having to use a package for everything. But now that Bun is actually doing it its somehow bad? Its also still open source, so those implementations you mention need dedicated teams can still get the attention they need by the community if needed. I'm on the side that I'd actually prefer if node included more out of the box and we could drastically cut down on the number of packages we need due to the amount of supply chain attacks that happen on packages in the node ecosystem.
  • optionalsquid 2mo ago
    Is that flip-flopping or just different developers having different preferences? Those who complain now would have had no reason to complain back then, and vice versa
    • nozzlegear 2mo ago
      Also known as the Goomba fallacy: https://en.wiktionary.org/wiki/Goomba_fallacy https://en.wiktionary.org/wiki/Goomba_fallacy
    • nicoburns 2mo ago
      I'm pretty sure it's this. There's a genuine split in the developer community over this issue. And the JS community in particular is enormous.
  • pier25 2mo ago
    I agree and I also wish Node did more. Otoh should a standard lib give you absolutely everything? Probably not. There needs to be a line somewhere. Right now Bun’s policy on this seems to be "whatever Jarred feels like should be in there".
    • erlich 2mo ago
      > "whatever Jarred feels like should be in there" This is the main draw. Everything he implemented was fast and minimalist and he usually implements a standardized api (web apis, esbuild bundler api). The opinionated stuff is usually very common sense. Most of the libraries OC mentions are things you would just like to be as fast as possible above all else.
    • barnabee 2mo ago
      My line for exclusion from standard library is a library that’s any one of: - not obviously/generally useful (i.e. useless or too specific/should be a program not a library) - obviously trivial - already available (open source) elsewhere by a credible team that supporte and maintains it Anything else… put it in the stdlib
  • evilrabbit99 2mo ago
    wasn't that complaint mostly about those tiny dependencies like `is-even` or `is-array`? I feel like nobody complained that you needed to install a dependency to do headless browser testing for example.
  • ivanjermakov 2mo ago
    Standard library is up to the TC39 committee, not a VC-funded all-in-one JS runtime owned by Anthropic.
  • joshkel 2mo ago
    I would guess that many devs' preference would be for a larger standard library, but not a kitchen sink. Personally, I'd be happy with a larger suite of utility functions (say, most of Lodash / es-toolkit - remove the need for left-pad silliness), probably SQLite bindings (having a good persistence layer is great, it's perhaps the most robust and most widely deployed software on the planet), but not YAML (complex, security concerns, parser differences) or image handling (again, security concerns). Node.js is, IMO, actually pretty good these days; they're regularly adding useful built-in tools that remove the need for add-on packages. (The ecosystem is so big that getting those updates to filter out is hard.)
    • spankalee 2mo ago
      SQLite bindings should absolutely not belong in a JS "standard library". SQLite is a project that most JS environments won't have enbedded.
      • mort96 2mo ago
        There should be a space between "in the standard library" and "in a library written by some random person with a github account". An sqlite driver does not need to be bundled by the runtime, but it would be pretty great if there was an official sqlite driver library developed and supported by the node.js project but distributed through NPM.
  • verdverm 2mo ago
    I could argue that one implementation adding these things does not make a std library. You lose portability and fracture the ecosystem, which is probably one of their intentions
  • stevefan1999 1mo ago
    I would argue it is more of a politcal problem, rather than in tech problem. It is the same idea arounds LLM: people loving it keep praising it and criticise the haters, people hating it keep nitpicking it and criticise the lovers, and both of them tries to poach you to go to their side. So no matter what, those people would also try to find things to shit on Bun if they make a move even if it is considered rational. So the whole thing is never about tech anymore, it is about wanting Bun to succumb to their will.
• tempaccount420 2mo ago
  It's faster to have it in the runtime in native code. You have more options, not less, you can still use the external dependencies.
• cnqso 2mo ago
  I personally do not feel limited by the ~100mb binary size. We're working in Javascript after all.
• preommr 2mo ago
  > Why would I want everything reimplemented in this massive binary? Why would Bun be anymore in touch with nuances of all these different technologies then individual projects dedicated to their own speciality? It's funny because the top article on HN is about a malicious rust crate package, and people keep making comparisons to js/npm and how both language suffer from frequent security issues because they have weak std libs.
  • andai 2mo ago
    I saw a post recently about how LLMs are much more effective in Ruby on Rails because it's batteries included, so you don't get so many implementation details crapping up the context window. I assume the same benefit applies to humans as well!
    • DanielHB 2mo ago
      I am not into the Ruby on Rails world, but I find LLMs much more effective with powerful type systems like Typescript. Especially if you nudge it to keep things strict and (statically) eliminate invalid states. Do they use similar systems (build-time typing) for Ruby? When the LLM can verify its own output by running static analysis they produce better results. They also seem to understand type definitions and avoid going to the source which, in theory, should reduce context size.
      • brandensilva 2mo ago
        Elixir started adding a type system as well after Typescript proved to greatly help AI feel confident in its output. So yeah others are catching on the importance of a type system to enforce that successful contract for AI agents.
    • CuriouslyC 2mo ago
      If agents are good at RoR, it's ironic because they're bad at Ruby. They aren't good at holding a model of the 20 different things various code you've loaded has monkey patched, no longer respecting their original contracts.
• maherbeg 2mo ago
  Some of these feel like solved problems effectively, so having them in the standard library is nice (at the expense of keeping these forever for backwards compatibility once a new tech replaces it). I do think having a larger standard library for common things (like golang) is the way to go. If a dependency seems to basically be installed by default everywhere, maybe it should go in the standard library.
• Aurornis 2mo ago
  > It's weird their promotional video repeats "you can do <million things> without installing dependencies", A couple years ago a common complaint was that the JavaScript ecosystem relied too heavily on dependencies for everything. Remember the left-pad incident where the developer deleted the popular dependency out of protest for reasons I can even remember? Or when colors.js was sabotaged to break everything that depended on it? The node-ipc package was sabotaged to delete files on developer’s machines. Then we had a wave of supply chain attacks that tried to insert malware into build scripts of popular dependencies. So the ecosystem started moving toward more batteries-included style development in response.
  • skydhash 2mo ago
    The complaint was micro-dependencies and huge sprawling trees. What was needed was quality dependencies on the level of SDL, ffmpeg, libcurl, where one domain is solved well and the focus is on API stability and good implementation. Not a battery included type of things.
• shimman 2mo ago
  I've still yet to run into any enterprise project using bun in the wild. It really feels like something entirely contained within startups that would choose wildly inappropriate tech like next.js. Add in the influencer dev brainrot culture and you get these VC backed efforts to privatized publicly important projects (node.js) under control of quite evil people that have zero record of helping others.
• bcye 2mo ago
  I always thought Bun's approach was to be the JS runtime with a large well-designed std-library, this isn't really new. It's nice to have a choice of a more or less-featured runtime depending on the project's requirements -- if size and complexity are an issue, there's a variety to choose from.
• pettijohn 2mo ago
  I for one prefer batteries-included. Decision fatigue for every cobbled together package takes its toll. Having a single, trustworthy, good-enough solution for so many things makes my life easier.
• ryankuykendall 2mo ago
  “ Why would I want everything reimplemented in this massive binary? “ This isn’t about what individual developers would want but what is most beneficial to Anthropic and claude code. They are likely using Bun as a vehicle for standardizing and enriching local user environments in order to address common tasks that claude generally writes bespoke scripts to accomplish.
• panzi 2mo ago
  Out of the things you mentioned I think the following make totally sense to be included in a language runtime like this: JavaScript runtime (obviously), package manager, test runner for unit tests, bundler, JSX, SQLite bindings, formatter, linter, YAML and TOML parsers. Maaaaybe even a Markdown parser and HTML5 parser. Definitely JSON, CSV and XML parsers. I.e. similar to Python. Though Python is a bit of an incoherent mess. If you have all these you need them to be coherent.
• ralusek 2mo ago
  Things like headless browsers are really annoying to include in FaaS environments, but are super useful. If they're in the runtime binary already, that'd be great.
• barnabee 2mo ago
  Ideally everything not built specifically for any given project is part of the OS or some other battle tested, supported system package. For example, I might well choose to reimplement eg a subset of TOML parsing to avoid the dependency risk. I don’t write JavaScript/TypeScript, but if I did, I’d find Bun’s “batteries included” approach compelling, at least to the extent I decide I can trust Bun, after due diligence
• tredre3 2mo ago
  > It's weird their promotional video repeats "you can do <million things> without installing dependencies" In 1.3 you couldn't even use the repl without downloading dependencies. In 1.4 it is now finally built-in, hurray! That alone is why I'm going to install 1.4. Finally a truly portable typescript repl.
• jamesnorden 2mo ago
  If you want Node just use Node, complaining that something else is not Node is crazy.
• dataplumb3r 2mo ago
  Some of these are situational, but many are expectations of a modern platform. Take Python - the standard lib now has things like a toml parser, sqlite client. And while I avoid the entire JS ecosystem as much as possible, a simple search to find a good Postgres client was not elucidating. https://wiki.postgresql.org/wiki/List_of_drivers https://wiki.postgresql.org/wiki/List_of_drivers two options - with node-postgres / pg seeming to be the most supported or postgres.js which has more abstractions but is less active Contrast that to the question for Java, where it's clear the official JDBC driver is the best option.
• vrighter 2mo ago
  it's because they were asking claude what features they should implement next. So we got everything and the kitchen sink