Comment by kingnight | Hacker News Reader

Comment by kingnight | Hacker News Reader

Without looking at the behind the scenes memory allocation/speed — the real world speed of the application surpassed my expectations.

I've jumped from ST to try and use this since I received my invite and am incredibly impressed without how little I feel the urge to switch back. Other editors that I try out (which I do far to often, ugh) are pretty, have unique features, but they lack the can't live without feature(s) that no one has matched in ST is the ease of line/text manipulation (find-next(cmd-d) + find-skip-next-next(cmd-k+cmd-d)+ undo + Multi Cursor, Block Select, Dupe...).

Atom got close with this version. The duplicate function is only duplicate line but without knowing any CoffeeScript I was able to override this function to duplicate selection if there is a selection before duping the line — for every selection. There are many other areas that are close and will either be closed out by myself for my own use, addressed by others via packages, or even in the core once it hits 1.0.

Anyway, this is a good write up and good look at the negatives of a web based editor, but I would argue the drawbacks of the DOM outlined are outweighed by the ability talk to it (and also the entire API) via the webkit inspector.

Also, the current version number is 0.6.0.

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.

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.

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 challenge anyone to find me a feature in an editor that you can't find in an IntelliJ IDEA based editor like WebStorm or RubyMine. Atom, Sublime Text, Text Mate, and even Vim and Emacs use (broken) regular expressions to do syntax highlighting and intelligent things. IntelliJ build a "PsyElement" tree which is basically an AST. As such it will always have more features and be more powerful, and it's all on the JVM and super amazingly fast, well except for the indexing and startup (yech), but Cmd+B on any variable in any language IntelliJ understands, or Alt+F7 on a variable definition or Shift+F7 or Shift+F6 for a rename. IntelliJ is actually here from the future to write our code for us, and I'm saying this as a pretty dedicated vim user.

IDEA's scala support still flags bogus errors (e.g. it doesn't seem to infer the type of a Kleisli { ... } correctly). It's one of the things keeping me on Eclipse.

What's bothering you about Eclipse?

Its scala refactoring is quite limited (even organize imports doesn't work, can't move a type out of a file without moving it to a different package which will sometimes fail anyway, no "generate interface implementations" or "move method to parent class"), autocomplete is painfully slow, and every so often the UI freezes for several seconds.

How about watches in LT - http://www.youtube.com/watch?v=d8-b6QEN-rk

I've only used Intellij for scala and while the static analysis was pretty useful I wasn't at all impressed by the facilities for live interaction. Maybe some of that is down to the scala repl being pretty poor - perhaps if I used Intellij with python or javascript I would find it more useful.

I don't seem to be able to do multiple cursors in IntelliJ. That's a massively useful feature available in Sublime, Text Mate, VIM (via plugins), and Emacs (via plugins). Emacs can do almost anything. I can read my email, browse the web (with images, no less), chat via IRC and Jabber, open multiple terminals, manage my Git repositories, etc. I can't find anything like that in IntelliJ.

You probably would use IntelliJ's refactoring instead of multiple cursors. Renaming variables, functions, editing function signatures, etc. Whatever you'd do with multiple cursors you would probably do with a refactor, or a search and replace. There's also column select mode.

I use multiple cursors for tons of stuff that can't be handled by search/replace, column selection, or refactoring tools. Once you really get into it, multiple cursors are a very powerful tool.

Speed? Resource consciousness? Ability to work on older hardware? Ability to work in a terminal?

Nock Vim's hacky syntax highlighting all you want, but people have done amazing things with it. I mean, just today I found a plugin that properly highlights PHP annotations. All the intelligence in PHPStorm failed to deliver on that front.

> Speed?

Aside from startup speed Intellij is pretty fast, I would like to know what speed issues you might be talking about? This isn't a buggy piece of mess like eclipse.

> Resource consciousness? Ability to work on older hardware? Ability to work in a terminal?

You're right, vim has Intellij beat on all these things. But let's be real here, what platform are you doing heavy duty development on? I'm going to guess it's not a resource constrained, esoteric piece of hardware that only has terminal access. Don't get me wrong, I think you should be proficient with a terminal based text editor to be able to do in place edits over ssh, but seriously, that's not where you're doing most of your development work. At least I hope not.

This is also from a huge vim fan, I love it and I've used it for primary development when suitable IDE environments didn't exist (in the past Scala, recently hacking around with clojure and playing with Rust). But when you've got a mature IDE environment that isn't buggy, fast, and not resource intensive enough to make a big different on your development environment, it's a no brainer in my book. Plus the VIM plugin for Intellij is pretty good ;-)

> Without looking at the behind the scenes memory allocation/speed — the real world speed of the application surpassed my expectations

Agreed, I too was positively surprised about it's speed.

>Anyway, this is a good write up and good look at the negatives of a web based editor, but I would argue the drawbacks of the DOM outlined are outweighed by the ability talk to it (and also the entire API) via the webkit inspector.

Yes, you know, I thought about that a lot. But I'm not entirely sure that's true. Are you?

I can't really think of a good reason why this would be true. It would seem to me that an elaborate API for manipulating, and annotating the text store while being more complicated to design would be much better to create high quality plugins. This solution opens the door to lots of hard to debug memory leaks, and conflicts that can easily destroy the text your editing.

You could argue that bad plugin developers don't warrant closing off the api, and i would be with you. I'm just not sure what exactly you need the DOM for.

EDIT: actually I can. when dealing with web technologies, i have to admit it would be sometimes cool when you can instant preview code in the editor. this is possible with both brackets and atom. but atom has been much smarter about marketing a finished product. so this can turn into a sort of wysiwyg for the web

> Yes, you know, I thought about that a lot. But I'm not entirely sure that's true. Are you?

No, I am not. Ha! I guess I am exposing my own ignorance of _the right way_ to do things like this along with what my comfort zone is.

If I want to going to write a package to insert the current date at the cursor point, for example, I am likely going to just open up the webkit console and write code in their until it works (I did this) — instead of going to atom.io and finding their API documentation.

One cop out too I was thinking about is that one could easily write a plugin to 'edit in' and assign a keyboard shortcut to handle the big files in their robust editor de jour.

Reply on news.ycombinator.com