Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The State of Atom's Performance

blog.atom.io

Post reply on HN
Print view View original

171–180 of 293 posts

Re: The State of Atom's Performance

#171

Post by styfle »

stupidcar wrote: post #69
smacktoward wrote: post #51

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…

The thing is, are those alternative toolkits better ? Done right, they're faster, for sure. But when you use Electron you're leveraging thousands of man-years of Google developer effort to build a web browser that works consistently and well across different platforms. Although the web platform gets a bad rep for cross-browser compatibility problems and general weirdness, a huge amount of that goes away when you targ…

Yeah, this is is actually one of the reasons I used Electron for a screen-recording project...because most browsers didn’t implement the experimental screen recording APIs yet but Chrome already had it.

https://github.com/styfle/magnemite

Re: The State of Atom's Performance

#172

Post by rubyn00bie »

subsection1h wrote: post #160
rubyn00bie wrote: post #156

Earlier quoted context omitted.

My general dislike for Atom wasn't anything to do with the editor itself, I've just always been sore they used CoffeeScript which is a language I personally _loathe_. I was excited to have a sublime replacement I could hack on, but that killed it for me. It was that it was so inaccessible and for such a asinine reason (a language purely for syntactical sugar). JavaScript is the lingua franca of the internet for fucks…

> CoffeeScript which is a language I personally _loathe_. [...] it was so inaccessible You know JavaScript, yet CoffeeScript is inaccessible? WTF. I had never written a line of Lisp in my life before using Emacs, but that didn't stop me from writing hundreds of lines of Emacs Lisp during the first weekend that I used Emacs. What's up with the unwillingness (or inability?) that many web developers seem to have for usi…

Why would I learn something which doesn't offer me any value? CoffeeScript is literally syntactical sugar, which I believe, adds levels of indirection to the code and makes it more difficult long-term to support, read, and develop. Not only that, but JavaScript's evolution has made nearly every reason to use it moot.

Also FWIW-- I've done vastly more native and server-side programming over the last... oh, seven years than "web." So... I don't think this is something with "web developers."

Re: The State of Atom's Performance

#173

Post by maddyboo »

joehewitt wrote: post #25

Don't get all the gripes about slow startup time. How often do you launch your editor? We're programmers - the editor stays open all the time!

I launch instances of neovim all the time. So often that I have a keybinding for it (super + v). It launches and is ready to use in under 500ms.

Re: The State of Atom's Performance

#174

Post by jopsen »

styfle wrote: post #170
redwall_hp wrote: post #94

Earlier quoted context omitted.

Is it really bandwagonning to be annoyed that so many bits of software, which many people run simultaneously, use a tool where a Hello World is over 100MB in memory? At least the Electrino idea is more reasonable. Using a framework already loaded into memory by the OS and sharing it would go a long way toward reducing the bloat...though not toward the horrible battery problems it introduces. Seriously, people are sti…

Electrino was a great idea, but the project was more of a POC and I haven’t seen any new development. So until someone can build a production ready, cross platform, JS desktop experience....Electron will live on.

On android I think both Chrome and Firefox supports installing a website as an icon on the home screen.

It might already hide the address bar when opened in this mode. I personally expect that it's just a matter of time before this becomes an install mode for desktop apps as well.

Re: The State of Atom's Performance

#175

Post by flukus »

jopsen wrote: post #174
styfle wrote: post #170

Earlier quoted context omitted.

Electrino was a great idea, but the project was more of a POC and I haven’t seen any new development. So until someone can build a production ready, cross platform, JS desktop experience....Electron will live on.

On android I think both Chrome and Firefox supports installing a website as an icon on the home screen. It might already hide the address bar when opened in this mode. I personally expect that it's just a matter of time before this becomes an install mode for desktop apps as well.

When I check where my battery life is disappearing will these apps appear under Firefox/chrome or the app name?

It sounds like a promising avenue for bitcoin mining.

Re: The State of Atom's Performance

#176

Post by Veedrac »

taeric wrote: post #154
Veedrac wrote: post #149

Earlier quoted context omitted.

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

The only one of those I'm not sure on is the expose one. The rest seem like they already exist in emacs. It is probably mentioned in every editor thread, but org-mode is enough magic with an editor to mystify most developers. Syntax highlighting for multiple languages in a single file is already stretching most boundaries.

Forgive me for being skeptical. Where is this git-time-machine equivalent?

Re: The State of Atom's Performance

#177

Post by maskedSlacker »

lolc wrote: post #115
HumanDrivenDev wrote: post #99

Earlier quoted context omitted.

VSCode is really bizzare, in a good way. All the configuration is done through JSON files. It's a good editor as well as an IDE. There's no "projects" or "solutions" or wizards. I almost never run into issues with it. It doesn't feel like a microsoft product at all. Nothing like Visual Studio.

Maybe I should give VSCode a try then. I've been using Atom for a year now and some things just never felt good.

VSCode won me over grudginly. It's faster, lighter, and just as extensible. I was conditioned at an early age to throw holy water at anything Microsoft, and still, I like VSCode better than Atom.

Re: The State of Atom's Performance

#178

Post by draw_down »

shaki-dora wrote: post #95

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

I could see why extension authors enjoy access to everything and the ability to run wild. But that is less interesting to users of extensions.

Re: The State of Atom's Performance

#179

Post by maskedSlacker »

gt_ wrote: post #168
Lev1a wrote: post #155

Earlier quoted context omitted.

Even I (as someone who has a profound hatred for MS and their business practices) have to admit that VSCode is vastly superior to Atom, which is why I have used the former instead of the latter for a long time.

Weird question, I know, because I use VS Code as well, every day for about 6 months and love it, but, I’ve never used these other popular editors. What makes VS Code so much better? I chose it because it had some integration with DCC apps I use use, and I like the GUI and general simplicity. What other reasons do people have for loving it?

Relative to Atom, which I left for VS Code: Code is faster and lighter, just as extensible. Better git integration and code analysis, even for Javascript (I finally understand what devs from other languages were talking about!). My workflow is just smoother for everything except Clojure and system admin (but I use emacs for those, atom isn't any better there).

Re: The State of Atom's Performance

#180

Post by kalcode »

kalcode wrote: post #147
taternuts wrote: post #129

Earlier quoted context omitted.

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.

*wasn't one of the major slow downs
Post reply on HN