Live data from Hacker News

The State of Atom's Performance

blog.atom.io

201–210 of 293 posts

Re: The State of Atom's Performance

#201
post #97

I am not badmouthing JavaScript or bandwagoning on the "Electron is the devil. Long live native apps!" But I've been wondering more and more, especially through my own experienced biases at work: how much of the, "we chose x because y and z" is retroactive justification for the simple truth: "I wanted to use the technologies that make me enjoy my job." I often have to fight with myself to pick the right tool for the…

Here are some more reasons to pick a technology: Familiarity, knowledge transfer is a big drive for technology adoption. The bad bit is when the decision maker leaves the team and the rest are unfamiliar with the tech. I think this applies to Electron pretty well as web developers can now contribute. The "it would look good on my CV". I'm thinking about Kubernetes where it doesn't make sense to use most of the time b…

Thanks to Docker and Kubernetes, everyone that cares about DevOps needs to brush up their Go skills, regardless how we might think about it.

However this is a part of being professional, using the required tools for the job.

Re: The State of Atom's Performance

#202

I do go back to Atom often because of a few details that I like better over VS Code, but it's a lost cause, and reading this proves it. Who cares about start-up time? I only open the thing once/day. Same thing for large files: it's a edge case. Memory usage? Sure, but as developers we probably have GB and GB sitting there, if the thing worked it wouldn't be a big deal for the most important tool in your arsenal. What…

> Who cares about start-up time? I only open the thing once/day.

I care.

I live in three editors: Xcode for iOS/Mac/Swift on server development, VS Code for Rust, Go and Python, and Sublime for a thing that starts up fast, opens new windows fast and can deal with huge amounts of text. I wouldn't mind reducing that number to two, but it doesn't seem likely to happen anytime soon.

Re: The State of Atom's Performance

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

These days. 20 years ago people hated on Emacs for the same reasons they hate on Atom now.

So we are getting a text editor with the features of a 20 years old application, using enough memory to run several Emacs instances.

Re: The State of Atom's Performance

#204

Earlier quoted context omitted.

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

yeah, I could see myself saying the same but not about coffeescript. That thing just needs to go away, seriously. Having to constantly keep a mental model of two languages when you write code outweighs any benefits from syntax sugar and supposed readability. It was nice ten years ago when JavaScript was absolutely horrendous but not now.

> It was nice ten years ago when JavaScript was absolutely horrendous but not now.

ECMAScript 5 was released in December 2009, Coffeescript first appeared the same month with release 0.1.0.

What was absolutely horrendous about ECMAScript 5?

edit: Javascript 1.8 shipped with Firefox 3 in June 2008.

Re: The State of Atom's Performance

#205

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

>It must be tough to see how quickly the community turns on you when something better (in some ways) comes around.

I agree, and i want to like atom. I love the motivation and i love how they have moved the "friendlier than VIM but not quite an IDE" market forward, because that's exactly the sort of editor I want.

but ultimately i'm trying to do a job, and that job is a lot easier when i'm not waiting for a text editor to catch up to my keystrokes. Even if it is some plugin's fault and not actually Atom's fault that the editor is slow, I don't have time to troubleshoot that when other editors don't let plugins screw up the editor.

Re: The State of Atom's Performance

#206
post #168
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?

I was a long term user of Brackets (since 0.14!) before I switched to VS Code sometime in 2016 because it just worked so well with Typescript. I tried to switch to Atom several times but could never get over the slugginess of it compared to the other two editors.

There were other issues too, the way they handed project folders, intellisense for Scala, but the slugginess was the main issue. I often had to debug large JSON files and while Brackets and VS Code would open them almost immediately, Atom would take several tens of seconds.

Also, personal issue was that I didn't like the default keybindings they had for macOS. I don't remember what they are anymore but there were lots of what I thought should've been obvious defaults that weren't.

Re: The State of Atom's Performance

#207

I am not badmouthing JavaScript or bandwagoning on the "Electron is the devil. Long live native apps!" But I've been wondering more and more, especially through my own experienced biases at work: how much of the, "we chose x because y and z" is retroactive justification for the simple truth: "I wanted to use the technologies that make me enjoy my job." I often have to fight with myself to pick the right tool for the…

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…

> Tools that let people leverage what they already know will always do better than those that require a whole bunch of learning up-front to use. Electron is just the latest example.

Yes.

In "Code Complete", Steve McConnell argues that although a programmer can learn a language syntax in a couple weeks, mastering the language, tools and libraries that make up a platform can take a couple of years.

In other words, asking developers to build and maintain non-trivial products in a language that they don't already know is an even bigger burden than you might think, to the point that it's probably an unreasonable request.

Re: The State of Atom's Performance

#208

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…

> Starting from a web framework not only gives you portability

... except when you actually need to actually, you know, port it, to a platform it wasn't already ported to out of the box.

Re: The State of Atom's Performance

#209

Earlier quoted context omitted.

>> written in the accessible Javascript language so that anyone can contribute Anyone that knows JavaScript.

Which is a very substantial population.

Lowest common denominator.

We put it on every kids desktop in the 1990's. We put it on every kids phone in the 2000's. We are shocked when they reinvent the wheel with in the 2010's.

Now in 2020 they are trying to tell me all the kinks are worked out with frameworks and to get your javascript to work in a browsers you first need to compile/transpile it.

Skip the whole multi-platform idea and focus on electron with all the custom bells/whistle not available on all the platforms. Btw how does meltdown/spectre affect the outlook on security with all these application in their own little v8 kingdoms?

I'm not cynical, I'm concerned.

Re: The State of Atom's Performance

#210

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.

I think the moderators do an excellent job on HN. The signal to noise ratio is pretty high here and while there is snark, there's far less than in most other forums.
Post reply on HN