Comment by albiabia | Hacker News Reader

Comment by albiabia | Hacker News Reader

Parent Full thread

Anyone who has ever looked at the DOM structure of an in-browser code editor (CodeMirror, Ace) knows that they are extremely nasty. So much overhead. The markup characters outnumber the content by like 50x. While the speed of Atom is much better than I expected, it just doesn't feel native enough. I still feel like I'm using an in-browser editor.

Maybe Sublime has spoiled me, but that editor is pretty fast. It can open large files. It's almost as extensible, especially for any kind of practical purpose. Oh and it's cross-platform, which Atom is not at the moment.

I also can already see a time when we reach Atom package hell. Someone is going to have to come up with a system to manage all these packages pretty quick. When you are literally installing packages to add a single hot-key, and all packages are treated as equals, it quickly becomes very difficult to find what you are looking for to manage your install.

I'm excited and optimistic to see where Atom will go, but my thoughts before I tried it are only reinforced after a few days of use. GitHub does not mess around. I know they will fix most of my concerns pretty quick, but I'm not sure how much more can be done about performance.

In my few reviews of the Atom DOM for creating a theme, the structure felt very tame (and I too have looked at CodeMirror/Brackets). I found it readable and straightforward. There's a bit to it, but eh, good enough to work through if I inspect elements etc.

Sublime sure is fast. This is fast too. I haven't put it through its paces in normal usage, but at least I have a fallback that I like.

Package hell is true for anything is it not? If you're saying Atom doesn't have N feature count that matches other editors, you could very well be right, but I have a feeling that will change. Also, I'm sure Atom will start ranking plugins at some point too.

> I found it readable and straightforward. There's a bit to it, but eh, good enough to work through if I inspect elements etc.

I meant more from a performance perspective. It might not be hard to sift through to make a theme, but it seems like a lot of overhead for the core to continually process all that data.

> Package hell is true for anything is it not?

I guess so. Curation is always an option. But even just from a settings perspective, they are just all listed alphabetically in the prefs panel. I'm not sure what the solution is, but a stock install already has too many packages to manage.

> The markup characters outnumber the content by like 50x.

This isn't an accurate measure of DOM memory usage because element names/attributes/CSS selectors/CSS properties are interned in all browser engines.

I don't know about Ace, but CodeMirror only loads a small portion of the file text into the dom. I regularly load 40 kloc javascript files in Light Table without any noticeable pauses.

Yes they both display only visible part of the text, which Actually Ace was the one that first used this technique for rendering. And c9.io opens 80kloc files without a problem, and have much faster searching and scrolling.

Reply on news.ycombinator.com