Atom was archived today(github.com)
github.com
Atom was archived today
https://github.com/atom/atom
613 comments
Atom predated the LSP and leaned heavily into customizations with all the plugins running inside the UI thread (more like a traditional web page and 3p scripts). At the time they viewed the extreme customization support as a feature, and there was a thriving ecosystem of folks making plugins.
That architecture has a major flaw though. A default install was fast, but a real configuration with all the plugins ended up quite slow.
VSCode's architecture worked much better in real world configurations, and it turns out better performance wins in the editor space, even if it meant losing certain customizations (up to a limit). The architecture also allowed seamless remote editing, something Atom never could have done.
The interesting thing has always been that both were built on Electron. Atom's developers had built all the tools and primitives needed, they just didn't have the understanding of the long term ecosystem effects of their design.
That architecture has a major flaw though. A default install was fast, but a real configuration with all the plugins ended up quite slow.
VSCode's architecture worked much better in real world configurations, and it turns out better performance wins in the editor space, even if it meant losing certain customizations (up to a limit). The architecture also allowed seamless remote editing, something Atom never could have done.
The interesting thing has always been that both were built on Electron. Atom's developers had built all the tools and primitives needed, they just didn't have the understanding of the long term ecosystem effects of their design.
VSCode is one of the greatest pieces of engineering of our time. It's really only when you compare it with Atom that you realize how great it is. Atom was built by incredibly smart people, who had full control over the platform and several years of head start, and they were still out-engineered by the VSCode team at every turn.
VSCode did almost everything right: The choice of TypeScript as the base language (with which VSCode has a symbiotic relationship), the limited, slowly expanding extension API, LSP, the monorepo, the monthly release cadence, the built-in terminal, and the list goes on and on. They turned Electron's strengths into super-strengths, and deftly engineered around Electron's weaknesses. VSCode is the greatest productivity tool in the history of software engineering, and it fully deserves the dominant status it has today.
VSCode did almost everything right: The choice of TypeScript as the base language (with which VSCode has a symbiotic relationship), the limited, slowly expanding extension API, LSP, the monorepo, the monthly release cadence, the built-in terminal, and the list goes on and on. They turned Electron's strengths into super-strengths, and deftly engineered around Electron's weaknesses. VSCode is the greatest productivity tool in the history of software engineering, and it fully deserves the dominant status it has today.
VSCode is good but as someone who’s been writing software for nearly 40 years, I really feel you’ve over doing the compliments by a long long way.
Compilers, operating systems, browser engines (unfortunately) and reverse engineering proprietary hardware/firmware are all significantly harder challenges than writing an IDE.
in fact there have been excellent IDEs around for decades before VSCode came along. Yes the industry lacked an LSP but that doesn’t mean that languages severs didn’t exist before then, there just wasn’t a standard before so everyone did their own thing.
Having built in terminals isn’t a new innovation either. That is and always has been the norm.
And most of the other accomplishments aren’t any more unique either (eg lots of software projects have monorepos).
It’s ironic that you say VSCode is the greatest productivity tool in the history of software engineering when VSCode is dependent on so many pre-existing technology’s like Electron, web standards, GUI frameworks, compilers, operating systems, device drivers, etc. in the grand scope of the engineering, VSCode occupies a very small fraction of engineering effort and in a niche that was already crowded before it even entered.
Is it the best IDE on the market? some might think so. JetBrains certainly have their fans too. But even if it’s the “best”, it’s extremely hard to argue that it is that far ahead of the competition and that innovative to deserve the accolades you’re describing.
Compilers, operating systems, browser engines (unfortunately) and reverse engineering proprietary hardware/firmware are all significantly harder challenges than writing an IDE.
in fact there have been excellent IDEs around for decades before VSCode came along. Yes the industry lacked an LSP but that doesn’t mean that languages severs didn’t exist before then, there just wasn’t a standard before so everyone did their own thing.
Having built in terminals isn’t a new innovation either. That is and always has been the norm.
And most of the other accomplishments aren’t any more unique either (eg lots of software projects have monorepos).
It’s ironic that you say VSCode is the greatest productivity tool in the history of software engineering when VSCode is dependent on so many pre-existing technology’s like Electron, web standards, GUI frameworks, compilers, operating systems, device drivers, etc. in the grand scope of the engineering, VSCode occupies a very small fraction of engineering effort and in a niche that was already crowded before it even entered.
Is it the best IDE on the market? some might think so. JetBrains certainly have their fans too. But even if it’s the “best”, it’s extremely hard to argue that it is that far ahead of the competition and that innovative to deserve the accolades you’re describing.
Spot on.
And I would rather say that Atom was an engineering feat in terms of that they developed Electron and tree-sitter.
One also has to take into account that Atom started long before VS Code so for sure the VS Code team could make much more informed decisions and learn from the "failures" of Atom. And things like TypeScript wasn't around when Atom started.
And I would rather say that Atom was an engineering feat in terms of that they developed Electron and tree-sitter.
One also has to take into account that Atom started long before VS Code so for sure the VS Code team could make much more informed decisions and learn from the "failures" of Atom. And things like TypeScript wasn't around when Atom started.
Admittedly this is a little bit of a nitpick (and I agree with your general sentiment re: VSCode devs benefitting from prior art) but for clarity's sake — Atom v1.0.0 was released mid-2015. TypeScript v1.0 was early 2014 and had been usable since 2012 pre 1.0.
They were very much contemporaries of one another, though obviously TS popularity has surged since 2017/2018.
They were very much contemporaries of one another, though obviously TS popularity has surged since 2017/2018.
Also, the Monaco code editor (a core component of VS Code) was started for the Azure Portal and then used by the IE Dev Tools experience for several years before Atom. VS Code didn't have Electron until after Atom, but they had a running start in several core component areas.
Honestly I’m not a fan of VSCode as a user. It’s too generic and lacks identity (too powerful to edit simple configs); it auto-updates every time I start it; it’s too complicated to configure; JSON is ugly and it’s 2022, why not favor GUI configurations?
If my goal is to program in language X then I should be able to grab a product and get started without fuss. VSCode is a whole lot of fussing about.
That being said, it’s very stable and performs well—I will give the devs a massive kudos for that. Also if I did a lot of NodeJS dev work it would probably classify as a proper IDE for that.
But all-in-all I would prefer something purpose-built with minimal configuration out the gate for development workloads (C/C++, Java, C#) and a more minimal editor (nano, vim, eMacs, notepad++, geany, etc) for editing configs.
If my goal is to program in language X then I should be able to grab a product and get started without fuss. VSCode is a whole lot of fussing about.
That being said, it’s very stable and performs well—I will give the devs a massive kudos for that. Also if I did a lot of NodeJS dev work it would probably classify as a proper IDE for that.
But all-in-all I would prefer something purpose-built with minimal configuration out the gate for development workloads (C/C++, Java, C#) and a more minimal editor (nano, vim, eMacs, notepad++, geany, etc) for editing configs.
These seems impression by somebody who's not a VSC user at all. Specifically:
> it’s 2022, why not favor GUI configurations?
VSC provides, at all the (four) levels, both GUI and text-based configuration editing.
> JSON is ugly
You can't get any simpler than JSON. The VSC designers have actually been admirably pragmatic, and opted for JSON5-ish, which supports comments and terminal commas (in arrays).
> too powerful to edit simple configs
Editors are complex by nature; other editors are not different.
It is actually quite the opposite; one can edit a subset of options in the GUI, then observe the changed values only in the JSON editor.
> it auto-updates every time I start it
VSC updates once a month, plus once or twice for patch releases in-between. It auto-updates every time if one opens it two/three times per month.
Plugins do auto update, but one can disable this, if they want.
> I should be able to grab a product and get started without fuss. VSCode is a whole lot of fussing about
There is no default configuration that satisfies all the users; this is not specific to VSC.
Actually, the extensions experience is probably the most polished out there, and this matters, because if one makes something easy to use, users will use that feature more.
> it’s 2022, why not favor GUI configurations?
VSC provides, at all the (four) levels, both GUI and text-based configuration editing.
> JSON is ugly
You can't get any simpler than JSON. The VSC designers have actually been admirably pragmatic, and opted for JSON5-ish, which supports comments and terminal commas (in arrays).
> too powerful to edit simple configs
Editors are complex by nature; other editors are not different.
It is actually quite the opposite; one can edit a subset of options in the GUI, then observe the changed values only in the JSON editor.
> it auto-updates every time I start it
VSC updates once a month, plus once or twice for patch releases in-between. It auto-updates every time if one opens it two/three times per month.
Plugins do auto update, but one can disable this, if they want.
> I should be able to grab a product and get started without fuss. VSCode is a whole lot of fussing about
There is no default configuration that satisfies all the users; this is not specific to VSC.
Actually, the extensions experience is probably the most polished out there, and this matters, because if one makes something easy to use, users will use that feature more.
> You can't get any simpler than JSON.
Actually a plain text file containing a JavaScript object is simpler and prettier than JSON.
Not universal across languages though I suppose.
Actually a plain text file containing a JavaScript object is simpler and prettier than JSON.
Not universal across languages though I suppose.
JSON, as used in VSC, can be defined as "plain text file containing an object", as configuration files have a hash map as root-level object.
AFAIK the difference between JSON (as used in VSC) and a Javascript object are minimal (no quoting for keys, possibly minor other differences) and using a JS object should have significant advantages in order to replace a de-facto standard.
AFAIK the difference between JSON (as used in VSC) and a Javascript object are minimal (no quoting for keys, possibly minor other differences) and using a JS object should have significant advantages in order to replace a de-facto standard.
`Template literals ie- multiline strings without needing escape or newline characters is a signficant advantage of JS object over JSON`
some will argue that scripting would thus be possible if the config was simply JS but that is a rabbit hole both on the debate itself and then the potential compexlity of config; there are trade-offs for/against but not a settled matter IMO as there are major projects like neovim that support full fledged config scripting (in the case of neovim they allow use of Lua)
some will argue that scripting would thus be possible if the config was simply JS but that is a rabbit hole both on the debate itself and then the potential compexlity of config; there are trade-offs for/against but not a settled matter IMO as there are major projects like neovim that support full fledged config scripting (in the case of neovim they allow use of Lua)
If you like JSON that much, obviously you haven't yet seen
https://github.com/Enhex/Deco
I've never wrote that I "like JSON that much".
What I "like that much" is the pragmatism (which, again, I didn't write) of the choice to break the JSON standard and introduce features that are significant for configuration files (comments, essentially, and to a very minor extend, trailing newlines in arrays).
I've never seen Deco, but it's not an established standard. Based on the repository, it has no grammar and it even leaves details to the implementations (e.g. multi-line strings). The simplicity comes at a cost, for example, to represent leading whitespaces.
If one asks 10 developers which format they'd use, they'd choose 10 different ones, therefore a certain level of standardization is required.
What I "like that much" is the pragmatism (which, again, I didn't write) of the choice to break the JSON standard and introduce features that are significant for configuration files (comments, essentially, and to a very minor extend, trailing newlines in arrays).
I've never seen Deco, but it's not an established standard. Based on the repository, it has no grammar and it even leaves details to the implementations (e.g. multi-line strings). The simplicity comes at a cost, for example, to represent leading whitespaces.
If one asks 10 developers which format they'd use, they'd choose 10 different ones, therefore a certain level of standardization is required.
It's like yaml and json had a baby.... And it scares me
As far as I know most configuration can be done through GUI. You have both JSON and GUI views of the preferences. It seems the GUI is automatically generated from the JSON-schema that validates and gives autocomplete to the JSON editor.
VS Code has the power of emacs and an autogenerating UI which maps to the configuration files. To me, that’s the easy way out—make the UI map one-to-one with the data underneath, obviating the burden of considering the UX of each configuration path, and missing out on the benefits of good UX.
It's sad that you were downvoted for this because you are not wrong at all. VS Code GUI config is a mess, and a lot of the settings are not available there. I just got used to messing with the JSON autocomplete.
> it’s too complicated to configure; JSON is ugly and it’s 2022, why not favor GUI configurations?
GUIs can change layout and users have to spend time learning where things are. Someone who is using a text editor is probably comfortable editing text.
GUIs can change layout and users have to spend time learning where things are. Someone who is using a text editor is probably comfortable editing text.
Well unfortunately that’s a typical assumption developers make. “It’s an editor, Bob! The users ought to know how to read JSON!” Well thought-out UIs actually help the user find things and they don’t need to change all the time.
Unfortunately, even though we engineer with code, reading long streams of text is actually a terrible user experience by itself.
Good user experience should hold the user’s hand through the process so they don’t need to sift through a haystack of configurations.
VS Code has the power of emacs and an autogenerating UI which maps to the configuration files. To me, that’s the easy way out—make the UI map one-to-one with the data underneath, obviating the burden of considering the UX of each configuration path, and missing out on the benefits of good UX.
Unfortunately, even though we engineer with code, reading long streams of text is actually a terrible user experience by itself.
Good user experience should hold the user’s hand through the process so they don’t need to sift through a haystack of configurations.
VS Code has the power of emacs and an autogenerating UI which maps to the configuration files. To me, that’s the easy way out—make the UI map one-to-one with the data underneath, obviating the burden of considering the UX of each configuration path, and missing out on the benefits of good UX.
VSCode isn't the most complex of projects or most widespread etc. But from perspective of engineering a large project is about making 100s of small and large choices. In hindsight, lot of them are wrong. Take any software WinNT, Linux, Atom, IntelliJ, Adobe* you can now with all the extra information available today can find some decisions that were wrong.
With VSCode these wrong decisions are very few and minor compared to the brilliant choices made by the team. That's why it is right to cite it as an engineering excellence project.
With VSCode these wrong decisions are very few and minor compared to the brilliant choices made by the team. That's why it is right to cite it as an engineering excellence project.
The software you mentioned were pioneers in their category. On the other hand, VSCode had the benefit of learning from the many IDES in the saturated market that came before it. If VSCode was one of the first IDE it would not look anywhere near the same because it wouldn't be able to lean on the lessons of past IDEs like it does today.
Dunno, just getting VSCode to run and debug a project requires manually editing cryptic config files which is what almost any IDE does much better...
Indeed; while VSCode is held up as the "best ever IDE for everything, period", what those people gloss over is that they are web devs, not C++ hackers who need to be able to easily build projects (and have good, reliable syntax highlighting and autocompletion). In the rare occasion that I use VSCode for C++ development, I just use cmake from the built-in terminal because I really don't think VSCode is designed to build C++ projects.
VSCode is not tied to a specific language so the job of handling config files is left to the extension. Not every language has a fixed project structure so I think the major extensions have kept structure-dependent things out. In C++ for example there are CMake projects and GNU Makefile projects. Not sure why such extensions haven't bubbled yet.
Other IDEs have their own fixed project structure and a project config file specific to their IDE. This means running and debugging is easier in their IDE if your project works in the specific way intended by the IDE, but this locks you to their IDE.
By your logic Sublime is an even higher feat of engineering since it made even better engineering decisions.
Ultimately they’re both very fancy text editors, not ‘the greatest feat of modern software engineering’.
I’d happily switch from Sublime to VScode or EMacs or any of the other umpteen code editors. I’d shudder to have to go back from Git to SVN. Even Mercurial seems milquetoast in comparison.
Similarly, what about the Linux kernel?
What about C?
Ultimately they’re both very fancy text editors, not ‘the greatest feat of modern software engineering’.
I’d happily switch from Sublime to VScode or EMacs or any of the other umpteen code editors. I’d shudder to have to go back from Git to SVN. Even Mercurial seems milquetoast in comparison.
Similarly, what about the Linux kernel?
What about C?
> I’d shudder to have to go back from Git to SVN.
What are some of the Git features that make a big difference to you? I use them on different projects and I end up using them both in the same very basic way (check out code, make changes, check code in).
What are some of the Git features that make a big difference to you? I use them on different projects and I end up using them both in the same very basic way (check out code, make changes, check code in).
All git operations are several times faster than their SVN counterparts, and git is more storage efficient as well. This becomes especially relevant for larger repositories.
Merging. Sure you can “branch” on svn but you merge at your own risk.
Subversion merging has mostly been fixed. I haven't really noticed much difference between the two systems.
One place where Subversion historically did better with respect to merging is avoiding merging by allowing you to lock files. We use this with some binary files in our repository. About a year ago Git added similar functionality but I haven't had the chance to try it yet.
One place where Subversion historically did better with respect to merging is avoiding merging by allowing you to lock files. We use this with some binary files in our repository. About a year ago Git added similar functionality but I haven't had the chance to try it yet.
local commit
VSCode is good but as someone who’s been writing software for nearly 40 years, I really feel you’ve over doing the compliments by a long long way.
I agree.
Lots of people talk about how great VS Code is. But how many of them would sing that tune if they had to pay for it?
VS Code's killer feature isn't customization or extensibility. Clearly it isn't speed or stability. It's price.
I agree.
Lots of people talk about how great VS Code is. But how many of them would sing that tune if they had to pay for it?
VS Code's killer feature isn't customization or extensibility. Clearly it isn't speed or stability. It's price.
Well, it has to have something beyond price if it's taking by storm the editor arena that always has had great editors.
I think it has gained its place in the eternal emacs vs vim discussion, and that's a feat to be reckoned. In 15 years there will be other fancier editors but VS Code will still be there.
I think it has gained its place in the eternal emacs vs vim discussion, and that's a feat to be reckoned. In 15 years there will be other fancier editors but VS Code will still be there.
VS Code is good, but not THAT good. It has unparalleled remote editing with the SSH extension, but the actual editor is beaten by Sublime.
I can buy that people like it, I don’t dislike it, but it also isn’t sliced bread. There’s peers in the market that are ahead in various ways, so VS Code isn’t the end all be all, even if it is cool.
I can buy that people like it, I don’t dislike it, but it also isn’t sliced bread. There’s peers in the market that are ahead in various ways, so VS Code isn’t the end all be all, even if it is cool.
Is the remote editing better than emacs?
No, but it does allow remote pair programming via its live share feature
As a vim user with only superficial emacs experience, does emacs have something like the remote file system setup that VS Code with the ssh extension provides? Basically local editor with local response time, but file system is external?
I realize sshfs provides something similar, but it has a few rough edges compared to the vs code implementation.
I realize sshfs provides something similar, but it has a few rough edges compared to the vs code implementation.
I hesitate to dive into comparing editors, but here goes. I've used editors for a very long time, I believe the first was TECO sometime in the 1970s at the time I stopped punching cards. My preferred editors now are Emacs, Neovim, Jet Brains IDEs, and VSCode (in that order). All of them are really great professional grade tools.
Emacs supports editing remote files via ssh, ftp, or scp; one simply refers to filenames like: /ssh:host:filename or /ssh:user@host:filename. It's pretty simple and transparent. One can browse remote directories, etc.
Likewise editing a local file under a different user id is also supported using paths that look like /sudo::filename.
See section 18.5 Remote Files in the Emacs user manual[1].
[1] https://www.gnu.org/software/emacs/manual/html_mono/emacs.ht...
Emacs supports editing remote files via ssh, ftp, or scp; one simply refers to filenames like: /ssh:host:filename or /ssh:user@host:filename. It's pretty simple and transparent. One can browse remote directories, etc.
Likewise editing a local file under a different user id is also supported using paths that look like /sudo::filename.
See section 18.5 Remote Files in the Emacs user manual[1].
[1] https://www.gnu.org/software/emacs/manual/html_mono/emacs.ht...
Yes, when you're editing a remote file, using commands to access a shell or browse directories will open a shell in the remote system/browse remote directories- it all feels the same as working with local files.
Something I have yet to try is using an lsp server with a remote project. I'm not sure how some, like the rust lsp, that need the whole project (at least w/ emacs it doesn't yet support isolated files), would work.
Something I have yet to try is using an lsp server with a remote project. I'm not sure how some, like the rust lsp, that need the whole project (at least w/ emacs it doesn't yet support isolated files), would work.
Yeah, look at tramp-mode
> Atom was built by incredibly smart people, who had full control over the platform and several years of head start, and they were still out-engineered by the VSCode team at every turn.
The VSCode team didn't have to make Electron. They got to use it, though. Along with the various lessons learned by the Atom project.
The VSCode team didn't have to make Electron. They got to use it, though. Along with the various lessons learned by the Atom project.
I think VSCode's impressiveness is less about the pure engineering challenge (although I do think even among popular, well-used IDEs there's a large differential in things like performance, which points to it not being a trivial problem), and more about making smart product decisions to strike a great balance between extensibility and performance / smoothness. There's not a singular big hairy problem to solve, but if you compare VSCode to other Electron apps, it's clear that the VSCode team really took the time to make sure everything was as performant and polished as possible.
And in terms of "well it depends on other technologies for it to work", this describes pretty much any innovation in software since the very earliest computers, including all the examples you listed.
And in terms of "well it depends on other technologies for it to work", this describes pretty much any innovation in software since the very earliest computers, including all the examples you listed.
Sure, we do all stand on the shoulders of giants. But the other things I listed requires significantly more research and development effort than building an IDE does.
Also I dispute that VS Code is the quickest editor out there. It’s faster than its Electron counterparts but that’s a pretty low bar. This isn’t a dig at VS Code, it’s my default IDE (well that and vim). But the largest part of the reason I use VSCode is because it’s free.
That, for me, is its real advantage. But that’s not an engineering achievement.
Also I dispute that VS Code is the quickest editor out there. It’s faster than its Electron counterparts but that’s a pretty low bar. This isn’t a dig at VS Code, it’s my default IDE (well that and vim). But the largest part of the reason I use VSCode is because it’s free.
That, for me, is its real advantage. But that’s not an engineering achievement.
I agree that it is an exaggeration to call it the greatest pieces of engineering of our time. Still there are many technologies that are well liked but haven't developed in many years. There are many technologies that are here today but severely limited. And there are many technologies which promises potential for something better in the future. There are very few pieces of software that are here today and ticks a lot of the boxes of computer science. That are open source, cross-platform, extensible and has a modern stack.
> browser engines (unfortunately)
I often wish it wasn't so but the reality is that a shit ton of development has gone into browsers and in many cases other areas just aren't comparable. Even more so considering most resources go into proprietary technologies.
> reverse engineering proprietary hardware/firmware
As as side note reverse engineering hardware can certainly be very hard. It is also something that can gather far more credit than it probably should compared to actually engineering a solution in the first place.
> browser engines (unfortunately)
I often wish it wasn't so but the reality is that a shit ton of development has gone into browsers and in many cases other areas just aren't comparable. Even more so considering most resources go into proprietary technologies.
> reverse engineering proprietary hardware/firmware
As as side note reverse engineering hardware can certainly be very hard. It is also something that can gather far more credit than it probably should compared to actually engineering a solution in the first place.
> There are very few pieces of software that are here today and ticks a lot of the boxes of computer science. That are open source, cross-platform, extensible and has a modern stack.
Open source: there’s loads. I’m very surprised to read that comment here of all places. But even if we take your comment at face value, licensing has naff all to do with engineering impressiveness.
Cross platform: again I’d beg to differ there there aren’t many. And again I’d also like to point out that something not being cross platform doesn’t negate it being impressive engineering.
Extensible: this is another metric you’ve added that I disagree is a requirement
Used a modern stack: this absolutely shouldn’t matter when one talks about “of all time” like the GP was. Otherwise you’re intentionally skewing the results to only include recent developments.
> I often wish it wasn't so but the reality is that a shit ton of development has gone into browsers and in many cases other areas just aren't comparable.
The point of the GPs tangent was comparing all software engineering.
Sure, if you say VSCode is the greatest software engineering project of all time then suffix that comment with a dozen footnotes describing a dozen exclusions to the scope, then the claim might be more reasonable. But that wasn’t what the GP said and nor is it then “greatest”.
Frankly though, I wouldn’t even extend that description of his to modern IDEs specifically, let alone the broader context they intended.
Open source: there’s loads. I’m very surprised to read that comment here of all places. But even if we take your comment at face value, licensing has naff all to do with engineering impressiveness.
Cross platform: again I’d beg to differ there there aren’t many. And again I’d also like to point out that something not being cross platform doesn’t negate it being impressive engineering.
Extensible: this is another metric you’ve added that I disagree is a requirement
Used a modern stack: this absolutely shouldn’t matter when one talks about “of all time” like the GP was. Otherwise you’re intentionally skewing the results to only include recent developments.
> I often wish it wasn't so but the reality is that a shit ton of development has gone into browsers and in many cases other areas just aren't comparable.
The point of the GPs tangent was comparing all software engineering.
Sure, if you say VSCode is the greatest software engineering project of all time then suffix that comment with a dozen footnotes describing a dozen exclusions to the scope, then the claim might be more reasonable. But that wasn’t what the GP said and nor is it then “greatest”.
Frankly though, I wouldn’t even extend that description of his to modern IDEs specifically, let alone the broader context they intended.
>I really feel you’ve over doing the compliments by a long long way.
Well, that shows the bar for Web Developers these days are so low, that even VSCode could even be on the list of "one of the greatest pieces of engineering of our time."
Web developers are so abstracted away from everything, their understanding of computing and software is really hurting the industry. And the sad part is not only are they the majority in software development, they are also the most well paid and vocal.
Well, that shows the bar for Web Developers these days are so low, that even VSCode could even be on the list of "one of the greatest pieces of engineering of our time."
Web developers are so abstracted away from everything, their understanding of computing and software is really hurting the industry. And the sad part is not only are they the majority in software development, they are also the most well paid and vocal.
I dunno, I'm not convinced that a compiler or OS is a harder problem than an IDE. "Turns out humans are complicated and making computers do things they want is hard."[1] UX design is not only a whole complicated field in its own right, it imposes additional technical constraints that interlock with UX ones in complex ways. (E.g., VS Code's plugin API is architected the way it is partly to limit the ability of a plugin to accidentally add latency in the places that are most critical for usability, or otherwise undermine the editing experience.)
Obviously some compilers and OSes and IDEs are larger in scope than others, but all else being equal, if I had to pick one to write and it was really important to deliver something good, I'd rather do one of the former.
(This applies to any kind of GUI program that needs to be very feature-rich in order to meet the needs of power users, and where user productivity is at a premium because those users spend all their time in it. IDEs are just the subcategory of that that we as programmers most often use.)
[1] https://wiki.alopex.li/LetsBeRealAboutDependencies#yeah-but-...
Obviously some compilers and OSes and IDEs are larger in scope than others, but all else being equal, if I had to pick one to write and it was really important to deliver something good, I'd rather do one of the former.
(This applies to any kind of GUI program that needs to be very feature-rich in order to meet the needs of power users, and where user productivity is at a premium because those users spend all their time in it. IDEs are just the subcategory of that that we as programmers most often use.)
[1] https://wiki.alopex.li/LetsBeRealAboutDependencies#yeah-but-...
I think a "compiler" isn't too bad — certainly easier than an IDE by a long margin. An optimizing compiler OTOH, can be a bit of a beast. Because the optimization passes self-interact, on every line of code, repeatedly, any small error in the passes can dramatically amplify (or cancel out!). It means the level of quality of the optimization passes is (by necessity) much, much, much higher than plain old SW. It's just ... very tedious.
I’ve written hobby compilers, hobby kernels and hobby IDEs.
The later was by far the easiest for me.
Maybe you’re brain is wired differently but I can only speak from my own experiences.
The later was by far the easiest for me.
Maybe you’re brain is wired differently but I can only speak from my own experiences.
It seems like not really an apples-to-apples comparison anyway. Designing a text editor, there are just a lot more subjective questions.
The technical issues are also sort of different, fixing latency problems is a totally different type of problem that developing a framework for how an optimizing compiler should do its thing. Both valuable and hard things to do, hard to come up with a metric to rank them.
The technical issues are also sort of different, fixing latency problems is a totally different type of problem that developing a framework for how an optimizing compiler should do its thing. Both valuable and hard things to do, hard to come up with a metric to rank them.
> In fact there have been excellent IDEs around for decades before VSCode came along.
I wonder what everyone's favorite IDE is. I don't think I could put my finger on a single one and claim that it's the best.
I really liked Lazarus (for Pascal), because it's perhaps one of the snappiest tools I've used for a language that also compiles pretty fast. Though it's certainly not as modern or smart as JetBrains products.
I rather liked NetBeans (for Java and PHP), because it's truly free and can be relatively lightweight. The interface doesn't feel overbearing either, you get some framework/library support out of the box and even projects like jMonkeyEngine built upon NetBeans for their game engine editor. It's like libre JetBrains lite, but struggles with larger projects.
I rather liked MonoDevelop (for C#), because it felt like the .NET equivalent of NetBeans, was lightweight, functional and just worked without getting too much into your way. That said, it never really got as much attention as other products in the space (Visual Studio or JetBrains Rider).
I acknowledge the success of Eclipse (for Java and other languages), because I've seen that platform be used for anything from being an IDE for programming, to niche modeling tools and graphical programs. Some also swear by its incremental compiler (for Java), but personally it feels sluggish to me (like running JetBrains IDEs with low RAM) and its stability is inversely proportional to how many plugins you have.
I acknowledge the success of Visual Studio (for .NET and other languages), because when your platform is a walled garden, you can make sure that the experience is focued on doing things within it decently (like XCode, I guess), even though sometimes the IDE felt similarly heavy to JetBrains offerings and was more opinionated towards what you can do with it, as well as the platform support.
I like JetBrains IDEs (IntelliJ and their other offerings), because they have perhaps the best autocomplete and code refactoring/inspection tools out of any other solution out there. The plugin ecosystem is rich, the language support is pretty great, the experience across various languages is similar enough. Though the obvious downsides are large system requirements (you need enough RAM and project indexing is slow, having 6 Java projects open and 2 front end projects open is a pain), bad run configurations (that making sharing run configurations across Windows/Linux really hard because of interpreter selection for scripts etc.) and confusing menus (due to how much functionality there is, a bit like Visual Studio, though the menu structure changes for different IDEs from them as well). The benefits still outweigh the negatives and so I pay for all their tools.
I like Visual Studio Code as a text editor (for anything really), but it feels like some of the refactoring and code editing support is lacking, especially when working with enterprise codebases. You can get pretty close to a fully fledged IDE with it, but at that point you're also trading some of the performance and lighter footprint away. Regardless, most of my projects have a .workspace file in them and I use Visual Studio Code together with JetBrains products.
I like other attempts at feature filled text editors as well, be it Fleet (though was a bit too unfinished last I tried their preview), CudaText (really interesting project with lots of nice features) or anything else, really.
At the end of the day, there is no single best IDE, just different ones that are suited for different tasks.
Edit: actually decided not to include the nano vs vi/vim discussion, since that's not super relevant to the discussion. Either is fine, I like the simplicity of nano more.
I wonder what everyone's favorite IDE is. I don't think I could put my finger on a single one and claim that it's the best.
I really liked Lazarus (for Pascal), because it's perhaps one of the snappiest tools I've used for a language that also compiles pretty fast. Though it's certainly not as modern or smart as JetBrains products.
I rather liked NetBeans (for Java and PHP), because it's truly free and can be relatively lightweight. The interface doesn't feel overbearing either, you get some framework/library support out of the box and even projects like jMonkeyEngine built upon NetBeans for their game engine editor. It's like libre JetBrains lite, but struggles with larger projects.
I rather liked MonoDevelop (for C#), because it felt like the .NET equivalent of NetBeans, was lightweight, functional and just worked without getting too much into your way. That said, it never really got as much attention as other products in the space (Visual Studio or JetBrains Rider).
I acknowledge the success of Eclipse (for Java and other languages), because I've seen that platform be used for anything from being an IDE for programming, to niche modeling tools and graphical programs. Some also swear by its incremental compiler (for Java), but personally it feels sluggish to me (like running JetBrains IDEs with low RAM) and its stability is inversely proportional to how many plugins you have.
I acknowledge the success of Visual Studio (for .NET and other languages), because when your platform is a walled garden, you can make sure that the experience is focued on doing things within it decently (like XCode, I guess), even though sometimes the IDE felt similarly heavy to JetBrains offerings and was more opinionated towards what you can do with it, as well as the platform support.
I like JetBrains IDEs (IntelliJ and their other offerings), because they have perhaps the best autocomplete and code refactoring/inspection tools out of any other solution out there. The plugin ecosystem is rich, the language support is pretty great, the experience across various languages is similar enough. Though the obvious downsides are large system requirements (you need enough RAM and project indexing is slow, having 6 Java projects open and 2 front end projects open is a pain), bad run configurations (that making sharing run configurations across Windows/Linux really hard because of interpreter selection for scripts etc.) and confusing menus (due to how much functionality there is, a bit like Visual Studio, though the menu structure changes for different IDEs from them as well). The benefits still outweigh the negatives and so I pay for all their tools.
I like Visual Studio Code as a text editor (for anything really), but it feels like some of the refactoring and code editing support is lacking, especially when working with enterprise codebases. You can get pretty close to a fully fledged IDE with it, but at that point you're also trading some of the performance and lighter footprint away. Regardless, most of my projects have a .workspace file in them and I use Visual Studio Code together with JetBrains products.
I like other attempts at feature filled text editors as well, be it Fleet (though was a bit too unfinished last I tried their preview), CudaText (really interesting project with lots of nice features) or anything else, really.
At the end of the day, there is no single best IDE, just different ones that are suited for different tasks.
Edit: actually decided not to include the nano vs vi/vim discussion, since that's not super relevant to the discussion. Either is fine, I like the simplicity of nano more.
I respect your experience and opinion, but you’re missing the point here.
VSCode delivered a fantastic user experience. It reached a product market fit other editors could only dream of (let alone any editor based on browser tech). This, must have required engineering smarts and very thoughtful collaboration between product and engineering.
Hard engineering = delivering the best possible outcome within tight constraints/requirements. I’m sure the VSCode team was trying to hit a very specific number in responsiveness, startup time and memory usage.
Yes, compilers fall in that category as well as modern chip manufacturing (single digit nanometer fab FTW!). Those folks are the unsung heroes. However, we cannot discredit the fantastic product experience of VSCode. It was not possible without some innovation, clever engineering and a well thought out architecture. (I am sure they learned from Atom’s failings)
Update: > The VSCode team didn't have to make Electron. They got to use it, though. Along with the various lessons learned by the Atom project.
Yes! They are progressively a huge leap forward, built on the contributions of others before them. Now the VSCode framework has spawned a new generator of tools (such as Obsidian).
VSCode delivered a fantastic user experience. It reached a product market fit other editors could only dream of (let alone any editor based on browser tech). This, must have required engineering smarts and very thoughtful collaboration between product and engineering.
Hard engineering = delivering the best possible outcome within tight constraints/requirements. I’m sure the VSCode team was trying to hit a very specific number in responsiveness, startup time and memory usage.
Yes, compilers fall in that category as well as modern chip manufacturing (single digit nanometer fab FTW!). Those folks are the unsung heroes. However, we cannot discredit the fantastic product experience of VSCode. It was not possible without some innovation, clever engineering and a well thought out architecture. (I am sure they learned from Atom’s failings)
Update: > The VSCode team didn't have to make Electron. They got to use it, though. Along with the various lessons learned by the Atom project.
Yes! They are progressively a huge leap forward, built on the contributions of others before them. Now the VSCode framework has spawned a new generator of tools (such as Obsidian).
> VSCode is one of the greatest pieces of engineering of our time.
That must be one of the saddest things I read this month.
That must be one of the saddest things I read this month.
Yes, it’s not.
It’s just free.
What people mean when they say “I can’t believe how good this is” is:
“I can’t believe how good this is for something I got for free”
That’s not engineering excellence. It’s just engineering; being given away as a loss leader.
Vscode is good and well maintained, but that’s because a lot of money is being spent making it so.
Enjoy it; there’s no harm in taking money people are giving away. …just don’t presume they’re either a) doing it for love, or b) going to keep doing it indefinitely.
It’s just free.
What people mean when they say “I can’t believe how good this is” is:
“I can’t believe how good this is for something I got for free”
That’s not engineering excellence. It’s just engineering; being given away as a loss leader.
Vscode is good and well maintained, but that’s because a lot of money is being spent making it so.
Enjoy it; there’s no harm in taking money people are giving away. …just don’t presume they’re either a) doing it for love, or b) going to keep doing it indefinitely.
It's not like commercial alternatives are automatically better though, see Visual Studio (some aspects of VStudio are still better than VSCode, but VSCode has caught up fast, and as IDE for multi-language projects it is already better - the only important feature that's still inferior in VSCode compared to VStudio is the debugger integration).
If the current 'trajectories' remain roughly the same, VSCode will leave Visual Studio entirely in the dust in a couple of years.
If the current 'trajectories' remain roughly the same, VSCode will leave Visual Studio entirely in the dust in a couple of years.
I think that's a pretty bad choice of comparison. For one, they're two products under the same company. Secondly, Visual Studio is a bit of a dinosaur that suffers (and somewhat benefits) from a long history so it's easy for the VSCode team to look at that and just trim the fat and correct mistakes. They also target somewhat different domains with Visual Studio having a longer history in C++ and VSCode being more geared towards web dev (yes I know it's widely used for other languages but web is the leader and obvious target). Visual Studio is also by far not the best in its class, using IntelliJ products side by side with Visual Studio is like night and day especially when it comes to C++. A better comparison for VSCode would be something like Sublime Text since it's in the same product space of "lightweight" code editors with a focus on web.
Debugger integration has always been the killer differentiator for IDEs.
I worked around some of the vscode folk, there are a lot of them there who do it out of love for the product and the betterment of developer tooling.
Someone should write up the story of how it started, and how it got to where it is. The backstory is fascinating.
Someone should write up the story of how it started, and how it got to where it is. The backstory is fascinating.
They may be making it out of love, but they’re not the ones giving it away. The ones who are giving it away are not doing it out of love.
Out of love for long term profits maybe ;)
Vim and Emacs are free. This seems like the norm to me.
Yes, and when was the last time a large room of new developers told you how amazed they were at how great Emacs was? How easy it was to setup vim plugins? How seemless the experience was between Mac and windows and Linux?
Literally never would be my answer.
People like vscode because of the time and effort that has been spent making it friendly and approachable, yet still powerful.
Those are not just things that magically happen.
They didn’t happen because it’s free.
Those are things you get from a paid product team that prioritises issues, ux, etc. and a company that pays to implement them.
Literally never would be my answer.
People like vscode because of the time and effort that has been spent making it friendly and approachable, yet still powerful.
Those are not just things that magically happen.
They didn’t happen because it’s free.
Those are things you get from a paid product team that prioritises issues, ux, etc. and a company that pays to implement them.
> How seemless the experience was between Mac and windows and Linux?
It's pretty damn seamless with Vim. I code on a Mac these days, but was using Windows (w/ WSL) and Ubuntu about 50/50 before that. The same Vim (neovim) config script followed me everywhere.
It's pretty damn seamless with Vim. I code on a Mac these days, but was using Windows (w/ WSL) and Ubuntu about 50/50 before that. The same Vim (neovim) config script followed me everywhere.
Agreed. Vim was probably the most seamless of any software. If all I could see was the vim window, I wouldn't be able to say whether it was running on Linux or Mac. I don't think it gets any better than that.
> Yes, and when was the last time a large room of new developers told you how amazed they were at how great Emacs was? How easy it was to setup vim plugins? How seemless the experience was between Mac and windows and Linux?
This seems like a reflection of your environment. This has happened to me more than once with both Vim and Emacs (and not just at a Vim conference:-D). The environment at the time one was a C++ shop, another was a Ruby conference. For example people were amazed when they heard about how you can call vim APIs with Ruby!
This seems like a reflection of your environment. This has happened to me more than once with both Vim and Emacs (and not just at a Vim conference:-D). The environment at the time one was a C++ shop, another was a Ruby conference. For example people were amazed when they heard about how you can call vim APIs with Ruby!
Literally yesterday I set up Emacs on my new laptop, the Doom Emacs distribution. It took around 10 minutes overall.
The thing that surprises me most is the fact that people don’t want to learn the tools. I get the point that Emacs/Vim ecosystem is difficult to get used to because of well, multiple reasons. But it worths the time because these tools are amazing. You need to invest a couple of hours in Vim, probably some more in Emacs, but it’s just one time investment and then you have an instrument (or two) to rely on.
The thing that surprises me most is the fact that people don’t want to learn the tools. I get the point that Emacs/Vim ecosystem is difficult to get used to because of well, multiple reasons. But it worths the time because these tools are amazing. You need to invest a couple of hours in Vim, probably some more in Emacs, but it’s just one time investment and then you have an instrument (or two) to rely on.
The thing to keep in mind with VS Code is that they built a new IDE on a rather humble platform, and somehow managed to leapfrog every other IDE in the market (for JS and Python anyhow) in terms of functionality while keeping performance good. It may not be a marvel of engineering, but it is a marvel for having strong product vision and top notch execution while also being well engineered.
For JS perhaps, PyCharm has a few tricks up its sleeve that I haven’t quite seen in VS Code, especially wrt debugger support.
That said, the Python IDE market has been sadly underfed for surprisingly long.
That said, the Python IDE market has been sadly underfed for surprisingly long.
[deleted]
It made me sad as well. It’s interesting that it did. I think it’s related to the fact that I read it in HN I guess, and what kind of commentary do I seek and enjoy when roaming around here. Although of course I respect the commenter’s opinion, and we can all politely disagree and have different points of view, for some reason when I read this one I felt a certain degree of sadness.
Maybe it's the stagnation in our field the "it's good enough" mentality.
It is. It reminds me of that unhinged essay in praise of Hillary Clinton:
> Maybe she is more than a president. Maybe she is an idea, a world-historical heroine, light itself.
No criticism meant of either VSCode or Hillary Clinton, but sometimes fans take things a bit too far.
> Maybe she is more than a president. Maybe she is an idea, a world-historical heroine, light itself.
No criticism meant of either VSCode or Hillary Clinton, but sometimes fans take things a bit too far.
Could you elaborate on what exactly you find "sad" about it?
Something that immediately comes to mind is https://github.com/chrislgarry/Apollo-11#readme.
Of course, this is an earlier generation. But if the commenter is correct that VS Code is one of the greatest pieces of engineering of our time, then what the heck are we doing. And if the commenter is incorrect, then what the heck are we doing as a community in our duty to educate to the extent that the commenter doesn't realize that massive projects like this have been implemented, and continue to be implemented.
We have rockets that land by themselves, trucks making cross-country autonomous trips without intervention, multiple systems that can securely run arbitrary sandboxed code from anywhere in the world by simply typing a URL. I'd want someone to be excited not by an IDE for an IDE's sake, but what they can build with their IDE.
Of course, this is an earlier generation. But if the commenter is correct that VS Code is one of the greatest pieces of engineering of our time, then what the heck are we doing. And if the commenter is incorrect, then what the heck are we doing as a community in our duty to educate to the extent that the commenter doesn't realize that massive projects like this have been implemented, and continue to be implemented.
We have rockets that land by themselves, trucks making cross-country autonomous trips without intervention, multiple systems that can securely run arbitrary sandboxed code from anywhere in the world by simply typing a URL. I'd want someone to be excited not by an IDE for an IDE's sake, but what they can build with their IDE.
I think the point here is that there are two ways to measure impact. One is just a raw "how impressive is this code" score. In that case, self-landing rockets, self driving trucks, etc, all score much higher than VSCode.
On the other hand, an equally valid measure of impact is utility * number of people. While things like self-driving trucks are extremely cool, as of today their overall impact is quite small. VSCode impacts an enormous amount of people every single day and saves them a ton of time.
On the other hand, an equally valid measure of impact is utility * number of people. While things like self-driving trucks are extremely cool, as of today their overall impact is quite small. VSCode impacts an enormous amount of people every single day and saves them a ton of time.
Well put. Though by that second metric, I'm not sure that the marginal utility of VSCode, relative to a world where Atom existed and was equally free and accessible, would place it in the highest echelon of widespread-utility-creating engineering marvels.
Visual Studio is right there. A lot of the features you love about VSCode are present in Visual Studio. But Visual Studio is a much more robust piece of software.
So while VSCode is nice, it's not even the most impressive piece of software bearing the Visual Studio branding.
So while VSCode is nice, it's not even the most impressive piece of software bearing the Visual Studio branding.
Second that....that statement would be even sad (maybe even more) in the 60's.
"VSCode is the greatest productivity tool in the history of software engineering" in a world where vi and emacs exist seems like a bit of an exaggeration, and I'm not even a fan of either (VS Code is my daily driver; I like my GUI editors and I like them to behave like normal apps on the platform I'm running).
Of course a lot goes on but pre-LSP and post-LSP are day and night. There is now a huge amount of serious language tooling that _isn't_ locked up into one or several editors.
Now some might point out that LSP-based stuff is, like, bloat. Sure, OK. But there's a lot of motivation to do work that can pay off across the board. So much language stuff was based off of random regexes! It's hard to overstate how much better of an editor situation we are in than 10 years ago.
This isn't even getting into VS Code offering a way for you to put... one? two? files into a git repo and have that mean that opening the editor will spawn a container, _install itself in the container_, and run there while still having a native GUI for the actual usage of the tool. So much incidental complexity, gone!
One might point out that containers are a "big ball of mud" solution, but I vastly prefer that to big setup scripts that only half work. Here's to hoping we can shrink the ball of mud.
Now some might point out that LSP-based stuff is, like, bloat. Sure, OK. But there's a lot of motivation to do work that can pay off across the board. So much language stuff was based off of random regexes! It's hard to overstate how much better of an editor situation we are in than 10 years ago.
This isn't even getting into VS Code offering a way for you to put... one? two? files into a git repo and have that mean that opening the editor will spawn a container, _install itself in the container_, and run there while still having a native GUI for the actual usage of the tool. So much incidental complexity, gone!
One might point out that containers are a "big ball of mud" solution, but I vastly prefer that to big setup scripts that only half work. Here's to hoping we can shrink the ball of mud.
LSP is nice, but it's not an engineering marvel. It's just a text protocol. It's not even a great text protocol; it's okay, but not great. There's been lots of "LSP-like" protocols over the years, even decades, it's just that none of them really became a standard (partly because no one actually invested the time in writing one, and it just used an "ad-hoc protocol"). And of course the general concept of "process A communicates with process B over a text protocol" is all around us.
Like I said, I like LSP, but a great exceptional feat of engineering it is not.
This applies to most of VSCode as near as I can tell.
Like I said, I like LSP, but a great exceptional feat of engineering it is not.
This applies to most of VSCode as near as I can tell.
The thing is it successfully had work put in so that it’s a standard. “They did a thing that basically no one succeeded in doing” is, imo, proof of something.
I don't think anyone tried to really make a standard, as far as I know. But even if they did, there's lots of reasons why some things take off and others don't: putting in the work as you mentioned, whether it's any good, marketing, state of other tooling and tech, zeitgeist at the time ("timing"), etc.
Would something like Go have taken off 20 years ago? I'm not so sure, the zeitgeist at the time was very much in the direction of dynamic languages. And would Python take off if it was released today? Not so sure about that either.
But you know, putting in the work to write down a specification isn't really a marvel of engineering. It's ... just putting in the work.
Would something like Go have taken off 20 years ago? I'm not so sure, the zeitgeist at the time was very much in the direction of dynamic languages. And would Python take off if it was released today? Not so sure about that either.
But you know, putting in the work to write down a specification isn't really a marvel of engineering. It's ... just putting in the work.
[deleted]
> But you know, putting in the work to write down a specification isn't really a marvel of engineering. It's ... just putting in the work.
It's no marvel of engineering, but someone did put in the work, and others used it, more that can be said about many other things that might be "better engineered".
It's no marvel of engineering, but someone did put in the work, and others used it, more that can be said about many other things that might be "better engineered".
I never said they were "better engineered". I only wanted to refute that "VSCode is one of the greatest pieces of engineering of our time", which went to use LSP as an example in this (sub)thread.
It's proof of nothing but popularity, which isn't indicative of quality in the least.
I don't know what LSP is or why you'd think it's anything special or game-changing.
It just seems to be a generic interface to describe language bindings, which most text editors have.
In practice it's mostly a bad thing because any advanced language has special needs which will end up difficult to address by funneling everything through a common interface.
It just seems to be a generic interface to describe language bindings, which most text editors have.
In practice it's mostly a bad thing because any advanced language has special needs which will end up difficult to address by funneling everything through a common interface.
It is a generic interface which also helps with many capabilities, including proper refactoring, formatting, and the like. Since VSCode does so much through it, basically all nontrivial interaction with the code base can also be used in other editors.
A far cry from the days of sublime text’s regex-based autocomplete
A far cry from the days of sublime text’s regex-based autocomplete
Except it only works for trivial languages.
What languages do you consider "non-trivial"?
Rust-analyzer works via the LSP, and I'd hardly call Rust "trivial".
Vim and Emacs cannot compare to VSCode when it comes to productivity. With VSCode, you type the name of any programming language in the extension search, click "Install", and you have a world-class development environment for that language ready to go. This is light years ahead of the traditional editors, and saves many hours of time.
Not to mention that VSCode has countless other productivity boosters built in which would require plugin hunting or fiddling with configuration files for Vim and Emacs.
Not to mention that VSCode has countless other productivity boosters built in which would require plugin hunting or fiddling with configuration files for Vim and Emacs.
> Vim and Emacs cannot compare to VSCode when it comes to productivity.
For me you are 100% correct. In either vim or emacs I am at least 10 times more productive than I would ever be in VSCode. No comparison.
> Not to mention that VSCode has countless other productivity boosters built in which would require plugin hunting or fiddling with configuration files for Vim and Emacs.
First, there are distributions of both vim and emacs that come bundled with sets of plugins, if that is the sort of thing you like.
Second, some people enjoy customizing their editor to work exactly the way they want to. You obviously prefer the "set up out of the box" experience, and that is totally fine. Others boost their productivity by customizing their tools. Different people work differently.
Everyone else is not like you. That doesn't make their preferences invalid.
I have known many developers over the years who use both editors, and are extremely productive using their tool of choice. I am certain many of them would not be more productive using VSCode - it simply does not offer them anything significant enough to them to make that big of a difference.
For me you are 100% correct. In either vim or emacs I am at least 10 times more productive than I would ever be in VSCode. No comparison.
> Not to mention that VSCode has countless other productivity boosters built in which would require plugin hunting or fiddling with configuration files for Vim and Emacs.
First, there are distributions of both vim and emacs that come bundled with sets of plugins, if that is the sort of thing you like.
Second, some people enjoy customizing their editor to work exactly the way they want to. You obviously prefer the "set up out of the box" experience, and that is totally fine. Others boost their productivity by customizing their tools. Different people work differently.
Everyone else is not like you. That doesn't make their preferences invalid.
I have known many developers over the years who use both editors, and are extremely productive using their tool of choice. I am certain many of them would not be more productive using VSCode - it simply does not offer them anything significant enough to them to make that big of a difference.
[deleted]
VSCode's out-of-the-box configuration is better suited for the most common modern development contexts (probably?) and its customization, add-on and overall UIs are definitely more aligned with modern conventions, more readily accessible and more exploration-friendly.
But VSCode is also less responsive, more resource heavy and ultimately less flexible or extensible. Vim and emacs have more of a learning curve, and their configuration is more fiddly, but the biggest hurdle is probably that the interfaces they use for this predate modern GUI conventions. Notably the "search by keyword, click install, done" workflow for adding extensions is definitely standard behavior in emacs (and vim too, I assume).
Configuration fiddling aside - and that shouldn't be a daily activity - "Vim and Emacs cannot compare to VSCode when it comes to productivity" is a claim that does not hold up to scrutiny. In the hands of an expert user, emacs (and again, I assume vim too) is definitely more capable and productive than VSCode. I'm fairly confident this could be demonstrated objectively. They just _do more_ and can be made to do it _exactly the way you want_ them to. The learning curve for vi/vim and emacs represents an investment, but one that can pay off handsomely.
The topic of this thread is actually a perfect example of one of the major advantages of these "classic" editors. Atom - and countless editors that have come before - has been sunset. And it will eventually happen to VSCode too. Your Atom customization skills (and mine) are wasted. Now we need to pick up a new editor and climb a new learning curve. But vim or emacs mastery is a skill you'll literally be able to use for the rest of your career.
It's absolutely valid to decide that learning how to use these esoteric tools well is not worth the effort to you personally, but there _is_ a reason these tools have been around for nearly half a century.
But VSCode is also less responsive, more resource heavy and ultimately less flexible or extensible. Vim and emacs have more of a learning curve, and their configuration is more fiddly, but the biggest hurdle is probably that the interfaces they use for this predate modern GUI conventions. Notably the "search by keyword, click install, done" workflow for adding extensions is definitely standard behavior in emacs (and vim too, I assume).
Configuration fiddling aside - and that shouldn't be a daily activity - "Vim and Emacs cannot compare to VSCode when it comes to productivity" is a claim that does not hold up to scrutiny. In the hands of an expert user, emacs (and again, I assume vim too) is definitely more capable and productive than VSCode. I'm fairly confident this could be demonstrated objectively. They just _do more_ and can be made to do it _exactly the way you want_ them to. The learning curve for vi/vim and emacs represents an investment, but one that can pay off handsomely.
The topic of this thread is actually a perfect example of one of the major advantages of these "classic" editors. Atom - and countless editors that have come before - has been sunset. And it will eventually happen to VSCode too. Your Atom customization skills (and mine) are wasted. Now we need to pick up a new editor and climb a new learning curve. But vim or emacs mastery is a skill you'll literally be able to use for the rest of your career.
It's absolutely valid to decide that learning how to use these esoteric tools well is not worth the effort to you personally, but there _is_ a reason these tools have been around for nearly half a century.
You’re definitely not coming in to this having much familiarity with the ecosystem of either other tool. Distributions like LunarVim, Spacemacs, and Doomemacs exist that fill that gap between the basic terminal editors and a ready-for-anything experience. Think, open a source file and get the language server auto detected and suggested for installation, right in vim.
Not to mention IntelliJ which I can’t help but keep coming back to after repeatedly getting frustrated enough trying to adopt VSCode. The git tooling in VSCode’s marketplace is a far cry from what’s available for some of these other tools. Fortunately for me, Fleet (new editor aimed at VSCode segment) is maturing at a rapid enough pace that I’ll likely be able to migrate to it in months/weeks and hopefully have a more zen experience.
Not to mention IntelliJ which I can’t help but keep coming back to after repeatedly getting frustrated enough trying to adopt VSCode. The git tooling in VSCode’s marketplace is a far cry from what’s available for some of these other tools. Fortunately for me, Fleet (new editor aimed at VSCode segment) is maturing at a rapid enough pace that I’ll likely be able to migrate to it in months/weeks and hopefully have a more zen experience.
For a while. Why not just stick to one that'll last your lifetime, ie Emacs/vim?
>With VSCode, you type the name of any programming language in the extension search, click "Install", and you have a world-class development environment
Very minor feature. It is not usefull unless you are constantly hunting for new languages.
>Not to mention that VSCode has countless other productivity boosters built in which would require plugin hunting or fiddling with configuration files for Vim and Emacs.
This is only true if you are comparing default vim/emacs to VSCode, which would be quite unfair. Compare it to some vim/emacs distributions and list the differences.
Very minor feature. It is not usefull unless you are constantly hunting for new languages.
>Not to mention that VSCode has countless other productivity boosters built in which would require plugin hunting or fiddling with configuration files for Vim and Emacs.
This is only true if you are comparing default vim/emacs to VSCode, which would be quite unfair. Compare it to some vim/emacs distributions and list the differences.
> Very minor feature.
Moreover it is supported out-of-the-box in emacs: `M-x list-packages`.
I think `:packadd` or something may be the equivalent for vim.
Moreover it is supported out-of-the-box in emacs: `M-x list-packages`.
I think `:packadd` or something may be the equivalent for vim.
> Moreover it is supported out-of-the-box in emacs: `M-x list-packages`.
Or just use the menu; click on "Options” → “Manage Emacs Packages”. No need to scare people with “M-x” weirdness right out of the gate when it isn’t necessary since the option is right there in the menu.
Or just use the menu; click on "Options” → “Manage Emacs Packages”. No need to scare people with “M-x” weirdness right out of the gate when it isn’t necessary since the option is right there in the menu.
Menus? Clicking? That doesn't seem very emacs-y of you. M-x weirdness - up to and including the fact that it refers to a "Meta" key not found on modern keyboards - is exactly the kind of gatekeeping that allows me to feel superior for knowing how to exit emacs gracefully.
But seriously you raise a good point. The OS-native menus in aquaemacs and similar go a long way toward making emacs more accessible and explore-able.
No joke, it is legitimately hard for a newbie to figure out how to close emacs, which is pretty ridiculous. (It's `C-x C-c` btw, but I honestly don't know how a first-time user could figure that out on their own without a menu. You need to be _told_. It's absolutely crazy that you need to consult the manual to know how it exit the program.)
EDIT: It looks like this thread is too deep for me to post a genuine reply, but just to respond to the "it's just plain emacs too" comment. Good point, and I was aware of that but I didn't know what to call the plain-vanilla Windowed/GUI-enabled emacs. I guess it's just "emacs". I actually hesitated on naming aquaemacs for exactly this reason, which is why I hedged with "or similiar".
But seriously you raise a good point. The OS-native menus in aquaemacs and similar go a long way toward making emacs more accessible and explore-able.
No joke, it is legitimately hard for a newbie to figure out how to close emacs, which is pretty ridiculous. (It's `C-x C-c` btw, but I honestly don't know how a first-time user could figure that out on their own without a menu. You need to be _told_. It's absolutely crazy that you need to consult the manual to know how it exit the program.)
EDIT: It looks like this thread is too deep for me to post a genuine reply, but just to respond to the "it's just plain emacs too" comment. Good point, and I was aware of that but I didn't know what to call the plain-vanilla Windowed/GUI-enabled emacs. I guess it's just "emacs". I actually hesitated on naming aquaemacs for exactly this reason, which is why I hedged with "or similiar".
To be clear, I’m not talking about the menus in some special Emacs port like aquamacs, I mean the regular Emacs, with its menu bar, seen here: https://www.gnu.org/software/emacs/tour/
I think it actually helps to present M-x to new people as being the "command palette" for Emacs. A modern starting Emacs setup should have a vertical completion setup and fuzzy matching, so hitting M-x and a few keys gives you a list of matching commands with their documentation next to them.
It’s also supported out of the box in SublimeText, though probably not as extensive as VSCode. Code completion, for example, is more like guessing in SublimeText. Though I can’t imagine either emacs or VSCode to respond as quickly to input as SublimeText, which is one of the reasons it will remain the text editor of choice for me. At least when writing some code in Lua.
I appreciate that perspective. Launching quickly and no input latency are probably my base demands from a text editor. Not sufficient, but necessary. I may need to give Sublime a closer look.
FWIW you _can_ get emacs to launch as quickly as, say, vi, and to respond to input as quickly as just typing in the terminal (but in my experience the default GUI doesn't have noticeable input latency):
* `emacs -nw` will launch emacs in a terminal rather than a OS-native GUI window. This has surprisingly little impact on the interface or usability, but it does make cosmetic tweaks like font-rendering more difficult.
* `emacs --daemon` will start an "emacs server" process running in the background, and `emacsclient` will connect a UI instance to it (so you don't need to re-process all your .emacs stuff each time)
That said you can probably introduce a lot of input latency by hooking a slow method to the keypress event, but that applies to Atom and VSCode as well as emacs. But all three of them seem to do OK suggesting auto-completions of one kind or another, which must be handled on keydown or similar, so maybe that's not as critical as I assume.
I usually have a text editor open all the time anyway (recently Atom, lately VSCode) so the time-to-launch isn't that big of a deal in practice (and isn't _that_ large to begin with) but I am disproportionately, irrationally annoyed every time I need to wait for the editor to start.
FWIW you _can_ get emacs to launch as quickly as, say, vi, and to respond to input as quickly as just typing in the terminal (but in my experience the default GUI doesn't have noticeable input latency):
* `emacs -nw` will launch emacs in a terminal rather than a OS-native GUI window. This has surprisingly little impact on the interface or usability, but it does make cosmetic tweaks like font-rendering more difficult.
* `emacs --daemon` will start an "emacs server" process running in the background, and `emacsclient` will connect a UI instance to it (so you don't need to re-process all your .emacs stuff each time)
That said you can probably introduce a lot of input latency by hooking a slow method to the keypress event, but that applies to Atom and VSCode as well as emacs. But all three of them seem to do OK suggesting auto-completions of one kind or another, which must be handled on keydown or similar, so maybe that's not as critical as I assume.
I usually have a text editor open all the time anyway (recently Atom, lately VSCode) so the time-to-launch isn't that big of a deal in practice (and isn't _that_ large to begin with) but I am disproportionately, irrationally annoyed every time I need to wait for the editor to start.
>>With VSCode, you type the name of any programming language in the extension search, click "Install", and you have a world-class development environment
> Very minor feature. It is not usefull unless you are constantly hunting for new languages.
The big advantage isn't just installing but keeping them up to date without any actual effort. I used to know vimscript, used to understand how the vim package managers I used works and all. With VSCode I don't even know in which language are extenssions written.
I work mostly on golang, and now the environment is certainly more stable, but I remember that in order to have go extensions working on vim I used to have to be updating manually the extensions pretty much every release and it was some effort. Now I update the golang version and things just work.
> Very minor feature. It is not usefull unless you are constantly hunting for new languages.
The big advantage isn't just installing but keeping them up to date without any actual effort. I used to know vimscript, used to understand how the vim package managers I used works and all. With VSCode I don't even know in which language are extenssions written.
I work mostly on golang, and now the environment is certainly more stable, but I remember that in order to have go extensions working on vim I used to have to be updating manually the extensions pretty much every release and it was some effort. Now I update the golang version and things just work.
I do agree the Vim plugin ecosystem (and vimscript) sort of sucks. That said, I've been using Vim for 20+ years and generally only mess with my config and plugins once every 2-3 years at most. Since the thing is just supposed to edit text, why would I feel compelled to update them, much less try to figure out what language they're written in?
> I work mostly on golang, and now the environment is certainly more stable, but I remember that in order to have go extensions working on vim I used to have to be updating manually the extensions pretty much every release and it was some effort. Now I update the golang version and things just work.
Most of that is because the Go ecosystem moved ahead. Five years ago something like vim-go would depend on maybe 15 different binaries that operated on the source code. Automatically updating all of that is possible, but somewhat slow and tricky (especially because there were no modules yet, so had to "go get -u" all these different binaries to check for updates).
Now, it's basically just gopls. You don't even need vim-go any more; just Vim + $any_lsp + gopls gives a very similar experience.
Most of that is because the Go ecosystem moved ahead. Five years ago something like vim-go would depend on maybe 15 different binaries that operated on the source code. Automatically updating all of that is possible, but somewhat slow and tricky (especially because there were no modules yet, so had to "go get -u" all these different binaries to check for updates).
Now, it's basically just gopls. You don't even need vim-go any more; just Vim + $any_lsp + gopls gives a very similar experience.
If we're talking about professional tools i'm not sure if setting it up as fast as possible is the best productivity comparison. All good tools need getting to know them, and setting things up yourself (eg. in vim) means you also know how to fix any issues that pop up in the future. Installing a vscode plugin for playing around is great, but it doesn't automatically make you a professional and stable production environment.
On the contrary, working in a professional environment, almost no one I know is using vim or Emacs seriously day to day for coding. We all use VSCode because that is a tool that just works for our team and company. Having a unified tool set works wonders for group productivity, no more messing around with some employees not having a certain package and others needing to customize their vim configs. No, everything simply works, and we can focus on the actual coding rather than messing around with our configs.
My experience of VSCode _is_ messing around with my config, but giving up and going back to a more mature editor because I could never get it to do what I wanted. I suppose capitulation was also an option, but I dislike the characterisation of tooling as something other than ‘actual coding’.
That's very strange, when did you use it? And what config did you need? In our company there really isn't any config we mess around with, just download the language plug-ins and that's it. If someone wants to add more then that's fine but not required.
I have a setup that I maintain and I pop back to it every six months or so. There are probably three classes of things that end up turning me off.
1) VSCode is very UI heavy and doesn’t allow consistent keyboard and text navigation. I want my text editor to be text-based, and it slows me down to have different types of windows (some of which seem impossible to hide permanently) with inconsistent forms of navigation.
2) The terminal window is its own thing, even if you open it in an editor window, which is then ignored by anything that interacts with the terminal. This is more what I want but is very limited and immature:
https://marketplace.visualstudio.com/items?itemName=jeffgran...
The lack of an infrastructure like Emacs comint mode also means there’s no good text-based database mode either. I want the same navigation, search and editing functions in every single window I have to interact with.
3) Where analogues to Emacs modes exist, they are universally less featureful, often because of fundamental limitations of the VSCode extension API. REPLs do less and offer less programmability. Edamagit is a fine and welcome effort but not as good as Magit.
If people want an editor with a little bit of auto completion and some squiggly lines to tell them they’ve typed something wrong VSCode is great. I have many mostly happy VSCode users within my organisation. But I think every individual programmer, like every team, should have a regular little retrospectives with themselves. What work did I do today, what would have made it flow better? In every case, I can build that in Emacs, but it’s much more friction in VSCode. This is partly immaturity and partly the APIs not offering as much. Long term I’m rooting for VSCode because it’s snappy and has undeniable market share. But it’s never quite been there for me yet.
1) VSCode is very UI heavy and doesn’t allow consistent keyboard and text navigation. I want my text editor to be text-based, and it slows me down to have different types of windows (some of which seem impossible to hide permanently) with inconsistent forms of navigation.
2) The terminal window is its own thing, even if you open it in an editor window, which is then ignored by anything that interacts with the terminal. This is more what I want but is very limited and immature:
https://marketplace.visualstudio.com/items?itemName=jeffgran...
The lack of an infrastructure like Emacs comint mode also means there’s no good text-based database mode either. I want the same navigation, search and editing functions in every single window I have to interact with.
3) Where analogues to Emacs modes exist, they are universally less featureful, often because of fundamental limitations of the VSCode extension API. REPLs do less and offer less programmability. Edamagit is a fine and welcome effort but not as good as Magit.
If people want an editor with a little bit of auto completion and some squiggly lines to tell them they’ve typed something wrong VSCode is great. I have many mostly happy VSCode users within my organisation. But I think every individual programmer, like every team, should have a regular little retrospectives with themselves. What work did I do today, what would have made it flow better? In every case, I can build that in Emacs, but it’s much more friction in VSCode. This is partly immaturity and partly the APIs not offering as much. Long term I’m rooting for VSCode because it’s snappy and has undeniable market share. But it’s never quite been there for me yet.
Sounds like junior web devs working on Javascript pull-in-the-whole-internet code bases. Not criticising your choice, it might be the best solution to your specific challenges; that just does not sound like the environment I work in. If somebody can't configure their own editor and its dependencies, I wouldn't trust them to handle application dependencies in the supply chain either.
Then again, I might pre-date the which editor to use and how to configure it era.
Then again, I might pre-date the which editor to use and how to configure it era.
For seniors, sure that makes sense, use whatever editor you want, but for onboarding juniors, we definitely have a recommended toolset just so we can make sure there aren't incompatibilities and that their productivity is still high, ie having a debugger when needed, using code completion, error checking, linting tools etc.
My point is you could configure all this stuff in Vim or Emacs but it's not as straightforward plus it wastes time when onboarding. We'd rather have an IDE like experience.
My point is you could configure all this stuff in Vim or Emacs but it's not as straightforward plus it wastes time when onboarding. We'd rather have an IDE like experience.
I don't understand, what config is necessary to work on the same codebase? Whatever program I use to open source code, eg. emacs or vscode, shouldn't matter should it?
The only time I ever had to use vscode working with other programmers was for pair programming, using the vscode sharing thing. Apart for that, not being able to use emacs would be a deal breaker - using other editors is like wading through quicksand for me.
The only time I ever had to use vscode working with other programmers was for pair programming, using the vscode sharing thing. Apart for that, not being able to use emacs would be a deal breaker - using other editors is like wading through quicksand for me.
I made a related reply here: https://news.ycombinator.com/item?id=34020775
It's not just the code, we'd want everyone on the team to use the appropriate toolsets including debugging and error checking support. They can set it up in Vim and Emacs if they want but it saves time for the team as a whole if we all use a standardized set of tools.
It's not just the code, we'd want everyone on the team to use the appropriate toolsets including debugging and error checking support. They can set it up in Vim and Emacs if they want but it saves time for the team as a whole if we all use a standardized set of tools.
Yes, that makes perfect sense. If they want to set up an alternative editor, doing it on their own time is a reasonable expectation. No question vscode is millions of times easier for juniors.
These kinds of hyperboles are really really bad. You are stating that if it took 1 minute to install a plugin and get to work in vscode, it would take 694.4 days to do the same in other editors? Please use reasonable numbers if you are trying to make a valid point.
Not just 'other editors', I was thinking about emacs specifically. I think my point was fairly obvious. Maybe not a million times, but probably hundreds. Vscode and other modern editors use key combinations everyone knows by default, eg. C-q, C-c, C-v, etc., have gui directory browsing- so there is essentially no learning curve.
It takes weeks (at least) using emacs/vim until text editing/movement starts to pay off. There's no learning curve for `M-x package-install`, but if there is some variable that needs to be customized, like the path to an executable or something, that's a whole rabbit hole to go down, and at some point you need to learn lisp or you'll waste a lot of time being confused by errors.
During the only programming course I took in college, one in which emacs was required, I spent as much time learning emacs as anything else (it was also the most valuable thing I learned so I'm grateful in the long run).
It takes weeks (at least) using emacs/vim until text editing/movement starts to pay off. There's no learning curve for `M-x package-install`, but if there is some variable that needs to be customized, like the path to an executable or something, that's a whole rabbit hole to go down, and at some point you need to learn lisp or you'll waste a lot of time being confused by errors.
During the only programming course I took in college, one in which emacs was required, I spent as much time learning emacs as anything else (it was also the most valuable thing I learned so I'm grateful in the long run).
> Having a unified tool set works wonders for group productivity, no more messing around with some employees not having a certain package and others needing to customize their vim configs.
Completely agree: the entire company should be on a common, future-proof, extensible, free platform: Emacs!
I honestly don’t understand why anyone bothers wasting effort on any other editor.
Completely agree: the entire company should be on a common, future-proof, extensible, free platform: Emacs!
I honestly don’t understand why anyone bothers wasting effort on any other editor.
Yes, I'd agree if everyone wanted to use Emacs too, fine by me. However everyone uses VSCode so that's what we will continue to use.
You misspelled Vim/Neovim. wink
> All good tools need getting to know them
Wrong. Good tools don't require that. Imagine someone showed you a complicated mechanical contraption and told you "it's a type of hammer, much better than the 'non-professional' hammer, but you need to 'get to know it' first". That product would be dead on arrival.
Great tools are obvious in their base functionality and have optional additional layers that can be discovered if necessary. When you have to search the web to find out how to close the editor you just opened, because it works differently than every other program running on your system, you know you're using a bad tool.
Wrong. Good tools don't require that. Imagine someone showed you a complicated mechanical contraption and told you "it's a type of hammer, much better than the 'non-professional' hammer, but you need to 'get to know it' first". That product would be dead on arrival.
Great tools are obvious in their base functionality and have optional additional layers that can be discovered if necessary. When you have to search the web to find out how to close the editor you just opened, because it works differently than every other program running on your system, you know you're using a bad tool.
> > All good tools need getting to know them
> Wrong. Good tools don't require that.
No, good tools absolutely require learning how to use them.
To think that they don't is a maddening take because it has led to the infantilization of applications in so many areas of the software world.
There is definitely a place for simplistic tools that have no customization, no configuration, a single limited way to do anything and no hooks/APIs to modify their internal behavior. Yes, such tools are easiest to pick up and casually use in the limited way they can be used and that's often all that is needed.
But, the world also need professional tools. In the non-software world this is obvious and such tools exist in every profession. Even your hammer example is wrong as the sibling post noted, there are "professional hammers" (nail guns) that require a bit more care to use but are much better.
There is a place for test lights (that anyone can touch to a wire to see if there's voltage). But we can also buy voltage meters of increasing complexity and capabilities. They start to require a little bit of understanding of volts and amps and ohms, but they are so much more useful. But yes you need to learn a little to use them. There are also things like oscilloscopes which an untrained person wouldn't stand a chance to know how to use at first sight. But of course they are vastly more useful once you learn the tool.
Just one random example of thousands. Yes, good tools absolutely require training.
> Wrong. Good tools don't require that.
No, good tools absolutely require learning how to use them.
To think that they don't is a maddening take because it has led to the infantilization of applications in so many areas of the software world.
There is definitely a place for simplistic tools that have no customization, no configuration, a single limited way to do anything and no hooks/APIs to modify their internal behavior. Yes, such tools are easiest to pick up and casually use in the limited way they can be used and that's often all that is needed.
But, the world also need professional tools. In the non-software world this is obvious and such tools exist in every profession. Even your hammer example is wrong as the sibling post noted, there are "professional hammers" (nail guns) that require a bit more care to use but are much better.
There is a place for test lights (that anyone can touch to a wire to see if there's voltage). But we can also buy voltage meters of increasing complexity and capabilities. They start to require a little bit of understanding of volts and amps and ohms, but they are so much more useful. But yes you need to learn a little to use them. There are also things like oscilloscopes which an untrained person wouldn't stand a chance to know how to use at first sight. But of course they are vastly more useful once you learn the tool.
Just one random example of thousands. Yes, good tools absolutely require training.
>Wrong. Good tools don't require that. Imagine someone showed you a complicated mechanical contraption and told you "it's a type of hammer, much better than the 'non-professional' hammer, but you need to 'get to know it' first". That product would be dead on arrival.
You mean like a nail gun? The kind that all professional roofers use?
You mean like a nail gun? The kind that all professional roofers use?
Does one need to "get to know a nail gun first" to use it well?
Considering that nails from a nail gun have a habit of following the grain in surprising ways (possibly causing the nail to do a 180 degree turn and find your finger), yes, it is important for a prospective user to "get to know it".
Step inside a woodworking- or machine shop sometime and see how many of tools there you can instantly use with proficiency, with no instruction. (Please stand back from the table saws while trying this experiment.)
It’s wonderful and beautiful that we can get real work done with a heavy thing on a stick, but pretending every tool can be as simple as a hammer is not really arguing in good faith.
It’s wonderful and beautiful that we can get real work done with a heavy thing on a stick, but pretending every tool can be as simple as a hammer is not really arguing in good faith.
I’ve seen so many people use a hammer wrong. They don’t swing it effectively, hold it too high on the handle, or even use the wrong type of hammer for the job (yes, there are different types of hammers designed for different types of hammering).
And that’s before you go into all the other technologies invented that are evolutions of the hammer, from nail guns to jackhammers.
And that’s before you go into all the other technologies invented that are evolutions of the hammer, from nail guns to jackhammers.
>> All good tools need getting to know them
> Wrong. Good tools don't require that.
So any tool that is complicated enough to use that it requires more than 5 minutes to understand can't be a good tool? That is just false.
Obviously vim is not the tool for you (and emacs probably isn't either). You don't like the way they work, so don't use them. They are not bad tools. They are both very good tools. They are just not tools that fit your preferences. They do fit other people's preferences.
> Wrong. Good tools don't require that.
So any tool that is complicated enough to use that it requires more than 5 minutes to understand can't be a good tool? That is just false.
Obviously vim is not the tool for you (and emacs probably isn't either). You don't like the way they work, so don't use them. They are not bad tools. They are both very good tools. They are just not tools that fit your preferences. They do fit other people's preferences.
There are more complex problems than "nail" requiring more complex tools than "hammer".
And even the hammer metaphor falls apart pretty quickly: compressor driven nail guns are commonly used.
VSCode is obviously has something going for it, else so many people wouldn't be using it. Vi and Emacs are also extremely popular and have been for decades.
And even the hammer metaphor falls apart pretty quickly: compressor driven nail guns are commonly used.
VSCode is obviously has something going for it, else so many people wouldn't be using it. Vi and Emacs are also extremely popular and have been for decades.
This is completely wrong. Basic tools that solve basic tasks are easy to learn and understand.
I use spectrum analyzers to identify partial discharges in high voltage equipment. Sometimes I use a hammer. One of them require deep knowledge, with the other one I just give the equipment a whack with to see where the fault lies.
I use spectrum analyzers to identify partial discharges in high voltage equipment. Sometimes I use a hammer. One of them require deep knowledge, with the other one I just give the equipment a whack with to see where the fault lies.
An operating theatre is filled with tools that require decades to master and years to learn to use originally. Even if you forget the surgeon's skill there is still the likes of ECMO (run full time by a perfusionist), EMG/NCS (an electrophysiologist) or the old classic, an anaesthetic machine (anaesthetist). Many of the UIs on these are, to the outside eye, downright janky.
Good tools usually have a beneficial tradeoff - it takes a minute or two to learn how to do it, but you have recurrent measureable gains in productivity after that. That includes closing Vim.
You do realize there are huge mechanical hammers that do require training to use, right?
I wouldn't put it that blunt but I do agree. The problem are these nerds with seemingly infinite memory. It is almost impossible for them to make a UI for the rest of us.
I tried editing a txt document in vim one time. After gazing at the UI for much to long I had to ask for help because it wouldn't let me edit the txt.
I'm sure your average vim wizard can see no wrong in forcing new users to learn how to engage edit mode by pressing 12 keys simultaneously.
They simply dont get that our brains are like bookshelves that take only n books. If you push more than that onto the shelve other books are falling off on the other side.
I could certainly learn some of vim's functionality but there would be very little disk space left to write the software. I'm seriously more productive using MS notepad or nano. I can totally see myself forget how to engage edit mode in a week or 2. I'm having visuals of picard ordering enterprise to engage
All i need is a shuttle!
The edit mode feels like a child safety feature where I'm the child.
Human children flying Vulkan space ships, think about it.
If non of this makes sense, that is the whole point.
I tried editing a txt document in vim one time. After gazing at the UI for much to long I had to ask for help because it wouldn't let me edit the txt.
I'm sure your average vim wizard can see no wrong in forcing new users to learn how to engage edit mode by pressing 12 keys simultaneously.
They simply dont get that our brains are like bookshelves that take only n books. If you push more than that onto the shelve other books are falling off on the other side.
I could certainly learn some of vim's functionality but there would be very little disk space left to write the software. I'm seriously more productive using MS notepad or nano. I can totally see myself forget how to engage edit mode in a week or 2. I'm having visuals of picard ordering enterprise to engage
All i need is a shuttle!
The edit mode feels like a child safety feature where I'm the child.
Human children flying Vulkan space ships, think about it.
If non of this makes sense, that is the whole point.
>It is almost impossible for them to make a UI for the rest of us.
Have you considered that their tool is not necessarily made for you? You'd shudder at emacs yet there's still people there that really want it over vim and are more productive with it than most vim and vscode users.
>I'm sure your average vim wizard can see no wrong in forcing new users to learn how to engage edit mode by pressing 12 keys simultaneously.
it's 1 key. It's not intuitive by default tho that's very much true.
>They simply dont get that our brains are like bookshelves that take only n books. If you push more than that onto the shelve other books are falling off on the other side.
If you use a tool every day you're often expected to know a bit about it regardless of which one you use. The previous poster compared it to a hammer and someone else mentioned a nailgun. Similarly a an ax is simple but a chainsaw used more plenty by my father...but he knows how to replace and fix the chain, And even beyond that a nailgun and chainsaw are simple simple machines compared to the tooling you'll find in many workshops. If you processed wood professionally you'd use room filling machinery instead to make boatloads of planks and whatnot in no time.
The thing is. Much of these issues one would encounter with em and things to know them are relatively simple and easy on their own... But seem difficult if you don't know. They're pretty easy to forget if you do it once. But if you've done it dozens of times you just know. Knowing these things doesn't impact the person's ability to learn other related things much. How a new kind of wood to cut behaves or whatever in the same way that remembering that new face and name doesn't obviously directly makes me forget my existing coworkers.
Have you considered that their tool is not necessarily made for you? You'd shudder at emacs yet there's still people there that really want it over vim and are more productive with it than most vim and vscode users.
>I'm sure your average vim wizard can see no wrong in forcing new users to learn how to engage edit mode by pressing 12 keys simultaneously.
it's 1 key. It's not intuitive by default tho that's very much true.
>They simply dont get that our brains are like bookshelves that take only n books. If you push more than that onto the shelve other books are falling off on the other side.
If you use a tool every day you're often expected to know a bit about it regardless of which one you use. The previous poster compared it to a hammer and someone else mentioned a nailgun. Similarly a an ax is simple but a chainsaw used more plenty by my father...but he knows how to replace and fix the chain, And even beyond that a nailgun and chainsaw are simple simple machines compared to the tooling you'll find in many workshops. If you processed wood professionally you'd use room filling machinery instead to make boatloads of planks and whatnot in no time.
The thing is. Much of these issues one would encounter with em and things to know them are relatively simple and easy on their own... But seem difficult if you don't know. They're pretty easy to forget if you do it once. But if you've done it dozens of times you just know. Knowing these things doesn't impact the person's ability to learn other related things much. How a new kind of wood to cut behaves or whatever in the same way that remembering that new face and name doesn't obviously directly makes me forget my existing coworkers.
>Have you considered that their tool is not necessarily made for you?
of course it could always be more conplex but there is no need to expose that in the ui by default
of course it could always be more conplex but there is no need to expose that in the ui by default
The key for learning a profession is to dump as much knowledge as possible into your 'muscle memory'. there are many operations in emacs and vi that i can do when i want to, but i might not be able to pull up the key sequence to tell someone. Like a musical instrument, the key is practise, practise, practise.
I don't feel like i have proficiency in a language until i have forced myself to speed run a few projects in it. The ideas are important, but it is the ingrained habits that keep the code clean and consistent.
I mean if you don't want to spend so much time studying a given profession, of course. But the neural positioning of generating this text, or transform this text' is different than the neural positioning of 'should this call to this new to me gRPC server be blocking? Timeout? Retries?'
The latter takes thorough focus. the former can be done by muscle memory with practise, and the limit is more on how many new things your fingers can learn in a month, the total of learned things can be quite high.
I don't feel like i have proficiency in a language until i have forced myself to speed run a few projects in it. The ideas are important, but it is the ingrained habits that keep the code clean and consistent.
I mean if you don't want to spend so much time studying a given profession, of course. But the neural positioning of generating this text, or transform this text' is different than the neural positioning of 'should this call to this new to me gRPC server be blocking? Timeout? Retries?'
The latter takes thorough focus. the former can be done by muscle memory with practise, and the limit is more on how many new things your fingers can learn in a month, the total of learned things can be quite high.
Reading such posts really makes me wonder how people wrote UNIX (up to V7) with just ed and an ASR33. And productive, they were.
I've seen some old timers on ACME who dislike even the "distraction" of syntax coloring with modern editor such as vim. I wonder how they would fare with something like MS VSCode.
I've seen some old timers on ACME who dislike even the "distraction" of syntax coloring with modern editor such as vim. I wonder how they would fare with something like MS VSCode.
The complexity of any software system built in the 70s and 80s is laughably low compared to the biggest system we build today.
Their constraints were much harsher, but the fact of the matter is the end result was rather simple by today's standards.
I think just the Bluetooth stack in a modern OS contains as much code as an entire Unix kernel from any time up to 1990 or so.
Their constraints were much harsher, but the fact of the matter is the end result was rather simple by today's standards.
I think just the Bluetooth stack in a modern OS contains as much code as an entire Unix kernel from any time up to 1990 or so.
Don't underestimate the complexity of software built in the seventies either for the business, financial or scientific world. We already had virtual machines, HA, realtime and distributed computing back then.
Some code running at CERN or NASA was far more complex than a bluetooth stack, yet was also written with teletypes or ADM-3A style terminals.
Some code running at CERN or NASA was far more complex than a bluetooth stack, yet was also written with teletypes or ADM-3A style terminals.
As someone who has worked on both sides of the coin in the finance world in consumer credit processing, I think the person you are replying to is more right than wrong, but it's also a matter of how you view the idea of complexity.
I've worked on 30+ year old systems where the code base is absolutely immense, but the <complexity density> of this stuff is very, very low on average compared to the magical bullshit that happens on a simple UI render of some template react app in 2022.
Folks had very little in the way of abstractions at their fingertips, and the languages themselves weren't nearly so helpful in helping you manage complexity, so applications were usually long, shallow, and operating under a litany of fixed boundaries that define and drive a significant amount of behavior for you.
The biggest source of complexity was having to manage your own unique `personal operating system` of bespoke resources at any given time, where each developer was carved into an incomplete walking repository of both business processes and software practices with the passing of each year.
I've worked on 30+ year old systems where the code base is absolutely immense, but the <complexity density> of this stuff is very, very low on average compared to the magical bullshit that happens on a simple UI render of some template react app in 2022.
Folks had very little in the way of abstractions at their fingertips, and the languages themselves weren't nearly so helpful in helping you manage complexity, so applications were usually long, shallow, and operating under a litany of fixed boundaries that define and drive a significant amount of behavior for you.
The biggest source of complexity was having to manage your own unique `personal operating system` of bespoke resources at any given time, where each developer was carved into an incomplete walking repository of both business processes and software practices with the passing of each year.
To put it more simply, software can't be more simple in aggregate because we can trivially rely on insanely complex components others have built and made available. Components which were simply not available back then.
Yes, the glue on top might be trivial, but even that frequently isn't.
And if anything breaks down, the humans at the top are normally expected to handle it, no matter where in the stack it is.
Yes, the glue on top might be trivial, but even that frequently isn't.
And if anything breaks down, the humans at the top are normally expected to handle it, no matter where in the stack it is.
I admire what people built with stone tools, but at the end of the day, a modern skyscraper is a marvel of complex engineering with no rival in that world.
I'm not saying that NASA or CERN people were dumb or anything, they were probably smarter than the average dev today. But even a genius can only go so far with limited tools.
An elite slinger from the Roman times will probably lose at least 8/10 against a Russian mobilized soldier with 2 weeks of training, armed with an AK-47.
That's how progress works, we both learn ourselves, and more than that, we make powerful and accessible tools.
I'm not saying that NASA or CERN people were dumb or anything, they were probably smarter than the average dev today. But even a genius can only go so far with limited tools.
An elite slinger from the Roman times will probably lose at least 8/10 against a Russian mobilized soldier with 2 weeks of training, armed with an AK-47.
That's how progress works, we both learn ourselves, and more than that, we make powerful and accessible tools.
Having worked with a handful of terminal CLI purists I'm convinced most of the people who bang the drum hard for vi and emacs aren't nearly as productive as they think they are, and instead evangelize it largely for some mixture of these reasons:
1) They have a strong preference for keyboard only operation
2) It serves as a cultural cachet, or shibboleth, to signal how elite and pure a developer they are
3) they wish to continue working in the same environment they have been for years or decades, and learning new key binds, trying to find equivalent features and testing new features isn't worth some potential benefit
Everything else, like differences in RAM consumed, total install size, etc seem like post-hoc metric seeking for folks who have already decided what they like.
1) They have a strong preference for keyboard only operation
2) It serves as a cultural cachet, or shibboleth, to signal how elite and pure a developer they are
3) they wish to continue working in the same environment they have been for years or decades, and learning new key binds, trying to find equivalent features and testing new features isn't worth some potential benefit
Everything else, like differences in RAM consumed, total install size, etc seem like post-hoc metric seeking for folks who have already decided what they like.
I find that many people "banging the drum hard" for a text editor are falling for the same kind of faulty thinking.
In my experience, the only situations a colleague has been slowed down in a significant way by their choice of editor seem to boil down to two categories: - Haven't put in the time to actually learn the tool (i.e. using vim purely in insert mode, or VSCode as a plain text editor, constantly going back to a file manager to find and open files) and get stuck in a particularly horrible workflow. - Burn hours daily fiddling with their setup, chasing perfection.
Neither of these are typically caused by the tool itself. At the end of the day... I'm confident most devs can be quite effective using just DOS EDIT or Notepad if pressed.
As for me.... unless I'm doing something specialized, I catch myself trying to eke out that last 1% productivity boost from my editor and ask myself... is this really the best thing to be messing with? Usually, it's not. Honestly, writing documentation or doing a quick prototype is much higher return.
In my experience, the only situations a colleague has been slowed down in a significant way by their choice of editor seem to boil down to two categories: - Haven't put in the time to actually learn the tool (i.e. using vim purely in insert mode, or VSCode as a plain text editor, constantly going back to a file manager to find and open files) and get stuck in a particularly horrible workflow. - Burn hours daily fiddling with their setup, chasing perfection.
Neither of these are typically caused by the tool itself. At the end of the day... I'm confident most devs can be quite effective using just DOS EDIT or Notepad if pressed.
As for me.... unless I'm doing something specialized, I catch myself trying to eke out that last 1% productivity boost from my editor and ask myself... is this really the best thing to be messing with? Usually, it's not. Honestly, writing documentation or doing a quick prototype is much higher return.
> 1) They have a strong preference for keyboard only operation
Sounds like having a strong preference for keyboard only to edit text and code is the natural way.
I don't think most vscode user are using mouse a lot either and if they do that, they are doing it the slow and inefficient way as vscode can be entirely piloted with the keyboard as well.
Sounds like having a strong preference for keyboard only to edit text and code is the natural way.
I don't think most vscode user are using mouse a lot either and if they do that, they are doing it the slow and inefficient way as vscode can be entirely piloted with the keyboard as well.
>the "distraction" of syntax coloring
Also known as "spitzensparken blinkenlichten"
Also known as "spitzensparken blinkenlichten"
Liebe!
That is kind of a bad example, because installing extensions is something you do rarely. Making that easy is nice, but not a huge productivity win.
I think Emacs also has a lot of stuff for extensions and such built-in, but I'm not too familiar with Emacs. With Vim it's a bit more manual, but really not all that much work. Basically search "Vim $my_language", usually click the first link, "git clone" in your ~/.vim/pack, and you're ready to do for most plugins, which will work out of the box. That you need to spend "hours" on this is just nonsense.
And the last time I tried VSCode with Go I had to spend some time fiddling around with things to make it work too.
What it comes down to is personal preference. Some people prefer A, others B. I strongly dislike VSCode's default settings and need to spend quite a bit of time fiddling with that too. But ... I don't pawn off my preferred way of doing things as somehow objectively superior to anyone else's. There's just one person why needs to use your editor: you. So ... whatever works for you, ya know. I can't believe it's 2022 and we're still doing this "editor war" bullshit.
I think Emacs also has a lot of stuff for extensions and such built-in, but I'm not too familiar with Emacs. With Vim it's a bit more manual, but really not all that much work. Basically search "Vim $my_language", usually click the first link, "git clone" in your ~/.vim/pack, and you're ready to do for most plugins, which will work out of the box. That you need to spend "hours" on this is just nonsense.
And the last time I tried VSCode with Go I had to spend some time fiddling around with things to make it work too.
What it comes down to is personal preference. Some people prefer A, others B. I strongly dislike VSCode's default settings and need to spend quite a bit of time fiddling with that too. But ... I don't pawn off my preferred way of doing things as somehow objectively superior to anyone else's. There's just one person why needs to use your editor: you. So ... whatever works for you, ya know. I can't believe it's 2022 and we're still doing this "editor war" bullshit.
>With VSCode, you type the name of any programming language in the extension search, click "Install", and you have a world-class development environment for that language ready to go.
Same with Emacs. `M-x package-install`, type, RET.
Same with Emacs. `M-x package-install`, type, RET.
I think there's a difference in the approaches. Emacs (and vim though I use the former) is like an old multi tool that has been with you on every programming or technical journey you've ever made. Scars, patches, customizations and everything else. It fits like an old glove and in most (though not all) cases, this comfort and the resulting productivity is far greater than a new editor that does "everything right" out of the box.
> Vim and Emacs cannot compare to VSCode when it comes to productivity.
That is true but not in the way you think ;)
That is true but not in the way you think ;)
But I don't want to click (or not even click) and install random stuff from the internet. It's a security, performance and stability risk. My editor should do what I tell it to, not go solo. While I understand your viewpoints, my priorities are just not aligned.
A whole bunch of people still prefer not to have an Appstores in their apps. It's not like this things are god given improvements. Time safer maybe.
People handle their Emacs config files like little shareable babies. That is not even on the same level as 'click and ready' fully unpersonalized environments.
I am a lazy atom, soon sublime user tho.
People handle their Emacs config files like little shareable babies. That is not even on the same level as 'click and ready' fully unpersonalized environments.
I am a lazy atom, soon sublime user tho.
emacs packages is basically the same UX, tho perhaps there are more packages a given person might want for a language. really most packages don't need much config for base functionality.
Vim and Emacs cannot compare to VSCode when it comes to productivity. With VSCode, you type the name of any programming language in the extension search, click "Install", and you have a huge security breach.
(corrected for you)
(corrected for you)
You can run vim and emacs in a gui app. I run neovim in neovide which imo is the best experience for vim these days. Vim's builtin terminal is good enough now that you can ditch running it inside tmux/terminal.
Vim and emacs do not adhere to platform conventions anywhere, unless your platform happens to be "emacs".
There was a running joke about this on the Emacs irc channels.
"I use Linux. One of the libraries that Emacs can use to communicate with the hardware."
"I use Linux. One of the libraries that Emacs can use to communicate with the hardware."
Anything running on electron, such as vscode, do not adhere to platform conventions either.
Do you know any platforms that adhere to vim/emacs conventions?
Because that sounds way better than any of the options I'm aware of.
Because that sounds way better than any of the options I'm aware of.
Nor does VS Code, thanks to being a web page inside a native frame.
They're all terminal apps so I'm not sure why platform conventions would matter. Sure some people use GUI wrappers but most people primarily use them in terminals which have the same conventions everywhere, generally speaking.
Emacs isn't really a terminal app, though. CLI is just one of several frontends.
And there are good reasons to prefer the gui version: https://irreal.org/blog/?p=5835
And there are good reasons to prefer the gui version: https://irreal.org/blog/?p=5835
Platform conventions matter because uniformity matters. It's a mystery to me why people just accept that in their (terminal) text editor, copying text uses a different shortcut than it does in their web browser. That is terrible usability, consumes brain cycles for no good reason, and is above all else completely unnecessary because modern alternatives exist that actually blend in with the system they're a part of.
> Platform conventions matter because uniformity matters.
There are tradeoffs to using software that has different shortcuts for similar things you might do in other software. Uniformity is nice, but I don't find it to be so essential that there is no room for any different ways of working.
> It's a mystery to me why people just accept that in their (terminal) text editor, copying text uses a different shortcut than it does in their web browser.
I don't think they "just accept" it. In the case of emacs (and I believe vim also), you can enable a CUA mode if you wish, and have keybindings that are more like the system. However, in my experience, users of both of those text editors (and indeed, I use both) often choose to use the normal keybindings of those editors intentionally. In my opinion, it doesn't "consume brain cycles for no good reason". There are two very different approaches between those two editors, both are perfectly reasonable and valid. The fact that "modern alternatives exist..." is not necessarily relevant. People have been using both of those editors for years, and they are well versed in how they work and can be very efficient using them. Suggesting that they should just switch to a modern alternative makes some broad assumptions. 1) That they would be happier using some "modern alternative". 2) That whatever value they get from using those editors with different keybindings pales in comparison to what they would gain from switching to an editor with bindings more consistent with the system.
I don't believe you can assume either of those things for most of the people who choose to continue to use either of those editors after working in them for a significant amount of time.
Don't get me wrong, I understand your viewpoint. It's just that not everyone finds that uniformity to be as important as you do.
I also think it is important to point out that both vim and emacs are in active development, so it is not as if either of them has been "mothballed". So while their user interface conventions are very different from much "modern" software, it is not as if they are abandoned -- both are still being developed. They obviously both have significant value to a lot of people.
There are tradeoffs to using software that has different shortcuts for similar things you might do in other software. Uniformity is nice, but I don't find it to be so essential that there is no room for any different ways of working.
> It's a mystery to me why people just accept that in their (terminal) text editor, copying text uses a different shortcut than it does in their web browser.
I don't think they "just accept" it. In the case of emacs (and I believe vim also), you can enable a CUA mode if you wish, and have keybindings that are more like the system. However, in my experience, users of both of those text editors (and indeed, I use both) often choose to use the normal keybindings of those editors intentionally. In my opinion, it doesn't "consume brain cycles for no good reason". There are two very different approaches between those two editors, both are perfectly reasonable and valid. The fact that "modern alternatives exist..." is not necessarily relevant. People have been using both of those editors for years, and they are well versed in how they work and can be very efficient using them. Suggesting that they should just switch to a modern alternative makes some broad assumptions. 1) That they would be happier using some "modern alternative". 2) That whatever value they get from using those editors with different keybindings pales in comparison to what they would gain from switching to an editor with bindings more consistent with the system.
I don't believe you can assume either of those things for most of the people who choose to continue to use either of those editors after working in them for a significant amount of time.
Don't get me wrong, I understand your viewpoint. It's just that not everyone finds that uniformity to be as important as you do.
I also think it is important to point out that both vim and emacs are in active development, so it is not as if either of them has been "mothballed". So while their user interface conventions are very different from much "modern" software, it is not as if they are abandoned -- both are still being developed. They obviously both have significant value to a lot of people.
This isn't even true on virtually any macOS terminal, which use Command-C (just like a web browser). The problem isn't the terminal, it is the operating system.
> Platform conventions matter because uniformity matters
Except just as you noted the conventions change across platforms, contexts and over time, so they aren't really uniform at all.
If you're moving between Windows, macOS, and Linux, or between GUI, command line and remote shell (either within or across any of these) you're already context switching on a regular basis. And if you stick around long enough an OS upgrade will come along that moves the window controls and menu buttons around so you need to retrain your muscle memory (and update your end-user documentation).
If anything some of the long-established, old-school conventions are probably _more_ uniform and consistent. E.g. in vi/vim `:w` will save and `:n` will jump to line n - always and everywhere. In a terminal `find . -name foo` will search the filesystem - (almost) always and everywhere.
That sort of thing isn't comprehensive (i.e. it doesn't cover action you'll need to take) but it's kinda nice when it's available. Maybe we'd be better off if select-then-middle-click worked for copy/paste everywhere.
Except just as you noted the conventions change across platforms, contexts and over time, so they aren't really uniform at all.
If you're moving between Windows, macOS, and Linux, or between GUI, command line and remote shell (either within or across any of these) you're already context switching on a regular basis. And if you stick around long enough an OS upgrade will come along that moves the window controls and menu buttons around so you need to retrain your muscle memory (and update your end-user documentation).
If anything some of the long-established, old-school conventions are probably _more_ uniform and consistent. E.g. in vi/vim `:w` will save and `:n` will jump to line n - always and everywhere. In a terminal `find . -name foo` will search the filesystem - (almost) always and everywhere.
That sort of thing isn't comprehensive (i.e. it doesn't cover action you'll need to take) but it's kinda nice when it's available. Maybe we'd be better off if select-then-middle-click worked for copy/paste everywhere.
You mean like yy versus ctrl+c? You can definitely use a Vim browser/OS extension but Vim does it that way because the creator, I suppose, perceived that his user interface is better than what's already there. And I tend to agree. I don't need uniformity if it'll be inefficient.
vi and emacs don’t follow desktop conventions because they predate desktop conventions (and vim of course follows vi)
[deleted]
I have C-f mapped to Find and C-v mapped to Paste on vim. It’s trivial to do (one line per mapping) but yes I would be considered an heretic by some vim purists. They tend to go the other way around, using plugins to make their browser behave like Vim. Which makes more sense than it might seem; if you spend a lot of time on the command line vim bindings are better supported than ctrl c ctrlv
I never really see the need to do that remapping. By default in a Linux terminal Ctrl-Shift-v is paste and Ctrl-Shift-c is copy.
On macOS there's an extra set of keys so Cmd-v is paste and Cmd-c is copy.
I think I committed that to muscle memory so long ago that I never really think about it unless someone asks.
Not sure about Windows as I haven't used it professionally since 2006 but I'd guess it's the same as Linux.
On macOS there's an extra set of keys so Cmd-v is paste and Cmd-c is copy.
I think I committed that to muscle memory so long ago that I never really think about it unless someone asks.
Not sure about Windows as I haven't used it professionally since 2006 but I'd guess it's the same as Linux.
> It's a mystery to me why people just accept that in their (terminal) text editor, copying text uses a different shortcut than it does in their web browser.
M-x cua-mode resolves this in Emacs. I don't use it, because I've been using Emacs for slightly longer than the CUA has existed.
M-x cua-mode resolves this in Emacs. I don't use it, because I've been using Emacs for slightly longer than the CUA has existed.
Exactly. But I'm sure there are extensions to fix the web browser.
I appreciate you saying Emacs, and vi, but I don't think we even have to reach out of the Microsoft ecosystem to find an even great achievement of engineering for a productivity app; namely Excel.
vi and emacs have certainly had more impact to date, but at the current moment VSCode far outcompetes it on every front. That doesn't mean that there aren't people who still prefer vi or emacs, the same way that some people still ride horses despite the fact that cars exist.
You seem to be implying that VSCode is "better" than Emacs or Vim, as cars are better than horses, but other than having wider adoption atm, I'm not sure it's "better" in any meaningful way.
I think it’s more like how some people still wear wool and linen despite the fact that polyester and rayon exist. Popularity does not equal quality.
How many daily users do vim and emacs have? How many daily users does VSCode have?
Thankfully neither emacs nor vim have built-in tracking, so we may never know.
The closest thing I know to an actual source for this is the StackOverflow developer survey.
2022 edition says 74% of respondents use VSCode regularly, 23% use Vim regularly, and 4% use Emacs regularly.
https://survey.stackoverflow.co/2022/#section-most-popular-t...
2022 edition says 74% of respondents use VSCode regularly, 23% use Vim regularly, and 4% use Emacs regularly.
https://survey.stackoverflow.co/2022/#section-most-popular-t...
How many people believed the earth was flat at one point?
To be clear, I don’t care either way about vim or vscode. I use vim mode in vscode right now, but I might use something else later. All I care about is being able to work pleasantly.
What I meant is that numbers of people doing something is not proof for something being better.
For instance: How many people listen to Justin Bieber and how many listen to The Doors?
To be clear, I don’t care either way about vim or vscode. I use vim mode in vscode right now, but I might use something else later. All I care about is being able to work pleasantly.
What I meant is that numbers of people doing something is not proof for something being better.
For instance: How many people listen to Justin Bieber and how many listen to The Doors?
The claim was not that VSCode is a better editor than vim or emacs, but rather that "VSCode is the greatest productivity tool in the history of software engineering". To me, the tool that matches that description is the one which most increases the productivity level for the most people. Emacs or Vim might be better at increasing the productivity of a single individual (super huge might here – I personally found VSCode improved my productivity much more than vim ever did), but once you multiply that out by the number of people impacted, I doubt there is much contest.
> VSCode is one of the greatest pieces of engineering of our time.
It's not. It's not even the greatest piece of engineering to come out of Microsoft - that's probably Windows NT. But here are just a few examples of things I think are better:
* Millau Viaduct
* The Linux Kernel
* The Bugatti Veyron
* Pretty much any NASA Mars mission
That's not to say VSCode is a bad editior, it certainly isn't. But lets have some perspective.
It's not. It's not even the greatest piece of engineering to come out of Microsoft - that's probably Windows NT. But here are just a few examples of things I think are better:
* Millau Viaduct
* The Linux Kernel
* The Bugatti Veyron
* Pretty much any NASA Mars mission
That's not to say VSCode is a bad editior, it certainly isn't. But lets have some perspective.
I'd say compilers are the greatest productivity tool. Have you tried to program in assembly? it's doable, but there's a reason we work in higher languages most of the time.
>VSCode is one of the greatest pieces of engineering of our time. It's really only when you compare it with Atom that you realize how great it is. Atom was built by incredibly smart people, who had full control over the platform and several years of head start, and they were still out-engineered by the VSCode team at every turn.
Its good, but not that good. There are still some pretty basic features that full fledged IDEs have - like multi window/display setup. And before someone suggests opening another instance - no, that is not enough and creates some synchronization issues that are no-go.
It also handles huge files very badly - try opening up 1-2gb XML files. It will either ask for more RAM, and crash. Or open it and disable all formatting options. Mind you that other editors can handle such files.
Or try to do a complex multiline regex find and replace - it will just sometimes crash outright on bigger files.
Its good, but not that good. There are still some pretty basic features that full fledged IDEs have - like multi window/display setup. And before someone suggests opening another instance - no, that is not enough and creates some synchronization issues that are no-go.
It also handles huge files very badly - try opening up 1-2gb XML files. It will either ask for more RAM, and crash. Or open it and disable all formatting options. Mind you that other editors can handle such files.
Or try to do a complex multiline regex find and replace - it will just sometimes crash outright on bigger files.
VSCode is built by one of Visual Age and Eclipse architects, so they have some experience in IDEs.
I disagree, even I use it myself, for those reasons:
- plugins are a mess - when working with tech x how do I know from that huge list which plugins to use
- keyboard shortcuts don`t work out of the box in my Ubuntu system
- The ui feels non intuitive and overbloated to me - even IntelliJ Idea feels more clean and easy to use
- I would love if VSCode could detect the technologies my project uses and just install/use the proper plugins for me. And maybe even without asking me so I could be happily writing code, building, running tests and doing debugging right from the start wether it`s Rust, Kotlin + Spring Boot, Node + Typescipt whatever... sadly its not working like this...
> - I would love if VSCode could detect the technologies my project uses and just install/use the proper plugins for me
VSCode does this already, if it detects a new language it suggests installing a new plugin. I don't know the criteria it follows to recommend a plugin, perhaps it only does it with some official plugins, but it has showed me this a few times.
VSCode does this already, if it detects a new language it suggests installing a new plugin. I don't know the criteria it follows to recommend a plugin, perhaps it only does it with some official plugins, but it has showed me this a few times.
You are definitely over-hyping VS Code, but it definitely has a killer feature: being the only modern IDE (Sublime Text aside) that doesn't slow to a crawl when opening any file larger than a few hundred lines of code.
Qt Creator has been just fine for me. Granted, it may take a few seconds to generate syntax highlighting, but it seems very usable to me.
Qt Creator is what advise to newcomers who aren't yet familiar with the terminal.
Unlike VSCode, its C/C++ debugger is first class, and it's a native binary developed in a high efficiency language.
I've mostly switched over to VS Code from both vim and BBEdit, although I still use both somewhat regularly. It seems to me that VS Code is the 21st-century equivalent of Eight Megabytes And Constantly Swapping — that is, an editor that does a lot at the cost of quite a few CPU cycles and more than a bit of RAM.
While Emacs isn't quite as heavyweight as it was 25 years ago (hooray for Moore's Law), it still makes me grin to see Emacs fans sneer at the resource usage of a modern Electron-based editor.
While Emacs isn't quite as heavyweight as it was 25 years ago (hooray for Moore's Law), it still makes me grin to see Emacs fans sneer at the resource usage of a modern Electron-based editor.
VS Code built on top of Atom’s team great work, which was open source (something that Microsoft was still grasping at the time). Not saying VS Code isn’t great, but they definitely learned from past projects mistakes and wins. Atom was one of the pioneers.
I feel like VS Code was a "learn from the mistakes of Atom" project in very much the same way C# was a "learn from the mistakes of Java" project.
I remember when I couldn't fly across the country without running out of power due the terrible power usage of VSCode.
One such example was the cursor blinking causing hight cpu usage - https://github.com/Microsoft/vscode/issues/22900 I'm assuming they've fixed it?
Electron in general continues to be a bloated memory hog and inefficient. I think the real interesting thing is how good it is despite the runtimes/frameworks they are using, not because of them. It's more an example of there's no such thing as the "right tool".
One such example was the cursor blinking causing hight cpu usage - https://github.com/Microsoft/vscode/issues/22900 I'm assuming they've fixed it?
Electron in general continues to be a bloated memory hog and inefficient. I think the real interesting thing is how good it is despite the runtimes/frameworks they are using, not because of them. It's more an example of there's no such thing as the "right tool".
> VSCode is one of the greatest pieces of engineering of our time.
I don’t know… things like vertically landing rockets, the Large Hadron Collider, inflating space stations, CRISPR, mRNA vaccines come to mind among many other things that surely surpass VS Code when it comes to engineering marvels.
I don’t know… things like vertically landing rockets, the Large Hadron Collider, inflating space stations, CRISPR, mRNA vaccines come to mind among many other things that surely surpass VS Code when it comes to engineering marvels.
Based on last sentence, software engineering is probably implied.
edit: Seems it was not.
edit: Seems it was not.
I hold VSCode to be at least equal to those achievements. Having used dozens of text editors and IDEs in the course of my programming career, I can appreciate how non-obvious it is for a piece of software this complex to work so fucking well all the time.
And considering how many people are empowered by the productivity gains VSCode brings, I'd say that the real-world impact of VSCode is also much greater than that of most of the projects you listed. VSCode has probably saved hundreds of millions of hours for programmers over the past few years. It's almost impossible to come up with an appropriate comparison for how important it is.
And considering how many people are empowered by the productivity gains VSCode brings, I'd say that the real-world impact of VSCode is also much greater than that of most of the projects you listed. VSCode has probably saved hundreds of millions of hours for programmers over the past few years. It's almost impossible to come up with an appropriate comparison for how important it is.
You are saying an IDE (of which there are many wayyy better) is as equally important as a technology which helped save thousands of lives? Do you really think VSCode is an equally big achievement as building space stations?
peoples lives are more important than a few hours of a programmers life getting used to vim (or any other non VSCode editor)
EDIT: Even millions, and thats only one of thousand technologies that improve our life (expectancy)
peoples lives are more important than a few hours of a programmers life getting used to vim (or any other non VSCode editor)
EDIT: Even millions, and thats only one of thousand technologies that improve our life (expectancy)
It baffles me how many people seem to have no idea how important software is.
Software runs the world. It runs your healthcare. It runs medical research. It runs space exploration. It runs every science megaproject. None of the engineering feats mentioned above would have been remotely possible without modern software.
And modern software is built with tools like VSCode. In fact, I can pretty much guarantee that VSCode was and is involved in the development and maintenance of every single project listed above.
Software controls lives. Software saves lives. Software is every single bit as important as medicine. If all software suddenly stopped working, civilization would collapse and hundreds of millions, if not billions, of people would die.
It wasn't always so. But it certainly is today.
Software runs the world. It runs your healthcare. It runs medical research. It runs space exploration. It runs every science megaproject. None of the engineering feats mentioned above would have been remotely possible without modern software.
And modern software is built with tools like VSCode. In fact, I can pretty much guarantee that VSCode was and is involved in the development and maintenance of every single project listed above.
Software controls lives. Software saves lives. Software is every single bit as important as medicine. If all software suddenly stopped working, civilization would collapse and hundreds of millions, if not billions, of people would die.
It wasn't always so. But it certainly is today.
The consensus is that it’s millions of lives, not merely thousands.
https://www.cidrap.umn.edu/covid-19-vaccines-saved-estimated...
https://www.cidrap.umn.edu/covid-19-vaccines-saved-estimated...
VSCode over mRNA vaccines?
That's too obvious of a troll, please, stop here for a second, take a deep breath and reconsider. It's okay, you can let go of your past mistake, nobody will blame you.
That's too obvious of a troll, please, stop here for a second, take a deep breath and reconsider. It's okay, you can let go of your past mistake, nobody will blame you.
Yesterday p-e-w was arguing all programming should be done in English and IDNs never used, today that VSCode is the greatest engineering achievement.
https://news.ycombinator.com/item?id=33995265
https://news.ycombinator.com/item?id=33995265
Yeah, they've been successful in their trolling in this thread, but they're still just a troll.
See my reply on the sibling comment.
To summarize, you have no idea how important software is.
To summarize, you have no idea how important software is.
How complex is VSCode anyway compared to the older days of Eclipse IDE compiling and building apps for Blackberry and Android. If VSCode was released circa 2010 it can't even compile a small J2ME application.
> VSCode is the greatest productivity tool in the history of software engineering,
Emacs would like a word with you.
Emacs would like a word with you.
VSCode is impressive, but to keep it in perspective, consider that an editor with a bug might corrupt a file, an OS with a bug might corrupt an entire file system and at worst a bad OS could actually damage hardware. Windows, MacOS, and Linux or BSDs are incredibly impressive software.
Emacs has around 6000 packages available from the most common repositories. Nine years ago Emacs had over 1.6 Million lines of code. It would be much larger now. How many lines of code in VSCode? I don't know.
However, consider really large projects in lines of code (see [1]):
[1] https://thenextweb.com/news/google-requires-5000-times-code-...
Emacs has around 6000 packages available from the most common repositories. Nine years ago Emacs had over 1.6 Million lines of code. It would be much larger now. How many lines of code in VSCode? I don't know.
However, consider really large projects in lines of code (see [1]):
Average iPhone app: .... 40,000
Space Shuttle: ........ 400,000
Windows 3.1: ........ 2,300,000
World of Warcraft: .. 5,250,000
Android OS: ........ 11,800,000
F35: ............... 24,700,000
Windows 7: ......... 39,300,000
Facebook: .......... 61,000,000
Google: ......... 2,000,000,000
[1] https://thenextweb.com/news/google-requires-5000-times-code-...
May be true but I feel joy when using atom and annoyance when using vscode. There is a subtle aesthetic to atom that feels so much better. I also feel a perceptible lag with vscode at times. If it is better engineered it sometimes seems noticeably less performant.
That's an overstatement of the century.
Even if it would be running natively, the statement'd be still highly debatable.
But it's Electron based and using TypeScript, which means it uses a lot more electricity than a native solution would (about 20 times [1]), wasting precious resources. Now consider the fact that this is a product of a company that states "to ensure that technology is inclusive, trusted, and increases sustainability."
The only amazing thing here is the level of hypocrisy, IMHO.
[1] https://thenewstack.io/which-programming-languages-use-the-l...
Even if it would be running natively, the statement'd be still highly debatable.
But it's Electron based and using TypeScript, which means it uses a lot more electricity than a native solution would (about 20 times [1]), wasting precious resources. Now consider the fact that this is a product of a company that states "to ensure that technology is inclusive, trusted, and increases sustainability."
The only amazing thing here is the level of hypocrisy, IMHO.
[1] https://thenewstack.io/which-programming-languages-use-the-l...
> VSCode is one of the greatest pieces of engineering of our time.
> VSCode is the greatest productivity tool in the history of software engineering
VSCode just seems like an IDE to me. Here's some things that are either better feats of engineering or better for software productivity:
- moving from line-based editing to screen-based editing
- any mainstream database
- any mainstream browser
- compilers
- linters
- any mainstream OS
- continuous integration
- headphones
- big monitors
- stack overflow
- any graphics driver
- any mainstream 3D platform (Unity, Unreal)
- version control (edit: added, how could I have left it out??)
I'm team Vim so I'm obviously salty, but even so I think you're going a little overboard here haha. I don't even think this about Vim!
> VSCode is the greatest productivity tool in the history of software engineering
VSCode just seems like an IDE to me. Here's some things that are either better feats of engineering or better for software productivity:
- moving from line-based editing to screen-based editing
- any mainstream database
- any mainstream browser
- compilers
- linters
- any mainstream OS
- continuous integration
- headphones
- big monitors
- stack overflow
- any graphics driver
- any mainstream 3D platform (Unity, Unreal)
- version control (edit: added, how could I have left it out??)
I'm team Vim so I'm obviously salty, but even so I think you're going a little overboard here haha. I don't even think this about Vim!
From a company which hindered web development efforts and made devs life misearable with IE because why not. If you are doing web development with VSCode then congratulations, why not spit yourself in the face?
Plus it's freeeee... because as a software behemoth with 1 trill marketcap you have to ruin smaller companies, because why not.
Plus it's freeeee... because as a software behemoth with 1 trill marketcap you have to ruin smaller companies, because why not.
> VSCode is the greatest productivity tool in the history of software engineering
Surely that honor goes to compilers, right (take your pick which one is the greatest)?
Sure, VSCode starts faster than Visual Studio, and has better IDE features than (pre-lsp) Emacs, but all of that dwarfs compared to the productivity increase of not writing assembly.
Surely that honor goes to compilers, right (take your pick which one is the greatest)?
Sure, VSCode starts faster than Visual Studio, and has better IDE features than (pre-lsp) Emacs, but all of that dwarfs compared to the productivity increase of not writing assembly.
There is one thing that I will always remember ATOM for, and I don't mean this as a joke, it _really_ was awesome: The ATOM 1.0 Launch video (https://youtu.be/Y7aEiVwBAdk)
> VSCode is the greatest productivity tool in the history of software engineering
LOL. Do you work for MS? This is a bit thick, even for hyperbole. Personally I find IntelliJ to be superior to VS Code.
LOL. Do you work for MS? This is a bit thick, even for hyperbole. Personally I find IntelliJ to be superior to VS Code.
Is TypeScript responsible for how performant VSCode is relative to other Electron apps? I always wondered how they figured it out and all other Electron apps struggle.
Poe's Law in action.
I can imagine this being a reality for any developer that doesn't need to spend a majority of time in the terminal, or is more comfortable using a mouse than a keyboard (which _is_ a productivity drawback).
What are you typically developing? How often do you spend in the terminal? Are you at all familiar with modal editing? Have you tried alternative editors, like Neovim, Emacs, or any of their related distributions?
I went the trajectory from Goland -> VSCode -> Neovim. Goland -> VSCode, was a downgrade, personally. Goland/VSCode -> Neovim was surprisingly drastic upgrade.
I can imagine this being a reality for any developer that doesn't need to spend a majority of time in the terminal, or is more comfortable using a mouse than a keyboard (which _is_ a productivity drawback).
What are you typically developing? How often do you spend in the terminal? Are you at all familiar with modal editing? Have you tried alternative editors, like Neovim, Emacs, or any of their related distributions?
I went the trajectory from Goland -> VSCode -> Neovim. Goland -> VSCode, was a downgrade, personally. Goland/VSCode -> Neovim was surprisingly drastic upgrade.
> VSCode is the greatest productivity tool in the history of software engineering
According to whom? Personally, I find Jetbrains products a far superior experience.
According to whom? Personally, I find Jetbrains products a far superior experience.
> VSCode is one of the greatest pieces of engineering of our time
I feel this is a slight overestimation of VSCode’s design.
I feel this is a slight overestimation of VSCode’s design.
I seriously don't understand the hype around VS Code. I find it atrocious. The UI is complete trash.
It's great software but really far from being the greatest of all time.
> VSCode is the greatest productivity tool in the history of software engineering
Really?
Really?
[deleted]
Where's the love for Borland Turbo Pascal DOS?
VS Code is massively inferior to Visual Studio. It’s a gloried text editor. Nobody writes large software projects on VSCode
I'm not a big fan of VSCode, but this is objectively untrue.
No it’s not. Visual Studio is a proper IDE. VSCode is not. VSCode has a very small subset of the features Visual Studio has
> Nobody writes large software projects on VSCode
Sorry, this was the bit I was responding to. I should have quoted it in the original.
This statement is false.
Sorry, this was the bit I was responding to. I should have quoted it in the original.
This statement is false.
lol
lmao
lmao
Meh it's a second rate copycat in a shifty runtime.
There is nothing they've done with it that is notable or new, typical micro$oft nonsense.
There is nothing they've done with it that is notable or new, typical micro$oft nonsense.
> The interesting thing has always been that both were built on Electron.
Atom wasn't just "built on" Electron, they made Electron.
Electron was made from Atom, literally. Electron was originally called Atom Shell https://www.electronjs.org/blog/electron
Atom wasn't just "built on" Electron, they made Electron.
Electron was made from Atom, literally. Electron was originally called Atom Shell https://www.electronjs.org/blog/electron
LSP was a HUGE step forward, all editors benefit from it nowadays. Having multiple communities contributing back to the same language server makes maintaining those plugins a lot more comfortable.
I still fail to understand the importance of a language server.
One could have created a library which conformed to some specification, written the library a single time, then compiled it for different platforms. Editors could then have loaded that shared library and used it just as they wrote in support for a language server. There's no need to get a network server involved.
You still have the majority of development effort in the library, instead of individual text editors. You still have the joy of a nearly pure piece of code, without OS-specific paradigms like networking which impede progress. You still have a simple interface with the editor.
I see exactly zero benefits of having a language server over a traditional shared library, except with a network server you make a trade off where you gain latency and other networking problems, and you gain absolutely nothing.
I don't even know of any central language servers, which were one of the core benefits of the LSP design. "ooh we can all share a language server which is kept up to date independently of our editors! squeeee!" Where's that? Why is that a benefit at all? Presumably you'd still need to shut it down to update it, and someone has to manage it.
The experience that people using editors got when aeditor developers started thinking about how to do something better is what the users love, not the LSP itself. LSP triggered this change in thinking, but anything could have, and I'm honestly surprised that nothing else did prior to LSP.
One could have created a library which conformed to some specification, written the library a single time, then compiled it for different platforms. Editors could then have loaded that shared library and used it just as they wrote in support for a language server. There's no need to get a network server involved.
You still have the majority of development effort in the library, instead of individual text editors. You still have the joy of a nearly pure piece of code, without OS-specific paradigms like networking which impede progress. You still have a simple interface with the editor.
I see exactly zero benefits of having a language server over a traditional shared library, except with a network server you make a trade off where you gain latency and other networking problems, and you gain absolutely nothing.
I don't even know of any central language servers, which were one of the core benefits of the LSP design. "ooh we can all share a language server which is kept up to date independently of our editors! squeeee!" Where's that? Why is that a benefit at all? Presumably you'd still need to shut it down to update it, and someone has to manage it.
The experience that people using editors got when aeditor developers started thinking about how to do something better is what the users love, not the LSP itself. LSP triggered this change in thinking, but anything could have, and I'm honestly surprised that nothing else did prior to LSP.
And VSCode is still pretty customizable/extensible- in most of the ways that people really cared about. It found a really solid balance
Predated VSCode version of LSP, the idea is at least as old as Lucid Emacs.
> A central server uses an Objectstore database to tightly integrate compiler(Lucid C++ Compiler), editor(emacs), debugger(gdb), and browsers
https://www.desy.de/user/projects/C++/products/lucid.html
> A central server uses an Objectstore database to tightly integrate compiler(Lucid C++ Compiler), editor(emacs), debugger(gdb), and browsers
https://www.desy.de/user/projects/C++/products/lucid.html
Which demonstrates once again that doing something right is far more important than doing it first.
That's not always true, sometimes first (and worse) is better. VHS vs Betamax comes to mind.
Except that VHS was released after Betamax, so second & worse video quality won that time.
https://en.m.wikipedia.org/wiki/VHS
https://en.m.wikipedia.org/wiki/Betamax
https://en.m.wikipedia.org/wiki/VHS
https://en.m.wikipedia.org/wiki/Betamax
This IS an urban legend which deserves to die.
VHS wasn't of discernible worse picture quality but provided much better usability at the same time.
VHS wasn't of discernible worse picture quality but provided much better usability at the same time.
VHS was of marginally worse picture quality, but for that small trade-off you got the huge benefit of being able to record a feature-length movie on one tape.
[deleted]
LSP = Language Server Protocol
3p = third-party
3p = third-party
[deleted]
Slow means more than just lack of speed here, for the average folk it means tedious.
[deleted]
People hate on electron, but it's a pretty amazing piece of tech if you ask me. I can turn a browser game into a steam game with basically no effort which is nice because browsers change over time and electron helps you get a working offline snapshot of something you created.
> People hate on electron, but it's a pretty amazing piece of tech if you ask me.
It really does come down to how people build on top of it.
I tried opening a 2gb log file in Atom and it took like 10 minutes before crashing.
VSCode on the other hand, while a bit slow, opened it and I could search quickly and scroll it without any issue at all.
That was what caused me to switch.
It really does come down to how people build on top of it.
I tried opening a 2gb log file in Atom and it took like 10 minutes before crashing.
VSCode on the other hand, while a bit slow, opened it and I could search quickly and scroll it without any issue at all.
That was what caused me to switch.
I used VS Code beta and it was slow… I remember an issue in the beginning where the cursor was refreshing at 60fps, causing huge delays. The software evolved really well over the years.
I didn't try during beta because I was convinced VSCode would never take off. Boy was I wrong :D
Your specific example highlights the performance difference between VS Code and Atom very nicely, and VS Code is an absolute gem of engineering.
But, for large files, I am not sure it has much to do with Electron in this specific case. Notepad is about as native as they come, and famously struggled with large files - anything over a few dozen KB - for a few decades (maybe still today?). Basically, if you're going to do seriously stupid stuff in an app's code, like loading the entire file upfront and applying word-wrapping, it doesn't really matter if you're doing it 2-5x faster, it will still take too long.
But, for large files, I am not sure it has much to do with Electron in this specific case. Notepad is about as native as they come, and famously struggled with large files - anything over a few dozen KB - for a few decades (maybe still today?). Basically, if you're going to do seriously stupid stuff in an app's code, like loading the entire file upfront and applying word-wrapping, it doesn't really matter if you're doing it 2-5x faster, it will still take too long.
Loading large files need not have anything with Electron. The file can live in another child process either fully in memory or swapped to the filesystem. When you scroll you can load the required contents into the view (Electron). For searching you can build index or even perform search on the swap and show results accordingly.. It's complex but can be done with Electron (as proved by VSCode).
Wow man.
Your comment brought me memories. This exactly was what made me switch over too back then.
Pre-VS setup was: Atom for most cases but [large files | quickly edit something] was with Brackets (It was unbelievably swift)
VS Code comes in and says: Don't worry. I got you!
Your comment brought me memories. This exactly was what made me switch over too back then.
Pre-VS setup was: Atom for most cases but [large files | quickly edit something] was with Brackets (It was unbelievably swift)
VS Code comes in and says: Don't worry. I got you!
[deleted]
Opening large files is a pretty niche case anyway. Even CLI tools like less and grep are slow with things like searching muti GB files.
Electron is essentially an operating system that runs on every operating system, so you can target just a single OS and your application works everywhere.
Yes, and that's exactly what people hate about it: every application written in Electron lugs around its own copy of this OS. You can imagine why this might not be a good idea, especially for applications designed to run in the background, like the Slack client. For me, it was a godsend when Slack decided that my Linux version was too old to support and the client stopped working. Then I switched to the in-browser version and never looked back, even after upgrading to a new machine. My laptop's CPU and memory usage are still thanking me...
There are two sides to this.
In the Electron case, it’s wasteful to some degree. Especially if the app is not doing much with files/storage etc. For VSCode it makes sense to not run in the browser but for Slack, not so much.
But generally I feel like there’s too much overlap between OS, browsers, IDEs and language runtimes (JVM, V8/Node etc.). It gets worse if you add containers and VMs.
I wonder how many garbage collectors, file abstractions, JITs, databases, schedulers, GUI engines, indexers and so on are running on my machine. How many flavors and versions of essentially the same libraries are used.
There is no unified vision, of what an OS/runtime/IDE/browser should be. There’s not even a common understanding!
In the Electron case, it’s wasteful to some degree. Especially if the app is not doing much with files/storage etc. For VSCode it makes sense to not run in the browser but for Slack, not so much.
But generally I feel like there’s too much overlap between OS, browsers, IDEs and language runtimes (JVM, V8/Node etc.). It gets worse if you add containers and VMs.
I wonder how many garbage collectors, file abstractions, JITs, databases, schedulers, GUI engines, indexers and so on are running on my machine. How many flavors and versions of essentially the same libraries are used.
There is no unified vision, of what an OS/runtime/IDE/browser should be. There’s not even a common understanding!
> I wonder how many garbage collectors, file abstractions, JITs, databases, schedulers, GUI engines, indexers and so on are running on my machine
I tried to picture clusters of information as they moved through the computer. What did they look like? Ships? Motorcycles? Were the circuits like freeways? I kept dreaming of a world I thought I'd never see. And then one day …
I tried to picture clusters of information as they moved through the computer. What did they look like? Ships? Motorcycles? Were the circuits like freeways? I kept dreaming of a world I thought I'd never see. And then one day …
Teams holds the crown as far as terrible electron apps.
I actually can't run it locally (absurd tech policies), and I am so glad to never run it at all ever. Just easier to load it into an isolated browser tab when I need it, Zoom is so superior it's not even funny...
I actually can't run it locally (absurd tech policies), and I am so glad to never run it at all ever. Just easier to load it into an isolated browser tab when I need it, Zoom is so superior it's not even funny...
With regards to various applications, the question seems it is not if Electron is fit for them, but if they really need to be a "native application". Why does a chat application need to have it's own native package and can't run in a browser tab? With all the recent development on WebRTC and even File System Access API, can't really find a sole reason* (but feel free to point them out) for 99% of Electron applications: seems some kind of developer ego "we are not just a[nother] web app, we are native".
* Looking at an arbitrary article, "Why does Slack desktop app use Electron?" [1], the answer seems mostly aesthetics, "faster performance [citation needed] and the frameless look".
[1] https://brainhub.eu/library/electron-app-examples#:~:text=Wh...
* Looking at an arbitrary article, "Why does Slack desktop app use Electron?" [1], the answer seems mostly aesthetics, "faster performance [citation needed] and the frameless look".
[1] https://brainhub.eu/library/electron-app-examples#:~:text=Wh...
When you start building an app that does anything more than what a typical website does – basic stuff like keeping some persistent files, drag and drop, notifications, minimize to tray, using threads, the html5 apis are widely insufficient, performs poorly or – in the case of webrtc – massively over-complicated). They’re (rightfully) designed for the browser with its ephemeral untrusted model.
It’s a shame, because cross platform app building, distribution and updates is a shitshow, even with electron, putting extra labor on the developers, so neither party is happy.
That said, some apps should really be web apps, but are still bundled as desktop apps purely for the frameless “premium” experience, and I assume to not be lost among 100s of tabs. It would be great if there was better browser support for allowing users to “install” web apps, but right now the support for that is pretty poor in terms of UX.
It’s a shame, because cross platform app building, distribution and updates is a shitshow, even with electron, putting extra labor on the developers, so neither party is happy.
That said, some apps should really be web apps, but are still bundled as desktop apps purely for the frameless “premium” experience, and I assume to not be lost among 100s of tabs. It would be great if there was better browser support for allowing users to “install” web apps, but right now the support for that is pretty poor in terms of UX.
I strictly run Teams, Slack, Discord, and Spotify in pinned browser tabs
Thought the same. So was using teams and slack in the browser. But at least for new m1 Mac, resources for running a tab and a seperate electron app are pretty similar. It's scary how much memory certain latent tabs use, especially with video ads running.
What's the big deal? Surely you have at least 512 GB of RAM, not the typical 1 TB for good measure these days. Modern computers with these bare minimum hardware requirements can handle a few electron apps.
Kind of defeats the point of having separate operating systems. I think the best environment an OS creates where apps are deigned around that OS is the value an OS brings to the table.
The selling point of Electron is that it is cross platform, but that does come at a cost. The cost is essentially running a separate instance of Chrome for every application you run that is built with it. The runtime overhead for that is significant. It is a tradeoff that works for some applications, but there are a huge number of applications for which it makes them resource-sucking pigs that do not provide value significant enough to justify the resources they consume.
The source of most of complaining about Electron and companies/developers choosing to use it is that it's not just an ordinary trade-off. The gains - being cross-platform - accrue mostly to the producer side (cheaper to develop and maintain). The costs - resource use at runtime - happens entirely on the consumer side.
In other words, it's a typical case of costs being externalized, making the supposed trade-off be a "free win" instead. Since software resists commoditization, consumers don't even have a way to pass those costs back onto the vendor (by e.g. leaving for a competitor).
In other words, it's a typical case of costs being externalized, making the supposed trade-off be a "free win" instead. Since software resists commoditization, consumers don't even have a way to pass those costs back onto the vendor (by e.g. leaving for a competitor).
Like a JVM?
But with a crappy language.
again, like the JVM
I am not particularly fond of Java (I know I am not alone :-D).
I am not particularly fond of Java (I know I am not alone :-D).
Java can perform well, and even with all the enterprizey bullshit, it still performs much better than your run of the mill, best practices follower javascript program.
Javascript actually can perform well, not nearly as well as java can, but it doesn't have to be as bad as what you see on most electron applications. But it's not trivial to make it so.
Javascript actually can perform well, not nearly as well as java can, but it doesn't have to be as bad as what you see on most electron applications. But it's not trivial to make it so.
Yeah, I wasn't really thinking of performance. I was thinking of the dislike I have for working with Java. Past experiences with "enterprizey" Java is the worst. AbstractWidgetFactoryBuilderLoaderMaker, etc.
Well, all the discussion about Atom, all around we is about performance. Even when the people in the discussion don't actually notice this.
But I'd put javascript and java on the same cohort when talk about usability (programability?, what name do I use here?). They are not as bad to be dangerous, but neither is any good either. Anyway, the JVM allows some other languages that don't solve all the problems but bring you some expressivity (honestly, I have no idea if this is a positive), while electron can work with typescript (much better than javascript) and can run wasm (what currently implies on rust, what means low expressivity but high confidence on your code).
I'm not ready to declare any winner here.
But I'd put javascript and java on the same cohort when talk about usability (programability?, what name do I use here?). They are not as bad to be dangerous, but neither is any good either. Anyway, the JVM allows some other languages that don't solve all the problems but bring you some expressivity (honestly, I have no idea if this is a positive), while electron can work with typescript (much better than javascript) and can run wasm (what currently implies on rust, what means low expressivity but high confidence on your code).
I'm not ready to declare any winner here.
The third most loved language [1], below Rust and Elixir, uses the JVM: Clojure.
[1]: https://survey.stackoverflow.co/2022/#section-most-loved-dre...
[1]: https://survey.stackoverflow.co/2022/#section-most-loved-dre...
Yeah, I wasn't suggesting the JVM was bad (on the contrary, I think it is quite good). I was just putting Java in the "crappy language" camp.
The best use of Java is implementing Clojure. Of that (Clojure) I am a fan.
The best use of Java is implementing Clojure. Of that (Clojure) I am a fan.
I’d rather write Java than be in parentheses hell any day of the week.
There was a time when I had an equal revulsion toward languages with a Lisp-like syntax. However, dissatisfaction with the limitations of most other programming languages, and the influence of a bunch of very smart and effective developers was enough to convince me to give them another look (and try to be open minded about it).
As countless others have said before me, the parens really do cease to be an issue over time (and not really very long of a time either). The power and flexibility gained by writing code in Lisp/Scheme/Clojure or other Lisp dialects really is worth the effort, in my opinion. I'm not saying there are no bumps in the road - there definitely are. However, I have zero regrets about taking the time to learn those languages. Even if I never write another line of code in any of them again, it will still have been worth the effort.
As countless others have said before me, the parens really do cease to be an issue over time (and not really very long of a time either). The power and flexibility gained by writing code in Lisp/Scheme/Clojure or other Lisp dialects really is worth the effort, in my opinion. I'm not saying there are no bumps in the road - there definitely are. However, I have zero regrets about taking the time to learn those languages. Even if I never write another line of code in any of them again, it will still have been worth the effort.
There are other choices. One of my planned projects over the Christmas break is to use Scala for a personal project.
https://en.wikipedia.org/wiki/List_of_JVM_languages
https://en.wikipedia.org/wiki/List_of_JVM_languages
Always bet on Javascript, isn't that how the saying goes?
> I can turn a browser game into a steam game with basically no effort
There's actually quite a lot of effort required if you want Steam overlay to work and/or not crash with Electron, or to interact with Steamworks APIs.
There's actually quite a lot of effort required if you want Steam overlay to work and/or not crash with Electron, or to interact with Steamworks APIs.
[deleted]
Microsoft and Mozilla did it first, nothing great about Electron, other than shipping Chrome even into more computers.
I believe the Komodo IDE was written on top of xulrunner, which used the internals of Mozilla/Firefox.
There was node-webkit (nowadays called nw.js) that predate electron by quite some times. I remember know about it precisely because I was playing games that was developed with it.
I don't think that people actually hate on electron. It's more that we hate on tiny tools written in electron.
A small usb stick copy tool? here take 300mb and more to get the 1 minute job done. A bash one liner.
A small usb stick copy tool? here take 300mb and more to get the 1 minute job done. A bash one liner.
The people that hate on Electron aren't amused by cute browser tricks.
But what value is that, over the website?
Two big ones I can think of:
1. Have your application look and act like a standalone application rather than a webpage—Chrome tried to support this with application shortcuts (or whatever they were called), but it never worked well enough
2. Give your application access to native APIs and capabilities that you can't get through the browser, like direct filesystem access
1. Have your application look and act like a standalone application rather than a webpage—Chrome tried to support this with application shortcuts (or whatever they were called), but it never worked well enough
2. Give your application access to native APIs and capabilities that you can't get through the browser, like direct filesystem access
But it doesn’t act like an application. Most of the OS right click services, keyboard shortcuts, menu items are all missing. Accessibility tools don’t work.
It doesn't feel like one either. It feels like a shitty web page, and it costs 500$ to run. I can run apps in python and they don't feel the same way, never mind native.
>1. Have your application look and act like a standalone application rather than a webpage
That sounds suspiciously like "properly adheres to the native OS's conventions", the lack of which is the #1 criticism of electron.
That sounds suspiciously like "properly adheres to the native OS's conventions", the lack of which is the #1 criticism of electron.
They are talking in the context of games though, for which there aren’t such strong conventions, besides lives in your applications folder, and runs full screen.
“ because browsers change over time and electron helps you get a working offline snapshot of something you created.”
If the browsers change in a way that makes the website not work, the electron application will still work.
If the browsers change in a way that makes the website not work, the electron application will still work.
This makes sense from the perspective of the individual developer, but it's also a sad reflection of the sorry state of technology that the only way to be sure a website will work in 5 years is by shipping your own copy of the browser.
> which is nice because browsers change over time and electron helps you get a working offline snapshot of something you created.
I started a job in 2018 and someone commented “what are you still on Atom for? Everyone has moved to vs code”. So yeah it’s been kinda dead for a long time now.
I haven't worked for someone in years and that totally passed on me. I've tried code several times because of specific platforms it has plugins for but I never seen it as even comparable, at least not more than sublime.
No idea what problems people had with Atom, but I really hope some fork let it live on.
No idea what problems people had with Atom, but I really hope some fork let it live on.
There's https://github.com/atom-community/atom, hoping that or similar will gain traction
whoa, a whole 4 years ago!! ;-) i want to make a "kids today" joke/comment, but it's more of just the pace of trends/fads not the people per se. you show up at a new job and the people make comments, of course you change. i've never used Atom, so maybe it was a better thing to change, but i've been introduced to some very ingrained workflows that just no longer made sense on so many levels. you can come in guns blazing and try to change everything now, or slowly acclimate to the workflow and then start suggesting changes/updates from inside. if you're hired as a 10x dev, then maybe guns blazing works, but if you're not, i'd suggest the latter.
Oh you’ve been programming only for a few decades?
I want to make a "kids today" joke/comment, but it's more of just the pace of trends/fads not the people per se. I’m actually a cosmic entity that views time as an artificial construct. When you’ve been around for centuries like I have, you’ll understand that trends/fads are mere points in the time space-continuum. Don’t get bent out of shape when you see one.
I want to make a "kids today" joke/comment, but it's more of just the pace of trends/fads not the people per se. I’m actually a cosmic entity that views time as an artificial construct. When you’ve been around for centuries like I have, you’ll understand that trends/fads are mere points in the time space-continuum. Don’t get bent out of shape when you see one.
Somewhat unrelated, but why is it that when someone online writes an emoji with a nose, ie ;) vs ;-), I can immediately tell it's an older person? Was that something that was taught back in the day?
Yes.
(Damn, it's hard to find a "list of emoticons" (or even "usenet faq") from back in the day now. So much more recent stuff clogging the search results.)
Anyway, this list of emoticons from '94 (according to the internet archive) is a pretty good representative of the sort of thing that people passed around then:
https://ia802801.us.archive.org/view_archive.php?archive=/23...
As you can see, most have noses.
Also, RFC-1855 (Netiquette Guidelines) from October '95 has one example of a smiley in §2.1.1: "Use smileys to indicate tone of voice, but use them sparingly. :-) is an example of a smiley (Look sideways)." I suspect that at least one of the bibliographical references provided would have contained a decent list of them at the time, but so many links are dead now. (And even if some of the ftp ones still exist, most browsers have dropped ftp support now, so most people are kinda SOL there anyway.)
http://www.faqs.org/rfcs/rfc1855.html
(Damn, it's hard to find a "list of emoticons" (or even "usenet faq") from back in the day now. So much more recent stuff clogging the search results.)
Anyway, this list of emoticons from '94 (according to the internet archive) is a pretty good representative of the sort of thing that people passed around then:
https://ia802801.us.archive.org/view_archive.php?archive=/23...
As you can see, most have noses.
Also, RFC-1855 (Netiquette Guidelines) from October '95 has one example of a smiley in §2.1.1: "Use smileys to indicate tone of voice, but use them sparingly. :-) is an example of a smiley (Look sideways)." I suspect that at least one of the bibliographical references provided would have contained a decent list of them at the time, but so many links are dead now. (And even if some of the ftp ones still exist, most browsers have dropped ftp support now, so most people are kinda SOL there anyway.)
http://www.faqs.org/rfcs/rfc1855.html
It like when i receive a text when no punctuation, i can tell it is a younger person. anyone using emoticons vs emojis should be the indicator in and of itself regardless if there's a nose or not. how many times did you have to push that number to get to the symbol? "huh?" you ask. shows me your age too.
Hah, bucking the trend there with your lack of capitalization.
that's too many pushes of the same button, so we all learned caps are a waste. also, e e cummings. ;) lol <eyeroll> or is it :eyeroll:
> that's too many pushes of the same button, so we all learned caps are a waste
No we didn't, because on a computer it doesn't require any meaningful extra effort (unless you're a lazy kid -> another age indicator), and pre-smartphones... texting actually used to cost money. You'd probably have a plan of some 1000 free text messages / month, or sth., which isn't that much if you're a teenager, given that a text messages was limited to ~140 characters (yes, that's where Twitter's limit came from - SMS compatibility).
Caps, instead of being waste, let you skip whitespace. Instead of writing "caps are a waste", you'd write "CapsAreAWaste" (and then possibly shorten it to "CapsRAWaste"). We'd cut the message length by some 20-30% this way, which mattered for longer messages - it would turn a 4 SMS long message into a 3 SMS long one. We'd of course optimize harder when we were close to message length boundary.
Being efficient with text messaging was a critical social life skill when I was young.
No we didn't, because on a computer it doesn't require any meaningful extra effort (unless you're a lazy kid -> another age indicator), and pre-smartphones... texting actually used to cost money. You'd probably have a plan of some 1000 free text messages / month, or sth., which isn't that much if you're a teenager, given that a text messages was limited to ~140 characters (yes, that's where Twitter's limit came from - SMS compatibility).
Caps, instead of being waste, let you skip whitespace. Instead of writing "caps are a waste", you'd write "CapsAreAWaste" (and then possibly shorten it to "CapsRAWaste"). We'd cut the message length by some 20-30% this way, which mattered for longer messages - it would turn a 4 SMS long message into a 3 SMS long one. We'd of course optimize harder when we were close to message length boundary.
Being efficient with text messaging was a critical social life skill when I was young.
I tried Atom for a while in Windows, but a file watching bug made it quite inconvenient. Every time I edited and saved a file in another IDE (at the time, I was stuck using it to compile and debug an embedded system), that IDE would rename the original to a temporary file in a temporary directory before writing the new version. Atom would follow the rename rather than re-load the new file at the original path. It would make the open tab useless.
I tried making an issue for it, but someone ranted on about moving files around on a Mac and then closed the issue.
I tried trying to solve the bug myself, but I got about 4 layers deep into callbacks across at least three different repos, and gave up.
I tried making an issue for it, but someone ranted on about moving files around on a Mac and then closed the issue.
I tried trying to solve the bug myself, but I got about 4 layers deep into callbacks across at least three different repos, and gave up.
What editor did you go for after that? I still use Atom (I don’t need an IDE that much)
I've been using vscode lately. It mostly just works without getting in the way. Although if you work with python, one of the extensions seems prone to glitching out and spinning a CPU core. They're at least responsive to issue tickets.
Sublime text seems to be a good paid option.
Sublime text seems to be a good paid option.
I know people shit on VSCode but in my humble opinion, VSCode single handedly destroyed Atom. Far superior tool, 100% free and adoption growth was crazy.
I also was an early tester (not adopter) of Atom and I kinda hated it right from the start, but it's been a while and I could never really put my finger on it. I think it always somehow felt sluggish (I'm talking trying out several builds over several months, not just a one-off). But I've also never warmed up to Sublime (which was fast but also felt off).
Interestingly the moment I tried out VS Code (many years later) I instantly liked it and have been using it sporadically ever since, and as people always liken the two, I am confused to this day why one felt wrong and one felt right.
Interestingly the moment I tried out VS Code (many years later) I instantly liked it and have been using it sporadically ever since, and as people always liken the two, I am confused to this day why one felt wrong and one felt right.
My journey went Sublime > Atom > VSCode.
I started with Sublime in college and then went to Atom when it came out because it was "Free Sublime". Granted I liked it back then but I was still a college student (had I picked it up now I would have different opinions). Almost as quickly VSCode came out and was a "Better Atom" (I thought VSCode was based on Atom for the longest time).
I wonder what will eventually replace VSCode. Lex Friedman said on his podcast that he sees VSCode as a modern Emacs which I think is a good way of thinking about VSCode.
I started with Sublime in college and then went to Atom when it came out because it was "Free Sublime". Granted I liked it back then but I was still a college student (had I picked it up now I would have different opinions). Almost as quickly VSCode came out and was a "Better Atom" (I thought VSCode was based on Atom for the longest time).
I wonder what will eventually replace VSCode. Lex Friedman said on his podcast that he sees VSCode as a modern Emacs which I think is a good way of thinking about VSCode.
Personally, I prefer CoffeeScript. The code gets more concise, it stimulates a coding style that's more objective and less "enterprisy" than TypeScript with all the excessive OO stuff. A simpler and more concise language attracts more contributors overtime.
However, TypeScript has clearly won and static typing can help a lot with autocomplete stuff, so there is no point fighting back.
However, TypeScript has clearly won and static typing can help a lot with autocomplete stuff, so there is no point fighting back.
Yes, the star number of VSCode surpassed Atom in April 2018, 2 months before GitHub was acquired. https://ossinsight.io/analyze/atom/atom?vs=microsoft%2Fvscod...
There is a solid alternative, though. Pulsar. Atom was kind of dead, but it still had a small, dedicated fanbase including myself. Hopefully Pulsar will be able to keep the project alive as long as us Atom fans use it
VSCode is owned by Microsoft, ever since Microsoft bought GitHub in 2018 it was bound to happen. The two text-editors had the same audience therefore Atom was bound to get shut.
I'm not sure it's fair to say it failed. Not everything is forever. It served very important purposes, helped push technology forward and paved the way for editors like VSCode.
I'd call that success.
I'd call that success.
> While the Atom project ultimately failed, it did give us Electron
That’s not the positive thing that you think it is.
That’s not the positive thing that you think it is.
I guess I'm old school, but I'm genuinely surprised by how Microsoft drove such widespread adoption of Visual Studio which, as I remember, was an expensive, basically enterprise-only IDE for very Microsoft-specific proprietary technologies like C# and .NET.
eh? VS Code is unrelated to Visual Studio except by the name.
I really missed all of that. Atom is still the editor installed on all my systems. The one single thing I work with every day since many many years.
Are they killing off Atom because Microsoft bought GitHub and they already have VSCode?
we had the conversation at University back in 2002; it went, "Atom is a dumb name" (for a beta package for editing, building in). What is this, the year of Marvel Comics taking over the Galaxy or something?
Don't be sad it's gone; be glad it happened.
[deleted]
Electron shouldn't exist. It's an insult to the engineering discipline. :barf:
Typescript makes VSCode very slow though. I remember the feeling when switched from Atom to VSCode it's wicked fast. And then Typescript happens, my macbook's fan keeps spinning from time to time.
AFAIK Typescript has no runtime impact on performance, the transpiled JS should be equally fast as the handwritten code
I think they mean the performance of VSCode editing a project with Typescript code in it. There's the runtime cost of VSCode checking the Typescript, providing intellisense, etc. (Not that I've ever had that runtime cost be noticeable to me. Maybe it's a real issue on certain codebases or workflows.)
Typescript is compiled away. There are certainly issues with VSCode, but TS isn't one of them.
It might sound controversial, but for me Atom was almost a 1 to 1 Sublime copy with worse performance and quality. It was slow and ugly. It’s only quality was that it was 0$.
It was the first editor I’ve seen to choke when opening 1M file (it even had a warning that it’s a too big file - lol). There simply was not enough RAM in the world for this memory hog.
I’m not really sad to see it go. It was another free toy of a big company that people used not to spend 60$ on real thing made by small company and waste thousands of dollars on lost productivity and time.
It was the first editor I’ve seen to choke when opening 1M file (it even had a warning that it’s a too big file - lol). There simply was not enough RAM in the world for this memory hog.
I’m not really sad to see it go. It was another free toy of a big company that people used not to spend 60$ on real thing made by small company and waste thousands of dollars on lost productivity and time.
As an editor day to day yes you are correct. Sublime is the goat as far as performance. VSCode has become my primary editor because I work remotely via SSH but nothing can touch the lightness and latency of subl. I still run it in tandem with vscode for stuff that doesn’t require a remote conn. It’s an order of magnitude quicker than VSCode.
You need a good machine, but on an M2 SSD with a recent CPU and enough RAM, VSCode takes one second to start, much less to open a new tab. Not sure Sublime Text's speed will still be a big selling point in the future.
> nothing can touch the lightness and latency of subl
There's this editor called vim. You should have a look.
There's this editor called vim. You should have a look.
For some people (like me), re-teaching muscle memory is a huge battle that takes years. Switching to an editor where you can't use the mouse as a crutch until you learn it is a non-starter.
Next time you're on an airplane and have nothing to do, but have access to a laptop, consider firing up `vimtutor`. I think you might underestimate how much time it takes to build up muscle memory in a new system. Not saying you'll be a wizard by the time you get off the flight, but it might surprise you how far you get!
vim has both terminal and gui builds. The latter supports the mouse.
Even the terminal build supports the mouse. `set mouse=a`
I use vim as my daily driver. Just want to make it clear to people that even vim with mouse support is not going to be a drop in replacement for vscode/atom/sublime. You're still going to have a hare time being productive in it for a good while until you learn the keybinds and train your muscle-memory
> t was the first editor I’ve seen to choke when opening 1M file
I recall trying Atom before VSCode had been released. I loaded up a 1MB XML file and it ground to a halt.
After some searching I found a bug tracker issue reflecting this, where one of the devs said something to the effect of "a 1MB XML file is extremely large, I don't think we'll support that".
At that point I uninstalled Atom.
On a related note, not long ago I accidentally dragged a 450MB SQL script into VSCode. I fully expected it to cave like Atom had on the 1MB XML. However to my pleasant surprise it worked just fine. Editing it was as quick as a regular file, and the memory usage was not excessive (around 2.5G total). I admit I was a bit impressed by that.
I recall trying Atom before VSCode had been released. I loaded up a 1MB XML file and it ground to a halt.
After some searching I found a bug tracker issue reflecting this, where one of the devs said something to the effect of "a 1MB XML file is extremely large, I don't think we'll support that".
At that point I uninstalled Atom.
On a related note, not long ago I accidentally dragged a 450MB SQL script into VSCode. I fully expected it to cave like Atom had on the 1MB XML. However to my pleasant surprise it worked just fine. Editing it was as quick as a regular file, and the memory usage was not excessive (around 2.5G total). I admit I was a bit impressed by that.
I had a gig which required opening ridiculously large XML files (metadata for music albums). Some classical music compilations (think "6 CD bargain bin" boxsets) would end up with 1-2GB XML files.
Sublime didn't even flinch when opening and navigating around the file. Truly impressive text editor and absolutely worth the license cost.
Sublime didn't even flinch when opening and navigating around the file. Truly impressive text editor and absolutely worth the license cost.
2.5G is definitely excessive.
Not sure how it represents text, but if it's using UTF-16 (I'm on Windows), then that's 900MB just there given the ASCII input file.
Not gonna say it's lightweight, but not excessive in my book.
Not gonna say it's lightweight, but not excessive in my book.
Not optimized, perhaps, but not unreasonable given the metadata over a nearly-500MB file I would think?
Sublime Text is a fantastic editor. In my opinion it deserves more popularity.
Sublime Text definitely had it's moment in the spotlight, at one point (around 2012-2014) it was basically the only editor I saw people using, besides emacs/vim which has its diehard fans (including myself).
Most of those people are using Visual Studio Code today instead, although in comparison, VS Code is very bloated and slow.
For fun and giggles, here is a comparison of the Google popularity between Sublime Text, Visual Studio Code, TextMate, Vim and Emacs: https://trends.google.com/trends/explore?date=all&q=%2Fm%2F0...
Most of those people are using Visual Studio Code today instead, although in comparison, VS Code is very bloated and slow.
For fun and giggles, here is a comparison of the Google popularity between Sublime Text, Visual Studio Code, TextMate, Vim and Emacs: https://trends.google.com/trends/explore?date=all&q=%2Fm%2F0...
And here I am still using TextMate...
(95% of my coding is in Xcode, the rest gets funneled through TextMate).
(95% of my coding is in Xcode, the rest gets funneled through TextMate).
I also like emacs, Vim and NeoVim a lot… I guess I probably prefer them over Sublime Text. I like the fact that Sublime Text is performant, written in C++, and the product of the work of a guy, not a corporation. I’m happy to pay for stuff I like. It’s a pity that it’s closed-source, though…
Atom being free was surely the main factor. But Sublime was also in a bit of a development rut back then. So Atom filled a bit of a void there.
Yeah, same. I have that disorder where I reflexively try new editors, and Atom lasted about 20 minutes on my computer.
My daily driver editors for the last 20 years, in rough order, were:
* BBEdit
* TextMate
* Sublime
* emacs
I still fire up Sublime, but the longer I use org the better I am at general editing in emacs. It's a gateway drug. ;)
My daily driver editors for the last 20 years, in rough order, were:
* BBEdit
* TextMate
* Sublime
* emacs
I still fire up Sublime, but the longer I use org the better I am at general editing in emacs. It's a gateway drug. ;)
It's unfortunate because all I want is a notepad with syntax highlighting and Atom with most packages disabled offered that.
I don't need code complete, or a terminal, or extensions, or anything else VScode offers. I suppose now is a good time to write my own notepad :/
I don't need code complete, or a terminal, or extensions, or anything else VScode offers. I suppose now is a good time to write my own notepad :/
I think you should get just that with Notepad++ on Windows or TextWrangler (BBedit) on Mac. On Linux I think that all stock editors have it (GEdit, etc…). All that for free and without Electron madness. You should be much better with any of them.
TextWrangler was my goto before Atom and I do prefer the look of the latter.
If you use windows, notepad++ is what you're looking for. It was my first love in terms of code editors, and I still haven't found an editor (besides vim, and probably emacs) that handles on-the-fly macro recording and playback like NPP has for decades.
SciTE is pretty good in that role.
https://www.scintilla.org/SciTE.html
https://www.scintilla.org/SciTE.html
Both Sublime Text and Merge are great and well worth the price for me :)
Same for me and my whole Team. I'm loving it. They're cheap, reliable, fast, flexible, beautiful - just awesome enabler that don't stand in the way. Huge Kudos to the creators! <3
I do not really see the point of Sublime Merge. Tried it a few times, but it just seems unnecessary.
Is it just for people who want to avoid the CLI?
Is it just for people who want to avoid the CLI?
I own a Sublime Merge license and I've been using it as my only Git client for the past year, at least.
It is faster and exposes what I want to do better than any other Git client I've tried. It's easier than the CLI to use, and so far I've found minimal things it cannot do.
I would recommend it to anyone (unless they're obsessed with all-CLI tools for efficiency, then I guess not)
It is faster and exposes what I want to do better than any other Git client I've tried. It's easier than the CLI to use, and so far I've found minimal things it cannot do.
I would recommend it to anyone (unless they're obsessed with all-CLI tools for efficiency, then I guess not)
When you're dealing with multiple repos, projects, tasks, contributors etc, version control quickly becomes a very multi-dimensional thing. I generally prefer CLI software where possible, and will happily use vanilla git for personal projects, but once a certain threshold of complexity is passed, a good git GUI seems to add a lot of value.
I'm a heavy git user, but I've never used anything else except Sublime Merge.
Because of that, I am also comfortable now with the CLI: Sublime Merge uses git terminology and made me understand a lot of details about git that I can transfer to the CLI. Things like using stash, cherry picking, tagging or rebasing are all very easily doable in Sublime Merge and if you choose to use one of those features, you automatically get familar with the CLI commands you'd need to use. Brilliant.
I'm not familiar with the whole feature set of the CLI, but I'm not missing much during day-to-day work in Sublime Merge.
PS: Clearly when it comes to more specific issues to fix, there is still the option to use the CLI for that.
Because of that, I am also comfortable now with the CLI: Sublime Merge uses git terminology and made me understand a lot of details about git that I can transfer to the CLI. Things like using stash, cherry picking, tagging or rebasing are all very easily doable in Sublime Merge and if you choose to use one of those features, you automatically get familar with the CLI commands you'd need to use. Brilliant.
I'm not familiar with the whole feature set of the CLI, but I'm not missing much during day-to-day work in Sublime Merge.
PS: Clearly when it comes to more specific issues to fix, there is still the option to use the CLI for that.
Line-by-line commits in Sublime Merge are much easier to do. Also the timeline view if you're pressured into "gitflow" and such things.
The first and last time I tried Sublime Text, it turned out to be impossible to properly have a file open in two editors (or tabs or whatever Sublime's term is): any changes made in one editor were only synchronized to the other editor upon saving the file. I really tried to like Sublime, but the lack of such a basic feature was a total no-go. That was several years ago, has the situation changed?
Multiple views into a single file have been supported for a long time; I believe as far back as ST2. Currently it's easily accessible by right-clicking on a tab and selecting "Split View".
Make no mistake... This project, Atom. Provided the runway that others copied, then improved upon (and on and on... with plenty of funding).
Atom provided the seed, excitement and vision for what is possible on this platform, and should be proud of that fact.
Atom provided the seed, excitement and vision for what is possible on this platform, and should be proud of that fact.
People started focussing on text editors again after Atom came out.
I'd credit Sublime Text with that.
I second that, Sublime raised the bar and set the new standard, the only advantage VScode now has over sublime is it's open source license.
VS Code is not really open source.
https://opensource.stackexchange.com/questions/4288/is-micro...
https://code.visualstudio.com/docs/supporting/faq#_why-does-...
https://opensource.stackexchange.com/questions/4288/is-micro...
https://code.visualstudio.com/docs/supporting/faq#_why-does-...
Though you can just use Codium or the OSS version if you don't need remote magic.
Or the vast amount of plugins and community support. Using atom over vscode hasn’t really made sense for a few years now , and I loved atom
... and the fact that I don't have to pay for it. Never understood why anyone would spend money on a text editor.
It's a tool most of us use for many thousands of hours a year. Buying a better one, even if it was only a bit easier to use, or a bit faster, makes a lot of sense.
Also, many developers (not all) make a lot of money. Even Sublime's steep 60 bucks, which when I discovered Sublime as a student was crazy to me, is reasonable when compared to our salaries.
I don't think anyone would be surprised if a woodworker said "Yeah my drill works fine but I'm going to spend 60 bucks on a slighly better one; I use it a lot and mine's ergonomics aren't great."
Also, many developers (not all) make a lot of money. Even Sublime's steep 60 bucks, which when I discovered Sublime as a student was crazy to me, is reasonable when compared to our salaries.
I don't think anyone would be surprised if a woodworker said "Yeah my drill works fine but I'm going to spend 60 bucks on a slighly better one; I use it a lot and mine's ergonomics aren't great."
TextMate might have a word here.
Yes.
Few of my friends were using Macs and used TextMate. That was years before Sublime was even released.
To me it Sublime was a fast, but clunky alternative to TextMate that ran on PC.
Then came Atom, Brackets, and finally VSCode.
Few of my friends were using Macs and used TextMate. That was years before Sublime was even released.
To me it Sublime was a fast, but clunky alternative to TextMate that ran on PC.
Then came Atom, Brackets, and finally VSCode.
I love this take, this is software in escence, build something, influence is something every developer should strive for
I wonder if it played a part in Microsofts purchase of Github. When you look at things like code spaces, co-pilot and how VSC can now work directly on Github/Azure repositories without moving the code to "your machine", it seems like they found a good way to make Github (and Azure DevOps) more profitable through Atoms successor.
That is how we all will remember Atom.
> Atom provided the seed, excitement and vision for what is possible on this platform, and should be proud of that fact.
Atom provided the seed, excitement and vision for bloated Electron apps, and shouldn't be very proud of that fact.
Atom provided the seed, excitement and vision for bloated Electron apps, and shouldn't be very proud of that fact.
I believe it was the first electron app and to be fair, there are some great electron apps out there (VSCode, Obsidian, Discord, Slack).
Pour one out. While Atom itself was overtaken by a better editor, its legacy lives on in the form of "Atom Shell" aka Electron (for better or worse).
For better, certainly. Electron has in particular been an enormous boon for Linux users, because it's so easy to make cross-platform applications now that even companies who wouldn't have bothered otherwise now have a Linux download. No way that apps like Slack would have a Linux desktop version if it wasn't for Electron.
Or another way to phrase it is that the experience sucks equally on all platforms, so you might as well switch to Linux.
Everyone believes Electron "sucks" because it's mainly the apps that suck that are noticeably built with Electron.
It's the "when you do things right, people won't be sure you've done anything at all" phenomenon. <https://www.youtube.com/watch?v=VofkquwmT40&t=29s>
It's the "when you do things right, people won't be sure you've done anything at all" phenomenon. <https://www.youtube.com/watch?v=VofkquwmT40&t=29s>
When almost every app sucks, I feel like it’s at least partially a platform issue.
(Disclaimer: I actually have RAM to spare, in constrained environments the situation might be different)
VS Code is pretty much the only larger electron app I think is very well done. Discord is pretty good, but then it starts going downhill. MS Teams is mostly responsive, bottom-of-the-barrel apps like postman feel like you are on a thin client remoting over a slow internet connection. And most electron apps sit between Teams and Postman.
(Disclaimer: I actually have RAM to spare, in constrained environments the situation might be different)
VS Code is pretty much the only larger electron app I think is very well done. Discord is pretty good, but then it starts going downhill. MS Teams is mostly responsive, bottom-of-the-barrel apps like postman feel like you are on a thin client remoting over a slow internet connection. And most electron apps sit between Teams and Postman.
Many Electron apps literally are a wrapped or packaged version of some SPA-style web interface, and the UX reflects that, naturally.
But - beyond the base Chromium "footprint", which to be fair isn't negligible - you absolutely _can_ build high-performance, resource-conserving (and not degrading-over-time) applications with Electron.
It probably can't quite match the fully native UX or performance, but with a little care you can definitely get close enough (especially given how common actual web/browser-based apps are anyway). The trouble is Electron is already a "lazy" way to build desktop apps, so many teams probably don't give it the level of care it requires or deserves.
Disclaimer of my own: I maintain a media-rich, processing-intensive and performance-sensitive Electron-based app, so I may be defensive (or arguably informed) about the performance. But I can also consistently achieve 40 to 60 FPS rendering of dynamic graphics (full-screen) and audio (multi-channel) simultaneous with non-trivial, near-real-time input signal processing, on typical hardware, across platforms, just using Electron and standard web APIs. (And I'm just some guy working solo. A larger or more capable team would probably do it better.) The rest of the app's UI/UX is noticeably not native, but that's probably (but not entirely) more the result of _my_ limitations rather than Electron's.
Truly native apps are always going to work and perform at least a little bit better (in the general case) but IMO Electron (when done correctly) is at least on par with any other cross-platform framework you can point to.
It's a compromise, but it doesn't _have_ to be a major one.
But - beyond the base Chromium "footprint", which to be fair isn't negligible - you absolutely _can_ build high-performance, resource-conserving (and not degrading-over-time) applications with Electron.
It probably can't quite match the fully native UX or performance, but with a little care you can definitely get close enough (especially given how common actual web/browser-based apps are anyway). The trouble is Electron is already a "lazy" way to build desktop apps, so many teams probably don't give it the level of care it requires or deserves.
Disclaimer of my own: I maintain a media-rich, processing-intensive and performance-sensitive Electron-based app, so I may be defensive (or arguably informed) about the performance. But I can also consistently achieve 40 to 60 FPS rendering of dynamic graphics (full-screen) and audio (multi-channel) simultaneous with non-trivial, near-real-time input signal processing, on typical hardware, across platforms, just using Electron and standard web APIs. (And I'm just some guy working solo. A larger or more capable team would probably do it better.) The rest of the app's UI/UX is noticeably not native, but that's probably (but not entirely) more the result of _my_ limitations rather than Electron's.
Truly native apps are always going to work and perform at least a little bit better (in the general case) but IMO Electron (when done correctly) is at least on par with any other cross-platform framework you can point to.
It's a compromise, but it doesn't _have_ to be a major one.
As I said, VS Code shows, that it certainly is possible to build performant electron apps. But I’m also saying, that electron is not fully innocent when almost every app built with it sucks.
And assuming you are talking about FATpick, it’s certainly a lot faster than Postman, at least the logged out part I looked at ;)
And assuming you are talking about FATpick, it’s certainly a lot faster than Postman, at least the logged out part I looked at ;)
Sorry but the very good Electron app which actually is very good, VSCode, really does suck if you maintain 10 projects. That’s not a lot of projects. It’s just a lot of browser tabs multiplied by documentation in an actual browser.
I agree you have to keep the number of VSCode windows quite low (5 is ok, 10 will make it struggle) but in fairness how many times have you had 10 instances of Visual Studio or IntelliJ running? I've never got close to that.
"No worse than a Java-based app" is sorta damning with faint praise. Java is notorious for being ill-suited for user-facing desktop apps - and justifiably so, at least historically.
But I agree with your core point. I use VS Code all the time, regularly switching between maybe a dozen different projects, and I personally don't run into performance issues or resource constraints very often. Certainly less often than with heavyweight IDEs like IntelliJ, Eclipse or XCode. But I felt the same way about Atom as well, so maybe my typical project/workflow/usage pattern is less resource intensive than others. (For one thing I hardly ever run apps from _within_ the IDE, I prefer to build/test/run from a terminal, so that might be a factor.)
VS Code isn't quite as responsive or quick to start as something like vim, or even emacs when run in a terminal, but its resource demands seem roughly on par with any other feature-rich IDE/editor in my experience.
But I agree with your core point. I use VS Code all the time, regularly switching between maybe a dozen different projects, and I personally don't run into performance issues or resource constraints very often. Certainly less often than with heavyweight IDEs like IntelliJ, Eclipse or XCode. But I felt the same way about Atom as well, so maybe my typical project/workflow/usage pattern is less resource intensive than others. (For one thing I hardly ever run apps from _within_ the IDE, I prefer to build/test/run from a terminal, so that might be a factor.)
VS Code isn't quite as responsive or quick to start as something like vim, or even emacs when run in a terminal, but its resource demands seem roughly on par with any other feature-rich IDE/editor in my experience.
> Java is notorious for being ill-suited for user-facing desktop apps - and justifiably so, at least historically.
I'm on a trip in Brazil, and so far I saw 1 commercial system built in Java at a grocery store cashier, and 3 Government systems: Border and Customs office's computer, Postal Office ("Correios") point of sale (a desktop), and the software that must be used for tax return by all citizens (IRPF).
All of them used by millions of people directly or indirectly, all of them implemented in Java Swing.
I'm on a trip in Brazil, and so far I saw 1 commercial system built in Java at a grocery store cashier, and 3 Government systems: Border and Customs office's computer, Postal Office ("Correios") point of sale (a desktop), and the software that must be used for tax return by all citizens (IRPF).
All of them used by millions of people directly or indirectly, all of them implemented in Java Swing.
Pretty much all the time!
- Four that I maintain directly which integrate together, so even if I’m only working on one at a time I often have to cross reference. This is a good candidate for a workspace, but lots of my workflow broke when I tried it. It’s entirely possible that’s solvable but I had more pressing work to do.
- Two related projects which I seldom contribute to directly, but integrate with the prior four, and I cross reference frequently as well.
- One for organizing and tracking work, notes, various work-related detritus.
- Generally my top three personal projects. I’m not working on them nearly as frequently, but they too are useful for cross referencing. And with seven windows already open, it’s slower to open and close them on demand than to just leave them up.
- Four that I maintain directly which integrate together, so even if I’m only working on one at a time I often have to cross reference. This is a good candidate for a workspace, but lots of my workflow broke when I tried it. It’s entirely possible that’s solvable but I had more pressing work to do.
- Two related projects which I seldom contribute to directly, but integrate with the prior four, and I cross reference frequently as well.
- One for organizing and tracking work, notes, various work-related detritus.
- Generally my top three personal projects. I’m not working on them nearly as frequently, but they too are useful for cross referencing. And with seven windows already open, it’s slower to open and close them on demand than to just leave them up.
Visual Studio (purple icon) can struggle with just one instance, especially if you're using ReSharper. As for the IntelliJ family, I've run Rider with about 10 projects a few times and it was fine (granted, those projects were small).
For real, just because Electron takes up additional space doesn't mean shit.
Discord, VSC, Teams, Slack, and Skype are built with Electron, all inspired by Atom.
What's the difference between Electron apps that are "noticeably built with Electron" and ones that aren't?
This is my take, a Mac user since 68k who finds very little besides hardware appealing on the platform anymore. The only reason I’m not running everything in Linux at least in a VM at this point is time to migrate my dev environment. It’s a shame IMO but yep 20Electron is apparently the year everything might as well be Linux on the desktop.
The 1% Linux users may have benefited, but it came at the expense of the other 99% on Windows & Mac who had to give up native performance and UI on all their applications.
Because I totally need native performance on an app that primarily displays text, text entry, buttons, other form controls, and maybe a random image or two.
Exactly. The truth is that over that last 15+ years _most_ of the apps that people use _most_ of the time are a perfect and natural fit for the web UI/UX: text, media, hyperlinks, standard form/window controls, with relatively modest standards of performance and responsiveness, etc.
Assuming developers avoid resource leaks (and to be fair some notable Electron-based apps tend to be both leaky and long-running) the main drawback of Electron seems to be the non-native look-and-feel. But that _could_ be worked around (for the most part) with some effort, and I suspect most users don't actually care that much. The web browser is still probably the most-used desktop app. The web look-and-feel is familiar and intuitive to users, even if it stands out a little from the UI of native apps.
Poor resource management aside, something like Electron is probably good _enough_ for most applications.
Assuming developers avoid resource leaks (and to be fair some notable Electron-based apps tend to be both leaky and long-running) the main drawback of Electron seems to be the non-native look-and-feel. But that _could_ be worked around (for the most part) with some effort, and I suspect most users don't actually care that much. The web browser is still probably the most-used desktop app. The web look-and-feel is familiar and intuitive to users, even if it stands out a little from the UI of native apps.
Poor resource management aside, something like Electron is probably good _enough_ for most applications.
I have never, in my life, used an electron program that isn't irritatingly slow on my main computer. Yes, it's not something you'd probably call a fast computer (4th gen i3, 4GB ram), but this same computer doesn't drop a frame in equivalent native programs. Most of the time the CPU is almost idle.
I have nothing intrinsic against electron, and I'll take everything back if I see these "natural fits" actually fit.
I have nothing intrinsic against electron, and I'll take everything back if I see these "natural fits" actually fit.
It sounds like your 8 year old computer can't keep with today's technology. If it's possible, might I suggest upgrading your computer? A more modern system would let you run Electron apps without being irritatingly slow. It seems silly that I had to upgrade my laptop in order to run a text editor, but it seems that's just the world we live in.
I know this is not what you're saying, but when I read your post I start hearing an internal voice going something like:
Contribute more to e-waste! Pollute more! Consume! Consume!
A bog-standard 8-year old computer would be considered a supercomputer by the standards of the '80s, so at some point we ought to put some effort into making computers feel like the insanely powerful beasts they are. And Electron won't help with that.
Contribute more to e-waste! Pollute more! Consume! Consume!
A bog-standard 8-year old computer would be considered a supercomputer by the standards of the '80s, so at some point we ought to put some effort into making computers feel like the insanely powerful beasts they are. And Electron won't help with that.
Typical first world answer.
Most people in this world would rather spend the required 400usd needed to get a >=8GB computer on fixing their vehicule/home and pay their monthly bills.
This +environment damage limitations.
Apart from the software and system engineers I don't know a single person in my social circle that own a computer with more than 4GB of memory. And I am not living in a third world country.
Most people in this world would rather spend the required 400usd needed to get a >=8GB computer on fixing their vehicule/home and pay their monthly bills.
This +environment damage limitations.
Apart from the software and system engineers I don't know a single person in my social circle that own a computer with more than 4GB of memory. And I am not living in a third world country.
> A more modern system would let you run Electron apps without being irritatingly slow.
That's the problem though: it won't. There is no modern system on which Electron apps run without being irritatingly slow.
That's the problem though: it won't. There is no modern system on which Electron apps run without being irritatingly slow.
I get what you're saying, but Electron apps on like a Core2Duo is unusably bad. On a modern system with plenty of ram they're much more usable.
On one side, I agree that expecting an 8yo machine to keep up with modern workflows is silly, and that at some point even bill gates or whoever you attribute the famous 512kb RAM quote to had to admit they were wrong
Forgot to type the rest and can't edit for some reason.
On the other hand, vim or Emacs with all features I personally currently use in vscode come in at a fraction of the memory usage, and it is a bit dumb to have to use that much ram for slack or discord considering how light IRC clients used to be.
On the other hand, vim or Emacs with all features I personally currently use in vscode come in at a fraction of the memory usage, and it is a bit dumb to have to use that much ram for slack or discord considering how light IRC clients used to be.
Yeah it's dumb but what're you gonna do? Technology evolves and the way this industry works is you gotta keep up. Can't keep computing like we're still on mainframes writing Cobol.
According to the industry, my laptop is slow. I, however, think that my laptop is actually very fast. It's just that everyone gets new stuff every year and the threshold for "usable computer" goes up accordingly.
VS Code is unusable on my laptop. I tried it, it's way too slow to be usable. I've used vim with a few plugins that got it to the same feature set as VS Code and it's actually usable. At some point I tried Lite XL, and it was incredibly fast with the same features. More recently, I tried helix and I can say that I've never used such a fast editor with auto complete and all that.
Most electron applications waste me time and energy (both human and electricity), and if software keeps going this way it'll start wasting me money. I'm not thrilled, but like you said, what are you gonna do?
VS Code is unusable on my laptop. I tried it, it's way too slow to be usable. I've used vim with a few plugins that got it to the same feature set as VS Code and it's actually usable. At some point I tried Lite XL, and it was incredibly fast with the same features. More recently, I tried helix and I can say that I've never used such a fast editor with auto complete and all that.
Most electron applications waste me time and energy (both human and electricity), and if software keeps going this way it'll start wasting me money. I'm not thrilled, but like you said, what are you gonna do?
> I have nothing intrinsic against electron, and I'll take everything back if I see these "natural fits" actually fit.
As a baseline, Electron performance _should_ be no worse than a regular SPA-style web UI running in the browser. Unless you find _everything_ on the web "irritatingly slow" it's surely _possible_ to create an Electron app with acceptable performance.
From my perspective anyway, I've both used and contributed to multiple Electron-based apps with performance that was not only "adequate" but not noticeably different from a typical native app. Basic Electron apps (done correctly) will look and feel more or less like a web app but perform more or less like a web app too.
FWIW there is a lightly-curated list of electron apps at https://www.electronjs.org/apps
I'm not sure offhand which of those is a good example of UI/UX and performance, but if you poke around with some of the medium-scope stuff (not too basic, not too ambitious) I'll bet you can find some examples.
UPDATE: I spot checked a few of those Electron apps for the fun of it. Here are a few examples you may find compelling:
* Deer - https://github.com/abahmed/Deer/releases/tag/v1.0.0 - A simple styled-text note-taking app that was last updated ~4 years ago. I don't _love_ all the UX choices personally but the performance seemed reasonable in my short test, especially considering the version of Electron they are using is 16 major releases out of date. There are probably more robust note-taking examples in that list (e.g. Inkdrop, Notable, Notion), this just happens to be the one I grabbed.
* Pencil - https://pencil.evolus.vn/ - A much more complex app for drawing fairly sophisticated Visio-like diagrams and UI mock-ups. Performance wise it seems about as responsive as a typical native app on my nearly 3 year old MacBook. But it may have large-ish baseline memory footprint so YMMV.
* I notice that some well known apps (or at least brands) are listed, like Trello, Asana, Notion, GitHub Desktop, Basecamp, WordPress, Twitch, Skype, Signal, Quickbooks, Light Table, Figma, WhatsApp, etc. For several of those I for one was not aware that they were Electron-based, and I'm guessing at least some (but probably not all) of those work pretty well. I think I've used both GitHub Desktop and Notion without anything to complain about but I'm not surprised that they are Electron apps. I've definitely used that Skype client and never noticed that it was an Electron app. I've never used it, but I'd bet Trello works well too.
IMO I think this demonstrates my original point in this thread: When an Electron app is well-engineered you don't even notice that it's Electron. It's survivor bias. People think Electron apps are bad because it's the bad apps that are noticeably Electron-based.
As a baseline, Electron performance _should_ be no worse than a regular SPA-style web UI running in the browser. Unless you find _everything_ on the web "irritatingly slow" it's surely _possible_ to create an Electron app with acceptable performance.
From my perspective anyway, I've both used and contributed to multiple Electron-based apps with performance that was not only "adequate" but not noticeably different from a typical native app. Basic Electron apps (done correctly) will look and feel more or less like a web app but perform more or less like a web app too.
FWIW there is a lightly-curated list of electron apps at https://www.electronjs.org/apps
I'm not sure offhand which of those is a good example of UI/UX and performance, but if you poke around with some of the medium-scope stuff (not too basic, not too ambitious) I'll bet you can find some examples.
UPDATE: I spot checked a few of those Electron apps for the fun of it. Here are a few examples you may find compelling:
* Deer - https://github.com/abahmed/Deer/releases/tag/v1.0.0 - A simple styled-text note-taking app that was last updated ~4 years ago. I don't _love_ all the UX choices personally but the performance seemed reasonable in my short test, especially considering the version of Electron they are using is 16 major releases out of date. There are probably more robust note-taking examples in that list (e.g. Inkdrop, Notable, Notion), this just happens to be the one I grabbed.
* Pencil - https://pencil.evolus.vn/ - A much more complex app for drawing fairly sophisticated Visio-like diagrams and UI mock-ups. Performance wise it seems about as responsive as a typical native app on my nearly 3 year old MacBook. But it may have large-ish baseline memory footprint so YMMV.
* I notice that some well known apps (or at least brands) are listed, like Trello, Asana, Notion, GitHub Desktop, Basecamp, WordPress, Twitch, Skype, Signal, Quickbooks, Light Table, Figma, WhatsApp, etc. For several of those I for one was not aware that they were Electron-based, and I'm guessing at least some (but probably not all) of those work pretty well. I think I've used both GitHub Desktop and Notion without anything to complain about but I'm not surprised that they are Electron apps. I've definitely used that Skype client and never noticed that it was an Electron app. I've never used it, but I'd bet Trello works well too.
IMO I think this demonstrates my original point in this thread: When an Electron app is well-engineered you don't even notice that it's Electron. It's survivor bias. People think Electron apps are bad because it's the bad apps that are noticeably Electron-based.
You're right. I tried Deer and it works perfectly, it's smooth and only drops a frame or two on a cold start. It's a well-written program. If it weren't for the UI, I wouldn't even have guessed it's electron. I tried using Pencil too but it didn't work for me because of dynamic link problems (not Pencil's fault - just Linux being very bad at packaging things and me running a slightly nonstandard system).
That said, the ratio of fast electron apps over slow electron apps is much worse than the one of fast native apps over slow native apps. If it's not the tech then it's the people around it. Either way, if I hear "hot new program" and it's electron, I don't think I'm in the wrong to assume it will also be rather slow.
At the end of the day, all I really care about is for the programs I use to work well and reliably. I don't really care how you make them, and as I said I don't have anything intrinsic against electron.
That said, the ratio of fast electron apps over slow electron apps is much worse than the one of fast native apps over slow native apps. If it's not the tech then it's the people around it. Either way, if I hear "hot new program" and it's electron, I don't think I'm in the wrong to assume it will also be rather slow.
At the end of the day, all I really care about is for the programs I use to work well and reliably. I don't really care how you make them, and as I said I don't have anything intrinsic against electron.
That's why to do that you need a full-blown browser that consumes enormous amounts of RAM and consumes 17% of CPU to display animated GIFs https://twitter.com/dmitriid/status/1486364312910368769?s=20...
I do actually, because it's a sad day when displaying a mere paucity of UI elements isn't performant.
Just an aside that had nothing to do with Atom itself, but I didn’t get into Electron while it was still called “Atom Shell” because the name was doing it a bit of a disservice. For some reason, by brain put it into a category of software more akin to bash/zsh and never questioned it again.
Did anyone else experience the something similar?
Did anyone else experience the something similar?
Tree-sitter[0] came out of Atom performance optimization, I think, and that's a legacy that will live on a long time. Atom was in my view the closest thing to emacs out there, and it's sad to see that sort of user-empowerment not live on.
[0]https://tree-sitter.github.io/tree-sitter/
[0]https://tree-sitter.github.io/tree-sitter/
The emacs comparison definitely feels apt. Being able to simply use JavaScript and CSS to make changes to the editor made it feel so powerful. Maybe I just need to get around to learning elisp (or find an elisp-JavaScript binding…)
Lots of things came from Atom and it's development, so much I'd still consider it a success although the editor itself didn't live on. Tree-sitter, Electron, "text-editor as a browser app" all became popular ideas thanks to Atom. Is there more things coming from Atom that I'm missing?
I resisted switching to VS Code for a long time because I far preferred the UX and design of Atom, but I eventually caved not because of performance gains I wanted in VS Code (honestly I found Atom plenty fast for the work I was doing), but because many Atom extensions were left to rot and slowly broke over time as most maintainers moved to VSCode extensions.
Farewell friend, you will be missed.
Farewell friend, you will be missed.
>I far preferred the UX and design of Atom, but I eventually caved
That's my experience exactly. I still haven't been able to configure VS Code to fully match the experience I want with respect to keybindings and subtle look-and-feel and functionality details.
Aside from the infrequent case of hanging when opening very large files I had no real issues with Atom and could have happily kept using it.
For what it's worth Pulsar (https://pulsar-edit.dev/) appears to be a community-maintained fork of Atom. (For that matter one of the primary Atom creators is working on https://zed.dev/.) But personally I got tired of swimming upstream and just caved to VS Code.
(I am a little tempted to go back to emacs, which was my editor of choice before Atom, but that's ends up being an enormous time-sink for me anyway.)
That's my experience exactly. I still haven't been able to configure VS Code to fully match the experience I want with respect to keybindings and subtle look-and-feel and functionality details.
Aside from the infrequent case of hanging when opening very large files I had no real issues with Atom and could have happily kept using it.
For what it's worth Pulsar (https://pulsar-edit.dev/) appears to be a community-maintained fork of Atom. (For that matter one of the primary Atom creators is working on https://zed.dev/.) But personally I got tired of swimming upstream and just caved to VS Code.
(I am a little tempted to go back to emacs, which was my editor of choice before Atom, but that's ends up being an enormous time-sink for me anyway.)
I cannot stand VSCode UX/UI. Not sure how this is not an issue for everyone. Maybe I'm just too picky. For this kind of things I don't use VSCode:
- The right side bar is "dynamic". Most of the time it's the Explorer showing the directories and files, but when I try to search for something, though, it becomes the Search sidebar. Same for all the potential sidebars (Source Control, Run and Debug, etc.)
- Everything is a plugin. That means I need to carefully check who's the author of the plugin, probably check as well the source code to avoid using malware, etc.
- Everything is a plugin. That means I need to craft a set of plugins in order to work in certain projects. I prefer JetBrain's approach
- No floating windows. Maybe I'm old-fashioned, but I prefer that, for instance, Settings to be opened in its own window, instead of opening a new tab in my editor. Also all the Settings in VSCode are on the same "page" (sure, whenever you scroll, the left-side grouping of Settings is updated accordingly, but imho it's difficult for me to focus on the section I need to work on)
- The right side bar is "dynamic". Most of the time it's the Explorer showing the directories and files, but when I try to search for something, though, it becomes the Search sidebar. Same for all the potential sidebars (Source Control, Run and Debug, etc.)
- Everything is a plugin. That means I need to carefully check who's the author of the plugin, probably check as well the source code to avoid using malware, etc.
- Everything is a plugin. That means I need to craft a set of plugins in order to work in certain projects. I prefer JetBrain's approach
- No floating windows. Maybe I'm old-fashioned, but I prefer that, for instance, Settings to be opened in its own window, instead of opening a new tab in my editor. Also all the Settings in VSCode are on the same "page" (sure, whenever you scroll, the left-side grouping of Settings is updated accordingly, but imho it's difficult for me to focus on the section I need to work on)
> - The right side bar is "dynamic". Most of the time it's the Explorer showing the directories and files, but when I try to search for something, though, it becomes the Search sidebar. Same for all the potential sidebars (Source Control, Run and Debug, etc.)
Yeah it's just a tabbed view. I like it, saves space while staying useful. Maybe because most software I use has tabs already.
- Everything is a plugin. That means I need to carefully check who's the author of the plugin, probably check as well the source code to avoid using malware, etc.
True, but most popular languages have plugins authored by Microsoft. Some are from Red Hat. You'll miss out on GitLens and LaTeX Workshop, but VSCode with only trusted plugins is more than good enough.
> - Everything is a plugin. That means I need to craft a set of plugins in order to work in certain projects. I prefer JetBrain's approach
For Python, web dev, C++, etc., there's a "plugin pack" that depends on what you need to work.
> No floating windows. Maybe I'm old-fashioned, but I prefer that, for instance, Settings to be opened in its own window, instead of opening a new tab in my editor. Also all the Settings in VSCode are on the same "page" (sure, whenever you scroll, the left-side grouping of Settings is updated accordingly, but imho it's difficult for me to focus on the section I need to work on)
Sounds like you just don't like tabs? I find that the window list gets way too crowded and messy when I'm working on multiple projects with multiple tools. Tabs (in browser, explorer and editors) are a lifesaver.
Yeah it's just a tabbed view. I like it, saves space while staying useful. Maybe because most software I use has tabs already.
- Everything is a plugin. That means I need to carefully check who's the author of the plugin, probably check as well the source code to avoid using malware, etc.
True, but most popular languages have plugins authored by Microsoft. Some are from Red Hat. You'll miss out on GitLens and LaTeX Workshop, but VSCode with only trusted plugins is more than good enough.
> - Everything is a plugin. That means I need to craft a set of plugins in order to work in certain projects. I prefer JetBrain's approach
For Python, web dev, C++, etc., there's a "plugin pack" that depends on what you need to work.
> No floating windows. Maybe I'm old-fashioned, but I prefer that, for instance, Settings to be opened in its own window, instead of opening a new tab in my editor. Also all the Settings in VSCode are on the same "page" (sure, whenever you scroll, the left-side grouping of Settings is updated accordingly, but imho it's difficult for me to focus on the section I need to work on)
Sounds like you just don't like tabs? I find that the window list gets way too crowded and messy when I'm working on multiple projects with multiple tools. Tabs (in browser, explorer and editors) are a lifesaver.
On "No floating windows". I'm with you.
I've gotten used to Visual Studio, where I can grab a tab and pull it out of the window to make it its own window. If you try that in VSCode, it'll just drop the file on the Desktop.
To get something similar in VSCode, I have to open a new window, drag the file over, then close it in the original window.
I've gotten used to Visual Studio, where I can grab a tab and pull it out of the window to make it its own window. If you try that in VSCode, it'll just drop the file on the Desktop.
To get something similar in VSCode, I have to open a new window, drag the file over, then close it in the original window.
For your first point, you can drag views to other parts of the window.
To add to everything else people are reminiscing about, here's Atom's very fun announcement trailer from 7 years ago: https://www.youtube.com/watch?v=Y7aEiVwBAdk
In general the marketing and branding of Atom was awesome. The retro-futuristic design worked well with the idea of bringing a text editor into the 21st century. I love that they call their docs the 'flight manual.' It will be missed.
On its announcement it made my 2014 netbook overheat and lag like an ssh terminal in south Peru.
RIP
RIP
I think the Atom editor + Hydrogen plugin for running interactive Python sessions inline with the code is still unmatched by anything available in VS Code. This setup is what I migrated to when I ditched Matlab for the "scientific Python" stack, and I'm still here.
Multiple concurrent kernels, the ability to connect any .py file to any running kernel, sharing variables and imports across multple .py files, inline matplotlib output that persists on-screen and inline with the code even when running other code cells... the list goes on. I'm really fond of this setup. I use it daily--it's an essential component of my day job--and intend to do so for the foreseeable future. VS Code does seem to be the way of the future but there have just been too many friction points for me to leave Atom.
Multiple concurrent kernels, the ability to connect any .py file to any running kernel, sharing variables and imports across multple .py files, inline matplotlib output that persists on-screen and inline with the code even when running other code cells... the list goes on. I'm really fond of this setup. I use it daily--it's an essential component of my day job--and intend to do so for the foreseeable future. VS Code does seem to be the way of the future but there have just been too many friction points for me to leave Atom.
What’s preventing this from being done in VSCode? Other than it hasn’t yet?
I don’t think it ticks every box for you, but have you tried Jupyter Notebooks in VSCode[0]?
[0] https://code.visualstudio.com/docs/datascience/jupyter-noteb...
I don’t think it ticks every box for you, but have you tried Jupyter Notebooks in VSCode[0]?
[0] https://code.visualstudio.com/docs/datascience/jupyter-noteb...
VSCode doesn't support an API to put outputs inline in the text editor. IIRC there have been longstanding feature requests for it but it would probably have a performance hit. The closest thing is having a separate output window on the right side
I don't think it's an API problem, because Scala Worksheets work in VSCode[0] (and in most editors actually).
[0] https://scalameta.org/metals/docs/editors/vscode/#worksheets
[0] https://scalameta.org/metals/docs/editors/vscode/#worksheets
I think you're referring to the "inlay hint" API, which is different from being able to visualize any HTML in the current text editor, like Hydrogen is able to: https://cloud.githubusercontent.com/assets/13285808/20360886...
VSCode’s Jupyter Notebooks is slightly different from Hydrogen in that it’s basically a MarkDown document with executable code blocks (cells) in the text editor that show their output in the text editor.
Again, not exactly the same as Hydrogen but there’s definitely some overlap in use cases and VSCode’s Jupyter Notebooks is pretty good. You should give it a shot and see if it’s a viable replacement for what you were using Hydrogen for.
This showcases the UI a bit if I’m not being clear: https://code.visualstudio.com/learn/educators/notebooks
Again, not exactly the same as Hydrogen but there’s definitely some overlap in use cases and VSCode’s Jupyter Notebooks is pretty good. You should give it a shot and see if it’s a viable replacement for what you were using Hydrogen for.
This showcases the UI a bit if I’m not being clear: https://code.visualstudio.com/learn/educators/notebooks
That's exactly my complaint though. I don't want to work in a notebook frame of mind. I don't want to have to demarcate `#%%` every time I run code (especially because you'd need to scroll down to put another `#%%` where the code you're running should stop.)
As I noted in a sibling comment, I wrote a quick extension [0] that makes this easier by automatically inferring code blocks, but VSCode Jupyter is lacking in other ways: you can't have multiple Jupyter kernels running at the same time and it doesn't show you runtime completions in the editor (necessary for compiled packages without type support).
[0]: https://github.com/kylebarron/vscode-jupyter-python
As I noted in a sibling comment, I wrote a quick extension [0] that makes this easier by automatically inferring code blocks, but VSCode Jupyter is lacking in other ways: you can't have multiple Jupyter kernels running at the same time and it doesn't show you runtime completions in the editor (necessary for compiled packages without type support).
[0]: https://github.com/kylebarron/vscode-jupyter-python
Is that not what Jupyter notebook support is about? I can run something and see the output below the code.
But with Hydrogen you could do that in a regular Python script without needing to create a notebook or think in terms of cells. There's an example of this in the Hydrogen readme: https://github.com/nteract/hydrogen#hydrogen-
I completely agree. For the last couple years I've used VSCode for everything _except_ interactive Python development because Atom + Hydrogen is just too good.
I'm giving VS Code + its Jupyter extension a shot for now. It's significantly worse than Hydrogen, but I tried to make it a little less bad with a quick extension to auto-infer code blocks [0].
[0]: https://github.com/kylebarron/vscode-jupyter-python
I'm giving VS Code + its Jupyter extension a shot for now. It's significantly worse than Hydrogen, but I tried to make it a little less bad with a quick extension to auto-infer code blocks [0].
[0]: https://github.com/kylebarron/vscode-jupyter-python
Same! I live in this ecosystem (Atom + Hydrogen python sessions) on a daily basis. But rather than for "science", i use it for devops productivity (scrape logs, query dbs, automate mitigations) and some low-key data analysis.
It's breathed life into my love for programming, given how easy it is to just start executing code (sometimes I just use it as a calculator app since it's that easy and accessible)
I tried VSCode's equivalent plugin, but the UX was nowhere near as nice.
It's breathed life into my love for programming, given how easy it is to just start executing code (sometimes I just use it as a calculator app since it's that easy and accessible)
I tried VSCode's equivalent plugin, but the UX was nowhere near as nice.
I'm a happy user of Atom as my daily driver for basic note taking and scratch pads. Even though it's being sunset, I look forward to using it for years to come.
Perhaps it will have a good fork one day, but honestly it works great as-is. Sometimes software reaches a point where it just works, and you appreciate not having a team that wants to change everything.
Perhaps it will have a good fork one day, but honestly it works great as-is. Sometimes software reaches a point where it just works, and you appreciate not having a team that wants to change everything.
> Even though it's being sunset, I look forward to using it for years to come.
I'd be very, very careful with that. My understanding is that Atom will no longer receive any updates, including security updates. Atom has had a remote code execution vulnerability in the past that could be triggered by simply opening a package readme IIRC.
Atom is deeply integrated with the browser/Node.js ecosystem, and as such using a stale version sounds potentially very dangerous. I sincerely wish it was different, and that we could just continue using unmaintained applications as long as they "work", but that is sadly not the state of software today.
I'd be very, very careful with that. My understanding is that Atom will no longer receive any updates, including security updates. Atom has had a remote code execution vulnerability in the past that could be triggered by simply opening a package readme IIRC.
Atom is deeply integrated with the browser/Node.js ecosystem, and as such using a stale version sounds potentially very dangerous. I sincerely wish it was different, and that we could just continue using unmaintained applications as long as they "work", but that is sadly not the state of software today.
There’s already an attempt to keep it going
https://pulsar-edit.dev/
https://pulsar-edit.dev/
Today they just announced V1.0 of their backend:
"This Backend Server supports all documented and undocumented endpoints that were originally available on Atom, and should support all interactions with APM, PPM the Atom application, the Pulsar application, and any other unknown 3rd party services that integrated with the backend. Essentially it should look like nothing has changed."
https://github.com/pulsar-edit/package-backend/releases/tag/...
So that's progress.
https://github.com/pulsar-edit/package-backend/releases/tag/...
So that's progress.
If you're on Linux, I recommend Geany as an alternative (also has autosave, etc.). Also my favorite IDE at the moment.
For those looking for a good substitute, I've switched to Sublime Text and so far I've gotten it to pretty much a near-perfect replica of the original. Kind of surprising to me how much of the Atom UI was built to mimic the Sublime interface.
I also tried VSCode, but was never really quite able to get into the interface the same way. For a while I tried customizing the interface with plugins like CustomizeUI, but Microsoft broke those recently, and I've been happier with Sublime.
I also tried VSCode, but was never really quite able to get into the interface the same way. For a while I tried customizing the interface with plugins like CustomizeUI, but Microsoft broke those recently, and I've been happier with Sublime.
> was never really quite able to get the [VS Code] interface the same way
You're at least the 3rd person I've seen make that observation in this thread. I don't get how VS Code made this so hard, isn't it fundamentally built on a fork of Atom's core? The CSS and JS customization seemed more capable and accessible in Atom somehow.
I've heard only good things about the Sublime Text UX for literally a decade or more, but is it "hackable" in the way that Atom and VS Code are? Emacs-like hack-ability with less esoteric scripting (and a better UX out-of-the-box) is exactly what attracted me to Atom in the first place.
You're at least the 3rd person I've seen make that observation in this thread. I don't get how VS Code made this so hard, isn't it fundamentally built on a fork of Atom's core? The CSS and JS customization seemed more capable and accessible in Atom somehow.
I've heard only good things about the Sublime Text UX for literally a decade or more, but is it "hackable" in the way that Atom and VS Code are? Emacs-like hack-ability with less esoteric scripting (and a better UX out-of-the-box) is exactly what attracted me to Atom in the first place.
Atom extensions are like script tags added to the page, while VS Code runs all extensions in a single separate process and gives them a limited API.
That means that in VS Code actions like "right click to open context menu" or "type in Command Palette to filter commands" are instantaneous regardless of your extensions, as no extension code gets run. But extensions can't change the layout of the editor, or really do anything not exposed by the API.
If you want hack-ability there is an extension - https://marketplace.visualstudio.com/items?itemName=betterth...
That means that in VS Code actions like "right click to open context menu" or "type in Command Palette to filter commands" are instantaneous regardless of your extensions, as no extension code gets run. But extensions can't change the layout of the editor, or really do anything not exposed by the API.
If you want hack-ability there is an extension - https://marketplace.visualstudio.com/items?itemName=betterth...
> I've heard only good things about the Sublime Text UX for literally a decade or more, but is it "hackable" in the way that Atom and VS Code are?
The vast majority of the UI uses a custom GUI toolkit and doesn't have any API, though you can theme it. There's a few things that are extensible in limited ways: the command palette, text phantoms, input boxes, html sheets, etc. So no it's not generally hackable.
The vast majority of the UI uses a custom GUI toolkit and doesn't have any API, though you can theme it. There's a few things that are extensible in limited ways: the command palette, text phantoms, input boxes, html sheets, etc. So no it's not generally hackable.
> isn't it fundamentally built on a fork of Atom's core?
No. AFAIK the only thing common to them is Electron.
No. AFAIK the only thing common to them is Electron.
Sublime is great! Ultra fast. I feel like VSCode will be as sluggish as Visual Studio eventually.
It is so noticeable how different they are in speed. I’ve worked in Sublime for many years now (and continue to for most projects) but will switch to VSCode whenever I want to hack on some Go, since the LSP stuff works so well there. I constantly find myself messing things up due to input latency.
I was a noob when Atom was new and I remember thinking it was unusably slow. Took a minute to realize that I had loaded my entire computer's directory, not just the project I was working on.
That's because it was (and is) slow compared to true compiled applications. Just because VSCode has about 1000 tortured dev's making it usable doesn't mean its not fundamentally flawed on its face using a scripting language for text editing.
https://medium.com/commitlog/electron-is-cancer-b066108e6c32
Spread the TRUTH - praise be compiled programs...
https://medium.com/commitlog/electron-is-cancer-b066108e6c32
Spread the TRUTH - praise be compiled programs...
You can compile web tech to V8 bytecode and run it in Electron – how do you feel about compiled programs now?
THERE IS NO GOD. I only program in Ada to keep my sanity 0.0
Indeed. I wonder if someone will write a text editor in Flutter so that we have cross platform support but also natively compiled code.
It's been a while when I've used VS code in production but on Linux the issues with Atom have been less from the very start and VS Code simply never delivered the performance increase everyone was talking about. Maybe because I never made it an IDE but used it as editor.
On Linux Atom simply was the "better" choice for a long time.
On Linux Atom simply was the "better" choice for a long time.
Having used Atom and VS Code on an old laptop in college, VS Code definitely does a better job when you throw it a large file, a first-gen i5, and 4GB of RAM. Likewise, at my first internship, I tried sublime on my work computer, which they had clearly just grabbed from the storage room (Windows 7! In 2018!). Sublime exploded into a million pieces.
My point is this: if we're being honest, all Electron-based editors suck. They're slow, and community-provided extensions are buggy and they integrate awkwardly with each other. But in my world (embedded firmware) there simply isn't a less-terrible option. VS Code is the least-terrible among them.
My point is this: if we're being honest, all Electron-based editors suck. They're slow, and community-provided extensions are buggy and they integrate awkwardly with each other. But in my world (embedded firmware) there simply isn't a less-terrible option. VS Code is the least-terrible among them.
I honestly don't get that use case, I don't open large files in a text editor usually. But I agree that atom sucks in that degree.
Maybe slow never was the problem is kinda what my point is. In the end it's just an editor for text.
Maybe slow never was the problem is kinda what my point is. In the end it's just an editor for text.
I like to reverse-engineer web APIs (working on the NBA's stats API right now) and sometimes I have to open/autoformat JSON files with 500k+ lines.
As a firmware engineer, it's also frequently useful to be able to do hexdumps of large binary files in VS Code.
As a firmware engineer, it's also frequently useful to be able to do hexdumps of large binary files in VS Code.
By looking at the other comments, I see the seemingly unavoidable discussion over which is the best text editor/IDE. My opinion on the matter is the following: the best text editor/IDE(/many other tools) doesn't exist. What exists is the best tool for you. Each one of us has it's own opinion based on its personal experience, and it's baked by arguments that stem out of what we find most important in those tools. The problem arises when, after picking what is the best tool for me, I forget about the last two words and it becomes the best tool. Each one of us is the most productive when it's using its own favorite tool, but it doesn't mean that if I convince someone else to switch to my preferred tool, then that person will be more productive. Each one of us has to see for him/herself which tool suits him/her best. It is fine if we suggest other people to try our tools for some reasons, but it makes little to no sense to argue that our favorite tool is objectively the best one.
I tried Atom a few years ago and was impressed by the features, but it was such a resource hog that I ditched it immediately. As someone with web development experience amounting to zero, it seems strange to me that nobody is asking about the feasibility of porting it to less resource hungry Electron alternatives (Tauri? Neutralino? ...?). Tauri has made the front page lately and everyone praises it for being a much lighter alternative to Electron, so using it would seem the natural step, or am I missing something?
I'm not a huge fan of Microsoft, but they hired Erich Gamma and that was a brilliant move. He is an engineer I have tremendous respect for, with obvious vision. He was key in VisualAge for Java, which was a Java IDE, written in Smalltalk, which supported refactoring down to the smallest level (including file operations). He was obviously a key designer for VSCode. From its earliest days, I could see how they were sketching in facilities for advanced features in an open way, and it has maintained its development well.
I didn’t quite understand the loss of Atom until I authored https://ghuntley.com/fracture about VSCode. Now I deeply care about ensuring programming languages do not outsource their LSP development to Microsoft and enable them to capture the ecosystem as is happening in python.
Thanks for the article.
VSCode is dead to me. I don't want to use development tools which allow a corporation to constantly inject it's agenda into my work.
VSCode is dead to me. I don't want to use development tools which allow a corporation to constantly inject it's agenda into my work.
I've moved to VS Code (or rather Codium, the OSS build of Code) long time ago, but still keep the Atom keybindings and icons (both available in the extension gallery). RIP.
Never got into Atom because Sublime Text was so perfect (I was a textmate user).
I'm also sad to see it go, but I have high hopes for Lapce
https://lapce.dev
https://github.com/lapce/lapce
https://lapce.dev
https://github.com/lapce/lapce
Dear Atom, thanks for everything!
This made me think of Brackets [0] made by Adobe. Which hasn't seen new commits in the past 4 months[1].
They seem to have spun-off a new project "Phoenix Code Editor" [2].
[0] https://brackets.io
[1] https://github.com/brackets-cont/brackets
[2] https://github.com/phcode-dev/phoenix
They seem to have spun-off a new project "Phoenix Code Editor" [2].
[0] https://brackets.io
[1] https://github.com/brackets-cont/brackets
[2] https://github.com/phcode-dev/phoenix
https://old.reddit.com/r/AMA/comments/8pc8mf/im_nat_friedman...
> I’m Nat Friedman, future CEO of GitHub. AMA.
> Atom is a fantastic editor with a healthy community, adoring fans, excellent design, and a promising foray into real-time collaboration. At Microsoft, we already use every editor from Atom to VS Code to Sublime to Vim, and we want developers to use any editor they prefer with GitHub.
> So we will continue to develop and support both Atom and VS Code going forward.
> So, I love the years of collaboration between Microsoft and GitHub that have produced these two beloved editors, and I expect this fruitful relationship to continue!
And... no you won't. You make decisions that weren't your's to make.
> I’m Nat Friedman, future CEO of GitHub. AMA.
> Atom is a fantastic editor with a healthy community, adoring fans, excellent design, and a promising foray into real-time collaboration. At Microsoft, we already use every editor from Atom to VS Code to Sublime to Vim, and we want developers to use any editor they prefer with GitHub.
> So we will continue to develop and support both Atom and VS Code going forward.
> So, I love the years of collaboration between Microsoft and GitHub that have produced these two beloved editors, and I expect this fruitful relationship to continue!
And... no you won't. You make decisions that weren't your's to make.
I was at MS more than a decade ago, and I can attest that nobody cared what editor you used and there were people using everything.
Of course there were many problems at MS, but lack of religiosity about text editors was a bright point of their culture.
Of course there were many problems at MS, but lack of religiosity about text editors was a bright point of their culture.
The former Atom team and some new friends are building a new editor over at https://zed.dev. We're using our own Rust-based UI framework instead of Electron so it's really fast, and real-time collaboration is baked into the core.
Can someone tell me why OSes can't do what browsers do? It seems to me that browsers are the OS of today so why not just skip the middleman and make it first class? It seems to be a layer that exists solely because the 3 competing OSes is incompatible and browsers just happen to be compatible (for how long?).
Not everyone prefers browsers, especially these days when they are consolidating into one engine. Especially with text editors where you will be dealing with local files, a browser based editor won't work well.
Do you mean like ChromeOS?
Electron isn't popular just because it's cross-platform, but I think that is a big reason. The only other realistic option is Qt and that's looking increasingly dated.
Electron isn't popular just because it's cross-platform, but I think that is a big reason. The only other realistic option is Qt and that's looking increasingly dated.
nothing these days is really stopping you from making a cross platform native gui app, like with Qt, wxWidgets or similar. The only reason you wouldnt do it is because a lack of skilled programmers, and/or time.
Ive built quick little apps in Qt or wxWidgets for my wife, they use a few MB at most, they don't use any cpu unless you click on them (because naturally, theyre suspended), and the code bases are incredibly concise.
It really is, as gen z would say, a skill issue.
Or, said the other way around: Its simple and easy to use, and as a tradeoff you get no performance.
Ive built quick little apps in Qt or wxWidgets for my wife, they use a few MB at most, they don't use any cpu unless you click on them (because naturally, theyre suspended), and the code bases are incredibly concise.
It really is, as gen z would say, a skill issue.
Or, said the other way around: Its simple and easy to use, and as a tradeoff you get no performance.
No, what I mean is that our browsers are becoming OSes. So why don't OSes become more like browsers? The way it works now is that each of my tabs have their own VM (tabs) that runs on another VM (browsers) which itself runs on another VM (OS). Why can't tabs just be processes that run directly on the OS (with all its security features).
Every time I see any problems/advancements in browsers, I squint my eyes and they look exactly like an OS problems/advancements.
Every time I see any problems/advancements in browsers, I squint my eyes and they look exactly like an OS problems/advancements.
Do you even know what an OS is? How can you ask this question? Who will communicate with the hardware?
The kernel is just a bunch of code. What prevents the browsers from implementing all the capabilities of the kernel? Why can't my computer boots into a browser directly and it then figures out how to talk and manage the hardware directly.
The way I see it, OSes of today is simply an implementation detail of the browser. 99% of the world won't even care or notice f Windows 12 is is shipped as a Ubuntu distro with familiar UIs. Heck, not even most developers will I think.
I have this thought when I ponder on the fact that most programming languages of today assumes a virtual machine of one kind or another. But...the OS is already a virtual machine (of the yesteryear I suppose). The only reason we don't have yet another level of virtual machine inside our browsers is that most browsers are almost fully compatible. Even each browsers starts having diverging APIs then its only a matter of time before someone creates an OS on top of browsers.
The way I see it, OSes of today is simply an implementation detail of the browser. 99% of the world won't even care or notice f Windows 12 is is shipped as a Ubuntu distro with familiar UIs. Heck, not even most developers will I think.
I have this thought when I ponder on the fact that most programming languages of today assumes a virtual machine of one kind or another. But...the OS is already a virtual machine (of the yesteryear I suppose). The only reason we don't have yet another level of virtual machine inside our browsers is that most browsers are almost fully compatible. Even each browsers starts having diverging APIs then its only a matter of time before someone creates an OS on top of browsers.
The thing I remember most about Atom is the privacy issues that it had - first of the text editors that sent telemetry by default.
https://en.wikipedia.org/wiki/Atom_(text_editor)#Privacy
https://en.wikipedia.org/wiki/Atom_(text_editor)#Privacy
Very sad. I'll continue to use it. I can't abide how vscode is run as a project by Microsoft.
What's wrong with how Microsoft runs the VS Code project?
If you spend time in their issues, or try to contribute via issues, a pattern emerges; Microsoft as a corp entity has an iron grip on the development and progress. It's open source only in that you can fork freely. UX and DX improvements are routinely shut down by MS employees, MS employees have a deep, deep sense of ownership and tend to respond defensively, repo maintainers are exclusively MS employees (I'm welcome to be wrong here, I couldn't find any that weren't), platitudes are common responses to issues for legitimate improvement, any comparison to Atom or any other editor is summarily shut down after "good faith" discussion, and development and improvements are beholden to the Microsoft development and release cycle.
Now I'll admit I'm fairly cynical wrt VS Code and have a negative view of the team that runs and owns VS Code, and by extension VS Code itself as a product due to the myriad of Microsoft-esc UX and DX forced upon the user. There's a great product in there but Microsoft is a horrible steward.
Now I'll admit I'm fairly cynical wrt VS Code and have a negative view of the team that runs and owns VS Code, and by extension VS Code itself as a product due to the myriad of Microsoft-esc UX and DX forced upon the user. There's a great product in there but Microsoft is a horrible steward.
Biggest issue is the closed source licensing of many of the most popular extensions. Pylance, C# (future), Remote Extensions, etc. In addition, the VSCode marketplace is only licensed for use with the closed source distribution of Visual Studio Code, hence openvsx.org.
https://ghuntley.com/fracture/
https://ghuntley.com/fracture/
RIP Atom. It was a great few years using it before switching back to Coda > Nova a while ago after the GitHub acquisition when it became clear development was no longer a priority.
Sometimes products reach a natural end of life, but it also highlights the importance of supporting open source.
Sometimes products reach a natural end of life, but it also highlights the importance of supporting open source.
Here's a few ways to make VSCode (or VSCodium) look and feel a little like Atom:
https://medium.com/@samuells/how-i-moved-from-atom-to-vs-cod...
https://medium.com/@samuells/how-i-moved-from-atom-to-vs-cod...
Rest In Peace. The Atom devs did an amazing job, but failed to get enough market share. I used Atom a lot at home, and some at work. Work jumped on VS Code as soon as VS Code came out. I think in part it was the ease of use, but I also think a major factor was that it came from Microsoft, so work immediately accepted it as better than something from people managers didn't recognize.
If VS Code didn't have MS funding them and marketing them, then I think the outcome would have been much different. Maybe. The Atom devs did make some design choices that seemed weird. As one commenter noted, Coffeescript is a good example. I personally liked the extreme customizability and plugin ecosystem.
If VS Code didn't have MS funding them and marketing them, then I think the outcome would have been much different. Maybe. The Atom devs did make some design choices that seemed weird. As one commenter noted, Coffeescript is a good example. I personally liked the extreme customizability and plugin ecosystem.
Brackets and Atom were two of the most influential developer tools in my life. Former made me fall in love with the web and the latter allowed me to ship some of my most impactful projects whilst I was in college. I don't think I'd have managed to finish, let alone start writing them had Atom and its amazing marketplace of extensions not been present. Sure, it was slow as hell on my modest Toshiba laptop but I still loved it. And no denying how it paved way for even bigger projects like the Electron framework and Visual Studio Code.
I will cherish those fond memories. Thanks a lot to all the individuals who contributed to Atom and its ecosystem—take a bow!
I will cherish those fond memories. Thanks a lot to all the individuals who contributed to Atom and its ecosystem—take a bow!
Seems like the Microsoft ways of embrace, extend & extinguish sre still alive and well.
What did they extend this time?
Atom was the slippery slope, the shiny new thing, the tailwind that pushed thousands of us into deeper and more varied programming passions. The amity and enmity of using the thing will be spoken of with some fondness for decades, I think.
Sad to see, Atom has been my go to editor for the last years. What would you recommend as alternative for the average Ruby / Rails developer? I am looking at Panic Nova, VSCode, Sublime Text and others.
Take a look at Jetbrains‘ RubyMine. It takes development to a new level; You won’t want to go back. It understands your code so well, it’s magical. It can rename stuff anywhere it’s referenced, for example, which is way superior to search/replace in a directory (because you won’t replace unrelated items). It has a Sequelace built in, but with support for practically any database. It can perform debugging inside the editor. It has support for all relevant tooling. It handles deployment. And more.
Not related, just a fan :)
Not related, just a fan :)
Definitely VSCode, with some Ruby and Rails extensions and a hefty usage of Copilot too.
I used atom for years, it was such a nice UX especially compared to vscode.
Unfortunately it was slow when I loaded it up with plugins.
I moved on to vscode first, hated it, then back to vim, then to neovim, and now finally to helix.
Unfortunately it was slow when I loaded it up with plugins.
I moved on to vscode first, hated it, then back to vim, then to neovim, and now finally to helix.
Brief comment + total noob question here:
I've been using atom for several years now to main a few sites. I have always found it a pleasure to work in, but then admittedly I am probably using a small percentage of the features that it offer.
What does it mean that the project (or any project) is archived? Does it mean that it no longer has maintainers? Should we stop using it because security will worsen due to lack of updates?
If I should stop using it - what should I try instead (apart from Vi / Emacs / VS Code, which are already well represented in the discussion)?
Thanks
I've been using atom for several years now to main a few sites. I have always found it a pleasure to work in, but then admittedly I am probably using a small percentage of the features that it offer.
What does it mean that the project (or any project) is archived? Does it mean that it no longer has maintainers? Should we stop using it because security will worsen due to lack of updates?
If I should stop using it - what should I try instead (apart from Vi / Emacs / VS Code, which are already well represented in the discussion)?
Thanks
I know you've said not to discuss VS Code, but VS Code was pretty much an Atom clone at release, and it would still be a very easy switch. Many of us back then loved Atom and switched simply because VS Code was so similar but could also do a find-and-replace on a large project without crashing.
Thanks for that will give VS Code a spin
Are you on Windows? Notepad++ in case
Mostly Debian at home - thanks for reminding me though - I do use Notepad++ at work. I believe it's available as a snap on Linux. I do enjoy the simplicity of N++.
Heh, just a month ago Adobe Brackets (another Atom clone) did the same https://github.com/adobe/brackets
Huh, I’d forgotten about this. Makes me think of Onivim 2 running out of steam. Have we just gone through an era-ending moment with text editors with VS-code coming out on top along with a few old survivors (vim, eMacs and sublime come to mind)?
I remember using Atom back in high school, sad to see it go. It was fun while it lasted. Now primarily using VSCode, I'm curious what the next best IDE will be.
I loved Atom. Before that it was, oof, Notepad++ or Bloodshed Dev C++ or Code::Blocks. I can't remember what editor I used at work in 2014...
Huge thank you to Atom for birthing VS Code!
To this day Atom is the only editor I've written an extension for, because they made it so easy and accessible.
To this day Atom is the only editor I've written an extension for, because they made it so easy and accessible.
Atom and XUL were the children of 00s pre-occupation with complete extensability in a package. Think Foobar2000 might be the last app standing.
It can still be revived, they're still solid platforms - just too hard for people to work with.
Took me some good few seconds to realize that it's not about the slightly better RSS - and I have used Atom-the-editor in the past.
VSCode might be better feature-wise than Atom but I'd choose Atom any time of the day over VSCode if it was still maintained. Just considering CVEs popping up every now and then. Also I found the UX getting slightly less in the way. Otherwise Sublime is my go to "normal" editor but it's not really free...
RIP, fav text tool by far. Personally, jetbrains outshines most when working on actual code; sublime for small work, and bbedit for virtual copy/paste formating.
edit: thanks M$ for messing up another beloved solution.
edit: thanks M$ for messing up another beloved solution.
I really hope that Visual Studio Code at least ports the Markdown Preview Plus extension, which was amazing:
https://github.com/atom-community/markdown-preview-plus
Unfortunately, VS Code extensions are often poor quality.
https://github.com/atom-community/markdown-preview-plus
Unfortunately, VS Code extensions are often poor quality.
I had a lot of fun whipping up plug-ins within minutes for Atom! It let me try out ideas very quickly.
emacs may probably let you do this too, and better. The big problem is: You need to know emacs beforehand, which is seriously a lot, and likely bizarre to any modern person. I do, and I will likely never give it up, but I've been at it since the 90s.
In my mind, emacs suffers the same problem as TeX/LaTeX. Some parts of it are very antiquated and just don't fit into the modern world anymore. They'd need an overhaul.
But, that overhaul is hard to impossible to do without losing compatibility. And that compatibility is why you simply cannot replace emacs or LaTeX: There is many decades of features, packages, and whole ecosystems in there. Throwing that away would be a giant loss, people will always continue using it. Other editors can't catch up. Maybe if they survive for ~50 years, too?
Just to drive home how old emacs is: At one point, the popular joke was that emacs stands for "eight megabytes and constantly swapping". Yep, 8MB large software was so bloated that it was funny and debilitating.
In my mind, emacs suffers the same problem as TeX/LaTeX. Some parts of it are very antiquated and just don't fit into the modern world anymore. They'd need an overhaul.
But, that overhaul is hard to impossible to do without losing compatibility. And that compatibility is why you simply cannot replace emacs or LaTeX: There is many decades of features, packages, and whole ecosystems in there. Throwing that away would be a giant loss, people will always continue using it. Other editors can't catch up. Maybe if they survive for ~50 years, too?
Just to drive home how old emacs is: At one point, the popular joke was that emacs stands for "eight megabytes and constantly swapping". Yep, 8MB large software was so bloated that it was funny and debilitating.
They (whoever they are) would be well-served to move to emacs, and stay there forever. I don't know which "antiquated" thing you're referring to, specifically, but it all works quite well. Both back in the day and today.
How often do you have emacs hanging because TRAMP is completing some network operation, for example? I’m a big emacs fan, have been using it since the 90s, and will likely never move away. But there’s no reason to pretend that it doesn’t have warts.
Then the joke evolved to that it couldn't open files 8MB or larger without hanging, at one point.
Yeah. I did feel the original joke, though. There's a reason why emacs had this weird "unexec" bootstrap during building that would run emacs, compile all its lisp, and just dump all its memory back onto disk to be the actual executable.
My first Linux PC had 8MB RAM, long long after emacs became a thing. If emacs' resident set came even close to half of that or so, "constantly swapping" would have been reality.
My first Linux PC had 8MB RAM, long long after emacs became a thing. If emacs' resident set came even close to half of that or so, "constantly swapping" would have been reality.
Related:
Atom editor is not dead, but is now Pulsar (viva OSS) - https://news.ycombinator.com/item?id=33465854 - Nov 2022 (9 comments)
To Favor Microsoft VS Code, Microsoft's GitHub Is Killing GitHub's Atom Editor - https://news.ycombinator.com/item?id=31717196 - June 2022 (19 comments)
Ask HN: Why did Atom Text Editor failed? - https://news.ycombinator.com/item?id=30733674 - March 2022 (8 comments)
Atom: Editor window startup is slow - https://news.ycombinator.com/item?id=21740568 - Dec 2019 (11 comments)
Atom editor still phones home prior to consent dialog - https://news.ycombinator.com/item?id=21642391 - Nov 2019 (108 comments)
Ask HN: What Happened to GitHub's Atom? - https://news.ycombinator.com/item?id=21142934 - Oct 2019 (46 comments)
Future of GitHub's Atom Editor - https://news.ycombinator.com/item?id=17258419 - June 2018 (13 comments)
Sublime vs. Atom – who will win the editor's war? - https://news.ycombinator.com/item?id=11561865 - April 2016 (13 comments)
Atom text editor 1.7.0 released - https://news.ycombinator.com/item?id=11492203 - April 2016 (139 comments)
How to make the Atom editor transparent - https://news.ycombinator.com/item?id=10916760 - Jan 2016 (55 comments)
Atom text editor 1.4 released - https://news.ycombinator.com/item?id=10900355 - Jan 2016 (198 comments)
GitHub's Atom Switches from the Open Code of Conduct to the Contributor Convent - https://news.ycombinator.com/item?id=10043990 - Aug 2015 (57 comments)
Atom Editor for Sublime Text Users - https://news.ycombinator.com/item?id=9872614 - July 2015 (54 comments)
Atom now opens files larger than 2MB - https://news.ycombinator.com/item?id=9690653 - June 2015 (59 comments)
Ask HN: Why was Atom (text editor) written in JavaScript? - https://news.ycombinator.com/item?id=9257087 - March 2015 (6 comments)
“Implement text editor DOM updates manually instead of via React” - https://news.ycombinator.com/item?id=9117028 - Feb 2015 (220 comments)
Atom Editor or Sublime Text – which one to pick? - https://news.ycombinator.com/item?id=9008352 - Feb 2015 (65 comments)
Atom now using Io.js - https://news.ycombinator.com/item?id=8991853 - Feb 2015 (130 comments)
Sublime VS. Atom: Will GitHub's Text Editor Beat the Standing Champion? - https://news.ycombinator.com/item?id=8945685 - Jan 2015 (70 comments)
Atom Shell: Cross-platform desktop application shell - https://news.ycombinator.com/item?id=8793489 - Dec 2014 (59 comments)
Atom: Editor window startup is slow - https://news.ycombinator.com/item?id=8393648 - Oct 2014 (76 comments)
Ask HN: Are you using Atom Editor? - https://news.ycombinator.com/item?id=7547813 - April 2014 (16 comments)
Free invites to Atom, GitHub's new text editor - https://news.ycombinator.com/item?id=7376063 - March 2014 (170 comments)
Download Atom editor without an invite - https://news.ycombinator.com/item?id=7328592 - March 2014 (114 comments)
GitHub's new text editor leaked on Twitter - https://news.ycombinator.com/item?id=7302941 - Feb 2014 (249 comments)
Others?
Atom editor is not dead, but is now Pulsar (viva OSS) - https://news.ycombinator.com/item?id=33465854 - Nov 2022 (9 comments)
To Favor Microsoft VS Code, Microsoft's GitHub Is Killing GitHub's Atom Editor - https://news.ycombinator.com/item?id=31717196 - June 2022 (19 comments)
Ask HN: Why did Atom Text Editor failed? - https://news.ycombinator.com/item?id=30733674 - March 2022 (8 comments)
Atom: Editor window startup is slow - https://news.ycombinator.com/item?id=21740568 - Dec 2019 (11 comments)
Atom editor still phones home prior to consent dialog - https://news.ycombinator.com/item?id=21642391 - Nov 2019 (108 comments)
Ask HN: What Happened to GitHub's Atom? - https://news.ycombinator.com/item?id=21142934 - Oct 2019 (46 comments)
Future of GitHub's Atom Editor - https://news.ycombinator.com/item?id=17258419 - June 2018 (13 comments)
Sublime vs. Atom – who will win the editor's war? - https://news.ycombinator.com/item?id=11561865 - April 2016 (13 comments)
Atom text editor 1.7.0 released - https://news.ycombinator.com/item?id=11492203 - April 2016 (139 comments)
How to make the Atom editor transparent - https://news.ycombinator.com/item?id=10916760 - Jan 2016 (55 comments)
Atom text editor 1.4 released - https://news.ycombinator.com/item?id=10900355 - Jan 2016 (198 comments)
GitHub's Atom Switches from the Open Code of Conduct to the Contributor Convent - https://news.ycombinator.com/item?id=10043990 - Aug 2015 (57 comments)
Atom Editor for Sublime Text Users - https://news.ycombinator.com/item?id=9872614 - July 2015 (54 comments)
Atom now opens files larger than 2MB - https://news.ycombinator.com/item?id=9690653 - June 2015 (59 comments)
Ask HN: Why was Atom (text editor) written in JavaScript? - https://news.ycombinator.com/item?id=9257087 - March 2015 (6 comments)
“Implement text editor DOM updates manually instead of via React” - https://news.ycombinator.com/item?id=9117028 - Feb 2015 (220 comments)
Atom Editor or Sublime Text – which one to pick? - https://news.ycombinator.com/item?id=9008352 - Feb 2015 (65 comments)
Atom now using Io.js - https://news.ycombinator.com/item?id=8991853 - Feb 2015 (130 comments)
Sublime VS. Atom: Will GitHub's Text Editor Beat the Standing Champion? - https://news.ycombinator.com/item?id=8945685 - Jan 2015 (70 comments)
Atom Shell: Cross-platform desktop application shell - https://news.ycombinator.com/item?id=8793489 - Dec 2014 (59 comments)
Atom: Editor window startup is slow - https://news.ycombinator.com/item?id=8393648 - Oct 2014 (76 comments)
Ask HN: Are you using Atom Editor? - https://news.ycombinator.com/item?id=7547813 - April 2014 (16 comments)
Free invites to Atom, GitHub's new text editor - https://news.ycombinator.com/item?id=7376063 - March 2014 (170 comments)
Download Atom editor without an invite - https://news.ycombinator.com/item?id=7328592 - March 2014 (114 comments)
GitHub's new text editor leaked on Twitter - https://news.ycombinator.com/item?id=7302941 - Feb 2014 (249 comments)
Others?
True
If it was according to Hindu calendar you can perform the shraddha (https://en.wikipedia.org/wiki/%C5%9Ar%C4%81ddha) today for atom .
Wrote some NES map editors using Atom at one point. Was kind of a pain. I didn't use it much after that.
I don't use VSCode but it just feels like this started an era of Electron-based everything that slowly consumes all of our machine's resources.
I don't use VSCode but it just feels like this started an era of Electron-based everything that slowly consumes all of our machine's resources.
I'm still not convinced VSCode is faster and better. My Atom setup was never slow, the only thing that wasn't instantaneous was code completion. For me, it felt like VSCode came out of nowhere and surpassed Atom for inexplicable reasons.
I just uninstalled the app. I'll miss it.
What's the most popular replacement for a text editor with code support? VS Code? I was looking into Nova, but I'd assume an open-source editor would be updated more frequently and have more themes etc.
What's the most popular replacement for a text editor with code support? VS Code? I was looking into Nova, but I'd assume an open-source editor would be updated more frequently and have more themes etc.
I've been living with VS Code for the last year at work and it's nice, it feels less like an Electron app than Atom did. I still use Sublime Text at home (and for pesky column edit and other tricks I know in Sublime).
Nova is a nice update from Coda 2, but it lacks the plugin community to really shine unless it does everything you want today. I kept opening it up because I wanted to like it, but after a year I let my license lapse.
Nova is a nice update from Coda 2, but it lacks the plugin community to really shine unless it does everything you want today. I kept opening it up because I wanted to like it, but after a year I let my license lapse.
Atom was a success on all fronts. I'd be willing to wager than if you search for code editors for any kind of a front-end language, in the top 100 results (listicles, whatever) you'll find Atom mentioned in more than 50% of them.
Not even at his funeral can poor Atom be at rest, so many comments torturing or ignoring it while praising the killer.
I, for one, salute you dear Atom. You have been a worthy contribution to the community. Thanks you for all you have done.
RIP
I, for one, salute you dear Atom. You have been a worthy contribution to the community. Thanks you for all you have done.
RIP
Wow, that's so odd. I used Atom when I first started learning Java back in 2009, before switching to Eclipse and eventually IntelliJ. I don't think I ever expected that it'd be archived!
What can I say, I had this thing frequently crash with no warning, it did not lose data or anything, but it crashed at least 10 times a day, with 2 projects loaded into it.
Apart from that, was a great tool.
Apart from that, was a great tool.
I used it as a tuned Markdown editor and it was a blast. Had to switch to VSCode and depicts it's very fast, I don't like the experience.
Any good Markdown editor to recommend?
Any good Markdown editor to recommend?
Obsidian (https://obsidian.md/).
Not a professional programmer, just a weekend Python LARPer but Atom was my first. Held on until they made the announcement of it's imminent demise.
Sad to see it go
Sad to see it go
I use Atom daily. There are many times when I need a simple, powerful text editor but not a full blown IDE.
I knew this day was coming but didn’t prepare for it.
I knew this day was coming but didn’t prepare for it.
Moment of silence.
For the laptop fans…
Oh, no, those won't be silent when using anything electron
I haven’t heard the fan of my M1 laptop since this summer, and I have multiple electron apps almost always running.
Now, if I move the mouse a bit fast on my i9 laptop, it’s time for hairdryer mode.
I think the silence depends more on the hardware than the software.
Now, if I move the mouse a bit fast on my i9 laptop, it’s time for hairdryer mode.
I think the silence depends more on the hardware than the software.
That's the joke. Now that Atom is dead, laptop fans will be silent.
Only for a minute: enough time to
download and install VSCode
It lived as it died, in mediocrity
Such a shame.
Atom was (is?) great. The first editor extension I wrote was for it (in Coffeescript, no less. Terrible idea in hindsight).
Thanks for the good times.
Atom was (is?) great. The first editor extension I wrote was for it (in Coffeescript, no less. Terrible idea in hindsight).
Thanks for the good times.
Shame, Atom was an absolute game changer back in the day. Pathed the way for new text editors. Fond text editing memories!
Wow! Been a while since I heard that name. Atom was the cool kids editor back when I was a teenager, surprised to see it go!
Atom was my first editor when I started learning coding…still have the main shortcuts in muscle memory!
One dark is still my favorite theme
Damn! It's been a while since I heard about Atom. Sad this is happening!
Yes the last I heard was people wishing GitHub would do more with it (though I think those sorts of comments meant that the writing was on the wall).
I liked way more the UI of Atom than VSCode. I cannot stand VSCode UI.
I’m still using Atom, Postman, and PuTTY. Does that mean I’m old?
No, these are fairly recent tools.
Used to love Atom back in the day, thanks for everything team.
I also used Atom a fair bit but moved on to Sublime. RIP.
It was a really nice editor. I used it before VSC.
Presses "F" to pay respect
[deleted]
In the future, it will be studied as one of the slowest, worst performing software products mankind has produced.
now i will never know what purpose this software served
About damn time
cant wait for react.js to be archived
Why? And what's better?
I don't like any framework that uses templates. I already know JS, let me use that. Also they usually work poorly with editors and TypeScript since they require custom syntax to be supported. I'll stick with JSX.
I like JSX too, it allows multiple composable components in the same file, but Sveltekit support for typescript has been amazing so far, the whole framework has been written with typescript in mind and it shows.
That's good to hear. I also used to use Vue before switching to React, which has a similar layout, ie HTML, styles, and script tags in a single file component. It was alright but it had some weird rules, like registering plugins, two way data binding, etc.
Biggest thing though is the package support for Vue and other non-React libraries was miserable compared to React, so I switched and I definitely prefer it over any template-based framework.
Biggest thing though is the package support for Vue and other non-React libraries was miserable compared to React, so I switched and I definitely prefer it over any template-based framework.
I scrolled down and still saw and npm command. I just check out whenever I see NPM. I really should learn how to use that thing.
VirtualDOM is why.
vanilla.js is better
vanilla.js is better
Have fun rewriting your own ad hoc, informally-specified, bug-ridden, slow implementation of half of ̶C̶o̶m̶m̶o̶n̶ ̶L̶i̶s̶p̶ React.
that's the "problem" tho — i dont need that level of abstraction, i already know how to assign event listeners and toggle css classes, which covers 99% or real-life needs
For small projects, sure. But it breaks down in larger ones, ask me how I know. The reality is React and other tools solve problems at scale, plus they're genuinely nice to develop in, while vanilla JS simply is not.
So sad :(
[deleted]
goodbye my old friend
[deleted]
[deleted]
Anything built on elecyron should be archived asap
[deleted]
The Atom developers made some technology choices that in retrospect were ill-advised, CoffeeScript being the worst of them and splitting everything into dozens of packages a close second. They tried to backpedal on both of these later on, but by that time VSCode, with its far superior engineering built around TypeScript, was rapidly taking over.
Of course, the GitHub acquisition was the last straw, but to be fair Atom was already pretty dead by then.
While the Atom project ultimately failed, it did give us Electron and Tree-Sitter, two technologies that will certainly outlive it.