Let's discuss Phoenix LiveView

phoenix
elixirconf2018
liveview

#102

Hi,

My 2 cents, my webapp/website uses pjax-api. It’s like turbolinks but with the capacity to selectively update certain part.

I use it to maintain an audio stream and/or a YouTube video during navigation.
I configure pjax-api to replace only the main tag. No need for SPA.

It’s a good usecase for liveview. .


#103

Hi, For a comparison with where LiveView looks like it might be heading, in the Java world, Apache Wicket is a highly successful open source, component oriented, serverside web application framework that’s been doing server side since 2004 and with many thousands of production websites (being one of the few survivors of the Java serverside web framework wars of the mid 2000’s).

It successfully handles the impedance mismatch between the stateless nature of HTTP and the need to handle complex state without the usual MVC world of requests, routes, controllers, views etc.

Obviously it’s not as sophisticated as LiveView promises to be, however it’s a very successful model well worth looking at for lessons.

https://wicket.apache.org

https://builtwithwicket.tumblr.com

Regards …


#104

Unpoly is awesome! It will be nicer if it’s not dependent on jQuery. I heard that jQuery dependency is going to be removed in near future. Is that true?


#105

Yes. I’ve been working to remove jQuery in the hk/kill-jquery branch for the past 2 months.

It’s been a pretty brutal change internally, but it should be ready at the end of this year or early next year.


Unpoly - a framework like Turbolinks
#106

The Flutter team is working on this: https://medium.com/flutter-io/hummingbird-building-flutter-for-the-web-e687c2a023a8


#107

Better example from Java world is https://vaadin.com . It’s(was) based on GWT (google web toolkit) and development experience is amazing here. Worth to review.


#108

I came across a library called UmbrellaJs which is less than 3kb (as mentioned in its github repo), and is like a subset of jQuery. There is also a Migrating from jQuery guide at the github repo. I think migrating from jQuery to UmbrellaJs (for now) will be a lot easier and faster than Killing jQuery altogether.

UmbrellaJs Github Repo
UmbrellaJs Docs
Migrating to UmbrellaJs from jQuery


#109

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!)


#110

24 posts were split to a new topic: The Web and Required JavaScript


#113

That’s what I was hoping for too at first. Liveview could handle the fallback case seamlessly, which means that devs like you and me would write the code once, and the client would either take advantage of JS if available or do with traditional html functionality. I think OvermindDL1 wants just the same thing: with that, you code once in Elixir, and all the use cases just work, and your website can be made compliant with any weird accessibility law from country X that you never heard about with much less work.

Edit: oh well, the website updated the page with the info that the other posts were split into another topic yesterday, after I post that now…


#114

@chrismccord - do you have an ETA for a preview of LiveView?

I’ve asked a couple of times already, so I apologise for eagerness/redundancy, but it’d be really helpful for internal planning if we had at least a tentative timeframe to know when it might land.

Obviously, we’ll be grateful that it even lands at all, but fundamentally it may change our approach to a project if we’re targeting, say, React instead of LiveView in the meantime, vs. if we knew there was going to be a release in the next month or two. In the latter case, it might make sense for us to work on other parts of the project first and tackle UI last rather than rewrite down the line.

Thanks in advance!


#115

That’s exactly what I am doing since I have the luxury of a nice multi-month backlog of required backend/DB work to do in my context app anyway. LiveView as already demo’ed is a perfect match for my requirements and I’m sure it will save me months.

I have a feeling the initial version will be out before my backlog dries up given the latest blog post says “We’re close to an initial release” and he said the plan was to release a “v0.1” version then iterate rather than polish it perfectly first. I guess if it’s not out when my context app backlog dries up then it’s back to React.


#116

I think we might see it soon too. Chris has been pretty good on keeping to his estimates and even though he doesn’t give concrete dates (as missing them could cause issues for people), he does give you an idea, eg, “after Phoenix 1.4 is out” and “currently balancing the book and LV” etc

As @tme_317 mentioned, if you feel LV is going to be a good fit - why waste time on working on stuff with React that you may not end up using? So my vote is that I’d work on the other stuff for now too :003:


#117

Exactly the approach I’m taking at the moment. I’ve got a small prototype built out with Drab to check the premise works well for my use-case, but beyond that; I’m leaving anything frontend for the time being.

I prefer dividing my work in backend and frontend “sprints” anyway…


#118

I can completely appreciate not giving definitive dates. I’m very much of the ‘it’s done when it’s done’ brigade. If it hasn’t yet been released, I’m sure there’s a reason for it.

All I’m really holding out for at this stage is a rough-ish timeline. Like - are there a bunch of pretty massive features that still need implementing, or is it cosmetic stuff? Are there parts of Phoenix that a release is blocking on? Does Chris want to align LV’s release with, say, Phoenix 1.5? Having some idea would make planning commercial projects / selling it to other team members that much easier.

Of course, none of this is directly Chris’ concern, nor should third parties factor into/pressure a release timetable. It’d just be useful to know!

Hopefully doesn’t come to that. In my current project, LV all but eradicates client-side JS. With React being quite an opinionated view layer that tends to bundle both mark-up and business logic, refactoring to LV later would be tantamount to a rewrite in my case. So React isn’t really an ideal plan B this time around.

Instead of an SPA, I’ll prob stick with plain HTML and a thin JS layer on top. Hopefully that’ll be a bit easier to refactor for LV when it lands.


#119

Phoenix 1.4 is out :003:

He has not said so, in fact he’s said we’ll see LV after 1.4 so I would take that as not wanting to wait till 1.5.

This is why I reckon it won’t be too long before we see LV :023: (though this is just a guess like everyone else’s :lol:)


#120

Perhaps it has not been a concern since the mid-2000s for most front-end JS devs :wink:. For security-conscious individuals though, disabling JS and re-enabling only as needed is an easy way to prevent all kinds of undesirable garbage from executing on one’s computer. When a website depends on 30 different scripts, and I only need to enable 2 of them to get full functionality of the site, why waste my local machine’s resources to execute the other 28 scripts that are just there to track you and who knows what else?


#121

This was discussed at length in a JS thread that split from this one, and has since been deleted, so I won’t go into the technical counter points again for the sake of re-opening a can of worms.

But suffice to summarise that the vast majority (99%+) don’t share your browsing habits, so commercially designing for a ROI on the remaining fraction is often not worth doing.


#122

In terms of dev-hours I’d agree that for most web apps today it isn’t worth it to put much effort into design for users with JS disabled beyond some basic graceful degradation, especially for fancy stuff like graphs / charts. I think this is partly the fault of our tools though - one thing about LiveView that seems interesting is the potential to make it easier to fallback to server-side-rendering only.

I realize this probably is not a priority for the project especially in the beginning, but it’s certainly interesting to think about giving devs an easier fallback path without requiring a ton of extra work.


#123

I had an example of how a fallback might work in the deleted JS thread, but it got really messy, fast.

The problem is, there’s no real substitute for the JS API in the absence of JS. Let’s say an onClick handler is attached to a (non-submitted) button that should send a GraphQL request via a WebSocket, get some data, and update the local state which in turn refreshes the DOM without a full page reload. How do you simulate that in plain HTML? Form handlers won’t work - you’d need to explicitly submit a form by either hitting inside <input> tags, or click a button with type=submit. Even then, you’re limited to POST data, which would mean preserving some kind of state. This was the domain of ASP.NET view state, years back, and even that (IIRC) required some level of JS buy-in.

Unless you’re doing the absolute most basics - submitting forms, and clicking <a> links - there’s really no ‘graceful degradation’ these days for even rudimentary parity with basic app expectations.

JS is 99%+ supported, by default. No plugins, no workarounds - it works in 995 out of 1,000+ visits. For those other 5 out of 1,000 edge cases, you need to make a business decision as to a) why those users have JS disabled and b) whether there’s a ROI working around it.

I’d argue that for the majority of cases, in all but very few exceptions, a simple message asking users to enable JS would be sufficient.

As I said elsewhere, not once in the last 10 years of building anything for online (across many verticals, covering many demographies and geographies) have I ever encountered a scenario where it was necessary to design for a non-JS environment. This has nothing to do with designing Javascript properly, btw. There are plenty of examples of where it’s done badly. But done right - with good asset loading strategies, minification, and efficient code that won’t kill resource-constrained devices, there has been zero occasions where a customer/user has ever written in to complain that the site/app required JS support.

If there’s a need to consume parts of your site/app outside of JS, that’s what REST endpoints are for.

It’s just not a design consideration today. Back in 1998 when I started, absolutely it was a concern. Even in the mid-2000s, when JS support was patchy and non-standard, there was an argument for it. But in 2019, when virtually every mainstream web browser released in the last decade has it enabled by default? This is an old problem that really doesn’t warrant workarounds, for all but the slimmest of use-cases.

(Apologies @AstonJ if this risks repeating the previous JS thread… this is intended to conclude the point rather than branch off into a separate discussion!)