23 ms·

I enjoy seeing the latest fad being burned at the stake as much as the next guy, but I don't think we should blow this out of proportions. Atom is a text edito

I enjoy seeing the latest fad being burned at the stake as much as the next guy, but I don't think we should blow this out of proportions. Atom is a text editor, and text editors have an insanely high bar to clear in terms of performance and responsiveness. Users will abandon a text editor if the cursor takes a bit too long to move. On top of that, Atom has been criticized about its slowness since the very first announcement. They don't have any margin for error there (and to be honest, I think their technical choice of going for Javascript will be their ultimate downfall, but that's a discussion for another day). Also, as it was pointed out, Atom didn't really embrace much of React to start with (which is to their credit: always be very conservative when you're adopting a bleeding edge, unproven technology). I think React has potential. It's at about the same stage of maturity that Angular was five years ago, and if it's as successful, we can expect it to enjoy five years of being the new darling in the Javascript world, until the Next Big Framework comes around. I'm really enjoying how fast Javascript frameworks and practices are churning, it makes me feel like I'm witnessing the birth of a brand new software field with my very eyes.

Goopplesoft 12y ago
> and to be honest, I think their technical choice of going for Javascript will be their ultimate downfall, but that's a discussion for another day I'd like to see this discussion today ;)
- adrusi 12y ago
  It's not javascript. Modern javascript engines (like v8 which powers Atom) are well beyond fast enough. GC can cause occasional latency if the programmer is lackadaisical with allocations, but with care it's a non-issue. But Atom simply will not achieve performance competitive with Sublime while they are using the DOM. The DOM is too general-purpose for what is almost always just a grid of monospaced text. The overhead introduced by allowing plugins to render entire webpages inline with the text is just too much. I want so very much to like Atom --- a Free text editor that isn't vim or emacs and is actually powerful enough to replace them, but the imperceivable latency manifests as a gradual accumulation of stress.
  - jlongster 12y ago
    So much this. The DOM is absolutely going to be the bottleneck more than JavaScript. I can't really provide any concrete benchmarks to support this because its a very complex topic, and you can really only come to that conclusion after trying to optimize the DOM for something as critical as a text editor.
  - vbit 12y ago
    Just curious - why replace vim or emacs?
    - pmontra 12y ago
      Don't tell me, because I use both (mainly emacs), but maybe is to do something like this https://confluence.atlassian.com/display/BITBUCKET/Edit+online https://confluence.atlassian.com/display/BITBUCKET/Edit+onli... It can be strategic even if limited to quick edits and for some subsets of the repository now. Anyway I can think of a GitHub augmented with an IDE and integrated with a CI and CD system with deployment to a Heroku. It could let you write code from pretty everywhere, occasionally even on a tablet or a large phone. Somebody will use it.
      - couchand 12y ago
        GitHub has been slowly tricking me into doing more and more of those quick edits on their site. If they can work Atom in as seamlessly as their other updates I'm sold. Somehow I'm still circumspect.
    - crazychrome 12y ago
      emacs doesn't have decent support of jsx: the jsx-mode is actually for another tech with same name, the js2-mode is great except xml support. i love vim a lot (use evil in emacs), except vimscript. I hope oneday I could use neovim with atom/st2 as frontend.
      - mrkipling 12y ago
        I use web-mode to edit JSX. It's not bad at all actually - the indentation and highlighting are there. I've started using web-mode for its intended purpose, too (when editing templates that have CSS and JS snippets).
mcbutterbunz 12y ago
> I'm really enjoying how fast Javascript frameworks and practices are churning, it makes me feel like I'm witnessing the birth of a brand new software field with my very eyes. I totally agree. A language or technology that doesn't change is dead. The JS world can get a crazy sometimes but we need to understand WHY certain frameworks/patterns may be better and when to apply them. Kudos to the Atom team on making their product better.
zghst 12y ago
React is so much different from other frameworks, I feel. Someone that doesn't know React can basically come in and start working on a large app from Day 1. It is so much less frustrating than Angular, Backbone + Ember + handlebars, etc. You can continue to add features to a React application and not slow down. Also React isn't unproven. Over 1 Billion people use a React application everyday (Facebook + Instagram web). Unlike Google with Angular, React is Facebook's baby, the FB team is constantly churning out great additions to React. I feel though with these JS editors, they should just basically give up for the next 5 years or so. Switching between Atom / Brackets to Sublime or Vim is extremely painful, I can't stand how slow it is. I love adopting new technologies, but I do not have faith in JS applications outside of a browser, they are too slow and lack in features.
- jsprogrammer 12y ago
  Do you know of a large open source react application that I can take a look at?
  - zghst 12y ago
    Check this list on on the React repo: https://github.com/facebook/react/wiki/Examples https://github.com/facebook/react/wiki/Examples Noteworthy, Flipboard's React Canvas - https://github.com/Flipboard/react-canvas https://github.com/Flipboard/react-canvas Webpack also has great examples - https://github.com/webpack/react-starter https://github.com/webpack/react-starter
- ryanSrich 12y ago
  I had the opposite impression when looking at the React docs. JSX was intimidating and getting the quick examples to work resulted in several errors. JSX is of course optional, but the way that Angular just worked, without any non sense of installing anything, is what really drew me into the framework.
  - Bahamut 12y ago
    I agree - I find React has a higher initial overhead than Angular. Frontend web development is complex, so in the long run, the complexities will still show if you make a misstep. That said, I'm happy with my time so far with React. I haven't gone into nitty gritty engineering with it yet due to not having the time to start really coding on my project with it, but it has been fairly simple relatively speaking. I'm excited for Angular 2 though - the amount of planning going into it is excellent, and I believe it will also turn heads with its simplicity & performance. Frontend web development is seeing some exciting changes that should ultimately make our development ecosystem much better to work with.
forrestthewoods 12y ago
"and text editors have an insanely high bar to clear in terms of performance and responsiveness" For some reason that sentence really bothers me. Not because our standards are so high for text editors. But because they're so low for damn near everything else.
- NhanH 12y ago
  It might have something to do with the demographics. Text editor users are developers, power users, or at the very least, very tech savvy (there is also the other extreme of the spectrum, people who know nothing better, but you get my point). With that demographics, we (at least I know I do) tend to be more picky. The majority of people are content with coffee-making-loading-time for their OS, and the slug that is called Microsoft Word or Adobe Reader.
  - seanmcdirmid 12y ago
    MS Word is pretty responsive as an editor. Adobe Reader isn't even an editor.
  - veidr 12y ago
    I'm not a fan, but Microsoft Word 2013 is massively more performant than Atom, at any basic task that both programs do (launching, opening files, find/replace, etc).
- rtpg 12y ago
  For this sort of thing, with a fixed amount of developer time: - Performance - Stability - Actually working you can pick 2. Also, if you pick performace, 50% of the time you can only pick 1. Everything is a tradeoff but it's a lot easier to sell something slow than to sell something that doesn't work, and a lot of the performance costs are due to general techniques encoded in these frameworks that reduce bugs. Another thing is that things do get faster. I think V8 has gotten 10x faster (at least) on real code since its inception. And that's despite JS not having changed.
  - 12y ago
shubhamjain 12y ago
> I think React has potential. It's at about the same stage of maturity that Angular was five years ago, and if it's as successful, we can expect it to enjoy five years of being the new darling in the Javascript world, until the Next Big Framework comes around. React is something which stands astride on a line that divides a framework and library. I believe, like all good libraries out there, which do one thing and one thing well, React might stay for a longer period of time. At the first look of it, it might look heavy and bloated but it professes a far simpler view of building UIs. The best part is, just like jQuery, it didn't take me more than a few hours to get comfortable with React and incorporate it into building something, something that could have taken a few weeks with other frameworks. I am not saying there won't be anything better than this but I am sure it isn't just another hyped fad.
amelius 12y ago
The problem with React is that it doesn't improve the computational complexity of the problem. In fact, it makes the situation worse, since every little update is now O(n).
aikah 12y ago
> I enjoy seeing the latest fad being burned at the stake as much as the next guy You're talking about a project developed in Coffeescript. > I think their technical choice of going for Javascript will be their ultimate downfall, This is debatable. Editors like cloud9 have acceptable performances and webtechs allow one to distribute software right in the browser,which fits a huge number of use cases.
- PlzSnow 12y ago
  Why have "acceptable" performance, when I can have "stunning" performance (Sublime Text). I am a professional, and my tools should reflect this.
  - jessaustin 12y ago
    I am a professional, and my tools should reflect this. Then why aren't you using vim or emacs? b^)
  - Morgawr 12y ago
    Why have "stunning" performance when you can have "incredibly groundbreaking" performance (vim, emacs)?
  - elinchrome 12y ago
    Isn't the main complaint about sublime that it's slow once you add enough plug-ins to make it useful?
    - wtf_is_up 12y ago
      I don't think so.
sigzero 12y ago
Until it opens files bigger than 2MB, it's a non-starter for me to even look at.
boomlinde 12y ago
> Atom is a text editor, and text editors have an insanely high bar to clear in terms of performance and responsiveness. This "insanely high bar" has been easily cleared by text editors running on humble home computers for 30+ years. I'm not sure it qualifies as being insanely high.
- jerf 12y ago
  I think the point is not necessarily that "text editors intrinsically require gigabytes of RAM and gigahertz CPUs", but that they have "insane" latency requirements. On the one hand, yes, our computers ought to be able to handle text editing. On the other hand, as long as you meet the latency requirements one way or another it doesn't much matter whether you barely met them or utterly blew them out of the water by four orders of magnitude... instant is instant, to a human. A browser is a tough place to build a text editor. You're running a huge, complicated, sophisticated text rendering and typesetting environment, which you're using only a vanishing fraction of but the browser doesn't know that and can't much optimize for it. (Some, sure, I'm sure it's got special routines for monospaced text, but it still can't know you won't just stick a picture in the middle of it a moment from now.) You're running on top of a fairly slow language, even after all the optimization work on it [1]. You're running in an environment that is deeply structured to be synchronous so if you accidentally write a for loop over anything that turns out to be larger than you expected, you've frozen your environment until you're done, to say nothing of accidentally handing the browser a big rendering job ("did you just open a directory with 20,000 files? here, let me render that for you..."). Any of these things individually might be overcome, but the combination is quite challenging. It's nifty that the browser lets you run "anywhere" but it is also in a lot of ways a crazy place to try to build a programmer-quality text editor. [1]: I have to justify this every time I say it since somehow the idea that "Javascript is fast!" has sunk into the community, but it's not true. The easiest proof is asm.js... if Javascript was already "C-fast" or even close, it would not even exist. It exists precisely because Javascript is not a fast language. Javascript is much faster than it started out as, but it started out as an extraordinarily slow afterthought meant to run a statement or 4 in response to a mouse click. It has still stabilized on "much slower than C" and appears to have essentially plateaued. The result of speeding up something miserably slow by quite a bit can still result in something slow in the end.
taylorwc 12y ago
As someone who never really jumped into code until very recently, I find Atom far and away the most accessible text editor. Familiar interface (to a browser) and not overwhelming to set up. I've tried emacs, vim, and sublime. I'm sure that I could come to love emacs or vim, but it just seemed like too much messing with it before I would really enjoy it. Sublime is better, but I just prefer Atom. Guess that makes me some kind of radical minority here :)
- Guvante 12y ago
  > As someone who never really jumped into code until very recently Honestly your first code editor is always the best until you find a killer feature. Familiarity is huge.
  - taylorwc 12y ago
    Actually Sublime was the first one I tried. And I liked it quite a bit more than vim or emacs, perhaps due to being a noob. But I still preferred Atom to Sublime.
    - addicted44 12y ago
      If you will be programming professionally (or for significant amounts of time) learning either of emacs or vim is absolutely worth the effort. You will be very glad you did.
frik 12y ago
A WYSIWYG html or text editor with low latency is inbuilt in HTML5 called ContentEditable - though the implementation is in a sad state.
- frik 12y ago
  to downvoters: it was not against Atom, it was about the current state of contentEditable API: * http://caniuse.com/#search=contenteditable http://caniuse.com/#search=contenteditable * http://www.quirksmode.org/dom/execCommand.html http://www.quirksmode.org/dom/execCommand.html (and more info: https://blog.whatwg.org/the-road-to-html-5-contenteditable https://blog.whatwg.org/the-road-to-html-5-contenteditable ) Example editor: http://neilj.github.io/Squire/ http://neilj.github.io/Squire/

Goopplesoft 12y ago

> and to be honest, I think their technical choice of going for Javascript will be their ultimate downfall, but that's a discussion for another day I'd like to see this discussion today ;)

adrusi 12y ago
It's not javascript. Modern javascript engines (like v8 which powers Atom) are well beyond fast enough. GC can cause occasional latency if the programmer is lackadaisical with allocations, but with care it's a non-issue. But Atom simply will not achieve performance competitive with Sublime while they are using the DOM. The DOM is too general-purpose for what is almost always just a grid of monospaced text. The overhead introduced by allowing plugins to render entire webpages inline with the text is just too much. I want so very much to like Atom --- a Free text editor that isn't vim or emacs and is actually powerful enough to replace them, but the imperceivable latency manifests as a gradual accumulation of stress.
- jlongster 12y ago
  So much this. The DOM is absolutely going to be the bottleneck more than JavaScript. I can't really provide any concrete benchmarks to support this because its a very complex topic, and you can really only come to that conclusion after trying to optimize the DOM for something as critical as a text editor.
- vbit 12y ago
  Just curious - why replace vim or emacs?
  - pmontra 12y ago
    Don't tell me, because I use both (mainly emacs), but maybe is to do something like this https://confluence.atlassian.com/display/BITBUCKET/Edit+online https://confluence.atlassian.com/display/BITBUCKET/Edit+onli... It can be strategic even if limited to quick edits and for some subsets of the repository now. Anyway I can think of a GitHub augmented with an IDE and integrated with a CI and CD system with deployment to a Heroku. It could let you write code from pretty everywhere, occasionally even on a tablet or a large phone. Somebody will use it.
    - couchand 12y ago
      GitHub has been slowly tricking me into doing more and more of those quick edits on their site. If they can work Atom in as seamlessly as their other updates I'm sold. Somehow I'm still circumspect.
  - crazychrome 12y ago
    emacs doesn't have decent support of jsx: the jsx-mode is actually for another tech with same name, the js2-mode is great except xml support. i love vim a lot (use evil in emacs), except vimscript. I hope oneday I could use neovim with atom/st2 as frontend.
    - mrkipling 12y ago
      I use web-mode to edit JSX. It's not bad at all actually - the indentation and highlighting are there. I've started using web-mode for its intended purpose, too (when editing templates that have CSS and JS snippets).

mcbutterbunz 12y ago

> I'm really enjoying how fast Javascript frameworks and practices are churning, it makes me feel like I'm witnessing the birth of a brand new software field with my very eyes. I totally agree. A language or technology that doesn't change is dead. The JS world can get a crazy sometimes but we need to understand WHY certain frameworks/patterns may be better and when to apply them. Kudos to the Atom team on making their product better.

zghst 12y ago

React is so much different from other frameworks, I feel. Someone that doesn't know React can basically come in and start working on a large app from Day 1. It is so much less frustrating than Angular, Backbone + Ember + handlebars, etc. You can continue to add features to a React application and not slow down. Also React isn't unproven. Over 1 Billion people use a React application everyday (Facebook + Instagram web). Unlike Google with Angular, React is Facebook's baby, the FB team is constantly churning out great additions to React. I feel though with these JS editors, they should just basically give up for the next 5 years or so. Switching between Atom / Brackets to Sublime or Vim is extremely painful, I can't stand how slow it is. I love adopting new technologies, but I do not have faith in JS applications outside of a browser, they are too slow and lack in features.

jsprogrammer 12y ago
Do you know of a large open source react application that I can take a look at?
- zghst 12y ago
  Check this list on on the React repo: https://github.com/facebook/react/wiki/Examples https://github.com/facebook/react/wiki/Examples Noteworthy, Flipboard's React Canvas - https://github.com/Flipboard/react-canvas https://github.com/Flipboard/react-canvas Webpack also has great examples - https://github.com/webpack/react-starter https://github.com/webpack/react-starter
ryanSrich 12y ago
I had the opposite impression when looking at the React docs. JSX was intimidating and getting the quick examples to work resulted in several errors. JSX is of course optional, but the way that Angular just worked, without any non sense of installing anything, is what really drew me into the framework.
- Bahamut 12y ago
  I agree - I find React has a higher initial overhead than Angular. Frontend web development is complex, so in the long run, the complexities will still show if you make a misstep. That said, I'm happy with my time so far with React. I haven't gone into nitty gritty engineering with it yet due to not having the time to start really coding on my project with it, but it has been fairly simple relatively speaking. I'm excited for Angular 2 though - the amount of planning going into it is excellent, and I believe it will also turn heads with its simplicity & performance. Frontend web development is seeing some exciting changes that should ultimately make our development ecosystem much better to work with.

forrestthewoods 12y ago

"and text editors have an insanely high bar to clear in terms of performance and responsiveness" For some reason that sentence really bothers me. Not because our standards are so high for text editors. But because they're so low for damn near everything else.

NhanH 12y ago
It might have something to do with the demographics. Text editor users are developers, power users, or at the very least, very tech savvy (there is also the other extreme of the spectrum, people who know nothing better, but you get my point). With that demographics, we (at least I know I do) tend to be more picky. The majority of people are content with coffee-making-loading-time for their OS, and the slug that is called Microsoft Word or Adobe Reader.
- seanmcdirmid 12y ago
  MS Word is pretty responsive as an editor. Adobe Reader isn't even an editor.
- veidr 12y ago
  I'm not a fan, but Microsoft Word 2013 is massively more performant than Atom, at any basic task that both programs do (launching, opening files, find/replace, etc).
rtpg 12y ago
For this sort of thing, with a fixed amount of developer time: - Performance - Stability - Actually working you can pick 2. Also, if you pick performace, 50% of the time you can only pick 1. Everything is a tradeoff but it's a lot easier to sell something slow than to sell something that doesn't work, and a lot of the performance costs are due to general techniques encoded in these frameworks that reduce bugs. Another thing is that things do get faster. I think V8 has gotten 10x faster (at least) on real code since its inception. And that's despite JS not having changed.
- 12y ago

shubhamjain 12y ago

> I think React has potential. It's at about the same stage of maturity that Angular was five years ago, and if it's as successful, we can expect it to enjoy five years of being the new darling in the Javascript world, until the Next Big Framework comes around. React is something which stands astride on a line that divides a framework and library. I believe, like all good libraries out there, which do one thing and one thing well, React might stay for a longer period of time. At the first look of it, it might look heavy and bloated but it professes a far simpler view of building UIs. The best part is, just like jQuery, it didn't take me more than a few hours to get comfortable with React and incorporate it into building something, something that could have taken a few weeks with other frameworks. I am not saying there won't be anything better than this but I am sure it isn't just another hyped fad.

amelius 12y ago

The problem with React is that it doesn't improve the computational complexity of the problem. In fact, it makes the situation worse, since every little update is now O(n).

aikah 12y ago

> I enjoy seeing the latest fad being burned at the stake as much as the next guy You're talking about a project developed in Coffeescript. > I think their technical choice of going for Javascript will be their ultimate downfall, This is debatable. Editors like cloud9 have acceptable performances and webtechs allow one to distribute software right in the browser,which fits a huge number of use cases.

PlzSnow 12y ago
Why have "acceptable" performance, when I can have "stunning" performance (Sublime Text). I am a professional, and my tools should reflect this.
- jessaustin 12y ago
  I am a professional, and my tools should reflect this. Then why aren't you using vim or emacs? b^)
- Morgawr 12y ago
  Why have "stunning" performance when you can have "incredibly groundbreaking" performance (vim, emacs)?
- elinchrome 12y ago
  Isn't the main complaint about sublime that it's slow once you add enough plug-ins to make it useful?
  - wtf_is_up 12y ago
    I don't think so.

sigzero 12y ago

Until it opens files bigger than 2MB, it's a non-starter for me to even look at.

boomlinde 12y ago

> Atom is a text editor, and text editors have an insanely high bar to clear in terms of performance and responsiveness. This "insanely high bar" has been easily cleared by text editors running on humble home computers for 30+ years. I'm not sure it qualifies as being insanely high.

jerf 12y ago
I think the point is not necessarily that "text editors intrinsically require gigabytes of RAM and gigahertz CPUs", but that they have "insane" latency requirements. On the one hand, yes, our computers ought to be able to handle text editing. On the other hand, as long as you meet the latency requirements one way or another it doesn't much matter whether you barely met them or utterly blew them out of the water by four orders of magnitude... instant is instant, to a human. A browser is a tough place to build a text editor. You're running a huge, complicated, sophisticated text rendering and typesetting environment, which you're using only a vanishing fraction of but the browser doesn't know that and can't much optimize for it. (Some, sure, I'm sure it's got special routines for monospaced text, but it still can't know you won't just stick a picture in the middle of it a moment from now.) You're running on top of a fairly slow language, even after all the optimization work on it [1]. You're running in an environment that is deeply structured to be synchronous so if you accidentally write a for loop over anything that turns out to be larger than you expected, you've frozen your environment until you're done, to say nothing of accidentally handing the browser a big rendering job ("did you just open a directory with 20,000 files? here, let me render that for you..."). Any of these things individually might be overcome, but the combination is quite challenging. It's nifty that the browser lets you run "anywhere" but it is also in a lot of ways a crazy place to try to build a programmer-quality text editor. [1]: I have to justify this every time I say it since somehow the idea that "Javascript is fast!" has sunk into the community, but it's not true. The easiest proof is asm.js... if Javascript was already "C-fast" or even close, it would not even exist. It exists precisely because Javascript is not a fast language. Javascript is much faster than it started out as, but it started out as an extraordinarily slow afterthought meant to run a statement or 4 in response to a mouse click. It has still stabilized on "much slower than C" and appears to have essentially plateaued. The result of speeding up something miserably slow by quite a bit can still result in something slow in the end.

taylorwc 12y ago

As someone who never really jumped into code until very recently, I find Atom far and away the most accessible text editor. Familiar interface (to a browser) and not overwhelming to set up. I've tried emacs, vim, and sublime. I'm sure that I could come to love emacs or vim, but it just seemed like too much messing with it before I would really enjoy it. Sublime is better, but I just prefer Atom. Guess that makes me some kind of radical minority here :)

Guvante 12y ago
> As someone who never really jumped into code until very recently Honestly your first code editor is always the best until you find a killer feature. Familiarity is huge.
- taylorwc 12y ago
  Actually Sublime was the first one I tried. And I liked it quite a bit more than vim or emacs, perhaps due to being a noob. But I still preferred Atom to Sublime.
  - addicted44 12y ago
    If you will be programming professionally (or for significant amounts of time) learning either of emacs or vim is absolutely worth the effort. You will be very glad you did.

frik 12y ago

A WYSIWYG html or text editor with low latency is inbuilt in HTML5 called ContentEditable - though the implementation is in a sad state.

frik 12y ago
to downvoters: it was not against Atom, it was about the current state of contentEditable API: * http://caniuse.com/#search=contenteditable http://caniuse.com/#search=contenteditable * http://www.quirksmode.org/dom/execCommand.html http://www.quirksmode.org/dom/execCommand.html (and more info: https://blog.whatwg.org/the-road-to-html-5-contenteditable https://blog.whatwg.org/the-road-to-html-5-contenteditable ) Example editor: http://neilj.github.io/Squire/ http://neilj.github.io/Squire/