Yes, you don't need Parcel, Vite, Webpack, Rome or Rollup to code with Javascript.
I never understood how to configure webpack and you don't know what thoses tools are doing.
Just keep things simple. Write your own bundler with esbuild. Here is a script I wrote to build a Svelte Typescript Tailwind projetct :
https://github.com/Tazeg/svelte-typescript-esbuild-tailwind-...
Some notes on using esbuild
101–110 of 205 posts
Re: Some notes on using esbuild
#102> there are 2 standards (CommonJS and ES6 modules), and that require is CommonJS and import is ES6 modules
Kind of, but not really. There are JavaScript modules as defined by the ECMAScript standard and implemented in Web browsers and anyone else who cares about implementing the spec, and then there is NodeJS, which has its own way of doing things, along with people who refuse to give it up and insist on dragging those headaches into places where you should not otherwise expect to see them. People call the latter "CommonJS modules" (including e.g. the TypeScript team), but in fact CommonJS is a whole thing on its own that NodeJS doesn't actually follow. The thing that CommonJS and NodeJS-style imports have in common is that both used the `foo = require("bar")` convention.
To understand the mess that is the current JS ecosystem (and hopefully how to get out of it), people really need to come to grips with recognizing NodeJS's role as an IE-like entity:
- 800-pound gorilla
- not under the control of the best and the brightest
- implements its own share of proprietary (vendor-specific) shenanigans
- the people who shamelessly target it and see nothing wrong with doing things this way are the source of the the worst problems within the ecosystem or on a given project
- responsible for a massive corpus of legacy junk that you are expected to be familiar with and that it will take years to clean up
Re: Some notes on using esbuild
#103> “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 have a couple of files, one for local one for production. About 50-70 lines each 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.
Modern webpack is also much simpler than when it started, as they’ve followed their zero-config northstar (#0CJS) for a while now. Many simple projects can literally run without a config file at all. The config file only grows in relation to the complexity you want to take on, like adding Typescript or wanting to run WebWorkers, but that seems fair? It’s not like you can just start adding Kotlin or Scala to a Java project without changing your setup.
And there are plenty of higher-level tools than webpack that are pre-configured to handle most of your variations anyway (eg CRA) and are a much better starting point if you don’t need to fine tune your build or do complicated/exotic things (which isn’t a breeze in any language I’ve experienced).
Re: Some notes on using esbuild
#104> “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…
At two places I’ve worked, we had performance issues with webpack where builds would take tens of minutes. Every frontend guru would come in with their “oh, it’s probably X”, spend half a day debugging, and then give up.
Moreover, webpack does all sorts of things I don’t care about: support for a dozen different module systems, javascript versions, polyfills, scss, JSX, etc etc. I just want to issue a few requests and update the DOM.
I guess I’m spoiled by Go and Rust where I can basically just throw a list of dependencies at the build tool and it spits out an executable (almost immediately in the case of go).
Re: Some notes on using esbuild
#105Earlier quoted context omitted.
> 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 - Y…
> What I want is to reload the page and see my changes. 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 enjo…
> lose all state on the page and make API requests all over
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.
Re: Some notes on using esbuild
#106I've recently being helping a friend who is starting with Node.js, and I strongly recommended him (and anyone else getting started now) to use all `import` instead of `require`. I would say it takes a bit more of work because the tutorials are normally written on commonJS (require), but otherwise it's just a different kind of work. Both of them have their peculiarities and issues, and CommonJS might also bite you big…
FWIW, you can replace __dirname with information from import.meta (and 2 lines of JS). It’s not quite as automagic but can yield the exact same info. You’re also right that it might just be a code-smell in general though.
Re: Some notes on using esbuild
#107Great write up. Would like to direct to skypack.dev too for zero build tool imports as well! e.g. https://cdn.skypack.dev/vue/dist/vue.esm.js
Skypack looks interesting. However, as I come from a Nix background, I'd like to a) pin my dependencies and b) do a hash check at install/download time to ensure the pinned package hasn't been modified behind the scenes.
Based on https://docs.skypack.dev/skypack-cdn/api-reference/pinned-ur..., it appears that you can do a. with Skypack, but this requires a manual step: look up the package in the CDN with curl or your browser and copy-paste the URL into your JS import statement. Is there any tooling to automate this?
Also, there appears to be no way to fail the build if the contents of the pinned URL change. Are Skypack users relying on Skypack to ensure that can't happen?
Re: Some notes on using esbuild
#108Earlier quoted context omitted.
You're saying Java & Maven/Gradle are simpler than even Nodejs or ESM workflows?
Maven and Gradle are build tools, similar to esbuild. I was talking about import in JavaScript itself, not build tools or package managers. Within the actual language, there isn't a universal syntax just to use a package. In Java, there is.
> Within the actual language, there isn't a universal syntax just to use a package.
There is. The issue is one of mindset. You recognize Maven and Gradle as belonging to a sort of "parastandard" set of technology, offering proprietary (albeit free/open source) glimpses of how one could conceivably solve the set of problems that they're meant to be used for, but when it comes to JS, you're elevating the parastandard stuff to the level of being part of "JS".
Neither CommonJS nor NodeJS's `require` nor package.json nor TypeScript nor esbuild are part of JS. You shouldn't give them any privileged status that you aren't willing to give to Maven or Gradle when you think of Java.
Re: Some notes on using esbuild
#109TIL strace[1] exists. What a handy tool!
1. https://jvns.ca/blog/2021/04/03/what-problems-do-people-solv...
Re: Some notes on using esbuild
#110Earlier quoted context omitted.
My primary frustration with frontend development is that I have gone to JS Build Tool University... Roughly 10 times now. I'm not sure I've ever set up two separate frontends the same way. Even when I avoid the shiny new tools and stick with crusty slow webpack, there's a new version that behaves entirely different than the previous version. I'm enjoying the speed and simplicity of ESBuild.
I've been poking fun at JS for a long time (friendly though, I'm consistently amazed at what those people manage to do with little more than straws and duct tape ;-) Just be glad Gradle hasn't entered the JS scene yet: With JS there is at least some standards now: both Angular and React at least has some systems for getting things running in a standard way and keeping it somewhat aligned. With Gradle however I haven'…
Gradle is capable of very powerful things so on larger projects there is generally a project specific Gradle dialect in play and I can understand why this frustrates newcomers but it's an important capability for large projects and monorepos.
I would say most small projects (especially OSS) tend to stick to a simple subset of Gradle even if it's multiproject build etc.
The amount of churn in the JS build tool space easily outstrips any one time learning you need to do to surpass the Gradle knowledge cliff where all this complex stuff just makes sense.