What was the reason for this usage, how you made this duo work with Phoenix and how was the experience. Also which tutorial / blog-post etc do you recommend for someone who want to integrate these two technologies with Phoenix?
3 Likes
As Turbolinks is a front-end client, and Iāve never heard of StimulusJs but based on having Js in itās name Iām guessing itās a front-end client library too, Iām not sure anything unique needs to be done with Phoenix as Phoenix runs on the server side. What issues were you having?
As a side-note, I propose Unpoly.js over Turbolinks, just more capable and better designed overall.
3 Likes
I remember someone saying on the forum that the reason they used Turbolinks (or it might have even been Unpoly) was because they like the -feel- of the app (i.e. the smooth transition between pages, rather than page loads).
I can see why that would be nice for some apps but not for allā¦
1 Like
Stimulus is also created by Basecamp. Itās official website says
1 Like
Yes, I heard about Unpoly before in the forum, but didnāt use it actually. I re-visited their website and now itās even more mature. Iām watching Stimuls tutorial at Lynda.com, once I complete that Iāll also give Unpoly a try and see which one is better.
Looks like Unpoly have very good documentation and using it with Phoenix wonāt be a problem.
Edit: Does Unpoly need jQuery as a dependency?
I fooled around with turbolinks but eventually settled on http://instantclick.io/ in the end. It is imo not as sophisticated but in my case that was a good thing.
The reason to use such a library is to decrease the perceived page load time. So if you are really well versed with your webframework (say Phoenix or Ruby on Rails) or already have an existing application with a lot of existing webviews then it is most certainly more cost effective to have a preloader library instead of a full rewrite in React, Elm, Vue, etc.
Now for Stimulus: I looked into it a few month back and Iām not sure Iām keen of the concept. It is quite heavy in download size and has in my opinion limited use cases. Most of the times you really donāt need data binding for existing markup. Use jQuery (or simply vanilla js) if you need to manipulate the dom or straight up Preact components if you really need highly interactive elements.
I think you throw away lots of the benefits of using Phoenix to render your html by using Stimulus, because now you suddenly have to maintain two technologies that have each some control over your markup.
If you are willing to make this kind of sacrifice (especially for new projects) it might be a better idea to do it straight up as a single page application.
Just remember: a single page app is seldomly worth the hassle. Most of the times you can (and should) reduce your application to more or less static views and forms. You donāt need to pump several MB of JavaScript to the client most of the times.
My 2/c 
4 Likes
Iām coming from a Rails background and happily using Turbolinks and StimulusJS on my test projects. If all goes well I can see deploying them.
1 Like
Iād love to know about your whole experience with Turbolinks + Stimulus.
Iāve been using Turbolinks and itās been a great experience. Works just as well as it does with Rails.
Iāve been using this Turbolinks plug to handle the tiny bits of server side code: https://github.com/thechangelog/changelog.com/blob/e37f183ac104b8b9ce8b1e76d1f4330cac2bfc72/lib/changelog_web/plugs/turbolinks.ex
Otherwise itās just dropping in the turbolinks.js file on the front end.
6 Likes
Iāve been working on a medium sized project with Turbolinks and (more recently) Stimulus.
With Stimulus I do things like dynamic checkboxes in tables with stimulus populating hidden fields for batch actions. Like checking which invoices in a table are going to be sent and then submitting the send multiple form. Experience with Stimulus is solid. I think it is a very well designed library and I think it is rather unique in the way it tackles the problem of combining interactivity with server side rendering. 5/5.
Turbolinks however is a different beast. I like it and use it. Mostly for having tabs on pages that are actually different pages but does not add to history but replaces the current location. Also I use it do persist the applications main menu between loads since it is slow to reload. Basically I render an empty menu that a stimulus-controller will populate from a different url, then when Turbolinks changes the page body it will persist that part of the page so the menu is not replaced by the empty menu. Few lines of code and good enough for me. 4/5.
Unpoly looks nice. What unpoly offers I will do with Stimulus instead. Turbolinks is more about location and stimulus about interactivity. Unpoly does both. I think both are viable choices.
Hope this helps someone.
6 Likes
I know theyāve been in the process of removing that dependency, unsure if thatās complete yet or not, or maybe one of those lightweight shims can be used now?
+1 (thousand)
4 Likes
I would like to try unpoly. Is there a example repo app with phoenix? Or what kind of plug need in server side?
Itās a client-side library, not a phoenix library, you just use it either via cdn or your npm assets then just decorate the HTML however you wish, all of itās information and access is trivially accessible via the headers it sends on requests. 
1 Like
The only advantage of Turbolinks is that you get for free the integration for IOS and Android, as exemplified here
2 Likes
Could someone summarize? I canāt really view anything audio/video related easily, a webpage would be fantastic though!
Also, if you put the URl directly on itās own line then the forums will onebox it.
1 Like
You take for free an almost native experience encapsulating the app inside a webview in a Android/IOS shell, with several niceties. I strongly recommend all to watch this presentation.
I would watch it if I could, but unfortunately I still cannot. ^.^;
What is an āalmost native experienceā, and please donāt say PWA, Iāve yet to see any PWA that feels even remotely native (there was a huge thread on that in these forums not long ago)? Anything that runs in a webpage/webview is not even remotely native feeling.
I think for many apps you can take the performance to a level where it will feel as if itās a truly native app. Uberās Android app runs in a webview and I think itās performance is great even on mediocre devices.
1 Like
Itās not just performance, I exceptionally dislike when a program does not āactā like the rest of the system. I have a very specific dark theme with a very specific magnification of text (making it much smaller actually) and I expect the same interface through-out, swipe in from left for options and primary menu, from right for context-specific menu, double-tap top to jump back to top of whatever scrollable, etcā¦ etcā¦ etcā¦ Webviews and apps made in somecrazyguitoolkit always end up doing things wrong. An example of a well made third-party program is Sync For Reddit, it fits the interface so fantastically, can be themed perfectly, is extremely responsive in ways that even few native apps, not to mention the horror of webapps, can ever achieve, and itās a network interface to reddit of all things! ^.^
3 Likes
This is the best summary of their hybrid native approach Iāve found.
Itās out of date now (> 4 years!), and I suspect their approach as changed/matured; but it explains the gist.
They use a native app, native menus and interface and just use the web views for page content. Admittedly it doesnāt buy you any functionality over the mobile web app ā they should be almost identical, save for menus ā but makes the app easily accessible and feel more native in a way that a mobile web app doesnāt.
I donāt think itās a perfect solution, but where the app largely mirrors an exciting website I think itās a healthy compromise. Certainly preferable to the web site being built as a single page React app so that āmigrationā to a React Native app is easier.
1 Like
