This is a pompously written puff piece. Moving logic to the client is the right choice for an application, and the wrong choice for mostly non-interactive content. Know what you're building and choose the right tools/use the right techniques.
Javascript has been (and kind of continues to be) a mess, but thankfully you can compile almost anything to WebASM these days, and 95% of people have browsers that support WebASM, so if you want to build your app in Rust with QT have at it.
> Moving logic to the client is the right choice for an application, and the wrong choice for mostly non-interactive content
Well then we're fucked. Juniors and a good chunk of intermediate level devs do not understand where one solution ends and another begins, let alone how they work or their trade-offs, so if we want things to not suck ass in the real world (where there aren't enough senior devs who actually know and care) we'll have to figure this one out.
My gut says that it starts with a solution similar to Qwik, but I haven't thought about the DX implications deeply enough.
JavaScript is a mess but HTML is a catastrophe. I don’t understand how JS gets so much flak when most of its shortcomings are actually shortcomings of HTML interaction.
> Know what you're building and choose the right tools/use the right techniques.
I feel that this is the author's point: in the modern era, the "right tool" is React (in the worst possible way and often because of ignorance). As the saying goes: when all you have is a hammer, every problem looks like a nail.
Javascript has been (and kind of continues to be) a mess, but thankfully you can compile almost anything to WebASM these days, and 95% of people have browsers that support WebASM, so if you want to build your app in Rust with QT have at it.