Builders and bundlers fail sometimes. I don't want to introduce an extra point of failure in my production services.

Maybe this is nice for local development. But really it just feels like the tooling version of a "code smell". If people think bundling/building is too slow, then people should work on making that faster. Maybe that means people need to stop writing JS builders/bundlers in JS, and use a language like Rust that has better performance characteristics. I wouldn't consider that a failure; it's just an admission that we should use the right tool for each job.

Speaking of Rust, the Rust compiler is fairly slow, but my proposed solution wouldn't be "get rid of it and have it dynamically compile at runtime", it's "profile it and make it faster" (which people are doing!).

Eh... I don't really think this is a killer feature.

If you don't want to maintain a build step, use a framework that's configured it for you and avoid customizing it.

Lots of frameworks already do that, this is just Deno's implementation of the same thing.

There's STILL a build step, they're running esbuild in the background for you. You've just lost visibility and control, exactly the same as if you picked a framework that gives you a default webpack config.

If anything, I see esbuild as the real "killer feature" here, since it's just really fast. Fast enough to bundle at request time.

Alternately, you can just stick close to standards and not really worry about it.

I write plain CSS.

I use Web Components as my unit of isolation, generally sticking with the light dom.

I have a small state utility [1] that I wrote years ago and works great.

I do have a build step before deployment, but I use vite during development so I have zero "make a change, wait, test, rinse, repeat" downtime. When it's time to deploy, vite build does the trick nicely.

I don't use frameworks. I don't use JSX. I don't use typescript, for types I use jsdoc in vscode which gives me 90% of the benefits of TS without the downsides.

My pages are light, fast and easy to maintain. I don't have to deal with painful build steps, or framework churn.

Debugging is simple. No multiple layers of transforms and sourcemaps, WYSIWYG.

I'm pretty passionate about the "keep it simple" philosophy.

I chose to innovate in the problem domain, not the technical one.

Anecdotally, I had a new developer join my team and he was initially very confused. He said "it's just so strange using this tech stack. You make a change, and you see it..."

I didn't know whether to laugh or cry.

[1] https://www.npmjs.com/package/applicationstate

My comment was more about the saying of the parents comment then specific to deno.

What I mean is that a good craftsmen doesn't complain about bad tool because they choose to use good tools (or more precise appropriate tools for the job) not because they ad-hoc easily negate any drawbacks of bad tools(1). And if they use bad tools anyway they do so intentionally or because there is not other choice and in turn don't complain because it's pointless to do so.

So the saying in the op comment is IMHO misleading at best deceptive at worst. Furthermore it doesn't advance any discussion, only side track it.

I'm sure the deno specific workflow from the article is a grate tool for a lot of use-case. I'm also sure there are use cases where it will fall apart.

(1): Depending on what you do creating a decent result without good tools might literally be impossible no matter how good your skill is. Or it might not make too much of a difference and can be compensated by skill, it's all context dependent, like most things in live.