Live data from Hacker News

Moving Atom to React

blog.atom.io

81–90 of 142 posts

Re: Moving Atom to React

#81
post #48

Earlier quoted context omitted.

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

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…

"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 () {
      // ...
    };

Re: Moving Atom to React

#82
post #79
post #76

Earlier quoted context omitted.

Log files.

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

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.

Re: Moving Atom to React

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

Yeah, I was wondering what was wrong.

Re: Moving Atom to React

#84
post #82
post #79

Earlier quoted context omitted.

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

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.

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

Re: Moving Atom to React

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

Do you have an example where you rewrite the virtual DOM? I don't see anything like that on the React site.

Re: Moving Atom to React

#87
post #73

Earlier quoted context omitted.

Why do we need cars when we have horse carriages?

Because they're faster. Atom is slower than Sublime :) But Atom is free, open source, and actively being developed.

Cars were not faster at the beginning.

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

Re: Moving Atom to React

#88
post #71

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!

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!

Re: Moving Atom to React

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