4 ms·

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 incantati

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.

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.