Live data from Hacker News

You don't need a build step

deno.com

71–80 of 224 posts

Re: You don't need a build step

#71

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's treating the system as a perfect solution, which makes sense since it's a marketing page ("content marketing"). If it was…

From the article: "Fresh renders each page on the fly and sends only HTML" So the bundle size is zero.

> unless an Island is involved, then only the needed amount of JavaScript will be sent as well

It's not just HTML but also JS that gets sent.

Re: You don't need a build step

#72

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

> I hate hate hate that modern web development requires a build system Why? For any sufficiently complex software system, a build system serves as a reducer whose input is something that is more convenient for developers, ie huge codebase with tons of utilities and annotations, and whose output is something more optimized to run on the end users' devices. It's good to do such optimization because there will be, at le…

> Why?

Having to manually kick off a build process is another thing that I have to go do that takes me out of the flow and is another point where things can go wrong.

When you run a Deno script, it has a build step that it does internally, so I don't have to think about it, and I don't have to configure anything. It just works because it was designed that way. I don't know why more language runtimes aren't.

Even when I want to compile a JavaScript bundle to run in the browser and there is an explicit build step, `deno bundle` is far simpler and more pleasant to use than the mess of npm packages I would have to worry about in the Node world.

Re: You don't need a build step

#73
post #2

> And to be make your Fresh app more performant, all client-side JavaScript/TypeScript is cached after the first request for fast subsequent retrievals. 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?

(At least in React) the JSX gets transpiled to function calls, which are then run at render time with a particular set of data. That first transpilation step will always come out the same and can be cached.

Re: You don't need a build step

#74

So Deno is relying on native ESM imports in production code? Isn't that exactly what Vite _doesn't_ do, because of poor performance? 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't you rather traverse the dependency graph one time and bundle your code into modules so tha…

I think this is actually because esbuild doesn’t support everything needed in their production bundle (well controlled/grouped bundles) while it’s excellent for dev where there’s no such need. I can’t remember where I read it, I think it’s in the official docs.

That's indeed correct [0]. esbuild is still a bundle though, so it wouldn't change much other than (much) faster production builds.

[0]: https://vitejs.dev/guide/why.html#why-not-bundle-with-esbuil...

Re: You don't need a build step

#76

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's treating the system as a perfect solution, which makes sense since it's a marketing page ("content marketing"). If it was…

It sounds like (it is a little vague) there is no bundling at all, the only thing Deno does magically at request time is transpiling TypeScript/JSX to browser-compatible JS. Beyond that I think the idea is it relies on native ES module imports (and import-maps), both of which are browser standards

both of which are browser standards

ES modules have great support but import maps don't. Your website won't work on iPhones if you launch with them today. They're close though. Give it a month and it should work.

Re: You don't need a build step

#77

I thought this will be an article about adding import maps to deno, which would be great. I hope builders start adding it (at least to dev instances) to decrease the magic. I was trying to use import maps, but it's not trivial go create actually. 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 include…

Deno does support import maps out of the box. For Node there’s a loader[1] you can use (though a glance at the GitHub issues suggests it’s incomplete). 1: https://www.npmjs.com/package/@node-loader/import-maps

Does it generate import maps for me automatically? That's the hard part.

I'm using Vite with Sveltekit, which is great because it compiles files separately, but still doesn't generate import maps, but uses imports with relative and absolute filenames.

Re: You don't need a build step

#78

So Deno is relying on native ESM imports in production code? Isn't that exactly what Vite _doesn't_ do, because of poor performance? 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't you rather traverse the dependency graph one time and bundle your code into modules so tha…

HTTP/2, which is getting pretty widespread now, mitigates most of the concerns about making a bazillion requests.

h2 makes individual requests cheaper. However, if you have a waterfall of dependent resources where some must be fetched after others, you’re still waiting out the roundtrip for each edge in the longest chain. Which developers working and living 10ms from the data center usually don’t give a shit about.

Re: You don't need a build step

#79
IMO, this post doesn'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.

For example, Fresh has a “build process” whose cost is paid for by the user [1]. You want to do these things before the user hits your page, and that’s the nice thing about CI/CD. You can ensure correctness and you can optimize code.

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].

[1]: https://github.com/denoland/fresh/blob/08d28438e10ef36ea5965...

[2]: https://vercel.com/docs/concepts/incremental-static-regenera...

Re: You don't need a build step

#80

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

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

I feel the same about C and C++. And Java. And Fortran, Pascal, Lisp, Kotlin, Swift, Rust, Forth...

Post reply on HN