https://dockyard.com/blog/2018/12/12/phoenix-liveview-intera...
To the point that on my follow up project I ended up recomending for JSP with tag libraries instead, regardless of Sun advising them as deprecated and replaced by JSF.
WebForms never felt as complex as JSF.
I feel JSP like models with component libraries, or MVC are more closer approaches to the whole Web programming model.
The only use case I know is for map where you can download map so when you don't have 4G you will not be lost but that's the only use case I know.
They need to make sales order, survey, etc while offline and sync with our server whenever they get internet connection.
But yes we use pouch+couch to one way sync from our server to thousands device.
And from our sales force device to our server while we still save the data in pouch, we choose to use pwa's service worker to send directly to postgresql instead of pouchdb-couchdb sync.
But in more than ten years, offline mode have never been a requirement on any of the projects I worked on.
What I’m saying is that offline mode is just a feature like any other and it’s one with a huge cost in architecture complexity.
And, although it’s just my own opinion, I think if you want to be offline first, odds are that better stacks than the web exists for those needs.
Phoenix LiveView is a framework where it keeps websocket open with the client and renders DOM changes server side and passes it to the client [0]. Thus with fully server side development without any JS you can have almost full SPA experience.
[0] Have no experience with it, and only read about it some time ago, so don't judge me on the details, but the gist of the "LiveView" idea should be like that.
I don't see the point of going back to full server side, you have to scale more with more users.
The only benefit would be if it all worked without running JS in browsers, but it doesn't.
And no, same hassle, same money spent. Thought about from the start server-side rendered pages are almost as cacheable as API responses will be. If you can't cache you're in for a world of expense at scale whichever way you go.
I would much rather scale out my REST/Graph/RPC API instead of having to scale out a WS API.
You can make it work when JS is disabled as well, you fall back to rendering regular HTML. It does require a little extra work, but it’s not insurmountable (e.g. using @conn instead of @socket).
>you have to scale more with more users
I might opt for additional optimizations once it gets bigger, but I’m not too worried about scaling Erlang processes.
<%= live_patch "about", to: Routes.about_path(@socket, :index) %>
<a href="/about" data-phx-link="patch" data-phx-link-state="push">about</a>
Edited to fix glaring code sample error.
Do you have any experience in that? I'd love to know where server resource requirements sit between SPA, this and a typical SSR site like Django.
The Phoenix core team has demonstrated over a million (maybe it was even 5?) simultaneous connections running on one server all being updated at once. Granted, it was a proof of concept, but in the real world, you would load balance well before that in all likelihood. The point is the same though. BEAM languages can easily manage a hundred thousand nodes of state simultaneously without breaking a sweat. For most apps, this is plenty as demonstrated by discord, WhatsApp, and other BEAM focused tech companies.
1. Asyncio is like java.lang.Thread in that it's very low level; which isn't accurate: it's totally acceptable and easy to write async concurrency using asyncio (the python async stdlib) directly. While frameworks like Trio are nice they're nowhere near as necessary when working async as thread/pool managers are in Java. 2. Asyncio is like java.lang.Thread in that it has similar pitfalls to threaded programming in general. This is also untrue: in async programming in general, race conditions are much harder to write, and concurrent modification issues aren't a risk at all in Python async code the way they are in threaded Python or Java.