
Moving Atom to React - _pius
http://blog.atom.io/2014/07/02/moving-atom-to-react.html
======
kolev
I've used React since it became available and the editor is still pretty slow,
to be honest. Can't imagine using it with the option enabled. Honestly,
Sublime Text is great, I've purchased a license, but the speed of development
will kill it. Every day I "Check Update" and I get disappointed. Not that it
needs that much new stuff, but still. You don't feel the heartbeat, if you see
what I mean. One great feature of Sublime that I miss in Atom is persisting
unsaved changes between restarts, which I abused for temporary To Do lists and
stuff.

~~~
lelandbatey
Upon downloading and running Atom, that was also immediately the thing I
missed most. I really love the scratch-space as a feature that Sublime Text
gives me, and I find that I want it in more and more things.

~~~
silversmith
This just shows how hard it is to please everyone - when I was using ST,
disabling the open file persistence was the first thing I did. My usual
workflow has me editing / looking up information in many different files,
usually just a bit here and there, so at least once every two hours I'd cmd-q
the whole mess and `e .` in the project directory and re-open the files as I
need them.

~~~
TheZenPsycho
I think it just shows that you do computers wrong.

Okay sorry that sounds snarky and unproductive- What I mean is, as a model for
how human evolved navigation works- a persistant work space with effectively
no need to "save" work is more like reality. If you scribble something on a
napkin, and leave it on your desk, the desk doesn't demand you name the napkin
when you try to leave the house. At the exact moment you need to leave to go
to work, is the exact moment you are least prepared to think of a name and
location to find something later.

But with a persistent workspace, you can just shut the program instantly,
without being spammed by 15 "save, discard, cancel" dialogues. Pressing the
power button on the computer, and having the computer just.. turn off… and
then turn back on having not forgotten anything by accident or otherwise. You
can name and save stuff AT YOUR LEISURE.

that. is. the. future.

…. of 1996. It's 2014 now and we've just now gotten round to adding it… to one
program. a text editor. now we just need to get the rest of the developers in
the world on board with this really obviously correct thing to do.

~~~
alextgordon
> If you scribble something on a napkin, and leave it on your desk, the desk
> doesn't demand you name the napkin when you try to leave the house

Maybe if they did, my desk wouldn't be so untidy right now.

The save/discard/cancel dialogs are there for a reason: the computer doesn't
know whether you want to save or discard! "Keep everything" is not a solution.

Usually I will keep about 50% of the "unattached" files I create. Some will be
good ideas: they get saved. Some will be go nowhere: I throw those away.

For files attached to a project it's more like 100% -- so they should be named
upfront on creation.

Besides, doing something "at your leisure" is a euphemism for never doing it
at all. People are difficult like that.

~~~
TheZenPsycho
so when you're trying to do something else is the time to be making these
decisions?

------
donw
Having spent the past two weeks diving deeply into React, this doesn't
surprise me. If you haven't tried it out, give it a go.

Being able to rewrite the virtual DOM at will makes development _so_ much
cleaner, and it plays incredibly well with other tools, because React is just
a presentation layer (I'm using it with Backbone)

There are rough edges (TransitionGroup), but they clearly know what they are
doing.

~~~
dmak
Can this play nicely with Angular and still make use of Angular's two-way
binding?

~~~
rdtsc
Look at some of Peter Hunt videos:

[https://facebook.github.io/react/docs/videos.html](https://facebook.github.io/react/docs/videos.html)

2-way binding is not necessarily the way to go with this.

~~~
kalkeo
good~

------
cnp
So psyched. The speed in which the editor used to function drove me totally
crazy and I was hoping that GitHub would find a solution. And I'm doubly
psyched that they chose such an awesome technology! Great work.

edit: Just installed the update and indeed, all of the "clunk" that you used
to feel is gone. Gonna retire Sublime Text 3 now :)

~~~
notduncansmith
I don't know if I'm ready for that step yet.

One thing that attracts me to Atom is the infinite UI hackability. If I don't
like the color of the text in the tree view, I can change that, just by
writing CSS. It's an editor by the web, for the web, and _of_ the web.

Sublime, however, feels much more fluid. When I open a file in the tree view,
it animates down (have yet to get that working properly with Atom - it
animates but it looks choppy). It's faster, for obvious reasons. The themes I
have in place look damn good, and I have a git package that can show me a diff
of the file I'm looking at (oddly, Atom lacks this feature).

I very much look forward to following Atom and maybe in a year or two, if
they've gotten it up to a level of performance I can tolerate, I'll give it
another shot.

Ultimately, right now the choice is between the performance and usability of
Sublime, vs the aesthetics of Atom. Sublime's performance actually gives it a
bit of an aesthetic edge over Atom, so despite the hackability of Atom's UI,
it's just not there... yet.

I'd love to make the switch, but the subtle (though perceptible) UI lags and
smaller ecosystem make it a subpar choice right now.

~~~
TimWolla
There is a git-diff package that shows colored bars next to the line numbers:
[https://github.com/atom/git-diff](https://github.com/atom/git-diff). While
not a real diff I find it pretty helpful.

~~~
notduncansmith
Yeah, I do have that installed. It's nice to know how big of a change I made,
but still requires me to use more memory than I'd like when composing a commit
(or go to the terminal).

Maybe SublimeGit has spoiled me, but I really feel like leaving my editor to
make a one-file commit is for the birds. It doesn't break my workflow nearly
as much as popping back to the terminal, doing a status to make sure I'm
committing what I think I am, adding the file, then doing a commit, then
(possibly) pushing. 3-4 steps compared to 1 from the editor (add and commit,
or add and commit and push, this file).

------
forrestthewoods
I hope that some day Atom is fast, full of features, and on Windows. My gut
tells me it will be a long, long time til it replaces Sublime Text 3 as my
editor of choice. =[

Edit: Since several people chimed in with the same thing. I'll check out the
windows binaries for. I expect to use ST3 for awhile longer still, at least
until Windows is a first class citizen, but this will be great to monitor
Atom's development. Thanks!

~~~
JoelHobson
It's already got a huge amount of features when you include packages (and
installing them is completely frictionless). Unofficial windows builds exist
too[1]. And as someone who's used to heavyweight IDEs, Atom is already pretty
fast (not that I'm going to complain about the react update...)

[1] [http://atom.someguy123.com/](http://atom.someguy123.com/)

------
exogen
The new rendering method kills subpixel font rendering, I suspect due to the
translate3d hardware acceleration. Unfortunately noticeable for those of us
not yet on retina-resolution screens.

~~~
MagerValp
The font rendering in Atom is what's currently keeping me from giving it a
serious try:

[http://discuss.atom.io/t/atom-vs-textmate-font-
rendering/907...](http://discuss.atom.io/t/atom-vs-textmate-font-
rendering/9072/3)

------
Sir_Cmpwn
This is a natural consequence of forcing an editor into the browser.
Everything about Atom just seems so unneccessary to me.

What's compelling about Atom that draws people in, compared to Sublime or even
vim (my editor of choice)?

~~~
sehr
It's very easy to make plugins for. Most web developers know JavaScript, not
everyone knows vimscript/viml

~~~
shadowmint
To be fair you can write vim plugins in python, and a fair number of people
do.

It's also, I'd argue, a fail from the Atom guys to make their plugins run in
coffee script natively, rather than allowing people the choice of compile-to-
javascript/native javascript to write plugins in (this has definitely hurt
adoption for the creation of plugins that do more than trivial things or
syntax highlighting).

The thing about atom that is compelling for me is apm (the command line atom
package manager); its really very good.

(Yes, I know you _can_ write 'pure javascript' atom plugins, but its complex
and it's clunky; you have to manually implement the coffee script inheritance
semantics. Fail.)

~~~
adrusi
"Coffeescript inheritance semantics" aren't anything special in javascript. If
the editor was written in javascript syntax and still chose to make use of
inheritance in its design, extensions would look the same.

This works just fine, and it can't get much more javascripty:

    
    
        ExtensionComponent.prototype = Object.create(Component.prototype);
        function ExtensionComponent() {
          Component.call(this);
        }
    
        ExtensionComponent.prototype.doSomething = function () {
          // ...
        };

~~~
shadowmint
Have you actually tried it?

Seems like the people who actually have found it a little more complicated
than that (see [http://discuss.atom.io/t/coffeescript---extends-vs-util-
inhe...](http://discuss.atom.io/t/coffeescript---extends-vs-util-inherits-
inheritance-in-js/2536)).

To quote the post:

    
    
        The difference is important. CS copies functions from parent to child on top of 
        setting the prototype while the std library just does the latter. Inheriting from 
        require("atom").View breaks without doing this manually (which isn't obvious at all). 
        If this is not being done for performance, it should be documented; otherwise, those
        methods should be moved to the prototype.

------
RSO
I've been using Atom for a while now, and I'm really impressed with the
progress that it's showing. There are still some times that I'm forced to
switch back to Sublime (mass-editing a large text file for instance), but I'm
really enjoying the experience!

------
mproud
A 2 MB file limit makes Atom just impossible for me to use.

~~~
seanp2k2
Curious: what type of things would you want to edit over 2MiB? I think it's
probably more a function of "having such a huge DOM would be a bad UX anyway"
vs just some arbitrary limit.

~~~
xienze
Log files.

~~~
adrusi
I'm curious, do you really need a _text editor_ for log files? It seems like
the wrong tool, after all, you're not editing your logs. I have never found a
case where `cat example.log | grep Error | less` is insufficient.

Granted, I think a good editor _should_ be able to handle files of any size,
but if atom sacrifices that for the ability to let an extension display
anything it wants inline with the text, it doesn't seem like a catastrophic
loss.

~~~
nilkn
Moreover, if you really need a text editor for a log file, you can just launch
vim or something for that task.

I've never really understood why people get in this mindset of "X is my
editor, and I will _only_ use X."

I guess, though, this is harder to do if you insist on a completely GUI-based
interface.

~~~
snotrockets
> I've never really understood why people get in this mindset of "X is my
> editor, and I will only use X."

If you use certain software a lot, you'd find it behaviour and shortcuts
ingrained into your subconscious mind. Like driving: an experienced driver
doesn't consciously think of how to control the car, she just does.

This is what makes Emacs or vi users so efficient: they had years to get the
operation of those editors ingrained into their brains. Which takes quite an
effort, that is not worth repeating with another editor (unless yours is
broken).

~~~
nilkn
There's no reason to downvote me because you have a different opinion. I
thought this place was supposed to be better for discussion but evidently not.

I'm a vim user who can easily use something else if it's better for a certain
purpose. I guess not everybody feels the same way and some are even offended
by the suggestion.

~~~
reitanqild
The offense is not about not agreeing with you it seems but about the way you
present it. (Disclaimer: not a downvoter, just an observer. )

------
elwell
Not trying to start an editor war, but I've been trying to learn Emacs for the
past week. The learning curve is still at the point of being
frustrating/painful. Should I stick with it or download Atom? (Anyone have a
solid opinion between the two?)

~~~
swah

        I use ST because it just works.
        
        Let me tell you.. Atom will probably never come 
        close to Emacs programmability and extensibility. 
        Its by far the most beautiful software 
        environment. Its a living thing.
    
        In Emacs you're constantly reminded of the love of 
        generations of hackers in improving it. The 
        C-core-and-Lisp-scripting pattern was a perfect
        match. Emacs has the quality without a name.
        
        But Atom is modern. Emacs is single threaded (IIRC)
        and a single evil elisp snippet takes it to its knees.
        
        Those thousands of elisp mdoules (mostly) work together,
        without any kind of sandboxing. I think this is also
        notable and beautiful. It was achieved by a lot of 
        hackers who cared a lot.
    

This is MY little list of people who wrote emacs philosophy or code that I
loved, off the top of my head:

    
    
        erik naggum (rip,  most people hated him, but he loved 
                     and understood lisp and I want back to old usenet
                     posts for insights many times 
                     those insights now lost somewhere)
        luke gorrie (slime originator iiuc, mind blown w/ his demos. 
                     also erlang guy and hacker at heart
        steve yegge (js2, explained emacs qwan in many posts)
        sacha chua
        TamasPatrovics (anything!)
        Eduardo Ochs (eev, built his own little world inside emacs)
        David O'Toole (linkd.el, many other intersting packages)
        rubikitch (!!! so many useful emacswiki snippets)
        alex schroeder (emacswiki master iirc)
        Matsushita Akihisa (moccur-edit.el, still miss this in Sublime)
        dr qubit
        Nikolaj Schumacher (beautiful auto completion packages)
        xahlee
        magnars sveen
    

Using emacs feels like being immersed in the rich culture of a past
civilization.

~~~
johnm
Have you tried LightTable yet?

~~~
swah
Yes, I really like its philosophy, but it had some rendering issues when I
tried.

Also, I've yet to accept that javascript is taking over (Atom, Lighttable..)

~~~
johnm
Yeah, that's been my experience, too (on both counts).

Emacs ftw!

------
eknkc
Just checked the new version briefly. Scrolling performance seems to be much
better, especially on a large display with fullscreen editor. Atom is getting
pretty decent for daily use.

~~~
tolas
Haven't been following it too much recently, but just curious, why use it over
Sublime?

~~~
eknkc
I still use Sublime mostly. However, Atom seems to have a thriving ecosystem
around it. There are a lot of high quality Atom packages. I believe it's
mostly because Atom has a more accessible developer interface for newcomers,
being it is just a web app. And it's open source.

Also, Sublime seems to be abandoned for a while. Not that it stopped working
or anything.. But I believe the lack of development will push people away
eventually.

~~~
Swizec
I just find it funny that replacing "Atom" with "Emacs" in your argument
doesn't feel out of place at all.

Well, Emacs Lisp might be less newcomer friendly and it's not a webapp. But
still, thriving ecosystem - check, accessible to developers - check, huge
number of packages - check, runs everywhere - check.

~~~
hamburglar
The thing Atom has which Emacs doesn't is that it's _approachable_ even if you
don't appreciate all the customization and the rich ecosystem. You can sit
down with Atom and just explore it like you would any other GUI text editor,
and it pretty much behaves exactly like you'd expect without having to learn
any obscure commands or shortcuts. You can learn the commands and shortcuts
(and explore the ecosystem) as you settle in.

I'm primarily a vim user and I still prefer vim to Atom, but within a day or
two of seriously trying out Atom, I was probably up to speed with 90% of the
core functionality I use in vim on a day to day basis. That last 10% is a bit
of a killer, though. :)

~~~
willismichael
That last 10%... same reason I keep going back to emacs after trying a half
dozen other editors that more or less promised to be "the one".

------
beefman
I tried scrolling through a 1MB JSON file with all four combinations of React
DOM on/off and hardware acceleration on/off. Anything with React on was
crashing slow. With React off, hardware accel was maybe slightly better on.
Sublime 2 blew Atom away. Chrome had flawless scrolling too (albeit with no
syntax highlighting). MacBook Pro running 10.9.3.

------
ivank
Typing text at the end of a 1000-line file seems to be laggier with the React-
based editor enabled.

------
niix
One of my biggest pain points with Atom was the speed. More specifically, the
selecting of multiple lines greatly killed performance and made me switch back
to Sublime. Glad to here they are making efforts to speed the editor up, I'll
give it another go!

~~~
ehurrell
Speed was really a killer for me too, it became slow very easily. It also
began erroring out of update-checks and package installs, making it feel quite
worthy of the beta tag. Look forward to seeing where it is now!

------
mercer
I would love to switch from Sublime Text to Atom, but the two main things
holding me back are the noticeable performance issues (compared to ST), and
vim keybindings.

ST's vim support is good enough for me, and when I need more I'll just switch
to Vim for those things. But Atom unfortunately is still too limited, although
it's good to see progress.

Happy to see the performance issues being worked on, though, and as a big fan
of React, I'm happy with their choice.

------
jipumarino
It gets better every time I try again, but I'm still missing four things:

\- Good project management. I tried the project-manager plugin, but it doesn't
seem to remember my fuzzy finder options and reindexes everything every time.

\- Good Vim emulation, like Vintageous in Sublime.

\- Keyboard mapping override. I use cmd-j and cmd-k for switching tabs in
Sublime. I cannot map this easily in Atom.

\- Actually, I disabled tabs in Sublime and only use the side bar. I miss this
in Atom too.

------
spolu
This is very interesting. Reminds me of what I saw in Chrome Secure Shell
source code while hacking a while back on a vt100 emulator in JS.

ls -l ~ was always the best test to see how scrolling would behave and how
fast was the rendering...

What they say here and what I realized then is that the most important part is
about rendering only what is visible on the screen!

------
desireco42
I finally tried Atom and it looks pretty much like SublimeText, which I use
quite a bit. Is there a reference somewhere where it says it was inspired by
good work of SublimeText editor?

Ah Google always provides:

[https://github.com/atom/atom/issues/2038](https://github.com/atom/atom/issues/2038)

~~~
bronson
Just curious, is there a reference in Sublime where it says it was inspired by
TextMate?

~~~
girvo
As someone who loved TextMate, ST, and Atom (but now use Komodo): The
similarities between Atom and ST are much greater than those between TextMate
and ST, in my opinion.

------
sandyarmstrong
Weird behavior with scroll wheel. It seems to not stop where I'd expect. Works
great with trackpad, so I guess that's what the developers must be using.

Fast scrolling by dragging the scrollbar nub is pretty slow, still, but this
is definitely an improvement.

~~~
mrbogle
What platform? What kind of mouse are you using? The team uses all different
mice. I use an apple magic mouse, and it works well.

You can change the scroll sensitivity in the settings.

------
hoffer
No mention of the Brackets editor here from Adobe. Also built with JS and open
source. Any opinions on it in comparison to Atom?
[http://brackets.io](http://brackets.io)

------
TheMakeA
One thing that I would like to see is multiple process support. At least once
per day, one tab will become unresponsive (for seemingly no reason) and I have
to kill the entire editor and reopen it.

~~~
mrbogle
Try the new editor, it may help with this.

------
jbeja
Would they gain better performance if they use canvas intead the dom?

~~~
aikah
they could use WebGL and an engine that supports ASMjs. But it wouldnt make
sense since it's not a web app.

IMHO,it's a mistake to use webtechs to code a serious text editor. TextEds
require great performances,if I cant open a 3MB with it,it's just not worth
it.

They could have kept javascript/coffeescript for plugins and write the UI in
C/C++.Javascript is fast with engines like V8,the DOM is absolutely not fast
at all.

------
SimeVidas
> We also render the cursors and the hidden input field that receives keyboard
> events as their own layers on the GPU

How is this performed? transform: translateZ(0)?

------
cturhan
After this news, I downloaded and build on windows and yeah it might replace
my favorite text editor :)

------
flyrain
Why we need another editor? We already have vi, emacs, st, ... Why Atom?

~~~
toxicFork
Why do we need cars when we have horse carriages?

~~~
afro88
Because they're faster. Atom is slower than Sublime :)

But Atom is free, open source, and actively being developed.

~~~
flyingbeaver
Cars were not faster at the beginning.

You don't know if something will eventually become better unless you try hard.

~~~
taeric
Not really a good analogy, though. There were serious benefits to getting off
horses, even if we ignore the speed promise of automobiles. Moving to a text
editor that is written in JavaScript doesn't really seem to have much promise
of gains in the future.

Though, the enthusiasm there is nice and there is no reason to bemoan its
existence. Just don't be surprised when the things it can do have already be
done in more venerable environments in the past. :)

