7 ms·

If you're going to have a build step at all, instead of hand rolling your build commands and configs, just use Vite[1] already. It uses esbuild for development

by oefrha 5y ago

If you're going to have a build step at all, instead of hand rolling your build commands and configs, just use Vite[1] already. It uses esbuild for development and rollup for production (since esbuild is not featureful enough for a lot of production use cases), you get instantaneous startup, hot module replacement, static asset imports, etc. for free. It's from Evan You, the creator of Vue, but it also supports React, which works pretty well with it in my experience. Btw SvelteKit also uses Vite.[2] [1] https://vitejs.dev/ https://vitejs.dev/ [2] https://svelte.dev/blog/sveltekit-beta#From_Snowpack_to_Vite https://svelte.dev/blog/sveltekit-beta#From_Snowpack_to_Vite

cuu508 5y ago
Addressed in TFA: > 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.
- loevborg 5y ago
  She's doing things the right way here - applying the beginner's mindset, trying to understand things rather than cargo-culting by copy-pasting magical incantations from github. There's just so much incidental complexity in JS tooling, and her instinct to steer clear of that insanity by using Unix tools like esbuild is spot on.
  - tgv 5y ago
    Seems right to me, too, but perhaps it's not the beginner's mindset. My colleague, who is an actual beginner, started the frontend part of a project, read up to the vue-cli scaffolding incantation, copy-pasted it into his terminal and checked in the result. The consequence was that I have to fix the unavoidable breaks and other npm and webpack issues, because he has no clue. Apart from that, debugging the builds is a bad experience.
  - oefrha 5y ago
    First, esbuild is meant to be a complete JavaScript bundling platform. It already packs a lot of features, and is in the process of acquiring more. What it doesn't pack natively can be bolted on via the plugin system. It's an end-to-end solution, or almost one (it doesn't give you a dist folder you can just deploy, you still need to add an index.html), not "doing one thing and one thing well", unless you define your "one thing" to be very broad. 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?
  - hsn915 5y ago
    > the beginner's mindset 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.
  - merrywhether 5y ago
    On the flip-side this approach sounds kind of like premature optimization. You don’t have to understand the entire path from pressing buttons on a keyboard to a program causing photons to exit your monitor. You instead trust that large parts of that chain just work. 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%.
  - jrochkind1 5y ago
    I am fairly good at avoiding cargo culting and only using things I understand. I am uncomfortable developing any other way. 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).
  - lhorie 5y ago
    I mean, there is a certain amount of buy-in into cargo culting. She could've used something like mithril.js and that would've worked with a script tag only setup without having to worry about template language compilers or anything of the sort. The tutorial even walks you through how to do exactly that. 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.
hsn915 5y ago
I don't understand the point of vite. I tried using it and the "build" took over 30 seconds. esbuilds takes less than 1 second for the same project. > 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.
- oefrha 5y ago
  > I tried using it and the "build" took over 30 seconds. 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-esbuild https://vitejs.dev/guide/why.html#why-not-bundle-with-esbuil...
  - inopinatus 5y ago
    I read that as yet another 30 seconds for a CI or production build, on top of every other inefficient tool shipping with an inflated sense of necessity and no feel for devops concerns. Accepting such into your toolset remains a primary source of creeping bloat. The JS ecosystem is riddled with such pests, and (as with webpack) eradication from our workflows always proves by far the best policy.
    - oefrha 5y ago
      Sure, please contribute to esbuild so that it solves more of people's actual needs. It's not like Evan doesn't want to switch to esbuild in Vite completely. My link to "Why Not Bundle with esbuild?" should be a good start for where you should look.
  - hsn915 5y ago
    > It hardly matters 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.
dmitriid 5y ago
> instead of hand rolling your build commands and configs, just use Vite[1] already. 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 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.
- oefrha 5y ago
  Point taken, but it's not like switching the average existing webpack project (let alone a webpack 4 project) to esbuild is just a walk in the park. We're talking about whether you should roll your own esbuild commands here.
  - dmitriid 5y ago
    Yeah, it looks like rolling our own esbuild commands might be the way to go because "just switch to vite already" doesn't work, does it?
    - oefrha 5y ago
      If you can roll your own esbuild commands to build your codebase without change, good for you. Once you’ve done that, good luck figuring out a dev server with HMR, since esbuild certainly doesn’t offer that.
toastercat 5y ago
If you're already familiar with JavaScript, it takes about a day's worth of Node.js API knowledge to write your own build scripts with esbuild. 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.
ComputerGuru 5y ago
> just use Vite[1] already 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?
- toastercat 5y ago
  Yes. I've used them all. I think Julia's approach is the best: code like it's 2005 until you feel like you hit roadblocks, then pick the simplest and most focused tool for the job (which at this point, I think esbuild is the best pick for its scope and speed). 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.
- mhink 5y ago
  Not really. 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.
andrei_says_ 5y ago
I’d love to. 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?
- andrei_says_ 5y ago
  I just discovered that vite uses js to paste your css in the html?! So no way to use unless I let it also process the html files?

by oefrha 5y ago

cuu508 5y ago

Addressed in TFA: > 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.

loevborg 5y ago
She's doing things the right way here - applying the beginner's mindset, trying to understand things rather than cargo-culting by copy-pasting magical incantations from github. There's just so much incidental complexity in JS tooling, and her instinct to steer clear of that insanity by using Unix tools like esbuild is spot on.
- tgv 5y ago
  Seems right to me, too, but perhaps it's not the beginner's mindset. My colleague, who is an actual beginner, started the frontend part of a project, read up to the vue-cli scaffolding incantation, copy-pasted it into his terminal and checked in the result. The consequence was that I have to fix the unavoidable breaks and other npm and webpack issues, because he has no clue. Apart from that, debugging the builds is a bad experience.
- oefrha 5y ago
  First, esbuild is meant to be a complete JavaScript bundling platform. It already packs a lot of features, and is in the process of acquiring more. What it doesn't pack natively can be bolted on via the plugin system. It's an end-to-end solution, or almost one (it doesn't give you a dist folder you can just deploy, you still need to add an index.html), not "doing one thing and one thing well", unless you define your "one thing" to be very broad. 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?
- hsn915 5y ago
  > the beginner's mindset 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.
- merrywhether 5y ago
  On the flip-side this approach sounds kind of like premature optimization. You don’t have to understand the entire path from pressing buttons on a keyboard to a program causing photons to exit your monitor. You instead trust that large parts of that chain just work. 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%.
- jrochkind1 5y ago
  I am fairly good at avoiding cargo culting and only using things I understand. I am uncomfortable developing any other way. 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).
- lhorie 5y ago
  I mean, there is a certain amount of buy-in into cargo culting. She could've used something like mithril.js and that would've worked with a script tag only setup without having to worry about template language compilers or anything of the sort. The tutorial even walks you through how to do exactly that. 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.

hsn915 5y ago

I don't understand the point of vite. I tried using it and the "build" took over 30 seconds. esbuilds takes less than 1 second for the same project. > 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.

oefrha 5y ago
> I tried using it and the "build" took over 30 seconds. 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-esbuild https://vitejs.dev/guide/why.html#why-not-bundle-with-esbuil...
- inopinatus 5y ago
  I read that as yet another 30 seconds for a CI or production build, on top of every other inefficient tool shipping with an inflated sense of necessity and no feel for devops concerns. Accepting such into your toolset remains a primary source of creeping bloat. The JS ecosystem is riddled with such pests, and (as with webpack) eradication from our workflows always proves by far the best policy.
  - oefrha 5y ago
    Sure, please contribute to esbuild so that it solves more of people's actual needs. It's not like Evan doesn't want to switch to esbuild in Vite completely. My link to "Why Not Bundle with esbuild?" should be a good start for where you should look.
- hsn915 5y ago
  > It hardly matters 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.

dmitriid 5y ago

> instead of hand rolling your build commands and configs, just use Vite[1] already. 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 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.

oefrha 5y ago
Point taken, but it's not like switching the average existing webpack project (let alone a webpack 4 project) to esbuild is just a walk in the park. We're talking about whether you should roll your own esbuild commands here.
- dmitriid 5y ago
  Yeah, it looks like rolling our own esbuild commands might be the way to go because "just switch to vite already" doesn't work, does it?
  - oefrha 5y ago
    If you can roll your own esbuild commands to build your codebase without change, good for you. Once you’ve done that, good luck figuring out a dev server with HMR, since esbuild certainly doesn’t offer that.

toastercat 5y ago

If you're already familiar with JavaScript, it takes about a day's worth of Node.js API knowledge to write your own build scripts with esbuild. 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.

ComputerGuru 5y ago

> just use Vite[1] already 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?

toastercat 5y ago
Yes. I've used them all. I think Julia's approach is the best: code like it's 2005 until you feel like you hit roadblocks, then pick the simplest and most focused tool for the job (which at this point, I think esbuild is the best pick for its scope and speed). 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.
mhink 5y ago
Not really. 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.

andrei_says_ 5y ago

I’d love to. 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?

andrei_says_ 5y ago
I just discovered that vite uses js to paste your css in the html?! So no way to use unless I let it also process the html files?