Live data from Hacker News

The State of Atom's Performance

blog.atom.io

111–120 of 293 posts

Re: The State of Atom's Performance

#111
post #92

Earlier quoted context omitted.

And note that outside of C, C++, .NET, and java, making a desktop means using a library built in another language with documentation in another language. (C has GTK and C++ has QT.) I started building an app in Rust against GTK with a Rust shim, but I only got so far before I had to start reading through GTK docs which meant understanding the C-derived documentation, on top of the Rust shim. If the goal is to learn G…

Forget Lazarus. There is no (finished) Cocoa for Mac. Development is not on Github. Syntax has no common style. Documentation is uneven. The whole ecosystem feels (well, is) dated. Of course, Lazarus/FPC is still quite nice. But to really shine and be a valid alternative, it would need a large infusion of money and manpower. Thus, don't hope too eagerly...

> There is no (finished) Cocoa for Mac.

This is true but in practice the Carbon backend will work fine and if that isn't good enough you can use the Qt backend which uses Cocoa (but then you'd have to bundle Qt with your app which increases its distribution size a bit). To preempt a "then why not just use Qt" reaction, this isn't the same as using Qt since you can use the Win32 and Gtk backends in the other platforms.

Cocoa is of course under heavy development, but keep in mind that there are only a handful of Lazarus developers that even have access to a Mac and they actually had to write a special dialect for the compiler (Objective Pascal) to be able to handle Cocoa objects directly without the need of an intermediate (like Qt that needs libqt4pas that exposes the Qt API as a C interface that is then linked dynamically with FPC through a C-to-Pascal binding).

> Development is not on Github.

This is not a negative, please do not enforce the GitHub monoculture, GitHub is not the be all end all of open source development.

> Syntax has no common style.

What do you mean? The IDE even provides formatting tools.

> Documentation is uneven.

Documentation is lacking in terms of detail but generally you can find stuff easily and things have improved tremendously over the last five years or so (it used to be that you had to have some old Delphi help file to find anything or dig into the source code).

> The whole ecosystem feels (well, is) dated.

Sorry but this doesn't mean anything, please be more specific because this feels like you just want to mudsling.

> But to really shine and be a valid alternative, it would need a large infusion of money and manpower.

Careful what you wish for, because more often than not having a company become a dominant player, it ends up steering a project against the wishes of the community. Lazarus, like Free Pascal, are fully community made projects and most of the people who work on it do it on their free time. On one hand you get a few rough areas like those you mentioned (immature Cocoa support, spotty documentation, etc) but on the other hand you do not have anyone throwing their weight around. For me Lazarus being community driven is a major feature.

The biggest problem Lazarus has is simply the lack of developers, but this will only be solved with developers fixing the issues they face. Fortunately i've seen a lot of new blood lately in the mailing lists so i expect things to improve.

Re: The State of Atom's Performance

#112

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?

Re: The State of Atom's Performance

#113

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…

> What Atom sucks at is regular file editing: huge latency when typing, constant freezes (try editing remote files), and general sluggishness. They specifically address those issues in the post: > Text Rendering Rewrite - Atom renders text... we rewrote Atom’s text rendering system from scratch, with the goal of making DOM updates after keystrokes as efficient as possible... The result is that when typing, typical DO…

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.

Re: The State of Atom's Performance

#114
post #9
post #3

>Atom takes longer to start up than text editors like Vim and Sublime Text because of the dynamic architecture of the app. The majority of our code is written in JavaScript as opposed to C or C++, which is important for Atom’s extensibility, but makes it more challenging to ensure that the app starts quickly. Yet Microsoft's VSCode, which is also Electron based, is much faster than Atom. Electron obviously slows it d…

I found it strange that they mention Vim and Sublime Text without mentioning VS Code anywhere.

Vim and sublime aren’t their competitor while vs code is.

Re: The State of Atom's Performance

#115

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.

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

Re: The State of Atom's Performance

#116

Earlier quoted context omitted.

I know that vscode has a lot of non-electron native code baked in as well, which I'm assuming atom has far less of.

Does it? I've not heard this myself, and the GitHub page says there's no native code in the main repo: https://github.com/Microsoft/vscode

whoops, maybe I've heard wrong then.

Re: The State of Atom's Performance

#117
post #76

Earlier quoted context omitted.

Firstly, I agree with you! I like the philosophy that "Production should be as boring as possible." That being said, using tech that makes you enjoy your job will help you be more productive and potentially attract enthusiastic developers. I feel there's probably a balance (as in all things) between boring production/exciting development - but I don't feel I hear that discussed often enough.

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.

Re: The State of Atom's Performance

#118

Earlier quoted context omitted.

> What Atom sucks at is regular file editing: huge latency when typing, constant freezes (try editing remote files), and general sluggishness. They specifically address those issues in the post: > Text Rendering Rewrite - Atom renders text... we rewrote Atom’s text rendering system from scratch, with the goal of making DOM updates after keystrokes as efficient as possible... The result is that when typing, typical DO…

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

Instead of the developer worrying about trying to gather all their dom changes dependent on user interaction and data syncing you interact directly with Reacts vDom and then react takes care of making the dom changes.

Virtual dom frameworks are a huge thing now cause UX/UI are more complex and we were fighting those issue before. Angular, Ember now, Vue, react ect cause we get speed back when making many state changes to our UI.

This has nothing to do with Atom.

Re: The State of Atom's Performance

#119

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…

[deleted]

Re: The State of Atom's Performance

#120

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…

And note that outside of C, C++, .NET, and java, making a desktop means using a library built in another language with documentation in another language. (C has GTK and C++ has QT.) I started building an app in Rust against GTK with a Rust shim, but I only got so far before I had to start reading through GTK docs which meant understanding the C-derived documentation, on top of the Rust shim. If the goal is to learn G…

> And note that outside of C, C++, .NET, and java, making a desktop means using a library built in another language with documentation in another language. (C has GTK and C++ has QT.)

Not necessarily. D has dlangui and dwt, tcl (and also python?) has tk. Vala is also available for gtk. I think VB also lets you write GUIs although not sure I never used it. Objective-c has cocoa (gnustep outside of macosx).

Post reply on HN