6 ms·
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 se
by Mizza 5y ago
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-interactive-real-time-apps-no-need-to-write-javascript https://dockyard.com/blog/2018/12/12/phoenix-liveview-intera...
- drbw 5y agoSo pretty much the Blazor Server approach in the Dot Net world then?
- shijie 5y agoYes, basically. Fun fact: Blazor and LiveView were developed independently, around the same time as each other! Just two similar implementations in disparate communities.
- pantulis 5y agoGuess that was due to browser-land innovations that made this a possibility.
- keewee7 5y agoBlazor 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.
- SketchySeaBeast 5y agoYes, yes they do. I don't know why you'd name pretty much the exact opposite techs the exact same thing.
- jmnicolas 5y agoI 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.
- culturedsystems 5y agoIt'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.
- pjmlp 5y agoAs 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.
- adamddev1 5y agoSo 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.
- BoumTAC 5y agowhat 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.
- recursive 5y agoWorking on stuff, not communicating. e.g. Google docs, Photopea.
- ies7 5y agoWe 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.