I love Atom, and use it every day. (Happy anniversary Atom!)
But I don't get one very big thing about Atom: why is it so intimately tied to Electron?
Coming from a company that has a huge web site dealing in source code, and that even has a source code editor embedded in it, I can't understand why they would preclude Atom from running in a browser. Github offering online-IDE functionality seems like a such a natural extension to their business.
I'm not confused, I know the lineage of Atom, Atom Shell and Electron. I also write apps that run in Electron and the browser with only minor differences.
As a product and a set of building blocks for an IDE, I still don't understand why they would be tied so closely to web-incompatible APIs.
I've tried to get parts of Atom running in a browser, and it's pretty damn hard. Many parts of Atom directly call node APIs and assume synchronous APIs where async would be the only option on the web.
Plugins wouldn't work because they require installing node modules during runtime. Accessing the file system wouldn't work. Any multiprocessor support wouldn't work. I guess I don't see the point in an online editor.
I'm building an electron app that's web compatible and you lose a lot making it work for both and it requires a lot of planning to make feasible.
Hmmm! When you enquired about the intimate link to Electron, I assumed that it was because you'd prefer a native interface (GTK+, ncurses, etc.), not because you wanted it in the browser.
I can confidently say that I hope that I never have to use a text editor inside my browser.
So a big part of IDE features rely on the Node-y native access that Electron gives (for example calling out to external programs). You _could_ have things like syntax highlihgting, but it would end up being pretty crippled in the browser.
> I can't understand why they would preclude Atom from running in a browser.
If memory serves me right, I believe it was conceived to be a standalone commercial product, with tight GitHub integration; but somewhere a long the line, it became a free open source project that it is today.
I still don't understand why so much effort is being put into an editor though. I'm guessing people are drawing a comparison with the web browser war, with who owns the editor, will own the developer mind share.
The three applications I use every single day without fail are an editor, an email client and a web browser (I'm a developer/sysadmin). If you provide one of those, I'm going to see your brand all the time, even if I'm not directly aware of it. That's quite a powerful position to be in.
GitHub does get huge mindshare from Atom. For packages to be included in Atom's repos, they need to be at GitHub, lots of stuff in Atom assumes GitHub etc. etc.
I've taken on a curiosity of getting Atom to work in ChromeOS (natively, not with crouton or other developer mode solutions). It's just a curiosity at this point, I make no promises. But I'd think if Atom could jump to another environment besides Electron, then getting it inside a browser wouldn't be much more work.
Downvotes because I'd like to use Atom in a browser? Stay classy HN.
edit: If you think Atom, or parts of it, running in a browser is a _bad_ idea, maybe say why rather than just click a little down arrow.
I'll point out that GitHub embeds Ace when editing files. Ace is pretty good for quick edits, but Atom's editor is better, as is the whole package of UI. From editing from Chromebooks, to tighter git and GitHub integrations, Atom on the web could do a lot of good. If I were GitHub, I'd look to take advantage of the awesome work done on Atom in the core business somehow.
Obviously, if you are loading 100s of random extensions made by fledgling JS programmers you are gonna have a bad time. Obviously if you load a 2gb text file and try to syntax highlight it, you're gonna have a bad time.
The core editor is fast, looks great, and is stupid extensible. Yeah, it's not vim fast, and yeah it won't fly on your dads old compaq, but it's fast enough not to care at this point.
I try it out of the box every so often and it is slow. Slow enough to keep me on Sublime, even though Atom has a much better plugin API. Everything looks great until I try to use a few hundred cursors at once or load a large file and then it grinds to a halt. There is also a general lagginess to the interface that is hard to pin down.
I vastly prefer the working files list in the VS Code sidebar over any traditional horizontal tabbed interface. The overall functionality is practically same, but having a vertical file list makes much better use of horizontal space (vertical space is generally at a much higher premium for widescreen displays) and handles use cases where a large number of files are open much better (having too many files open doesn't preclude you from seeing the whole filename). I much prefer using Firefox with Tree Style Tabs over regular horizontal tabs for mostly the same reasons. However, I agree that they should offer the option for horizontal tabs those who find it more familiar.
I've never had a problem with VS Code's performance, but VS Code itself is also not without issues though. For instance, this is the one that often leaves me no choice but to open another editor: https://github.com/Microsoft/vscode/issues/1690
No, Atom is still slow. I opened a 150kb JavaScript file yesterday which brought it to its knees. VSCode, which is also based on Electron handles the same file seamlessly. Atom has a long way to go.
I mainly write JS. With vs code I can get some basic autocomplete with type script files (typings) and it autocompletes my own JS (including Docs). Atom will only show generic auto completion and won't even autocomplete my own files. I've given ternJS a try but can't seem to get it working.
I love atom. However, I use VS Code, because atom is slow. I am primarily a JS developer and often have to interact with bundled js files. Atom freezes for 10+ seconds whenever ever so much as click on a bundled file, while VS Code is instant. Moreover, sometimes I like to have 2 instances of the editor open (one for each the client and server). When I do this with atom, my laptop's performance is visibly affected.
So at least in my case, the '"Atom is slow" meme' is still relevant.
I'm sick of the meme but I agree with it. I think it needs to be put away for a little while because it's just noise. We know some people feel it's too slow for them. We don't need the same comment on every thread discussing atom.
To reply directly to your comment though, sublime is much faster when first opening the application, regardless of extensions. That, and the fact I use sublime for browsing log files on the order of 10-50mb keeps me from jumping.
I think what's more important about Atom's speed is not the speed itself, but the rate at which it increases. Atom was slow 2 years ago, became faster 1 year ago, and today is faster than that. On the other hand, Sublime Text, on a similarly specced computer (of a colleague), today, seems much slower, for example, when doing a project-wide search.
On a fresh, OOTB El Capitan install, with an identical plugin load to what I use on vim, atom takes a good 5-6 seconds to appear, and a few more to become usable.
Atom is objectively slow, compared to its competition.
Atom starts up really slow, but I restart it maybe once a week. It's the same as emacs; when you spend hundreds of hours in the same editing session, who gives a shit about 8 seconds you paid 7 days ago?
I wouldn't call Atom slow in general use, post-startup, which is all I really care about anyways.
I wrote a blog post where I reverse engineered Sublime Text's fuzzy match. One of my test cases was a C file with single line functions. I think there were about 16000 lines. Both Sublime and my algorithm ran in under 100 milliseconds.
Atom also has a fuzzy match algorithm. It hard froze the editor for over 5 seconds while matching.
Atom already has this integrated, not as a plugin, but right into the editor. I cannot recall where at the moment, but you can get a list of every package, and it'll list the startup time in milliseconds.
Timecop - but it has a huge weakness in that the startup time before the main window appears is not counted. I can use a stopwatch and get about 8 seconds, while timecop only shows me ~1100ms, and plugins account for maybe ~100ms of that.
Happy Anniversary Atom. I switched from Sublime over a year ago and love it.
Never had an issue with slow performance, and I am using it on an 8 year old MacBook Pro, lol.
Then again, I keep my plugins to a minimum (around 10 or 12 I think), and I also tend to keep my code in small files of around 100 - 400 lines of code per file. I routinely work in 6 to 10 open files at once, but never had a slowness issue.
The 2 or 3 occassions where I've had to open a humongous log file, I've just resorted to TextEdit or Sublime...
I really love working with Atom and almost completely switched from sublime text.
One problem I ran into lately quite often is that there seem to be shared resources with Chrome/Chromium on Ubuntu 14.04. Sometimes Chrome plugins and Atom crash at the same time and I know of another Ubuntu installation where Chrome and Atom are having weird graphic glitches which render the computer unable to work with.
But I don't get one very big thing about Atom: why is it so intimately tied to Electron?
Coming from a company that has a huge web site dealing in source code, and that even has a source code editor embedded in it, I can't understand why they would preclude Atom from running in a browser. Github offering online-IDE functionality seems like a such a natural extension to their business.