Everyone seems to have an opinion on this topic of late. You may have seen: Second-guessing the modern web By Tom MacWright.
So I figure I'd throw...
For further actions, you may consider blocking this person and/or reporting abuse
Thanks for the heads up for TurboLinks & Portals!
BTW, before ASP.NET, Java way back in the day (when it was owned by Sun) was touted as a 'unified platform' for Front End to do what what ASP.NET also tried. Security issues & poor performance kept it from doing that.
See that's my fear. I'm unclear how the libraries looking to pull routing to the server in a client-friendly way(not full reloads) plan to get around state management. It'd be distributed, or the server would be stateful.. which is kind of scary. We lose a lot of the benefits of caching this way. I'm most interested to see what we can do with streaming. But even then, I think there should be a fallback for cached pages. Can a service worker even cache them in the same way?
I'm guessing everything goes though the Service Worker, so yes? But I'm no SW expert, I only really know them via scripts that come bundled with 'create app' toolkits, & via Cloudflare Workers.
github.com/tomByrer/awesome-cloudf...
What I mean is if you are streaming back a response with specific data from the server dynamically the value of service worker caching goes down. Like if you start combining your data with your static page, the static part is no longer cacheable in the same way. I think people who serve dynamic pages are used to this. But I wonder if we hit state where initial render and cached response needs to resolve data in a completely different way. So if the routing is happening on the server and it's keeping track of your state it needs to know what data has been fetched before what data is stale etc. I've come accustomed to client side caches keeping track of that. The client outliving the life cycle of any individual request. If both sides are keeping track they need to communicate that information back and forth. If you go to a page and then navigate right back to it maybe you don't need to load the data again. Maybe you don't even need to load the html again (if it is server rendered). There are a lot of nuances here when you are on both sides. It's lot easier to have a clear responsibility. I suppose service worker specific modules could handle those details and abstract them from the client but a lot of complexity there.
What if there was no state management in the backend, and everything moved to the frontend? Sort of like a backend in the frontend. And the actual backend just streams modules of code, compiled or not, as needed by the frontend as soon as the frontend hits calls into those modules; or it streams preemptively in the background for "adjacent" modules?
And when you need something else besides frontend code, like actual data to display, I guess just go the normal way, like we do it now: hit an API endpoint but use some client-side caching mechanism (possibly with local persistance) like SWR or react-query.
Of course, for low power devices, SSR might still be needed... so maybe a solution would be having a mirrored frontend context in the backend, including all frontend platform features (like those that should be provided by a browser). So like having to delegate everything but the presentation layer (the actual UI rendering), to the backend.
This might have security issues that can't be tackled... I'm not sure, but I can't think of a better way.
You might be interested in CloudFlare Workers to pre-render the content:
github.com/tomByrer/awesome-cloudf...
Definitely interested in this, serving from the edge seems really interesting.
Note: Turbolinks has been superseded by Turbo, a component of Hotwire (see this issue in the Turbolinks repo).
Hmmm....portals. I wonder if the page will be allowed to embed itself as a portal so we can make fractals like in powerpoint.
Anyways, great article! I found a lot useful tools and ideas from this.
Whenever Turbolinks come up I feel compelled to mention Unpoly.
It's Not You, it's Us We're Breaking Up with JavaScript Frontends
Comparatively speaking it may seem old school but so are Turbolinks.
Thanks a lot Ryan, looks like another 5 years of study for me.
Such a thorough article. Great observations Ryan! Thanks for this 🙏