Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Atom was archived today

github.com

Post reply on HN
Print view View original

311–320 of 614 posts

Re: Atom was archived today

#311

Post by danwee »

dcchambers wrote: post #25

I resisted switching to VS Code for a long time because I far preferred the UX and design of Atom, but I eventually caved not because of performance gains I wanted in VS Code (honestly I found Atom plenty fast for the work I was doing), but because many Atom extensions were left to rot and slowly broke over time as most maintainers moved to VSCode extensions. Farewell friend, you will be missed.

I cannot stand VSCode UX/UI. Not sure how this is not an issue for everyone. Maybe I'm just too picky. For this kind of things I don't use VSCode:

- The right side bar is "dynamic". Most of the time it's the Explorer showing the directories and files, but when I try to search for something, though, it becomes the Search sidebar. Same for all the potential sidebars (Source Control, Run and Debug, etc.)

- Everything is a plugin. That means I need to carefully check who's the author of the plugin, probably check as well the source code to avoid using malware, etc.

- Everything is a plugin. That means I need to craft a set of plugins in order to work in certain projects. I prefer JetBrain's approach

- No floating windows. Maybe I'm old-fashioned, but I prefer that, for instance, Settings to be opened in its own window, instead of opening a new tab in my editor. Also all the Settings in VSCode are on the same "page" (sure, whenever you scroll, the left-side grouping of Settings is updated accordingly, but imho it's difficult for me to focus on the section I need to work on)

Re: Atom was archived today

#312

Post by noufalibrahim »

p-e-w wrote: post #115
JonathonW wrote: post #90

Earlier quoted context omitted.

"VSCode is the greatest productivity tool in the history of software engineering" in a world where vi and emacs exist seems like a bit of an exaggeration, and I'm not even a fan of either (VS Code is my daily driver; I like my GUI editors and I like them to behave like normal apps on the platform I'm running).

Vim and Emacs cannot compare to VSCode when it comes to productivity. With VSCode, you type the name of any programming language in the extension search, click "Install", and you have a world-class development environment for that language ready to go. This is light years ahead of the traditional editors, and saves many hours of time. Not to mention that VSCode has countless other productivity boosters built in which…

I think there's a difference in the approaches. Emacs (and vim though I use the former) is like an old multi tool that has been with you on every programming or technical journey you've ever made. Scars, patches, customizations and everything else. It fits like an old glove and in most (though not all) cases, this comfort and the resulting productivity is far greater than a new editor that does "everything right" out of the box.

Re: Atom was archived today

#313

Post by underbrush »

hnlmorg wrote: post #189
p-e-w wrote: post #75

Earlier quoted context omitted.

VSCode is one of the greatest pieces of engineering of our time. It's really only when you compare it with Atom that you realize how great it is. Atom was built by incredibly smart people, who had full control over the platform and several years of head start, and they were still out-engineered by the VSCode team at every turn. VSCode did almost everything right: The choice of TypeScript as the base language (with wh…

VSCode is good but as someone who’s been writing software for nearly 40 years, I really feel you’ve over doing the compliments by a long long way. Compilers, operating systems, browser engines (unfortunately) and reverse engineering proprietary hardware/firmware are all significantly harder challenges than writing an IDE. in fact there have been excellent IDEs around for decades before VSCode came along. Yes the indu…

I agree that it is an exaggeration to call it the greatest pieces of engineering of our time. Still there are many technologies that are well liked but haven't developed in many years. There are many technologies that are here today but severely limited. And there are many technologies which promises potential for something better in the future. There are very few pieces of software that are here today and ticks a lot of the boxes of computer science. That are open source, cross-platform, extensible and has a modern stack.

> browser engines (unfortunately)

I often wish it wasn't so but the reality is that a shit ton of development has gone into browsers and in many cases other areas just aren't comparable. Even more so considering most resources go into proprietary technologies.

> reverse engineering proprietary hardware/firmware

As as side note reverse engineering hardware can certainly be very hard. It is also something that can gather far more credit than it probably should compared to actually engineering a solution in the first place.

Re: Atom was archived today

#314

Post by GTP »

By looking at the other comments, I see the seemingly unavoidable discussion over which is the best text editor/IDE. My opinion on the matter is the following: the best text editor/IDE(/many other tools) doesn't exist. What exists is the best tool for you. Each one of us has it's own opinion based on its personal experience, and it's baked by arguments that stem out of what we find most important in those tools. The problem arises when, after picking what is the best tool for me, I forget about the last two words and it becomes the best tool. Each one of us is the most productive when it's using its own favorite tool, but it doesn't mean that if I convince someone else to switch to my preferred tool, then that person will be more productive. Each one of us has to see for him/herself which tool suits him/her best. It is fine if we suggest other people to try our tools for some reasons, but it makes little to no sense to argue that our favorite tool is objectively the best one.

Re: Atom was archived today

#315

Post by zppln »

p-e-w wrote: post #75
esprehn wrote: post #32

Earlier quoted context omitted.

Atom predated the LSP and leaned heavily into customizations with all the plugins running inside the UI thread (more like a traditional web page and 3p scripts). At the time they viewed the extreme customization support as a feature, and there was a thriving ecosystem of folks making plugins. That architecture has a major flaw though. A default install was fast, but a real configuration with all the plugins ended up…

VSCode is one of the greatest pieces of engineering of our time. It's really only when you compare it with Atom that you realize how great it is. Atom was built by incredibly smart people, who had full control over the platform and several years of head start, and they were still out-engineered by the VSCode team at every turn. VSCode did almost everything right: The choice of TypeScript as the base language (with wh…

I seriously don't understand the hype around VS Code. I find it atrocious. The UI is complete trash.

Re: Atom was archived today

#316

Post by waitwhatt »

https://old.reddit.com/r/AMA/comments/8pc8mf/im_nat_friedman...

> I’m Nat Friedman, future CEO of GitHub. AMA.

> Atom is a fantastic editor with a healthy community, adoring fans, excellent design, and a promising foray into real-time collaboration. At Microsoft, we already use every editor from Atom to VS Code to Sublime to Vim, and we want developers to use any editor they prefer with GitHub.

> So we will continue to develop and support both Atom and VS Code going forward.

> So, I love the years of collaboration between Microsoft and GitHub that have produced these two beloved editors, and I expect this fruitful relationship to continue!

And... no you won't. You make decisions that weren't your's to make.

Re: Atom was archived today

#317

Post by Narann »

I used it as a tuned Markdown editor and it was a blast. Had to switch to VSCode and depicts it's very fast, I don't like the experience.

Any good Markdown editor to recommend?

Re: Atom was archived today

#318

Post by klabb3 »

ly3xqhl8g9 wrote: post #201
rob74 wrote: post #37

Earlier quoted context omitted.

Yes, and that's exactly what people hate about it: every application written in Electron lugs around its own copy of this OS. You can imagine why this might not be a good idea, especially for applications designed to run in the background, like the Slack client. For me, it was a godsend when Slack decided that my Linux version was too old to support and the client stopped working. Then I switched to the in-browser ve…

With regards to various applications, the question seems it is not if Electron is fit for them, but if they really need to be a "native application". Why does a chat application need to have it's own native package and can't run in a browser tab? With all the recent development on WebRTC and even File System Access API, can't really find a sole reason* (but feel free to point them out) for 99% of Electron application…

When you start building an app that does anything more than what a typical website does – basic stuff like keeping some persistent files, drag and drop, notifications, minimize to tray, using threads, the html5 apis are widely insufficient, performs poorly or – in the case of webrtc – massively over-complicated). They’re (rightfully) designed for the browser with its ephemeral untrusted model.

It’s a shame, because cross platform app building, distribution and updates is a shitshow, even with electron, putting extra labor on the developers, so neither party is happy.

That said, some apps should really be web apps, but are still bundled as desktop apps purely for the frameless “premium” experience, and I assume to not be lost among 100s of tabs. It would be great if there was better browser support for allowing users to “install” web apps, but right now the support for that is pretty poor in terms of UX.

Re: Atom was archived today

#319

Post by Jorengarenar »

rahen wrote: post #231
p-e-w wrote: post #115

Earlier quoted context omitted.

Vim and Emacs cannot compare to VSCode when it comes to productivity. With VSCode, you type the name of any programming language in the extension search, click "Install", and you have a world-class development environment for that language ready to go. This is light years ahead of the traditional editors, and saves many hours of time. Not to mention that VSCode has countless other productivity boosters built in which…

Reading such posts really makes me wonder how people wrote UNIX (up to V7) with just ed and an ASR33. And productive, they were. I've seen some old timers on ACME who dislike even the "distraction" of syntax coloring with modern editor such as vim. I wonder how they would fare with something like MS VSCode.

>the "distraction" of syntax coloring

Also known as "spitzensparken blinkenlichten"

Re: Atom was archived today

#320

Post by Beltalowda »

rtpg wrote: post #155
JonathonW wrote: post #90

Earlier quoted context omitted.

"VSCode is the greatest productivity tool in the history of software engineering" in a world where vi and emacs exist seems like a bit of an exaggeration, and I'm not even a fan of either (VS Code is my daily driver; I like my GUI editors and I like them to behave like normal apps on the platform I'm running).

Of course a lot goes on but pre-LSP and post-LSP are day and night. There is now a huge amount of serious language tooling that _isn't_ locked up into one or several editors. Now some might point out that LSP-based stuff is, like, bloat. Sure, OK. But there's a lot of motivation to do work that can pay off across the board. So much language stuff was based off of random regexes! It's hard to overstate how much better…

LSP is nice, but it's not an engineering marvel. It's just a text protocol. It's not even a great text protocol; it's okay, but not great. There's been lots of "LSP-like" protocols over the years, even decades, it's just that none of them really became a standard (partly because no one actually invested the time in writing one, and it just used an "ad-hoc protocol"). And of course the general concept of "process A communicates with process B over a text protocol" is all around us.

Like I said, I like LSP, but a great exceptional feat of engineering it is not.

This applies to most of VSCode as near as I can tell.

Post reply on HN