3 ms·

Github uses something called View Component to render 'partials' (aka components) which is a bit more sophisticated than just Turbolinks and IMO the future of c

by dmix 4y ago

Github uses something called View Component to render 'partials' (aka components) which is a bit more sophisticated than just Turbolinks and IMO the future of complex web apps https://viewcomponent.org/ https://viewcomponent.org/ It's the right balance in-between React/SSR hydration and Railsy server-side apps, taking the best of both worlds. This is a really good talk about how we got here from Jquery->Backbone.js->SPAs + React/Vue->Stimulus/ViewComponent/ActionCable https://www.youtube.com/watch?v=sIxvxp7E0xg https://www.youtube.com/watch?v=sIxvxp7E0xg There's another similar project called AnyCable which combines websockets with an ActionCable style approach: https://anycable.io/ https://anycable.io/

msbarnett 4y ago
Eh, we use ViewComponents inhouse at work too, and they're great, but they're really just a better way of approaching partials instead of the normal "grab the Controller's ivars" free-for-all -- they don't move the needle any on the MPA front, and they change nothing w.r.t turbolinks (or any client side JS), since they're purely a server-side rendering time thing.
- dmix 4y ago
  I'm more interested in the concept of ViewComponents than just the current library. It's really just starting with Rails adopting ActionCable and Phoenix using LiveView (which I see as both immature proto-concepts of the future of JS frontends). This blog post (and my linked talk above) opened my eyes on the subject: https://evilmartians.com/chronicles/anycable-actioncable-on-steroids https://evilmartians.com/chronicles/anycable-actioncable-on-... Right now the complexity is a bit high on this approach^ and I personally just use a mix of Vue + Turbolinks/Rails at work for legacy/simplicity reasons. But I'm watching the space.
eyelidlessness 4y ago
> It's the right balance in-between React/SSR hydration and Railsy server-side apps, taking the best of both worlds. This is similar to how React Server Components work, except that they work for arbitrary server-side rendering updates to the client as well as navigation. And it’s conceptually similar to how Qwik works, only the “partials” are typically client chunks. And again with Qwik, not tied to navigation, but that’s pretty much how I’d imagine a client routing solution for Qwik would (will?) look.

by dmix 4y ago

msbarnett 4y ago

Eh, we use ViewComponents inhouse at work too, and they're great, but they're really just a better way of approaching partials instead of the normal "grab the Controller's ivars" free-for-all -- they don't move the needle any on the MPA front, and they change nothing w.r.t turbolinks (or any client side JS), since they're purely a server-side rendering time thing.

dmix 4y ago
I'm more interested in the concept of ViewComponents than just the current library. It's really just starting with Rails adopting ActionCable and Phoenix using LiveView (which I see as both immature proto-concepts of the future of JS frontends). This blog post (and my linked talk above) opened my eyes on the subject: https://evilmartians.com/chronicles/anycable-actioncable-on-steroids https://evilmartians.com/chronicles/anycable-actioncable-on-... Right now the complexity is a bit high on this approach^ and I personally just use a mix of Vue + Turbolinks/Rails at work for legacy/simplicity reasons. But I'm watching the space.

eyelidlessness 4y ago

> It's the right balance in-between React/SSR hydration and Railsy server-side apps, taking the best of both worlds. This is similar to how React Server Components work, except that they work for arbitrary server-side rendering updates to the client as well as navigation. And it’s conceptually similar to how Qwik works, only the “partials” are typically client chunks. And again with Qwik, not tied to navigation, but that’s pretty much how I’d imagine a client routing solution for Qwik would (will?) look.