Earlier quoted context omitted.
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.
Have you considered that Atom is not an editor meant for "quick jobs"? It's a workhorse for programmers who are coding all day every day.
The State of Atom's Performance
91–100 of 293 posts
Re: The State of Atom's Performance
#92Earlier 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…
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...
Re: The State of Atom's Performance
#93I 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…
Re: The State of Atom's Performance
#94I 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…
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 still brushing aside issues with something where a blinking cursor caused CPUs to crank up to the max...
Re: The State of Atom's Performance
#95Atom 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] access to almost everything.
The latter turned out to be somewhat of a curse, unfortunately. Because the wide-ranging access allowed extension authors, and their users, to shoot themselves in the foot: It often lead to performance degradation, instability, murky UIs etc. Such troubles would usually be attributed to Atom itself. This was the groundwork for the narrative to almost instantly flip when VSCode appeared.
VSCode itself took the lessons from Atom, which must make it even more painful to now see it glorified vis-a-vis Atom: Extensions have to work through tightly defined protocols, and are never run on the main threat. This works well to avoid performance issues and to keep the UI from disintegrating. But it is also a severe limitation on the freedom to experiment, which is why that extension I once tried my hand on could not possibly be build in VSCode (it renders block comments written in Markdown as HTML right in the source code, including images, diagrams, links etc.)
[0]: Yeah, I'm sure there's some other editor that did it before. But somehow Atom got it right with Javascript as the language, and maybe the UI and documentation steering people to actually try it.
Re: The State of Atom's Performance
#96Here's a cool gem: https://github.com/atom/watcher There are nice possibilities for this project, it could be abstracted out to work with FreeBSD and stuff. Grunt/gulp/etc. watch features may be able to utilize it in library form. For a similar project, check out entr(1): http://entrproject.org/ I'm a full time VIM user, but I'm happy and glad anytime I see VSCode/Atom/etc win. I see it as a great editor for the sake…
It’s a cross platform file monitoring daemon with a json (and bser) querying API, with support for opaque cursors so you can poll for changes since the last time you checked.
Re: The State of Atom's Performance
#97I 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…
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 but everybody wants to be doing it because it's hot.
Re: The State of Atom's Performance
#98Earlier 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…
The larger the dependency, the more it should have to do to justify itself. "It's fun to write in" is not a sufficient justification for a 70mb dependency. "I need a cross platform app" is better.
As an engineer, you're responsible for the transitive dependency graph that gets delivered to customer machines. If you want to take on gigantic dependencies because they are the current lovechild of ascendant Medium bloggers, be my guest. I prefer to go off of more than fun and social proof when making engineering decisions, however.
Re: The State of Atom's Performance
#99Earlier quoted context omitted.
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…
> I fail to see why one wouldn’t just use VS Code Github is cool, Microsoft isn't. /s
It doesn't feel like a microsoft product at all. Nothing like Visual Studio.
Re: The State of Atom's Performance
#100I 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…