Can you explain what you mean by “Live App” era vs React era? Can you point towards resources which might disambiguate the two?

Sure! Basically, the idea is that rather than requests in JavaScript going through an API, each user connection is maintained by a lightweight process on the server (which Elixir can scale easily), and then interactions with the page are pushed as a diff via WebSockets and then magically merged into the DOM. Interactive pages, no JavaScript required. I'm still pretty new to it, but after learning the ropes it's seeming very productive, and most importantly, fun.

https://dockyard.com/blog/2018/12/12/phoenix-liveview-intera...

So pretty much the Blazor Server approach in the Dot Net world then?

Blazor Server and Blazor WebAssembly needs to be marketed separately. Most people have heard about Blazor WebAssembly but are unaware that LiveView-style web development is possible in the .Net world using Blazor Server.

Yes, yes they do. I don't know why you'd name pretty much the exact opposite techs the exact same thing.

I don't use Blazor, however when I went to get basic info about it every article I have read were very clear that there's 2 ways to dev a Blazor app.

It's also not unlike JSF in the Java world, which went out of fashion 10 or so years ago, and for good reason: relying on a framework to paper over the distinction between client and server side turned out to be much more complicated and fragile than a cleanly defined separation. I haven't seen any authors or users of these recently developed server-side-first frameworks discuss this prior art, but I'd be interested to see if they've come up with a way around what seemed like a fundamental problem in the approach.

As former JSF framework tech lead built on top of Richfaces, the major problem with JSF was its lifecycle model and the fact that Sun et al only defined the basic infrastructure and lead to a forest of frameworks that could hardly interoperate among themselves.

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.

Yes, basically. Fun fact: Blazor and LiveView were developed independently, around the same time as each other! Just two similar implementations in disparate communities.

Guess that was due to browser-land innovations that made this a possibility.

So then this can never work offline like a single page React PWA could then I guess? For me after seeing offline-first PWAs it's hard to want to go back to building stuff that's only available online, but I guess everyone's use-case is different.

Not saying offline-first apps have no interest, they totally can have some.

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.

what is your use case of offline ? I've never seen the point. For example what the purpose of a social offline app ? I can't refresh feed, I can't upload post or react to any thing in my feed.

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.

We made a pwa for our sales team. Globally they visit millions of stores everyday and more than 80% stores are in poor or no internet area at all.

They need to make sales order, survey, etc while offline and sync with our server whenever they get internet connection.

Yes! I think it's hard for people in the 1st world to imagine that not everyone can get data whenever they want. In one country even YouTube added a feature for downloading and saving videos for offline viewing because they knew that internet was often slow or unreliable.

i'm currently thinking about building something similar - do you mind sharing more about what tech stack you used, esp. how you handled the offline data and syncing?

Was PouchDB / CouchDB used? I've found that it works marvelously for no-hassle syncing.

Sorry very late reply.

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.

Thanks for the reply. And I guess you do the service worker -> postgresql thing to avoid the database-per-user setup with pouch-couch 2-way sync?

A dictionary that works offline (and updates when online), book-like educational reference apps that people can access when they don't have data or if they want to turn their data off to study and not be distracted by notifications. There are tons of things that people want to download/install on their phone as traditional apps, the PWA just makes it cross-platform and available for all.

Working on stuff, not communicating. e.g. Google docs, Photopea.

OP probably talking about Phoenix's "LiveView" (https://www.phoenixframework.org/ check the video about it).

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.

But you still need JS to update the DOM and handle the websocket stuff, right? Or is this all somehow done with JS disabled?

It’s done with JS but that’s all written for you. But as a bonus, LiveView apps do work without JS (they just aren’t updated over web sockets anymore).

I assume you have to specifically design your site to work with both the request/response model and the LiveView model in order for this to actually work, as opposed to LiveView being able to plug that hole automatically for you.

To be a little more concrete, here's an example:

  <%= live_patch "about", to: Routes.about_path(@socket, :index) %>

which creates:

  <a href="/about" data-phx-link="patch" data-phx-link-state="push">about</a>

The data attributes are read by the LiveView HTML and are otherwise ignored by a JSless broswer.

Edited to fix glaring code sample error.

You can design singularly for LiveView and it handles everything. But if you want both request/response and LiveView (e.g. to mix the two or fallback to r/r when no js) you have to be more explicit in your design. It’s mostly trivial though. I have authentication pages that use the old controllers but pages that use only LiveView without any hassle.

Nope, all you need to do is make sure that everything has a route (which is very much encouraged in LiveView) and it works.

Right. It uses JS but you don’t write any. Or very little. Or in a custom DSL/framework.

Important distinction, as it wouldn't work when JS is disabled in browsers.

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.

> as it wouldn't work when JS is disabled in browsers.

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.

Yup, this is my thinking as well. If I go back to fully server side, it's because I can somehow instruct the browser to update without JS involved.

Don't you have to scale your api too ?

I have (limited) experience scaling long-lived websocket connections and it _sucked_. It is _way_ easier to scale out little Node servers that are "stateless" than it is to ensure that Client A is connected to Socket A.

I would much rather scale out my REST/Graph/RPC API instead of having to scale out a WS API.

Yes, but now you have to scale both the data layer logic and view layer logic when doing server side rendering.

So now it's two times the hassle, two times the money spent

99% of the time no one runs into scaling issues and worrying about it is premature optimisation. I have to remind myself that all the time.

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.

The term “era” in this context has to be interpreted as a personal perspective to not be confusing. The mentioned paradigm is not new nor does it replace/evolve from React and similar.

Having recently looked into Blazor Server (similar to LiveView but in C#), one of the cons Microsoft listed was the scalability (compared to a typical SPA) as each client now needs an active websocket connection to the server, which will require more server resources.

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 thing that elevates Phoenix in this regard is since it’s built on Elixir (and consequently the BEAM), adding a new “process” to hold the web socket in memory is trivial and basically comes for free out of the box.

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.

There's a thriving ecosystem these days around the ASGI standard for building concurrent web applications in Python - it came out of the Django project originally but Starlette and FastAPI are the most widely used implementations of it.

ASGI is a bad solution to the concurrency issues as the ecosystem is heavily centralised around asyncio (which is ``java.lang.Thread`` for async/await, with all the pitfalls included).

Could you elaborate on what you mean by that? I can think of two interpretations, both wrong:

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.

I haven't done frontend work for a few years, but Angular was really a revelation to me when it first came out. For all the headaches, it made it practical to do stuff that was really cool.