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

191–200 of 224 posts

Re: You don't need a build step

#191

Post by justinclift »

Vaguely2178 wrote: post #179
edflsafoiewq wrote: post #171

Earlier quoted context omitted.

> When you ship js you can't guarantee the version of Ecmascript that the client will be running, or the standard library of DOM functions that will be available (which differ slightly from browser to browser), so you end up transpiling your code to the least common denominator. Isn't that the same as shipping native binaries? You don't know what version OS or libraries it will run on. That's why you do stuff like li…

The main difference between shipping a binary and a js file, is that users don't expect binaries to be small, which means you can usually ship an entire runtime with your binary. If you shipped every single js polyfill with your website performance would tank. You also generally differentiate between downloading a binary and running it, and users will tolerate a loading spinner while a massive binary downloads. Webpa…

> users don't expect binaries to be small

That seems to only be a "modern times" thing.

Prior to that, minimising the size of shipped programs (binaries, images, doc files, etc) has been important part of release management.

Re: You don't need a build step

#192

Post by kelnos »

pianoben wrote: post #170
falseassertions wrote: post #107

Earlier quoted context omitted.

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.

Conceptually, I don't see how this is much different from JIT compilers in the JVM, CLR, and similar runtimes. You don't hear so much from Java devs about how they can't* see the machine code their customers are running. They talk about cold-start performance, but accept that the first few requests will be slower in exchange for the productivity and eventually-high-performance. Now that I think about it, this is how…

The difference is that the JIT doesn't "fail". Builds and bundling can fail, and I wouldn't want to trust that all the machinery the builder/bundler depends on (especially if it needs to fetch things over the internet) are available and working properly.

Put another way, as long as the `java` command is present and working on the production machine, I can be pretty sure my service is going to run and work (aside from any bugs in my code, of course). With Deno, more moving parts on the production machine need to be working properly in order to ensure things work properly.

Re: You don't need a build step

#193

Post by kelnos »

simplotek wrote: post #158
dathinab wrote: post #149

Earlier quoted context omitted.

A good craftsman knows not to use bad tools.

> A good craftsman knows not to use bad tools. In your opinion, what's so wrong in prefering to just run your JS/TS code without having to maintain a build/bundling step? To me, Deno's approach is undoubtedly a killer feature with regards to the status quo of the whole nodejs ecosystem. Don't you agree?

Builders and bundlers fail sometimes. I don't want to introduce an extra point of failure in my production services.

Maybe this is nice for local development. But really it just feels like the tooling version of a "code smell". If people think bundling/building is too slow, then people should work on making that faster. Maybe that means people need to stop writing JS builders/bundlers in JS, and use a language like Rust that has better performance characteristics. I wouldn't consider that a failure; it's just an admission that we should use the right tool for each job.

Speaking of Rust, the Rust compiler is fairly slow, but my proposed solution wouldn't be "get rid of it and have it dynamically compile at runtime", it's "profile it and make it faster" (which people are doing!).

Re: You don't need a build step

#194

Post by whstl »

deckard1 wrote: post #134
whstl wrote: post #38

Earlier quoted context omitted.

There is an ES39 proposal to allow type annotations in Javascript, that would allow the browser to handle TS/Flow files without needing a compile step: https://github.com/tc39/proposal-type-annotations (That's only to allow the type annotations to be there, not to have static checking in the browser) IMO: I would love to see this implemented. Linting and typechecking should be ran before committing code or deploying,…

that sounds needlessly wasteful. You can trivially strip TS out of JS before sending off to the client. You're still going to need to check TS in the build/CI step (i.e. the time consuming part) before doing anything so you've gained exactly nothing.

"You can trivially strip TS out of JS before sending off to the client"

To quote you, that sounds needlessly wasteful to me. Also I prefer not needing to deal with SourceMaps or different source when debugging. So it's quite the contrary: I gain a lot. Different strokes for different folks.

Re: You don't need a build step

#195

Post by eyelidlessness »

xiphias2 wrote: post #77
eyelidlessness wrote: post #35

Earlier quoted context omitted.

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.

I don’t use Svelte of any kind so I’m possibly out of my depth, but I don’t know what I’d want to automate with import maps. I don’t think Deno addresses any use case like that but I’m hesitant to say so because I really don’t know what need I’m even addressing.

Re: You don't need a build step

#196

Post by phist_mcgee »

abraxas wrote: post #160
spookthesunset wrote: post #91

Earlier quoted context omitted.

I have to say, for some reason one of the more satisfying things to do is dramatically speed up a lengthy build. It’s hard to beat taking a build that runs forever and making it take a few seconds. I don’t know why. Perhaps it’s because it’s something you and your peers use constantly so when it speeds up the quality of life for all in the shop improves. I mean, it’s not often you get to make an improvement to your p…

To me that's a definition of make work. A good development ecosystem should require no wizardry to make it perform well. And it adds absolutely zero value for the end user of your product. This is why myself and 99% of developers abhor Rube Goldberg build systems like those that permeate JS.

A great craftsman will take care of his tools and seek to use the fewest number of cuts to achieve the desired result.

Improving builds/dev environments is taking care of your tools.

Also, citation needed on the 99%

Re: You don't need a build step

#197

Post by phist_mcgee »

tracker1 wrote: post #142
spookthesunset wrote: post #91

Earlier quoted context omitted.

I have to say, for some reason one of the more satisfying things to do is dramatically speed up a lengthy build. It’s hard to beat taking a build that runs forever and making it take a few seconds. I don’t know why. Perhaps it’s because it’s something you and your peers use constantly so when it speeds up the quality of life for all in the shop improves. I mean, it’s not often you get to make an improvement to your p…

Had similar issues with linting/formatting... switched to rome.tools a couple months ago and really happy with the change. I'm really looking forward to that project's goals too.

Hasn't rome had some dramas in the past?

I was under the impression that since it's such a large project, it is quite a risk to use it atm before it's fully ready.

Happy to be proven wrong.

Re: You don't need a build step

#198

Post by rwalle »

TheRealPomax wrote: post #188
cjblomqvist wrote: post #100

Earlier quoted context omitted.

I'm not sure what recent means, but I'm fairly sure (sorry, no references - only from memory) that it's been tested quite a lot, and also relatively recently (1-2 years?) by Evan (the guy behind Vite). Even with newer versions of http just transferring lots of small files is noticeably slower (few percent if I remember correctly).

A few percent of a second is a few milliseconds, so no worries there, that's at the very edge of "audio visual desync" perception. For huge bundles, of course, a few percent of a few seconds can hit 100ms or more, but even that's barely noticable compared to how long we're already waiting for the bundle to download. The bulk of the argument in favour of ESM in a "bundle vs ESM" comparison is in the cost of downloadin…

A few milliseconds if you live in a first world country, sorry.

Re: You don't need a build step

#199

Post by Vaguely2178 »

justinclift wrote: post #191
Vaguely2178 wrote: post #179

Earlier quoted context omitted.

The main difference between shipping a binary and a js file, is that users don't expect binaries to be small, which means you can usually ship an entire runtime with your binary. If you shipped every single js polyfill with your website performance would tank. You also generally differentiate between downloading a binary and running it, and users will tolerate a loading spinner while a massive binary downloads. Webpa…

> users don't expect binaries to be small That seems to only be a "modern times" thing. Prior to that, minimising the size of shipped programs (binaries, images, doc files, etc) has been important part of release management.

Binaries were definitely leaner in the past, but there's always been that dichotomy between downloading software and running it.

In the browser, users expect software to be available instantly, and that constrains how you build webapps. Users will tolerate the google maps app taking a few minutes to download, but they won't accept the google maps webapp taking several minutes to load in a browser.

Re: You don't need a build step

#200

Post by throwaway14356 »

I think new features move into the browsers pretty fast nowadays? The new stuff introduced is overly hipster. The old stuff still needs a lot of polish. We keep getting the means to do all kinds of new things but it (by lack of better words) progresses forwards. The sum of things adds up to greater things. The (almost) opposite approach is to look what people are doing then make a single thing that does that directly, without 100 weird steps. Update it to make it better just like modules do. Everything html does looks like it was slapped together in a weekend. If you look at the spec it is obvious a lot of work went in but the default behavior never fails to disappoint. Some examples out of hundreds: we wanted a range selector and a slider, we got a slider and they called it range. How do I do a range now and make it look the same as the slider? Oh, I write both from scratch? lmao Half of json's greatness is in how sad the xml tools are but if I compare both to sql I wonder how I get any work done at all! Imagine a form was just a json. Like json in and json out. Dynamically creating form fields and populating them from a deeply nested json, allowing the user to add fields, then trying to get the json toothpaste back into the tube was a truly hilarious adventure. I eventually just set the attribute value to the value of the form field then stored the html in the db. Did you know js has an xpath implementation? Not that one could use it but there it is. haha

I really think with some love we could just go back to writing html/js/css directly. Maybe it is just that I fail to see the point of nodejs.

Post reply on HN