I’m new to this discussion, and to Elixir (and thus, Phoenix) in general. I started delving into Elixir literally just within the last month, due to a company I work with already being heavily invested in Elixir on the back-end. I became aware and curious of Elixir through conversational osmosis from team members, more than anything else.

I’m the author of ReactQL project, a prototypical JS stack these days: React, Apollo GraphQL (including to manage local state hydration), Styled Components, Webpack, written in Typescript, fully SSR’d. So that gives you an idea what has been my general approach to writing front-end apps (and with a large enough cross-over, back-end APIs too.)

Even with this preference/bias, I can honestly say that after watching @chrismccord’s unveiling of LiveView on stage, I’m more excited about this library than I have been about any other lib or stack piece, in quite some time. On par with early-day DHH RoR videos, or Meteor.js demos. So much so, that for my next major project (the timing being right, and all), there’s serious cause to drop my usual go-to stack - and the platform I’ve spent a bunch of personal time authoring - in favour of a pure Phoenix + LiveView front/back-end.

I really don’t understand some of the criticism I’ve seen. The solution LiveView provides is, IMO, obvious, and plugs a serious disconnect with current alternatives. I know of a great many developers who turn to React, Apollo, Redux, etc because they lack better options. Given the opportunity to render entirely on the server and turn the browser into essentially a ‘dumb’ DOM updater would solve a boatload of problems that many of these stack pieces introduce.

Off the top of my head:

• Competing packages that update the DOM. Opting for React requires, for the most part, singular buy-in; using it with jQuery or other pieces creates problems maintaining DOM state in React lifecycle methods, especially when introducing SSR. Having the server drop down just the pieces that need updating eliminates a class of problems that competing DOM renderers can introduce.

• SSR itself. Introducing JS packages that require a window object on the server-side usually requires that the packages themselves have defensive typeof checks (which rarely is the case.). NPM packages just aren’t often built with isomorphism in mind. In ReactQL, I approach this by having a SERVER constant baked into the Webpack config, for code blocks that can be tree-shook out of the final build that aren’t applicable. This often causes problems, though, for import statements; if they’re not at the top-level, they’re implicitly Promise-returning, which changes the loading strategy of additional modules and can be hard to keep track of. This problem disappears if the browser just consumes packets of HTML.

• Data management with a separate API. In ReactQL, we await GraphQL data on the initial HTML render, but after that it’s up to the client to load it directly. This has numerous issues out-the-box: CORS/cross-site concerns, async data states (i.e. guarding against null data or loading: true with additional checks/UI.), re-hydrating server state on the client, storing auth tokens in session/local storage, etc. Leaving data loading to the server and having it pipe down changes when it’s guaranteed to be loaded solves a whole class of problems. This alone makes LiveView extremely compelling.

• Real-time by default. Real-time is very hard to get right. Few platforms provide obvious solutions. Until now, we’ve been solving this with Apollo GraphQL subscriptions, but that doesn’t answer the infrastructure concerns around data loading, scaling to multiple processes/machines, broadcasting efficiently, etc. Having this out-the-box with Phoenix is a huge boon.

FWIW (coming from someone that has exclusively front-end JS for a decade) I’d also consider the point of JS fallbacks to be entirely moot. In the past 10 years, I haven’t once come across a use-case for building anything for users that explicitly have JS disabled. Try visiting any major site with JS disabled. It’s practically unusable. Aside from a few tinfoil-hat wearing types and explicitly locked-down corporate environments (which is exceedingly rare), who disables JS these days? That hasn’t been a concern since at least the mid-2000s.

So all this to say: Thank you @chrismccord for working on this. I can’t wait to see it released (ETA? pretty please?). And thanks to other authors for working on similar libs that perhaps didn’t initially (or ever) get the traction or attention they deserved. I personally am very excited to see Chris work on and support this directly - that gives me a lot of confidence that the compatibility between LiveView and Phoenix will be first class.

(Now if only I had some code to play with!)

This is true, we are taking the react model (or elm architecture) and placing it on the server.

This is the exact model we take on LiveView.

So let me preface by saying, are client apps increasingly necessary as the clients become more powerful? Absolutely. That said, do the majority of applications require this complexity for the UX the developers are after? I don’t think so– unless folks are after the SPA usecaes I mentioned in my talk. With solutions like LiveView I think a lot of folks can avoid the complexity and still get the UX they want with way less effort, which I imagine is why this is an exciting way to writing applications for many of us.

I don’t know about the ignorance to HTML/CSS point, but I think in general a large part of the webbev community has reached prematurely for client frameworks for any kind of rich interaction. I think a lot of these frameworks like react are great to “sprinkle” in for rich features, but once react/ember/elm/et al is in place, then it becomes increasingly tempting to adopt your point of view, where the separation of client ↔ server is the True Model and the natural path of web development. The issue is we’ve been running this experiment for years now with client-side apps, and so far from what I see is the best folks served by this added complexities are consultancies who get to bill and maintain all thus churning complexity. Who here has had the privilege of upgrading or maintaining Angular 1 for example? So you absolutely can produce incredible client applications with the great available frameworks we have today, but the cost we’ve taken on to make it happen has been enormous and I think folks are more aware of this than ever. It makes sense for some apps, but I know a lot of folks who look back and certainly find it not worth it in retrospect.

The 60fps was to showoff the performance of the approach, not to promote using LiveView for sending an html page every 16ms . Performance wise, we’re planning to perform diffing on the server to only send the bits that have changed.