Advantanges and disadvantages of using phoenix liveview for ecommerce website

We all know that by using phoenix framework in proper way, we can build a highly reliable and scalable websites and apps backend.

Phoenix live-view is an amazing feature of phoenix, which allow us to make a interactive website without any javascript client side code, which will save a lot of front-end development time.

I want to know :
What are the advantages and disadvantages of using phoenix live-view for building a e-commerce website? (which is currently in active development)



The standard answer you should get in all these situations is, of course, “it depends”. You are asking a fairly broad question so definite answers can’t be given.

That being said… I can think of a few points:

  • Advantage: minimal JS work. Many website projects stumble when JS has to get a bit more complex. And I don’t mean the projects that can afford 5x JS rockstars / ninjas / hackers / whatever-they-love-being-called, I mean like 2 backend guys who now curse their lives for having to learn JS. So LiveView can be really valuable for smaller-budgeted projects.

  • Disadvantage: maybe in hosting bills or quickly getting to a point where the user experience is laggy. LiveView requires a WebSockets connection, and many cheaper hosting providers’ servers will quickly bend over the pressure of, say, 10_000 live and active connections. This however very much depends on your hosting provider! It’s not an universal truth.

  • Possible disadvantage: don’t forget LiveView is still under active development. It’s possible that a future updates breaks the API and you’ll have to do rewrites here and there. Although I don’t think that’s very likely to happen from this point and on, it’s still a possibility.

  • Advantage: LiveView to me isn’t a clear win in terms of code size (or files where important bits reside) compared to a vanilla Phoenix website, but it does look more readable and clear to understand to me at least, which has led to a bit faster iterations in 1-2 hobby projects of mine. Subjective though.


Possibly another couple of points to build on what @dimitarvp already said:

  • If you have a fairly high complexity front end ambition you may need to do at least some of those parts in JavaScript anyway. LiveView is impressive but it probably isn’t going to get you into something like clustering on google maps (not exactly an e-commerce requirement but an example of something that would not be ideal). So depending on the UX design it may be well suited to some, all or none of what you want to produce, you will only really see it as an advantage if the use is appropriate.

  • a flat out advantage on the JS side is that a well designed and well built JS app could be turned into a mobile app or electron desktop app without starting from scratch. You wouldn’t get this for free just because you made a JS app, but you could design your JS app to leverage this possibility.


Also, one more advantage is that in phoenix liveview after first page load, only diff will be send to clients, which will save network traffic.

Also, we can use kubernetes so when traffic increases, we can add more servers and user experience may not be laggy then.

1 Like

Adding to this, there may be some things that are more difficult or impossible to do effectively in LiveView because they’re simply not implemented yet or are still low priority. For example, I think doing some sort of drag-and-drop (say, to sort lists of data in your website) is not very simple to do at the moment.

1 Like

Agree, and thankfully LiveView has an escape hatch with hooks. I used this: as a guide for sorting a list - the JS library handles the UI, but as soon as the drag is done the backend model is updated. The sample code is probably more complex than you probably need because it sorts columns as well as items in a column.

I think the single biggest potential issue is lagginess for certain types of UI. For example, playing some of the games people have hosted in the US from Australia is not fun - they are too unresponsive. For average picklists, calendar popups etc etc it is fine. Test whatever you have in mind with a 250ms lag…