Yes! I would love to see this - the simplicity of standard links with the speed of websockets.
I’m not fluent enough in JS and coffeescript to do it very well, but it seems quite do-able, along with an elixir plug to manage the socket and dispatch to the standard phoenix routing.
Here’s a site that uses Turbolinks with Phoenix:
As you can see it’s pretty fast: https://changelog.com/
More info: Changelog.com is open source
I’ve never heard of Turbolinks before but I like what I see. Definitely can be better than building a slow JS-heavy SPA when it’s not needed.
I actually ended up writing something like it since that post, but without a fallback to non-javascript browsers (will not be an issue at my job). It is indeed blazing fast. ^.^
I decided not to return html though, generating it seems useless, I went more of the Discourse method, the server returns just enough html/script to generate a client router, the client router then sets up a websocket connection back to phoenix, hands the url over the websockets, the server sends back an element name to render and a set of dependent files that should be downloaded, the router checks if they are already in the cache, and downloads the ones that are not, once complete it then attaches the element to the page, passing startup data to it (like the websocket connection and more), then swaps the page (via a slide off/in animation, it looks like the pages are attached side-to-side). There is a loading bar at the top just below the header (which is 'static’ish across all pages) that appears when downloading dependencies and waiting for the websocket communication, but thus far I do not even see it blink it is so fast since the site is hosted on the internal company LAN only across a few thousand people, even the VLan remote people do not see any delay. Most of the time it just feels as fast as a native app (and interestingly the html/script of many pages so far is smaller than even the Elm standard library, blehg Elm is huge).
I guess this can be considered an SPA maybe, but only the needed parts are requested from the server (the server can ahead-of-time push messages to the client to have it preload files as well, though I’ve not used it yet).
Hello everyone. I’ve added Turbolinks to my Phoenix app. It works great except one scenario:
Any ideas how can I solve this issue?
That is just because it tried to GET what was probably only a POST url, that is just because of the auto-reload on a POST I’d imagine?
I’m using morphdom in my hand-rolled crappy framework.
I basically render Handlebars templates, create a DOM node out of them, then morph the existing DOM. Works quite nicely, but I don’t really care about performance, so no idea how it compares with React’s VDOM.
React’s is very slow. Preact or others like it tend to be much faster. Picodom is a vdom’ish thing that diff’s to the physical dom instead, it is tiny but unsure about speed.
May be a bit off-topic, since somone moved Unpoly to a new thread, but I think it’s worth to mention SPF which YouTube used before the recent redesign. I think Github also was using it, probably not anymore. In this video from 2014 Google describes how it works.
Hey, @OvermindDL1, your approach looks interesting.
Is there a blog post/code sample I could consult to learn more?
