Seems like Atom will eventually just be a native app.
"Hey, let's write an editor for a browser. Oh wait, we need a browser for that editor".
Something good will probably come out of this eventually. I mean if they manage to turn electron into a true native cross platform app framework it's nice.
…then you’ll end up back where you started with the JVM.
To be more clear, no one is writhing in their sleep, or bemoaning to their team mates, this: "We have no good way to edit text in the 21st century". No one. At best, it's a nice idea to see "what if" we could build an emacs-like text editor using modern day web technologies, just to see what browsers and HTML5, etc, can do these days, and hey, maybe we will learn something and push the browser technology a bit, too. At worst, it's bunch of people with no other interesting ideas and who need to bring attention to their company.
What's next for this Electron crowd? Let's see if we can build a whole operating system into a browser? Oh wait. That's also been done with a lot of noise and no real-world impact. Well then, what about a new kind of spreadsheet? Or maybe we could do some cool photo-processing using only a TI-84 calculator!
Ugh. I'm so tired of this, and this massive post by the dev team at Atom proves the insanity of all this.
They have spent thousands of man-hours "improving" their text editing rendering for their slow text editor (but hey, we saved time by building it on top of Chrome!), and yet they are nowhere near text-rendering speeds of 40 years ago.
But never mind that. They will continue to plug ahead and write more posts about it. Meanwhile, emacs (and Vim) plug along as always.
How bad is it (to me)? I'll tell you. Even though I alter between Sublime (written in real code and not on 'borrowed' code) and BBEdit sometimes, along with Vim (still learning), and even MacVim (the horrors!)... THIS is how bad it is. It's so bad... that I would use TextEdit to edit code before I used Atom. I promise you. I actually like TextEdit and often use it anyway. I sometimes wish Apple would just add a few tiny improvements (but I'm daydreaming) and I would use it for 90% of files and projects.
But Atom? Like a lot of modern day projects (React, Bootstrap, WordPress, Facebook, etc), it's a total step backwards to reinvent what we already had. So that basically "new" people can come along and play - with less understanding, IMHO.
You'd think that hundreds of thousands of Atom users would convince you that maybe there's something to the editor that works for others if not for you. But nope, all those guys are happy with switching their main IDE to "a total step backwards", for some reason.
Cargo cult is the reason.
Large files, slowish startup, and the like are all special case problems that I can use Sublime for, but until now, the almost subliminal typing sluggishness always drove me away.
Bravo Atom team for making it fast enough. I look forward to continued improvements in this space.
Their integration for TypeScript and GoLang are first class as well. Overall though I held the same excitement for Atom as you did (and I used to use Emacs for everything because I wanted an open editor in my tool belt) I've really come to appreciate the approach and polish of VSCode.
An editor that is not "hacked" together on idiotic technologies ("web" "dev"), but a well designed editor, written for performance, on top of the best technology for that specific job.
That's why emacs has existed for decades now.
This is a perfect example of why we need parallel restyling. :)
Is it worth restricting an editor to only styles that don't influence block layout? For example, should it be impossible for a theme to make comment lines taller or shorter? I don't know; it's a tradeoff between performance and flexibility. My feeling is that there's a lot more room to improve the implementation before we have to resort to reducing capabilities, but reasonable people can disagree.
This is exactly what people used to do to optimize drawing in intensive application. You only render the visible area. The entire post explains the supporting actions needed to accomplish this for the browser. Thats why at the end of the text they talk about exploring the use of the canvas.
Here's an application from ~2000 https://www.macintoshrepository.org/2214-vncthing
The actual VNC canvas was offscreen and it would only frequently display the entire thing. Which made it for a long time more efficient than modern vnc clients. I think 2010 it was still better than any other VNC client on macosx. It's by far not an uncommon technique, it's just a pain to do when your target is markup, which is what this post is all about.
Granted, it's more complex because a tile here is a chunk of markup rather than a piece of a pixmap, but still.
