4 ms·
While this is obviously a great demonstration as to why you wouldn't do something silly like build an entire code editor in the browser for day to day use (beca
by SilverBirch 4y ago
While this is obviously a great demonstration as to why you wouldn't do something silly like build an entire code editor in the browser for day to day use (because it would be slow and clunky and have all sorts of issues), it's great for a accessibility when you don't need performance at all.
- e12e 4y agoIs this a snide comment on Atom and VS code? (I do think they're "slow" but not necessarily more than non-web rich IDEs - just compared to something like vim with conservative config/plug-ins).
- kmacdough 4y agoI don't think so. VSCode, Atom (and Jupyter) all run natively, only using a browser renderer for UI. Jupiter already uses a browser as the front end, but the kernel runs natively. JupiterLite runs entirely in the browswer, including the kernel. This means you don't need Jupyter installed or running on a server to execute the kernel. But it also means the kernel is running much slower in Web Assembly.
- SilverBirch 4y agoYeah I’ve had a slowly bubbling level of hatred towards vscode for the last few months. Because it’s heft it’s absorbed all the plug-in ecosystem but it’s like sublime text left the sunroof open and now everything is soggy.
- cyanydeez 4y agoThere's definitely a noticeable input lag in vscode. I basically nerfed the vscode language features which make it more manageable. But sublime still feels far more responsive.