14 ms·

I don't get client side navigation. It's a worse experience in every way. It's slow, often doesn't support things like command-click, it usually breaks the back

I don't get client side navigation. It's a worse experience in every way. It's slow, often doesn't support things like command-click, it usually breaks the back button, and even if it doesn't it breaks the restoration of the scroll position. The only thing worse is a custom scroll UI. Why do people try to reinvent the most basic features of a webbrowser? And if they do, why do they always only do a half-assed job at it? It's infuriating.

kccqzy 7y ago
For a company I worked for, we tested client side navigation and non-client (traditional) navigation for the admin interface. And then we asked the admins who use the site in question: all of them loved the client side navigation. So you see, I suspect most users are not like the HN crowd and don't really care about command-click or the back button.
- petemill 7y ago
  But you can support both with client side navigation
  - kccqzy 7y ago
    I certainly can. It was just not necessary because the people who are using the site didn't care.
- efrafa 7y ago
  Its also really not that hard to make cmd click + back button to work properly with client side nav.
  - saagarjha 7y ago
    Can you support iOS's "peek" menu as well?
    - regecks 7y ago
      Yes, I tried it just now on a random website I built in Vue. Any sane implementation of client-side navigation uses the History API[1]. It is indistinguishable from "real" navigation in the browser UI, apart from how fast it is. If on the other hand, if you encounter code like the abomination below (which breaks cmd+click, peek and forward/back), you should not (imo) conflate it with actual client-side navigation. I suspect that's what some comments here are referring to. <a href="#" onclick="loadContentIntoPane('contact')">Contact Us</a> 1. https://developer.mozilla.org/en-US/docs/Web/API/History_API https://developer.mozilla.org/en-US/docs/Web/API/History_API
    - baddox 7y ago
      Is there anything special needed to support that? I’m pretty sure you just need an <a> tag with an href. With any SPA framework/library I’m aware of, you have to go out of your way to make it not work.
- zucker42 7y ago
  Not every project is the same. I suspect there are many applications where an SPA is a much better experience than a traditional website. In my opinion, a documentation site is not one of them.
- pmontra 7y ago
  I've got a customer with a complex UI where a lot of things happen. Basically a desktop application in a browser. We built a SPA for that. Then there are the AWS and Google consoles where nearly every click loads a new page and I don't complain, because it's ok. And Amazon, the shopping site. Every click into a product loads a new page. They seem to be doing pretty well. I would build SPAs where it's difficult to give a different URL to what's on screen after every click. Server side rendering in every other case.
sergiomattei 7y ago
Slow? I'm quite sure the whole point of client side apps is for them to be substantially faster - and most are.
- snek 7y ago
  Did you read the article?
  - olliej 7y ago
    I’m guessing no?
  - cj 7y ago
    I read the article. Perhaps I'm misunderstanding, but did they do this test on a 128 kilobit cellular Internet connection?
    - csande17 7y ago
      I made the video in the article using Chrome's "low-end mobile" throttling preset, which simulates a ~300 kbit connection IIRC. But I saw very similar behavior on my actual phone with an actual 128 kilobit connection in Canada.
      - cj 7y ago
        Thanks for the clarification. Do the conclusions hold up when testing with a broadband network connection?
        csande17 7y ago
        As I mention in the article, I'm not really able to tell the difference between old MDN and new MDN on the fast network connection I usually use. They both load pretty much instantly for me.
        7y ago
n8hunzaker 7y ago
Sadly I think this is true for a lot of sites. However my experience has been that many (particularly in the last 3-5 years) support command-click, back button navigation, and scroll position restoration. More often than not, I've seen that tracking scripts break this more than anything else. Particularly command+click. Still - it'd be great of there was an API to preserve UI state moving into a new entry in browser history. I don't want to lose scroll position for a sidebar if I'm drilling down into a large list of data. Being able to add hints through markup for when to preserve UI state could go a long way towards making page-refresh based form and navigation behavior competitive again.
hoorayimhelping 7y ago
I have no idea. I do a lot of front end work in React, and the assumption that an SPA is a better experience for people because you don't have to do a page reload to see a new page is really baffling to me. It's widespread too - across industries and disciplines and age ranges, as if the people suggesting these things have never used SPAs.
- RandomInteger4 7y ago
  Because page reloads are jarring and discontinuous experiences. They run counter to a good user experience. That's not to say that every SPA is a good user experience, but just that a page reload is not part of the recipe for a good user experience.
  - arethuza 7y ago
    HN uses the "old fashioned" approach of rendering everything server side and every link forces a page reload and I wouldn't describe the experience as "jarring and discontinuous". I'd rather have a fast full page reload than looking at a spinner while complex client side stuff does its stuff. [NB I really like React and when good SPAs are very very good - but a lot aren't].
    - SilasX 7y ago
      Well, the up/downvote transition is client side, but otherwise, yes.
      - eitland 7y ago
        AFAIK it works without js as well :-)
        arethuza 7y ago
        I occasionally suggest to people who complain on HN about the bad old days of table based layouts to do a "View Source" ;-)
drdaeman 7y ago
I believe the only upside is that site framing (headers, navbars, side menus, etc etc) doesn't flicker or jump around reflowing as you navigate across pages. Which is I think why almost every "webapp" out there does this - to provide visually continuous experience, even if this client-side intra-screen navigation is slower. Surely, on a fast-enough connections this flicker is essentially invisible, but if your connection is far from perfect (crappy hotel WiFi or poor cellular reception), it is certainly well noticeable. Also, it's easier to persist some state across the navigations. Like making it trivial for those (annoying) on-page support chat overlays not losing message history. This rationale only applies to web "apps", not documents, of course.
- basch 7y ago
  I much prefer getting normal pages to behave more like spa, than spa trying to recreate the web browser experience. Probably most importantly, automatically degrading back to normal web behavior, if the transitions arent supported or js doesnt load. like https://github.com/turbolinks/turbolinks https://github.com/turbolinks/turbolinks
marcosdumay 7y ago
> And if they do, why do they always only do a half-assed job at it? Oh, that's the easy one. It's half-assed because it's hard as hell to do a good job replacing the browser navigation. It shouldn't be surprising, since browsers are huge pieces of software made basically for displaying content and navigation, it's not reasonable to expect every web page to competently replace half of that job.
- jimmaswell 7y ago
  Just use the history state pushing API and it's not that hard. Put state information in the url and load the right content on refresh.
  - mintplant 7y ago
    Scroll restoration is very difficult to reproduce perfectly. Particularly when content changes between navigating from one page to another and then navigating back, or when the user closes and re-opens the tab/browser.
Ambroos 7y ago
I think it's possible but it's hard to execute well. I tried 4.5 years ago with https://vivavlaanderen.radio2.be/ https://vivavlaanderen.radio2.be/ - disclaimer: the experience isn't great on mobile (design issue, not tech) and the JS/HTML is massive (it was my first JS project ever, so I messed a bit with Webpack etc). One of the tricks I used is partial rendering. If you click an artist page (the square/rectangular people photos with a name) and have JS enabled it'll first only render the header, then add a few body items, then the rest of the body items. Since we used a horribly inefficient handmade Markdown to JS thing with a renderer in old naive React it took way too long to render them all at the same time, it'd easily lock up the browser for two seconds on a large page. Another ridiculous thing was to preload enough data to render the top part of every single artist page while you're on the homepage. A complete waste of data, but otherwise navigation would need a request before being able to render something useful and that defeated the point. I did pay a lot of attention to making it feel like real navigation though. Almost any meaningful interaction modifies the URL, and the site is practically fully functional without JS. Navigation and Cmd-clicking should all work perfectly. Including scroll positions handling. SEO worked really well too. So for a classic website format, to make client side rendering work, you need: - a URL for every view change, with regular old <a> elements that have those URLs as href. - server rendering that actually handles all of those URLs - something that restores scroll positions on navigation - phased/batched rendering on click if your initial new view doesn't render in say 100ms (basically faking progressive rendering) The development experience was a bit frustrating back in the day, and I don't think it paid off. Which is why for the next project (https://www.klara.be https://www.klara.be) we decided to go back to server rendering, but using React on the server. Some parts of the page (like the coloured box top right on desktop) are rendered as a skeleton on the server, and then React on the client reuses the same exact code to make these parts interactive again. Partial universal React basically, and it worked very well. I think klara.be feels like a nice and snappy site and it was way easier to develop for.
- kevincox 7y ago
  > with regular old <a> elements that have those URLs as href. This is the most common problem I have. I middle-click and nothing happens (or it loads in the same page) That being said this is partially an API issue since the website needs to guess what a "regular click" is. It would be nice if there was an "onnavigate" event which would trigger for regular clicks (or other ways to follow a link in the same page) but not for things such as "open in new tap" shortcuts.
tiborsaas 7y ago
Because it's faster. If you don't have to download all the content again, force the browser to re-render everything, then by design you just get the new content from the server faster, if you have to download anything at all. The idea exists since the introduction of AJAX. Furthermore, you don't lose state, which makes things much more simple. Imagine a simple image gallery. You just update the <img> tag, update the URL with the history API and everybody is happy. If you were to navigate via links, you get the same behavior. Of course shitty implementations exists and you only notice the bad ones. If done right, you don't notice that it's happening at all. Lastly but most importantly, context matters! It's not a silver bullet, but it can be really useful.
- moron4hire 7y ago
  It's probably not the network round trip or the actionable content making reloading the site so slow. It's almost certainly tracking scripts, unoptimized database queries, and unoptimized assets.
  - tiborsaas 7y ago
    Sure, web performance is an afterthought at many places and the more people work on a certain project the worse it gets because each team has its own motivation, but they all have the same target to shoot at. I think there's a connection between the organizational structure and the bad frontend experiences and this is almost always overlooked in these discussions. This is no surprise of course, we only see the crappy end result and blame the technologies, but this is superficial. It's usually not the certain technology that's problematic (SPA, history api, react, angular, webassebmly...) but the use of them without understanding the problem first. That's why I find it funny when I constantly read general comments here like "SPA-s are the worst".
    - ryacko 7y ago
      CSS doesn’t require javascript, and allows for nearly all the features of a SPA.
deleted 7y ago
[deleted]
bhousel 7y ago
I see lots of responses to this article asking "why client-side navigation?". I can share my own experience with building an app a few months ago, and how/why I switched to a client-side single-page app.. The app is this: https://osmlab.github.io/name-suggestion-index/index.html https://osmlab.github.io/name-suggestion-index/index.html It is a worldwide list of brands that have been seeded with OpenStreetMap data, and which volunteers have linked to Wikidata identifiers. We use this data in OpenStreetMap editors to help people add branded businesses. Pretty cool! 1. We had data in `.json` files (but not too much data) and we wanted to show it to people working on the project so that they could review the brands. 2. I spent a day or two and built a static document generator. It took our data and spit out an `index.html` and few hundred `whatever.html` files. This worked really well. As the article says, "browsers are pretty good at loading pages". A side benefit - Google is really good at indexing content like this. 3. Then users made the obvious request: "I want to filter the data. Let me type a search string and only show matching brands. Or brands that appear in a certain country". 4. OK, SO.. If your data is spread out over a few hundred files, short answer - you can't do this. 5. But the data is _really_ only a few megabytes of `.json`. I spent a few days to learn React and switch to a single-page client side app so that we can filter across all of it. The new version uses hooks to fetch the few `.json` files that it needs, `react-router` to handle navigation between the index and the category pages. It works pretty ok! Most people would stop here. 6. The first version with client-side filtering performed good enough, but not great. The reason was because, as users type these things happen: The filters get applied, the React components get a new list of brands passed in as props, and React re-renders these new lists to the virtual DOM, and eventually, slowly, the real DOM. 7. It's really easy to build React code like this, and many people do. But it is better to avoid DOM changes in the first place. I changed the components so that the lists stay the same, but filtered things just get classed as hidden `display:none` instead of being added and removed from the DOM, and performance is much better now. Anyway hope this is helpful to someone!
- Blackstone4 7y ago
  I believe that a multi page app/website would have the data in a database rather than distributed across html files. The server would then populate the html files before serving them up to clients. It sounds like you started by trying to build a static website and then decided you wanted something more dynamic...so shifted to react where you are doing the dynamic data manipulation on the client as opposed to a server..not a like for like comparison
amelius 7y ago
Curious, how would you implement Facebook's infinite scroll with only static pages?
- ignoranceprior 7y ago
  https://mbasic.facebook.com/ https://mbasic.facebook.com/
- cottsak 7y ago
  Don't ask me how to solve a problem that doesn't need to be solved in the first place! :p #deletefacebook
visarga 7y ago
It's justified if you run a web app that needs to maintain complex state between clicks, such as a text/graphical editor.
- lucb1e 7y ago
  I don't think anyone disputes that. Maintaining a whole editor state in server side sessions or re-rendering everything from localStorage would be rather silly indeed. This is about changing pages, such as Github annoyingly does when browsing a repository.
TwoQ 7y ago
It also breaks a lot of disability features, like text to speech (in many instances) or navigation using keyboard keys instead of a cursor. On the plus side, not having to reload a new page for each click can have some interesting benefits. These systems remind me of flash content, except they are perhaps less terrifying and intrusive.
cottsak 7y ago
Dude! #scrollhijacking is the worst!
Sharlin 7y ago
https://en.wikipedia.org/wiki/Inner-platform_effect https://en.wikipedia.org/wiki/Inner-platform_effect
tdxcbkifxx 7y ago
The problem isn't client side apps. YouTube is a single page app and it works very well for me. No issues with ctrl clicking or anything like that. The real issue is poor SPA implementations.

kccqzy 7y ago

For a company I worked for, we tested client side navigation and non-client (traditional) navigation for the admin interface. And then we asked the admins who use the site in question: all of them loved the client side navigation. So you see, I suspect most users are not like the HN crowd and don't really care about command-click or the back button.

petemill 7y ago
But you can support both with client side navigation
- kccqzy 7y ago
  I certainly can. It was just not necessary because the people who are using the site didn't care.
efrafa 7y ago
Its also really not that hard to make cmd click + back button to work properly with client side nav.
- saagarjha 7y ago
  Can you support iOS's "peek" menu as well?
  - regecks 7y ago
    Yes, I tried it just now on a random website I built in Vue. Any sane implementation of client-side navigation uses the History API[1]. It is indistinguishable from "real" navigation in the browser UI, apart from how fast it is. If on the other hand, if you encounter code like the abomination below (which breaks cmd+click, peek and forward/back), you should not (imo) conflate it with actual client-side navigation. I suspect that's what some comments here are referring to. <a href="#" onclick="loadContentIntoPane('contact')">Contact Us</a> 1. https://developer.mozilla.org/en-US/docs/Web/API/History_API https://developer.mozilla.org/en-US/docs/Web/API/History_API
  - baddox 7y ago
    Is there anything special needed to support that? I’m pretty sure you just need an <a> tag with an href. With any SPA framework/library I’m aware of, you have to go out of your way to make it not work.
zucker42 7y ago
Not every project is the same. I suspect there are many applications where an SPA is a much better experience than a traditional website. In my opinion, a documentation site is not one of them.
pmontra 7y ago
I've got a customer with a complex UI where a lot of things happen. Basically a desktop application in a browser. We built a SPA for that. Then there are the AWS and Google consoles where nearly every click loads a new page and I don't complain, because it's ok. And Amazon, the shopping site. Every click into a product loads a new page. They seem to be doing pretty well. I would build SPAs where it's difficult to give a different URL to what's on screen after every click. Server side rendering in every other case.

sergiomattei 7y ago

Slow? I'm quite sure the whole point of client side apps is for them to be substantially faster - and most are.

snek 7y ago
Did you read the article?
- olliej 7y ago
  I’m guessing no?
- cj 7y ago
  I read the article. Perhaps I'm misunderstanding, but did they do this test on a 128 kilobit cellular Internet connection?
  - csande17 7y ago
    I made the video in the article using Chrome's "low-end mobile" throttling preset, which simulates a ~300 kbit connection IIRC. But I saw very similar behavior on my actual phone with an actual 128 kilobit connection in Canada.
    - cj 7y ago
      Thanks for the clarification. Do the conclusions hold up when testing with a broadband network connection?
      - csande17 7y ago
        As I mention in the article, I'm not really able to tell the difference between old MDN and new MDN on the fast network connection I usually use. They both load pretty much instantly for me.
        7y ago

n8hunzaker 7y ago

Sadly I think this is true for a lot of sites. However my experience has been that many (particularly in the last 3-5 years) support command-click, back button navigation, and scroll position restoration. More often than not, I've seen that tracking scripts break this more than anything else. Particularly command+click. Still - it'd be great of there was an API to preserve UI state moving into a new entry in browser history. I don't want to lose scroll position for a sidebar if I'm drilling down into a large list of data. Being able to add hints through markup for when to preserve UI state could go a long way towards making page-refresh based form and navigation behavior competitive again.

hoorayimhelping 7y ago

I have no idea. I do a lot of front end work in React, and the assumption that an SPA is a better experience for people because you don't have to do a page reload to see a new page is really baffling to me. It's widespread too - across industries and disciplines and age ranges, as if the people suggesting these things have never used SPAs.

RandomInteger4 7y ago
Because page reloads are jarring and discontinuous experiences. They run counter to a good user experience. That's not to say that every SPA is a good user experience, but just that a page reload is not part of the recipe for a good user experience.
- arethuza 7y ago
  HN uses the "old fashioned" approach of rendering everything server side and every link forces a page reload and I wouldn't describe the experience as "jarring and discontinuous". I'd rather have a fast full page reload than looking at a spinner while complex client side stuff does its stuff. [NB I really like React and when good SPAs are very very good - but a lot aren't].
  - SilasX 7y ago
    Well, the up/downvote transition is client side, but otherwise, yes.
    - eitland 7y ago
      AFAIK it works without js as well :-)
      - arethuza 7y ago
        I occasionally suggest to people who complain on HN about the bad old days of table based layouts to do a "View Source" ;-)

drdaeman 7y ago

I believe the only upside is that site framing (headers, navbars, side menus, etc etc) doesn't flicker or jump around reflowing as you navigate across pages. Which is I think why almost every "webapp" out there does this - to provide visually continuous experience, even if this client-side intra-screen navigation is slower. Surely, on a fast-enough connections this flicker is essentially invisible, but if your connection is far from perfect (crappy hotel WiFi or poor cellular reception), it is certainly well noticeable. Also, it's easier to persist some state across the navigations. Like making it trivial for those (annoying) on-page support chat overlays not losing message history. This rationale only applies to web "apps", not documents, of course.

basch 7y ago
I much prefer getting normal pages to behave more like spa, than spa trying to recreate the web browser experience. Probably most importantly, automatically degrading back to normal web behavior, if the transitions arent supported or js doesnt load. like https://github.com/turbolinks/turbolinks https://github.com/turbolinks/turbolinks

marcosdumay 7y ago

> And if they do, why do they always only do a half-assed job at it? Oh, that's the easy one. It's half-assed because it's hard as hell to do a good job replacing the browser navigation. It shouldn't be surprising, since browsers are huge pieces of software made basically for displaying content and navigation, it's not reasonable to expect every web page to competently replace half of that job.

jimmaswell 7y ago
Just use the history state pushing API and it's not that hard. Put state information in the url and load the right content on refresh.
- mintplant 7y ago
  Scroll restoration is very difficult to reproduce perfectly. Particularly when content changes between navigating from one page to another and then navigating back, or when the user closes and re-opens the tab/browser.

Ambroos 7y ago

I think it's possible but it's hard to execute well. I tried 4.5 years ago with https://vivavlaanderen.radio2.be/ https://vivavlaanderen.radio2.be/ - disclaimer: the experience isn't great on mobile (design issue, not tech) and the JS/HTML is massive (it was my first JS project ever, so I messed a bit with Webpack etc). One of the tricks I used is partial rendering. If you click an artist page (the square/rectangular people photos with a name) and have JS enabled it'll first only render the header, then add a few body items, then the rest of the body items. Since we used a horribly inefficient handmade Markdown to JS thing with a renderer in old naive React it took way too long to render them all at the same time, it'd easily lock up the browser for two seconds on a large page. Another ridiculous thing was to preload enough data to render the top part of every single artist page while you're on the homepage. A complete waste of data, but otherwise navigation would need a request before being able to render something useful and that defeated the point. I did pay a lot of attention to making it feel like real navigation though. Almost any meaningful interaction modifies the URL, and the site is practically fully functional without JS. Navigation and Cmd-clicking should all work perfectly. Including scroll positions handling. SEO worked really well too. So for a classic website format, to make client side rendering work, you need: - a URL for every view change, with regular old <a> elements that have those URLs as href. - server rendering that actually handles all of those URLs - something that restores scroll positions on navigation - phased/batched rendering on click if your initial new view doesn't render in say 100ms (basically faking progressive rendering) The development experience was a bit frustrating back in the day, and I don't think it paid off. Which is why for the next project (https://www.klara.be https://www.klara.be) we decided to go back to server rendering, but using React on the server. Some parts of the page (like the coloured box top right on desktop) are rendered as a skeleton on the server, and then React on the client reuses the same exact code to make these parts interactive again. Partial universal React basically, and it worked very well. I think klara.be feels like a nice and snappy site and it was way easier to develop for.

kevincox 7y ago
> with regular old <a> elements that have those URLs as href. This is the most common problem I have. I middle-click and nothing happens (or it loads in the same page) That being said this is partially an API issue since the website needs to guess what a "regular click" is. It would be nice if there was an "onnavigate" event which would trigger for regular clicks (or other ways to follow a link in the same page) but not for things such as "open in new tap" shortcuts.

tiborsaas 7y ago

Because it's faster. If you don't have to download all the content again, force the browser to re-render everything, then by design you just get the new content from the server faster, if you have to download anything at all. The idea exists since the introduction of AJAX. Furthermore, you don't lose state, which makes things much more simple. Imagine a simple image gallery. You just update the <img> tag, update the URL with the history API and everybody is happy. If you were to navigate via links, you get the same behavior. Of course shitty implementations exists and you only notice the bad ones. If done right, you don't notice that it's happening at all. Lastly but most importantly, context matters! It's not a silver bullet, but it can be really useful.

moron4hire 7y ago
It's probably not the network round trip or the actionable content making reloading the site so slow. It's almost certainly tracking scripts, unoptimized database queries, and unoptimized assets.
- tiborsaas 7y ago
  Sure, web performance is an afterthought at many places and the more people work on a certain project the worse it gets because each team has its own motivation, but they all have the same target to shoot at. I think there's a connection between the organizational structure and the bad frontend experiences and this is almost always overlooked in these discussions. This is no surprise of course, we only see the crappy end result and blame the technologies, but this is superficial. It's usually not the certain technology that's problematic (SPA, history api, react, angular, webassebmly...) but the use of them without understanding the problem first. That's why I find it funny when I constantly read general comments here like "SPA-s are the worst".
  - ryacko 7y ago
    CSS doesn’t require javascript, and allows for nearly all the features of a SPA.

deleted 7y ago

[deleted]

bhousel 7y ago

I see lots of responses to this article asking "why client-side navigation?". I can share my own experience with building an app a few months ago, and how/why I switched to a client-side single-page app.. The app is this: https://osmlab.github.io/name-suggestion-index/index.html https://osmlab.github.io/name-suggestion-index/index.html It is a worldwide list of brands that have been seeded with OpenStreetMap data, and which volunteers have linked to Wikidata identifiers. We use this data in OpenStreetMap editors to help people add branded businesses. Pretty cool! 1. We had data in `.json` files (but not too much data) and we wanted to show it to people working on the project so that they could review the brands. 2. I spent a day or two and built a static document generator. It took our data and spit out an `index.html` and few hundred `whatever.html` files. This worked really well. As the article says, "browsers are pretty good at loading pages". A side benefit - Google is really good at indexing content like this. 3. Then users made the obvious request: "I want to filter the data. Let me type a search string and only show matching brands. Or brands that appear in a certain country". 4. OK, SO.. If your data is spread out over a few hundred files, short answer - you can't do this. 5. But the data is _really_ only a few megabytes of `.json`. I spent a few days to learn React and switch to a single-page client side app so that we can filter across all of it. The new version uses hooks to fetch the few `.json` files that it needs, `react-router` to handle navigation between the index and the category pages. It works pretty ok! Most people would stop here. 6. The first version with client-side filtering performed good enough, but not great. The reason was because, as users type these things happen: The filters get applied, the React components get a new list of brands passed in as props, and React re-renders these new lists to the virtual DOM, and eventually, slowly, the real DOM. 7. It's really easy to build React code like this, and many people do. But it is better to avoid DOM changes in the first place. I changed the components so that the lists stay the same, but filtered things just get classed as hidden `display:none` instead of being added and removed from the DOM, and performance is much better now. Anyway hope this is helpful to someone!

Blackstone4 7y ago
I believe that a multi page app/website would have the data in a database rather than distributed across html files. The server would then populate the html files before serving them up to clients. It sounds like you started by trying to build a static website and then decided you wanted something more dynamic...so shifted to react where you are doing the dynamic data manipulation on the client as opposed to a server..not a like for like comparison

amelius 7y ago

Curious, how would you implement Facebook's infinite scroll with only static pages?

ignoranceprior 7y ago
https://mbasic.facebook.com/ https://mbasic.facebook.com/
cottsak 7y ago
Don't ask me how to solve a problem that doesn't need to be solved in the first place! :p #deletefacebook

visarga 7y ago

It's justified if you run a web app that needs to maintain complex state between clicks, such as a text/graphical editor.

lucb1e 7y ago
I don't think anyone disputes that. Maintaining a whole editor state in server side sessions or re-rendering everything from localStorage would be rather silly indeed. This is about changing pages, such as Github annoyingly does when browsing a repository.

TwoQ 7y ago

It also breaks a lot of disability features, like text to speech (in many instances) or navigation using keyboard keys instead of a cursor. On the plus side, not having to reload a new page for each click can have some interesting benefits. These systems remind me of flash content, except they are perhaps less terrifying and intrusive.

cottsak 7y ago

Dude! #scrollhijacking is the worst!

Sharlin 7y ago

https://en.wikipedia.org/wiki/Inner-platform_effect https://en.wikipedia.org/wiki/Inner-platform_effect

tdxcbkifxx 7y ago

The problem isn't client side apps. YouTube is a single page app and it works very well for me. No issues with ctrl clicking or anything like that. The real issue is poor SPA implementations.