5 ms·

Sometime ago I had an idea that SPAs exist mostly because animated transitions between pages make managers happy, not to serve any actual user need. If that's t

Sometime ago I had an idea that SPAs exist mostly because animated transitions between pages make managers happy, not to serve any actual user need. If that's true, maybe we could add support for animated transitions between server-side rendered pages, and make SPAs mostly go away. Then I realized we could do that easily with a JS library! We could give some divs a "sticky-id" attribute, so they stay as part of the DOM tree when the page reloads, only their contents get replaced with the contents of divs from the new page having the same "sticky-id". That way there's no flash to white, and CSS transitions on sticky elements get a chance to fire. The whole thing could be handled by a generic onclick handler on each link. And the links would support opening in new tab as well, the JS would only fire when they are clicked in the same tab. I think that would be the most conservative way to have an SPA-like experience with a minimum of JS. Unfortunately I was too lazy to implement it :-/ EDIT: It's interesting that most replies to this comment seem to talk about whole page transitions, like fading out the whole page. But as I envisioned it, the key part of the idea is that we can get element-by-element transitions without writing custom JS, just by adding "sticky-id" attribute to some elements and letting their CSS transitions do the work.

detaro 8y ago
https://github.com/turbolinks/turbolinks https://github.com/turbolinks/turbolinks is pretty close?
- cousin_it 8y ago
  Neat! Though the point of my idea is having animated transitions between pages, by replacing contents of sticky elements and letting their CSS transitions work as usual. As far as I can tell, turbolinks doesn't do that.
  - detaro 8y ago
    I think it always replaces the entire body element, not parts of it, yes
  - b_f 8y ago
    Kinda like this? https://github.com/miguel-perez/smoothState.js https://github.com/miguel-perez/smoothState.js
    - cousin_it 8y ago
      Yeah, well... that still requires you to write custom JS. The thing I'm imagining would be based only on markup - which sticky ids exist in both pages. But the idea is really similar, thanks for the link!
- victor106 8y ago
  Turbolinks is cool but it seems more tied to only a rails backend. Anyone know how to use it with Java?
  - PascalW 8y ago
    It's not tied to Rails at all. I'm using it with a Phoenix backend. You just include the JS and presto!
    - elcritch 8y ago
      So you don’t you need to configure the Phoenix backend or whatnot? That’s even more awesome!
  - nicostouch 8y ago
    It's independent of Rails. It simply hooks the all calls to <a href> tags and replaces them with ajax get requests to the url. It works really nice with Rails because of how easy Rails makes it return a piece of javascript to the page (this is called SJR) so there is some magic included for making form submissions work which is part of the Rails turbolinks gem. The javascript that the server returns to the page essentially calls Turbolinks.visit("/url-form-submission-would-redirect-to-after-completion") so that the expected navigation takes place. It's quite clever. I think you would have to replicate that in the Java world to get the full experience. This SO answer alludes to how you might replicate SJR https://stackoverflow.com/questions/26750738/java-spring-return-javascript https://stackoverflow.com/questions/26750738/java-spring-ret... So I think out of the box you can expect clicking links to work (and that alone provides a great speedup), but ajax form submissions will require some work. If you look at some articles on how form submissions with turbolinks make use of SJR you could likely figure it out and implement it. It's overall not a very complicated mechanism. I suppose Rails .erb templating engine also has some helpers which the form submission side of turbolinks relies on. Namely it includes a data attribute data-remote and that's the thing turbolinks hooks into to prevent the default behavior of the form submission and and instead fire the ajax request. In theory so long as your forms include that it will work if you have the SJR stuff in place on your back-end. You could definitely roll full support for it.
- cyberferret 8y ago
  Turbolinks looks neat, but our Ruby app selectively includes CSS and Javascript snippets outside the <body> tag depending on what page is loaded (using :content_for declarations in our templates). I am guessing that Turbolinks will not work for us in this case, as the relevant external files will not be called on page load?
  - nicostouch 8y ago
    turbolinks swaps out the <body> and merges the <head> tags of the incoming page with the existing <head> tag.
blattimwind 8y ago
history.pushState() aka pjax
schizoidboy 8y ago
JQueryMobile does this (automatically applying to all anchor links): https://jquerymobile.com/ https://jquerymobile.com/ Various page transitions can be set using `defaultPageTransition`: https://demos.jquerymobile.com/1.4.5/transitions/ https://demos.jquerymobile.com/1.4.5/transitions/ Click the "page" button to the right of a transition for a demo.
spankalee 8y ago
There once was (still is?) a proposal for this: https://github.com/jakearchibald/navigation-transitions https://github.com/jakearchibald/navigation-transitions
52-6F-62 8y ago
I've done something not the same, but a compromise previously using the Window object's `beforeunload` event to fade out everything in the DOM smoothly, and then using the `beforeload` and `load` events to fade the new DOM back in. It's a bit of a halfway between having sliding transitions, etc. You might be able to simulate that even further than I ever tried. https://developer.mozilla.org/en-US/docs/Web/Events/beforeunload https://developer.mozilla.org/en-US/docs/Web/Events/beforeun...
dwaltrip 8y ago
The primary benefit I see from SPAs is to enable pages that changes in a wide variety of ways without having to reload the whole thing at any point. Funny thing, you can actually serve each page as a separate, stand-alone JS "app/page" and still get this benefit (e.g. each page in your app becomes separate webpack entry point).
johnnypopcorn 8y ago
You may be interested in http://barbajs.org/ http://barbajs.org/

detaro 8y ago

https://github.com/turbolinks/turbolinks https://github.com/turbolinks/turbolinks is pretty close?

cousin_it 8y ago
Neat! Though the point of my idea is having animated transitions between pages, by replacing contents of sticky elements and letting their CSS transitions work as usual. As far as I can tell, turbolinks doesn't do that.
- detaro 8y ago
  I think it always replaces the entire body element, not parts of it, yes
- b_f 8y ago
  Kinda like this? https://github.com/miguel-perez/smoothState.js https://github.com/miguel-perez/smoothState.js
  - cousin_it 8y ago
    Yeah, well... that still requires you to write custom JS. The thing I'm imagining would be based only on markup - which sticky ids exist in both pages. But the idea is really similar, thanks for the link!
victor106 8y ago
Turbolinks is cool but it seems more tied to only a rails backend. Anyone know how to use it with Java?
- PascalW 8y ago
  It's not tied to Rails at all. I'm using it with a Phoenix backend. You just include the JS and presto!
  - elcritch 8y ago
    So you don’t you need to configure the Phoenix backend or whatnot? That’s even more awesome!
- nicostouch 8y ago
  It's independent of Rails. It simply hooks the all calls to <a href> tags and replaces them with ajax get requests to the url. It works really nice with Rails because of how easy Rails makes it return a piece of javascript to the page (this is called SJR) so there is some magic included for making form submissions work which is part of the Rails turbolinks gem. The javascript that the server returns to the page essentially calls Turbolinks.visit("/url-form-submission-would-redirect-to-after-completion") so that the expected navigation takes place. It's quite clever. I think you would have to replicate that in the Java world to get the full experience. This SO answer alludes to how you might replicate SJR https://stackoverflow.com/questions/26750738/java-spring-return-javascript https://stackoverflow.com/questions/26750738/java-spring-ret... So I think out of the box you can expect clicking links to work (and that alone provides a great speedup), but ajax form submissions will require some work. If you look at some articles on how form submissions with turbolinks make use of SJR you could likely figure it out and implement it. It's overall not a very complicated mechanism. I suppose Rails .erb templating engine also has some helpers which the form submission side of turbolinks relies on. Namely it includes a data attribute data-remote and that's the thing turbolinks hooks into to prevent the default behavior of the form submission and and instead fire the ajax request. In theory so long as your forms include that it will work if you have the SJR stuff in place on your back-end. You could definitely roll full support for it.
cyberferret 8y ago
Turbolinks looks neat, but our Ruby app selectively includes CSS and Javascript snippets outside the <body> tag depending on what page is loaded (using :content_for declarations in our templates). I am guessing that Turbolinks will not work for us in this case, as the relevant external files will not be called on page load?
- nicostouch 8y ago
  turbolinks swaps out the <body> and merges the <head> tags of the incoming page with the existing <head> tag.

blattimwind 8y ago

history.pushState() aka pjax

schizoidboy 8y ago

JQueryMobile does this (automatically applying to all anchor links): https://jquerymobile.com/ https://jquerymobile.com/ Various page transitions can be set using `defaultPageTransition`: https://demos.jquerymobile.com/1.4.5/transitions/ https://demos.jquerymobile.com/1.4.5/transitions/ Click the "page" button to the right of a transition for a demo.

spankalee 8y ago

There once was (still is?) a proposal for this: https://github.com/jakearchibald/navigation-transitions https://github.com/jakearchibald/navigation-transitions

52-6F-62 8y ago

I've done something not the same, but a compromise previously using the Window object's `beforeunload` event to fade out everything in the DOM smoothly, and then using the `beforeload` and `load` events to fade the new DOM back in. It's a bit of a halfway between having sliding transitions, etc. You might be able to simulate that even further than I ever tried. https://developer.mozilla.org/en-US/docs/Web/Events/beforeunload https://developer.mozilla.org/en-US/docs/Web/Events/beforeun...

dwaltrip 8y ago

The primary benefit I see from SPAs is to enable pages that changes in a wide variety of ways without having to reload the whole thing at any point. Funny thing, you can actually serve each page as a separate, stand-alone JS "app/page" and still get this benefit (e.g. each page in your app becomes separate webpack entry point).

johnnypopcorn 8y ago

You may be interested in http://barbajs.org/ http://barbajs.org/