I am considering my options regarding a future project and I appreciate hearing from forum members regarding this. I am planning to build a site which utilizes heavily content filters (categories). The user would find what he’s looking for by making some check- marks, search terms and / or selecting categories.
My question, I want the site experience to be fast and easy. Can this be achieved with pure Phoenix HTML or would it be better to develop the back-end as Phoenix API and write the front-end with a JS framework?
Which contrib. modules would you suggest to use in conjunction with Phoenix HTML to build a project like this one?
Vue is a very solid choice, because it combines some of the great things about angular, and it’s also quite simple. It can be intricate if you need it, but at the low end vue can be straight out of the box extremely simple (fits in well with plain vanilla JS), and can handle 2 way binding so that filtering and stuff is taken care of.
Hey there, I’ve worked on a few SPA apps and some server side rendered ones. From what your describing you can do that with just phoenix easily enough, @mbuhot has a good suggestion there. Otherwise a small amount of React/Vue/Glimmer/Elm/Reason ect. would do the job. No need for a SPA with those requirements.
@James-Byrne I have already experimented with VueJS and Phoenix API in the back-end, it worked fine, I liked specially how fast navigation experience is for end-user. I have also used in another project VueJS partially within Phoenix HTML templates, this worked also very fine especially when it comes to filtering results. What can be a concern using pure VueJS on front-end for a public website is initial page load time as the application gets larger.
Would you kindly elaborate more about when you would definitely recommend using pure VueJS on front-end? Which scenarios?
In my mind there isn’t any one reason you’d use a single page app over a multi page app. It really comes down to the type of user experience you want to create and what the team working on the project is comfortable with. So if you want to create a really dynamic web app with lots of user interaction, holding state (thats a big one) and provide the best user experience possible then a single page app is going to serve you well. However there are a number of downsides that come along with building a SPA. Namely you now have 2 code bases and 2 apps instead of one to look after, slower initial load times, SEO issues, javascript (10 + [] = "10" … obviously).
So choosing when to use one over the other is really a per project thing. For instance at Testing Pays we have an ember app for our main site . But our “front page” site (the marketing one) is server redered html, we’re looking to add some functionality to that one soon and we will likely use glimmer for that.
@James-Byrne, thank you, I appreciate your input. In this regard, would you recommend combined VueJS & Phoenix HTML on front-end or complete VueJS on front-end for an e-commerce site?
There is a huge difference in the authentication mecanism depending on your choice.
It’s fine to use session authentication if You use a mix of HTML and JS framework. But if You completely separate both, You will need to implement a token based authentication, as with most API. That can be a bit painful first time You do it.
Sometime You don’t have the choice and You need to fully separate frontend from backend. For example when You go mobile.
In that use case, I would prefer React Native over Vue, because of the ability to write real cross platform application.
There is also NativeScript-Vue which is another mobile native solution leveraging Vue. Not sure which of these Vue options is the most stable for production, although certainly React Native is currently much more popular/mature.
For an e-commerce site in particular I would recommend using a mix of Phoenix templates and Vue partials. E-commerce websites are in general not very dynamic, they don’t hold a lot of state and page transition times are not limited by the speed of a network call, rather the time taken to get and filter the data the user wants (when filtering products). Overall e-commerce websites have a lot of heavy lifting to do as CRUD apps go, as such I’d rather leverage the performance of Elixir and just do a really good job of making the page transitions look and feel good.
@kokolegorille brings up the conversation of going mobile with this app. Firstly if its not something you where thinking of already then I wouldn’t start. Pick the best tech for the platform for what you need now and go with that. Otherwise you’ll be waiting for Angular/React/Ember/Vue/Elm version n+1 forever.
If however you are thinking of going mobile then I’d recommend you look into building a progressive web app instead. Your app can’t work offline (I mean fully functional there, need internet to make a payment after all), you don’t need mandatory user accounts, your performance bottleneck is the speed at which you retrieve data from the server (not render speed). Overall I don’t see what a native app gives an e-commerce site over a well built PWA. You also have the advantage of building a single app then rather than building for multiple platforms. However this is getting into the weeds a bit.
Why not Turbolinks? You can do a lot with it. There is this awesome presentation with a good overview. You can study changelog.com source code here, which uses Elixir/Phoenix, Turbolinks, plain ES6 and umbrellajs
Depending on use-cases I highly recommend either Drab or Unpoly.js (Unpoly.js is a bit more SEO friendly as it ‘lifts’ static pages but is otherwise fully backwards compatible with no javascript at all).
For note, Unpoly.js is like Turbolinks but a bit more declarative in design, a few more features, less rails-focused and more general, etc…
