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

121–130 of 293 posts

Re: The State of Atom's Performance

#121

Post by sus_007 »

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.

I was in your position a year back. Now I'm in love with VSCode. Do give it a try.

Re: The State of Atom's Performance

#122

Post by gmueckl »

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

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.

Re: The State of Atom's Performance

#123

Post by vog »

jkmcf wrote: post #117
beckler wrote: post #76

Earlier quoted context omitted.

I heard once that if you're doing something boring to pick an exciting technology. If you're doing something exciting, pick a boring technology. Not sure what you would consider exciting or boring, but I thought it was decent advice.

That advice is good when you only report to yourself. If you report to a company and your decisions affect $$$$, directly or indirectly, then it's probably the worst advice.

Do you care to elaborate? That doesn't make any sense to me, as the advice given above is exactly what you should do in a company, if I understood it correctly.

(Higher risk on a simple project, because that's the only opportunity to learn new stuff, as in the worst case you can start over. Lower risk for a complex project, because there's already enough risk in the project itself.)

Re: The State of Atom's Performance

#124

Post by earenndil »

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 use vim, which launches almost immediately. I launch a new instance for every file I open, each in a new screen. It seems to work fine. Yet I wouldn't be able to do that under atom... (ignoring the issue of it doesn't work with tty).

Re: The State of Atom's Performance

#125

Post by earenndil »

cle wrote: post #78
ninjakeyboard wrote: post #16

I've been learning emacs over the last 6 month or so. How is the "hackability" of atom compared to emacs? I threw away spacemacs, started over, built all my config, am starting to build plugins etc. While the learning curve was steep, the flexibility of emacs is quite amazing and I've only just scratched the surface of the extensibility. It makes me very intrigued to hear about how other people are using editors like…

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

Re: The State of Atom's Performance

#126

Post by nkkollaw »

HumanDrivenDev wrote: post #99
bdcravens wrote: post #86

Earlier quoted context omitted.

> I fail to see why one wouldn’t just use VS Code Github is cool, Microsoft isn't. /s

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.

I don't know about this. Configuration via JSON is common (Sublime Text, the most popular), I'd say that it's Atom that is bizzare on this aspect.

As for "projects", I'd argue that if you open a folder, that's your project/workspace/whatever.

Just thought I'd add this in case someone who doesn't know VS Code[ well] gets confused.

Re: The State of Atom's Performance

#127

Post by nkkollaw »

ASalazarMX wrote: post #112
nkkollaw wrote: post #24

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…

We as developers might have plenty of RAM to waste, but our users usually don't. If it runs well on our machine but not in the users', what good is it? Even if it runs well on the users' machines, how many resource-heavy applications can they run concurrently? Will they have to close one to open another?

> We as developers might have plenty of RAM to waste, but our users usually don't.

Mh? This is a tool for developers. I don't get your point. My mom isn't going to use Atom for her shopping list :-)

Re: The State of Atom's Performance

#128

Post by jamesmcintyre »

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 in the accessible Javascript language so that anyone can contribute. I love that I feel like I can change any aspect of the editor fully, without limitations imposed by some vendor.

Atom, like any editor, is not for everybody. I don't care much for Sublime but it certainly has its strengths- I don't pounce on HN posts about Sublime spouting negativity because it's not my preferred editor.

Please, fellow engineers, before you post something negative think about a project you've worked on that you were most passionate about and cared most about and then remember that projects like Atom do require passionate developers and those developers likely deserve a bit more than snark or non-constructive negativity.

Thank you Atom contributors! I think the idea and ongoing evolution of Atom is a special project and I hope to one day make some contribution of my own, in some form, to the core or plugins!

Re: The State of Atom's Performance

#129

Post by taternuts »

kalcode wrote: post #118
RobertRoberts wrote: post #113

Earlier quoted context omitted.

Maybe they should rewrite it in React. I've been argued into the ground under the guise that it's faster than the browser's rendering of DOM.

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?

Re: The State of Atom's Performance

#130

Post by shakna »

vog wrote: post #123
jkmcf wrote: post #117

Earlier quoted context omitted.

That advice is good when you only report to yourself. If you report to a company and your decisions affect $$$$, directly or indirectly, then it's probably the worst advice.

Do you care to elaborate? That doesn't make any sense to me, as the advice given above is exactly what you should do in a company, if I understood it correctly. (Higher risk on a simple project, because that's the only opportunity to learn new stuff, as in the worst case you can start over. Lower risk for a complex project, because there's already enough risk in the project itself.)

Processing transactions at a bank is "boring". It's simple, apart from scale, and the spec is usually insanely well documented.

But if you reach for that new language that hasn't been battle-tested yet, you're probably screwing the bank over.

Post reply on HN