Live data from Hacker News

Moving Atom to React

blog.atom.io

91–100 of 142 posts

Re: Moving Atom to React

#91
post #90
post #30

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 S…

I too feel this way, it seems to still have that signature javascript 'lag' where ST3 is very snappy, also it still can't load files > 2MB.

I like that core Sublime Text is stable and fast. Where 'interesting' things mostly happen in the thousands of available plugins.

Speed, good core API design, and stability take time.

Re: Moving Atom to React

#92
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?

Yes, and apparently you can take advantage of React's faster/smarter rendering (http://www.williambrownstreet.net/blog/2014/04/faster-angula...)

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.

Re: Moving Atom to React

#93
post #65
post #27

Earlier quoted context omitted.

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

Look at some of Peter Hunt videos: https://facebook.github.io/react/docs/videos.html 2-way binding is not necessarily the way to go with this.

good~

Re: Moving Atom to React

#94
post #39
post #31

Earlier quoted context omitted.

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.

why?

Re: Moving Atom to React

#95
post #27

Earlier quoted context omitted.

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

Yes, and apparently you can take advantage of React's faster/smarter rendering ( http://www.williambrownstreet.net/blog/2014/04/faster-angula... ) 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 perfor…

Pretty much this. AngularJS abstracts DOM manipulation away from the user; by adding React to an AngularJS project, you're giving up on that abstraction. I consider React a sacrifice of abstraction / ease of development in favor of 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.

Re: Moving Atom to React

#96
post #70

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.

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...

Re: Moving Atom to React

#97

Earlier quoted context omitted.

Yes, and apparently you can take advantage of React's faster/smarter rendering ( http://www.williambrownstreet.net/blog/2014/04/faster-angula... ) 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 perfor…

Pretty much this. AngularJS abstracts DOM manipulation away from the user; by adding React to an AngularJS project, you're giving up on that abstraction. I consider React a sacrifice of abstraction / ease of development in favor of 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…

I disagree with this. React abstracts away DOM manipulation just as well as Angular does at a high level. When you dive deeper (i.e. building components/directives) React continues to abstract it away, whereas Angular reveals it.

In fact, React is able to get superior performance because the DOM is abstracted so far away.

Re: Moving Atom to React

#98
post #23

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

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 animate…

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

Re: Moving Atom to React

#99
post #34

Earlier quoted context omitted.

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 ke…

Almost every Emacs user uses the standard keybindings for most stuff (though many change the odd binding or two for personal reasons). They work really well once you get used to them, and they tend to form a system: C-f goes forward a character, M-f goes forward a word, C-M-f goes forward an "expression", and those same modifier keys have similar relationships for other commands.

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

Re: Moving Atom to React

#100
post #30

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 S…

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.

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.
Post reply on HN