3 ms·

I didn't mean to imply that, if I did. That said, Atom and VS Code did gain a big market share of the text editor/IDE space pretty quickly, and the author calle

I didn't mean to imply that, if I did. That said, Atom and VS Code did gain a big market share of the text editor/IDE space pretty quickly, and the author called out Atom as something built on a web platform that was slow and bad because it was built on the web platform, and further implied that we could build better a better version of it if we abandoned the web platform. My point was just that the new editors were successful in the ways that they were (e.g. for web developers working with a quickly evolving language) precisely because of the fact that they were built on an extensible platform, and in spite of the performance issues. I was an Emacs user a few years back. Then I started writing more Javascript than lisp and picked up React. IIRC the point where I switched to Atom was when the emacs syntax highlighting packages were choking on es2015, but I could get support for JSX and stage-0 ES extensions if I used Atom. If Atom had been built with a focus on performance over extensibility, those features wouldn't have showed up as quickly as they did and I wouldn't have had any reason to consider switching. Atom was extensible (and not uniquely so) because it was built on a browser and didn't have to reinvent the language and concepts that browsers already had for building basic UI features. I'm not sure we're going to see a new, successful IDE for quickly evolving languages that does reinvent that wheel, as it seems the author is suggesting that we do, in the name of performance.

pseudalopex 8y ago
Even web developers have always used Sublime Text and Notepad++ much more than Atom in Stack Overflow's developer surveys. VS Code overtook Atom in 2017. GitHub completely rewrote Atom's text rendering last year. Both VS Code and Atom are migrating JavaScript code to C++. Maybe performance matters more than you think. Atom used TextMate language definitions until recently. VS Code uses an RPC protocol designed to let any editor support any language. Emacs just isn't very popular anymore. What "basic UI features" are easier to build in a browser?
- catpolice 8y ago
  That's interesting - I didn't know Notepad++ still ranked so high. Oddly enough, I'm actually pretty acutely aware of how much performance matters in this space - at my last job, I spent a year developing an IDE for a custom in-house language/environment with some unusual required features. I looked in to extending existing editors/IDEs. The web-based editors were too slow for my application (which required a very large number of page updates from remote sources) but extending the native editors was an unfathomable pain. When I looked into things that didn't use a browser back-end, I was budgeting a month just to learn enough about their plugin architectures to determine if what we needed was possible without rewriting the UI code from scratch, which I really wanted to avoid. From experience, working with raw Java/C++ UI toolkit code is a nightmare compared to html/js and requires orders of magnitude more LOC just to put anything on the screen that can be interacted with. In the end, I wrote my own web-based IDE from scratch, using a lot of application-specific performance optimizations that would be really difficult for a more generic, modular system (lots more care about what parts of the DOM to touch and when went directly into the parser than would have been possible with Atom/VSCode/CodeMirror/whatever at the time). I spent 6 months optimizing it and it was only barely fast enough that you could type at close to 60fps in big documents, but I don't think I could have made a native version that worked at all in that time. So I get it: performance is important, and there are cases where web-based things either don't cut it or are barely acceptable. My point wasn't that performance isn't important, it's that it's not the only concern and pointing to the relative popularity of editors over time still illustrates that. Notepad++ was released 12 years before VSCode (which has only been around for ~3 years) and has had better performance this whole time, but in the 2018 Stack Overflow survey, VSCode beats it in popularity. So performance can't be the overriding factor in its relative popularity - it became popular in spite of being slower than things that already existed. The author of the original piece argues that the whole web-stack is _wrong_ and should be thrown out and replaced with something else, because it's slow and people don't care about how easy it is to develop something if it's slow. I don't think that's true, and the easiest way to see that is to note that we already had faster things that were harder to develop and extend and they're increasingly being rejected in favor of the opposite.

pseudalopex 8y ago

Even web developers have always used Sublime Text and Notepad++ much more than Atom in Stack Overflow's developer surveys. VS Code overtook Atom in 2017. GitHub completely rewrote Atom's text rendering last year. Both VS Code and Atom are migrating JavaScript code to C++. Maybe performance matters more than you think. Atom used TextMate language definitions until recently. VS Code uses an RPC protocol designed to let any editor support any language. Emacs just isn't very popular anymore. What "basic UI features" are easier to build in a browser?

catpolice 8y ago
That's interesting - I didn't know Notepad++ still ranked so high. Oddly enough, I'm actually pretty acutely aware of how much performance matters in this space - at my last job, I spent a year developing an IDE for a custom in-house language/environment with some unusual required features. I looked in to extending existing editors/IDEs. The web-based editors were too slow for my application (which required a very large number of page updates from remote sources) but extending the native editors was an unfathomable pain. When I looked into things that didn't use a browser back-end, I was budgeting a month just to learn enough about their plugin architectures to determine if what we needed was possible without rewriting the UI code from scratch, which I really wanted to avoid. From experience, working with raw Java/C++ UI toolkit code is a nightmare compared to html/js and requires orders of magnitude more LOC just to put anything on the screen that can be interacted with. In the end, I wrote my own web-based IDE from scratch, using a lot of application-specific performance optimizations that would be really difficult for a more generic, modular system (lots more care about what parts of the DOM to touch and when went directly into the parser than would have been possible with Atom/VSCode/CodeMirror/whatever at the time). I spent 6 months optimizing it and it was only barely fast enough that you could type at close to 60fps in big documents, but I don't think I could have made a native version that worked at all in that time. So I get it: performance is important, and there are cases where web-based things either don't cut it or are barely acceptable. My point wasn't that performance isn't important, it's that it's not the only concern and pointing to the relative popularity of editors over time still illustrates that. Notepad++ was released 12 years before VSCode (which has only been around for ~3 years) and has had better performance this whole time, but in the 2018 Stack Overflow survey, VSCode beats it in popularity. So performance can't be the overriding factor in its relative popularity - it became popular in spite of being slower than things that already existed. The author of the original piece argues that the whole web-stack is _wrong_ and should be thrown out and replaced with something else, because it's slow and people don't care about how easy it is to develop something if it's slow. I don't think that's true, and the easiest way to see that is to note that we already had faster things that were harder to develop and extend and they're increasingly being rejected in favor of the opposite.