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

181–190 of 614 posts

Re: Atom was archived today

#181

Post by jiggywiggy »

rob74 wrote: post #37
p-e-w wrote: post #18

Earlier quoted context omitted.

Electron is essentially an operating system that runs on every operating system, so you can target just a single OS and your application works everywhere.

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

Thought the same. So was using teams and slack in the browser. But at least for new m1 Mac, resources for running a tab and a seperate electron app are pretty similar. It's scary how much memory certain latent tabs use, especially with video ads running.

Re: Atom was archived today

#182

Post by sgtnoodle »

p-e-w wrote: post #7

Sad to see this go. I was an early adopter of Atom, and I wrote two extensions for it, one of which while it was still in beta. The Atom developers made some technology choices that in retrospect were ill-advised, CoffeeScript being the worst of them and splitting everything into dozens of packages a close second. They tried to backpedal on both of these later on, but by that time VSCode, with its far superior engine…

I tried Atom for a while in Windows, but a file watching bug made it quite inconvenient. Every time I edited and saved a file in another IDE (at the time, I was stuck using it to compile and debug an embedded system), that IDE would rename the original to a temporary file in a temporary directory before writing the new version. Atom would follow the rename rather than re-load the new file at the original path. It would make the open tab useless.

I tried making an issue for it, but someone ranted on about moving files around on a Mac and then closed the issue.

I tried trying to solve the bug myself, but I got about 4 layers deep into callbacks across at least three different repos, and gave up.

Re: Atom was archived today

#183

Post by smaudet »

kiratp wrote: post #71
tikhonj wrote: post #34

Earlier quoted context omitted.

Two big ones I can think of: 1. Have your application look and act like a standalone application rather than a webpage—Chrome tried to support this with application shortcuts (or whatever they were called), but it never worked well enough 2. Give your application access to native APIs and capabilities that you can't get through the browser, like direct filesystem access

But it doesn’t act like an application. Most of the OS right click services, keyboard shortcuts, menu items are all missing. Accessibility tools don’t work.

It doesn't feel like one either. It feels like a shitty web page, and it costs 500$ to run. I can run apps in python and they don't feel the same way, never mind native.

Re: Atom was archived today

#184

Post by donatzsky »

satvikpendem wrote: post #113
JonathonW wrote: post #106

Earlier quoted context omitted.

Vim and emacs do not adhere to platform conventions anywhere, unless your platform happens to be "emacs".

They're all terminal apps so I'm not sure why platform conventions would matter. Sure some people use GUI wrappers but most people primarily use them in terminals which have the same conventions everywhere, generally speaking.

Emacs isn't really a terminal app, though. CLI is just one of several frontends.

And there are good reasons to prefer the gui version: https://irreal.org/blog/?p=5835

Re: Atom was archived today

#186

Post by satvikpendem »

kuratkull wrote: post #131
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…

If we're talking about professional tools i'm not sure if setting it up as fast as possible is the best productivity comparison. All good tools need getting to know them, and setting things up yourself (eg. in vim) means you also know how to fix any issues that pop up in the future. Installing a vscode plugin for playing around is great, but it doesn't automatically make you a professional and stable production envir…

On the contrary, working in a professional environment, almost no one I know is using vim or Emacs seriously day to day for coding. We all use VSCode because that is a tool that just works for our team and company. Having a unified tool set works wonders for group productivity, no more messing around with some employees not having a certain package and others needing to customize their vim configs. No, everything simply works, and we can focus on the actual coding rather than messing around with our configs.

Re: Atom was archived today

#187

Post by mnd999 »

steve1977 wrote: post #141
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 one of the greatest pieces of engineering of our time. That must be one of the saddest things I read this month.

No post body was provided.

Re: Atom was archived today

#188

Post by a2800276 »

p-e-w wrote: post #143
kuratkull wrote: post #131

Earlier quoted context omitted.

If we're talking about professional tools i'm not sure if setting it up as fast as possible is the best productivity comparison. All good tools need getting to know them, and setting things up yourself (eg. in vim) means you also know how to fix any issues that pop up in the future. Installing a vscode plugin for playing around is great, but it doesn't automatically make you a professional and stable production envir…

> All good tools need getting to know them Wrong. Good tools don't require that. Imagine someone showed you a complicated mechanical contraption and told you "it's a type of hammer, much better than the 'non-professional' hammer, but you need to 'get to know it' first". That product would be dead on arrival. Great tools are obvious in their base functionality and have optional additional layers that can be discovered…

There are more complex problems than "nail" requiring more complex tools than "hammer".

And even the hammer metaphor falls apart pretty quickly: compressor driven nail guns are commonly used.

VSCode is obviously has something going for it, else so many people wouldn't be using it. Vi and Emacs are also extremely popular and have been for decades.

Re: Atom was archived today

#189

Post by hnlmorg »

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…

VSCode is good but as someone who’s been writing software for nearly 40 years, I really feel you’ve over doing the compliments by a long long way.

Compilers, operating systems, browser engines (unfortunately) and reverse engineering proprietary hardware/firmware are all significantly harder challenges than writing an IDE.

in fact there have been excellent IDEs around for decades before VSCode came along. Yes the industry lacked an LSP but that doesn’t mean that languages severs didn’t exist before then, there just wasn’t a standard before so everyone did their own thing.

Having built in terminals isn’t a new innovation either. That is and always has been the norm.

And most of the other accomplishments aren’t any more unique either (eg lots of software projects have monorepos).

It’s ironic that you say VSCode is the greatest productivity tool in the history of software engineering when VSCode is dependent on so many pre-existing technology’s like Electron, web standards, GUI frameworks, compilers, operating systems, device drivers, etc. in the grand scope of the engineering, VSCode occupies a very small fraction of engineering effort and in a niche that was already crowded before it even entered.

Is it the best IDE on the market? some might think so. JetBrains certainly have their fans too. But even if it’s the “best”, it’s extremely hard to argue that it is that far ahead of the competition and that innovative to deserve the accolades you’re describing.

Post reply on HN