11–20 of 75 posts
This is one area where Electron really shines. For example, VS Code is a reasonably large project, yet one can make a modification and play with it within a couple seconds (~200ms to recompile the changes, a second or two to reload the window). I’d be curious if anyone here knows how InteliJ or Eclipse compares?
Aren't there native GUI toolkits for JavaScript too though?
[1]: https://squeak.org/
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 recompiled, and reloads are fast, partial, and often hot-swapped. It's quite close to the maximum level of "liveness" I can imagine.
It's kind of amazing how JS took over older and more established languages in this sense - and we're still not content (judging by how popular it is to complain about webpack). This is great.
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/
Modfiying web apps from the browser seems to be a rare case, interestingly. I think there were a forays[1] made in that direction, but the need for external tools to shoe-horn a half-shod module system onto JS was the final straw for that. Never mind the convenience of some nigh-essential language features (SCSS, ES6).
That's what drives me mad about all these configuration heavy (declarative?) systems. Just give me a debugger and an imperative language and I'll step through it myself when there's a problem. It's what is happening anyway so it's a really leaky abstraction.
What? Sometimes live or pseudo-live is helpful when programming or debugging, and therefore the whole concept of building software from scratch is invalid?
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/
At this point, you can either copy over the difference or just replace the whole production application. I'm not sure which would be faster.
I don't think liveness is important for a production system. I prefer production to evolve in discrete chunks. Liveness makes sense for development.
I suppose one other benefit of a live system is that you could deploy an update without without restarting the application. But at some level, you would be restarting part of the application, and you are just shifting the update logic from the networking layer to the function call layer or object layer or whatever minimal layer of swappable component you can deploy.
On the other hand, I would argue that the idea of a build is an entirely valid and useful construct, it merely represents a point in state space against which test cases (and production) must run. It is impossible to get away from that state. Some tools can make managing it easier, and some make it virtually impossible to manage. Imagine that we discovered a magical halting oracle and that we could compile everything instantaneously, we would still have to figure out what combination of states were valid, and we would call that the 'build'.