[HN Gopher] Bun 0.6
___________________________________________________________________
Bun 0.6
Author : tommasoamici
Score : 260 points
Date : 2023-05-16 18:04 UTC (4 hours ago)
(HTM) web link (bun.sh)
(TXT) w3m dump (bun.sh)
| schemescape wrote:
| How big are the bundles (edit: I meant self-contained
| executables) and do they depend on glibc?
|
| Edit: just saw a comment from the author indicating glibc is
| required.
| lionkor wrote:
| Doing it without glibc is not practical
| silverwind wrote:
| It's just DNS isn't it? Many apps don't even need DNS, so
| there should at least be an option to build fully static
| binaries.
| AndyKelley wrote:
| why?
| fluente wrote:
| It would be helpful to see how Bun's minifier compares to the
| others with popular libraries:
|
| https://github.com/privatenumber/minification-benchmarks
| dheera wrote:
| Why are we still minifying JavaScript? Is it only for
| obfuscation?
|
| State-of-the-art HTTP servers already do a pretty damn good job
| gzipping stuff on the fly, do we need this garbage?
|
| If it is for obfuscation, fine, can we just call it that?
| 10000truths wrote:
| You can shrink transmitted sizes even further by using
| minification on top of transport compression. That nets me ~25%
| reduction in size compared to compression without minification,
| in practice, and those kinds of gains add up, especially at the
| tail end of page load times.
| tracker1 wrote:
| Not to mention, you can get better compression with some pre-
| compression levels that are hard to match with the best on
| the fly, often getting another 10% or more on size. It all
| adds up.
|
| There are some Steve Souders books on optimization that are
| pretty good and still pretty relevant.
| nicetrybob wrote:
| We touch on this in the docs [0]. TLDR, bundlers are still
| necessary (for now) to reduce the number of roundtrip requests
| required before page load (ideally to 1), and in more complex
| apps to avoid overwhelming the browser with parallel requests.
| Even HTTP2 can't handle 100k parallel requests for a big app
| with a bloated node_modules.
|
| [0] https://bun.sh/docs/cli/build#why-bundle
| djbusby wrote:
| And pack a bunch of assets into one larger asset, reduce the
| HTTP request count and maybe pre-gzip to save a few clock
| cycles
| LispSporks22 wrote:
| I thought I read in the Rails docs somewhere that HTTP2 and
| import maps rescued us from bundling JS
| dheera wrote:
| Maybe all of this should be an optional feature of HTTP
| servers and browsers with graceful fallback? NGINX could have
| a module that understands JavaScript and CSS and bundles and
| caches things on the fly, enabled optionally.
|
| It would greatly simplify deployment to have the source and
| deployed code be identical. Obfuscation aside, given JS is an
| interpreted language, there is no reason to not use it for
| what it is. We've turned deploying JS into the same level of
| complexity as deploying C++ by adding building and packaging
| steps. Interpreted languages should never need build steps,
| and deployment should be no more than a simple rsync.
| doodlesdev wrote:
| Tangential, 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, even though it's already very fast to load
| (Netlify sets max-age=0, must-revalidate by default).
| ignoramous wrote:
| 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).
| Minor49er wrote:
| Its use of the Cloudflare cache seems to be a part of it
| doodlesdev wrote:
| Indeed, http headers indicate that the asset policy for the
| HTML is: cache-control: public, max-age=0,
| must-revalidate
|
| A few things I notice: - It uses Cloudflare
| cache (as you pointed out). - All CSS is in the HTML
| file, so only one request is needed to display the page.
| - The compressed webpage is reasonably lean considering it
| has all CSS in the same file and uses Tailwind.
| tracker1 wrote:
| I've been playing with static content generation with Deno+Lume
| and deploying to Cloudflare pages... crazy good loads.
| hu3 wrote:
| > Standalone executables. You can now create standalone
| executables with bun build.
|
| > bun build --compile ./foo.ts
|
| > This lets you distribute your app as a single executable file,
| without requiring users to install Bun.
|
| > ./foo
|
| This is big! Part of Go's popularity is due to how easy it is to
| produce self-contained executables.
|
| And it seems to support amd64 and arm according too:
| https://twitter.com/jarredsumner/status/1657964313888575489
| henry_viii wrote:
| Doesn't Deno already let us do this?
| chrisco255 wrote:
| Bun is intended to be a drop in replacement for Node.js, with
| Node.js compatible APIs. Deno chose to go a different route
| with the design of the runtime, encouraging more modern web-
| native paradigms.
| hiccuphippo wrote:
| Deno changed their opinion recently and will offer Node.js
| compatibility. Apparently it wasn't such a good idea to not
| be compatible on purpose.
| tracker1 wrote:
| I actually have mixed feelings on this one... since I
| think Deno's approach has been generally cleaner, but
| also recognize the scale of what's in NPM.
| chrisco255 wrote:
| Didn't realize that, thank you. I can empathize with
| Deno's desire to take backend JS in a more web-native
| direction.
| ignoramous wrote:
| Yes, that it does. _Bun_ is mostly towing Deno with Zig +
| JSCore (and per some microbenchmarks, faster than both Node
| and Deno).
| bdg wrote:
| Is this like a phar file?
| blowski wrote:
| Phar files still need the PHP runtime installed to run them.
| These files have the JS runtime embedded in them.
| pier25 wrote:
| Apparently a hello world is like 90MB.
|
| https://twitter.com/jarredsumner/status/1657765876085690368
| datavirtue wrote:
| That small!?
| leeoniya wrote:
| ICU :(
|
| https://github.com/oven-sh/bun/issues/2541
|
| https://twitter.com/jarredsumner/status/1616597667408404481
| edflsafoiewq wrote:
| QuickJS has a custom unicode library for this reason.
| mananaysiempre wrote:
| It's slow as molasses in some parts though.
| (Deliberately, it's a trade-off.)
|
| The _Unicode_ part of ICU shouldn't be that large,
| however (on the order of hundreds of kilobytes), it's the
| locale data that's big[1]. Does Bun implement ECMA-402
| internationalization? Even without locales, one of the
| largest parts of ICU data is normalization and casing
| tables, which I think bare ECMAScript does not require.
| (It does mean bare ECMAScript cannot adequately process
| Unicode text, but meh, you get what you pay for.)
|
| [1] https://unicode-
| org.github.io/icu/userguide/icu_data/buildto...
| sjrd wrote:
| Bare ECMAScript does require normalization [1] and case
| conversions (for the root locale only) [2].
|
| [1] https://developer.mozilla.org/en-
| US/docs/Web/JavaScript/Refe...
|
| [2] https://developer.mozilla.org/en-
| US/docs/Web/JavaScript/Refe...
| mananaysiempre wrote:
| Ah, I see, String.prototype.normalize() is in ES6. I
| remembered that Duktape (which has its own, even slower
| Unicode library) can't do it[1], but then it doesn't
| target ES6 compatibility either.
|
| [1] https://github.com/svaarala/duktape/issues/1718
| pseudosavant wrote:
| Is 90MB really that big when compared against the other types
| of binaries that would get deployed: containers and VM
| images? How big is the platform (k8s, docker, etc) you need
| installed to run your app? Probably more than 90MB.
| keyle wrote:
| yeah 90MB for a hello world is big.
|
| Approximately 2,700 times bigger than it could be.
| pier25 wrote:
| Depends. Doesn't seem much for a server but if you want to
| distribute an executable to your users then 90MB seems
| huge. IIRC a hello world Go binary is like 2MB.
| paulddraper wrote:
| IIRC the latest Linux Node.js binary is over 70MB.
|
| Though Bun doesn't use Node.js I believe, there's a reference
|
| (At least it's not JVM Hotspot...)
| U1F984 wrote:
| A Java Runtime for Hello world is just 32 MB:
| https://adoptium.net/blog/2021/10/jlink-to-produce-own-
| runti...
| bryancoxwell wrote:
| Well, I do appreciate the transparency to be honest.
| VWWHFSfQ wrote:
| I'm curious why that would be so big. Even my python3.10
| binary + /usr/lib/python3.10 is only 30MB
| matlin wrote:
| It bundles an entire JS engine with it. I think JSC in
| Bun's case. V8 for Deno and Node.
| ricardobeat wrote:
| The engine is not the largest part of it. just-js, which
| is pretty close to barebones V8, sits at ~20MB. JSC is
| supposed to be about 4MB, Hermes is 2-3MB. The largest
| parts I think are ICU and the built-in libraries.
| silisili wrote:
| It's why I dove into Go.
|
| This definitely took me from the 'eh, kinda cool project' to 'I
| cant wait to try this out immediately' camp.
|
| The binaries are pretty huge, hoping they can bring that down
| in time.
| TechBro8615 wrote:
| You've been able to do this with Deno for a long time (and
| Node too, as of recently). The downside is it bundles all of
| V8 so a "hello world" binary ends up being at least 70mb.
| winrid wrote:
| I've been desensitized by my world of 500mb docker
| containers.
| claytongulick wrote:
| Yeah, this is honestly one of the things that turns me
| off of containers in general.
|
| Like, the whole point was to effectively use linux kernel
| namespaces with cgroups in an intelligent way to give VM-
| like isolation, but non-emulated performance - and
| supposedly not having to deal with image size bloat from
| the OS like you get in VMs.
|
| What we got was an unholy mashup of difficult to debug,
| bloated images and ridiculously complex deployment and
| maintenance mechanisms like kubernetes.
|
| I just do old school /home/app_name deployments with
| systemd unit files, and user-level permissions.
|
| Oh, and it's webscale[1].
|
| [1] https://www.youtube.com/watch?v=b2F-DItXtZs
| tracker1 wrote:
| It doesn't _HAVE_ to be that bulky or complex. You have a
| lighter space like Dokku or just direct scripted
| deployments pretty easily. As to the size, you can use
| debian-slim or alpine as a base for smaller options.
| There 's also bare containers, or close to bare for some
| languages and platforms as well (go in particular).
| thewataccount wrote:
| 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.
| verdverm wrote:
| If everyone is on the same base image, then you aren't
| really dealing with 500mb images, but much smaller layers
| on top.
| winrid wrote:
| It becomes a political issue at this point w/ battling
| the ops team. I have more important battles.
| thewataccount wrote:
| Yeah that's fair, if it works it works.
|
| Depending on your setup it doesn't really matter anyway.
| beanjuiceII wrote:
| how about ubuntu chisel
| nine_k wrote:
| Docker containers are actually smaller if they share
| layers with other containers in the system. A ton of
| containers based on the same image reaps many
| deduplication benefits.
| tracker1 wrote:
| Yeah, I notice many/most images are based on a recent
| Debian base if they aren't on Alpine or closer to bare
| images. I don't consider even Alpine as a base too bad
| for a lot of apps.
| afavour wrote:
| > The binaries are pretty huge, hoping they can bring that
| down in time.
|
| I'm surprised the numbers are as high as they are and hope
| they can reduce them... but they'll never get down to the
| kind of numbers Go and Rust get to because Bun depends on
| JavaScriptCore, which isn't small, and unless they're doing
| some truly insane optimizations they're not going to be able
| to reduce its size.
|
| FWIW QuickJS is a tiny JS runtime by Fabrice Ballard... that
| also supports creation of standalone executables:
| https://bellard.org/quickjs/quickjs.html#Executable-
| generati... though its runtime speed is considerably worse
| than JSC or V8.
| vlovich123 wrote:
| For 90% of things this will be used for, it's more than
| enough so it might be a good default unless you enable a
| `-Ojit` flag when building more complex applications where
| the JIT will be a benefit. In fact, startup times might
| even be faster.
|
| The challenge of course is supporting two JS runtimes
| within the same codebase.
| afavour wrote:
| Yeah I suspect the weird little differences between
| runtimes (e.g. what language features they do and do not
| support) would lead you down a path of a thousand cuts.
|
| It still feels like a graceful idea, though.
| whimsicalism wrote:
| JSC is ridiculously fast, this is what makes bun great
| afavour wrote:
| It really depends on what you're doing. If 95% of your
| code is file or network I/O then it's really not going to
| make the slightest difference whether you're running JSC,
| V8 or QuickJS. If your code is enormously complex and
| benefits from JIT then yes, you're going to really feel
| that downgrade.
| mixedCase wrote:
| The difference in real world performance between web
| servers written in things like Python or Ruby to those
| written in Go, C# or even lower-level languages like Rust
| would indicate that's an over-estimation of how much IO
| dominates total runtime, even if it is by far the slowest
| part.
| latchkey wrote:
| `-trimpath -s -w` makes binary size smaller.
|
| `xz -z -9e` is good to compress it for distribution.
| inglor wrote:
| Node supports this too (experimentally)
| https://nodejs.org/api/single-executable-applications.html
| MuffinFlavored wrote:
| > Part of Go's popularity is due to how easy it is to produce
| self-contained executables.
|
| Rust too... :D
| winrid wrote:
| Nah, rust still depends on libc at runtime which is a pain.
| Go doesn't have this problem afaik as it has its own stdlib
| and runtime.
| d0100 wrote:
| Indeed, I built Supabase's edge-runtime and sent the binary
| to another pc with a earlier Ubuntu version only to
| discover it wont work
|
| I went on a wild goose chase to build static Rust but deno
| can't target musl yet and the issue is a few years old
| mirashii wrote:
| > Nah, rust still depends on libc at runtime which is a
| pain.
|
| It does in general, though I don't really think this is a
| big pain or blocker in the general case, there are very
| version requirements around libc.
|
| > Go doesn't have this problem afaik as it has its own
| stdlib and runtime.
|
| That's also true, but it's not really a pure win. Choosing
| not to use a battletested libc has led to a variety of
| subtle and difficult to diagnose bugs over the years, e.g.
| https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/
| arp242 wrote:
| You can statically link libc in Rust too; at least, if teh
| interwebz is correct (not a Rust expert); you just need
| some extra flags.
|
| This is actually not that different from Go in practice;
| many Go binaries are linked to libc: it happens as soon as
| you or a dependency imports the very commonly used "net"
| package unless you specifically set CGO_ENABLED=0,
| -tags=netgo, or use -extldflags=-static.
| Conscat wrote:
| Statically linking libC is problematic in various ways. I
| really appreciate that Zig has its own runtime that is
| designed specifically for this use case.
| diego_sandoval wrote:
| What bothers me is that even when that capability exists,
| most of the Rust open source programs that I've tried don't
| distribute binaries, and still ask you to install cargo and
| compile the program from source.
| [deleted]
| VWWHFSfQ wrote:
| My experience is the opposite. Nearly every Rust tool I've
| used offers static binaries for various platforms.
| brundolf wrote:
| Fwiw, Deno can do this too:
| https://deno.com/manual@v1.33.3/tools/compiler
| kbenson wrote:
| 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).
| brundolf wrote:
| 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
| petetnt wrote:
| And NodeJS too https://nodejs.org/api/single-executable-
| applications.html
| vdfs wrote:
| There is also https://github.com/vercel/pkg
| RedShift1 wrote:
| Experimental, so probably at least 5 years before it's
| considered "stable"
| g_delgado14 wrote:
| As if bun isn't experimental
| brundolf wrote:
| Node moves pretty slow these days, I wouldn't be
| surprised if Bun's version gets stabilized before Node's
| unilynx wrote:
| import.meta.main (whether the current file is the 'main' or just
| being required) looks interesting and like something I have
| wanted in the past, but not sure if it would actually be a good
| idea.
|
| was it ever offered for standardisation?
| Jarred wrote:
| There is no standard, import.meta is host-defined:
| 13.3.12.1.1 HostGetImportMetaProperties ( moduleRecord )
| The host-defined abstract operation HostGetImportMetaProperties
| takes argument moduleRecord (a Module Record) and returns a
| List of Records with fields [[Key]] (a property key) and
| [[Value]] (an ECMAScript language value). It allows hosts to
| provide property keys and values for the object returned from
| import.meta.
|
| https://tc39.es/ecma262/#sec-hostgetimportmetaproperties
| captainmarble wrote:
| Any plan on adding something likr Deno KV in Bun?
| Jarred wrote:
| I work on Bun. Happy to answer any questions
|
| also: there is a bug in `bun build --compile` I am currently
| working on fixing. Expect a v0.6.1 in a bit
| yobuko wrote:
| First, thank you for all of your hard efforts.
|
| I have seen some desire and works expressed towards using Bun
| with Electron or Electron alternatives; this interests me
| greatly. Do you have any plans or aspirations to make any
| strong push in this direction?
| sroussey wrote:
| This would be awesome. Use bun as the main process (replacing
| node) and have the front end use the system webview. The
| system webviews are good these days.
| samwillis wrote:
| > I work on Bun
|
| Understatement.
| intelVISA wrote:
| Local hacker seasons v8 Bun with io_urings; woulda been a
| cool proj if the Js runtime was organic like Bellard's qjs
|
| Still, in the native-starved web space this sorta meal will
| be considered haute cuisine.
| drschwabe wrote:
| Not a question, cause you already mention this here, but just
| wanted to give you extra props for supporting CommonJS out of
| the box; keep up the great work.
|
| https://twitter.com/jarredsumner/status/1475238259127058433?...
|
| have been doing this (using ES and CommonJS modules in the same
| file) in clientside code via Browserify or Rollup ever since
| ESM got popular but it's a bit more nuanced and annoying to do
| in NodeJS
| Signez wrote:
| Really impressed to see that bun is now faster than esbuild,
| that was in my mind one of the fastest bundler/minifier in
| town.
|
| How did you achieve that? Are there some shortcuts you took, or
| some feature you deemed not in scope (yet)?
| conradev wrote:
| This is a fantastic talk on some of the optimizations that
| Zig makes easy to implement: https://vimeo.com/649009599
|
| Bun is written in Zig, but it takes the same approach that
| esbuild took to make things fast: a linear, synchronous
| pipeline fitting as much as possible in the CPU cache with as
| little allocation and other overhead as possible. Zig has
| more knobs to turn than Go.
|
| Bun goes one step further and does a great job of offloading
| work to the kernel when possible, too (i.e. the large file
| I/O improvement with the Linux kernel)
| f311a wrote:
| Zig is cool, but Bun heavily relies on JSC which is written
| in C++
| conradev wrote:
| JSC is a multi-tier JIT with the last stage ultimately
| being LLVM, so if you want to be pedantic, Bun relies on
| LLVM's optimizer which is written in C++.
|
| The transpiling itself is written in Zig, which is the
| part that has the performance improvement. If Bun relied
| on JavaScript and JSC for the heavy lifting, it would be
| no faster than the other JS bundlers.
|
| edit: no longer LLVM:
| https://webkit.org/blog/5852/introducing-the-b3-jit-
| compiler...
| brundolf wrote:
| But bundling doesn't
| eatonphil wrote:
| I really hate to talk about software based on the language
| they're written in and I don't mean to imply one language is
| better or worse but the upper bound of performance on Zig is
| likely easier to reach and likely higher than the upper bound
| of performance in Go. Though it may depend on the workload.
| (esbuild being written in Go.)
| sroussey wrote:
| Bun is awesome! Need debug support and console fixes. Please!!!
| tazeg95 wrote:
| Hello, it seems very interesting. I am using esbuild to build
| my apps and it has a developper live server. How would you
| compare bun to esbuild ? what can one do that the other can't ?
| do you have a compare page ?
| networked wrote:
| 1. It seems the _Bun.file_ API (https://bun.sh/docs/api/file-
| io) doesn't provide a way to distinguish between a zero-size
| file and a file that doesn't exist. Is this right? If it is, it
| would be nice to have one. It doesn't have to interfere with
| the lazy loading.
|
| 2. I'd be glad to eventually see Bun work on Free/Net/OpenBSD.
| (I know there is a GitHub issue for FreeBSD.) My question is
| about something related: cross-compiling with Zig. Go projects
| tend to provide BSD binaries more often than others because
| they get cross-compilation "for free" (when they don't use
| Cgo). It must not be as easy when you depend on libc and C++
| code, despite the positive things I've heard about Zig's cross-
| compilation story. Do you cross-compile Bun? If you do, how has
| your experience been?
| kitd wrote:
| Congrats on the release!
|
| How standalone are the standalone executables produced by `bun
| build`? Is a libc or equivalent expected to be present?
| Jarred wrote:
| Bun does need glibc, but older glibc versions should work
| okay because of this: https://github.com/oven-
| sh/bun/blob/78229da76048e72aa4d92516...
|
| We haven't implemented polyfills for everything yet though,
| like Bun uses posix_spawn and doesn't have an exec + fork
| fallback
|
| Bun's dependencies otherwise are statically linked
| 10000truths wrote:
| Is there any plan to allow for statically linking with musl
| to get completely shared-lib-dependency-free executables?
| codethief wrote:
| > Bun does need glibc
|
| Wait, are we talking about what Bun needs to run or what
| standalone executables produced by bun build need in order
| to run?
| hiccuphippo wrote:
| Both, the executables produced by bun are the bun binary
| concatenated to your script at the end. Try building a
| hello world and run `tail -c200 hello | xxd` to see your
| script at the end of the file.
| raphaelrk wrote:
| Congrats on the launch!!
|
| Any plans on adding "in-memory" / "virtual" file support to
| Bun.build? I'd be interested in using it for notebook-style use
| cases
|
| --
|
| Also, ways to do "on-the-fly" "mixed client/server" components
| (ala hyperfiddle/electric) + sandboxing (ala Deno) would be
| extremely exciting
|
| Some projects in this vein -
| https://github.com/jhmaster2000/bun-repl and
| https://www.val.town/
|
| Also, bun macros are very cool -- they let you write code that
| writes over itself with GPT-4. Just mentioning as a thing to
| keep on your radar as you keep pushing the boundaries of what's
| possible in javascript :) making it more lispy and preserving
| eval-ability is great
| pastacacioepepe wrote:
| Is Windows support planned?
| alberth wrote:
| Revenue/monetization model?
|
| Given that Oven has taken $7m in VC funding, how do you plan to
| monetize Bun, etc?
| whimsicalism wrote:
| my understanding was an edge environment similar to CF
| workers
| Jarred wrote:
| The plan is JavaScript edge hosting focused on fast cold
| starts and being extremely inexpensive, using lots of custom
| infrastructure
| HorizonXP wrote:
| California Ave Lockitron crew represent!!
|
| Glad to see you leading this, incredible work and nice to see
| the positive reception.
| zamnos wrote:
| In Palo Alto by the Nuthouse? small Internet
| meekaaku wrote:
| Just wanted to say thank you for starting and leading the one
| of the most exciting projects in js landscape.
| [deleted]
| freddex wrote:
| Looks great! Still eagerly waiting for Windows support: I have a
| specific use case where I need both a bundler and a package
| manager to run on the user's desktop cross-platform, and right
| now that's yarn + esbuild. I'd love to roll this into a single,
| performant solution. It's already being worked on as far as I
| know [1], excited to upgrade to Bun when that's available.
|
| [1] https://github.com/oven-sh/bun/issues/43
| timetraveller26 wrote:
| How does this compare to bite?
| tankenmate wrote:
| I am truly perplexed as someone outside of the Javascript
| ecosystem; why are there so many incompatible bundlers? If you
| look at most compiled languages they have a set ABI / executable
| image format, and you just use a link editor (either compile
| time, run time, or both).
|
| Is it just because most Javascript developers have never learnt
| from any of the lessons that came from decades of compiled
| languages? (compilers, compiler tools, operating system and
| kernel development, etc).
|
| Is there some benefit that Javascript bundlers have that I'm
| unaware of?
|
| Truly curious.
| qbasic_forever wrote:
| Bundling is totally different from linking and building for
| native platforms. Bundling is all about optimizing code to be
| sent over a small pipe--you're combining multiple compilation
| units into one file (so just one web request and lower latency)
| and doing optimizations like tree shaking to send only the code
| that's actually used.
|
| It's a pretty unique use-case that not many other programming
| languages deal with or care about. It's almost as if you are a
| demo scene coder trying to optimize for the absolute smallest
| code possible.
|
| Linking native code doesn't really care about optimizing the
| size of the output and is just just trying to make sure all
| code paths can be called with some kind of code.
| colonwqbang wrote:
| A native compiler also optimises the code. A native static
| linker also tries to omit unused library data and code. It's
| absolutely not the case that native devs don't care about
| code size (we do!)
|
| I guess Javascript uses a slightly unusual executable format,
| text instead of binary. Otherwise, it seems like very much
| the same thing?
| haberman wrote:
| > Linking native code doesn't really care about optimizing
| the size of the output and is just just trying to make sure
| all code paths can be called with some kind of code.
|
| That is not true at all. There are many use cases where
| native code size is very important. Native code toolchains
| often target platforms with extremely limited ROM/RAM. Even
| on big machines, RAM is not free and cache even less so.
|
| Native code linkers will GC unused code sections (`-Wl,--gc-
| sections `), fold identical data to remove duplication (see
| COMDAT). Native code compilers have optimization modes that
| specifically optimize for small code size (`-Os` and the
| like).
| [deleted]
| moron4hire wrote:
| I think it's largely a three-fold problem of the fact that most
| JS apps are still deployed through browsers and not installed,
| the fact that HTTP2 was not the panacea of multi-request happy
| good times it was made out to be, plus the fact that there _is_
| no Application _Binary_ Interface, everything gets deployed as
| source code.
|
| This creates a situation where you need bundlers, whereas other
| languages don't have the concept at all, just to be able to
| minimize download time (and honestly, while we end up making
| rather large apps in comparison to web pages, they're pretty
| small in comparison to other kinds of applications), and then
| bundles are too opaque to share common code between
| applications.
|
| And because there's no chance to benefit across projects from
| sharing, there's no force driving standardization of bundling,
| or adoption of said standard.
| brundolf wrote:
| 1. Compiling/building is an ~optional layer on top of the core
| language/standard (which has become less optional over time)
|
| 2. Running JS outside of the browser is similarly a layer that
| was built before any kind of standard existed for it (which
| still doesn't, really)
|
| The browser standards are the only real standards. Everything
| else (which has turned into a lot) is "standard by
| implementation". Implementations usually try to agree with each
| other, because that's obviously beneficial for everybody, but
| sometimes they make choices to deviate either out of necessity
| or in an attempt to improve the ecosystem
|
| So it's all pretty ad-hoc, but in practice most things are
| mostly compatible most of the time. They orbit the same general
| things, and the orbit has narrowed in the last few years as
| most of the big problems have been solved and the community is
| zeroing in on the agreed solutions (with the caveat of often
| having to maintain legacy compatibility)
|
| Deno takes a stricter philosophy than most, where it prescribes
| a ~good way that everything should be done (which is almost
| entirely based on browser standards which have evolved since
| all this started), even though it runs outside of a browser,
| and requiring the ecosystem to fall in line
|
| Bun on the other hand takes a maximalist approach to
| compatibility; it does its best to make everything from every
| other sub-ecosystem Just Work without any modifications
| ponyous wrote:
| Because there were browsers and no standards. How can you
| expect someone that starts coding on the web to know what pains
| kernel went through decades prior?
| tankenmate wrote:
| But surely the people writing the browser code thought about
| the ecosystem they were creating / trying to create?
| moron4hire wrote:
| 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's certainly a chance at
| least a few of them foresaw the full scope of what that
| would mean (it's not like X11 remoting wasn't a thing), I
| don't think most of the people involved were thinking much
| past 10 years (The Distant Future, the Year 2000).
|
| JavaScript was apocryphally "invented in 10 days", it came
| as an attempt to create competitive advantage, not to
| create a global standard. The first JavaScript came a year
| (1995) after the first Netscape, but the first major JS-
| heavy application didn't come for another 13 years (Google
| Maps, 2008).
| tracker1 wrote:
| There were a lot of JS heavy web applications prior to
| Google Maps. From around the release of IE5 at the end of
| 2000 in particular through the long tenure of IE6. Having
| worked on some JS heavy applications around that time. It
| was also much harder as you had a relatively wide variety
| of browsers and versions. Since people on dialup were far
| less likely to update their browsers regularly (or at all
| beyond what came on an ISP or AOL CD.
|
| Of course, the efforts for larger dev teams,
| optimizations and bundling were far less popular before
| then. Can't tell you how many poorly written sites/apps
| carried who knows how many versions/copies of JQuery for
| example. It was really bad for a while.
|
| Now, at least there are more paying some attention to it.
| There's still some relatively large bundles that are easy
| to get overloaded. I mean as soon as you load any
| charting or graphing library it blows out everything
| else. Of course this is offset between bandwidth and
| compute advancements as well.
|
| There was a popular developer site around 1998-2000 or so
| called 15seconds.com as that was the average point at
| which users would start dropping off from a load. Now
| that's measured at around a second or two.
| biorach wrote:
| nope
|
| well.... not for a surprisingly long time
| ShadowBanThis01 wrote:
| Is WHAT? The title should tell us what the post is about. Why do
| we have to keep bringing this up? A title like this is a great
| way to miss out on a lot of views and reduce the usefulness of
| your post.
|
| Let the downvoting of this simple observation begin.
| [deleted]
| dimgl wrote:
| I've been pretty jaded by Node.js lately, especially with all of
| the ESM and TypeScript stuff. This led me to try using Deno but
| Deno was missing the mark in a lot of ways.
|
| Is Bun in a state where I can start thinking about replacing my
| Node.js production toolchains with it?
| ojosilva wrote:
| Nope. I wouldn't. Not for production.
|
| * Bun is not stable yet (0.6.0)
|
| * Zig, the language Bun is built upon is not stable either
| (0.11.0)
|
| Nothing against these awesome projects, I'm all in for a
| streamlined toolchain (TypeScript, bundling, binary
| generation...) and other excellent goals driving the Deno and
| Bun teams.
|
| But...
|
| * Node.js is a powerful piece of software, it's stable and full
| of battle-tested buttons and knobs
|
| * NPM and Bun/Deno are not real friends at the moment, just
| acquaintances
|
| * Take benchmarks with a pinch of salt. Real-world app
| performance depends on a well-greased system, not a particular
| 60,000 req/s react render benchmark. Remember the adage: your
| app will as fast as your slowest component.
|
| On a side note, lately I've been extending Node.js with Rust +
| N-API (ie. napi-rs or neon) and it opens up excellent
| possibilities.
|
| https://napi.rs/ https://neon-bindings.com/
| tracker1 wrote:
| I've been pretty happy with Deno... mostly in personal use...
| still some rough bits in terms of Node compatibility but pretty
| good in general.
| brundolf wrote:
| Anybody using Bun in production yet? What's your experience been
| like?
___________________________________________________________________
(page generated 2023-05-16 23:00 UTC)