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

101–110 of 224 posts

Re: You don't need a build step

#101

Post by LunaSea »

yoavm wrote: post #95
LunaSea wrote: post #92

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

That's quite a harsh statement... What's so bad about package management? And what's useless about the security harness?

> What's so bad about package management?

Hard coding URLs is significantly worse than having a package.json file:

- you don't need to write the full URL to import a module

- you have a quick overview of which modules are installed and for which reason (dev dependencies)

- you can easily create an immutable list of dependencies

> And what's useless about the security harness

Because most apps will have to enable all flags (file system and network) anyway and because huge security holes like symlinks breaking out of the harness were present not too long ago.

Re: You don't need a build step

#102

Post by llanowarelves »

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.

Try Deno anyway, if you haven't. The DX is very nice. I am very fast at cranking out small CLI tools -- and it gives binaries. Though sometimes I debate if Python is better for these tools, since it's so easy to get something going there too. For a JS maximalist stack, Deno no question.

Re: You don't need a build step

#104

Post by brundolf »

pseudosavant wrote: post #97
onion2k wrote: post #76

Earlier quoted context omitted.

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.

That is if you use import maps on the client-side. It wouldn't matter to the client if you are using it in your server-side JS/TS.

I believe Deno is doing this, though (could be wrong)

Re: You don't need a build step

#105

Post by KyleJune »

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

In addition to this, the bundle files generated at runtime are stored in memory in a Map. If you have a server and want to have multiple processes for handling requests, each of those processes will have a copy of the build artifacts in memory. Any requests that get routed to newly started processes will have their response delayed by however long it takes to generate the bundle. So users would experience seemingly random delayed load times due to runtime bundling.

I think it would be better to do bundling in your CI/CD. esbuild supports incremental builds, so using that + code splitting would be one way of speeding up builds.

With their current bundling design, if they believe bundling is fast enough for users to not be negatively impacted, wouldn't it also be fast enough to not slow down development/deployment by having it in a build step?

Re: You don't need a build step

#106

Post by andrewmcwatters »

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…

Maybe this is before your time, but there have been runtime minifiers/“builders” in the past. I remember them in the PHP days.

It’s not a new idea.

Re: You don't need a build step

#107

Post by falseassertions »

KyleJune wrote: post #96
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…

They are not using their own bundler. They are using esbuild at runtime to generate bundles for individual islands when the process starts up. Then they store those files in memory in a Map. When the bundle files are requested, it just pulls the copy that was generated at runtime. Here is a link to the source where esbuild is used. https://github.com/denoland/fresh/blob/main/src/server/bundl... I personally think it…

Man the things that pass for innovation in the node-adjacent space continues to blow my mind. It feels like hte horrors of /r/programmerhumor meets generic internet hype-beast cycles.

Re: You don't need a build step

#108

Post by andrewmcwatters »

yoavm wrote: post #95
LunaSea wrote: post #92

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

That's quite a harsh statement... What's so bad about package management? And what's useless about the security harness?

I have no comments regarding their dependency system.

But the security features are stupid on their face.

If you can’t trust your own code, why should users?

It’s too naive anyway. Why would I grant carte blanche to any entire feature instead of per dependency?

So Deno started with a bad idea, and then implemented it half-baked.

Which is it? Do you not trust your own code or do you? You don’t? Why not? Or why do you only trust a subset of it? If you do only trust a subset of it, why have you denied or granted the entire feature?

It’s useless. It’s one of the dumbest software features I’ve seen in my life.

Trust a dependency and pin its signature.

Re: You don't need a build step

#109

Post by andrewmcwatters »

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.

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.

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.

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.

Re: You don't need a build step

#110

Post by jstummbillig »

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/ts or rails I don't think it would move the needle in the slightest for me. It's simply not an issue outside of my brain finding beauty in any kind of optimization.

Is that all this is?

Post reply on HN