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?
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.
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…
Stimulus is also created by Basecamp. It’s official website says
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.
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.
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.
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.
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?
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.
The only advantage of Turbolinks is that you get for free the integration for IOS and Android, as exemplified here
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.
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.
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! ^.^
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.