You don't need a build step

So basically Deno has its own bundler that lets you not have a local build step and it gets bundled dynamically per-route as requested by users, right? This is very different from industry standards and possibly has many new concerns from devs, none of which are addressed in the article since it&#x27;s treating the system as a perfect solution, which makes sense since it&#x27;s a marketing page (&quot;content marketing&quot;). If it was a 3rd party article, I&#x27;d be interested in things like:<p>- How do you measure bundle size and make sure it remains small? (e.g. make sure that a PR doesn&#x27;t accidentally import a massive dependency)<p>- How do you measure bundling speed&#x2F;performance, does it add significant time to the first request? To subsequent requests? Is it linear, exponential, etc. with the number of LOC? Again like in the previous point, how do we make sure there are no regressions here?<p>- How does this work, well, with absolutely anything else? If I want my front-end in React? Vue? etc.

I worked on JS infra for Google. One thing we found in this space is that when your apps get very large in terms of number of source files, there is a developer-impacting load time cost to the unbundled approach.<p>That is, your browser loads the entry point file, then parses it for imports and loads the files referenced from there, then parses those for imports and so on. This process is not free. In particular, even when modules are cached, the browser still will make some request with If-Modified-Since header for each file, and even to localhost that has time overhead cost. This impact is greater if you are developing against some cloud dev server because each check costs a network round-trip.<p>However this may only come up when you have apps with many files, which Google apps tended to do for protobuf reasons.

In other languages, devs build better tools for solving existing problems faster or easier. In no other language, build tools are so broken that the best tool changes every few years.<p>In the JavaScript world, a significant chunk of energy is directed inwards, solving problems created by using JavaScript!

I am perplexed by the focus on this. Clearly there are excellent devs working on Deno — but what setups are you running that the actual build is holding your productivity back? Developing in node&#x2F;ts or rails I don&#x27;t think it would move the needle in the slightest for me. It&#x27;s simply not an issue outside of my brain finding beauty in any kind of optimization.<p>Is that all this is?

The decoupling of URLs that host your dependencies and the URLs that host your application feels like an important uptime measure currently. If the URLs that host your dependencies go down in an NPM world, you can&#x27;t build and deploy new code but your app is still up. It seems, if the URLs that host your dependencies go down in a Deno world, your app goes down if those dependencies have not yet been cached (even on the server).<p>Am I missing something? This might not be terrible if it becomes the standard to host your own mirror internally.

I hate hate hate that modern web development requires a build system. No build system would probably get me to convert to Deno.

So Deno is relying on native ESM imports in production code? Isn&#x27;t that exactly what Vite _doesn&#x27;t_ do, because of poor performance?<p>When you run the vite dev server it uses ESM, but when you build it uses rollup, because serving ESM is slow and with larger apps the client browser is going to make a bazillion requests. Wouldn&#x27;t you rather traverse the dependency graph one time and bundle your code into modules so that everyone who visits your site doesn&#x27;t force their browser to do it over and over again? Sure those dependencies will be cached between views or refreshes, but the first load will be slow as shit, then you still need to &quot;code-split&quot;, just now you&#x27;re calling it &quot;islands&quot;.

My understanding of this is that this is trading a build step for just in time (JIT) compilation, which seems, ok? But it seems to me that you&#x27;ve just moved the problem around and I&#x27;m sure there are additional trade-offs (as with anything).

The history here is a little misleading. Client side bundling happened before node&#x2F;npm. It&#x27;s a performance optimization to reduce the number of requests the browser has to make. Typically people were just concatenating files. Concatenating was a painful dependency management challenge for larger code bases. Subsequently there were module systems like requirejs that also sought to fix some problems like these and ran without a build step in dev. Browserify really changed the perspective here and people started to think a build step wasn&#x27;t sooo bad.<p>I do think, based on the requirejs code that commonjs&#x2F;browserify didn&#x27;t really need to be compiled anyways.<p>Also fwiw, the technique mentioned here is a way a colleague and myself introduced babel to a large company as well, we just transformed + reverse proxy cached in dev. And fwiw, webpack basically does this anyways these days.

&gt; What exactly needs to happen to make server-side JavaScript run in the browser?<p>That sounds like an oxymoron to me. I have honestly no idea what they mean by that. To me, a browser is client-side software, so saying you want to run server-side JS on it doesn&#x27;t make any sense. They mention it several times in the article but I simply can&#x27;t follow.<p>Could someone with a deeper understanding ELI5 this to me?

Of course Deno has a build step. The difference is you don&#x27;t have to configure it and it happens on demand rather than aot.<p>It&#x27;s definitely an improvement but the title is misleading.

IMO, this post doesn&#x27;t discuss the tradeoff of removing the build step. What a “build” is has been obfuscated. When you deploy an app, you now need to convert TypeScript into JS, and then the JS needs to be turned into an optimal representation for V8 to process.<p>For example, Fresh has a “build process” whose cost is paid for by the user [1]. You want to do these things <i>before</i> the user hits your page, and that’s the nice thing about CI&#x2F;CD. You can ensure correctness and you can optimize code.<p>In the interest of losing the build step, a tradeoff is made for worse UX for developer experience (DX). Rather, I would recommend shifting the compute that makes sense to the build step, and then give developers the optionality to do other work lazily at runtime[2].<p>[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;denoland&#x2F;fresh&#x2F;blob&#x2F;08d28438e10ef36ea5965efc712b3d785b0a2aec&#x2F;src&#x2F;server&#x2F;bundle.ts#L15">https:&#x2F;&#x2F;github.com&#x2F;denoland&#x2F;fresh&#x2F;blob&#x2F;08d28438e10ef36ea5965...</a><p>[2]: <a href="https:&#x2F;&#x2F;vercel.com&#x2F;docs&#x2F;concepts&#x2F;incremental-static-regeneration&#x2F;overview" rel="nofollow">https:&#x2F;&#x2F;vercel.com&#x2F;docs&#x2F;concepts&#x2F;incremental-static-regenera...</a>

I&#x27;m certainly not the foremost expert in JavaScript build systems, but this just seems wrong.<p>Reducing build times (or eliminating the build step) by moving things to runtime is a great idea for a debug build&#x2F;mode. But why is it a good idea not to have separate release build to optimise for runtime performance?

<a href="https:&#x2F;&#x2F;github.com&#x2F;denoland&#x2F;deno&#x2F;issues&#x2F;1739">https:&#x2F;&#x2F;github.com&#x2F;denoland&#x2F;deno&#x2F;issues&#x2F;1739</a> just crossed 4 years. if they want people to do transpiling inside their own tool create an API so we can use our own tools rather than ones behind their black box.<p>Would be a much better use of their time than writing this nonsensical bs

&gt; And to be make your Fresh app more performant, all client-side JavaScript&#x2F;TypeScript is cached after the first request for fast subsequent retrievals.<p>My understanding is that the client side JS is a result of backend compilation. How does this work if the backend is dynamically generating those JS files? `getPosts()` can return a different JSX based on what `getPosts()` returns. No?

They make you read an entire article about how bad build steps are, only to present you with the (no less appealing) alternative of JIT compliation with URLs. This does nothing to improve the &quot;sea of dependencies&quot; problem they spent so much time pointing out as a bad thing.

I&#x27;m not sure why so many are interested in not having a build step. You&#x27;ll still want to have a step that runs typescript to check for errors, a linter, maybe your tests and other stuff.<p>Or do people just want to YOLO it and let it crash in prod?

Deno didn&#x27;t have a structure that caught my attention in its early stages. But now i see it going in the direction i need logically. I guess I need to start experimenting with a side project.

I think new features move into the browsers pretty fast nowadays? The new stuff introduced is overly hipster. The old stuff still needs a lot of polish. We keep getting the means to do all kinds of new things but it (by lack of better words) progresses forwards. The sum of things adds up to greater things. The (almost) opposite approach is to look what people are doing then make a single thing that does that directly, without 100 weird steps. Update it to make it better just like modules do. Everything html does looks like it was slapped together in a weekend. If you look at the spec it is obvious a lot of work went in but the default behavior never fails to disappoint. Some examples out of hundreds: we wanted a range selector and a slider, we got a slider and they called it range. How do I do a range now and make it look the same as the slider? Oh, I write both from scratch? lmao Half of json&#x27;s greatness is in how sad the xml tools are but if I compare both to sql I wonder how I get any work done at all! Imagine a form was just a json. Like json in and json out. Dynamically creating form fields and populating them from a deeply nested json, allowing the user to add fields, then trying to get the json toothpaste back into the tube was a truly hilarious adventure. I eventually just set the attribute value to the value of the form field then stored the html in the db. Did you know js has an xpath implementation? Not that one could use it but there it is. haha<p>I really think with some love we could just go back to writing html&#x2F;js&#x2F;css directly. Maybe it is just that I fail to see the point of nodejs.

Sounds to me like we&#x27;ve round-tripped back to PHP, circa 2009. Bout time!

I tend to stick with script tags as much as I can. Really the problem are all the frameworks pushing people to create a build step. Their excuse is optimising the code size, but for most cases that matters little, I don&#x27;t mind including all of tailwind or font-awesome.<p>So please, if you own a framework like this, make sure a script tag with a CDN link is easily copyable.

This article is spot on. As a developer, I don&#x27;t want to see the build step. As soon as you expose the mechanics of the build and transpilation process to developers, you add a ton of complexity; for example, it opens up the possibility of transpiler and JS engine version incompatibilities. Devs should only need to concern themselves with one number; the version of the engine which runs their code. If they need to worry about the engine version and the transpiler version separately, it makes code less portable because you can&#x27;t just say &quot;This library runs on Node.js version x.x.&quot; It sucks to come across a library which works on your engine version but relies on a newer version of TypeScript... It&#x27;s like hoping for the planets to align sometimes.

The dumbest thing about people building JavaScript to me is that you burn all of the energy and labor of building with almost none of the meaningful benefits.<p>No one is building and ending up with bundles that are reducing the bloat of the web, you can’t tree-shake your way out of bad practices. Articles and real lived experiences show us that the web is still bloated.<p>And why are we transpiling anything? If people want to flirt with building, I wish JavaScript engineers would just build an implementation that compiles to machine code intermediate representation.<p>Which is it? Do you want to be a scripting language or a programming language that compiles to something? It’s so gross to me.

Pretty sure we were building code to validate it and unit test it before releasing it.<p>This article is strictly about JavaScript. What about all the server-side rendering frameworks?<p>Huge assumption that everything is built one way.

Great clickbait title, makes people wanna jump in the comments and say the OP is wrong.<p>I mean if we wanna get really pedantic about it then yes there will always be a build step no matter what you do, one could argue saving the file and alt-tabbing to the browser is a build step, but that&#x27;s not the point is it? The idea is to lower that friction as much as possible and JIT is perfect for that

I thought this will be an article about adding import maps to deno, which would be great.<p>I hope builders start adding it (at least to dev instances) to decrease the magic.<p>I was trying to use import maps, but it&#x27;s not trivial go create actually.<p>There are always problems with Node lagging behind browsers though that makes developing hard (no WebSocket support by default for example, crypto module is also not included)

Regardless of if Deno solves or not the issue, this article clearly depicts how broken the entire user experience is.

Putting JS in the backend was a tragic mistake born of laziness and ignorance. It should not be a surprise that everything else that followed suffers the consequences of these root traits as well. JS was barely acceptable when it was caged in browser-land, and we&#x27;d all be better off had it stayed there.<p>FE development has some unique challenges, but in my experience a lot of people who work in this domain try to find their own solutions to problems that have already been solved decades prior. There&#x27;s a reason the build chains are fragile and a nightmare to configure, that package lists are out of date the moment they&#x27;re published, and that it takes a sustained effort to maintain a project viable even if you&#x27;re not adding features or fixing bugs. It&#x27;s absurd, and it&#x27;s the status quo.<p>To take this into other areas of development (like BE for example) simply because that&#x27;s what you&#x27;re familiar with... it really is a special kind of masochism.

So, if I&#x27;m using URLs for dependencies, effectively I can&#x27;t code while I&#x27;m offline? I know it&#x27;s not the norm, but there have been plenty of times I needed to work without internet.

sure these framework may do just in time transpilation and compression, that doesn&#x27;t mean you don&#x27;t have a build step.<p>copying the code to the server becomes the build step.<p>except now you have no chance to lint the code before shipping it<p>&quot;but I can lint it on my machine&quot;<p>good, then you have a build system, and you may as well just get the optimized stuff on the server, since server startup time depends on your code size at some point or another, and you pay for that.

&gt; [graph]<p>&gt; Interest in Node.js grew since its inception.<p>They should mention the source of this, I guess is Google Trends.

Maybe they could add a new transpiled language as well, like Civet[0] or ReScript[1]. Not every project needs to be a C#&#x2F;.NET clone in TypeScript :)<p>[0] <a href="https:&#x2F;&#x2F;civet.dev&#x2F;" rel="nofollow">https:&#x2F;&#x2F;civet.dev&#x2F;</a><p>[1] <a href="https:&#x2F;&#x2F;rescript-lang.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;rescript-lang.org&#x2F;</a>

certainly, in terms of writing scripts, deno seems nicer. Like, if I want to write typescript that just runs and does something, without having to carry around a node_modules folder, etc, deno seems like it might be nice

Deno is the &quot;these go to 11&quot; of the Node.js world.<p>Creating a whole fork simply to not build TypeScript, reinvent a worse package management system and a useless security harness.

Yes JIT building on route request sounds super non-wasteful and better. &#x2F;s