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

171–180 of 224 posts

Re: You don't need a build step

#171

Post by edflsafoiewq »

Vaguely2178 wrote: post #157
ashishb wrote: post #138

In other languages, devs build better tools for solving existing problems faster or easier. In no other language, build tools are so broken that the best tool changes every few years. In the JavaScript world, a significant chunk of energy is directed inwards, solving problems created by using JavaScript!

Very few languages operate under the same constraints as js. 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. You also have completely different performance requirements compared to most othe…

> 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 link with the oldest glibc you want to to support.

Re: You don't need a build step

#172

Post by moritzwarhier »

inglor wrote: post #135
moritzwarhier wrote: post #123

Earlier quoted context omitted.

Google apps always seem to stand out with an especially large amount of requests. Does Google use a proprietary module system for these runtime imports? I've only seen this from afar when using the Maps JS API.

This is the "don't download code you don't run" and "don't ask for data you don't need yet" with smart prefetching and caching. Mostly facilitated using an internal 3 letter framework in Google. If you want a de-googled approach for "only code you need" check out qwik by Misko Hevery who worked on a bunch f JS related things and a few others. The concept is "resumability". (not sure if that's what you entirely meant…

Thanks for the tip, I'll look at quik!

My only experience with the approaches you mention so far has been code splitting and dynamic imports with webpack.

Yes my example was a bit misleading as it's probably not specific to the maps JS API. Just remembered my casual observation of the network requests when embedding Maps using the JS API.

Also saw that there were lots of tiny cacheable requests and overall great performance.

Re: You don't need a build step

#173

Post by whstl »

pier25 wrote: post #130
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.

> Really the problem are all the frameworks pushing people to create a build step. I doubt it. People moved on from jQuery and/or vanilla because they needed to produce more sophisticated apps. And even in those days of yore, for any non-trivial project you still needed to concatenate and minify your code. BTW Preact can be used without a build step.

React and Vue can also be used without a build step. Vue shows how to do it in the "Quick Start" at the beginning of the tutorial. React can do it with an ugly syntax and no libraries, or by using Preact creator's htm library, or domz.

Re: You don't need a build step

#174

Post by pjot »

jstummbillig wrote: post #110

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?

As far as learning typescript, Deno is great in that it allows you to focus on typescript the language. Rather than the environment setup, config, compiling, etc…

Re: You don't need a build step

#175

Post by horsawlarway »

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?

Eh... I don't really think this is a killer feature.

If you don't want to maintain a build step, use a framework that's configured it for you and avoid customizing it.

Lots of frameworks already do that, this is just Deno's implementation of the same thing.

There's STILL a build step, they're running esbuild in the background for you. You've just lost visibility and control, exactly the same as if you picked a framework that gives you a default webpack config.

If anything, I see esbuild as the real "killer feature" here, since it's just really fast. Fast enough to bundle at request time.

Re: You don't need a build step

#177

Post by [deleted] »

geysersam wrote: post #119
andrewmcwatters wrote: post #109

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 w…

> 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. This is ridiculous. Just aesthetics. JS compiles to machine code when you run it "just in time". It's even relatively efficient considering it doesn't need static typing. The "build step" is just for reducing the size of the payload. It is possible a binary representation would make it even…

[deleted]

Re: You don't need a build step

#178

Post by Vaguely2178 »

hobofan wrote: post #166
ashishb wrote: post #162

Earlier quoted context omitted.

> The closest comparison outside of the browser would be to the container ecosystem And as someone who has worked on both, I can tell you that the container ecosystem is way better and way more deterministic. `Dockerfile` from 10 years back would work today as well. Any non-trivial package.json written even a few years ago would have half the packages deprecated in non-backward compatible way! There is another simila…

> `Dockerfile` from 10 years back would work today as well. I highly doubt that any Dockerfile from back then would work if it runs `apt-get` (as many do), as the mirrors for the old distribution versions aren't online anymore. Dockerfiles can be made to be quite deterministic, but many use `FROM` with unpinned tags and install from URLs that can and do go away.

Exactly! Dockerfiles are not deterministic. The build artifacts that they produce (images) are, but the same could be said of js build artifacts (which would be a set of compiled and bundled js files).

Re: You don't need a build step

#179

Post by Vaguely2178 »

edflsafoiewq wrote: post #171
Vaguely2178 wrote: post #157

Earlier quoted context omitted.

Very few languages operate under the same constraints as js. 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. You also have completely different performance requirements compared to most othe…

> 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. Webpack will emit a warning if any of your build artifacts are larger than 244KB, whereas a 244KB binary would be considered anemic.

Re: You don't need a build step

#180

Post by irrational »

spookthesunset wrote: post #91
kevingadd wrote: post #66

Earlier quoted context omitted.

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…

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…

And that is one of the main reasons I hate build systems. If I have to use a build system it had better work perfectly the first time and every time, never slow me down, and never ever require any fiddling or maintenance.
Post reply on HN