19 replies

1. Zach Leatherman 2 min later

   (HT @beep @eric)

   1. Private reply 27 min later
      1. Private reply 40 min later
2. oguching 23 min later

   @zachleat This is my exact phone model.

3. nrk 32 min later

   @zachleat developers and software publishers need to realize that everyone don't have high end, multicore, 5nm cpu with 32gb RAM.

   This thing -> https://upstash.com/ for example consumes 50mb heap on startup, for displaying a "static" landing page 😭😭😭 (I believe a vast amount of this insane memory consumption is caused by telemetry, session replay and other sneaky stuffs that companies shouldn't do)

   1. nrk 37 min later

      @zachleat not entirely related to the article, but I believe, developer tools should also focus on reducing size and compute overhead.

      Going by https://www.11ty.dev/docs/performance/ , 11ty have like 34mb of node_module while gatsby (biggest piece of horseshit I've ever used 🤮🤮) have half a gb for the same.

      1. Alan Norbauer 2 hr later

         @nrk9819 Looking at node_modules size is a silly measure of bloat. Adding a great build tool like esbuild as a dependency, for example, downloads native binaries for every platform and so is huge. Does that mean using esbuild is bad and your project is bloated?

         1. Zach Leatherman 3 hr later

            @alannorbauer @nrk9819 I would acknowledge that the original post (on front-end performance) does not strictly relate to node_modules size, installation, or build performance.

            I would argue that node_modules size is worth measuring!

            As to whether “software bloat” extends to your dependencies, I would also argue that it does! More dependencies, more maintenance.

            I’m assuming there is a relationship between dependency count and file size, here. Maybe not with esbuild, but generally.

            1. Alan Norbauer 3 hr later

               @zachleat @nrk9819 Agreed, so let me reword what I said:

               *Only* looking at node_module size is a silly measure of bloat. (Because the entirety of it might be something like native binaries for multiple platforms).

               34MB could be 1000 terrible dependencies. 500MB could be one great dependency. The size, entirely on its own, is only a hint and it’s super silly to dunk on a package for that alone.

               1. Zach Leatherman 3 hr later

                  @alannorbauer @nrk9819 that might be true!

                  My hunch is that those are outliers and not typical—but maybe!

                  Someone should do a https://github.com/wooorm/npm-esm-vs-cjs -style analysis but for dependency count versus file size! 👀

                  1. Alan Norbauer 6 hr later

                     @zachleat @nrk9819 Surely. But the existence of outliers tells us node_modules size is (at most) correlational with good build speeds and small output bundles. It is not causal.

                     Meanwhile, web page payload size has a *causal* relationship with performance.

                     The distinction is important if this isn’t to be some silly aesthetic preference, which I suspect for some people it is.

                     1. Zach Leatherman 6 hr later

                        @alannorbauer @nrk9819 ah hmm—well, this doesn’t fit my experience. It doesn’t seem to fit the example cited in @nrk9819’s original post either?

                        Either way I’m fine with disagreeing on a thing (and I’ve hit my text reply limit here)—appreciate the discussion!

                        (Though I suspect we agree more than this discussion might suggest!)

4. Evan B🥥ehs 43 min later

   @zachleat Ok Tom

   1. Evan B🥥ehs 45 min later

      @zachleat And they wonder why I use an adblocker

   2. Zach Leatherman 56 min later

      @eb oh my god

      1. Evan B🥥ehs 57 min later

         @zachleat me obsessing over 1kb and then Tom’s Guide is out here like:

5. Alex Lohr (RIP Natenom) 1 hr later

   @zachleat The web itself is fast. Ads and their tracking, unnecessary feature cruft, frameworks needlessly throwing objects around and trying to take more control of the DOM than necessary and a lack of deferred loading strategy make it slow.

6. Jack Evans 1 hr later

   @zachleat We've collectively completely failed as an industry

   1. Zach Leatherman 2 hr later

      @JackEvans Failure is temporary as we move away from tools that have proven to be less than ideal—I remain optimistic!