90s me would be absolutely floored by a text editor needing 438MB RAM.
Wait, what am I saying? 2018 me is pretty flabbergasted by it, but perhaps less surprised (and more cynical) than 90s me.
That isn't RAM, that's 438MB of drive space. Even the compressed zip download for Atom is bigger than would have fit on that entire hard drive (Atom 1.24 is 123MB zip download).
Though the RAM usage is pretty close, with no files loaded it was using 360MB RAM here.
Some was.
WinAmp came out in 1997, 2.x was released in 1998. Real time streaming media.
Visual Studio 6 came out in 1998, had most of Intellisense up and running. The refactoring stuff wasn't there yet, but it could do remote debugging.
The Windows APIs were obtuse, but incredibly well documented.
It'd take a long time before a lot of things we take for granted got commoditized though. A streaming video player (+ server) was still an idea that a billion dollar company could be founded on.
It wouldn't have been hard to write a Slack competitor then. It wouldn't have had streaming video, and the client would have been native, but you could have gotten 80% of the functionality in there, and watched as people still complained it was just a fancy wrapper around IRC.
Web forums sucked though. Slashdot figured out the right idea, the entire conversation loaded at once, one big page, it took the rest of the web a lot time to catch up.
20 years later, I'm writing code, managing files, and have a chat app or two open. The monitor is higher res, and a lot larger. Hardware plug and play finally works, and printing is, on Windows at least, pretty much a solved problem. (Heck even Wi-Fi network printer works almost flawlessly!)
The APIs for writing code have gotten easier to use, but it seems like everyone's documentation is now 5, small, steps above garbage. Also APIs break more often nowadays.
My computer has dozens upon dozens of services running, most of which I don't know what they are. And individual websites take up more RAM than my entire OS used to.
That last part isn't even a joke. To load a few paragraphs of text, hundreds of megabytes of RAM.
It is cool that web browsers can natively play video. 99.9% of the time I don't want them to. I kinda just want that paragraph sitting in the <div id="content"> </div> tag.
Related to GP's "Software was a lot less capable back then." - somehow, WinAmp 2.x seems to be peak capability of music players; I don't recall any player made later that would be comparable in features for playing local music (with maybe the exception of Foobar2000).
My rose-tinted glasses have some scratches on them, but I still maintain that software of today didn't gain many meaningful features over the late 90s / early 2000s, and yet it grown tremendously in size and resource use.
These days I'm using Foobar2000 and Quod Libet, and have looked at other "music library" type apps, but I'm considering just going with a simple player such as DeaDBeeF, and handle everything else through the file manager, since I've taken the time to properly plan the folder layout. I don't need ratings or playback statistics or all kinds of other things. I need a simple playlist to add music to, with basic playback controls. If I need to add tracks, I'll drag and drop from the file manager.
Basically, I don't need in-between applications between simple WinAMP 2.x style and the all-singing all-dancing streaming services such as Spotify, that do a much superior job with ratings and especially smart playlists.
In 1998, I was using the Internet Explorer COM embeddable COM object to build an IRC client where all of the text rendering was handled by the HTML renderer ¯\_(ツ)_/¯. (The reason why is the same as the reason I'd do the same thing today: because fancy text layout in a native app has always sucked and still sucks :/.)
Yes, you need more RAM to load a paragraph of text than an entire OS used to need, but what of it? How's that a meaningful comparison? WinAmp probably ate more RAM than entire OSes 25 years prior to WinAmp.
Also, while you might not be playing videos most of the time, those few times when you need it it's there for you just a click away and it's more efficient than ever before.
Yes, software is very bloated compared to software 25 years ago, but in spite of the efforts of crappy web-infused "desktop apps" like Atom, software today actually consumes less resources proportionally to the amount of computing resources available while delivering more, and also requires less power.
If WinAmp were to play your today's music files and if that were possible (which it isn't, unless you use antiquated audio formats), how much % of CPU would it use and how soon would it drain your laptops battery? My guess is it wouldn't fare very well.
I think this is true-ish.
But when I compare Blender (330MB) and 3ds Max (6GB) I got the feeling some software is just better constructed.
Using a web browser as a text editor might not be the best solution...
Exactly, TextMate and Sublime Text are both around 35 meg and both are close to feature parity for with Atom. It's only this more recent breed of software that is so absurdly bloated.
The most efficient software today is still built with the lower level mindset of conserving memory and increasing runtime performance (Browsers, Compilers, Vector Graphics, Games etc)
The simplicity of Win3.11 and Win95 was great, and that isn't just rose tinted glasses speaking.
This is a false dichotomy. Vanilla Emacs needs 38Mb on my machine, and it has all the tools you'd ever need to develop plugins for it. Visual debugger, byte-compiler, object inspector, jump to definition (including straight to C implementation when needed), visual font pickers, color palette, documentation browser & docstring viewer for symbol at point, you name it - it's all there.
Browser engines are not optimized for handling text editing. They are optimized for basically everything else but text editing. You can make them into kind-of OK text editors, but you have to put a lot of effort just to get to where text-editing frameworks are already[1]. And 200Mb of unnecessary code doesn't make getting there any easier.
To my mind, developing a text editor with a web browser is a bad technical decision. It may pay off in the number of devs available and eager to help - it may be worth it, I don't know, it's for the projects' leads to decide. Technically, though, these projects would be much better off with a text-editing framework.
[1] LightTable is a good example here. Well-funded, motivated team worked on it for a couple of years - and still failed to provide anything more than Emacs with plugins. Well, it looked a bit better.
There's a simple array of lines, a gap buffer, a BTree... No DOM, though. I wonder why... :)
Somehow I think it has more to do with developers not wanting to pay for software than anything else.
XAML coupled with Blend studio is a powerful UI design tool, or stuff like Adobe XD. HTML/CSS not really.
Right now Spotify is taking up 1 GB. VLC can play 4k with less RAM, what the hell?
To be fair, Lightroom and Photoshop have an excuse: dealing with 20+ MP photos is memory intensive. Atom doesn't: dealing with 2 MB text files is not hard.
Steam's minimum storage guideline says 70GB(!).
Not say Atom can't be more efficient, but I think this is often our field's "I remember when a cola was 10 cents".
From the OP:
> In Atom, the vast majority of computation of any given frame is spent manipulating the DOM, recalculating styles, and performing layout. To achieve good text rendering performance, it is critical that we bypass this overhead and take direct control over rendering. Like Alacritty and Xi, we plan to employ OpenGL to position quads that are mapped to glyph bitmaps in a texture atlas.