Hacker News Reader

Comment by amasad | Hacker News Reader

Some stats not mentioned in the post. Create React App (webpack) vs Vite (esbuild) on Replit containers:

- 1 second start up time on Vite vs 15 seconds for CRA

- React.js hello world project is 234mb on CRA and only 34mb on Vite

- 1GB RAM for Vite dev server vs 3GB+ for CRA

This is a perfect example of how fast and efficient tools can be, and I think we can do even better! Super excited about the future of JavaScript tooling ecosystem with more focus on efficiency and speed.

In addition to the UX win, and I wish we measured this, but I bet this saved us thousands of dollars in monthly cloud spend.

View on HN

As the "webpack" guy on my team, these numbers look extremely compelling, but I also know Webpack does a lot for us (e.g., through Webpack v4, it includes browserfied node libs as needed). Beyond node libs, there's a long tail of niche things that need to be taken of... am I trading coverage of that long tail for speed?

You still can do polyfills manually via browserify packages

Previously I've been a heavy user of Webpack + plugins, but I've now moved over to ESBuild for all new projects. This means letting go of many fancy features, but the overall complexity is so much reduced and I'm a lot happier.

Before: Chain together style-loader, css-loader, postcss-loader and the MiniCssExtractPlugin in some weird way. So complicated to understand which PostCSS plugins interacts with resolving imports. I often need to look into the webpack.config.js to understand how everything work. After: Use PostCSS and its tooling for CSS. Yes, there's now a separate process I also need to run in order to watch and build CSS. Yes, I can no longer `import "./style.css"` from the JavaScript files. But it's so much easier to reason about! The CSS tooling creates a CSS file; the JavaScript tooling creates a JavaScript file. Do I want to build SVG sprites? Well, that can very easily be a separate script which I can debug independently and _not_ couple into my builder's plugin system.

In addition, now my JavaScript files are actually just JavaScript and I can be pretty sure that it will work with any new tooling without any problems. Once the successor to ESBuild comes out I will most likely be able to point it at index.js and everything will work.

> In addition, now my JavaScript files are actually just JavaScript and I can be pretty sure that it will work with any new tooling without any problems.

That's been my feeling for years, too: if your team is less than, say, several dozen people there's a significant amount of merit to having something which doesn't require continous care and feeding for anyone to work, especially when it's combining a number of complex libraries with independent development teams.

This is excellent advice. There's something I really dislike about import "./style.css" into JS files - it just seems meaningless especially if you've worked with other languages/ecosystems. A great many tutorials default to this style, so it'll likely live on for a while.

As yet another tiny UI framework creator (forgojs.org), the switch to esbuild-loader was our best developer experience decision. create-forgo-app (our CRA equivalent) takes 3-4 seconds, and running it is instantaneous. Faster builds actually change the way developers write code.

One great problem it solves is namespacing all of your styles. I don't have to worry about classname collisions because the bundle handles it all for me. Instead of having one massive global stylesheet, I have a bunch of small, modular stylesheets that fit entirely on my display without scrolling, and I can reason about the output much easier than before.

Plus effortless code splitting.

You're talking about css modules. It's a different feature.

It’s funny to me that we’ve sort of ended up back where I started with Browserify and a seperate Less compile step, or even further back with require.js in some ways.

It’s smart though. Despite having built webpack plugins myself, my main gripe with it was how overloaded it became.

You still need webpack for production build :). So all is good.

Vite uses Rollup for production builds, which is still much faster than webpack.

Why can't you use esbuild for production builds ?

Tree shaking isn't sorted, so can't currently get an bundle optimised to same extent as you do with Webpack/Rollup et al. It'll come, but not quite there yet.

Correct.

Yes you can, my bad/ But some people have webpack configs, so the easiest for them is to keep those and can use Vite for development. Like if you are not doing new project.

I use esbuild for prod...?

In my experience, the vast majority of use cases are covered by these "no config" tools. If your app isn't a typical CRUD app you might fall into that long tail, but FWIW almost every app I've built has not :)

>Super excited about the future of JavaScript tooling ecosystem with more focus on efficiency and speed.

Well they can't get worse than now... 234mb for a friggin hello world app

It’s more of a hello import the world.

Or is it the other way around!

It's worth noting that the tooling and build systems are that big. They include type definitions, binaries, scss preprocessors, typescript compiler, linter, and a lot of other tools to enhance DX. Some of them might include other non-code resources.

The hello world app is not going to be this big.

Would you count the size of the JVM when you do Hello World in Java?

You could, since it’s a runtime dep. But a better comparison would be to the client dev tool chains in other ecosystems, like Xcode (11GB), though still not very interesting. Turns out client dev is hard and it doesn’t make much sense hand wringing over dev tool size metrics.

Better to look at how well they solve their problem space.

No because they are not counting the size of the browser or nodejs

you could and it would still be much smaller.

Java HelloWorld runs in 1mb:

  20:18:01 /tmp > echo 'public class HelloWorld {public static void main(String[] args) {System.out.println("Hello World!");}}' > HelloWorld.java
  20:18:09 /tmp > javac HelloWorld.java
  20:18:14 /tmp > java -Xmx1m HelloWorld
  Hello World!

I’d like to see non-CRA numbers: I’ve found that a simple React + Webpack 5 project is not as bad to get off the ground as it used to be.

I'm sure it's less disk space because it has less deps but the most of the RAM and CPU usage in CRA is Webpack so I'd be surprised if that changed much.

I’d like to see the numbers: the webpack config CRA eject gives you is a monster.

webpack AND all the extra plugins and preprocessing and postprocessing CRA adds -- its not a small webpack setup by any means and you can get 1s build times with webpack pretty easily without CRA

Agreed, I use webpack for small and medium projects and it's basically instant. I use TS but not the compiler - I tell babel to strip types and use just a few plugins, transforms and loaders.

I'm not in love but it's a core tool in almost all of my projects, personal and professional.

Exactly: 99% of the time, "webpack is slow" is just code for "I have Babel in my toolchain" and forgetting to set ts-loader as "transpile only".

Personally I removed it years ago, and Webpack 5 even allowed me to get rid of more loaders now that there are Assets Modules that automatically detect assets and webworkers using the "new URL()" syntax, and Typescript does everything else I need.

The new URL() thing is amazing

Can someone clarify what the new URL() thing is?

https://webpack.js.org/guides/asset-modules

this is the release notes for it:

https://webpack.js.org/blog/2020-10-10-webpack-5-release/#as...

I can remove babel in my code?

It depends on your target platform: ES6 modules are basically supported in every browser I care about, so the major reason for Babel is JSX

Even if your target platform didn't have ES6 modules, Babel is probably not the tool you'd want to transpile those with. Let the bundler (which is the topic of the discussion here so I assume a bundler is used) handle them. Tree shaking works better that way anyway.

Also if JSX or similar JS extensions are the only thing you need tramspiling for, you might want to look at Sucrase [1] as a fast alternative to Babel.

https://github.com/alangpierce/sucrase

Yep, I needed to put together a Webpack build tool chain for React last month & thought it was going to be a bit of a nightmare and it just...wasn't. Tiny bit of fiddling, but generally easy -- that was with a fairly complex setup in terms of the project structure and rules around deployment, so quite impressed after a few years of avoiding it due to how much I hated the song and dance over setting it up.

“Only” 34mb for a hello world project? I can’t tell if you’re being ironic but I hope so!

Nearly an order of magnitude reduction. What do you think of that?

They probably mean that "hello world".length == 11 // bytes

Most of the build tooling gets installed along the way.

The compiled JS is hundreds of bytes at most, usually because React creates a bunch of boilerplate for you (a basic CSS file, an application, a web worker, etc) which you may remove.

But why would you? This is the silliest way to judge something ever: what practical web application is anyone routinely building with no CSS, web workers etc.

You would because you're comparing it to a "Hello world" command-line program in another language which also doesn't have CSS, web workers, etc.

Well, that's part of the jab: that you ostensibly don't need build tooling for an interpreted language, and further, that you don't even need an interpreted language in the first place considering we're talking about a platform that can do UI out of the box via a declarative language.

(Obviously, that's neither here or there when we're talking about baselines for SPAs)

ES6 is a compile target.

The actual languages are often Typescript and jsx, to say nothing of the Svelte compiler or Elm.

You can write vanilla JS without all that, of course.

Is it? I know there's no sizeof, but what would be sizeof(char) in JS? 1 byte?

The answer to this question is complicated. JavaScript char encoding is roughly UTF-16, which is 2-bytes, but the byte you read may have been part of a surrogate so, depending on your first one, you must read the next 2 bytes to complete your character.

And of course, this basic explanation doesn’t really do justice to answering your question, because depending on your definition of what a “character” is, you may need to take into account ligatures etc.

No need to overcomplicate though. None of this applies to the ascii range, and we're just talking about storage in disk in the first place.

The 2-bit part applies, if not the rest, and it’s not really “on disk” but rather “memory for data type,” right?

Given the nature of the questions, I presumed they were interested in knowing “how does JavaScript load strings into memory, anyway?”

And to answer that question, your rough heuristic should be “2 bytes per character” not 1, even for ascii range. That just leads to additional questions, though, because of the oddity of it.

In order to achieve the ability to do Unicode, there’s a reserved set of values within that 2-bytes, to allow you to extend the encoding to reach Unicode.

Back to the original measurement, for the string “hello world”, I believe a JavaScript `sizeof`, if it existed, would report 24 bytes (22 for the characters, and 2 (give or take) for either the NULL character or for a length header.

The thread was originally about CRA vs Vite size on disk (or implicitly, if we're applying it to real world applications, network cost in CI job startup times). And like I said, surrogate pairs don't apply to ASCII.

See this[0] for reference. Note how the first byte must fall within a certain range in order to signal being a surrogate pair. This range quite deliberately falls outside the ASCII range. This fact is taken advantage of by JS parsers to make parsing of ASCII substrings faster by special casing that range, since checking for a valid character in the entire unicode range is quite a bit more expensive[1].

IMHO nitpicking about memory consumption of the underlying data structure is a bit meaningless, since the spec doesn't actually enforce any guarantees about memory layout. An implementation can take more memory for pointer to prototype, to cache hash code/length, etc, and there are also considerations such as whether the underlying data structure is polymorphic or monomorphic due to JIT, whether the string is boxed/unboxed, whether it's implemented in terms of C strings vs slices, etc.

Regardless, it doesn't change the fact that the octet sequence "hello world" takes 11 bytes in ASCII/UTF8 encoding (disregarding implementation metadata).

[0] https://github.com/jquery/esprima/blob/0911ad869928fd218371b...

[1] https://github.com/jquery/esprima/blob/0911ad869928fd218371b...

All great points. Not trying to nitpick, just trying to satisfy curiosity.

Considering that projects nowadays have all dependencies installed into their folders, what else is both viable and much smaller? If we had to install everything required for a hello.c into c_modules, including a compiler, libc, etc, it wouldn’t take less than 34mb.

Of course a counter argument is that you don’t usually swap C compilers between projects and libc is stable af, but if a toolchain and/or stdlib was constantly changing and subject to non-compat, you’d have to.

This is informative.

How is the configuration overhead? Is it relatively easy to get Vite + a custom react app template + tsx + testing up and running?

CRA is bloated, but still one of the fastest ways to get a "full app" up and running with React.

I don't think Vite has a testing story yet. As for the rest, yes, it totally is straightforward. We only had to change one line of configuration in the base template for it to work on Replit. See https://replit.com/@templates/Reactjs

Reply on news.ycombinator.com