That is indeed true, but something that gets mitigated by loading less JS and less CSS in each request (and also by internet speed). Having a clean, non-bloated design that does not use fancy JS for effects and what have you, is in my opinion, a better experience (it also makes the page easy to navigate by screen readers for people with disabilities).
Another advantage to this approach is that the initial load of the page does not have to load all your JS framework code and your own code in order to run, which will make the initial load really slow. Subsequent loads will be cached, but stillā¦
Something like unpoly is such a shim, it loads pages from the server async then swaps the needed parts in the DOM, it is quick, still all server-side rendered, you can even add transitions and more.
/me uses a lot of unpoly.js, wishes it was module-based though, but eh
Phoenix is fast, that time delay effect of page transitions is not a big deal compared to all that needs to be cared for using a complete VueJS solution on the front-end: state store, routing etcā¦ no to mention webpack and npm and as you have said the possibly huge JS file that needs to be loaded on first visit.
How big is your js file with vuejs? The last time I used it, it was prettry small, about 50kb gzipped, and it included router, vuex, vue, and my application.
And downloading 50kb is hardly noticeable unless you are on a modem (http://www.download-time.com says itād take 7 seconds)ā¦
Right now though Iām looking into preact, which, together with a router and redux, fits in 10kb.
Have you encountered any limitation with Phoenix on API backend and VueJS on UI?
No, but if I were doing it again, I would probably use graphql for talking to the backend. VueJS was nice for UI, I really liked its styled components.
I might even use a different setup in the future, with cowboy websockets (or something of my own) for app logic and nginx for sending out js chunks from webpack. That would make the website extra fast, I guess. And scaling extra hard.
Have you implemented user authentication on that setup?
Yes, I sent a phoenix token to the client and stored it there. And then included it with every request in the Authorization header as a Bearer token.
Not yet, Iām currently working on my web serviceās frontend with RE:DOM but it wonāt be a single page application, but rather it will be used to enhance some places, to draw graphs and stuff. Iām still quite new with it so donāt yet have good rules how to organise stuff. But the smaller things I have made with it have worked well and it has been fun to write.
It seems like all the preferences are geared towards landing/info page sites.
What about full on Facebook / Gmail / Forums / CRM type web-apps?
How they have front-end user experiences and full on admin specific user experiences that are completely different. With all kinds of users in different companies, where there are all kinds of views depending on the action of the current user. Adding/removing features based on users or group memberships etc
I like the Ember.js framework ideology. My biggest annoyance with these frontend frameworks is the all or nothing part. If someone loads up the signup page, they donāt need the admin app or the full logged in user part yet, even if they are logged in, there needs to be a balance between first response and quick 2nd page. Ember has engines finally to help with this.
On a page by page basis I like the simplicity of other frameworks/libraries, however to get some efficiency across the whole app, spending time making components inside a full framework and stitching them together in the page as needed has been great. For example with a simple information game (think rpg, clan, army kinds), while the REST way was fine every single resource on its own page works it was super slow to get anything done. I needed lots of information from many endpoints on the page in their own little space on the screen and they all needed to update based on actions happening in the backend.
This is where I see a full framework like Ember.js being a great fit. If I were building a landing page/informational product site Iād go pure HTML with a helper if needed to make something appear instantly responsive to actions.
I would suggest Ember.js. Itās fast, easy to learn, has a great tooling story (ember-cli) and can be easily extended through addons (see Ember Observer for existing addons).
The post mentions Unpoly specifically which has a tutorial.
In terms of terminology it is interesting to note that people often use the term āshimā when they mean āpolyfillā (What is the difference between a shim and a polyfill? - i.e. not every shim is polyfill) - Unpoly isnāt polyfill (unless itās poly-filling āitās own imaginary standardā). The creatorās tagline:
Itās not you, Itās Us
Weāre Breaking Up With JavaScript Frontends
Henning Koch, makandra GmbH @triskweline
