4 ms·

Does that help much? The distinction between "web app" and "web page" seems fuzzier than the question "would a SPA lib/framework be useful here?" Is Reddit a w

Does that help much? The distinction between "web app" and "web page" seems fuzzier than the question "would a SPA lib/framework be useful here?" Is Reddit a web app? Is Twitter? Facebook? They all started with server-generated HTML, all kinda feel "document-like", all of them involve scrolling (if that means anything.) Is the "app" boundary further along the chain, like at Google Docs? I think instead of trying to come up with definitions to classify things (and probably argue for the meaning of those definitions from the conclusions we want to draw) we should ask, - Will this help developers? - Will this make users lives better?

Slartie 8y ago
None of them is a web app. All of them want to provide certain views on their content that are uniquely identified by their URLs. This is especially true for Twitter and Reddit, which both aim to have their views on tweets and threads to be indexed by search engines. Facebook is probably the least clear one, since they put great effort into eliminating discoverability and accessibility from "outside", i.e. without a Facebook account. They're basically the AOL of today, which was a classic application back then that tried to contain a proprietary "web" of stuff in itself, only accessible if you ran their "browser" application, had an account with them and were logged in, and that "AOL Internet" of course had its own search mechanisms, just like Facebook has its own sophisticated search. However, they're not fully closed-up, they just try really hard to nag you into having an account, which is why I'm inclined to still put them in the "website" camp. However, all of these web sites surely contain certain parts that are in itself "web apps" and that are pretty much isolated from the basic parts of the site (albeit possibly interacting with it at well-defined points through APIs). I guess that this is a logical result of the large engineering teams that are working constantly on what is basically the same big website - at some point, in order to scale out further, it just becomes economic and practical to effectively isolate certain features into mostly separated "apps".
- hombre_fatal 8y ago
  Deep-linking URLs are available to SPAs as well, though. I run a somewhat popular media site implemented as an endless-scrolling SPA. Clicking on an image or video opens its detail page in a floating modal and changes the URL. I specifically wanted people to be able to link to content this way, and my SPA will load that modal and the media-gallery behind it. Quickly, SPA just becomes implementation detail. It's the level of user-interaction that dictates your implementation. For example, if you insist on your site being server-rendered with heavy Javascript that takes over, there may be a point where it would've been simpler for you to just implement it all in Javascript (the SPA). I could've implemented my media site without Javascript. Or maybe just with AJAX that returns HTML. But I know from experience that, while simple upfront, those become more complicated as you try to build more interactive UX and starting wishing your Javascript had more access to the context. At which point a SPA is just another tool for managing client complexity in some other quadrant of the graph. But there's some nuance to the question of whether your site is or should also be in that quadrant.
hombre_fatal 8y ago
It's really easy to throw the baby out with the bathwater in this conversation as well. A more interactive Javascript-heavy UI can improve a lot of aspects of even websites we consider to be a server-side-rendered gold standard like a forum or message board. For example, look at the right-sidebar scrubber on Flarum that lets you quickly scroll to arbitrary parts of a long forum thread: https://discuss.flarum.org/d/17745-flarum-0-1-0-beta-8-released https://discuss.flarum.org/d/17745-flarum-0-1-0-beta-8-relea... Or look at how clicking a submission on Reddit's new UI opens it in a floating modal window so that you don't lose track of where you are when you click out of it. It makes opening submissions feel cheaper/faster to me where, in the old UI, I tended to open everything up in a new tab. There's a more thoughtful consideration that needs to be had here than just "webapp or website?" Else you're back to cargo-culting.
- KajMagnus 8y ago
  Or this, this blog post (I wrote) about how Hacker News itself can be improved, and it's about SPA things: https://www.talkyard.io/-32/how-hacker-news-can-be-improved-3-things https://www.talkyard.io/-32/how-hacker-news-can-be-improved-...
- rsynnott 8y ago
  Hrm. I apparently angered it by scrolling to fast, and it froze for about a second. I think I prefer ordinary forums...
- icebraining 8y ago
  Both of those are just fixing problems caused by the reliance on JS in the first place. The first could be done easily with anchor links - if the content wasn't loaded dynamically. And browsers are perfectly able to return you to the same position in the page - unless it's all loaded dynamically.
yellowapple 8y ago
"Is Reddit a web app? Is Twitter? Facebook? They all started with server-generated HTML, all kinda feel "document-like", all of them involve scrolling (if that means anything.)" All three of these are examples of websites where JavaScript should be entirely optional. With the exception of the realtime chat functionality in reddit and Facebook, there is very little that any of those three platforms couldn't do exclusively with server-side-rendered HTML and CSS. It might be ugly, but it'd be usable. Any client-side scripting should build on top of that and implement the fancier features.

Slartie 8y ago

None of them is a web app. All of them want to provide certain views on their content that are uniquely identified by their URLs. This is especially true for Twitter and Reddit, which both aim to have their views on tweets and threads to be indexed by search engines. Facebook is probably the least clear one, since they put great effort into eliminating discoverability and accessibility from "outside", i.e. without a Facebook account. They're basically the AOL of today, which was a classic application back then that tried to contain a proprietary "web" of stuff in itself, only accessible if you ran their "browser" application, had an account with them and were logged in, and that "AOL Internet" of course had its own search mechanisms, just like Facebook has its own sophisticated search. However, they're not fully closed-up, they just try really hard to nag you into having an account, which is why I'm inclined to still put them in the "website" camp. However, all of these web sites surely contain certain parts that are in itself "web apps" and that are pretty much isolated from the basic parts of the site (albeit possibly interacting with it at well-defined points through APIs). I guess that this is a logical result of the large engineering teams that are working constantly on what is basically the same big website - at some point, in order to scale out further, it just becomes economic and practical to effectively isolate certain features into mostly separated "apps".

hombre_fatal 8y ago
Deep-linking URLs are available to SPAs as well, though. I run a somewhat popular media site implemented as an endless-scrolling SPA. Clicking on an image or video opens its detail page in a floating modal and changes the URL. I specifically wanted people to be able to link to content this way, and my SPA will load that modal and the media-gallery behind it. Quickly, SPA just becomes implementation detail. It's the level of user-interaction that dictates your implementation. For example, if you insist on your site being server-rendered with heavy Javascript that takes over, there may be a point where it would've been simpler for you to just implement it all in Javascript (the SPA). I could've implemented my media site without Javascript. Or maybe just with AJAX that returns HTML. But I know from experience that, while simple upfront, those become more complicated as you try to build more interactive UX and starting wishing your Javascript had more access to the context. At which point a SPA is just another tool for managing client complexity in some other quadrant of the graph. But there's some nuance to the question of whether your site is or should also be in that quadrant.

hombre_fatal 8y ago

It's really easy to throw the baby out with the bathwater in this conversation as well. A more interactive Javascript-heavy UI can improve a lot of aspects of even websites we consider to be a server-side-rendered gold standard like a forum or message board. For example, look at the right-sidebar scrubber on Flarum that lets you quickly scroll to arbitrary parts of a long forum thread: https://discuss.flarum.org/d/17745-flarum-0-1-0-beta-8-released https://discuss.flarum.org/d/17745-flarum-0-1-0-beta-8-relea... Or look at how clicking a submission on Reddit's new UI opens it in a floating modal window so that you don't lose track of where you are when you click out of it. It makes opening submissions feel cheaper/faster to me where, in the old UI, I tended to open everything up in a new tab. There's a more thoughtful consideration that needs to be had here than just "webapp or website?" Else you're back to cargo-culting.

KajMagnus 8y ago
Or this, this blog post (I wrote) about how Hacker News itself can be improved, and it's about SPA things: https://www.talkyard.io/-32/how-hacker-news-can-be-improved-3-things https://www.talkyard.io/-32/how-hacker-news-can-be-improved-...
rsynnott 8y ago
Hrm. I apparently angered it by scrolling to fast, and it froze for about a second. I think I prefer ordinary forums...
icebraining 8y ago
Both of those are just fixing problems caused by the reliance on JS in the first place. The first could be done easily with anchor links - if the content wasn't loaded dynamically. And browsers are perfectly able to return you to the same position in the page - unless it's all loaded dynamically.

yellowapple 8y ago

"Is Reddit a web app? Is Twitter? Facebook? They all started with server-generated HTML, all kinda feel "document-like", all of them involve scrolling (if that means anything.)" All three of these are examples of websites where JavaScript should be entirely optional. With the exception of the realtime chat functionality in reddit and Facebook, there is very little that any of those three platforms couldn't do exclusively with server-side-rendered HTML and CSS. It might be ugly, but it'd be usable. Any client-side scripting should build on top of that and implement the fancier features.