“Implement text editor DOM updates manually instead of via React”

It's the closest thing we have to a general purpose, cross platform application engine that pretty much runs anywhere with a GUI interface (for anything updated in the past 3-5 years).

Browsers are more easily available on every major, and most minor platforms than any GUI toolkit out there... Things like atom, brackets and similar make sense. They translate well between standalone app in an OS, or a platform app for the likes of ChromeOS, or as a SaaS app in a browser.

No, they aren't the fastest, lightest or best performing. They don't even have the smallest codebases... what they are is broadly available, with minimal variance and a lot of developers with most of the knowledge needed to maintain them.

Using CSS magic tricks and JavaScript to make an unordered list appear like a menu or a toolbar just feels wrong, just as one example from many.

I liked the way XHTML was going to remove the semantic and pave way for proper components, sadly it never happened that way.

Anyone experienced with XAML and similar layout engines can see how much better the browsers could be, if people wouldn't insist into binding a document model into an application engine.

Even with HTML 5, which still is a problem to support properly across multiple devices without a "debug everywhere" attitude, has less widgets support than a 90's GUI.

I think developers are still a little shy about using the Canvas for much. In my own toying with a text editor, I found the Canvas to be pretty nice. The advantage is that one needs to render just the visible lines.

With the way developers use the DOM for things like text editors, it's no wonder that they may reach the limit of the browser performance. If we add too much stuff to the DOM, the browser does not have the flexibility of just "rendering the visible lines" like we could with the Canvas. The browser has to calculate everything again.

I was recently surprised when I added 100k table rows with 2 columns in a sample, and when I clicked on a button to toggle the visibility of some list items next to the table, the browser would take a few seconds to finish processing it. Since it was a sample test using React, I thought I would try it without React to see whether the slowdown was because of React somehow. But I found out that even without React it was about the same difference.

If you notice, Atom has a hard limit on 2MBs buffers. I just created a test loading almost 2 MBs in an Atom text tab, and it indeed became unresponsive. It took forever to load and then had problem handling text editing at the end of the buffer.

I think Atom would be better with Canvas. But many JavaScript editors use the DOM and for 1,000 lines they tend to work very well. Which is generally enough for running samples and such. Another advantage of the DOM is that they could more easily embed images and have varied size text, I guess. So those WYSIWYG HTML Editors may be better served by some DOM Editor.

I guess in the future Atom could also add a Canvas editor and keep both.

I think there may be a possibility of the terminal itself being slow. Years ago when I used semi transparent terminals in something like enlightenment it was seriously noticeable when you were trying to scroll through text and it'd take a while to appear. Then I switched to using a simple terminal like rxvt and no transparency effects under ion2 and wow was it fast.

So, perhaps the answer is that it's not the editor nor plugins that's slow in the scenario. I think the line numbering even causes some slight slowdown. Anything that actually parses text will obviously cause a performance hit too. I notice slowdowns when I use visual selection modes combined with tricky combos of commands. Even without any of that, it might be possible that the version of vim is doing something stupid like what happens when you open up a 1GB log file in less and hit G. Haven't run an strafe to understand the fseek calls being made but that's been painful without exception in my experience. Perhaps that's what the poster was recalling.

Didn't ST3's creator try to get 100k in a Kickstarter-like site to open source it, and failed? I seem to remember this.