6 ms·
Bun 0.3
- leejoramo 4y agoWill be watching how the new nodejs compatibility works out. Maybe in a few months I will have the time to test porting a few expresses applications.
- deleted 4y ago[deleted]
- progx 4y agoI 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.
- philippz 4y agoWould love to switch, but we're still missing the NodeJS TLS API
- Jarred 4y agoThe “tls” module is on our list of node core modules to implement, somewhere near the top
- christophilus 4y agoNot that I want to cause scope creep, but it would be amazing to have something like the certmagic library (the Caddy team’s automatic TLS Go library) without having to reach for a 3rd party.
- Jarred 4y agoI would love for us to do this builtin to Bun.serve() No idea about timeline but something we are thinking about
- qwerty3344 4y agowhat are the other core modules near the top?
- xchkr1337 4y agoI don't see any reason to use this over Deno.
- deleted 4y ago[deleted]
- philippz 4y agohttps://medium.com/deno-the-complete-reference/hello-world-performance-bun-vs-deno-dbfff38c9102 https://medium.com/deno-the-complete-reference/hello-world-p...
- deleted 4y ago[deleted]
- CharlesW 4y agoFWIW this similarly-trivial "Hello world" benchmark shows Bun's lead at ~25% faster than Deno at the moment, which doesn't seem insurmountable. https://github.com/denosaurs/bench https://github.com/denosaurs/bench
- panzerboiler 4y agoThose benchmarks are measuring the speed of the tool used to run the benchmark, not the http servers. Take them with a pack of salt.
- CharlesW 4y ago"Take all benchmarks with a grain of salt" is my middle name, but the benchmark I linked to is an open source project with 17 contributors. In contrast, I'm not seeing any source referenced by the Medium benchmark article I responded to.
- tested23 4y agoDoesnt deno bring a bunch of security improvements to the table?
- ryanto 4y agoLooks awesome. Gotta say, the built in testing, websockets, and file system router are exciting to see. Is anyone using bun in production? Would love to hear your experience.
- christophilus 4y agoI’m using it for some internal business apps. I quite like it. It’s early days, so I definitely miss some things— like a REPL. I gotta say, though, it’s a good feeling when you deploy a zero-dependency TypeScript application complete with tests.
- helsontaveras18 4y agoThis sounds like a dream come true. Are you running into any issues with existing dependencies or this a new application?
- Jarred 4y agoI work on Bun happy to answer any questions or feedback
- christophilus 4y agoI’ve built a few utility apps at work. I absolutely love it. I hijacked your jsx support so that I had built in server-side templating without having to pull in any external libraries (e.g. React). The process of building my own TSX bindings was pretty trivial, but did feel like a hack (I created a React package.json entry that was a file path to my local source folder). Is that scenario doable with less hackery?
- Jarred 4y agoYou can set “jsxImportSource” in tsconfig.json or jsconfig.json to point to a different jsx package There is also a setting in bunfig.toml but it appears we haven’t documented it yet
- damsta 4y agoWhat are the things you are hoping to release in Bun v0.4?
- johnnypangs 4y agoBun seems really cool! I had a question about this part: > Bun now works in more Linux environments, including Amazon Linux 2 and builds for Vercel and Cloudflare Pages. (Previously, you might have seen errors like: "version 'GLIBC_2.29' not found") How would building for Vercel and CF pages work? Like normal but installing the relevant build tools using bun?
- dstaley 4y agoAdditionally, I'd love to see the PR where this change was implemented. I've been trying to convince Zola, a static site generator written in Rust, to support older versions of GLIBC.
- adam_arthur 4y agoI'm surprised JSC doesn't get more press. Lots of news/articles about V8, but seems JSC has eclipsed it on perf by some metrics. Overall though, Bun honestly looks like it has a shot to supplant Node if npm package compatibility reaches a sufficient level. Or at least encourage Node to work much harder on perf. Deno feels a bit too esoteric/theoretical in its approach, vs Bun which looks to be much more focused on ease of use
- packetlost 4y agoDoes anyone know if there's a TypeScript runtime that compiles/runs TypeScript directly instead of going through the JS/ECMAScript intermediary?
- MrJohz 4y agoThere's AssemblyScript, which is designed to be Typescript-esque, and compiles to webassembly, but apart from that, there's not much. The thing is that there's not much value in a Typescript runtime. The semantics of Typescript are fundamentally the semantics of Javascript, but with labels attached to each variable giving a rough hint as to what the type might be. For static analysis, that's really useful - rough hints are mostly good enough for human things like editor hints and typechecking that are allowed to be incorrect - but when it comes to executing the code, the type hints don't actually have that much value. It's very easy for them to be incorrect ("A as B" is a valid Typescript construct that just asserts that a variable is a type without needing to check that it's actually the case), and so the runtime engine can only ever use them as a hint. But with the JIT engines that must runtimes use, the interpreter already has a pretty good idea what the type is going to be, because it's already executed the code and inspected the runtime variable. So you don't get a huge amount of practical value by using the type hints. And if the type hints aren't useful for the runtime, then there's no real reason to enforce that they be present. A Typescript runtime that ignores types is just a Javascript runtime with a more pedantic syntax, and if you're going to that effort, you may as well support both.
- nicky0 4y agoNot now but there is work going on in the JS standardisation process that will mean valid typescript is interpreted as valid JavaScript. (Basically run it and ignore the type annotations)