Comment by wtallis | Hacker News Reader

Comment by wtallis | Hacker News Reader

Parent Full thread

> Wasn't the whole OSX's new paradigm a switch to high level language and frameworks , with compositing window management to display super fancily rendered hello worlds ?

No, not really. You're making it sound like Classic MacOS applications were written in assembly, when it was mostly C++. Switching to Objective-C was more of a lateral move, not a clear step forward in time or level of abstraction.

The Mac OS X graphics stack was a pretty big change from Classic MacOS, but it wasn't that much of a change from NeXTSTEP, which worked with 12MB of RAM + 1.5MB VRAM. NeXTSTEP just wasn't as eye-catchingly colorful. Early OS X did poineer gratuitous use of some effects like translucency with blurs in desktop GUIs, but since this was the time period where GPUs were becoming mainstream, these effects weren't egregiously resource-intensive.

And considering that OS X was adapted with relative ease to power a smartphone with 128MB of RAM (with the graphical effects turned up to 11), it definitely wasn't fundamentally bloated in the way that today's Electron apps are.

Many Obj C libraries were a wrapping layer on top of the Carbon APIs and in terms of abstraction Obj C is also a level above C++. Passing everything as messages is an additional layer of indirection.

NextSTEP itself was a big change compared to X or Windows's GUI stack. NeXT machines were beefy and adjusted to high workloads so the user experience wasn't problematic, but it's still more resource use than the standard stacks of the time. I don't see it as a bad thing, but we should acknowledge resource economy wasn't a target of the neither NeXT nor Apple at that time.

> 12MB of RAM + 1.5MB VRAM

NeXT launched in 1988, basically around the times when "640k should be enough for everyone" was a meme. Even in 1996, 12MB of RAM was nothing to sneeze at. So, sure those are not enormous numbers, but they're far from the lower end of what was sold to consumers at the time.

> smartphone with 128MB of RAM

We should take a minute to note that 128Mb or RAM is not small for a phone at the time.

Otherwise, sure electron apps use a lot more than that, but the point was always to pay for powerful hardware and use it at full potential to run fancy apps. People loathe electron apps' bloat, but ease of development has also always been one of the core values. Better have apps that aren't fully optimized than no apps at all.

Electron’s bloat and power consumption wouldn’t bother me so much if the performance was actually good on a fast machine. But the experience is awful compared to a native app.

My guess is that Slack for instance would never make a full blown native client for macos. If it wasn't electron, they'd probably have gone with Mono or another cross platform stack, and we'd see performance lag and memory bloat compared to a handcrafted native app.

I say that looking at macos' pretty big market share compared to what it was a decade or two ago.

And we see tons of users choosing VSCode or IntelliJ's offering above Textmate, Codea, or even BBEdit, so the market for handcrafted delightful editors is also pretty slim. And that trend was there since the Eclipse days, so nothing new either.

All in all, I really think the choice comes down to electron/cross compiled apps or no apps, in many many cases.

I think Sublime Text does a good job of being both good and cross platform.

But yes I also remember the days when lots of software just didn’t exist for macOS and I was thankful for a webtech version.

Reply on news.ycombinator.com