MS also competes with GitHub also; Azure Repos are a thing, as is Azure DevOps and those are just two examples. MS has plenty of products that compete with each other.
In some spaces this is a good strategy as you will capture more market share with two products than you will with one and you can avoid to an extent monopoly claims.
GitHub Codespaces is what killed Atom and while MS was probably involved in the decision to develop Codespaces, the decision to sunset Atom likely wasn't explicitly made at that time; its simply a side affect as other things have eclipsed Atom.
Maybe it's just me but I'd not judge things like that on the first non-public beta.
https://twitter.com/Kristy_Viers/status/1287189581926981634
You can turn on the various accessibility features and try them yourselves. While I was already aware of the 'voiceover' features, I was blown away by the braille keyboard and how quickly she could type with it.
Blind people use TTS set at ridiculous speeds that make my 1.5x podcast playback seem glacial. Even back in the late 80s I remember a blind classmate who had a portable electronic typewriter thing that read her entries back to her at rapid speed.
Just pop open the console with F12, enter the following and hit enter:
$('video').playbackRate = 2.5
Change `2.5` to whatever number you wish.
Press up in the console to bring back your last command faster with the cursor at the end so you just delete the number, type a new number and hit enter.
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?
Adding accessibility for screen readers is much more difficult to add later in the project lifecycle. Thinking about those design considerations early makes a big difference in how accessible it will later. If developers don't think about these things early, most likely the product will never be fully accessible, ever. Blind people have seen this played out before with other software products and know where this path leads.
(I'm not blind but have worked with blind developers. I'm not an expert in accessibility but I know enough to know how important it is to listen to accessibility needs)
You start an editor with extensibility from day one, as well as theming from day one, as well as multi-platform from day one, etc.
Why should it be different for Localization or Accessibility?
Imagine if you can code screenless. Headaches in response to light? Not a problem. Avoiding screens at night to wind down for sleep? Solved. Eyesight deteriorating (a totally normal thing that comes with age)? No new tech or ecosystem to need to adapt to, everything is already there.
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.
Approaches like yours are why people who are differently abled feel left out and like second class citizens a lot of the time.
I recently had a scare with my eyes. Freaked me out. I started looking at my developer tools completely differently. You are not out of the woods buddy. Anything can happen tomorrow. :)
It’s also for users with poor eyesight, colour blind folks or folks with motor impairment.
It can happen to any of us and then you’d be glad that developers are taking accessibility standards seriously.
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 actually make a meaningful difference together with our peers on an equal playing field.