3 ms·

Front-End Developers

quectophoton 3y ago
Also that's why single page applications are no longer technically single page. https://example.com/#!/ https://example.com/#!/about/ https://example.com/#!/users/ Are all the same page as far as the browser concerns, and if you move from `/#!/` to `/#!/users/`, and reload the page, you still load the same page (i.e. `/`). But that was too ugly for URLs, so modern websites now use browser history APIs just so they can remove 3 characters from the URL and do stuff like: https://example.com/ https://example.com/about/ https://example.com/users/ Sure, if you load `/` and move to `/about/` you don't load a new page because of browser history APIs; but if you then refresh, now you load a different, uncached page (`/about/`, instead of `/`) even if the HTML in the response is exactly the same as in `/`. Sure, the difference is not much, but to me it still seems like a waste when the response could have been cached already like in the first example.
- alex_smart 3y ago
  > But that was too ugly for URLs, so modern websites now use browser history APIs just so they can remove 3 characters from the URL and do stuff like Would back/forward buttons continue to work if we decided not use browser history APIs?
  - quectophoton 3y ago
    Yes, and a quick test with Mithril.js confirms it. I could try with something like React, but that's too much for a quick test.
    - mewpmewp2 3y ago
      Mithril.js also probably uses the history API? .replaceState() will replace current url without putting it in the history, so back won't work, while .pushState() does.
  - PH95VuimJjqBqy 3y ago
    The other poster is wrong, the entire reason the history API exists is specifically because when these SPA frameworks first came onto the scene one of the things that was broken was history. So they invented the history API's so SPA's could stop breaking some of the user expectations they were breaking.
- prewk 3y ago
  The first one always requests / from the server when landed on/refreshed. The other one does not. This fact can be acted upon.
- cylemons 3y ago
  What does the ! symbol do in url fragments?
  - deleted 3y ago
    [deleted]
  - scq 3y ago
    It was part of a scheme to make SPAs indexable by search engines. Google deprecated it back in 2015, as Googlebot can now execute JS. https://developers.google.com/search/blog/2009/10/proposal-for-making-ajax-crawlable https://developers.google.com/search/blog/2009/10/proposal-f...
- vhcr 3y ago
  That issue can be solved with service workers.
- account42 3y ago
  The real reason for moving (back) from fragment URLs to real URLs is because the latter can serve different content on the initial load - specifically, they can act as actual webpages that use javascipt for progressive enhancement but work immediately whereas your / needs to display a spinner while you send of additional network requests to retrieve the content and build the page.

Also that's why single page applications are no longer technically single page. https://example.com/#!/ https://example.com/#!/about/ https://example.com/#!/users/ Are all the same page as far as the browser concerns, and if you move from `/#!/` to `/#!/users/`, and reload the page, you still load the same page (i.e. `/`). But that was too ugly for URLs, so modern websites now use browser history APIs just so they can remove 3 characters from the URL and do stuff like: https://example.com/ https://example.com/about/ https://example.com/users/ Sure, if you load `/` and move to `/about/` you don't load a new page because of browser history APIs; but if you then refresh, now you load a different, uncached page (`/about/`, instead of `/`) even if the HTML in the response is exactly the same as in `/`. Sure, the difference is not much, but to me it still seems like a waste when the response could have been cached already like in the first example.

alex_smart 3y ago
> But that was too ugly for URLs, so modern websites now use browser history APIs just so they can remove 3 characters from the URL and do stuff like Would back/forward buttons continue to work if we decided not use browser history APIs?
- quectophoton 3y ago
  Yes, and a quick test with Mithril.js confirms it. I could try with something like React, but that's too much for a quick test.
  - mewpmewp2 3y ago
    Mithril.js also probably uses the history API? .replaceState() will replace current url without putting it in the history, so back won't work, while .pushState() does.
- PH95VuimJjqBqy 3y ago
  The other poster is wrong, the entire reason the history API exists is specifically because when these SPA frameworks first came onto the scene one of the things that was broken was history. So they invented the history API's so SPA's could stop breaking some of the user expectations they were breaking.
prewk 3y ago
The first one always requests / from the server when landed on/refreshed. The other one does not. This fact can be acted upon.
cylemons 3y ago
What does the ! symbol do in url fragments?
- deleted 3y ago
  [deleted]
- scq 3y ago
  It was part of a scheme to make SPAs indexable by search engines. Google deprecated it back in 2015, as Googlebot can now execute JS. https://developers.google.com/search/blog/2009/10/proposal-for-making-ajax-crawlable https://developers.google.com/search/blog/2009/10/proposal-f...
vhcr 3y ago
That issue can be solved with service workers.
account42 3y ago
The real reason for moving (back) from fragment URLs to real URLs is because the latter can serve different content on the initial load - specifically, they can act as actual webpages that use javascipt for progressive enhancement but work immediately whereas your / needs to display a spinner while you send of additional network requests to retrieve the content and build the page.