8 ms·
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
by amasad 5y ago
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.
- protonimitate 5y agoThis 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.
- amasad 5y agoI 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 https://replit.com/@templates/Reactjs
- JMTQp8lwXL 5y agoAs 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?
- vijaybritto 5y agoYou still can do polyfills manually via browserify packages
- deleted 5y ago[deleted]
- judofyr 5y agoPreviously 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.
- acdha 5y ago> 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.
- jeswin 5y agoThis 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.
- desireco42 5y agoYou still need webpack for production build :). So all is good.
- darekkay 5y agoVite uses Rollup for production builds, which is still much faster than webpack.
- simlevesque 5y agoWhy can't you use esbuild for production builds ?
- RobertKerans 5y agoTree 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.
- eliseumds 5y agoCorrect.
- desireco42 5y agoYes 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.
- IggleSniggle 5y agoI use esbuild for prod...?
- jakelazaroff 5y agoIn 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 :)
- fiddlerwoaroof 5y agoI’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.
- amasad 5y agoI'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.
- fiddlerwoaroof 5y agoI’d like to see the numbers: the webpack config CRA eject gives you is a monster.
- mumphster 5y agowebpack 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
- bavell 5y agoAgreed, 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.
- wildpeaks 5y agoExactly: 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.
- sjaak 5y ago“Only” 34mb for a hello world project? I can’t tell if you’re being ironic but I hope so!
- amasad 5y agoNearly an order of magnitude reduction. What do you think of that?
- lhorie 5y agoThey probably mean that "hello world".length == 11 // bytes
- kklisura 5y agoIs it? I know there's no sizeof, but what would be sizeof(char) in JS? 1 byte?
- IggleSniggle 5y agoThe 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.
- lhorie 5y agoNo 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.
- IggleSniggle 5y agoThe 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.
- mariusmg 5y ago>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
- koolba 5y agoIt’s more of a hello import the world.
- thunderbong 5y agoOr is it the other way around!
- spoiler 5y agoIt'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.
- ng12 5y agoWould you count the size of the JVM when you do Hello World in Java?
- Scarbutt 5y agoNo because they are not counting the size of the browser or nodejs
- deleted 5y ago[deleted]
- hombre_fatal 5y agoYou 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.
- deleted 5y ago[deleted]