[2] https://svelte.dev/blog/sveltekit-beta#From_Snowpack_to_Vite
[2] https://svelte.dev/blog/sveltekit-beta#From_Snowpack_to_Vite
> But I stopped using those tools and went back to my old <script src="script.js"> system because I don’t understand what those vue-cli-service and vite are doing and I didn’t feel confident that I could fix them when they break. So I’d rather stick to a setup that I actually understand.
Secondly, here's an analogy: cargo is too much magic, people learning Rust should apply a beginner's mindset by downloading dependency crates themselves and finding the appropriate rustc command lines rather than using cargo build. Sounds unconvincing?
Apart from that, debugging the builds is a bad experience.
It's actually the experienced mindset.
With experience you learn to distrust complicated setups.
A beginner would just trust the tutorials and follow them to the letter without bothering to try to understand everything.
If what you’re doing works via script tag, the odds of Vite/CRA/etc not working for you are extremely low, so why worry about problems you might have before you ever have them. It’s perfectly fine to opaquely trust your tools while focusing on the details you actually care about.
In another context, no Java course ever starts off with explaining “public static void main(String[] args) {…}” and students just “cargo-cult” it for a while until through other exposures to various bits of functionality through natural use they build a context through which to eventually circle back and easily understand what that crucial bit of code actually means. And that’s long before someone would consider trying to get a deeper understanding of what the compiler is doing! “Welcome to CS101, we’re going to start off talking about byte-code and intermediate representations” would have a success rate of literally 0%.
With JS build tools, I eventually gave up and accepted being uncomfortable.
(And to be clear, we're talking "levels of abstraction" here. Or interface/implementation. I don't need/want to understand the implementation of the tools/libraries I use. I need/want to understand how they work at the "interface" level, the mental model for what they offer and how to make them do what I want, and what choices are available on what axes. I normally achieve this. With webpacker, I give up and just copy and paste magic phrases).
Esbuild is a fantastic tool, but the nature of the problem domain is indeed inherently complex. "I don't know what import does" may sound like admitting ignorance, but it is also borderline clairvoyant. Resolving a module involves the incredibly convoluted node resolution algorithm, semantics of doppelganger packages, semantics of peer dependencies, architecture-specific optional dependencies, other ad-hoc standards and spin-offs such as package.json `browser` fields and import maps, esm vs cjs vs umd woes... any of those could break and the error messages are impenetrable when they do.
For greenfield projects? Certainly. For existing projects? Oh, you're in for a world of pain.
I'm all for breaking with the old and ushering the new era in, but there should be an upgrade path for as many possible combinations of the old as possible.
As luck would have it I decided to convert our project to vite to see if it's feasible.
So far it's:
- Absolute imports don't work and are broken in any number of subtle ways
We use typescript with a setup that resolves `/our-stuff` to `./src`.
Also this is served from `http://our-server/our-stuff` because we're a part of a larger app.
Good luck making this work with vite. Somehow it insists that you should replace all absolute imports with `/@/` and setup an alias for that. All other options (like using vite-tsconfig-paths) will not work because vite's `base` config will break this.
I "solved" it by listing all directories in `src` and converting them into vite aliases.
- Now I'm stuck with `[vite] Internal server error: failed to resolve "extends":"../../tsconfig.json" in <some-path>/mui-theme/tsconfig.json`
How to fix it? Hell if I know.
At this point I'm just giving up, and looking into how to maybe upgrade to webpack 5.
Because vite does, and "just go with vite", right?
But hey, tons of people swear by the simple setup they claim to understand; good for them. As someone who don't work on frontend stuff professionally, I wouldn't pretend I "understand" esbuild and can always fix it when it breaks. Ironically, TFA presents an issue with this simple setup that the author could not figure out without help from experts:
> I was really baffled by this, but I was eventually able to figure it out with some help from people who understood Javascript.
1. Absolute paths are not "bespoke tooling config", it's a tsconfig setting
2. Requiring some code to be served from a specific url is not "bespoke tooling config", it's a requirement for quite a few projects
3. Forcing someone to mindlessly and absolutely needlessly re-write thousands of import statements isn't really a solution
4. This will still not fix "failed to resolve "extends":"../../tsconfig.json"" and who knows what other errors
This is how progress is measured in the web world. The impact of your code/project/patch is measured by how many lines have to be rewritten to adopt it. The higher the number, the better your web wizardry rank is.
Webpack allows you to paint yourself so far into a corner that it becomes impossible to move anywhere. We should see this for what it is: an existential threat for your app. It eventually grinds everything to a halt.
Which config?
> Webpack allows you to paint yourself so far into a corner
> esbuild is not featureful enough for a lot of production use cases
What makes you say that? I keep hearing people say this, but I haven't run into any problem that make esbuild not ready for production.
It hardly matters because it's very rare that you need to run build during development. Use dev.
> I keep hearing people say this, but I haven't run into any problem that make esbuild not ready for production.
https://vitejs.dev/guide/why.html#why-not-bundle-with-esbuil...
The JS ecosystem is riddled with such pests, and (as with webpack) eradication from our workflows always proves by far the best policy.
For the hundredth time: it does matter.
Stop wasting people's time with slow tools and telling them it doesn't matter. That's not a way to treat your users.
Your fancy hot module reloading is not what I want. What I want is to reload the page and see my changes.
I've never seen a "hot reload" that works properly. The one some of co workers are using right now works like this:
- You edit a file
- You wait 5 seconds for the "instant" rebuild
- The browser reloads the page 5 times
- After a total of over 10 seconds, you can finally see the effects of your changes.
Maybe vite's HMR is better, I will never know because I don't care.
The link you sent has the following to answer why not esbuild:
> some of the important features needed for bundling applications are still work in progress - in particular code-splitting and CSS handling.
But this is not true. It handles css and does code splitting. Now, you have to be very explicit about code splitting: you have to define other entry points that share the same libraries as the main program so that it forces those shared libraries into separate chunks. To have more chunks you have more entry points where each entry point uses just one or two libraries. Yes, it's not perfect, but it's not a blocker for getting to production.
Where as the 30 seconds build is a total blocker for development iteration.
And what other people want is to not having to reload everything, lose all state on the page and make API requests all over when they add a 2px margin.
> I've never seen a "hot reload" that works properly.
Yeah, you've never seen a hot reload that works properly means someone else can't develop something new that works. And whatever crappy workflow that you enjoy must be great for everyone else.
Anyway, talking to close minded individuals is pointless, so this is it.
That's the difference.
I don't make API request in local development mode.
If I do, the response is instant.
> Yeah, you've never seen a hot reload that works properly means someone else can't develop something new that works.
It might work, but if the cost is increasing build time from 1 second to 30 seconds, it's not worth it.
If you're using any ES6 features - default params, template literals, arrow functions, let/const, spread, etc, your cut-off for browser support will be ~2017 (= no support for IE 11).
swc (https://swc.rs) does transpilation and it's as fast as esbuild. Setup is slightly more complex. I'm hoping esbuild will add ES5 transforms at some point, would much rather have a Go tool underneath.
Regarding #2, I assume that things are set up so that type errors are caught in some other way, such as in CI or in a precommit hook.
My code editor catches 90% of the errors, but it’s definitely nice to have tsc catch the rest earlier than the CI process.
With or without strict mode enabled?
Then when you put in prod, you build once. 30s once a day doesn't matter.
I mean, notepad.exe is arguably a better text editor for most people compared to anything else most of us are using.
I'll happily take some minor overhead in build configuration over adding 30s+ to every automated build if it's not a personal or small-scale community project.
I’ve been told that about jspm, webpack, parcel, snowpack, babel w/ rollup, browserify, and God only knows how many others.
Don’t you guys get tired of all this churn?
I'm dealing with a complex webpack/babel setup at work. It is rife with issues, and it amazes me that these are issues that we created ourselves. Endless dev time is wasted on debugging overly complex toolchains.
The fact of the matter is, most of these projects came along for justifiable reasons, and represent some improvements over the existing tech: speed, ease of configuration, better dev experience, better use of platform features, and so on. I'll certainly grant that there's an aspect of chasing the new shiny here, but among the senior FE folks I know, the costs of migration are always being weighed against the actual benefits you get.
Additionally, the cost of adoption/migration is very often a high-priority concern by the people writing these libraries. The pendulum is swinging back from configuration to convention.
With regards to the pace: it mainly has to do with the fact that the Web-as-application-platform has only come into its own in the past 10-15 years or so (i.e. since the death of Flash.) The tooling is just now catching up. Another HUGE factor is the growing adoption of TypeScript- for the past several years, TypeScript tooling and existing JS build/bundle systems have gradually adapted to each other, which has driven change. (Trust me: trying to figure out how to set up TypeScript compilation under webpack was confusing and miserable for a long time.)
If you're just glancing into front-end OSS every once in awhile, or if you're not heavily using the features available in these tools, you might not notice or value these improvements. And that's perfectly OK- you can certainly continue to use whatever's comfortable for you. But there's more here than meets the eye.
I think Julia had the right attitude. Instead of taking the leap of faith with a popular tool that you don't understand, instead, choose a smaller, focused tool that you can understand. As you build your application, you can more clearly and organically identify your painpoints, and then you re-evaluate if a more complex tool would be a better fit.
I think going the other way around (as you seem to suggest) is a common mistake made by many entering the JS dev world.
EDIT: For the record, I use Vite, esbuild, and rollup across several projects.
Would you help me set it up to process SCSS with dart-sass and load stimulusjs controllers as well as possibly jquery and some other packages in conjunction with 11ty, middlemanapp or rails?
All I need is processing of scss and mostly vanilla js.
Is this possible?