Two Years Open Source | Hacker News Reader

Two Years Open Source

blog.atom.io

118 pointsokket56 comments

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 think you must be confused... Atom is the reason Electron exists, they were created in-tandem like Rails and Basecamp.

Electron is kinda like a browser anyway, you can even open Chromium's dev tools like you would in Chrome.

They haven't precluded Atom from running in a browser, they literally built it in a browser and they just don't have it online.

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.

You will almost certainly have better luck with running VS Code in the browser. The editor core was originally developed to be used for Visual Studio Online as its built-in web editor: https://www.visualstudio.com/en-us/products/what-is-visual-s...

I had no idea VS Code was actually open-source (MIT)... been using it as my favorite editor for what seems like close to a year now.

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.

This comment isn't going to help.

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

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.

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.

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.

You must not use atom. That or you must really hate url bars and back buttons. Otherwise I don't understand this comment.

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

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.

From what I've seen Atom needs to do some perf work and also integrate some perf monitoring tools, especially for addons.

Other than that: kudos for the great OSS project!

I think the "Atom is slow" meme needs to die.

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.

The slowness I have noticed and bothers me is on the startup time. Other than that its OK.

I tried atom a few months ago and it was slow. Loaded it up yesterday and I'm thinking of switching if only I could get decent autocomplete working.

Curious what problems you have with the autocomplete. I haven't had any serious issues with it (yet).

I wish there was a good C++ autocomplete package that's compatible with Nuclide's remote projects.

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.

There's You Complete Me[1], which will do: C, C++, C#, Go, JS, Obj-C, Obj-C++, Python, Rust, Typescript, and filesystem entries.

[1]: https://atom.io/packages/you-complete-me

Not to derail you, but you may want to give VS Code a try too... been my default editor for a while now... love the git integration.

using VS code now. It's great, but came back to atom to see if things changed

I love Atom, but it is noticeably slower than VS Code when editing, especially when autocomplete is involved.

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.

>a few hundred cursors

Dear god.

Just tried loading a 6MB json log, and it froze Atom horribly. On a nice laptop, less than 6 months old. Not sold yet.

Waiting for VS Code to implement tabs then will give that a more serious look.

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

I need tabs too ...

I wrote a post about setting up Atom for web development around a year ago:

http://www.developingandstuff.com/2015/04/setting-up-atom-fo...

after using it for around a year.

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.

Sublime text's search needs work, but on a huge project you often need a dedicated search tool anyway (or plugin for one).

IME the search isn't really what people complain about for atom's perf. Certainly isn't what keeps me from using it.

If only it weren't true.

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.

Atom still has a memory/cpu/power consumption problem that requires restarting to fix. A quick google returned a number of active issues on Github.

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 also has some of the highest latency when typing. By a large margin. https://pavelfatin.com/typing-with-pleasure/

So no. Atom is still a slow piece of shit. It's not a meme. It's a verifiable fact.

Sorry.

Please don't spoil an otherwise substantive comment by calling names ('piece of shit'). The HN guidelines specifically ask not to do this.

Do you have a link to your blog post?

"fast"

Wtf world do you live in?

It will die when it is no longer true.

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'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 if you are using a text editor to browse 50mb logs you are probably doing it wrong. Try grep.

Except text editor can handle it. Notepad++ eats that for breakfast.

When I am browsing files that big I often don't know exactly what I'm looking for. They're multiline entries, and Not easy to parse

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.

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 is what you're looking for.

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

Personally my top wish for this project is them handling standard in.

https://github.com/atom/atom/issues/1729

It's really the one big thing that keeps me on native editors.

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.

Atom's great. I admit to chuckling when I read jokes at node programmers' expense. But it's really good editor IMO. Feature rich, just works.

I almost completely switched from Atom to VSCode because of performance and nice IntelliSense for JS.

Reading this thread I gave a Atom another shot, uninstalling all plugins, and damn, how much faster it is :) I can open big files easily now.

I just saw their Atom 1.0 promo video (click on the link on the home page) and I loved it.

Reply on news.ycombinator.com