Hacker News new | ask | show | jobs
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.

2 comments

The reason frameworks usually don't run in a worker thread is because it is difficult to efficiently cross the barrier between workers and the main thread. Either you need a shared array buffer or the contents of your messages have to be copied on write. Even web assembly has similar issues as it runs in the same thread as any JavaScript you have.

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.

I've done some experiments in regards to a message service. And though a lot of this work isn't ready for production I have seen a lot of success. Long story short SSR to rebind via webworker. Unfortunately it's just one of many experiments that are way back in my todo list now.
> And by and far I believe that is the real issue in the industry.

Why? What problem does it solve?

Just better point out where dev's haven't been trained and are just doing their best. It's a large topic and not every company can keep a high standard.

But most complaints I hear on the topic is the same criticism of js in general. So much rope you can hang yourself with.