3 ms·

Yep. At my previous company, the Java (server-side) builds were a lot faster than the JS / React (client-side) builds. The fat jars were also a breeze to deploy

• Cthulhu_ 5y ago
  JS / React build performance suffers because of a few things; sheer amount of files and code due to the normalization of small files and many dependencies, and inefficient compilers / transpilers built in Node-flavored JS instead of native. There's projects like deno and esbuild that should help mitigate those issues, and Yarn's Plug'n'Play to reduce file amount and size overhead by using .zip files and centralized repositories. I mean it's only a patch but still.
  • icedchai 5y ago
    Whenever I do a "du" on a node_modules directly, I am always amazed! How did we get here?
    • nobleach 5y ago
      We said that we were adopting the Unix philosophy of doing one thing, and doing it well. While at the same time, we wanted to avoid the dependency hell that plagued other systems. So we allowed each dependency to specify its own version of dependencies. The graph grew to an unmanageable mess. I realize you may already know this, but perhaps someone reading these comments could benefit. Every organization with whom I've been affiliated since 2017 has a fairly strict policy of dependency audit. Dependencies are NOT allowed to be added unless there's a really good reason. And even then, we pay a lot of attention to what that dependency will bring with it.