Live data from Hacker News

The State of Atom's Performance

blog.atom.io

141–150 of 293 posts

Re: The State of Atom's Performance

#141

Earlier quoted context omitted.

I would phrase the problem slightly differently: not "I want to use the technologies that make me enjoy my job," but "I want to use the technologies that I already know. " Electron is popular because it lets you write desktop apps in JavaScript, and there are a lot of developers out there who know JavaScript. By going with Electron, those developers can build desktop apps without having to learn anything new. They ca…

> This "I don't have to learn anything new" factor is literally the only thing Electron has going for it. Not completely, don't underestimate how hard it is to write a cross platform UI that runs on Windows, OSX and Linux. Starting from a web framework not only gives you portability but also a common UI language(that may diverge a bit from native app conventions but that's a tradeoff you need to weigh). I say this as…

The other thing to keep in mind is that a similarly script-extensible Qt application carries the weight of Qt shared libraries, plus scripted wrapper shims. This can easily run 25-40 MB in Python-Qt systems, at which point 70 MB for Electron looks much less crazy.

(also a C++/Qt dev, jealously eyeing love preview, hot-reloading, and other niceties).

Re: The State of Atom's Performance

#142
post #78

Earlier quoted context omitted.

I tried out Atom and found its "hackability" sorely lacking compared to Emacs. Which made me sad, because it's the only new-gen editor to really claim to be "hackable". Specifically, what I'm looking for in an editor is the ability to introspect most/all of the editor's internals from the editor itself (including documentation, debugging, live modification of the editor, etc.). In Emacs, all of that is just a few key…

> a truly "hackable" editor a la Emacs, built on a web stack like Electron, would make me giddy with excitement. Why? I would much rather a truely "hackable" editor a la emacs, built on a native stack. Like emacs. (And I say this as a vim user).

Because building attractive UIs and doing graphical things is much easier on a web stack. Emacs can run in a terminal emulator, but as an editor in a development environment, that's not a use case I've ever had. I'd much rather be able to seamlessly plot some data with vega.js or slap together a quick UI for a tool, or be able to trivially inline images, animations, videos, PDFs, etc. without having to fiddle with native libs.

Re: The State of Atom's Performance

#143

Why has Hacker News become such a hotbed for cynicism, ridicule and snark by which almost none comes constructive ideas? I along with many of my fellow engineers use Atom everyday and love it. Sure it has some shortcomings but if anything this retrospective from the Atom team shows that they're trying to address those shortcomings at a rapid clip. I love that it's an entirely open source system and that it is written…

Just like with every forum, circle jerks reign supreme

Re: The State of Atom's Performance

#144

Why has Hacker News become such a hotbed for cynicism, ridicule and snark by which almost none comes constructive ideas? I along with many of my fellow engineers use Atom everyday and love it. Sure it has some shortcomings but if anything this retrospective from the Atom team shows that they're trying to address those shortcomings at a rapid clip. I love that it's an entirely open source system and that it is written…

Personally, Atom is not my editor of choice (team Sublime!), but I really hope Atom succeeds. I do love it's hackability, and I would much rather have my plugins in JS, but alas, it's just not fast enough for me, yet.

However I held onto Textmate until 2010 and Sublime wore me down, so I'm a laggard as well.

So no negativity from me, because I just want a great editor that I can control and hack on. But I'll be real, I don't see it happening for a little bit. If sublime were to support JS plugins, I fear Atom might be in trouble at that point, TBH.

Re: The State of Atom's Performance

#145

It must be tough to see how quickly the community turns on you when something better (in some ways) comes around. Atom clearly offered something that struck a chord when it initially appeared. I remember having an idea, and implementing it as a plugin, all within a lazy Sunday afternoon. This allowed the ecosystem to flourish, and new ideas being extremely easy to at least prototype. It also allowed unprecedented[0]…

Microsoft has a ton of experience with misbehaving third party developers. Distrust of code written by others is by now a second nature to them. I am sure that they would have gotten this right even without Atom falling into the "open internals" trap first.

Which, to be fair is understandable on Microsoft's part. Blindly trusting others to create in your ecosystem while novel, is a _very_ scary place to be if you are the one who has to answer to the shortcomings of the platform

Re: The State of Atom's Performance

#146

Why has Hacker News become such a hotbed for cynicism, ridicule and snark by which almost none comes constructive ideas? I along with many of my fellow engineers use Atom everyday and love it. Sure it has some shortcomings but if anything this retrospective from the Atom team shows that they're trying to address those shortcomings at a rapid clip. I love that it's an entirely open source system and that it is written…

Just like with every forum, circle jerks reign supreme

[deleted]

Re: The State of Atom's Performance

#147

Earlier quoted context omitted.

That doesn't make sense...the browser always does the rendering of the dom. Not react. React speed when keeping your states and data in sync is that React makes all changes to the virtual dom then it makes it to the browser dom. It not different then the concept of batching graphic changes in a 2d game. You blit batches of sprites that need to be changed around the same frame instead of making 500 draw calls you make…

If a bottleneck is dom manipulation, then something that smartly batches them and reduces the number of times it's called would help. How would that not apply to Atom?

Because they already implemented something similar as per the blog post.

React has an implementation of a virtual Dom. They don't have to use react to do that and as discussed in the blog that is the major slow down on their UI.

Re: The State of Atom's Performance

#148

Why has Hacker News become such a hotbed for cynicism, ridicule and snark by which almost none comes constructive ideas? I along with many of my fellow engineers use Atom everyday and love it. Sure it has some shortcomings but if anything this retrospective from the Atom team shows that they're trying to address those shortcomings at a rapid clip. I love that it's an entirely open source system and that it is written…

> Why has Hacker News become such a hotbed for cynicism, ridicule and snark by which almost none comes constructive ideas?

The moderators have almost certainly played a part. Selectively permitting snark from the in-group is easy in the short run, but eventually incurs a cost to the community.

Re: The State of Atom's Performance

#149
post #2

Atom takes longer to start up than text editors like Vim and Sublime Text because of the dynamic architecture of the app And yet Emacs is fast, hmmm.

Emacs doesn't offer a fraction of the graphical flexibility that Atom does. How would you do any of the below?

https://benmccormick.org/2016/01/11/the-most-interesting-ato...

Re: The State of Atom's Performance

#150

Why has Hacker News become such a hotbed for cynicism, ridicule and snark by which almost none comes constructive ideas? I along with many of my fellow engineers use Atom everyday and love it. Sure it has some shortcomings but if anything this retrospective from the Atom team shows that they're trying to address those shortcomings at a rapid clip. I love that it's an entirely open source system and that it is written…

> Why has Hacker News become such a hotbed for cynicism, ridicule and snark by which almost none comes constructive ideas? The moderators have almost certainly played a part. Selectively permitting snark from the in-group is easy in the short run, but eventually incurs a cost to the community.

s/in-group/in-meme

Apple products are bad now despite having a pretty similar rate of technical glitches they always did

It’s just the changes impact the HN crowd more now so complaining em masse is allowed

It’s meme-tribalism

No one wants to be the one to have to give up on their meme

Post reply on HN