Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You don't need a build step

deno.com

Post reply on HN
Print view View original

21–30 of 224 posts

Re: You don't need a build step

#21

Post by kamikaz1k »

mattlondon wrote: post #10
franciscop wrote: post #6

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.

Fresh supports islands, so it also does send JavaScript for the interactive bits. If you have a react (default is preact) island then that'll be bundled and sent down.

Re: You don't need a build step

#22

Post by hbn »

dom96 wrote: post #4

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't mind including all of tailwind or font-awesome. So please, if you own a framework like this, make sure a script tag with a CDN link is easily copyable.

Are you talking about the CDN version of Tailwind? If so, the docs specifically say that's not for production use.

A lot of very useful features require a build step because it generates classes on the fly based off what you typed in the HTML.

Re: You don't need a build step

#23

Post by vhiremath4 »

qbasic_forever wrote: post #15
vhiremath4 wrote: post #7

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'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 th…

Deno caches your dependencies locally. If you are building something that demands high availability you probably want to host the dependencies yourself though. Which is easy, you just copy them and serve them as static files (assuming their license allows that use).

Dope this answers my question. Honestly as I've become a more seasoned developer, I've increasingly come to appreciate the utility of mirrors for build systems too.

It's not always simple in every module system though. Currently, I want to figure out how to create a mirror for our Electron codebase, but it's tough because some of the modules fetch gyp native headers that live in other locations (including the Electron core packages themselves) and NPM doesn't always know what to do. The Electron core header URLs flake every 2-3 weeks or so and inevitably we lose a lot of engineering time.

Hoping Deno continues to gain steam and makes this simpler since everything is URLs all the way down.

Re: You don't need a build step

#24

Post by kamikaz1k »

kldavis4 wrote: post #12
dboreham wrote: post #8

Earlier quoted context omitted.

"Build" in JS circles usually means transpile, not a replacement for JIT which will still happen at runtime. In addition to that, often there are other concerns addressed at build time such as linting.

yeah, exactly. So I wonder if ultimately they want to have the browser handle transpiling things like typescript? And I definitely think there are other concerns (such as linting) that you want to happen as part of your development pipeline.

Browser doesn't transpile, and if you're transpiling in the browser in your own JS, you're doing it wrong...generally

Point of transpiling is improving DX, so it has no business being done during users browser render.

Re: You don't need a build step

#25

Post by elondaits »

dom96 wrote: post #4

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't mind including all of tailwind or font-awesome. So please, if you own a framework like this, make sure a script tag with a CDN link is easily copyable.

The reason for bundling is converting potentially hundreds of individual script files to an amount that’s more manageable with a browser, without suffering a cost from latency… not only optimizing code size. Also, besides tree-shaking there’s a big saving from minimization and removing development-only code.

Re: You don't need a build step

#26

Post by djrenren »

vhiremath4 wrote: post #7

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'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 th…

Dependencies in package.json are essentially just links to the npm CDN. (admittedly with a constraint solver in front that determines the exact link to use).

`npm install` is equivalent to `https://deno.land/manual@v1.31.1/tools/vendor` in that they both fetch your dependencies and store them locally, so your app can run without downloading the deps.

The just-in-time builds section of the linked article describes an approach where you dynamically bundle, at request time. If your server already has all the deps vendored then it won't need to fetch them at runtime and your app will stay up even if the URLs go down.

Re: You don't need a build step

#27

Post by codemonkey-zeta »

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 that everyone who visits your site doesn'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 "code-split", just now you're calling it "islands".

Re: You don't need a build step

#28

Post by kldavis4 »

kamikaz1k wrote: post #24
kldavis4 wrote: post #12

Earlier quoted context omitted.

yeah, exactly. So I wonder if ultimately they want to have the browser handle transpiling things like typescript? And I definitely think there are other concerns (such as linting) that you want to happen as part of your development pipeline.

Browser doesn't transpile, and if you're transpiling in the browser in your own JS, you're doing it wrong...generally Point of transpiling is improving DX, so it has no business being done during users browser render.

Sorry - I miswrote that - I meant the browser directly compiling (JIT) typescript

Re: You don't need a build step

#29

Post by silviot »

codemonkey-zeta wrote: post #27

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…

Deno is an alternative to node and npm. You can have a Deno http server serving content to a browser. But the browser won't care how the server runs, as long as it can speak HTTP.

You can also use Deno to run your bundling tools, but again, what happens in Deno stays in Deno and does not reach the browser.

Re: You don't need a build step

#30

Post by TheRealPomax »

codemonkey-zeta wrote: post #27

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…

That sounds like an assumption that's not actually been tested recently. Downloading a 2MB bundle or 100 separate files is an equally poor experience, but the separate files at least let you download only the parts that changed over time, instead of having to download a completely new 2MB bundle every time someone changes a single letter in one of 100+ files and a new bundle with a new integrity digest gets rolled out.

I'd rather have an equally slow experience on first load, and then much better performance forever, compared to having something that constantly invalidates the entire cache.

Post reply on HN