|
|
|
|
|
by rellekio
2367 days ago
|
|
I understand the pressure on js frameworks and the like. Even Microsoft attacked the same problem with Blazor. But the original goal of these frameworks is and still is portable code. I might be the rare engineer whose work flow is accelerated by these frameworks, but I also carry an approach to creating well patterned interchangeable components. And by and far I believe that is the real issue in the industry. However if we are talking about speed. I do agree. But that is because to me it is madness to have these frameworks sitting on the main thread. And should be concurrently offloaded to a worker. Reactor's concurrent mode is also a great stab at this problem. Howver I believe the point is missed. Being the only bindings a framework should have on the main thread is it's interactions with the dom. Everything else, including the virtual dom should be on a different thread. So while I understand the push back, I believe people are missing the point. These frameworks have been implemented in the easiest fashion and have matured. But now that we can rely on multiple cores and ht. There should be a response. Not to mention Web Apps vs Web Sites. We need to make that distinction, especially in line with wasm now being matured. Edit: As for serverside rendering. If your backend engineer can't figure out how to cache this. I question the hire. |
|
I do agree about making the distinction between sites and apps though. A lot of the contortion frameworks do is to avoid triggering layout excessively. You can't even get the position of a DOM element without layout rerunning to figure out where it should be. I suspect a lot of these quirks are legacy web behaviors more applicable to sites than applications.