Do we need live reload feature in bunders? Couldn’t we just use this extension for Visual Studio Code or simular features and extensions in other IDEs which will execute a custom command of your choice when you save a file with a certain file extension in your IDE?
https://marketplace.visualstudio.com/items?itemName=emeraldwalk.RunOnSave
This extensions allows you to customize the commands to execute in saving a file in your global VSCode settings and in the VSCode workspace settings .vscode/settings.json, allowing others to use the same configuration in group projects.
Lightning CSS does not have a live reload feature and the live reload feature in Rollup cannot handle watching many files, however using this extension in VSCode, will not watch files but run the npm run dev:css or npm run dev:js command when saving a css or js file without watching for files to change.
One downside I see with this is when working on a project with others who are using different IDEs that do not support this feature. Besides that, is there any downsides to this approach?
Incremental builds are much faster as it often only need to rebuild the specific part that changed. Just re-running the build in VSCode won’t help you if the build takes like 5 minutes, but still instant with watch mode.
Hot reload also has some advantages such as not having to reload the page and lose state: it can just update the CSS live so you can quickly iterate on your styles even if you’re deep into the navigation at page 10 of a modal window.
We don’t need live reload/watch, but it sure is convenient.
Why could a build take 5 minutes? Is it due to the size of your project or the language the bundler is written in (JavaScript being a slower option over Rust)?
The scale of things. Large projects take longer to compile and bundle because they’re made out of thousands of files and hundreds of thousands of lines of code.
Yeah, your hello program will go just as fast without a bundler, or a simple bundler. It’s when you go big, and use tons of libraries and stuff that it slows down and the advantages become clearer.
That’s especially true when using big libraries like React and dozens of plugins for it, frameworks like Next.js, SASS for CSS or CSS in JS, all the JSX, all the TypeScript. It adds up especially if Babel is also involved to transpile for older browser support.
5 minutes is a bit of an extreme use case, but the point is after the first build, live reload would still refresh your code at the same speed. So working on one page you don’t need to constantly rebuild the other hundreds of them, just the one you changed. If you target mobile platforms with Cordova or React Native then you also add a whole Android/iOS build + install + restart of the app. The same live reload would work even in that context, making the speed advantage even more apparent.
These things are designed for large enterprise projects, not for your small helloworld sized hobbyist programs.
Are incremental builds only available when you’re hot reloading?
Depends entirely on the bundler. They all have a watch mode, not all of them do hot reload. Hot reload is cool but full of gotchas, it’s a hack but worst case you reload the page anyway. Some probably cache on disk, I think webpack can.
But if you think about it, you either want a clean build for production, or rebuild quickly during development. Watch mode does exactly what you’d do anyway, re-run a build. And IDEs can watch its output to give you error messages.
It’s much easier to implement: just emit the code again when the file changes, and let it go through the pipeline. It’s already there in memory all figured out, no need to figure a serialization format to put on disk to load back up.
But to circle back to the original question of why use watch mode when you can just rebuild it when saving a file: you’re reinventing the wheel, and watch mode scales better and will always be faster. Yes, some people need watch mode.
I’m not a JS user, I was just surprised that bundlers were so bad
