I don't understand what prevents actors like Microsoft from doing a clean, lightweight, native rewrite of tools like Visual Studio for people who are looking forward into the .NET 5 horizon, and don't care about being able to debug VB.NET apps written in 2009. There is no reason there has to be any delay at all in the UI. Graceful degradation of intellisense is acceptable depending on project complexity, but there should never be any sort of perceptible hitching or delays when moving code windows around, scrolling, typing, switching tabs, minimizing/maximizing, etc. If my PC can display the complex 3d scenes of Overwatch at 2560x1440p@180FPS with <5ms input latency, I cannot comprehend any rational argument for my IDE being unable to achieve even 10% of that performance objective.
I understand that use of frameworks like ElectronJS make it virtually impossible to achieve my stated objectives, so perhaps we need to dust off some APIs and re-learn old tricks. Think about the aggregate developer hours that could be saved with 1 heroic implementation effort. Imagine if you could load a VS solution in less than a second and immediately start clicking through the UI in any direction without any fear that it is about to sandbag your ass with frustratingly-arbitrary UI delay soup. That is the kind of UX that inspires confidence and encourages a developer to charge forth, instead of compelling them to fuck off on HN for the 20th time of the day.
I keep wishing for the day that VSCode team finally replaces its engine with one based on React Native and then Electron gets its first fatal blow.
Meanwhile, https://www.windowscentral.com/xbox-app-pc-gets-speed-boost-...
Which would be never, since tons of VSC functionality is based on the ability to create ad-hoc widgets (through HTML).
I'd gladly jump ship from Electron as soon as there's a viable alternative, but we can't forget that it's lack of cross-platform support that got us here in the first place!
Electron as idea of shipping a full browser alongside the application has already been born multiple times, just it got luckier this time with the amount of devs that aren't willing to actually learn anything else.
2. I understand that sublime is closed source and respect that, but would sublime ever release or talk about how they develop their GUI? What libraries and techniques they use?
As a hypothetical example if we used GTK instead and it's rendering implementation was designed to be CPU based - say it's based on direct pixel manipulation by passing around a texture - if we wanted to be performant at high resolutions we'd have to refactor/rewrite large parts of GTK to use GPU rendering instead. That would mean either working with the maintainers to get something they'd be happy merging, then doing the work for all of gtk, or forking gtk ripping out the parts we don't use and just refactoring those. The latter would be significantly less work and the likely choice, so we'd likely end up in the same place as before.
Sure, we've got Sublime Merge 2, but hardly anything for Sublime Text in almost a year (since last September I believe).
And it's not like ST is done and perfect for eternity -- there are several issues still and lots of ways VSC has an edge for example...
Interestingly gvim had the lowest latency in this test. I wonder if that’s a side effect of it being written largely in C (Sublime Text uses a proprietary cross-platform C++ framework).
Maybe you should reconsider.
My definitions:
* hard real time: people will die or things will be destroyed if a certain block of code is not executed within N msecs of something happening
* soft real time: nobody will die but things only really work correctly if a certain block of code is not executed within N msecs of something happening
I write soft real time for a living (a multiplatform DAW). We have to go to great lengths to ensure performance, and we do things that you will NEVER(1) be able to do in a browser.
(1) for any reasonable definition of NEVER
Obviously, one can do music creation and audio processing in a browser.
The parameters that matter are what N is in the "N msecs" I mentioned above, how much audio (e.g. tracks) and how much processing (i.e. DSP).
When you make N small enough, make the track count large enough, and do enough DSP, it's never going to work inside a browser (it sometimes won't work outside the browser).
If N is large enough, the track count small enough and/or there's not too much DSP going on .... have fun!
But the ease with which apparent guarantees are tossed around by browser documentation (with regards to time) only to see them solidly trashed in real life is depressing.
There are plenty of reason why a lot of modern software is slow, but size of executable isn't even in the top 10.
I’m sure there are others but these are the two the come to mind.
https://mspoweruser.com/xbox-pc-app-gains-huge-performance-g...