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

61–70 of 293 posts

Re: The State of Atom's Performance

#61

Post by acdha »

loup-vaillant wrote: post #47
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!

Every time I type `git commit`. Every time I visualise files with ranger (terminal based file browser). Every time I typed an email, back when I was using Mutt —which I might again. For such quick jobs, launching the editor should be instantaneous . And I don't want to use another editor for them, I like the key bindings of my main editor.

> Every time I type `git commit`

This is true with something like Vi but with a separate GUI app, wouldn't the most common case be setting EDITOR={atom,code,etc.} and it simply opening a new window in the already-running app?

(Or, for that matter, don't most people using something IDE-like use the built-in UI to make a commit?)

Re: The State of Atom's Performance

#62

Post by mikestew »

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…

Memory usage? Sure, but as developers we probably have GB and GB sitting there

GB and GB which I had hoped to use for running an entirely other operating system, and all of its apps, in a VM, not run a goddamned text editor.

And that’s what annoys me about the “so what?”s. Start up time? Even just an update that requires a restart will make me wonder “I’m in the middle of something, how badly do I want this?” Resource hungry? See above, I have those resources for other stuff, not your piggish version of Notepad. A lot of these things can be excused for an OS, a database, crypto currency worker, but NOT AN EDITOR.

But even if I were more tolerant, as you point out the general use case has been abysmal in my experience. If this kind of thing is what you want, I fail to see why one wouldn’t just use VS Code.

Re: The State of Atom's Performance

#63

Post by acdha »

valarauca1 wrote: post #58

Wait. If your JavaScript is only going to execute in 1 version of the V8 engine forever why use JQuery? Serious question. I’m not a huge JS Develoler but when I dabbled I was told JQuery was there to soften the differences between browsers.

jQuery also provided a ton of usability improvements which many developers learned how to use. In many cases those are now obsolete[1] but there's a lot of habits and, more importantly, library code which uses jQuery. Migrating away from that would require replacing all of that code as well before you can see any savings in network transfer or memory usage.

1. For example, how many projects could basically use this for a significant fraction of their jQuery calls:

    let $$ = (selector, scope = document) => {
        return Array.from(scope.querySelectorAll(selector));
    };
(that's viable on the web now; with a single modern target you could even drop the Array.from bit)

Re: The State of Atom's Performance

#65

Post by Waterluvian »

smacktoward wrote: post #51
Waterluvian wrote: post #13

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…

I don't disagree with your analysis, but I disagree that it's a simple rephrase. They are two separate issues:

1. Pros/cons of using tools we already know 2. Pros/cons of using tools we enjoy using

I am awful at Docker because I started using it yesterday. But upon using it, I'm suddenly so attracted to it and am thinking about what fun personal projects I can apply it to. It's a beautiful technology.

I am very strong in JavaScript but love avoiding it like the plague unless it is the appropriate technology.

Edit: okay I'm skeptical of a part of your analysis. Please show me a detailed example of building a desktop app that runs on Mac/Windows/Linux, looks reasonable, and takes the same or less time from a competent developer. I am genuinely starving for an alternative to Electron that doesn't come with a significantly heavier dev/support cost.

Re: The State of Atom's Performance

#66

Post by nkkollaw »

mikestew wrote: post #62
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…

Memory usage? Sure, but as developers we probably have GB and GB sitting there GB and GB which I had hoped to use for running an entirely other operating system, and all of its apps, in a VM, not run a goddamned text editor. And that’s what annoys me about the “so what?”s. Start up time? Even just an update that requires a restart will make me wonder “I’m in the middle of something, how badly do I want this?” Resourc…

You know, I'm not saying those things aren't important.

I'm just saying that the general use case sucks enough that I'd think you'd want to worry about that _first_, then perhaps think about startup time (maybe).

Re: The State of Atom's Performance

#67

Post by aftbit »

goalieca wrote: post #55
ParkerK wrote: 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…

Emacs starts reasonably quick and it is written in a very extensible language.

I don't know if this is still true, but for many years emacs used a horrible hack called "unexec" to obtain this startup performance.

https://lwn.net/Articles/673724/

Re: The State of Atom's Performance

#68

Post by xemdetia »

Vekz wrote: post #33
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 would also like further discussion on this. I am full-time emacs. I hear from other colleagues that they will split time between editors. "vim for writing and VSCode for refactoring".

If anything the thing that is a killer feature that I always try to get out of emacs but ends up being half baked is the code completion/code aware tools (like the example given of refactoring). With emacs and yasnippet I can emit a ton of code but if I ever have to do a big surgery and have some level of assurance it's right as I go along is nice and I end up falling back into Eclipse/Visual Studio for those sorts of things. I have rarely gotten Emacs to have good code completion with most large software projects, and I end up using tools like opengrok to do the initial search because it just indexes better before diving in with emacs.

Because emacs in most implementations is not project aware the same way an IDE is (like the ways eclipse preprocesses the project and holds a coherent data model in memory while you edit) it just doesn't have the tools available to even build off of. It was only post-LLVM that tools for that kind of formatting and editing are expected to be coming from the compiler's AST itself (things such as https://langserver.org/ is pretty exciting). I think Go has some of the best source code at command line tools, but they are leveraging that there is a 'one true way' of go tools to work that is easy enough to deal with so a simple command can do just enough work to do what needs to be done as opposed to a C/C++ application that is a #define soup with custom build infrastructure that emacs has no way of getting a coherent model out of to decide whether it can refactor things or not.

I keep trying to make emacs work for it, but it turns into a lot of custom tooling that I really don't have time to build for the kinds of applications I end up having to work with. Emacs is still superior for actually reading and writing large bodies of code, just it is awful on operating on the code at a syntax-aware level and doing the same quality of IDE-grade checks to make it a mechanical thing as opposed to a brain-driven thing.

Re: The State of Atom's Performance

#69

Post by stupidcar »

smacktoward wrote: post #51
Waterluvian wrote: post #13

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…

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 target a single runtime. Suddenly you can use every half-baked Chromium API and prefixed CSS feature without worrying about how it's going to break in IE 11.

In that situation, you suddenly realise just how much power the web platform give you. You can style any element, any way you want. You have you have a complete, out-of-the-box object model for your whole UI, plus developer tools to help you debug it. You have advanced typography control. You can drop a canvas element in and get an immediate-mode 2D or 3D graphics API. You can layout stuff in flexbox or grid, or just as a plain old document (which most toolkits would delegate to an embedded web browser anyway).

There are better languages that JS, that's true. But whether there are truly better cross-platform app toolkits than the web is, in my opinion, rather more unclear.

Re: The State of Atom's Performance

#70

Post by shmageggy »

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…

> 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 DOM updates now take less than 5 milliseconds: well within the range required for smooth animation and low energy usage.

> Removing remaining synchronous IO: - Atom still uses synchronous IO (which blocks the UI thread) in some places... Much of the synchronous IO has been eliminated, but there are several Git-related code paths that we still have not updated, and which kills the experience of editing on remote drives like SSHFS for some users. We need to revisit these code paths and convert them all to use asynchronous IO.

Post reply on HN