6 ms·
Can you explain what you mean by “Live App” era vs React era? Can you point towards resources which might disambiguate the two?
by SoylentOrange 5y ago
Can you explain what you mean by “Live App” era vs React era? Can you point towards resources which might disambiguate the two?
- Mizza 5y agoSure! 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.
- trymas 5y agoOP probably talking about Phoenix's "LiveView" (https://www.phoenixframework.org/ 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.
- beardedetim 5y agoBut you still need JS to update the DOM and handle the websocket stuff, right? Or is this all somehow done with JS disabled?
- dgb23 5y agoRight. It uses JS but you don’t write any. Or very little. Or in a custom DSL/framework.
- hunterb123 5y agoImportant 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.
- dqv 5y ago> 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.
- beardedetim 5y ago
- dgb23 5y agoThe 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.