21–30 of 75 posts
Also, the more we incrementally patch a live environment the harder it becomes to specify what, exactly, is running in production.
Obviously even a compiler on a server can be caching and clever and not rebuild everything (if you use a source package manager like cargo then you may run into this, but if you have a binary package manager like nuget then you don't - each compilation unit is either required to build or it isn't, and external dependencies are always just fetched).
Is rebuilding everything from scratch on every build actually that common? If use use docker’s —cache-from flag on build, then assuming you’ve already pushed an image if you don’t make any changes on the part of the code that image is for you’re not going to actually rebuild that. That part of your build is just docker pull, build using cache, no changes so no work.
Depending on how clever the build system is, I have been burned by "build hygiene" in the past. Some would go so far as even nuking the source repository and cloning it again rather than updating or running "git clean" etc, to be absolutely sure that no a single byte was left from a previous build (Git is pretty good at this, but other version control systems not so much).
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.
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.
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…
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…
The hypothetical build system can, whenever files change, run the build again (in a container), execute tests (complaining when you break one), or let you keep the debugger open while you're editing (best attempt made to fast forward).
This is probably better suited for modern languages with proper modules and incremental builds, like Rust, C++20, Java9.
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'm not a web dev but used webpack some years ago. Is the issue not that webpack works fine once you finally get it working, and the complaints are about all the issues before it does?
Plus webpack got a lot better even in that regard, and there's alternatives like Parcel pushing the curve. Web devs sometimes don't realize how good they have it :-)
I believe many posts here miss the core point. The article is talking about _liveness_, i.e. modifying the program while it is running. One example of this would be Squeak[1]. Another perhaps more relatable one is modifying your HTML5 app from the browser console. [1]: https://squeak.org/
Not sure I understand the concrete suggestion here. When I develop I have "live" edits. (JS reloads, C# edit-and-continue, jvm hot reloading etc). But that's stile prone to being out of date, which is why there is a server that builds everything from scratch ensuring that we can reproduce it (as the local developers' edit loop sells those guarantees for speed). Obviously even a compiler on a server can be caching and…
I believe that's why he goes on about 'live-ness' which is a very smalltalk concept of a "live-image" of the running program. I doubt what he means is directly translatable to the Javascript world, although perhaps a running browser with JS in it can considered to be the live-image (like, say, the Clojurescript/React/Figwheel way of working).
But as you note, in the JS-dev world, very often you do need to reboot and start again (say if an external resource like a CSS has changed).
I believe many posts here miss the core point. The article is talking about _liveness_, i.e. modifying the program while it is running. One example of this would be Squeak[1]. Another perhaps more relatable one is modifying your HTML5 app from the browser console. [1]: https://squeak.org/
So why should I get excited about the ability to live edit when it's held up as bad practice in one of the few areas it's possible.