While I agree with the author on many fronts[0], > For example, Blazor framework, which uses WebAssembly to run C# code directly in the browser [17]. No bi

While I agree with the author on many fronts[0], > For example, Blazor framework, which uses WebAssembly to run C# code directly in the browser [17]. No bizarre syntax, no winding code flow, no infrastructure madness and, especially, no bad performance. This is simply not true. Performance here is objectively bad since the payload is quite large. Also, I would comment that the DX with Blazor is not very good overall. For all the things broken with JS UI dev these days, DX with hot module reload is quite a marvel that I wish more platforms could achieve (C# kinda has it). My team recently did a large browser extension project and ended up using jQuery and web components. One of the younger devs made a humorous comment like "Why does this feel kinda nice?" (paraphrase). We've somehow been convinced that direct DOM manipulation is a no-no when in fact, it's performant and the DOM itself can represent the state without the need for complicated solutions like VDOM diffing. (I don't know about other teams, but even if I plan to use React, Vue, or other front-end libraries, I'd interview candidates on raw HTML+JS+CSS first.) But yes, overall, the pain is very real. A recent pass with npkll[1] freed 20+ GB of disk space.... [0] https://chrlschn.dev/blog/2023/02/react-is-the-new-ibm/ https://chrlschn.dev/blog/2023/02/react-is-the-new-ibm/ [1] https://npkill.js.org/ https://npkill.js.org/