Moving Atom to React
blog.atom.io
blog.atom.io
Interesting idea though. Thanks for pointing it out.
It's such a major step in the wrong direction to have to go back to trying to avoid shutting down applications/your computer since it's such a big hassle.
If I want save something I'll save it and if I want to close something I'll close it, just keep it "open" for me in the mean time.
$ atom some/where/to/my/project
# open files
# close atom
$ atom some/where/to/my/project
# atom reopens everything I had open for that project
(If step (2) is "create new file", Sublime will preserve it, even if it's not saved.)
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.
(Expecting explanation on why hibernation is considered harmful. )
It's certainly useful, but I think the comment you were replying to was thinking more along the lines of saving that state without doing all the work our computers have to do to go into hibernate.
I for one would love a faster and less error prone sleep/hibernate feature. (Although recent Mac OS implementations have really cut down on the error prone part of that. I'm not sure where the Linux/Windows crowd is on that, I would assume the story is the same/similar.)
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.
Very powerful editor (vim too), seriously consider challenging your assumptions around text editor productivity...
Also, use The Silver Surfer for finding stuff in files + [e,c]tags. Emacs has some nice modes for interfacing with those tools too :)
Speed, good core API design, and stability take time.
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.
http://facebook.github.io/react/docs/two-way-binding-helpers...
That being said, there's an extension that adds two way bindings, called ReactLink. You can read more about it here: http://facebook.github.io/react/docs/two-way-binding-helpers...
https://facebook.github.io/react/docs/videos.html
2-way binding is not necessarily the way to go with this.
That said, I would be uncomfortable mixing something as opinionated as Angular with another framework that expects to "own" the DOM/rendering. My guess is that Angular will implement their own version of VDOM in the next few months since it shows demonstrably better performance.
I think AngularJS will adopt a similar strategy for their 2.0 development effort, maybe even a 1.x point release. But I haven't looked at the angular development process for a while now.
In fact, React is able to get superior performance because the DOM is abstracted so far away.
https://groups.google.com/forum/#!topic/reactjs/2-RhZTHxNdc
But yeah, I agree -- development is massively cleaner in nearly every single way.
edit: Just installed the update and indeed, all of the "clunk" that you used to feel is gone. Gonna retire Sublime Text 3 now :)
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.
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).
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!
https://github.com/atom/atom/blob/master/docs/build-instruct...
http://discuss.atom.io/t/atom-vs-textmate-font-rendering/907...
What's compelling about Atom that draws people in, compared to Sublime or even vim (my editor of choice)?
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.)
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 () {
// ...
};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...).
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.It's open source; Sublime isn't. I can't do anything to make Sublime better.
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.
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.
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).
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.
Well, it doesn't always boil down to "grep for one specific thing." Usually you find one thing, then you have to locate the next couple instances of it (I use vim, so I'm used to just doing nnnnnnnn... to keep finding the next occurrence). Or perhaps you grep for one specific thing, find out something is related, need to search for some other thing, etc. Maybe you need a little bit of context around the thing you grepped for. Text editors work pretty well for combing through log files...
And almost never without visiting (opening in the editor) at least one of the files being grepped.
In particular, loading the file into TextMate took about 15 sec. Searching for a string (using ^S) took 2 or 3 sec per occurrence (i.e., per tap of the S key with the control key held down). Inserting took 2 or 3 seconds per character. Scrolling was probably just as snappy as it is in a small file. In particular, by dragging in the scroll bar a person can smoothly scroll past many megs of text per second.
In GNU Emacs, loading took about 4 sec, after which scrolling, searching, moving to the top or bottom, and inserting (even near the end of the file) were instantaneous.
Other than /s, I wanted to say I am also learning emacs after some years of both vim and st2-3 and I really like it. I have still to stick to a cheat sheet to remember common commands but I am on my way to the Stallmanmination
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.
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
This was my only contribution to open source and I wish someday I can feel useful in that way again.
Also, I've yet to accept that javascript is taking over (Atom, Lighttable..)
Emacs ftw!
I suggest you continue on with your ascent to emacs understanding! Be sure to use something like prelude, i.e. something with 'sane defaults', and checkout this slideshow by emacs enthusiast (and chief designer of ruby) Yukihiro Matsumoto. (http://www.slideshare.net/yukihiro_matz/how-emacs-changed-my...)
It took me 3 weeks to become proficient, and I moved from Sublime Text 2.
As for ergonomics... Emacs bindings feel far more natural and comfortable than any other editor bindings I've ever used, but then I've used Emacs for a long time and am well used to them. I suspect that the same is true for most people: what feels/works best will have more to with what you're used to than any inherent superiority. [And probably no keyboard-oriented editor that's been successful for any length of time will have a truly un-ergonomic design, because it couldn't have succeeded with such.]
Probably the closest thing to what you're describing is the various editor emulation packages, which often remap many basic bindings... Of these, vi/vim emulation is probably the most popular these days, and there are like 4-5 vi/vim emulation packages, of varying degrees of sophistication (and age), although I'm not sure which is the current favorite (maybe "evil"? http://www.emacswiki.org/emacs/Evil ).
Vim is a very feature-rich editor, which can be distracting while learning the more basic steps. I started with nvi (the vi clone that ships with OpenBSD). Used copys of the 6th edition of O'Reilly's "Learning the vi Editor" (1998) are available practically for free. You don't have to read every single sentence ("remember that you must press ENTER to tell Unix that you are finished issuing your command"), but I found the structure very sensible.
If you don't think distraction is a problem for you, start with Vim and try the vimtutor.
> For example, if you know how to jump to the next occurence of character x (fx), you already know how to delete from cursor to character x (dfx).
Yes but if I have to start typing I have to press some key to switch modes (i?). That is a no-go for me.
That said, there are tricks to make modal editing less annoying. For example, mapping your CAPS LOCK key to ESC makes switching out of insert mode much easier.
Some commands perform actions and then switch modes all at once for you. To extend the grandparent comment's example, you can use the substitute command, s, instead of the delete command, d, to perform the "delete and switch into insert mode" action with sfx (rather than dfx).
Instead, just use it to edit files. After a while, if there is something you are finding would be convenient, search for and or build it.
That said, some obvious points that you will find nice do come by default if you start out with something like prelude. Though, again, just use it to edit files and don't worry about using the keyboard shortcuts that heavily.
If you are highly motivated by the shortcuts, then I would set a pace for learning a few at a time and really get them down first.
For that matter, whether in emacs or atom (or vim/sublime/acme/whatever), it would be rather instructive to see what features are used heavily by folks. Even better if there was a nice listing for what features were discovered, in order and frequency of use.
Is there already a trend/meme for doing something like this? "What I use in my editor?"
The primary reason, at least for non-code text, is that I find it annoying to go back to using stuff like the arrow keys for navigating now that I'm kind of used to the arguably more ergonomic C-f, C-b and friends. So I can echo the sentiment that sticking to the basics of emacs at first can be well worth it.
My advice is to just learn 5-10 basic commands. Movement, copy paste, exit, save and open file. Then see how you like it.
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.
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.
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. :)
Of course, Atom is open source and has potentially huge community backing to push it forward (vs. pleas for features and fixes to the other editor's seemingly absent overlord).
When I switched laptops recently, I made the conscious decision to only install Atom to see how things went...so far so good, although at times it does bog down pretty noticeably, and this is by far my biggest complaint. There's also no alt-drag support (to create a straight line of cursors like Sublime), but that's a fairly small gripe.
I loved the plugin ecosystem for Sublime, and in the short time Atom's been around, the ecosystem has already exploded. Lots of awesome themes and plugins are already available, with more coming every day. The low barrier to entry (most things can be done with JS / CSS) probably has a lot to do with that.
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.
- 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.
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!
Ah Google always provides:
Fast scrolling by dragging the scrollbar nub is pretty slow, still, but this is definitely an improvement.
You can change the scroll sensitivity in the settings.
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.
How is this performed? transform: translateZ(0)?
But Atom is free, open source, and actively being developed.
You don't know if something will eventually become better unless you try hard.
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. :)
Maybe we just don't need it, but it's nice to have a different approach / a choice.