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

Sunsetting Atom

github.blog

Post reply on HN
Print view View original

821–830 of 880 posts

Re: Sunsetting Atom

#821

Post by ClawsOnPaws »

polote wrote: post #690
ClawsOnPaws wrote: post #561

Earlier quoted context omitted.

Hey, Please don't forget about accessibility. Getting this right from day 1 will make your life a lot easier in the long run. If I remember correctly, I was never able to use Atom with a screen reader. Hearing custom UI already makes me nervous and I'm pretty sure I won't be able to use Zed with a screen reader either. Blind developers exist. Please don't forget about us. It's one of the few areas where we can actual…

It is normal to advocate for your needs but asking for it to be included from day 1 is weird. The same way you don't start a saas app with localization from day one. I'm not blind so for sure I won't really care about accessibility but honest question why not use an ide developed for blind people instead of using the same as non blind people?

> The same way you don't start a saas app with localization from day one. Believe it or not, my native language isn't English, so this doesn't make sense to me. > I'm not blind so for sure I won't really care about accessibility You should. You're not blind yet. You're not deaf yet. You don't have motor control problems yet. It does not take much to get there. One small accident and your life is changed forever. It's terrifying. > why not use an ide developed for blind people instead of using the same as non blind people? Because not only do those not exist, but that seems just a bit silly to me. Most operating systems provide pretty good means to make apps accessible. They usually have API's that, if implemented, will make your app work with whatever assistive tech you may use on that platform. Most apps work on Mac, most apps work on Windows. Linux is sadly another story, but even there we can at least edit text. What about tutorials? Courses? If we can't use the same software, should we also not be able to do any of them? Should we be locked out of great innovation because we need special software that nobody wants to update? Or worse, locked to one specific platform?

I believe I've said this before, but as sad as it is, every time I hear "Custom UI" I immediately think "Oh great, this won't work". In fact, I'm much more likely to give something a go if it's developed using web technologies. While not perfect, at least I know that there's a chance that it might work. It shouldn't be like that.

Re: Sunsetting Atom

#823

Post by ClawsOnPaws »

exysle wrote: post #656
ClawsOnPaws wrote: post #650

Earlier quoted context omitted.

My favorite is VS Code by far. I use it daily. They recently also added a bunch of sound cues to help figure out if code is folded or a line contains an error. It's pretty great. Auto completion reads well, the parameter hints read, even the built-in terminal works. So overall I'm really happy with it.

Would you mind commenting on XCode? I heard that Apple really cares about accessibility.

I don't have much experience with XCode, however the few things I did do seemed accessible. As accessible as XCode can be - I personally find a lot of the interface a bit confusing. Super long lists, nested options, but I assume those aren't things that are specifically confusing to people using assistive tech and I'm sure I'd be able to find my way around it well if I used it more. Mac seems to be a lot more consistent with their accessibility story than others, and we constantly get new features from them. With the new MacOS for example we got a VoiceOver feature that tells us when we have formatting problems in text, and we can finally get indentation announced (something which we had to do using custom scripting before). Not to mention all the cool things that involve some form of (live) image recognition, like telling us where people are, where doors are, etc etc.

Re: Sunsetting Atom

#824

Post by noobermin »

mumblemumble wrote: post #47
Doctor_Fegg wrote: post #7

“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.

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 i…

Then why did they say they are sunsetting it!? It's in the freaking article

Re: Sunsetting Atom

#825

Post by vintermann »

tikhonj wrote: post #513
gosukiwi wrote: post #478

Earlier quoted context omitted.

This is interesting. I wonder how Emacs solves that, given that it's one of, if not THE most, extensible editor out there. I'd think that is a good thing, but never considered the drawbacks, besides performance and plugin interop that is.

Design-wise, Emacs is less an editor with an API and more a set of core editing concepts (buffers, strings with properties... etc) embedded into a flexible language. The core concepts have a native implementation that's hard to change, but they're simple and flexible enough that you can put them together to do all kinds of text-editory (or even not-so-text-editory) things. Everything on top of the core is written in…

> it's difficult because substantial changes to the building blocks will change or break existing code in ways that are hard to control or predict.

This is a sign that emacs has too much extensibility (or, to be more accurate: too little isolation). It's been observed before that emacs really is the antithesis of the alleged Unix philosophy of "doing one thing and doing it well". It is an inner platform.

Re: Sunsetting Atom

#826

Post by PoignardAzur »

behnamoh wrote: post #718
ClawsOnPaws wrote: post #650

Earlier quoted context omitted.

My favorite is VS Code by far. I use it daily. They recently also added a bunch of sound cues to help figure out if code is folded or a line contains an error. It's pretty great. Auto completion reads well, the parameter hints read, even the built-in terminal works. So overall I'm really happy with it.

speaking of VSCODE, i wonder if MS acquiring github has anything to do with sunsetting atom.

It probably played a pretty big role. Everything Atom could do, VsCode could do better. At some point it didn't make sense to put man-hours into two different editors with the exact same technology stack.

Re: Sunsetting Atom

#827

Post by PoignardAzur »

niutech wrote: post #820
nathansobo wrote: post #253

Founder of Atom here. We're building the spiritual successor to Atom over at https://zed.dev . We learned a lot with Atom and had a great time, but it always fell short of our vision. With Zed we're going to get it right. Written in Rust, custom native UI framework, engineered to be collaborative. Just starting our private alpha this week, so the timing of this announcement feels quite fitting. Here's a talk I gave l…

Why not collaborate with developers of existing code editors such as Xi Editor ( https://xi-editor.io ) or Lapce ( https://lapce.dev ) instead of making yet another one? As for lightweight alternatives to Atom, there is also Lite-XL ( https://lite-xl.com ).

Speaking as someone involved in the Xi community, there's not that much to collaborate with. Work on Xi has completely stopped, and work on the Druid GUI framework is still in early stages.

I think it could be interesting to compare notes re GUI frameworks (especially since the Druid community is about to see some overhauls there) but I don't think it would have saved them that much work if they'd done that from the start.

Re: Sunsetting Atom

#828

Post by trasz »

Beltalowda wrote: post #657
trasz wrote: post #615

Earlier quoted context omitted.

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 hav…

>"I can do with the code what I want" is the entire and only point of Open Source

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.

Re: Sunsetting Atom

#829

Post by niutech »

mynegation wrote: post #398
sdfhdhjdw3 wrote: post #358

Earlier quoted context omitted.

Humble question, I don't mean to sound confrontational, I ask of genuine curiosity: Why not contribute to VS Code instead? For Julia, Atom+Juno was excellent. It was the first time I could select+run on a proper IDE (I was coming from python+notebook). To me this was revolutionary. Then I discovered VS Code, so Atom+Juno stopped making sense. You seem to be a very competent developer, so why not just contribute to VS…

If nothing else, Atom was the birthplace of Electron.js and I know it is controversial, but Electron was a boon for the rapid development of cross-platform desktop applications. VS Code was built - in turn - on Electron. We need people like nathansobo to try out new ideas and directions. I, personally, am very much looking forward to their WebAssembly-based extension system and Zed being the flagship UI application d…

There is also NW.js (f.k.a. Node-Webkit), which was preceding Electron and was also a foundation for a lot of apps: https://github.com/nwjs/nw.js/wiki/List-of-apps-and-companie...

Re: Sunsetting Atom

#830

Post by mwcampbell »

bscphil wrote: post #665
Matl wrote: post #441

Earlier quoted context omitted.

A lot of people started to refer to Qt as native around Electron's time. The only place where Qt is native as such in on a KDE Plasma/LxQt desktop.

You're correct, although Qt attempts to do fake native widgets on Win / Mac, and given how relatively lightweight it is compared to Electron, it's understandable how it became a obviously point of contrast with the latter, which doesn't even pretend to be native. Given a choice between the two I will obviously take fake native widgets over nothing.

I, on the other hand, will take whichever widgets have the better accessibility implementation. Currently Electron beats Qt on this.
Post reply on HN