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

61–70 of 224 posts

Re: You don't need a build step

#61

Post by doodlesdev »

brundolf wrote: post #43
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…

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

> Transpiling TypeScript/JSX to browser-compatible JS.

Which is another way to say it's a form of compilation..... [0]

[0]: https://en.wikipedia.org/wiki/Source-to-source_compiler

Re: You don't need a build step

#62

Post by mdaniel »

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.

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

Re: You don't need a build step

#63

Post by Ygg2 »

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 rendering (usage of resource, time to first render).

Re: You don't need a build step

#64

Post by pphysch »

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?

It doesn't make a lot of practical sense, but basically they want to reuse substantial amounts of server code as client code. A fundamental misunderstanding of the client-server model, methinks.

Re: You don't need a build step

#65

Post by doodlesdev »

thegeomaster wrote: post #39
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…

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

Here is what Vite has to say about it. [0]

Take a look at a few optimization it's able to do that the Deno guys will never even be able to dream of (otherwise they will reinvent Node.JS lol) [1]. The worst part is that the guy who created Deno is the same person that made Node.JS, if you don't like NodeJS I'm not sure why someone would be betting all in another of his projects, specially considering second-system syndrome is real and painful [2]. Deno is already suffering from feature creep, just recently starting to support package.json, which I find hilarious. Soon they will reinvent CPAN [3] and believe they just hit into something extremely innovative.

Does reading about CPAN remind you of something? Something that could be the same for JavaScript? Like a package manager for NodeJS?

[0]: https://vitejs.dev/guide/why.html#why-bundle-for-production

[1]: https://vitejs.dev/guide/features.html#build-optimizations

[2]: https://en.wikipedia.org/wiki/Second-system_effect

[3]: https://www.cpan.org/

Re: You don't need a build step

#66

Post by kevingadd »

mdaniel wrote: post #62
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.

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. This regression had occurred without anyone noticing, because we all just assumed it was normal for 'build and bundle our typescript' to take a long amount of time despite how simple our code was.

Re: You don't need a build step

#67

Post by brundolf »

doodlesdev wrote: post #61
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

> Transpiling TypeScript/JSX to browser-compatible JS. Which is another way to say it's a form of compilation..... [0] [0]: https://en.wikipedia.org/wiki/Source-to-source_compiler

Yes, but it's distinct from bundling, which is what most of the GP's concerns were around.

Re: You don't need a build step

#68

Post by jamesgeck0 »

groestl wrote: post #58
whstl wrote: post #44

Earlier quoted context omitted.

No, they don't have to. Deno supports Typescript. And Typescript supports Typechecking without a build process. Linters, tests and other tools can also be run without a build process.

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.

Re: You don't need a build step

#69

Post by rakoo »

sixstringtheory wrote: post #57
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 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…

Because the need for a tool that bridges the impedance mismatch only hides the impedance mismatch even more, it allows developers to be even more remote from end users than before. It doesn't even start to question why we have an impedance mismatch in the first place. It keeps engineers in their position of those-who-know, and end-users in their position of those-who-need, preventing appropriation of technology.

As software engineers we ought to question if we're going in the right direction, and "more complexity" is not something I agree is better

Re: You don't need a build step

#70

Post by [deleted] »

groestl wrote: post #58
whstl wrote: post #44

Earlier quoted context omitted.

No, they don't have to. Deno supports Typescript. And Typescript supports Typechecking without a build process. Linters, tests and other tools can also be run without a build process.

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.

[deleted]
Post reply on HN