Hacker News Reader

Comment by Mizza | Hacker News Reader

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...

View on HN

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.

Reply on news.ycombinator.com