Live data from Hacker News

Moving Atom to React

blog.atom.io

31–40 of 142 posts

Re: Moving Atom to React

#31
post #26

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.

TransitionGroup also annoys me to death. If you have any thoughts on animation please chime in here:

https://groups.google.com/forum/#!topic/reactjs/2-RhZTHxNdc

But yeah, I agree -- development is massively cleaner in nearly every single way.

Re: Moving Atom to React

#32
post #27
post #26

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.

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

I'm interested in this as well. I believe some people have had success by attaching components to the window as globals.

Re: Moving Atom to React

#33
post #20

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?)

Unless you have a specific reason not to, you definitely should look at vi if you find Emacs' learning curve frustrating. Adhering to the Unix philosophy, vi lets you combine simple commands to achieve more complex goals, which makes the learning curve way more pleasant. 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).

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.

Re: Moving Atom to React

#34
post #20

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?)

You probably do want an editor that is free, can be used for the rest of your life, works perfectly in a terminal, and is completely programmable. 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/yukih…

I'll check out Prelude; I have better-defaults installed, but this seems to be much more radical. Just curious, how did you find out about Prelude? I'm a freelancer so I don't have any in-person exposure to model/mentor programmers outside of the web, and I'm thus finding it difficult to even know if I'm using Emacs in a sane way. For example of the type of things I wonder about: do most Emacs users keep the basic keymapping the same (C-n, C-p, C-f, C-b etc.) or do many switch to a non-conflicting but more ergonomic alternative. (The idea that such an important keymapping is decided by the first letter of an action rather than ergonomic sensibility is insane to me.)

Re: Moving Atom to React

#35
post #27
post #26

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.

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

Take a look at http://josebalius.github.io/ngReactGrid/ for an example.

Re: Moving Atom to React

#36

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

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

Re: Moving Atom to React

#37
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!

Re: Moving Atom to React

#38
post #20

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?)

[deleted]

Re: Moving Atom to React

#39
post #31
post #26

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.

TransitionGroup also annoys me to death. If you have any thoughts on animation please chime in here: https://groups.google.com/forum/#!topic/reactjs/2-RhZTHxNdc But yeah, I agree -- development is massively cleaner in nearly every single way.

Yes, please do chime in -- for animation we're currently blocked on APIs that make sense, not implementation. If anyone has ideas about how animation should work, that thread is a great place to put them.

Re: Moving Atom to React

#40
post #20

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?)

Emacs is the One True Editor.

Maybe, but ed is the standard text editor.
Post reply on HN