Thanks @cpgo @OvermindDL1 @PragTob for the code simples. This should me to get started.
Iām sure if you guys work on it a bit and make it more compatible with Phoenix it will rise very high in popularity. My friend who is Laravel user said that Vue.js become famous because Laravel team praised it on many occasions and Jeffrey way and Taylor Otwel recommended it with Laravel, otherwise it was very hard for a new framework to get so much successful in the presence of Angular and React which are backed by tech giants.
It is already fully compatible with Phoenix.
You only have to write a hand full of code, if you want to support the server protocol ā which is optional. If you write an application with elixir/phoenix the hand full additional code should not add much complexity.
Iām sorry that I failed to explain what I meant.
I mean something which can be installed through a package, like Turbolinks in Rails.
I think if React needs extra work at the front-end, itās already visible, so better to install it through webpack or whatever bundler at the front-end, but if Turbolinks is invisible and donāt need extra work, so there should be an option to install it through the Gemfile, which is exactly the case in Rails (you can install it as a gem (default) or you can install it through webpack etc).
Similarly if there is the option of installing Unpoly though webpack etc, and also as a hex package if someone wanna use it that way, it will make the library so popular in Elixir community, and Elixir community is growing very quickly, so it will be great for the libraryās future.
I think weāre all in violent agreement
While Unpoly is completely language agnostic, the concerns at the top of this thread make it clear that we could communicate this better. Also the optionality of the server protocol confuses a lot of people. Offering a small Elixir package would go along way ensuring people that they wonāt have to jump through hoops.
Of course we all agree that itās language or framework agnostic but,
it will make it easier for novices like me.
and Thank You @triskweline for this awesome library!
You already can, just npm install --save-dependency unpoly
(or whatever the save command was called), then just link it in as normal.
In life there are things which look more scary than as dangerous they are in real, npm install --something is one of those things for a non-JavaScript programmer.
Anyway Iāll take your word for unpoly and will use it before it becomes a package, through the npm command.
You know you can just turbolinks now right? it has an npm package
Except unpoly by default updates smaller bits and thus is faster, in addition to quite a host of other useful built-in functionality.
Wow dude unpoly looks deep. Howās the learning curve? Do you know if it has mobile capabilities? Like turbolinks-ios?
The author actually appears on these forums on occasion. ^.^
From what I gather it was made by a company that wanted proper progressive enhancement and they either didnāt know about or didnāt like turbogears, so it is full of features they needed, thus it was built up to get āworkā done.
Well itās a pain to merge into a build system because lack of ES6 support and an odd testing framework, but if you just vendor it then it works fine. Actually using it is almost stupid-easy to use, you just decorate your elements with special attributes is all. It has a great āRouterā system for plugging other things and functionality in to it as well for if you want to touch javascript.
My work site works entirely well on mobile here. You can try out their own website on mobile too if you want. No reason it shouldnāt work though, worst-case is things just fall back to standard HTML so nothing should ever break regardless.
Never heard of it, I donāt touch platform-specific things (I and everyone I know in real life are android users, but even I still wonāt touch android-specific things, I keep to the spec when at all possible).
basicProgrammer actually meant Turbolinksā native adapters for iOS and Android. Turbolinks-Android and Turbolinks-iOS give you the capability to turn your turbolinks based front-end into hybrid Android and hybrid iOS apps.
What the turbolinks-ios
and turbolinks-android
adapters do: Whenever the user clicks on a link, your native code is asked whether it wants to handle the link with non-web technology. E.g. when the user clicks on a hamburger button, you might choose to open a native menu instead of displaying navigation options with HTML and JavaScript.
Unpoly has no such adapters. What you still can do is wrap your wrap your entire web app in a Webview if you want to place the app in an app store, and/or use the extended JavaScript API provided by tools like Cordova.
You could also just make a web app that works well on mobile without going through the hassle of compiling a native app, as Iām assume @OvermindDL1 is doing.
Let me know if you run into an issues with Unpoly, Iām happy to help.
Yes, I prefer webstandards or pure native (maybe flutter actuallyā¦) apps; once you start getting into platform specific things thatās only a crutch of poor cross-platform design as you then have to start dealing with platform versioning and other platforms that you yourself may not deal with but others use and so forth, where standards should ājust workā and if they donāt then yell at the idiots that implemented it wrong⦠^.^
if someone is targeting mostly mobile users, I would not recommend using unpoly. On my mobile devices it is slower with unpoly than as a normal (not with unpoly enhanced) website. unpoly is easy to use and great for ārealā computers, but one has to test, whether the performance loss on mobile devices it worth the additional comfort.
How is it slower Iām curious (Iāve not see it with my sites yet)? Is it the DOM-walking time to get the attributes (I try to keep my DOMās sane and small unlike many sitesā¦) or is it something else?
actually I do not know the reason. But triskweline has analysed it, so he should be able to answer that. See: Redirecting to Google Groups
And there is also a (closed) issue on github about that problem (a side menu takes one second to react to a click). See: https://github.com/unpoly/unpoly/issues/48
Wow that definitely doesnāt happen at work! I use side menuās for a lot of side-pages and they load about instantly when clicked! They do only load once the server has responded though so maybe they just have high latency from the server? Have they checked the network tab in chrome/firefox?
That⦠was not an error report, so yeah that is entire network latency, that is NOT unpoly being slow and rather if they want something to indicate loading then they should use a loading overlay (of which unpoly has support for, all you need to do is make the right css stuff and so forth).
Again, same issue, that person does not seem to know how networks and DOM swapping works. How could someone think that unpoly could display what the server sends before the server response arrives, that makes no sense⦠Unpoly was not slow, their network was slow, and the person should have added appropriate things to show a loading indicator if they wanted one (which I do have, kind of an animated Work logo thing). I just donāt get how they are saying unpoly is slow when unpoly just cannot magically render what the server sends it before the server actually sends it across the network, that⦠just makes no sense⦠o.O
/me is so confusedā¦
But at this point this is nothing but hearsay as unpoly is plenty fast, the only issue is the network connection, which unpoly has no control over at all but unpoly does give ways to ease network issues via loading indicators and other pluggable thingsā¦
I ran a couple of performance traces when @svsdehh posted to the Unpoly group some time ago.
There are a number of spots where Unpoly could be easier on the CPU. E.g. to mark links as a.up-current
, Unpoly spends a lot of time going through each link and comparing it to the current URL. I have been working on optimizing this a lot. This will be part of an upcoming release.
I also need to look into optimizing animated transitions. Right now Unpoly clones the old and new page and animates the clones. A lot of transition libs work that way, but it forces a full layout / reflow / repaint cycle on the browser. Maybe there is a way to make a page transitions without cloning elements.