It's possible. I feel a decade or so back we were just beginning collectively to understand how client-side state played in into the equation. If I've seen anything is that a lot of ideas predate when they have been popularized. Certain things are still coming to React that have been in Marko since 2014 and were leveraged by Facebook's PHP setup back in 2008. Similarly this sort of client router driven modelling native DOM approach existed in frameworks like Rill in 2016 even using React so definitely Remix isn't the first.
So I'm open to see where we've seen this before. I imagine elements of this may have made it into Meteor. But a solution like HTMX is not this and doesn't solve the problem in the same way. Not undercut it as an architecture for isomorphic development, but specifically I don't believe we've seen client centric universal solutions until more recently. Marko might be the first one to actually have pulled it off. But it's clear it will have company in the coming year.
Way over a decade ago seems unlikely mostly on the ground that the performance and capability of JavaScript are essential and limiting factor here. In theory that puts us in ~2008 about the earliest such a solution would likely be beneficial. Maybe 2005 with the advent of AJAX but it would be pretty poor compared to outgoing solutions.
Honestly if you know a project like this I'd love to see it. I'm super interested by framework design decisions and how they reflect the trends/thinking of the time they orginated. Please share.
I think the only method that can compete with native and make SSR completely obsolete is SSG with some technique to regenerate dynamic data, Next js has ISR for example which is amazing but there is still a small gap where a few users see the old version until the site is regenerated, if we close this gap completely for example with the help of web-sockets or so then there is no need for SSR anymore, I didn't test this but how I imagine ISR to have no stale time is having a small bit of client code always running and if the Connection detects new data it serves it instantly client side for a few miliseconds or seconds until the page is regenerated and then switches back to static.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It's possible. I feel a decade or so back we were just beginning collectively to understand how client-side state played in into the equation. If I've seen anything is that a lot of ideas predate when they have been popularized. Certain things are still coming to React that have been in Marko since 2014 and were leveraged by Facebook's PHP setup back in 2008. Similarly this sort of client router driven modelling native DOM approach existed in frameworks like Rill in 2016 even using React so definitely Remix isn't the first.
So I'm open to see where we've seen this before. I imagine elements of this may have made it into Meteor. But a solution like HTMX is not this and doesn't solve the problem in the same way. Not undercut it as an architecture for isomorphic development, but specifically I don't believe we've seen client centric universal solutions until more recently. Marko might be the first one to actually have pulled it off. But it's clear it will have company in the coming year.
Way over a decade ago seems unlikely mostly on the ground that the performance and capability of JavaScript are essential and limiting factor here. In theory that puts us in ~2008 about the earliest such a solution would likely be beneficial. Maybe 2005 with the advent of AJAX but it would be pretty poor compared to outgoing solutions.
Honestly if you know a project like this I'd love to see it. I'm super interested by framework design decisions and how they reflect the trends/thinking of the time they orginated. Please share.
I think the only method that can compete with native and make SSR completely obsolete is SSG with some technique to regenerate dynamic data, Next js has ISR for example which is amazing but there is still a small gap where a few users see the old version until the site is regenerated, if we close this gap completely for example with the help of web-sockets or so then there is no need for SSR anymore, I didn't test this but how I imagine ISR to have no stale time is having a small bit of client code always running and if the Connection detects new data it serves it instantly client side for a few miliseconds or seconds until the page is regenerated and then switches back to static.