The common retort from SPA devs is "what about offline?" Since LiveView keeps state on the server, it doesn't really work offline.
However, 1) you can add custom JS using LiveView's hooks, which might be enough for very simple offline behavior and 2) many SPAs don't work offline either.
If offline support is a major part of your app's design, LiveView isn't a good fit. But you could still use Phoenix Channels (the building block underneath LiveView) to provide fast push updates to your client. See the channels docs for an idea of how they work - https://hexdocs.pm/phoenix/channels.html
> The only modern web problem that Elixir isn't ideally suited for is heavy number crunching.
I would caveat that in a couple of ways.
First, suppose you have a web app where some requests involve heavy number crunching and others don't. In web frameworks where 1 request ties up 1 OS thread, a burst of heavy requests could gobble up all your available connections. Phoenix would use one cheap BEAM process per request, and the BEAM's preemptive scheduler would ensure that other requests are answered in a timely way and that all the heavy ones continue to make steady progress. So although the heavy requests might be completed more slowly than in another language, the overall system would remain more responsive.
I like to say that the BEAM's preemptive scheduling provides non-blocking IO AND non-blocking computation.
To expand on your workload description: things like waiting for a database query or an API result are smoothly handled in this paradigm; the process goes to sleep for a bit whle another request is processed.
If your workflow is like a delivery truck which makes a lot of stops, "faster trucks" doesn't help much with throughput. "More trucks" is better.
Another consideration: Phoenix PubSub makes it simple and performant to add more servers. So if one (say) chat app server can provide acceptable performance for N users, you can serve N more users by adding another node.
Imagine this: you set your browser to download only the first N bytes of each image, showing you a decent preview. If you want more detail on a particular image, you tap it, and the browser requests the next N bytes (or the rest of the file, if you prefer).
And to enable this, the site only needed to create one high-resolution image.
Seems like a victory for loading speeds, for low-bandwidth, and for content creation.
Agreed, but is it likely? Does any browser implement the even simpler feature "Show a placeholder for images. Tap the placeholder to load the actual image"?
I believe it's a joke referencing the default password for mssql for many years of sa/null. Eventually the install started forcing the user to change it to something, but for a time there were many mssql databases out there with a default password of null.
