61–70 of 205 posts
Earlier quoted context omitted.
Plain esbuild is perfect for adding typescript support to node.js projects. We literally just run ’esbuild && node dist/run.js’
How is this different from `tsc && node dist/run.js`?
Earlier quoted context omitted.
IE (all versions) seems to have 1-2% market share, so I'm not sure it's worth jumping through hoops for.
IE usage could be 50% in your industry, or your company may guarantee IE support for one reason or another. Global stats aren't always representative of your business.
> “webpack” which I will not try to explain much because I don’t understand it, I think it’s a system with a million plugins that does a million things Is webpack really considered such a difficult beast? I was an early adopter of TypeScript so I think I started with grunt, then gulp, then finally webpack 3, 4 and now 5. I mean it's not my main job or anything, and I don't really enjoy configuring things but spending…
Earlier quoted context omitted.
I don't understand why people are holding JS to a higher standard than other languages, is it just because it used to be easier? Knowing nothing about Java, I wouldn't expect to open a Java file and know what every line means. There's a million reasons to find modern web dev complicated but not taking the time to google "js import" is not one of them. Also I wouldn't expect to "just know" how to take a Java program a…
It's holding JavaScript to its own higher standard: is dead simple, and trivial to understand and get working. NPM, import, etc. seem mindbogglingly complex in comparison, with an enormous number of ways to do each thing, most of which require at least one build step just doesn't, and enormous numbers of third party dependencies, and if you go away for a few months and come back, there are good odds things will be di…
The most simple example is almost never a representative example that can be used as a standard to hold the whole language to.
In the same vein, one could say: "See how easy it is to build a C program with `gcc main.c`? Why should I have to figure out how to use make?". And the answer is simple: Most projects that go beyond a toy example have much more elaborate requirements(/whishes), like "I'd like to reuse code that another person has written in the past so I don't have to do it".
> “webpack” which I will not try to explain much because I don’t understand it, I think it’s a system with a million plugins that does a million things Is webpack really considered such a difficult beast? I was an early adopter of TypeScript so I think I started with grunt, then gulp, then finally webpack 3, 4 and now 5. I mean it's not my main job or anything, and I don't really enjoy configuring things but spending…
I don't think you realize how hellish this sounds. I haven't had >100 lines of build configuration in any other environment since my configure.in/Makefile.am days, and even that was more transferable to other tools than Webpack, which is only good for Webpacking.
Earlier quoted context omitted.
How is this different from `tsc && node dist/run.js`?
1. It’s much faster. 2. It won’t catch type errors. 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.
Earlier quoted context omitted.
Addressed in TFA: > But I stopped using those tools and went back to my old 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.
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.
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?
- http/2 multiplexing has made it unnecessary to limit the number of script or css files loaded at once. Faster connections together with http/2 mean payload splitting is no longer necessary for js and css (which means everything can load up front from index.html). Gzipping removes the need for minification.
- Any npm package can be loaded as script tags or through direct es6 module import from unpkg.com. I use a single ‘externals.js’ which exports those dependencies so I can just do “import { foo } from ‘externals.js’”
- sass is mostly unnecessary thanks to widespread css3 support, @import for modularity (see also http/2), bem notation for namespacing, and css variables for reuse
- es6 is supported in all browsers, so you can write modern code. ES6 modules “just work” if you import from a file path.
- vue and preact are designed to be used without build tools. An app deployed as a static site can use hash routing to need no builds and no server-side router.
Experimenting with this stuff has really made me wonder why we use all of these build tools.