This is hilarious. People suddenly realising servers can render web pages and web pages can function without JS. None of this shit is new. Give the people who worked this out a pat on the back - they're like some kind of bad-ass Indiana Jones code archaeologists who've deciphered the ancient secrets
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.
I think the obstacle.. and really hardly one, is the desire to preserve developer experience of writing client side apps. That's the goal. Mind you these developments could have happened at any point (including right at the beginning of these technologies).
So "why now?" is what I have been exploring and I think there are a few factors some of which are basically this technology built for apps which are actually a much narrower band of the whole range of websites are being desired more and more to be pulled into simple sites. I've found myself having to train against a different perspective. Like explaining normal web operation as MPA is definitely humorous at times.
It isn't like the creator of these libraries weren't aware of this stuff years ago. Like the Remix guys (behind React Router for years) clearly point out that they have always been able to do this if they wanted to and seem to view their library as a sort of retro thing (even with branding).
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.
This is hilarious. People suddenly realising servers can render web pages and web pages can function without JS. None of this shit is new. Give the people who worked this out a pat on the back - they're like some kind of bad-ass Indiana Jones code archaeologists who've deciphered the ancient secrets
Everyone knows that, the problem is you want CSR experience in static or server rendered apps in the time you mean this was not solved yet.
This was solved way over a decade ago
What was solved? You mean SSR is the solution? Don't know but SSR is far away from desktop expirence.
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.
I think the obstacle.. and really hardly one, is the desire to preserve developer experience of writing client side apps. That's the goal. Mind you these developments could have happened at any point (including right at the beginning of these technologies).
So "why now?" is what I have been exploring and I think there are a few factors some of which are basically this technology built for apps which are actually a much narrower band of the whole range of websites are being desired more and more to be pulled into simple sites. I've found myself having to train against a different perspective. Like explaining normal web operation as MPA is definitely humorous at times.
It isn't like the creator of these libraries weren't aware of this stuff years ago. Like the Remix guys (behind React Router for years) clearly point out that they have always been able to do this if they wanted to and seem to view their library as a sort of retro thing (even with branding).