> it's possible to both think that websites and web applications are worthy uses of the web, but also that many web applications would have been best engineered

> it's possible to both think that websites and web applications are worthy uses of the web, but also that many web applications would have been best engineered using 'classical' techniques from early websites. I agree with this. > There's a strong argument to be made in Facebook's case, since the core value proposition of Facebook hasn't changed much since it's inception, and it began its life as a server-side rendered 'website.' Yes, but I assume that's from the perspective of the value the site brings to you, not in general and not to everyone. If someone solely gets value from facebook.com as a site to send and receive information to/from friends and the world, then yeah, it hasn't changed much. Facebook today offers a richer experience and that might be part of its value for other people. On facebook.com you can IM a friend, while watching a video in a PIP window and engaging in a real-time conversation on the the comment thread of an event post. You can then switch back and forth between an online marketplace and a streaming service without losing the state of your chat window. The ability to do these things are part of the value proposition for many users that facebook.com now offers today, and delivering that value can be harder with a solely SSR'd website. > there would be less incidental complexity overall if what are typically called web applications took a different approach to implementing their features, while still maintaining the same user experience. If you've figured a way that's better do share! I'm sure there's instances in the wild, but I don't think an experienced engineer would ship their own client-side networking in JavaScript if there was a better way to achieve what they want without shipping any more JS. > It's hard to look at all of the crap you need to do to get a functioning web app working to not think there must be a better approach. To be clear, you can get a functional "hello world" web app with a single line a code (specifically, thanks to the fact html is very permissive with improperly formatted documents). Everything afterwards depends on the decisions you make, for the experience you want. Is getting rid of that 200ms flicker between page full page loads worth the 500ms it might take takes to load and initialize your client-side routing library? Is making your site available offline worth the effort of setting up all the extra PWA business? Some will think so, some will not. In any case, this argument is operating at the wrong level of abstraction, the issue here isn't the distinction between these two things conceptually, but if there would be less incidental complexity overall if what are typically called web applications took a different approach to implementing their features, while still maintaining the same user experience. It's hard to look at all of the crap you need to do to get a functioning web app working to not think there must be a better approach.