But my experience with build systems (not just Javascript build systems!), is that if you have a 5-year-old site, often it’s a huge pain to get the site built again.
I agree with this so much, the task of updating an old project’s dependencies to the latest version and going through every library’s migration guide is a massive pain.
The exception is even when I’m just writing a single JS file to directly include on a page I’ll still write it in TypeScript. The build step is minimal, it’s unlikely that a piece of code won’t compile in a couple years, the output is still perfectly readable if you set a high enough ES standard version, and the wins (for me) are well worth the small effort.
On some projects I use tsc to compile each TS file as a separate independent module (with make). It makes for a nice development workflow. I then use cjsc to bundle the TSC-compiled JS files into a single application bundle. It’s far from perfect and source maps don’t work but it is fast and simple.
If the TC39 proposal for erased type annotations progresses forward, that will make it far easier to just write TypeScript source and run that directly without any required tooling in the middle.
That’s still “a build step”, in my potentially very wrong definition of build step. My ideal is to just include some tags in the HTML and reload the browser. Anything that I have to install locally and run to generate an output is a build step.
I think OPs definition is the same as mine, for what is worth.
True, and I painfully remember this every time I get distracted during the 5-to-10 seconds build time, go look at something else, come back to the code 15 minutes later and I realize I’m not even sure if I did compile it or not.
That’s unavoidable as long as the browsers, in this case, can’t run Typescript directly. I’m just happy we stuck to the bare minimum. If it was just me I’d ditch Typescript entirely.
It seems like swc might be a much faster typescript compiler. It doesn’t do the type checking, but assuming you’re using an editor that does type-checking as you go, then you probably don’t care much about type checking in the compile/run phase of your iteration loop? I haven’t looked into it personally since my TS projects are relatively small.
I worked at a place that relied on editor lints for TS type checking and I wouldn’t do that again if I could help it. Things eventually became inconsistent across the (large) codebase because if you broke something in a file you weren’t looking at you didn’t notice the breakage. Maybe for a very small project, but I would rather set up a proper compilation step at the outset than deal with issues down the road.
I’m not totally sure why some libraries don’t provide a no-build-system version – maybe distributing a no-build-system version would add a lot of additional complexity to the library, and the maintainer doesn’t think it’s worth it.
I wonder if “a no build system” option is an attractive nuisance. We’ve seen a lot of systems where defaults set for developer convenience cause waste when they’re used in production environments. In some cases (probably not applicable to CSS), developer conveniences are even security risks.
I think Julia is making her decisions reasonably, and is well aware of the tradeoffs. For someone in her situation, requiring a build system really is a drawback. Still, I can see a maintainer who works with build systems all the time thinking that a no-build system option would just be handing people a way to shoot themselves in the foot. I can already imagine the HN and Lobsters posts about devs who are too careless to minify and tree-shake their projects.
htmx is an example of a JavaScript library without a build system (actually, with almost zero need for custom JavaScript). Highly recommend checking it out.
If we look at the current moment as frozen in time, than, yes, absolutely, deno thoroughly solves the problem of “building projects”. However, at this point I don’t think it’s clear if deno (and even typescript) will be there in ten years.
This is extremely true.
I agree with this so much, the task of updating an old project’s dependencies to the latest version and going through every library’s migration guide is a massive pain.
The exception is even when I’m just writing a single JS file to directly include on a page I’ll still write it in TypeScript. The build step is minimal, it’s unlikely that a piece of code won’t compile in a couple years, the output is still perfectly readable if you set a high enough ES standard version, and the wins (for me) are well worth the small effort.
On some projects I use tsc to compile each TS file as a separate independent module (with make). It makes for a nice development workflow. I then use cjsc to bundle the TSC-compiled JS files into a single application bundle. It’s far from perfect and source maps don’t work but it is fast and simple.
The post already calls it out, but I can highly recommend using esbuild as a basic build system. It is really no-bs and low barrier to entry.
I’d love a no-build-system way of using typescript =/
If the TC39 proposal for erased type annotations progresses forward, that will make it far easier to just write TypeScript source and run that directly without any required tooling in the middle.
This is one reason I’m pretty bullish on deno. The lack of tooling is actually more important than the stuff they give you.
the project I work on is straight
tsc.We have an
index.html,main.cssand atsconfig.jsonsuch asin which the order in “files” is meaningful.
Building is just running
tsc.The very few external libraries are
<script…tags in theindex.htmlThat’s still “a build step”, in my potentially very wrong definition of build step. My ideal is to just include some tags in the HTML and reload the browser. Anything that I have to install locally and run to generate an output is a build step.
I think OPs definition is the same as mine, for what is worth.
True, and I painfully remember this every time I get distracted during the 5-to-10 seconds build time, go look at something else, come back to the code 15 minutes later and I realize I’m not even sure if I did compile it or not.
That’s unavoidable as long as the browsers, in this case, can’t run Typescript directly. I’m just happy we stuck to the bare minimum. If it was just me I’d ditch Typescript entirely.
FYI, you can pass the –watch flag to tsc and forget about it.
It seems like
swcmight be a much faster typescript compiler. It doesn’t do the type checking, but assuming you’re using an editor that does type-checking as you go, then you probably don’t care much about type checking in the compile/run phase of your iteration loop? I haven’t looked into it personally since my TS projects are relatively small.I worked at a place that relied on editor lints for TS type checking and I wouldn’t do that again if I could help it. Things eventually became inconsistent across the (large) codebase because if you broke something in a file you weren’t looking at you didn’t notice the breakage. Maybe for a very small project, but I would rather set up a proper compilation step at the outset than deal with issues down the road.
Type checking in the editor and in the command line/CI is great together, but having only one, whichever it is, is miserable.
I mean, you still typecheck in CI and your editor (not just lints); you just don’t do it each time you run.
That would have been better, yes
I’m pretty happy typechecking javascript files with tsc + jsdoc.
Did you try Deno?
By no build I mean not running anything locally, just script tags.
I wonder if “a no build system” option is an attractive nuisance. We’ve seen a lot of systems where defaults set for developer convenience cause waste when they’re used in production environments. In some cases (probably not applicable to CSS), developer conveniences are even security risks.
I think Julia is making her decisions reasonably, and is well aware of the tradeoffs. For someone in her situation, requiring a build system really is a drawback. Still, I can see a maintainer who works with build systems all the time thinking that a no-build system option would just be handing people a way to shoot themselves in the foot. I can already imagine the HN and Lobsters posts about devs who are too careless to minify and tree-shake their projects.
htmx is an example of a JavaScript library without a build system (actually, with almost zero need for custom JavaScript). Highly recommend checking it out.
will this move nodejs developers to deno since deno doesn’t have a build process (at least for smaller, infrequently updated projects)?
If we look at the current moment as frozen in time, than, yes, absolutely, deno thoroughly solves the problem of “building projects”. However, at this point I don’t think it’s clear if deno (and even typescript) will be there in ten years.
Jvns is such a good writer
I use script src tags a lot. It works fine