WASM-side rendering. :)
Getting shivers, sounds like reincarnation of Flash websites.
Still haven't replaced half the functionality of flash websites. So many flash games are gone forever.
The future (and the past) of the web is server side rendering
131–140 of 371 posts
Re: The future (and the past) of the web is server side rendering
#132"The future of the Web is what suits our business model" /s But in all seriousness, the web has websites, it has apps, it has games. Pick a tool that's appropriate for the job and forget about what is the past/present/future.
The rise of metaframeworks is interesting because it brings nuance to this. The line between site and app can be blurry. For example, my app has a main screen that needs to be client rendered. It also has a user settings screen that could be implemented as a traditional server rendered page with no JavaScript, except it's a lot more practical to build everything inside the same project and technology. Apps and their…
Pardon my ignorance, but what do you mean by metaframework?
I just learned about Astro the other day. It allows you to blend components from SPA frameworks together. Is that what you mean?
Re: The future (and the past) of the web is server side rendering
#133You can do HTML templating directly in JS using tagged template literals[1], and a library to deal with problems like XSS attacks[2].
[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Re: The future (and the past) of the web is server side rendering
#134Earlier quoted context omitted.
> you can usually cache the entire client side app so that the browser doesn't have to hit the network at all to start running client side code This is also true for Web apps that do not have meaningful amounts of client-side code. > Caching also works for client side rendering There are obviously a lot of differences in how caching works, but client-side caching is generally strictly worse than doing so on the serve…
As with SSR vs CSR in general, I think which is best depends on how much interactivity there is on the page. And also how much can be done entirely on the client side (it is possible to cache data client side too and make the app work entirely offline). As an extreme example, something like https://www.photopea.com/ would be a nightmare to use if it was server-side rendered. Or consider something like Google Maps. Fo…
> how much interactivity there is on the page
Yes, and also how much interactivity is better served by a thick browser-based client than by a round-trip to the datacenter. In practice, many Web applications we encounter daily have relatively low interactivity (where something like Google Maps or the Spotify Web player score as "high"). And then they are implemented using thick frameworks that are frequently slower than a round-trip to a server for re-rendering the entire page was even as far back as 10 or 20 years ago.
Your extreme examples, plus applications like Figma, are absolutely places where I would expect to see thick client-side Javascript. However, most Web applications that we encounter frequently are more like e-commerce, blogs, recipe websites, brochureware sites, landing pages and the like that absolutely are primarily about presenting information. Using thick browser clients is a sub-optimization for most of those Web uses.
Re: The future (and the past) of the web is server side rendering
#135It's obviously nonsense. The lowest latency cache and state storage is clientside. You can piss around with multi regions and SSR to minimize latency but that's just placing a lot of regional caches near your users. The nearest place is in their actual browser -> offline first is the future
Client-side storage sucks, especially if you want to visit the same site from multiple devices. Without more code to sync this data, it's not great.
Being dependant on a reliable internet connection sucks, especially when travelling. SSR just won't work for mobile.
With offline first, the client is the lowest latency server possible.
Yes you should sync too. Offline first, not offline only
Re: The future (and the past) of the web is server side rendering
#136The thing that went wrong with front-end frameworks imho was that instead of being what was promised: you could update UI elements with NO NEED to contact the server at all, only posting back when something needed persisting, instead it became an excuse that every action on the front-end needed to call an API or 3 so we've ended up with over-complicated apps that instead of not relying on the backend are relying on it more than ever.
Any little glitch, slowdown or unavailability is affecting you not only once on page load but potentially with every single interaction. To make it worse, a lot of backend interactions are not made interactively or synchronously where the user might expect to wait a little while, they are made in the background causing all manner of edge cases that make apps somewhere from very slow to virtually unuseable.
I guess it's that old adage that people will make use of whatever you offer them, even if they go too far.
Re: The future (and the past) of the web is server side rendering
#137I may be misunderstanding this, but isomorphic SSR sounds an awful lot like the Java Server Faces concept of a server side DOM that is streamed to the client. JSF was largely dropped by java developers because it ended up scaling poorly, which makes sense since it violates one of the main constraints that Roy Fielding proposed for the webs REST-ful architecture: statelessness. An alternative approach is to retain the…
I think JSF was ahead of its time.
I'm working on a server side framework and someone told me it reminded them of Java Server Faces. I think the approach works really well and latency is low enough when you can deploy apps all over the world. Also they didn't have HTTP2 or websockets back then... What I'm doing is basically a clone of Preact, but server side Ruby, streaming DOM-patches to the browser...
Re: The future (and the past) of the web is server side rendering
#138"The future of the Web is what suits our business model" /s But in all seriousness, the web has websites, it has apps, it has games. Pick a tool that's appropriate for the job and forget about what is the past/present/future.
The rise of metaframeworks is interesting because it brings nuance to this. The line between site and app can be blurry. For example, my app has a main screen that needs to be client rendered. It also has a user settings screen that could be implemented as a traditional server rendered page with no JavaScript, except it's a lot more practical to build everything inside the same project and technology. Apps and their…
Agreed.
https://example.com/app might be a SPA and https://example.com/profile might be server rendered and https://example.com/blog might be a static site. And that's great!
Pick the right tool for the job :)
Re: The future (and the past) of the web is server side rendering
#139The future is not to stick to a single religion but to apply one's brains when architecting solution as it all depends on multiple factors and there are no silver bullets in this universe.
Re: The future (and the past) of the web is server side rendering
#140I think that biggest issue with page size is not due to client side rendering, but rather thanks to bundling and idea that you need to download the same minified Lo-Dash on each and every page. Why can’t we just use public CDNs is beyond my understanding. I really like client side apps. They are so much more responsive. The only problem is with bundle sizes.
> Why can’t we just use public CDNs is beyond my understanding. Privacy issues iirc. I think you can use the setup to introduce tracking/reveal information about your history.
It could have worked with a trusted, open broker. I'm sure there could be a compatible sustainability model. I feel like a lot of potential trust was broken by the likes of Facebook and Google.