Earlier quoted context omitted.
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.
Is 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).
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.