Does it work with Prisma yet? I’m kinda waitjng for that to switch everything over.
Bun 0.6
161–170 of 243 posts
Re: Bun 0.6
#162Earlier quoted context omitted.
Yeah, I used Deno to build a simple URL switch case utility in late 2021 to handle sending different URLs to different browsers, and that was ~56MB compiled at the time. I don't know if it's changed in the base size since then, but if bun is resulting in 90MB binaries (as reported here), then Deno may yield a significant reduction in size (if it hasn't gotten much worse in that time).
I'm sure it'll get better (I'm sure both will); there's probably a lot of potential optimization to be done, dropping unused parts of the standard library and platform APIs and such (the way Deno loads most of the standard library as remote modules might actually be helping it here at the beginning), and Jarred is a stickler for hyper-optimization
Interestingly, I'm sure a lot of people that want to compile to a binary would love an option that had trade-offs for the size even if it greatly hurt performance. For example, my case was ~100 lines of code not including the parseArgs and parseIni modules I used, and is meant to be run with an argument and then it exits with an action. If I could have chosen a dead simple and dumb JS interpreter without JIT but that was It might even have resulted in a faster runtime as well, since it wouldn't need to load nearly as much of the binary into memory, and also wouldn't need to initialize as many special purpose data structures to deal with advanced performance cases.
Re: Bun 0.6
#163Earlier quoted context omitted.
Browsers weren't written in a day. Technically speaking, Mozilla Firefox is a ship of Theseus going back to the release of Netscape in 1994. Did browser and internet infrastructure developers in the early 90s understand that these things would become rich application platforms? Looking at the history of HTTP, it's clear that they expected some concept of "application" to be delivered through the browser. While there'…
Was Google Maps the first JS-heavy app? That's a TIL for me..
According to Crockford, they were working with very JS-heavy apps in 2000[1]. No idea how mainstream that specific app, or technique, was.
[1]: https://corecursive.com/json-vs-xml-douglas-crockford/#the-p...
Re: Bun 0.6
#164Re: Bun 0.6
#165Earlier quoted context omitted.
Have you tried using alpine based images instead of debian/ubuntu/others? I know it's not always possible especially because of musl but for most things it works fine and is tiny.
It becomes a political issue at this point w/ battling the ops team. I have more important battles.
If it's a battle by all means avoid it. But it's weird that your ops team would care about the image type. The whole point of containers is that they don't need to care.
Re: Bun 0.6
#166Earlier quoted context omitted.
Revenue/monetization model? Given that Oven has taken $7m in VC funding, how do you plan to monetize Bun, etc?
The plan is JavaScript edge hosting focused on fast cold starts and being extremely inexpensive, using lots of custom infrastructure
Hi Jarred. Super excited to see bun coming along. I've been loving it ever since the invitation release. As I watch from the sidelines, I've been mesmerized by your productivity. I have a couple questions, if you don't mind.
The first – I'm curious about Vite in bun. You have a bundler, you have a typescript transpiler, and you have a HTTP server. Does this mean eventually Vite (or at least some of it's functionality) will be "native" inside of bun, or will Vite continue to be it's own thing? (eg. Vite plugins for )
The second is more related to Oven. I'm curious what the value proposition of Oven's edge is, compared to other serverless providers? It's hard to imagine the runtime being the main selling point, with it's node compatibility and packages like hono being able to run everywhere. What will set Oven's edge hosting apart from the pack?
Re: Bun 0.6
#167Earlier quoted context omitted.
Bun might be a cool project, but them building on an immature language like Zig makes me wonder where their priorities are.
It wouldn't exist any other way, the story is that it was built with speed as a priority, and Zig was chosen for the performance optimizations it enables.
There are several other languages that could achieve the same speed and performance optimizations. To be clear, I hope to see Zig succeed and I'd like to learn it one day. It reminds me of the video game engine question, only in this case it would be: do you want to build a product, or do you want to build something with Zig? I imagine the creators of Bun answered "we want to use Zig" as their first priority, and that's great, I hope they have fun.
Re: Bun 0.6
#168`bun` is currently my favorite "just works out of the box" utility for running Typescript programs. I've tried a couple and struggled with configuration and, on top of it all, bun is simply faster. So, if you want to write a bunch of `.ts` files and point something at them, I really recommend `bun` (and, frankly, why would you write `.js` in 2023? Probably because you've not tried bun. Edit: I don't care about bundle…
> and, frankly, why would you write `.js` in 2023?
It's surprisingly convenient for munging around random json files or calling random apis that return json (or for dealing with an interaction between the two), especially now that fetch ships with node.
Re: Bun 0.6
#169Tangential, but, this has to be one of the fastest websites I've used recently. How is it possible they get such fast loading of static content? It's basically instantaneous, specially with JavaScript disabled. edit: Oh well, after navigating to some pages on the blog I see that everything was already on browser cache, so that's why it was so fast. Reminds me I need to overwrite Netlify's cache-control on my website,…
From experience, static websites on https://pages.dev are blazing fast (and free); ex: pagespeed result for a static webpage I host: https://archive.is/PkZbO Netifly was equally fast (not free).
Cloudflare is indeed absurdly fast. I haven't been impressed with Netlify's speed, although I am using the free plan (don't think it makes sense to upgrade if I'm already not super happy with performance).
When you say paid Netlify is as fast as Cloudflare do you mean the Pro plan or the Enterprise plan? AFAIK the enterprise plans run on a different network, with more distributed servers, although I could be wrong.
It seems at least part of the noticed difference in speed has to do with my region, as pagespeed insights gives me sub-second FCP and LCP on my Netlify website [0], which feels a bit better than what I get at home (with 500mbps fiber). It's possible my ISP is at fault, but I'm not sure how I could diagnose this much better.
Re: Bun 0.6
#170Earlier quoted context omitted.
Browsers weren't written in a day. Technically speaking, Mozilla Firefox is a ship of Theseus going back to the release of Netscape in 1994. Did browser and internet infrastructure developers in the early 90s understand that these things would become rich application platforms? Looking at the history of HTTP, it's clear that they expected some concept of "application" to be delivered through the browser. While there'…
Was Google Maps the first JS-heavy app? That's a TIL for me..
No, certainly not the first in aggregate to use JS heavily. Actually, the browser-based Outlook client was the first to have all the parts that we would now consider to be essential for JS Single Page Apps (because Microsoft has to invent AJAX first). But Google Maps was definitely the first to have a major impact and start changing the public perception of what could be done with browser-based apps.
I consider Google Maps to be the first well-adopted, no-traditional-alternative app to be what we recognize today as a JS SPA. Gmail had a pure HTTP mode, and otherwise was not interesting to people who were happy with their current email. Outlook wasn't really used by that many people, not at the scale that Google Maps was Google Maps has broad appeal and was significantly better because of it's SPA-ness to change how people thought about browser-based apps.