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

81–90 of 224 posts

Re: You don't need a build step

#81

Post by brundolf »

onion2k wrote: post #76
brundolf wrote: post #43

Earlier quoted context omitted.

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.

Fair. I wonder if Fresh includes some kind of polyfill for those (or maybe the transpiler factors in which browser the current request is being made from?)

Re: You don't need a build step

#82

Post by groestl »

jamesgeck0 wrote: post #68
groestl wrote: post #58

Earlier quoted context omitted.

What exactly is "a build process" for you. For me, it is a process which results in an artifact. An artifact that is, in the best case, automatically tested, optimized, signed, and ready to be deployed. Compilation is a rather small part of it. But since I need to run all the other things anyway, why not compile there, and remove entropy from runtime.

"build process" is defined in detail in TFA. You're arguing about something so entirely orthogonal to the point of the article that I can't help but wonder if you've actually read it.

I did read it, and I find the title misleading.

Re: You don't need a build step

#83

Post by robust-cactus »

The history here is a little misleading. Client side bundling happened before node/npm. It'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't sooo bad.

I do think, based on the requirejs code that commonjs/browserify didn't really need to be compiled anyways.

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.

Re: You don't need a build step

#84

Post by explaininjs »

onion2k wrote: post #76
brundolf wrote: post #43

Earlier quoted context omitted.

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.

Based on https://www.digitalocean.com/community/tutorials/how-to-dyna..., aren't import maps a massive step back in the world of tree shaking? It would seem every export needs a dedicated file for it or else you get the whole world when you try to make a single request. (And better hope that single file doesn't import any other ones!)

Re: You don't need a build step

#85

Post by Existenceblinks »

irrational wrote: post #48

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

I'm ok but please set the config docs cap to 1 A4 size. It should cover 80% of application with zero config. 90% with config. 99.8% with plugins.

Re: You don't need a build step

#86

Post by thex10 »

kevingadd wrote: post #66
mdaniel wrote: post #62

Earlier quoted context omitted.

Fun fact: the "compilation" step in my company's React project is the biggest consumer of CI minutes by far across our entire organization, beating out every one of the Maven compile and test loops But, since the devs don't care, there's only so much finger wagging I can do

Over the course of a month or two the time taken to compile a single .ts file in our codebase climbed from 'too small to measure' up to '7 seconds'. It eventually turned out that a single type definition in the file was causing all typechecks to become incredibly slow. Getting timing data out of build tools like rollup was brutal, and editors with tsc integration like vs code/sublime text would just lag and misbehave…

> It eventually turned out that a single type definition in the file was causing all typechecks to become incredibly slow

I've love to read a blog post about this.

Re: You don't need a build step

#87

Post by thex10 »

rsp1984 wrote: post #54

> What exactly needs to happen to make server-side JavaScript run in the browser? 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't make any sense. They mention it several times in the article but I simply can't follow. Could someone with a deeper understanding ELI5 this to me?

Full stack devs working with JS on the backend love to be able to reuse their code on front and back end when desired. This question is relevant to them and them only.

Re: You don't need a build step

#89

Post by agumonkey »

Ygg2 wrote: post #63
rsp1984 wrote: post #54

> What exactly needs to happen to make server-side JavaScript run in the browser? 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't make any sense. They mention it several times in the article but I simply can't follow. Could someone with a deeper understanding ELI5 this to me?

A bit simplistic of a take, consider games. First client server games made server deal with logic, exclusively. Modern (post Quake) games make server authoritative but allow server logic to run locally. What modern JS app do is something hybrid client/server rendering. It's akin to moving/transmitting code from server for faster rendering. I think they use it for offline web apps and to fix problems with server side…

We're going to have locality optimizing migrating code.

Re: You don't need a build step

#90

Post by paxys »

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…

You can cache all dependencies in one go whenever you want. It doesn't have to be done in real time when the code is run.
Post reply on HN