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?
DevotionGeo
triskweline
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.
marciol
The Flutter team is working on this: https://medium.com/flutter-io/hummingbird-building-flutter-for-the-web-e687c2a023a8
dmarko484
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.
DevotionGeo
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
lee
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
windowobject on the server-side usually requires that the packages themselves have defensivetypeofchecks (which rarely is the case.). NPM packages just aren’t often built with isomorphism in mind. In ReactQL, I approach this by having aSERVERconstant 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: truewith 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!)
19
Cochonours
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…
lee
@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!
tme_317
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.
AstonJ
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 