3 ms·
One of the (several) unfortunate things about Atom being killed by VSCode was that its extension model was much closer to that of Emacs - everything ran in the
by throw10920 5y ago
One of the (several) unfortunate things about Atom being killed by VSCode was that its extension model was much closer to that of Emacs - everything ran in the main editor process - far more flexible than VSCode, but also with the mass-market appeal of JavaScript.
(yeah, that model led to poor performance, but afaict that's a combination of (a) just JS things and (b) not putting any effort into the design)
> I definitely don't have a lot of trust in Microsoft.
Very wise, given the user-hostile stuff they've been doing in Windows recently...
- smallnamespace 5y ago> (a) just JS things and (b) not putting any effort into the design This feels a bit self-contradictory, since one might argue a properly designed extension API must include process isolation, so naively-written extensions can't mess up the main loop. VS Code extensions are also in JS. This is the same problem that, say, preemptive multitasking solves, and why Windows 3.1 crashed much more than '95 and XP.