It's what kickstarted Electron which eventually gave us VSCode, Slack, and lots of HN comments about memory usage. It also had the sweetest default theme of any code editor. RIP.
Does anyone remember brackets? I cant remember if brackets or atom came first but I remember switching from sublime to brackets to atom. Good times, I heard DHH is still using TextMate.
I still use Textmate, think it's actually excellent these days and still updated a few times a year.
Spellcheck always works, nothing ever crashes and acts weird I run it for 10+ months without issue. VSCode on my PC the spell check is inconsistent and weird and on a long enough timeline it actually crashes the whole operating system if you leave it open.
I was in TextMate all day every day for a long, long time but gradually shifted to Emacs, hilariously, AFTER I quit coding for a living -- because of OrgMode.
I mean, I tried to become an emacs person several times when I was still coding, and it just never took. My last phase of programming work was on OS X, so I had friendlier yet still capable options like TextMate, which made shifting to emacs a pretty hard ask.
Then my job shifted to a point where my preferred method of tracking activites/tasks/notes was just falling apart. I was all-in on the GTD-inspired Omnifocus, but what I really wanted was a system where I could intermingle notes with Todo items, and then ask the system to collate a list of the Todos for me dynamically.
Which, as it turns out, is pretty much a description of how OrgMode works. And, sadly, almost nothing else that I've found, and so I use emacs all the time now.
My emacs expertise, though, is pretty limited to things I need to know to be productive with Org.
I worked on Brackets full time at Adobe. It came before Atom and had a bit of a different target (designers-who-code vs. developers in general). Brackets was great fun, but it too ultimately needed to be sunsetted.
Brackets was the foundation of Adobe Edge Code, which was part of Creative Cloud, so there were some bigger plans there.
Oh, that's a good point about the sunsetting. In Brackets's case, Adobe left it active in the hands of the community.
Live Preview in particular is one of the areas I had some fun working on. I worked out a way to do diff/patch to make it quickly and incrementally update the browser[1]
Brackets was cool and will always be in my memory; made a close friend (who we eventually hired to become a co-worker) because I mentioned that I was working on a Brackets extension on a Facebook group.
Electron is both an amazing enabling technology, and also an artifact of the sad state of affairs for computing platforms.
One could imagine a world where strong standards have been established which would allow you to easily deploy lean native applications across a wide variety of platforms.
Instead we ended up in this bizzare world where if you want to maintain a desktop GUI app, you either need a large team to support multiple platforms, or you need to target minified javascript of all things, and run your software on top of a large, arcane compatibility layer.
I still think of these inefficient things as being great multipliers of potential, even if wasteful.
FWIW: I'm probably one of the most "IT Conservative" people on this site, I still believe in sysadmins, dislike systemd, hate electron etc;
But there is something to be said about developer productivity: if you can build a prototype in 10 days when it would have taken 10 weeks that can be a huge differentiator between companies; it means you can make 6x more prototypes in the same time window, or work through different iterations of the same idea.
That's hugely beneficial.
I think if you treat inefficient things this way (I consider Ruby/Python in the same way) then we all benefit, test your ideas then go for gold on a more efficient platform.
Yeah but that's not the whole picture - it's not just FOSS choosing Electron so much as platform holders being hostile to cross-platform development.
For instance, if Apple had actually kept pace with OpenGL standards, and had embraced Vulkan, it would have been fairly straightforward to to build a native GUI framework which works across platforms.
Electron won because all the platform owners basically had to embrace the implementation of web standards on their platforms. So they couldn't prevent those tools from being used to deploy local software as well.
The absence of Vulkan on Apple platforms—something that it’s worth noting was developed after Apple’s Metal equivalent—is in absolutely no way even approaching a barrier to building a “native GUI framework”.
There literally are cross-platform native GUI frameworks. Even Electron itself is a third-party implementation of a GUI framework - it doesn’t use the platform’s web tech implementation and bundles its own.
It's just one example of an impediment. If all the major platforms used a consistent standards-based graphics API, you could have one implementation of the drawing layer shared between all platforms.
It wasn't FOSS that settled on Electron - it was businesses and corporations.
Decisions were taken with an eye to balance sheets and P&L reports; Electron remains the cheapest option of them all, because the supply of moderately-skilled HTML/JS labor is naturally larger than for any other language - all thanks to choices the Netscape Corporation made in 1995, when they needed interactivity in their product and they needed it quick.
Electron clearly means that we end up with a bunch of apps that would be otherwise unavailable, while at the same time meaning that we have a bunch of embarrassingly bad GUI experiences from companies who can afford to deliver better.
I feel that we were well on our way to a cross-platform, web-based future before mobile smartphones arrived around 2007. Also CSS and frameworks like Angular and React really derailed browser progress because they convinced everyone to use recycler views by hand instead of just making tables and the DOM itself more performant and memory-efficient in the browser itself.
I may be wrong in the moment, but I base my arguments on trends. Processing power, storage costs and bandwidth are always improving. So human productivity should always take priority over efficiency as time progresses.
I'd vote for a real Web 3.0 based on first principles like declarative and data-driven programming, idempotence, immutability, one-shot scripting (perhaps even a Turing-INcomplete DSL) for initial render without side effects (like CSS variables but for HTML), dynamic element loading with something like HTMX, secure server-side includes, distributed databases using Paxos/Raft, even distributed computing with a real Docker that provides an actual secure sandbox and repeatable builds of untrusted secure/private code (maybe with something like homomorphic encryption). I can go on and on about what real (not phantom) tech looks like. And it looks nothing like SPAs.
Also I think a lot of people recognize the need for this stuff, so ideas aren't the problem. The problem is, always has been, and always will be funding. In fact, my single greatest disappointment about the modern web is that stuff like advertising and eBay got coopted so there was never a viable way to make enough residual income to live on after the Dot Bomb around 2000/2001. The closest things we have are Uber and donating plasma. So we have a generation of highly-effective programmers spending the most productive years of their lives at a day job making rent, which is why rent increases. Hustling without understanding that the hustle itself is the failure when viewed through this lens.
Blah I dunno why I write this obvious stuff anymore. It just ain't never gonna happen. It may as well be impossible. Or I should say, it may take another 20 years to get here, and I just don't think we have that long anymore.
> there was never a viable way to make enough residual income to live on after the Dot Bomb around 2000/2001
Disagree with this. As a dev you have a huge advantage in that you can bootstrap a Saas or similar business cheaply. With the tooling and services available today you can launch quicker than ever before
If you can get a semblance of product market fit you can generate enough income to live off of. It’s not easy but it’s definitely possible.
> One could imagine a world where strong standards have been established which would allow you to easily deploy lean native applications across a wide variety of platforms.
Here is a unified binary format that can run on Linux, MacOS, Windows, FreeBSD, OpenBSD, and NetBSD too. They also boot from the BIOS.
huh I would think there is no measurable difference there.
However I honestly have no idea how much time does JS parser spends on what exactly. Are longer variable names and less tabs that big of a deal? It’s all in memory anyway, no… the lexer or tokenizer or whatever (…I never finished my compiler course…) just goes through that
Without nonlinearities like optimization/type checking/etc, the runtime is basically just the time to loop through the bytes. Make the input a quarter the size and you have a quarter the bytes to loop through. College classes will say “oh it’s all O(N) anyways, no big deal”. Industry on the other hand says “why make tens of millions of people wait 4 seconds for this to start when we could make them wait 1 second just as easily”.
The product’s source maps are publicly available in a way the debugger understands and the original code is freely accessible so there’s no real downside.
Minification also does some tree-shaking, which results in unused branches and libraries being pruned ( and therefore not needing to be loaded into memory ) and a smaller source size. Some constants can be inlined, which leads to faster execution times as there is no need to wait for a variable to be bound as its value is just written directly into the source everywhere it appears.
Yes. But in reality it was more "write once, debug everywhere". It was actually quite a nice concept, but the resulting UIs were inevitably clumsy and had that distinctive (ugly to me) look, no matter what the platform promised. If it doesn't look good out of the box, it won't look good later either.
Agreed. I know Electron isn't ideal, but as a Linux user, I have a pretty hard time complaining. In the pre-electron world, something like Slack for linux either wouldn't exist, or would be several versions behind other platforms and have some goofy UI that didn't match the rest of your desktop. At least we have it and it works.
This so much. I'm not fan of electron apps, but it's 1000x better to accept the chromium memory usage than a Windows VM memory usage. And I think that sharing the code between web and desktop also gives us very usable web apps (at least in case of Slack).
Not a very good one then, and never heard of any of those. The big ones like Slack do run in a browser because the whole point is to access an online service.
I completely agree, I'd rather have a memory hungry app than no Linux version at all. Slack is an odd one because you can run it in a browser, but things like 1Password are also good examples. I'd rather buy more ram than have companies pretend Linux just doesn't exist at all, at least it gives me options.
I'm wondering how viable a for-profit electron replacement (with native support) would be? Like Unity (similar business model), but exclusively thought for apps.
There's a bunch of Electron powered apps that feel really snappy, definitely faster and snappier than some default apps Apple ships on macOS these days.
I end up with vim bindings in VSCode at the present. It doesn't do everything but it does most things I want. There is neovim integration, but last time I tried it there were a bunch of glitchy things that didn't work right (I remember selection being buggy but I can't remember the specifics). Maybe I'll have to give it another whirl.
If you're retaining vim on your workstation for quick editing of files, I'd encourage you to keep an eye on the Helix editor. https://helix-editor.com/
There are three nice things about it: it flips vim's <verb><motion> into a <motion><verb> (like kakoune); it's got tree-sitter support out of the box (including for navigation); it's got LSP support out of the box.
Its keybinding is perhaps in "uncanny valley" of vim's. Overall, it still feels well thought out.
Yep. I am waiting for its plugin support to come out to start really using it but I have it installed and I use it from time to time. It is pretty nice!
Honestly? Emacs. Gonna be around for at least as long as RMS is still alive. I'd accept Vim as a runner-up; I'm conversant in it and can see where people might prefer it (though honestly, those people should probably enable evil-mode in emacs).
But realistically? A significant majority of developers use Visual Studio Code; Atom is still only being used by absolute diehards. Visual Studio Code's complete supplantation of Atom (with which it competes for resources in the same organization) is why we're having this discussion.
I used to say that investing some time in becoming proficient with Emacs (the One True Editor!) or vim will deliver returns over a lifetime-spanning career. But Visual Studio Code has already joined them and it is a pretty sensible editor platform to learn.
Also totally subject for discussion: I suspect VS Code will see more innovation in years to come.
RMS hadn't been involved with any technical contribution or project level decision making for a while. I would say people like Eli Zaretskii are far more important. While there is no shortage of people willing to hack on elisp, I get the feeling that people who can hack on the C core, and possessing deep knowledge of core subsystems is slowly dwindling.
But I do think Emacs will be fine. I don't think VSCode is an existential threat to Emacs in the same way Toyota is not a threat to Lamborghini. VSCode boasts impressive numbers, but it does so by consolidating in a target demography that was never a stronghold for Emacs to begin with - partly due to some level of indifference on its part. On the other hand, there are things Emacs is uniquely suited for, and for that reason it will continue to attract a particular type. I think in terms of absolute numbers Emacs userbase is still increasing, and I think falling numbers in terms of total percentage doesn't mean much for its survival.
Another Brackets user! There must be dozens of us!
I used Brackets too back then and tried Atom a few times but it was always too slow and laggy. I was so glad when VSCode came out and that it was actually good. I was in the midst of switching to VIM but it was just too much of a bother.
It's a very dumb reason to stick with an editor, but I have trouble going back to Sublime after VSCode despite preferring most things about Sublime, because I always forget how to manage packages using Sublime's command prompt and have to screw around with it for a while each time, while VSCode has a GUI for that so the memorization required is zero, and can easily browse available packages without bouncing out to a browser, and it often prompts me to install relevant plugins so it's just a matter of clicking "OK".
Every time I try to go back to Sublime, this annoys me right off the bat and I'm back in VSCode by the end of the day.
Sure, I find that every time I google for how to do it :-)
In VSCode, I can browse info about packages without having to remember a thing aside from "one of the six big icons on the left is 'Extensions'". One mouse click, start typing, click anything that looks like it might be good, get a ton of info and an "install" button. There are filters! So I can simply sort by "most popular" if I want, or by name, or a bunch of other things, all without having to remember anything for this somewhat-infrequent operation, because it's in the GUI.
It's mainly the integrated package exploration that's missing. And the auto-suggestion for plugins—in fact, I rarely have to do any of the above, and just click "OK" to whatever VSCode suggests, and everything's fine.
Sublime has (I just checked) a "package discovery" command, which... opens a web browser, to the exact same page you'd have ended on if you'd started by just googling it (which is what I do). So you have to find what you want on there, then go back to Sublime and find it again.
The result is that in the best case it takes me 1% as long to install what I need on VSCode (just click OK), and worst case it takes me perhaps 50% as long, compared with Sublime. I'm also way less likely to go poke around and see if there's anything that might be useful, in Sublime.
[EDIT] "Why aren't you way more familiar with the command palette?" ephemeral shells as anything more than dead-simple launchers make me really uncomfortable. I hate using them. Apple spotlight? I use it extensively—only for launching programs, period, nothing else. I'd much rather have a persistent shell environment I could attach from any terminal and leave open.
That's super fair. I'll admit I'm entirely in the same boat - if nothing happens on a new tool when I type Ctrl-Shift-P, I usually just shrug and go back to using all the other tools I have that do that.
I do love the fact that, with Sublime, that 75%+ of the time when I want to do something, say, pretty-print a JSON text document, it's just:
Ctl-Shift-P, "json" (Don't see anything obvious)
[hit backspace to clear json] "Install Package", "json"
See the "Pretty Print" option, install it in 2 seconds, and on my way.
A minor annoyance that happens often is actually a huge problem. I think we as engineers understate how important these little, often UX related issues really are because we understate how important UX is overall.
There are a couple credible alternatives that get a lot of maintenance (I use them both for 3+ hours a day):
If you are coding: Unless you are using IntelliJ (which a ton of of my colleagues do, and love) - it's a vscode world. Everyone at every company I've seen bangs away using that. It's kind of amazing how much inertia it's picked up (currently).
If you are working with text: 90% of the time if I have a couple gigabytes of text I need to do a lot of work with - it's Sublime Text. Actively Developed. A really solid text plugin architecture. The other 10% of the time I still use vim - mostly because it's in my finger DNA. Emacs is the obvious alternative which lots of smart people I know use.
I'd be interested in knowing if there are people who have used all five of these for > 100 hours that would recommend something else - (I haven't used Emacs that much - but I have well over a couple hundred hours on each of intelliJ/vscode/vim/Sublime. Probably close to 1000+ hours on the last three). (okay, small fib - close to 5,000+ hours on Sublime. I spend almost as much time in that tool as I do bash).
Isn't this for MacOS only? Sorry, [I just left Windows](https://www.scottrlarson.com/publications/publication-transi...) recently for it's anti-customer changes in Windows 11, Apple is way worse than Microsoft regarding its anti-choice position on all its products.
I've used many text editors back and forth and keep going back to Kate. It's what I use now. I'm not sure I'd say it's the best choice for everyone but it's what works for me the best it seems.
I’ve used Sublime Text for many many years now and it’s still my favorite text editor. I mainly use it for writing small reminders as well as Lua / LÖVE dev.
Sublime Text came pretty close to dying during the Sublime Text 2 years. I recall development slowed down substantially (it was a solo dev, IIRC), and it being pretty surprising when Sublime Text 3 came out.
It was only adderal driven developer crowd making mountain out of a mole because they felt uneasy their frigging text editor hadn't been updated every other week.
~10 years ago I was a Sublime 2 user surrounded by sad TextMate users—sad because TextMate had stagnated and was clearly on its way out and "everyone" had jumped to Sublime. When Atom was released, Sublime became the editor in decline.
It seemed to me that there would always be an endless cycle of boom and bust with editors. It was a cycle with more in common with fashion than craft, and I wondered if I might end up wasting an inordinate amount of time switching editors throughout my career without any upside. So rather than switch to Atom, only to switch again a few years later, I set about with adopting Vim.
The choice seems to have been correct as there will always be a new editor (that's more or less the same as the old editor) that catches hold, but I wanted stability. Vim gives me stability, and the only other editor I'd consider would be Emacs for similar reasons.
I don't think so, even if I use Atom as my primary editor there's a bunch of other great open source ones and even some non-OSS, and migration is trivial, so there's likely no need.
“Sunsetting” an open source project seems… unfitting? Hand it off to the community, look for new maintainers, donate it to the Apache Retirement Home for Veteran Projects, sure.
But saying that you’ve decided to “sunset” or “archive” it, telling users to plan for their migration, seems counter to the notion that open source software forms part of a commons - something that Github, of all companies, should understand.
Microsoft doesn't make money from VS Code. Atom was retired due to a lack of activity with the project. I've never even seen anyone use Atom, since the time it was released 8 years ago.
> We should be counting down the days till they sunset VS Code to focus on VS Code "Pro".
I don't think it would serve their interests, so I'm not worried about it, but who knows? This cynicism is directed towards Microsoft because they've earned it.
Had two coworkers at my last job use it when they needed to edit some of our legacy PHP stuff (we were mostly a .NET shop) but even they switched to VS Code eventually because the writing was on the wall for support.
Atom was developed before the acquisition. Which brings us to the second proud tradition of the tech titans, acquiring companies to end the products the acquirer doesn't like.
Probably a bit of both if I was to hazard a guess. MS has VS Code, which is definitely the elephant in the room as far as go to IDEs in the environments I’ve been in lately. So right now they’re spending engineering time on both VS Code and Atom, so they may as well focus their resources on the more popular one.
If you look at the contribution activity it dropped off after acquisition of GitHub by Microsoft and it seems that development was redirected to VSCode.
The writing was on the wall for a long while now, and was one of the reasons why the JuliaCommunity stopped advocating Juno/Atom as a platform and instead switched to VSCode
Well yeah, if you have two very similar products (editors/IDEs based on web technology), one of them much more successful than the other, putting a lot of effort into the less-used product sounds a bit hard to justify...
Look at the Atom repo, very few commits in the last year, and it's not like there are loads of open pull requests (serious PRs do get merged), and it's been strongly dropping off for a long time. It's the programming community that abandoned Atom, not Microsoft.
it was dead already, or at least, shown inferior to vscode in feature set. If anything you can accuse MS, it's using its market position and the VS brand name to "steal" adoption, but that completed before the aquisition too.
But Atom isn't, is it? It was started prior to Microsoft, to which Microsoft bought Github, and are now "sunsetting". While i don't think Atom was enough competition to actually warrant any real discussion here, the timeline seems quite fitting to EEE no?
I'd actually worry if the engineers I work with couldn't pick up a new IDE/text editor, etc. pretty easily and quickly, if and when something like this happens. And I'd say the risk of it happening in the next three to five years is pretty minimal at this point.
> I'd actually worry if the engineers I work with couldn't pick up a new IDE/text editor, etc. pretty easily and quickly
Once you start making full use of your editor, switching to a new one and reaching the same level of proficiency takes a long time. I can edit code even in notepad, but I can't ever be as fluid in it as my main editor. I've changed my editor multiple times and it's a huge pain every time.
While any software can be cancelled, I'd say Atom is being cancelled because of investment in VS Code (both currently owned by MS), I don't see any reason to think it's "inevitable" that VSCode will be cancelled, except in the sense that eventually everyone dies and the earth falls into the sun.
Despite the name, they have basically nothing in common. They don't share a user interface, they don't share plugins, they don't share hotkeys.
One of the main complaints many of the C# developers on my team have when they have to touch languages that aren't well supported by Visual Studio is that they don't know how to work VSCode.
I'm well aware of the differences between the two products, since I use both on a daily basis. My answer was a bit flippant, sure, but they are both IDEs developed by Microsoft and Visual Studio is definitely the "Pro" version of the two.
I know that perception of Microsoft will never go away in the open source community, and maybe it shouldn’t, although I’m not convinced Microsoft of 2022 is particularly worse (or particularly better) than most other companies operating simultaneously in open source and proprietary spaces.
The context of “embrace, extend and extinguish” has kind of been diffused over the years, though; it never meant “buy a product and kill it,” but rather meant adopting open standards and adding proprietary (not necessarily closed, which is not the same thing) extensions to them that end up becoming de facto standards, so your product is perceived as better at the task then the fully standards-compliant original. What happened with Visual Studio Code and Atom isn’t an example of this at all. For a start, they’re just two products that are competing in the same space; they’ve never had the same extension standards, so the idea of “embracing and extending” just isn’t relevant here.
Secondly, Microsoft obviously didn’t buy GitHub to shut Atom down. I’ve seen the arguments that once Microsoft did buy GitHub, Atom was doomed, but Code was already arguably more popular than Atom when Microsoft bought GitHub in 2018: Stack Overflow’s developer survey showed VSCode as far more popular among surveyed users (34.9% to Atom’s 18.9%). If those numbers had been reversed—if Code never made a real dent and Atom kept growing—then I have little doubt Atom would be the one continuing.
Lastly, I suspect the runaway popularity of Visual Studio Code is pretty good insurance against a hypothetical “Visual Studio Code Pro” replacing the existing VS Code. This would almost certainly cause a fork (or more than one!) to be created, and it’s highly likely such a fork would get immediate backing and support from one or more technology companies willing to pay for continued open source development.
However, I don’t think that’s likely, because I don’t think that’s how Microsoft is interested in monetizing Code. It’s not a source of income in and of itself. It doesn’t have to be. If it just so happens to have great GitHub integration, maybe your company will pay for GitHub enterprise features. If you’re used to using it, you may be more likely to pay for GitHub Codespaces. If it has a great story for deploying to Azure, then maybe you’ll be more likely to deploy to Azure. And so on.
> If it has a great story for deploying to Azure, then maybe you’ll be more likely to deploy to Azure
This. Microsoft share price depends on the size of their recurring revenue from cloud. They can easily write off a few million on VScode for bringing more users to Azure
No, they didn't buy GitHub to shut Atom down. But they did create VSCode to cut off GitHub's growing expansion of their business through Atom. They could have just extended Atom with Azure plugins etc, but instead they essentially forked it and poured tons of resources and hundreds of developers into it. That effort helped suppress the valuation of GitHub, so that they could buy it for cheaper (or at all?).
The revenue generating upsell for VSCode is already here and it IS GitHub Codespaces. They are going to add features you can't live without based off code synthesis (sky's really the limit here) and gate those off saying it can't run locally because it's too resource intensive. They'll charge you (or your company) by the second for all usage.
It would be much harder or impossible for them to do this if Atom and an independent GitHub had been further entrenching in this space for the last decade.
Many of the biggest developer tooling projects big corp are building now existentially threaten smaller developers and apps, by design.
I'd be willing to bet that even if Microsoft did create VSCode for the purposes of cutting Github's expansion, the effect that VSCode had on Github's valuation is extremely overstated here. The total valuation comes from a range of factors, but let's say there are two major ones: number of users and number of paying organizations. The latter is almost completely not dependent on Atom (companies would not use Atom as a deciding factor to use Github) and while some users might use Github because they used Atom first, I don't think that this is large enough that the migration from Atom to VSCode negatively impacted the valuation.
I think a simpler explanation is correct: Microsoft saw that open source developer tools are gaining a lot of popularity and also knew that it could help revitalize/modernize their image, so they authorized the funding for the creation of a (mostly) open source code editor, and it gained popularity because it was good.
I agree in principle, but I find it hard to imagine that there's enough interest to find someone who is willing to maintain the software and the package registry.
Speaking of packages - of the six featured packages I get offered on atom.io, only one had a release in the last two years, and half have been unchanged for half a decade. Atom's already dead.
A lack of releases could mean dead, but it could also mean finished. As in, complete: not in need of more features, and having no bugs of sufficient severity to bother fixing.
Finished is a state more software should aspire to reach. Sadly, with the advent of connectivity in everything, it's getting rare for even firmware to be finished.
Something as complex as a code editor will never be finished. There will always be new languages, new tooling, and better ways to edit.
Most real world problems have almost infinite demand for more and better software. The final text editor will be the one that reads the minds of the users and product manager and writes the code for you.
The code isn't being sunsetted, and anyone who wants to take it and keep working on it is free to do so.
But winding down the project is still a major event, and I think that it is appropriate to call that sunsetting. The existing project organization will go away. The team will presumably dissolve, with any people being paid to work on it going on to other things. I've seen this happen enough times to know that it is, indeed, an end of sorts. "The community" is almost never large and organized enough to keep a project like this vital. At best, they can only slow its descent into obscurity.
Correct me if I'm wrong, but most projects started by some form of organization end up being dead after handing them off to the community. That is, unless they make their code from the ground up to be as most readable and modular as possible.
I remember many projects made by Sun Microsystems that just died when Oracle took over, even if the code is still there.
I wouldn't really call Zulip a counter-example. It wasn't aband^H^H^H^H^H released to the community, it was spun off as a separate company. They offer paid products, have employees, an office in San Francisco, etc.
There are some things worse than death, like what MySQL experienced: being turned into a zombie designed to eat the brains and infect people who used to use it when it was truly free, all in the name of tricking people into switching to Oracle's expensive SQL server.
What? MySQL continues to work just fine. 8.0 (which was admittedly released two years ago) was the biggest release in ages in terms of new features and removal of things that should have been removed decades ago. Then there's MariaDB, which is named differently purely for copyright reasons and could be considered the 'real' MySQL (since its dev team are Monty and friends). I don't think MySQL came out of Sun's disintegration badly at all.
To be more precise: 8.0 finally has proper utf-8 out of the box, support for complex replication topologies (including multi-master), window functions, CTEs, etc.
MySQL has been and continues to be a major success for Oracle, and in 8.0+ and beyond the feature set, correctness, and performance have improved substantially; MySQL continues to evolve and currently is in a good spot. It is even more attractive in modern times thanks to systems like Vitess, which add major features (online schema change, excellent horizontal scaling) that give alternatives a run for their money. What are you even talking about?
>Dead database walking: MySQL's creator on why the future belongs to MariaDB
>MySQL's creator, Michael "Monty" Widenius, is scathing on database's future with Oracle
>It's fair to say that MySQL creator Michael "Monty" Widenius is not a fan of Oracle. When the company announced in April 2009 that it was purchasing Sun, Widenius saw a bleak future ahead for the (still) wildly popular open source database, which Sun had snapped up in 2008.
>The day the Sun purchase was announced, Widenius responded in the tried and true open source fashion — he forked MySQL, launching MariaDB, and took a swathe of MySQL developers with him.
>"Many of the original MySQL core developers, including me, didn't believe that Oracle would be a good owner of MySQL and we wanted to ensure that the MySQL code base would be free forever," Widenius explains.
>Some of the new code by Oracle is surprisingly good, but unfortunately the quality varies and a notable part needs to be rewritten before we can include it in MariaDB
>Widenius and a number of other MySQL developers started a company, Monty Program Ab "to provide a home both for MariaDB — the new MySQL — and for all MySQL core developers".
>"Monty Program Ab is owned by the employees and uses the 'hacking business model' as a way to drive the company," Widenius says.
>Although MySQL is still widely used — Db-engines.com ranks it as the third most popular RDBMS after Oracle and Microsoft SQL Server, compared to MariaDB coming in at #35 — Widenius still believes the database has a bleak future under Oracle's stewardship.
>Oracle's treatment of MySQL and its community since its purchase of Sun has proved Widenius' original fears correct, the developer says. Not mincing words, Widenius says that Oracle has made it clear "that they have no love for open source, working with the community, or MySQL in general".
>Widenius cites as examples of Oracle's disregard for open source principles the September 2011 announcement of commercial extensions to MySQL, the bugs database not being public any more, and a lack of test cases for new code in MySQL 5.5 and 5.6.
>Widenius is also scathing of the quality of Oracle's MySQL development efforts. "Some of the new code by Oracle is surprisingly good, but unfortunately the quality varies and a notable part needs to be rewritten before we can include it in MariaDB," he says.
>He also says that security issues are not addressed quickly enough.
>"Instead of fixing bugs, Oracle is removing features," Widenius says.
>"The MySQL documentation was never made open source, even [though] it was promised in the MySQL conference in April 2009," he adds.
>"Flagship features promised for MySQL 6.0 have never been released, even if they were fully developed and ready to be released," he says, referring to online backup for all storage engines and foreign keys for all storage engines.
>"Most of the original MySQL developers have left Oracle. Without people that can understand and explain the code it's almost impossible for Oracle to develop MySQL further even if they wanted to."
>As further evidence of disdain for MySQL users, Widenius cites what he describes as "sharp" increases in licence and support fees, a lack of an open roadmap and no way for the community to participate in the database's development.
>"Why is the price for a MySQL OEM license higher than for Oracle Express?" Widenius asks.
What exactly does these words prove? Monty has been known to shit on Oracle's efforts just because they are from Oracle, regardless of their quality (as do many others, proven by this very discussion). He's the head of a competing fork that they're trying to monetize, I would take his words with a shovel of salt.
The real problems with MySQL are:
- the bugs database is not public (as he's said)
- all development is going behind closed doors; MariaDB is more open to the public
That's it. Quality-wise it's better than MariaDB IMHO. And they pay more attention to low-level stuff that doesn't add too many new features but greatly improves things like reliability (such as rewriting the underlying InnoDB storage format). Although that one did introduce a significant feature (transactional and fully atomic DDL, which MariaDB implemented only partly and recently).
MariaDB has its share of problems. For example, they have exactly the opposite issue of what he's describing: in their first releases they've imported mountains of code from other MySQL forks without much testing (especially from Percona), things like Cassandra and TokuDB that went practically unmaintained for years and are now in the process of being removed. All to toggle as many feature checkboxes as possible ("look at how much shiny new stuff we ship!")
I personally don't use new MariaDB releases until at least their 5th or 6th patchset.
I also don't really understand this question:
> Then explain MariaDB?
Monty didn't want to work under Oracle. He left and started a competitor. What else to explain?
For a time it did seem MariaDB would replace MySQL. But your link is almost 10 years old and since that time MySQL has seen it’s biggest release (iirc ever) in terms of features and bug fixes. Meanwhile MariaDB and it have diverged and aren’t really 1 to 1 replacements as they were in 2014.
This is a responsible way to handle the ceasing of maintenance while allowing any and all interested members of the Atom community to fork and maintain versions.
I have a much more optimistic view of development communities than you do, and I expect to see Atom endure in some forms.
There had been at least one attempt to fork and revive Atom since, as the post mentions, Atom hasn’t seen feature additions in many years.
The problem, as I understand it, is that Atom’s relationship with electron makes it very difficult to work on the core of the editor. Namely, while VS Code is downstream from Electron, and can get feature benefits just by updating their Electron version, Atom is upstream from Electron, and new Electron features needed to be more manually integrated.
No it's perfectly reasonable. That open source software forms some part of a commons is not really a thing in practice. Open source software is ran by maintainers, those maintainers own the projects, and they do with the software what they deem fit. And even if it were, VSCode is basically a rewrite of Atom that reuses a big chunk of the original codebase, they're the same sort of project serving the same sort of market, and the community is much better off with only one of them.
Instead of letting it slowly bleed out and randomly catching stragglers with outdated marketing materials lingering on the web, they give it a swift death. Atom can go into the history books as an open source project that defined the industry for a decade.
Also, the core editor experience of VS Code, the Monaco editor, predated Atom by several years. It was used from the very early days of the Azure Portal and also in IE's Developer Tools. It didn't become "VS Code" until sometime after Electron stabilized out from under Atom, but parts of it have existed for longer than Atom.
Electron could probably be described as "a big chunk" of Atom's codebase. The rest of VS Code has a lot of similar functionality to Atom, so calling it "a rewrite" doesn't feel that far off (except insofar as it was redesigned as well, but that's sort of semantics)
> And even if it were, VSCode is basically a rewrite of Atom that reuses a big chunk of the original codebase
Atom and VSCode projects have always been separate projects. Both using Electron does not mean they share a codebase, not in the normal sense of the phrase.
from the article "This is a tough goodbye. It’s worth reflecting that Atom has served as the foundation for the Electron framework, which paved the way for the creation of thousands of apps, including Microsoft Visual Studio Code, Slack, and our very own GitHub Desktop."
Yes. As the comment you’re replying to said, “Both using Electron does not mean they share a codebase, not in the normal sense of the phrase.” Code is no more a “rewrite of Atom that reuses a big chunk of the original codebase” than Slack is.
“both using Electron" refers to a period of time that occurs after "Atom has served as the foundation for the Electron" and my quote states that Atom -> Electron -> Spark
I'm not an expert on this at all, I'm just quoting, but Spark is being used rhetorically as if it's an outlandish to consider it to be a descendent
Atom Shell, which was renamed to Electron, was made for Atom. Electron is not Atom. They both use javascript, too, but that doesn't mean they share code.
> That open source software forms some part of a commons is not really a thing in practice. Open source software is ran by maintainers, those maintainers own the projects, and they do with the software what they deem fit.
One should make a difference between (1) access to the source code to look, find bugs, make minor adjustments and (2) everybody with that access to be able to actively participate in the development.
In the sense of (1), open source is "some part of a commons". That's what the license gives you.
In the sense of (2), open source may or not be open to a community approach. It's fully legitimate for some company or other group of maintainers to provide (1) but deny anything related to (2). You are free to fork and make your own community, but there is nothing that guarantees you that your pull requests are accepted or even looked at, bug reports reacted to or anybody listening to wishes, concerns or other opinions about the project. It's nice if that's provided, and one could argue that some part of the spirit of open source is to enable a community, which in turn helps the original creators (and could be a major motivation to open source something), but nobody should be upset if maintainers choose otherwise.
It's nice if it's clearly communicated how maintainers see this though.
I actually prefer what they're doing. Consider most open source projects. Our involvement with them goes something like:
1. I need feature X
2. I find library WeLoveX
3. Is WeLoveX a good investment for my larger product?
4. Ambiguity happens here
The ambiguity happens because I have one prominent indicator: release activity. If it's changing lots, does that mean it's active and a solid foundation? Or does it mean it's actually probably not quite ready for prime time yet and hasn't found stability? On the flip, if there's very little release activity, does that mean it's dead, the developers have moved on and maybe there's something better out there? Or does it mean it just does its job really really well and doesn't need a constant stream of tweaks?
It's nice to have a general statement of disposition towards the product by the original authors.
Corporate speak involves blatant ambiguity and kafkaesque messaging. "Sunsetting" has a very direct meaning for GitHub, whether it gets supported by the community is something else.
Honestly, it kind of sucks that at this point you might as well call a project sunset if it has ASF stewardship, and that we seem to practically need the resources of a large company to keep an open source project "truly" afloat.
I vastly prefer the honesty in saying "sunset"; it helps bring more light to this situation, and will perhaps drive new approaches to funding foundations like the ASF.
Not everything in ASF is dead. OpenOffice probably is, but NetBeans is still being actively developed. Good thing, too, alongside IntelliJ it was probably the IDE most oriented toward getting people started writing Java code, rather than as a portal into the vast and confusing plugin ecosystem (looking at you, Eclipse).
I think this conflates several concerns which are unrelated. In particular, for a project to be under ASF stewardship does not mean it doesn't have large companies backing it. Look at projects like Kafka, Pulsar, Camel, Arrow, Spark, Flink, Pinot, Superset, Druid, etc. pp., they are all thriving and have strong funding.
the code is only one of many artifacts within a project . you have multiple support channels for bugs and features, builds, distribution , monitoring / ops (crash and perf reports), developer apis and a dozen more – each requiring time, attention, people and effort .
fork the code and start a new project with resources to take care of those and many other artifacts if you are so inclined . you have the license to do so
Most people using Atom or any other open source project, would likely have based their decision at least partly on the organization backing the project, especially in a professional setting.
For the most part, when a different organization picks up the development of the project (if one does) it's a completely new project at this point (there are exceptions, such as a backing organization continuing to back the project, but deciding that it's better supported by an independent trust, and therefore building a transition plan for that).
The best example of this is looking at any Apache supported project today. There are very few projects that were handed over to the Apache foundation that people would want to continue using in their post Apache handover date, even if they were amongst the lucky few that still have active development (OpenOffice, for example).
Sunsetting is absolutely the right term/approach to use.
The project is not open source. The code it releases is open source. There's no contradiction - it's perfectly normal for a company to release their code under an open license; Chromium is another example of this. It's technically open, but for almost every practical purpose it could be closed and it would make no difference.
What you're trying to say is "I don't like the way it's run". Okay, fine. That doesn't make it "not open source".
I have projects where I don't accept patches. "It works for me" and I just don't feel like reviewing patches. Is that not "open source" in spite of being MIT licenced?
"I can do with the code what I want" is the entire and only point of Open Source and Free Software, something Stallman and many others have been pretty clear about over the years.
Microsoft has never understood open source. This is why they bought GitHub and npm, and paid Docker to make it work on Windows, and why GitHub and the most important parts of VS Code are proprietary software.
They use open source as a marketing buzzword, not as a philosophy, and it shows.
I think perhaps TypeScript is the only counterexample.
I think they understand open source (and show it by many projects) but like you said, it is not their core philosophy.
They are a proprietary software and cloud vendor super house. They are very successful like that. Open Source is 3-4 level down to their main strategy.
The whole point of github is that anyone can fork the project and continue working on it. The code isn't going away, it's going to get archived.
The point of MS/Github announcing that they are sunsetting the project is that they are basically no longer spending time and money on the project. Projects this size have a lot of things that need attention like security fixes, legal stuff, trademarks/branding, etc. Basically, they do the right thing here by giving people some time to deal with this in whatever form they care to do that before pulling the plug.
Anyone interested in taking ownership of atom now has six months to get organized; I'm sure if somebody steps up, Github would end up doing the right thing and e.g. support them by e.g. transferring domain names, and other things they control. But somebody would need to step up for that to happen.
Apache taking ownership of a project would require that there is some community still there to work on it. They have an incubation process for this kind of thing. But there's also a thing called the attic in Apache where dead projects go after they stop being maintained.
It's a shame. Atom was my first love, taking me away from the pain of using GEdit to write code for my college courses. I loved finding new packages and tuning and tweaking it all just right. I'll miss it.
I like Atom and use it occasionally. But I use VS Code day-in and day-out. The decision makes sense.
If VS Code were not exceptionally good, Atom might have had more of an opportunity. But "yet another good option" is not enough to drive investment, sustain a community, and spin an ecosystem.
Atom predated VS Code and was the impetus for Electron, which VS Code uses. You may know this, but this comment makes it seem like they tried and didn't have an opportunity. They literally invented what the majority of new "desktop" apps uses to render UIs, they just couldn't compete with Microsoft (before they were bought out, after which of course Microsoft wasn't going to invest seriously in it).
While Electron had a huge impact, before Atom team developed atom-shell (which became Electron), there was NodeWebkit (now nw.js). I actually shipped a Windows app written with it and Angular.js, without using Windows for development or building.
I remember this being released and this was a concern at the time that the project would be abandoned. If I remember this it was mostly a concern as Github as a company should focus on their main product which is not an editor and that there are many existing editor that do it better.
I suspect that what actually killed this is the acquisition of Github by Microsoft and the fact that Microsoft are pushing VSCode very hard. Dev tooling is something Microsoft had a lot of experience (and failures) in and it was always an uphill battle.
Called this ~4 years ago when they were acquired by M$.
But it's still really sad to see. I use it because it was trivial to CSS style it to match my Desktop. It's comfortable to me in a way that other editors thus far have not been.
Are there other editors with this level of customizability? I know VSCode and Sublime support theming but from what I can tell it involves installing pre-packaged themes.
Well, if you just want a custom VSCode theme, you can try Theme Studio for VSCode: https://themes.vscode.one/. Login/signup required, though. No affiliation.
You can do a lot of customization in VSCode. Not as much as Atom, but way more than the average editor. I'm not positive whether or not it would be enough to serve your case
You can override any color you want in VS Code with a couple easy settings in your settings.json file: workbench.colorCustomizations and editor.tokenColorCustomizations
You have to package it if you want to make it easy for other people to install, but if you just want to play with it, just open settings.json and start feeding it colors.
It feels a little more natural/human. VSCode's default theme looks like Tron. Both are valid, but I can see how Atom's is more "cozy". It also had some fun "squishy" animations that were nice
For the colors at least, there are VSCode themes that will try to mimic it for you
Over the past year I've tried a few times to switch from Atom to VS Code, but there's always a little thing that brings me back. With effort most of the functionality could be reproduced in VSC, but the stupid MS typography can't be themed away.
I know a lot of people love vscode but are there any people who have tried something like IDEA/WebStorm/PHPStorm/etc that then went back to vscode?
I had to help a developer setup deploys to a dev server from vscode the other day and I wanted to pull my hair out. I'll admit it's at least in part due to not using vscode myself but I was a heavy Sublime Text user which is very similar to vscode when it comes to how you find/configure plugins.
I understand that vscode is very powerful and infinitely extendable but I feel like I shouldn't have needed to try 4-5 different vscode plugins (all configured via json) before I found one that worked and did what I needed.
At least 2 of the top downloaded plugins when searching for "SFTP" were read-only/archived on GitHub, the top one had a "reloaded" version which was also discontinued from what I could tell.
I'm comparing this experience to IDEA which has this built in (including support for deploying to multiple servers at the same time) and all configurable in the GUI.
Maybe I'm just getting old and cranky but vscode seems to get unwieldy very quickly (plugin conflicts, not being able to tell what's doing what, writing almost all config in json). The plugin ecosystem seems to be much lower quality that I what I see in the Intellij product line. I guess I'm just not interested in "building my own IDE" and forever tweaking it, I'd much rather buy a product that does almost everything I need in a sane way.
Totally agree, if I'm gonna put effort into building my IDE it's gonna be vim or emacs. I use nvim most of the time and intellij on occasion for debugging.
Of course I've heard of git and we use it, we just don't use local (on the computer we develop on) dev environments, we have a mix of developer-specific VMs and local physical hardware due to the nature of our business.
I’d write the SFTP stuff as a script and invoke it as needed via a VS Code task.
I have a few workflow-type things like this that I normally do via the CLI, but now I’ve added them as tasks to VS Code for convenience. I can also create the task at the project level and check in the JSON config so that teammates can use those same tasks.
+1 for remote ssh. If you can SFTP to the box you can use this feature.
The only possible wrinkle is the developer box needs the build toolchain. If you're writing python, your remote box obviously already has it to run your app. But if you're writing Rust or golang, it's very possible the remote machine doesn't have the compilers.
It's utterly life-changing instead of editing locally and using scp/sftp/unison to sync to the server. The "special daemon" is entirely transparent, the only requirement is ssh.
We're also talking about a dev box here, are we not?
VSCode has been working just fine for me for the last 5 years. Not sure what you mean by "keeping it working." I program in C/C++, Rust, Python, Go, TypeScript, JavaScript, and Java. Never had a problem that made me bang my head against the desk.
> The reason to switch to an IDE from something more flexible like VSCode or Emacs is the amount of time spent keeping the editor working.
An editor will generally not stop working like a car without oil. But, IDEs may stop working due to more complex configurations and disparate use cases.
> Everyone who uses VSCode has surely used an IDE before.
I would expect the opposite to be true. I could be wrong but it seems like the free editor that's mentioned in lots of tutorials would be the one newer developers gravitate to over a paid tool like IDEA.
I'm kind of surprised you did a deploy from VS Code. I would have assumed there was another tool for that. I do most of my git and ssh/scp stuff from the command line because I'm never quite sure what the tool will try to do to "help me out"
For myself it's all about reducing the delay between "writing code" and "seeing the results". Dropping down to scp or run a script to deploy files seems like an unnecessary delay/break in my development process that I don't like adding in.
If you can develop 100% locally this isn't an issue but we can't (or haven't taken the time to do so). Think of the dev server as just a VM running locally and it might make more sense.
It all comes back to that "development cycle" and wanting to make that as short as possible. What you suggest is absolutely fine, it's just my personal preference (and something that I've seen help other devs) to make the "write code"->"see results" as tight as possible.
If you add any delays, any potential chance of forgetting a step, etc then it breaks my programming flow which can kill my productivity.
But aren't you executing a task either way? Either running a script, or executing a command through Ctrl/Cmd+Shift+P, you have to do something to deploy.
I mean, hell, just set up gulp/grunt/another task runner to watch your files and run scp if you want it continuously running? Why involve your IDE at all at that point?
I set it up to deploy on save of the file or when the editor loses focus (when it auto-saves). So while you are correct I have to do “something” to make it deploy that “something” is either a hot key or me clicking out of my editor into the browser to refresh the page (talking about PHP here, all my frontend Vue work I do locally with a watch script to rebuild on changes).
Fair, that's more or less equivalent to a task runner watching the files. I'd recommend that approach only because it decouples the action from the editor. As long as the file changes, it executes.
I generally make a "run.sh" script or Makefile to build and deploy. Then it's just a few tappity taps in the terminal to run it again. Still not as good as a "play" button, but easier to set up in many cases.
I personally use CLion for all my C/C++ work, even preferring it over Visual Studio proper. It handles the environments, builds, build systems, etc for me a so I can focus on programming. VSCode is what I use for everything else (mostly Python, Golang, Web stuff) when I don't need the IDE overhead.
I switch back and forth between IntelliJ products and VSCode.
As a pure editor I prefer VSCode. It's fast and has a great plugin ecosystem. Another great feature is that it's config is just a JSON file that I can put into git and push it to my dotfiles repo making it easy to share config on all of my machines.
However, there's just some functionality in IntelliJ that I miss in VSCode like running tests. Of course there are plugins but they are all clunky and don't give you the great UX that IntelliJ does. I want the IDE to figure out where all the tests are and give me an easy way to run a single test/file/suite/feature. IMHO this is the killer IntelliJ feature for me.
My initial experience loading a python project was disappointing. I don't know if I didn't configure it right but auto complete and syntax highlighting didn't seem to work properly.
Isn't it just a frontend with the actual language servers and the whole IDE back end running somewhere else? At least that's what I thought it was from their announcement. Sort of like GitHub codespaces
> I know a lot of people love vscode but are there any people who have tried something like IDEA/WebStorm/PHPStorm/etc that then went back to vscode?
I know a few people like this. More or less, they all got burned by some technical issue that made IDEA unusable for them one day, so they quickly cobbled together a bunch of extensions in VS Code just to get their work done and stayed.
It's just the NPM problem. The barrier to entry being low means the ecosystem is gargantuan which means there's tons of bike shedding duplication and lots and lots of abandonware. So it's good that you have tons of options, but bad that curation is needed and tailoring your environment takes a lot of work.
You're deploying via VS Code? If so, that's a weird pattern.
I've been using VS Code for years to write JavaScript/TypeScript, Python, Go, Terraform, and CSS. My settings file is 60 lines, 42 of which are "for file extension X use autoformatter Y" configs.
When I first switched to VS Code I was frustrated trying to make it conform to random expectations I had. Eventually I learned that it's easier to embrace VS Code's defaults for 99% of things. I just want an IDE that works well (nearly) out-of-the-box and VS Code gives me that
> You're deploying via VS Code? If so, that's a weird pattern.
I don't think it's a weird pattern, maybe a slightly legacy one but not out of the ordinary. I've seen this pattern used at multiple places (not implement by me). It makes sense if you have special use-cases where you need to use physical hardware and/or a local stack is too heavy or complicated to run.
Then we tell the new upcoming developer that the hard part is setting up your tools. How long will this take? He asks. Oh, you answer: This will take decades! It's a wild, every man for himself kind of ride. You build a battle-royal out of abandon-ware plugins that each almost do what you want until your powerlevel finally rises to the point you just delete everything and use the terminal. The terminal is an emulator that mimics a physical device from 1941 you see, as its a physical device, there are no ever-tinkering developers bloating or [indeed] sunsetting your tools. You will finally be left alone, still in the dark but you get a cursor that no one can take away from you.
Sorry, “weird pattern” was a poor choice of words. I just meant that it’s an approach that isn’t common so it’s understandable that VS Code can’t handle it well.
VS Code is best when it’s just an IDE. I even have to drop into the terminal for some Git stuff
No almost about it, it's an anti-pattern and I personally would consider it a "worst practice". If you're deploying from an IDE it means you lack visibility, feedback, and automation fundamentals. What I do like is developer ownership and being able to see a change all the way through to production but having a system of record without manual intervention is always preferred.
It's always so interesting to see people who have no concept of your stack/problem-space speak so confidently about what you must be doing wrong.
I don't know if you've just chosen to assume the worst or don't care enough to think about it for more than a second but I've been very clear in all my comments that these are developer-specific machines we are deploying to. It's literally no different from running VMs on your local machine. There is full visibility and feedback, we aren't deploying to Prod or even QA, this is development where each developer has 2 or more boxes owned by them and only them. We also are working with specific custom hardware that our code runs on which is one reason we can't easily do this locally.
To jump in and call that "worst practice" is just lazy and condescending. On top of that, it's completely wrong.
Your aversion to running shell commands is definitely not helping you and what you're describing definitely doesn't need an IDE to be done so it's not shocking that people are questioning how familiar you are with deploying code and/or leveraging shell programs.
I never asked for or requested input on how we deploy code/manage our servers. I was asking questions about an IDE vs vscode and gave 1 example of trying to do the same thing in both of them. Had I known so many people would come out of the woodwork to tell me I'm doing it wrong without any idea of how our stack works I wouldn't have mentioned it.
I have no aversion to running shell commands and you are being disingenuous by saying that. I have a problem with manually doing a step that I can automate. I write and run shell scripts all the time for one-off process but seeing the code I've actively writing in an environment that can run it is not one of those cases. In fact, anyone doing that manually is just being silly or obstinate. If you aren't automating something that you do 100's+ times a day then I question your skills.
We have an entire industry, devops, that opposes this world view. Manual processes, snowflake developer machines, not testing the deploy piece as part of the process, throwing code over the wall for others to validate. I'm not trying to be a jerk, these are just well known and well documented anti-patterns.
For Java dev, VSCode just can't compete with IDEA. For JS/Typescript/PHP, VScode is fine, but it doesn't beat PHPStorm intellisense and code quality tools.
Can't stand IDEA if there's a decent VSCode plugin for the language I'm working with (which there generally is). It's way too sluggish, I avoid it as much as possible
I used it for a year or so around 2015. It was a huge improvement over Eclipse, which is what I'd been using since this was at a Java shop, but even then I knew it was sluggish. I just assumed back then that you couldn't have IDE features without sluggishness. Now I know better
(To be clear I have no idea how VSCode's Java experience, specifically, compares with IDEA these days; I haven't written Java since 2015)
I use both pycharm professional and vscode; vscode's remote is much better and it makes it way easier to work on projects that use multiple programming languages.
Also the default editor of the IDEA family is just unbearable (but there's the vim plugin for that, I guess), while Monaco is fine.
The only area where vscode is downright embarassing is interfacing with databases. In pycharm I can have a complete view of the database I'm connected to, run queries, get warnings and errors from inline SQL, and so on. Vscode has... strings?
If the remote capabilities get better, though, I'd admittedly have no reason to stay in the vscode camp.
I cannot stand the "dancing" sidebar in VS Code. It's used for showing the directory tree, search results, plugins, etc. I like Jetbrain IDEs (at least on my machine they load and feel fast).
I have used both, and use both working daily. If I could get away with doing everything in VSCode, I would. Part of this is how the community treats tools. VSCode is an editor, with some plugin support that lets it work as a bit of an IDE. But these are almost always optional. Code ecosystems and communities built around an IDE tend to only support working in that IDE, so there's typically only one way to do things, good or bad.
> I know a lot of people love vscode but are there any people who have tried something like IDEA/WebStorm/PHPStorm/etc that then went back to vscode?
Yep, I've tried Intellij several times over the past 5-6 years, but I've never really had an experience I liked. It's interesting that you mention SFTP and remote server deploys as a pain point for you in VS Code, because I've actually had a huge amount of frustration trying to do development over SSH in Intellij.. As of Intellij 2021 edition, I was completely unable to get ssh working from my work laptop to an EC2 instance; it could not parse my `~/.ssh/config`, and manually putting in the username, hostname, path to the private key, and even port 22 (because it literally required putting the port manually rather than defaulting to 22 unless stated otherwise), it would just say it failed to connect. The 2022 version has a "remote ssh" beta feature which also required manually putting in info that I felt like it should just be able to parse from my ssh config file, but it did connect and work for a week or two. One day it randomly started disconnecting a few seconds into loading a file continuously, which made it impossible to even scroll down into the file before it just zoomed me back up to the top. I gave up on it and just decided to stick with VS code for everything rather than try to get Intellij to work for the small amount of Java code I occasionally have to write.
Setting up ssh development with VS Code, on the other hand, was a breeze. The first plugin that came up when I searched "ssh" was Microsoft's own for ssh development, and running the command to connect to a server after installing it popped up with a list of my servers parsed from my ~/.ssh/config, which I could just select and it would connect (or prompt for a password if the ssh key required one). From there, I could easily open any project on my remote server, and VS Code even was able to detect which plugins I had installed for use with the project needed to be installed server-side rather than locally (e.g. the `rust-analyzer` plugin was installed remotely since it needed to run the daemon on the machine where the code existed). When I close my VS code window, shut down my laptop, and then the next day boot it up and open VS code, it still has the same files opened to the exact same spot (compared to Intellij's "scroll to the top of a file on connection" I mentioned before). I'm sure there are ways to get Intellij to work like I'd want, and I'm by no means a fan of Microsoft in general (I avoid Windows whenever possible and overall have a pretty negative opinion of them), but VS Code just absolutely nails the UX I want in an editor without needing that much custom configuration compared to what I've tried in the past with emacs/vim.
It's trite to say "the best tool for the job", but language support can vary drastically from one editor platform to another.
So I end up using IDEA if I'm working with Scala and Java at a job, Emacs if using Clojure, vim for those tasks that are kind of like using sed and awk but not quite, and for everything else, like Terraform, Python, shell, SQL, there's VS Code.
I was about to give up WebStorm the other day, but eventually got around it.
Jetbrains products are very good, but they feel a little "French" just like Macs: beautiful, but be aware that on some models the handbrake is on the same side as the door so you might end up tearing up your pants or bruising your thigh until you learn to be careful :-/
VS Code by comparison is very straightforward, but not always as sophisticated.
Personally I'd use NetBeans for backend and VS Code for frontend but because of Kotlin (which is great) I'm stuck with IntelliJ anyways.
I've tried too many times already to use the Jetbrains IDEs, because I know they're great, specially about the IntelliSense stuff, autocompletion, suggestions, etc.
But I just can't. My fingers are just too used to vscode, and I can do everything I need to. I feel like vscode is better at everything, and faster, except for the IntelliSense stuff. But lately I've tried GitHub Copilot and that just compensates it sooooo much, to the point I think it is even better than IDEA at suggesting stuff.
Also, working mostly with JavaScript and Typescript makes the difference go away (for me at least) as it is damn good at it.
Being free and open source also is a big plus for using it. And I love also how easy it is to configure... just a JSON with autocompletion for any setting you want to tweak. So much easier than having to mess with a ton of tabs and sections and search for settings, etc, etc.
But, if your language is not well supported in vscode, I agree Jetbrain's IDES are great and probably the best option out there. Specially IntelliJ if you're doing Java/Kotlin etc...
Muscle memory is a powerful motivator for sure. I was configuring vscode locally on my box so I could then send instructions to this other developer and my hotkeys not working was enraging. I use GitHub Copilot on IDEA and have quite enjoyed it as well.
It's funny how we have such opposite feelings on config (you enjoying the json config and me preferring UI). I have nothing against vscode and I'm glad it exists, likewise I've very glad IDEA/Intellij exists for my own uses. Thanks for the feedback.
Does VS Code support more refactoring and code generation now? I last used it heavily over a year ago, and at the time it seemed like anything beyond moving files and renaming things wasn't really doable. Meanwhile, in JetBrains's software I can extract and inline variables and functions, change signatures, split things out into other files, and more. I think I tried a plugin or two which were supposed to handle those things, but they either just didn't work at all or weren't reliable.
It all depends on the language plugin. rust-analyzer can do a lot of this stuff, I haven't seen much of it for TypeScript (though you tend not to need it as much in more flexible languages), not sure about other languages
Depends on the language LSP. From my experience, it works VERY well for JS, reasonably well for Go and not that well for python. Python allows you to refactor variables if it knows the scope of it but won't work if you use star imports and moving files doesn't work at all
I come from an era where the more fully featured your IDE, the less likely you were to truly understand what was going on under the hood.
I strongly recommend everyone spend their first ~5 years coding in vim or some other basic text editor (preferably through the terminal), before leaning on an IDE to solve their problems for them.
That said, VSCode is now my go-to IDE, and I haven't opened WebStorm in probably ~6 months. It's lighter weight than the IDEA suite of IDEs, and gives me ~80% of the functionality, so it's been a pretty good tradeoff.
There are languages, like C#, Java, and Kotlin, where the language design basically assumes an IDE is being used. It's just not practical or useful to deal with imports and their structure. Sure you can look them up on javadocs and copy/paste the import path. But at that point why not just use an ide? Why learn a skill you'll basically never use or need?
I was more productive than I suspect someone with just an IDE would have been, considering the volume of complex non-coding issues I needed to learn about and solve.
How does spending your time learning about things an IDE would have avoided make you "more productive"? That's a pretty clear cut argument that you were less productive as you were doing things manually a tool would have automated. Thereby spending time being unproductive.
Because an IDE doesn't always (or even usually) avoid those things, and I don't consider learning time to be unproductive if it means in the future I'm more productive.
It's a pretty clear cut argument that using an IDE as a crutch will inevitably bite you in the ass, and if you want the best possible understanding of the language you're using and all of its related tools you ought not use an IDE as it obfuscates those very things you're trying to learn about.
I use Sublime Text, but it has its own issues with Python fragility and needing tweaks to plug-in's config files more than I'd like, so I'll probably switch to VSCode eventually.
Java IDEs seem to be living in their own world, but for everything else VSCode works well thanks to LSP. For example rust-analyzer works best with VSCode, and this makes VSCode the best Rust IDE.
Same here, was a very happy Sublime Text user for years - much faster and less memory intensive than VSCode, but recently switched over because of all the tweaking required.
I purchased pycharm, couldn't stand it, logged bugs that are still open from over 5 years ago coupled with the fact I didn't see any immediate benefits coming from vim and vscode. I would never deploy from an ide, and I'm willing to make a small investment when it comes to my tools and productivity.
Also, as of lately, copilot is saving me an insane amount of time especially when it comes to boilerplate and testing.
I use IntelliJ for the bulk of my programming (which is nearly all Kotlin/Java) and begrudgingly switch to VSCode for other languages (i.e. Rust). It's hard going from something that seems to magically understand my code to an editor where everything, even supposedly core functionality, is a second-class citizen.
When coding JS + SQL, nothing beats WebStorm’s DB plug-in with SQL auto-completion, validation, etc.
I really wish the VS Code SQL/Postgres plugins would get there, but it’s a lot of work so I get that it probably will never happen unless Microsoft puts in the effort.
Atom has been dead for years, this is just the state funeral.
The situation now is:
* Sublime for the Williamsburg corpo-hipsters
* emacs and vim for the wizards and furries
* VSCode for all the normies who just want to get on with doing their job and don't feel a need to express their identity or politics through choice of editor
* WebStorm for the chads with the monster rigs to run it
I use VSCode because its Vim plugin is better than that of Sublime. If/when Sublime has caught up, I'd happily go back to it for that sweet performance and uncluttered UI. So am I a normie, a corpo-hipster or a furry wizard?
I'm pretty sure Sublime has a plugin that uses an actual NeoVim instance to process all inputs with all your configuration. Never tried it, I don't use Sublime. But I can confirm the feature works well in Firefox via FireNvim.
I think this is what vscode does as well. The magic is in how it cooperates with the GUI. All jumps and movements work, as well as search/replace and the hilighting and selections are even the native vscode hilights and selections so it's fluid going from mouse to vim and back. Last time I used Sublime (4+ years ago) there were a bunch of vim commands that didn't work.
The Vim plugin in VSCode is the thing that drives me out of VSCode, to be honest.
I have to say that I built so much muscle memory in those years that it is kinda hard to realized I'm not using Vim, and there is always something not-quite-like-vim in VSCode-vim that usually gets in my way.
(To be honest, the only editor that I found that is really close to Vim without being a Vim-thing was GNOME Builder.)
It's kind of bad, but they're probably the least bad behemoth owner.
Apple would try to switch everything towards their walked garden, no questions asked. Google would shut stuff down every two years. Oracle... I'm not even going to bother.
Amazon and Facebook could be interesting. Facebook is a bit shady, see the Oculus Facebook account debacle, but they're decent as stewards of dev tools. Amazon is also quite reliable for dev tools.
Would anyone really big be a better steward? Did I miss someone?
I guess I would vastly prefer an organization which is not one of the tech giants.
Facebook/meta seems horrifying. Some of their tools are indeed great, but I can just imagine having to use a facebook login to push code to GitHub or to download VSCode plugins.
Amazon is problematic for similar reasons as MS: since they are one of the biggest application hosts out there, bad incentives exist in terms of potentially allowing biases in their tooling to preference their own platform.
"VSCode for all the normies" ... feels weird. Maybe it's true. But I feel like VSCode rose 1:1 with Typescript, and I kind of resent it because I associate it with script kiddies around me cargo-culting React in places it isn't needed and writing thousands of lines of overcomplicated javascript to "manage state" on pages that don't even need to have any.
It's also noticeably slower than Sublime, which makes switching hard.
But "Williamsburg corpo-hipster" feels off the mark. To me Sublime aligns more around the "JS minimalist" camp, which overlaps a lot with the "bootstrapped and profitable" crowd.
Isn’t Sublime also for people whose haven’t bought a new computer in 10 years and so can’t run VSCode? That’s why I started using it, at least. (Now it’s just inertia.)
I went back to try Sublime lately and.. it's lost a lot of the minimalism that attracted me to it initially. That was the same reason why I loved Atom during it's golden years before it got too slow.
Right now I am using a very stripped down VSCode, which is.. fine. It works. I don't love it but it gets the job done usually.
Any other good editors on the minimal side? I need a bit more than vim/emacs, but I don't want or care for autocompletion or anything that alters what I have written. I don't need vcs support. I don't need a built in terminal. Just a good, simple and fast code editing experience with modern ergonomics and syntax highlighting that works across every language.
Have you tried neovim with any of the lsp integrations? I’m not going to pretend it’s trivial to set up, but the result seems very powerful. If you just want to dip your toes without doing that he setup yourself, I believe there are some prepackaged options eg onivim which you can try out.
Well put. There's just no reason to move off VSCode so far (for Python and friends). In a couple weeks' time, I'll be working with C# in Visual Studio. It has me excited since I've heard many good things about Microsoft developer tooling, of which VS is a huge tool in the box (C# as a language also seems attractive).
> VSCode for all the normies who just want to get on with doing their job and don't feel a need to express their identity or politics through choice of editor
Seems like just another kind of identity: The self-titled "normie" who glances over at the "corpo-hipsters" and "wizards and furries" and smugly pats themselves on the back about how they're so much better because, unlike everyone else, they just want to "get on with doing their job"...
The fact is, I can't do my job very effectively with Visual Studio Code. That's why I throw it down in frustration and storm back to Emacs every time I try it. Emacs has features that allow me to pretend to be an organized, functional person on the job -- notably, Magit, org-mode, and always-on Lisp that helps me automate away the tedious unusual bits of our process. If you were to compel me to use Visual Studio Code, much of my effort which is today productive would be lost as waste heat.
Heh, yes, def agree, although I think that a person who is genuinely oblivious or indifferent to all this will also prob end up using VSCode just cos it's free and has the highest brand awareness
This entire time I thought I used Sublime because it was a fast enough, full of features, battle tested editor, that also wasn't a bloated IDE nor an exercise in self flagellation (i.e. choosing to use an command line editor with a high learning curve like Vim or Emacs).
I didn’t use Atom much, but I think it’s obvious that the primary reason it died was because Microsoft decided to make their own competing editor, and then bought the parent company of Atom. It wasn’t exactly the most popular editor at the time, but it did still have some users.
Reminds me of how Adobe killed off FreeHand (the only competitor to Illustrator at the time) by buying the parent company and then halting development.
Of course, Microsoft likely gave zero shits about Atom as a competitive threat since it was effectively dead at the time anyways, but I still think it’s interesting to see the similarities to the Adobe situation.
> the primary reason it died was because Microsoft decided to make their own competing editor
> Microsoft likely gave zero shits about Atom as a competitive threat since it was effectively dead at the time anyways
How can Microsoft both give zero shits because it was effectively dead, while also still being the primary reason it died? That seems to be a chicken-egg problem.
I mean that Microsoft's acquisition of Github had nothing to do with Atom whatsoever (I assume), but the acquisition was the final nail in the coffin for it.
Would it have survived if Microsoft didn't acquire Github? It's possible, however unlikely. But after the acquisition? Not a chance.
I don't know what's worse, that Adobe would do something so shamelessly anti-consumer and anti-competitive, or that the FTC did nothing to stop such an obviously bad acquisition.
Today we can clearly see that as anti-competitive and anti-consumer acquisition, but at time, I guarantee you the FTC saw the agreement as business as usual, since it does not know how to regulate tech companies even today.
The first thing which Visual Studio Code did right was the better performance. The initial reaction to Atom was that it was very promising, but very slow.
The second big innovation was the language server protocol.This allowed any language to be supported by VS Code.
Third, for me at least: Remote Extensions. That suite of extensions including SSH WSL, and Container support made things I was already doing frictionless.
MS poured developers at VS Code which resulted in it blowing away Atom pretty soon in terms of performance. Soon devs started migrating to VSC, plugin ecosystem started accreting, and gradually people just forgot about Atom. It is not that Atom did anything horrendously wrong. If the same dev effort had been put into it that VSC got, am pretty sure it could've become almost as good now. Maybe even better in certain respects.
Speed. I used Atom for a couple years, but quickly switched to VSCode once it was viable as it was the first electron editor to actually be "fast enough" for me.
VS Code had a really interesting "head start": the core editor (named Monaco) had been built for very early stages of the Azure Portal and then been adopted into IE 10/11's Developer Tools to replace an aging code viewer/editor. In order to run in Dev Tools it had to run through an extreme gauntlet of some of the web's worst "files": giant one-line minified things, massive multi-megabyte bundles, and so forth. So the Monaco code editor got a huge amount of performance testing and work years before Atom arrived and built Electron.
It also sounds like VS Code took a much more measured approach to extension APIs than Atom did. In Atom nearly every part of the product was an extension, which is a great approach to dogfooding extension APIs and making sure everything including the kitchen sink has an extension API, but getting that performant is tough. Whereas VS Code was very careful in the early days in what extension APIs they declared and started from a place of performance first. In many cases if only a single extension doesn't perform well in VS Code you almost don't notice because it's mostly isolated from the rest of application performance. Atom had a lot more situations, from what I heard, where one badly performing extension brought everything to a crawl.
On the topic of performance - one of the architecture decisions that VSCode nailed was the 'extension host' (https://code.visualstudio.com/api/advanced-topics/extension-...): all VSCode extensions are sandboxed in a child Node process, and can only communicate back with the main IDE process via the VSCode API. This has huge benefits for performance:
(1) extensions can never block editor startup. this was a huge problem for Atom as package loads were startup blocking and it wasn't uncommon to have multi-second startup times with lots of packages installed - especially due to the fact that JS packages typically repeat dependencies, resulting in tons of bloat. Also extension authors are rarely performance-conscious
(2) extension code can never block the core rendering thread, another huge problem in Atom - you'd often have stuttering/frame drops if extensions were doing blocking work on character or cursor changes, which was more often the case than not..
The tradeoff of course is that VSCode extensions are very limited in the set of UI customizations they can make but MS did a very good job of designing their APIs to be sufficiently extensible in this aspect (i.e. having APIs for extensions to hook into all core IDE features). Atom's extension ecosystem was much more fragmented resulting in dependency/versioning hell.
As a side note, another benefit of the extension host model is how it enables extensions to semi-magically work on remote filesystems (including inside WSL) without needing complete rewrites.
Editors are like browsers, huge amount of upfront work to even get parity with decades old editor and no commercial potential to sell product. Charge a little bit of money and a million of well paid IT workers suddenly become so poor to pay for tools they need for work. They would further spend productive time haranguing maintainers on why editor need to be open source (code word for just free as in beer) or how 60-70 dollars / year is too much for a code editor and so on.
So end result is only editors exist are feature complete long time back/ or maintained by companies who could just give it for free, compensating it with cloud revenues. Besides a couple of paid editors with insignificant market share of course.
I wish there was an editor I feel comfortable paying for
Idea stuff is just way too bulky for me. I don't like using any of them, sacrilegious as that may be, and don't feel the need to use them for since I don't use java. Paying for Sublime is just not worth it with its far poorer plugins and API and their release cadence is atrocious. I checked Nova from Panic out and it looks promising but it's VERY far from being a replacement for my current setup
So I see almost no reason to switch from vim and VSCode, both of which are free and have extensive plugin support and are great at what they do. If something comes along that is faster, has good language support and good list of extensions, I would have no trouble paying for it
This makes me sad as I very much prefer the atom approach to the git and github panels than the vscode approach. vscode is much faster for typescript development though.
Even though Atom was much "lighter" than VS Code in terms of UI, VS Code had so much more development resources thrown at it that it was ultimately much speedier than Atom. IIRC, even Brackets was faster.
I see people complaining about the death of Atom, but in the past few years there just hasn't been a use case where Atom was the best choice.
Exactly. I used Atom for a while, but then it started getting so slow. My coworker mentioned I should try VSCode, and it did everything I wanted Atom to do but faster.
879 comments
[ 4.6 ms ] story [ 367 ms ] threadSpellcheck always works, nothing ever crashes and acts weird I run it for 10+ months without issue. VSCode on my PC the spell check is inconsistent and weird and on a long enough timeline it actually crashes the whole operating system if you leave it open.
I mean, I tried to become an emacs person several times when I was still coding, and it just never took. My last phase of programming work was on OS X, so I had friendlier yet still capable options like TextMate, which made shifting to emacs a pretty hard ask.
Then my job shifted to a point where my preferred method of tracking activites/tasks/notes was just falling apart. I was all-in on the GTD-inspired Omnifocus, but what I really wanted was a system where I could intermingle notes with Todo items, and then ask the system to collate a list of the Todos for me dynamically.
Which, as it turns out, is pretty much a description of how OrgMode works. And, sadly, almost nothing else that I've found, and so I use emacs all the time now.
My emacs expertise, though, is pretty limited to things I need to know to be productive with Org.
Brackets was the foundation of Adobe Edge Code, which was part of Creative Cloud, so there were some bigger plans there.
Thank you for developing Brackets! I used it daily as a web dev, it had an awesome live preview feature.
Live Preview in particular is one of the areas I had some fun working on. I worked out a way to do diff/patch to make it quickly and incrementally update the browser[1]
[1]: https://github.com/adobe/brackets/wiki/Research%3A-HTML-DOM-...
One could imagine a world where strong standards have been established which would allow you to easily deploy lean native applications across a wide variety of platforms.
Instead we ended up in this bizzare world where if you want to maintain a desktop GUI app, you either need a large team to support multiple platforms, or you need to target minified javascript of all things, and run your software on top of a large, arcane compatibility layer.
FWIW: I'm probably one of the most "IT Conservative" people on this site, I still believe in sysadmins, dislike systemd, hate electron etc;
But there is something to be said about developer productivity: if you can build a prototype in 10 days when it would have taken 10 weeks that can be a huge differentiator between companies; it means you can make 6x more prototypes in the same time window, or work through different iterations of the same idea.
That's hugely beneficial.
I think if you treat inefficient things this way (I consider Ruby/Python in the same way) then we all benefit, test your ideas then go for gold on a more efficient platform.
As a computer scientist, I can't help but cringe at the massive amount of collective inefficiency in the current state of computing.
But don't get me wrong, I'd rather have the inefficient thing which creates value than nothing at all.
And yet this didn't happen and Electron did. The "free market" of FOSS development settled on Electron as the winner for cross-platform development.
For instance, if Apple had actually kept pace with OpenGL standards, and had embraced Vulkan, it would have been fairly straightforward to to build a native GUI framework which works across platforms.
Electron won because all the platform owners basically had to embrace the implementation of web standards on their platforms. So they couldn't prevent those tools from being used to deploy local software as well.
There literally are cross-platform native GUI frameworks. Even Electron itself is a third-party implementation of a GUI framework - it doesn’t use the platform’s web tech implementation and bundles its own.
All these little wedges add up.
Decisions were taken with an eye to balance sheets and P&L reports; Electron remains the cheapest option of them all, because the supply of moderately-skilled HTML/JS labor is naturally larger than for any other language - all thanks to choices the Netscape Corporation made in 1995, when they needed interactivity in their product and they needed it quick.
Imagine a world where everything had to be deployed to the JVM and all progress depended on Sun/Oracle. Or god help us, IE/VBScript.
Electron clearly means that we end up with a bunch of apps that would be otherwise unavailable, while at the same time meaning that we have a bunch of embarrassingly bad GUI experiences from companies who can afford to deliver better.
I may be wrong in the moment, but I base my arguments on trends. Processing power, storage costs and bandwidth are always improving. So human productivity should always take priority over efficiency as time progresses.
I'd vote for a real Web 3.0 based on first principles like declarative and data-driven programming, idempotence, immutability, one-shot scripting (perhaps even a Turing-INcomplete DSL) for initial render without side effects (like CSS variables but for HTML), dynamic element loading with something like HTMX, secure server-side includes, distributed databases using Paxos/Raft, even distributed computing with a real Docker that provides an actual secure sandbox and repeatable builds of untrusted secure/private code (maybe with something like homomorphic encryption). I can go on and on about what real (not phantom) tech looks like. And it looks nothing like SPAs.
Also I think a lot of people recognize the need for this stuff, so ideas aren't the problem. The problem is, always has been, and always will be funding. In fact, my single greatest disappointment about the modern web is that stuff like advertising and eBay got coopted so there was never a viable way to make enough residual income to live on after the Dot Bomb around 2000/2001. The closest things we have are Uber and donating plasma. So we have a generation of highly-effective programmers spending the most productive years of their lives at a day job making rent, which is why rent increases. Hustling without understanding that the hustle itself is the failure when viewed through this lens.
Blah I dunno why I write this obvious stuff anymore. It just ain't never gonna happen. It may as well be impossible. Or I should say, it may take another 20 years to get here, and I just don't think we have that long anymore.
Disagree with this. As a dev you have a huge advantage in that you can bootstrap a Saas or similar business cheaply. With the tooling and services available today you can launch quicker than ever before
If you can get a semblance of product market fit you can generate enough income to live off of. It’s not easy but it’s definitely possible.
Here is a unified binary format that can run on Linux, MacOS, Windows, FreeBSD, OpenBSD, and NetBSD too. They also boot from the BIOS.
But it doesn't support GUIs (yet?).
https://justine.lol/ape.html
<https://justine.lol/redbean2/>
<https://news.ycombinator.com/item?id=31764521>
It doesn’t really bring any advantage? You need to package whole Chrome with your app, the few MB you save with minification does not matter??
But people here can enlighten me.
However I honestly have no idea how much time does JS parser spends on what exactly. Are longer variable names and less tabs that big of a deal? It’s all in memory anyway, no… the lexer or tokenizer or whatever (…I never finished my compiler course…) just goes through that
The product’s source maps are publicly available in a way the debugger understands and the original code is freely accessible so there’s no real downside.
People wrote Java applets that were supposed to be same everywhere. It even had GUI.
Nobody expected that not Java, but _JavaScript_ will be the actual write once-run everywhere.
Examples for me would be: VSCode and Linear
I'm sure VSCode and Linear are fast, nice, and fine. I just hated the lag/latency compared to my terminal text editor.
Really expected and unsurprising.
"Atom community involvement has declined significantly"
Probably because it works well enough, some tools don't need endless enhancing
Now I just need to install keymapper and convert all my M-w and C-y inputs to Ctrl-C and Ctrl-V.
There are three nice things about it: it flips vim's <verb><motion> into a <motion><verb> (like kakoune); it's got tree-sitter support out of the box (including for navigation); it's got LSP support out of the box.
Its keybinding is perhaps in "uncanny valley" of vim's. Overall, it still feels well thought out.
And the reason I went back to Emacs is because of elisp and M-x. Those are the true killer features of that editor, still unrivaled.
Sublime -> Atom -> Vim -> Emacs -> Emacs -> Emacs -> Emacs
https://www.sublimetext.com/
But realistically? A significant majority of developers use Visual Studio Code; Atom is still only being used by absolute diehards. Visual Studio Code's complete supplantation of Atom (with which it competes for resources in the same organization) is why we're having this discussion.
Also totally subject for discussion: I suspect VS Code will see more innovation in years to come.
But I do think Emacs will be fine. I don't think VSCode is an existential threat to Emacs in the same way Toyota is not a threat to Lamborghini. VSCode boasts impressive numbers, but it does so by consolidating in a target demography that was never a stronghold for Emacs to begin with - partly due to some level of indifference on its part. On the other hand, there are things Emacs is uniquely suited for, and for that reason it will continue to attract a particular type. I think in terms of absolute numbers Emacs userbase is still increasing, and I think falling numbers in terms of total percentage doesn't mean much for its survival.
Just found this. It’s a shame. I donno why but I just liked brackets interface.
I used Brackets too back then and tried Atom a few times but it was always too slow and laggy. I was so glad when VSCode came out and that it was actually good. I was in the midst of switching to VIM but it was just too much of a bother.
Every time I try to go back to Sublime, this annoys me right off the bat and I'm back in VSCode by the end of the day.
Or through the Gui - "Preferences --> Package Control"
In VSCode, I can browse info about packages without having to remember a thing aside from "one of the six big icons on the left is 'Extensions'". One mouse click, start typing, click anything that looks like it might be good, get a ton of info and an "install" button. There are filters! So I can simply sort by "most popular" if I want, or by name, or a bunch of other things, all without having to remember anything for this somewhat-infrequent operation, because it's in the GUI.
It's mainly the integrated package exploration that's missing. And the auto-suggestion for plugins—in fact, I rarely have to do any of the above, and just click "OK" to whatever VSCode suggests, and everything's fine.
Sublime has (I just checked) a "package discovery" command, which... opens a web browser, to the exact same page you'd have ended on if you'd started by just googling it (which is what I do). So you have to find what you want on there, then go back to Sublime and find it again.
The result is that in the best case it takes me 1% as long to install what I need on VSCode (just click OK), and worst case it takes me perhaps 50% as long, compared with Sublime. I'm also way less likely to go poke around and see if there's anything that might be useful, in Sublime.
[EDIT] "Why aren't you way more familiar with the command palette?" ephemeral shells as anything more than dead-simple launchers make me really uncomfortable. I hate using them. Apple spotlight? I use it extensively—only for launching programs, period, nothing else. I'd much rather have a persistent shell environment I could attach from any terminal and leave open.
I do love the fact that, with Sublime, that 75%+ of the time when I want to do something, say, pretty-print a JSON text document, it's just:
The entire editor being easily tweakble is the killer feature of web-tech based editors.
Sublime may have opened up more customizability since then...
It's amazing how much a minor annoyance can drive someone to a completely different solution.
If you are coding: Unless you are using IntelliJ (which a ton of of my colleagues do, and love) - it's a vscode world. Everyone at every company I've seen bangs away using that. It's kind of amazing how much inertia it's picked up (currently).
If you are working with text: 90% of the time if I have a couple gigabytes of text I need to do a lot of work with - it's Sublime Text. Actively Developed. A really solid text plugin architecture. The other 10% of the time I still use vim - mostly because it's in my finger DNA. Emacs is the obvious alternative which lots of smart people I know use.
I'd be interested in knowing if there are people who have used all five of these for > 100 hours that would recommend something else - (I haven't used Emacs that much - but I have well over a couple hundred hours on each of intelliJ/vscode/vim/Sublime. Probably close to 1000+ hours on the last three). (okay, small fib - close to 5,000+ hours on Sublime. I spend almost as much time in that tool as I do bash).
I think I’ll try it again after seeing the news about Atom.
[1]: https://nova.app/
It was only adderal driven developer crowd making mountain out of a mole because they felt uneasy their frigging text editor hadn't been updated every other week.
It seemed to me that there would always be an endless cycle of boom and bust with editors. It was a cycle with more in common with fashion than craft, and I wondered if I might end up wasting an inordinate amount of time switching editors throughout my career without any upside. So rather than switch to Atom, only to switch again a few years later, I set about with adopting Vim.
The choice seems to have been correct as there will always be a new editor (that's more or less the same as the old editor) that catches hold, but I wanted stability. Vim gives me stability, and the only other editor I'd consider would be Emacs for similar reasons.
If you use your text editor professionally, they more than worth the investment.
And if you want to build a text editor for your own needs, Emacs and Neovim are your friends.
Since it is only happening in 6 months, I wonder if the community will try to transition/fork it.
Do you know if there is still enough interest?
But saying that you’ve decided to “sunset” or “archive” it, telling users to plan for their migration, seems counter to the notion that open source software forms part of a commons - something that Github, of all companies, should understand.
We should be counting down the days till they sunset VS Code to focus on VS Code "Pro".
They harvest an astonishing amount of data from it.
> We should be counting down the days till they sunset VS Code to focus on VS Code "Pro".
I don't think it would serve their interests, so I'm not worried about it, but who knows? This cynicism is directed towards Microsoft because they've earned it.
The writing was on the wall for a long while now, and was one of the reasons why the JuliaCommunity stopped advocating Juno/Atom as a platform and instead switched to VSCode
Atom is inferior in every aspect to Visual Studio Code. Atom was on life support for too long.
Contingency planning for this could be a small but wise time investment for dependent teams. VSCode could very well go the way of the Do... Docker.
They maintain a trademark on the name Visual Studio Code and some other bits. And it is maintained by a Microsoft team.
But the code itself is MIT licensed. You can build it yourself. I have. There are one or two forks of it out there.
https://news.ycombinator.com/item?id=9872976
https://thenextweb.com/news/microsofts-cross-platform-visual...
https://news.ycombinator.com/item?id=17221917
I'd actually worry if the engineers I work with couldn't pick up a new IDE/text editor, etc. pretty easily and quickly, if and when something like this happens. And I'd say the risk of it happening in the next three to five years is pretty minimal at this point.
Once you start making full use of your editor, switching to a new one and reaching the same level of proficiency takes a long time. I can edit code even in notepad, but I can't ever be as fluid in it as my main editor. I've changed my editor multiple times and it's a huge pain every time.
I doubt that switching an editor requires a disaster-recovery plan.
I guess they have lots of "solutions" to "design and implement".
the normalization of this behavior within the industry makes using emacs or vim even more satisfying.
it's nice to having an unchanging cement foundation to stand upon once-in-awhile.
One of the main complaints many of the C# developers on my team have when they have to touch languages that aren't well supported by Visual Studio is that they don't know how to work VSCode.
And also why C++ workloads depend on .NET being available.
My money is on VS Code 365.
The context of “embrace, extend and extinguish” has kind of been diffused over the years, though; it never meant “buy a product and kill it,” but rather meant adopting open standards and adding proprietary (not necessarily closed, which is not the same thing) extensions to them that end up becoming de facto standards, so your product is perceived as better at the task then the fully standards-compliant original. What happened with Visual Studio Code and Atom isn’t an example of this at all. For a start, they’re just two products that are competing in the same space; they’ve never had the same extension standards, so the idea of “embracing and extending” just isn’t relevant here.
Secondly, Microsoft obviously didn’t buy GitHub to shut Atom down. I’ve seen the arguments that once Microsoft did buy GitHub, Atom was doomed, but Code was already arguably more popular than Atom when Microsoft bought GitHub in 2018: Stack Overflow’s developer survey showed VSCode as far more popular among surveyed users (34.9% to Atom’s 18.9%). If those numbers had been reversed—if Code never made a real dent and Atom kept growing—then I have little doubt Atom would be the one continuing.
Lastly, I suspect the runaway popularity of Visual Studio Code is pretty good insurance against a hypothetical “Visual Studio Code Pro” replacing the existing VS Code. This would almost certainly cause a fork (or more than one!) to be created, and it’s highly likely such a fork would get immediate backing and support from one or more technology companies willing to pay for continued open source development.
However, I don’t think that’s likely, because I don’t think that’s how Microsoft is interested in monetizing Code. It’s not a source of income in and of itself. It doesn’t have to be. If it just so happens to have great GitHub integration, maybe your company will pay for GitHub enterprise features. If you’re used to using it, you may be more likely to pay for GitHub Codespaces. If it has a great story for deploying to Azure, then maybe you’ll be more likely to deploy to Azure. And so on.
This. Microsoft share price depends on the size of their recurring revenue from cloud. They can easily write off a few million on VScode for bringing more users to Azure
The revenue generating upsell for VSCode is already here and it IS GitHub Codespaces. They are going to add features you can't live without based off code synthesis (sky's really the limit here) and gate those off saying it can't run locally because it's too resource intensive. They'll charge you (or your company) by the second for all usage.
It would be much harder or impossible for them to do this if Atom and an independent GitHub had been further entrenching in this space for the last decade.
Many of the biggest developer tooling projects big corp are building now existentially threaten smaller developers and apps, by design.
Don't give Microsoft a pass here.
I think a simpler explanation is correct: Microsoft saw that open source developer tools are gaining a lot of popularity and also knew that it could help revitalize/modernize their image, so they authorized the funding for the creation of a (mostly) open source code editor, and it gained popularity because it was good.
We're basically fucked.
Or when they sunset the closed-source PowerShell and created the open-source PowerShell Core?
Like those?
Speaking of packages - of the six featured packages I get offered on atom.io, only one had a release in the last two years, and half have been unchanged for half a decade. Atom's already dead.
Finished is a state more software should aspire to reach. Sadly, with the advent of connectivity in everything, it's getting rare for even firmware to be finished.
Most real world problems have almost infinite demand for more and better software. The final text editor will be the one that reads the minds of the users and product manager and writes the code for you.
But winding down the project is still a major event, and I think that it is appropriate to call that sunsetting. The existing project organization will go away. The team will presumably dissolve, with any people being paid to work on it going on to other things. I've seen this happen enough times to know that it is, indeed, an end of sorts. "The community" is almost never large and organized enough to keep a project like this vital. At best, they can only slow its descent into obscurity.
Correct me if I'm wrong, but most projects started by some form of organization end up being dead after handing them off to the community. That is, unless they make their code from the ground up to be as most readable and modular as possible.
I remember many projects made by Sun Microsystems that just died when Oracle took over, even if the code is still there.
https://zulip.com/history/
To be more precise: 8.0 finally has proper utf-8 out of the box, support for complex replication topologies (including multi-master), window functions, CTEs, etc.
https://www2.computerworld.com.au/article/457551/dead_databa...
>Dead database walking: MySQL's creator on why the future belongs to MariaDB
>MySQL's creator, Michael "Monty" Widenius, is scathing on database's future with Oracle
>It's fair to say that MySQL creator Michael "Monty" Widenius is not a fan of Oracle. When the company announced in April 2009 that it was purchasing Sun, Widenius saw a bleak future ahead for the (still) wildly popular open source database, which Sun had snapped up in 2008.
>The day the Sun purchase was announced, Widenius responded in the tried and true open source fashion — he forked MySQL, launching MariaDB, and took a swathe of MySQL developers with him.
>"Many of the original MySQL core developers, including me, didn't believe that Oracle would be a good owner of MySQL and we wanted to ensure that the MySQL code base would be free forever," Widenius explains.
>Some of the new code by Oracle is surprisingly good, but unfortunately the quality varies and a notable part needs to be rewritten before we can include it in MariaDB
>Widenius and a number of other MySQL developers started a company, Monty Program Ab "to provide a home both for MariaDB — the new MySQL — and for all MySQL core developers".
>"Monty Program Ab is owned by the employees and uses the 'hacking business model' as a way to drive the company," Widenius says.
>Although MySQL is still widely used — Db-engines.com ranks it as the third most popular RDBMS after Oracle and Microsoft SQL Server, compared to MariaDB coming in at #35 — Widenius still believes the database has a bleak future under Oracle's stewardship.
>Oracle's treatment of MySQL and its community since its purchase of Sun has proved Widenius' original fears correct, the developer says. Not mincing words, Widenius says that Oracle has made it clear "that they have no love for open source, working with the community, or MySQL in general".
>Widenius cites as examples of Oracle's disregard for open source principles the September 2011 announcement of commercial extensions to MySQL, the bugs database not being public any more, and a lack of test cases for new code in MySQL 5.5 and 5.6.
>Widenius is also scathing of the quality of Oracle's MySQL development efforts. "Some of the new code by Oracle is surprisingly good, but unfortunately the quality varies and a notable part needs to be rewritten before we can include it in MariaDB," he says.
>He also says that security issues are not addressed quickly enough.
>"Instead of fixing bugs, Oracle is removing features," Widenius says.
>"The MySQL documentation was never made open source, even [though] it was promised in the MySQL conference in April 2009," he adds.
>"Flagship features promised for MySQL 6.0 have never been released, even if they were fully developed and ready to be released," he says, referring to online backup for all storage engines and foreign keys for all storage engines.
>"Most of the original MySQL developers have left Oracle. Without people that can understand and explain the code it's almost impossible for Oracle to develop MySQL further even if they wanted to."
>As further evidence of disdain for MySQL users, Widenius cites what he describes as "sharp" increases in licence and support fees, a lack of an open roadmap and no way for the community to participate in the database's development.
>"Why is the price for a MySQL OEM license higher than for Oracle Express?" Widenius asks.
[...]
The real problems with MySQL are:
- the bugs database is not public (as he's said)
- all development is going behind closed doors; MariaDB is more open to the public
That's it. Quality-wise it's better than MariaDB IMHO. And they pay more attention to low-level stuff that doesn't add too many new features but greatly improves things like reliability (such as rewriting the underlying InnoDB storage format). Although that one did introduce a significant feature (transactional and fully atomic DDL, which MariaDB implemented only partly and recently).
MariaDB has its share of problems. For example, they have exactly the opposite issue of what he's describing: in their first releases they've imported mountains of code from other MySQL forks without much testing (especially from Percona), things like Cassandra and TokuDB that went practically unmaintained for years and are now in the process of being removed. All to toggle as many feature checkboxes as possible ("look at how much shiny new stuff we ship!")
I personally don't use new MariaDB releases until at least their 5th or 6th patchset.
I also don't really understand this question:
> Then explain MariaDB?
Monty didn't want to work under Oracle. He left and started a competitor. What else to explain?
For a time it did seem MariaDB would replace MySQL. But your link is almost 10 years old and since that time MySQL has seen it’s biggest release (iirc ever) in terms of features and bug fixes. Meanwhile MariaDB and it have diverged and aren’t really 1 to 1 replacements as they were in 2014.
This is a responsible way to handle the ceasing of maintenance while allowing any and all interested members of the Atom community to fork and maintain versions.
I have a much more optimistic view of development communities than you do, and I expect to see Atom endure in some forms.
The problem, as I understand it, is that Atom’s relationship with electron makes it very difficult to work on the core of the editor. Namely, while VS Code is downstream from Electron, and can get feature benefits just by updating their Electron version, Atom is upstream from Electron, and new Electron features needed to be more manually integrated.
Instead of letting it slowly bleed out and randomly catching stragglers with outdated marketing materials lingering on the web, they give it a swift death. Atom can go into the history books as an open source project that defined the industry for a decade.
It isn't true anymore then saying Slack is rewrite of Atom. While it is using electron, editor and IDE aren't from Atom.
> VSCode is basically a rewrite of Atom that reuses a big chunk of the original codebase
They both use Electron as their framework, but that's about where the code similarities end.
Atom and VSCode projects have always been separate projects. Both using Electron does not mean they share a codebase, not in the normal sense of the phrase.
I'm not an expert on this at all, I'm just quoting, but Spark is being used rhetorically as if it's an outlandish to consider it to be a descendent
One should make a difference between (1) access to the source code to look, find bugs, make minor adjustments and (2) everybody with that access to be able to actively participate in the development.
In the sense of (1), open source is "some part of a commons". That's what the license gives you.
In the sense of (2), open source may or not be open to a community approach. It's fully legitimate for some company or other group of maintainers to provide (1) but deny anything related to (2). You are free to fork and make your own community, but there is nothing that guarantees you that your pull requests are accepted or even looked at, bug reports reacted to or anybody listening to wishes, concerns or other opinions about the project. It's nice if that's provided, and one could argue that some part of the spirit of open source is to enable a community, which in turn helps the original creators (and could be a major motivation to open source something), but nobody should be upset if maintainers choose otherwise.
It's nice if it's clearly communicated how maintainers see this though.
1. I need feature X
2. I find library WeLoveX
3. Is WeLoveX a good investment for my larger product?
4. Ambiguity happens here
The ambiguity happens because I have one prominent indicator: release activity. If it's changing lots, does that mean it's active and a solid foundation? Or does it mean it's actually probably not quite ready for prime time yet and hasn't found stability? On the flip, if there's very little release activity, does that mean it's dead, the developers have moved on and maybe there's something better out there? Or does it mean it just does its job really really well and doesn't need a constant stream of tweaks?
It's nice to have a general statement of disposition towards the product by the original authors.
It’s not GitHub anymore though. It’s Microsoft and Microsoft must advance the Visual Studio brand.
Especially, if there isn't a dedicated community to maintain it.
I'll take honesty over corp-speak any day.
That said we probably only get honesty, because they want us using vscode instead.
Honestly, it kind of sucks that at this point you might as well call a project sunset if it has ASF stewardship, and that we seem to practically need the resources of a large company to keep an open source project "truly" afloat.
I vastly prefer the honesty in saying "sunset"; it helps bring more light to this situation, and will perhaps drive new approaches to funding foundations like the ASF.
fork the code and start a new project with resources to take care of those and many other artifacts if you are so inclined . you have the license to do so
For the most part, when a different organization picks up the development of the project (if one does) it's a completely new project at this point (there are exceptions, such as a backing organization continuing to back the project, but deciding that it's better supported by an independent trust, and therefore building a transition plan for that).
The best example of this is looking at any Apache supported project today. There are very few projects that were handed over to the Apache foundation that people would want to continue using in their post Apache handover date, even if they were amongst the lucky few that still have active development (OpenOffice, for example).
Sunsetting is absolutely the right term/approach to use.
I have projects where I don't accept patches. "It works for me" and I just don't feel like reviewing patches. Is that not "open source" in spite of being MIT licenced?
"I can do with the code what I want" is the entire and only point of Open Source and Free Software, something Stallman and many others have been pretty clear about over the years.
This is not true at all, as evidenced by http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral.... You are mistaking Open Source for public domain.
I don't know if it started when MS bought them, but it's when I think the decline became very apparent.
They use open source as a marketing buzzword, not as a philosophy, and it shows.
I think perhaps TypeScript is the only counterexample.
They are a proprietary software and cloud vendor super house. They are very successful like that. Open Source is 3-4 level down to their main strategy.
The point of MS/Github announcing that they are sunsetting the project is that they are basically no longer spending time and money on the project. Projects this size have a lot of things that need attention like security fixes, legal stuff, trademarks/branding, etc. Basically, they do the right thing here by giving people some time to deal with this in whatever form they care to do that before pulling the plug.
Anyone interested in taking ownership of atom now has six months to get organized; I'm sure if somebody steps up, Github would end up doing the right thing and e.g. support them by e.g. transferring domain names, and other things they control. But somebody would need to step up for that to happen.
Apache taking ownership of a project would require that there is some community still there to work on it. They have an incubation process for this kind of thing. But there's also a thing called the attic in Apache where dead projects go after they stop being maintained.
If VS Code were not exceptionally good, Atom might have had more of an opportunity. But "yet another good option" is not enough to drive investment, sustain a community, and spin an ecosystem.
Edit: Fixed typo (thanks torstenvl!).
Perhaps you meant impetus?
https://www.merriam-webster.com/dictionary/impetus
I suspect that what actually killed this is the acquisition of Github by Microsoft and the fact that Microsoft are pushing VSCode very hard. Dev tooling is something Microsoft had a lot of experience (and failures) in and it was always an uphill battle.
It’s not free, but if you’re really strapped for cash you can use it like most people use Winrar, at least until the guilt overcomes you.
But it's still really sad to see. I use it because it was trivial to CSS style it to match my Desktop. It's comfortable to me in a way that other editors thus far have not been.
Are there other editors with this level of customizability? I know VSCode and Sublime support theming but from what I can tell it involves installing pre-packaged themes.
https://marketplace.visualstudio.com/items?itemName=be5invis...
Emacs can go from this: https://emacshints.files.wordpress.com/2013/09/spash1.png
to this: https://github.com/rougier/nano-emacs
https://code.visualstudio.com/docs/getstarted/themes#_custom...
You have to package it if you want to make it easy for other people to install, but if you just want to play with it, just open settings.json and start feeding it colors.
great fonts, minimal visual clutter etc
> View: Toggle Activity Bar Visibility
Much nicer, thank you!
For the colors at least, there are VSCode themes that will try to mimic it for you
I had to help a developer setup deploys to a dev server from vscode the other day and I wanted to pull my hair out. I'll admit it's at least in part due to not using vscode myself but I was a heavy Sublime Text user which is very similar to vscode when it comes to how you find/configure plugins.
I understand that vscode is very powerful and infinitely extendable but I feel like I shouldn't have needed to try 4-5 different vscode plugins (all configured via json) before I found one that worked and did what I needed.
At least 2 of the top downloaded plugins when searching for "SFTP" were read-only/archived on GitHub, the top one had a "reloaded" version which was also discontinued from what I could tell.
I'm comparing this experience to IDEA which has this built in (including support for deploying to multiple servers at the same time) and all configurable in the GUI.
Maybe I'm just getting old and cranky but vscode seems to get unwieldy very quickly (plugin conflicts, not being able to tell what's doing what, writing almost all config in json). The plugin ecosystem seems to be much lower quality that I what I see in the Intellij product line. I guess I'm just not interested in "building my own IDE" and forever tweaking it, I'd much rather buy a product that does almost everything I need in a sane way.
far better and faster than sftp
Of course I've heard of git and we use it, we just don't use local (on the computer we develop on) dev environments, we have a mix of developer-specific VMs and local physical hardware due to the nature of our business.
I have a few workflow-type things like this that I normally do via the CLI, but now I’ve added them as tasks to VS Code for convenience. I can also create the task at the project level and check in the JSON config so that teammates can use those same tasks.
The only possible wrinkle is the developer box needs the build toolchain. If you're writing python, your remote box obviously already has it to run your app. But if you're writing Rust or golang, it's very possible the remote machine doesn't have the compilers.
We're also talking about a dev box here, are we not?
What does this mean? Setting it up so you can deploy through GUI?
Everyone who uses VSCode has surely used an IDE before. It just turns out they aren’t better in every way, and possibly not in the ways that matter.
VSCode plug-ins just have more eyeballs and work done on them for various ecosystems, for example. Especially for less common languages and features.
Almost every junior I hire has only used Atom, Sublime or VS Code, especially JavaScript developers.
>VSCode plug-ins just have more eyeballs and work done on them for various ecosystems, for example. Especially for less common languages and features.
The reason to switch to an IDE from something more flexible like VSCode or Emacs is the amount of time spent keeping the editor working.
An editor will generally not stop working like a car without oil. But, IDEs may stop working due to more complex configurations and disparate use cases.
I would expect the opposite to be true. I could be wrong but it seems like the free editor that's mentioned in lots of tutorials would be the one newer developers gravitate to over a paid tool like IDEA.
I'm kind of surprised you did a deploy from VS Code. I would have assumed there was another tool for that. I do most of my git and ssh/scp stuff from the command line because I'm never quite sure what the tool will try to do to "help me out"
If you can develop 100% locally this isn't an issue but we can't (or haven't taken the time to do so). Think of the dev server as just a VM running locally and it might make more sense.
If you add any delays, any potential chance of forgetting a step, etc then it breaks my programming flow which can kill my productivity.
I mean, hell, just set up gulp/grunt/another task runner to watch your files and run scp if you want it continuously running? Why involve your IDE at all at that point?
I set it up to deploy on save of the file or when the editor loses focus (when it auto-saves). So while you are correct I have to do “something” to make it deploy that “something” is either a hot key or me clicking out of my editor into the browser to refresh the page (talking about PHP here, all my frontend Vue work I do locally with a watch script to rebuild on changes).
As a pure editor I prefer VSCode. It's fast and has a great plugin ecosystem. Another great feature is that it's config is just a JSON file that I can put into git and push it to my dotfiles repo making it easy to share config on all of my machines.
However, there's just some functionality in IntelliJ that I miss in VSCode like running tests. Of course there are plugins but they are all clunky and don't give you the great UX that IntelliJ does. I want the IDE to figure out where all the tests are and give me an easy way to run a single test/file/suite/feature. IMHO this is the killer IntelliJ feature for me.
I know a few people like this. More or less, they all got burned by some technical issue that made IDEA unusable for them one day, so they quickly cobbled together a bunch of extensions in VS Code just to get their work done and stayed.
I've been using VS Code for years to write JavaScript/TypeScript, Python, Go, Terraform, and CSS. My settings file is 60 lines, 42 of which are "for file extension X use autoformatter Y" configs.
When I first switched to VS Code I was frustrated trying to make it conform to random expectations I had. Eventually I learned that it's easier to embrace VS Code's defaults for 99% of things. I just want an IDE that works well (nearly) out-of-the-box and VS Code gives me that
I don't think it's a weird pattern, maybe a slightly legacy one but not out of the ordinary. I've seen this pattern used at multiple places (not implement by me). It makes sense if you have special use-cases where you need to use physical hardware and/or a local stack is too heavy or complicated to run.
Software should allow that. Especially software for writing other software.
VS Code is best when it’s just an IDE. I even have to drop into the terminal for some Git stuff
I don't know if you've just chosen to assume the worst or don't care enough to think about it for more than a second but I've been very clear in all my comments that these are developer-specific machines we are deploying to. It's literally no different from running VMs on your local machine. There is full visibility and feedback, we aren't deploying to Prod or even QA, this is development where each developer has 2 or more boxes owned by them and only them. We also are working with specific custom hardware that our code runs on which is one reason we can't easily do this locally.
To jump in and call that "worst practice" is just lazy and condescending. On top of that, it's completely wrong.
I never asked for or requested input on how we deploy code/manage our servers. I was asking questions about an IDE vs vscode and gave 1 example of trying to do the same thing in both of them. Had I known so many people would come out of the woodwork to tell me I'm doing it wrong without any idea of how our stack works I wouldn't have mentioned it.
I have no aversion to running shell commands and you are being disingenuous by saying that. I have a problem with manually doing a step that I can automate. I write and run shell scripts all the time for one-off process but seeing the code I've actively writing in an environment that can run it is not one of those cases. In fact, anyone doing that manually is just being silly or obstinate. If you aren't automating something that you do 100's+ times a day then I question your skills.
But one is free, the other is paid...
I used it for a year or so around 2015. It was a huge improvement over Eclipse, which is what I'd been using since this was at a Java shop, but even then I knew it was sluggish. I just assumed back then that you couldn't have IDE features without sluggishness. Now I know better
(To be clear I have no idea how VSCode's Java experience, specifically, compares with IDEA these days; I haven't written Java since 2015)
Also the default editor of the IDEA family is just unbearable (but there's the vim plugin for that, I guess), while Monaco is fine.
The only area where vscode is downright embarassing is interfacing with databases. In pycharm I can have a complete view of the database I'm connected to, run queries, get warnings and errors from inline SQL, and so on. Vscode has... strings?
If the remote capabilities get better, though, I'd admittedly have no reason to stay in the vscode camp.
Yep, I've tried Intellij several times over the past 5-6 years, but I've never really had an experience I liked. It's interesting that you mention SFTP and remote server deploys as a pain point for you in VS Code, because I've actually had a huge amount of frustration trying to do development over SSH in Intellij.. As of Intellij 2021 edition, I was completely unable to get ssh working from my work laptop to an EC2 instance; it could not parse my `~/.ssh/config`, and manually putting in the username, hostname, path to the private key, and even port 22 (because it literally required putting the port manually rather than defaulting to 22 unless stated otherwise), it would just say it failed to connect. The 2022 version has a "remote ssh" beta feature which also required manually putting in info that I felt like it should just be able to parse from my ssh config file, but it did connect and work for a week or two. One day it randomly started disconnecting a few seconds into loading a file continuously, which made it impossible to even scroll down into the file before it just zoomed me back up to the top. I gave up on it and just decided to stick with VS code for everything rather than try to get Intellij to work for the small amount of Java code I occasionally have to write.
Setting up ssh development with VS Code, on the other hand, was a breeze. The first plugin that came up when I searched "ssh" was Microsoft's own for ssh development, and running the command to connect to a server after installing it popped up with a list of my servers parsed from my ~/.ssh/config, which I could just select and it would connect (or prompt for a password if the ssh key required one). From there, I could easily open any project on my remote server, and VS Code even was able to detect which plugins I had installed for use with the project needed to be installed server-side rather than locally (e.g. the `rust-analyzer` plugin was installed remotely since it needed to run the daemon on the machine where the code existed). When I close my VS code window, shut down my laptop, and then the next day boot it up and open VS code, it still has the same files opened to the exact same spot (compared to Intellij's "scroll to the top of a file on connection" I mentioned before). I'm sure there are ways to get Intellij to work like I'd want, and I'm by no means a fan of Microsoft in general (I avoid Windows whenever possible and overall have a pretty negative opinion of them), but VS Code just absolutely nails the UX I want in an editor without needing that much custom configuration compared to what I've tried in the past with emacs/vim.
So I end up using IDEA if I'm working with Scala and Java at a job, Emacs if using Clojure, vim for those tasks that are kind of like using sed and awk but not quite, and for everything else, like Terraform, Python, shell, SQL, there's VS Code.
I was about to give up WebStorm the other day, but eventually got around it.
Jetbrains products are very good, but they feel a little "French" just like Macs: beautiful, but be aware that on some models the handbrake is on the same side as the door so you might end up tearing up your pants or bruising your thigh until you learn to be careful :-/
VS Code by comparison is very straightforward, but not always as sophisticated.
Personally I'd use NetBeans for backend and VS Code for frontend but because of Kotlin (which is great) I'm stuck with IntelliJ anyways.
But I just can't. My fingers are just too used to vscode, and I can do everything I need to. I feel like vscode is better at everything, and faster, except for the IntelliSense stuff. But lately I've tried GitHub Copilot and that just compensates it sooooo much, to the point I think it is even better than IDEA at suggesting stuff.
Also, working mostly with JavaScript and Typescript makes the difference go away (for me at least) as it is damn good at it.
Being free and open source also is a big plus for using it. And I love also how easy it is to configure... just a JSON with autocompletion for any setting you want to tweak. So much easier than having to mess with a ton of tabs and sections and search for settings, etc, etc.
But, if your language is not well supported in vscode, I agree Jetbrain's IDES are great and probably the best option out there. Specially IntelliJ if you're doing Java/Kotlin etc...
It's funny how we have such opposite feelings on config (you enjoying the json config and me preferring UI). I have nothing against vscode and I'm glad it exists, likewise I've very glad IDEA/Intellij exists for my own uses. Thanks for the feedback.
I strongly recommend everyone spend their first ~5 years coding in vim or some other basic text editor (preferably through the terminal), before leaning on an IDE to solve their problems for them.
That said, VSCode is now my go-to IDE, and I haven't opened WebStorm in probably ~6 months. It's lighter weight than the IDEA suite of IDEs, and gives me ~80% of the functionality, so it's been a pretty good tradeoff.
I actually dislike computer science classes which won't let me just use an IDE.
No one can memorize the .net 7 API
It's a pretty clear cut argument that using an IDE as a crutch will inevitably bite you in the ass, and if you want the best possible understanding of the language you're using and all of its related tools you ought not use an IDE as it obfuscates those very things you're trying to learn about.
Java IDEs seem to be living in their own world, but for everything else VSCode works well thanks to LSP. For example rust-analyzer works best with VSCode, and this makes VSCode the best Rust IDE.
Also, as of lately, copilot is saving me an insane amount of time especially when it comes to boilerplate and testing.
With gopls, vscode is MUCH faster than goland, especially on big repos, and I don’t need to watch the dreaded “Indexing…” all the time.
It misses some features, but honestly it’s so much snappier, so that wins for me.
I really wish the VS Code SQL/Postgres plugins would get there, but it’s a lot of work so I get that it probably will never happen unless Microsoft puts in the effort.
The situation now is:
* Sublime for the Williamsburg corpo-hipsters
* emacs and vim for the wizards and furries
* VSCode for all the normies who just want to get on with doing their job and don't feel a need to express their identity or politics through choice of editor
* WebStorm for the chads with the monster rigs to run it
I'm pretty sure Sublime has a plugin that uses an actual NeoVim instance to process all inputs with all your configuration. Never tried it, I don't use Sublime. But I can confirm the feature works well in Firefox via FireNvim.
I have to say that I built so much muscle memory in those years that it is kinda hard to realized I'm not using Vim, and there is always something not-quite-like-vim in VSCode-vim that usually gets in my way.
(To be honest, the only editor that I found that is really close to Vim without being a Vim-thing was GNOME Builder.)
…respectively? TIL I’m a furry.
Apple would try to switch everything towards their walked garden, no questions asked. Google would shut stuff down every two years. Oracle... I'm not even going to bother.
Amazon and Facebook could be interesting. Facebook is a bit shady, see the Oculus Facebook account debacle, but they're decent as stewards of dev tools. Amazon is also quite reliable for dev tools.
Would anyone really big be a better steward? Did I miss someone?
Facebook/meta seems horrifying. Some of their tools are indeed great, but I can just imagine having to use a facebook login to push code to GitHub or to download VSCode plugins.
Amazon is problematic for similar reasons as MS: since they are one of the biggest application hosts out there, bad incentives exist in terms of potentially allowing biases in their tooling to preference their own platform.
It's also noticeably slower than Sublime, which makes switching hard.
But "Williamsburg corpo-hipster" feels off the mark. To me Sublime aligns more around the "JS minimalist" camp, which overlaps a lot with the "bootstrapped and profitable" crowd.
I mean, just that phrase sounds very "Williamsburg corpo-hipster" to me. Minimal, artisan javascript.
The conflict between Catholics and protestants in northern Ireland is not actually about subtle differences in religious doctrine.
Right now I am using a very stripped down VSCode, which is.. fine. It works. I don't love it but it gets the job done usually.
Any other good editors on the minimal side? I need a bit more than vim/emacs, but I don't want or care for autocompletion or anything that alters what I have written. I don't need vcs support. I don't need a built in terminal. Just a good, simple and fast code editing experience with modern ergonomics and syntax highlighting that works across every language.
Seems like just another kind of identity: The self-titled "normie" who glances over at the "corpo-hipsters" and "wizards and furries" and smugly pats themselves on the back about how they're so much better because, unlike everyone else, they just want to "get on with doing their job"...
This entire time I thought I used Sublime because it was a fast enough, full of features, battle tested editor, that also wasn't a bloated IDE nor an exercise in self flagellation (i.e. choosing to use an command line editor with a high learning curve like Vim or Emacs).
Why not?
Reminds me of how Adobe killed off FreeHand (the only competitor to Illustrator at the time) by buying the parent company and then halting development.
Of course, Microsoft likely gave zero shits about Atom as a competitive threat since it was effectively dead at the time anyways, but I still think it’s interesting to see the similarities to the Adobe situation.
> Microsoft likely gave zero shits about Atom as a competitive threat since it was effectively dead at the time anyways
How can Microsoft both give zero shits because it was effectively dead, while also still being the primary reason it died? That seems to be a chicken-egg problem.
Would it have survived if Microsoft didn't acquire Github? It's possible, however unlikely. But after the acquisition? Not a chance.
The second big innovation was the language server protocol.This allowed any language to be supported by VS Code.
It also sounds like VS Code took a much more measured approach to extension APIs than Atom did. In Atom nearly every part of the product was an extension, which is a great approach to dogfooding extension APIs and making sure everything including the kitchen sink has an extension API, but getting that performant is tough. Whereas VS Code was very careful in the early days in what extension APIs they declared and started from a place of performance first. In many cases if only a single extension doesn't perform well in VS Code you almost don't notice because it's mostly isolated from the rest of application performance. Atom had a lot more situations, from what I heard, where one badly performing extension brought everything to a crawl.
On the topic of performance - one of the architecture decisions that VSCode nailed was the 'extension host' (https://code.visualstudio.com/api/advanced-topics/extension-...): all VSCode extensions are sandboxed in a child Node process, and can only communicate back with the main IDE process via the VSCode API. This has huge benefits for performance:
(1) extensions can never block editor startup. this was a huge problem for Atom as package loads were startup blocking and it wasn't uncommon to have multi-second startup times with lots of packages installed - especially due to the fact that JS packages typically repeat dependencies, resulting in tons of bloat. Also extension authors are rarely performance-conscious
(2) extension code can never block the core rendering thread, another huge problem in Atom - you'd often have stuttering/frame drops if extensions were doing blocking work on character or cursor changes, which was more often the case than not..
The tradeoff of course is that VSCode extensions are very limited in the set of UI customizations they can make but MS did a very good job of designing their APIs to be sufficiently extensible in this aspect (i.e. having APIs for extensions to hook into all core IDE features). Atom's extension ecosystem was much more fragmented resulting in dependency/versioning hell.
As a side note, another benefit of the extension host model is how it enables extensions to semi-magically work on remote filesystems (including inside WSL) without needing complete rewrites.
So end result is only editors exist are feature complete long time back/ or maintained by companies who could just give it for free, compensating it with cloud revenues. Besides a couple of paid editors with insignificant market share of course.
Idea stuff is just way too bulky for me. I don't like using any of them, sacrilegious as that may be, and don't feel the need to use them for since I don't use java. Paying for Sublime is just not worth it with its far poorer plugins and API and their release cadence is atrocious. I checked Nova from Panic out and it looks promising but it's VERY far from being a replacement for my current setup
So I see almost no reason to switch from vim and VSCode, both of which are free and have extensive plugin support and are great at what they do. If something comes along that is faster, has good language support and good list of extensions, I would have no trouble paying for it
Definitely is a software you can bet on.
It's not the lisp vm that incidentally happens to edit code that GNU Emacs is.
Or, as he puts it [1]:
> I use this abomination called "micro-emacs", which has absolutely nothing to do with GNU emacs except that some of the key bindings are similar.
[0]: https://github.com/torvalds/uemacs [1]: https://www.tag1consulting.com/blog/interview-linus-torvalds...
I see people complaining about the death of Atom, but in the past few years there just hasn't been a use case where Atom was the best choice.