Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Build is Always Broken

gbracha.blogspot.com

Post reply on HN
Print view View original

71–75 of 75 posts

Re: The Build is Always Broken

#71

Post by [deleted] »

SamBam wrote: post #67
Cthulhu_ wrote: post #37

Earlier quoted context omitted.

I understand where Webpack et al came from, but the more I work with it the less I like it. There used to be a time when the JS I wrote was the exact same that was executed. Now, even in development mode, it gets pulled through several tools (webpack/babel and a heap of their plugins, a minifier, source maps get generated etc) before my changes are visible, even in an incremental / hot reloading build. It's not just…

Which is fine, if you have no need of any dependency management (stick everything in script tags and reference globals), your script is going to be made up of only a few individual .js files (every one has to go in the header), and you have no use for JSX or TypeScript. For most people working on larger projects, though, the advantages of real dependency management (however broken NPM is) and transpiling JSX or TS is…

[deleted]

Re: The Build is Always Broken

#72

Post by jupp0r »

kevingadd wrote: post #24
jupp0r wrote: post #17

OP should take a look at bazel and reevaluate his opinions. Things like executing only tests when necessary, caching/remote executing everything and stellar cross language support make it easier than ever to rebuild the world every time.

(Can't tell if this is the joke) OP worked at Google as one of the creators of Dart so I assume he had a chance to encounter Bazel. Reading the post I got the feeling that these takes are partly informed by his encounters with die-hard Build System Believers.

No joke intended. From reading the article, where cmake and scons are criticized, my impression was that many of OPs concerns could be addressed by using something more fundamentally sound like bazel.

Re: The Build is Always Broken

#74

Post by Kinrany »

theamk wrote: post #69
Kinrany wrote: post #50

Earlier quoted context omitted.

I barely touched Smalltalk, but I think people value liveness as a feature for the user, not the developer. This is basically ultimate customization: you can change the source code of your local copy.

That sounds insane -- how do versions updates work then? One of the best parts of only allowing customization at well-defined points is that you can upgrade software and it is likely to keep working. Or is the Smalltalk idea that you never update your software?

You could integrate version control into the app and rebase the customizations onto the upstream changes.

At worst the user would have to rewrite their code from time to time.

Re: The Build is Always Broken

#75

Post by commandeer »

tobr wrote: post #52
skrebbel wrote: post #13

People love to complain about Webpack, but it pretty much does all of this out of box, all the way down to hot-reloading UI components. In that sense it's way ahead of all C++, C#, Java, etc build systems I know. Doing an `npm run dev` type of command in a reasonably set up JS project is very much this staged execution model the author talks about. Everything gets cached, on disk and in memory, only changes are recom…

I’ve never had anything close to this experience with Webpack. In my experience all the magic “it just works” of incremental updates and live reloading is extremely fragile and just gives up silently all the time in large-ish projects. Adding to that, it’s incompetent at what’s supposed to be its core feature: bundling JavaScript modules. I would count it among the least reliable software systems I have to work with…

I think what it does is amazing in terms of hot reload, etc. But yea, I always make sure someone on the team I am working on is a master at it, because some people are and some people aren't and if nobody on the team 'thinks' in the way webpack does, it can be terrible.
Post reply on HN