4 ms·

That's actually a relatively nice, Rails-magic-style approach to solving this sort of thing. Of course, if you were building a more interactive application, you

That's actually a relatively nice, Rails-magic-style approach to solving this sort of thing. Of course, if you were building a more interactive application, you'd already have a JS framework in place that would negate these benefits – but I'm still convinced there's a nice middle-ground for server-rendered Rails apps that avoids the various problems of SPAs. It would be nice if it worked without JavaScript though – an increasing pain-in-the-arse about the web generally. If only it were possible to have <iframe>s adjust to their content size, then we wouldn't need JavaScript at all!

marsRoverDev 9y ago
At the very least, it's a very nice stopgap until a full JS frontend is in place. I intend on throwing this into my existing rails app for various optimisations while it awaits an SPA frontend.
tbranyen 9y ago
How would an iframe help avoid needing JS?
- matthewmacleod 9y ago
  Well in this case, it feels like you could easily substitute out the AJAX request with an inline iframe that would embed the asynchronous content into the page. That's not possible, unless you have fixed-size elements or Javascript, since you won't be able to have the frame adapt to the size of its content. It's definitely useful in some cases though – I know that various social plugins used to work like this (I don't know if they do any more!)
realusername 9y ago
I'm also using react-rails on my case to make a bridge between rails and react and it has been very useful so far, you can even render components server-side to test them with rspec.
kawsper 9y ago
I was the original author of this gem, so it is nice to see it here on HN, I have since passed it on the the caring hands of Semaphore since they wanted to maintain and improve it :-) The software was built for a forum where the admin buttons was only for specific users, but the rest of the frontend was the same, so we used render_async to render some content for some users, and other content for admins, and the rest of the page could be cached statically. We later changed it to use edge side includes with Varnish. An example of this is where you add the to your HTML: <esi:include src="http://example.com/1.html" alt="http://bak.example.com/2.html" onerror="continue"/> This will make Varnish fetch the URL(s), assemble the page and present it to the client, so your backend might see more requests, but the client only sees one.
- ksec 9y ago
  So you are suggesting using a front end cache server like Varnish is better then what you originally programmed for?
  - kawsper 9y ago
    It depends - Varnish is great, but in case of error-handling I think it is better to handle that with JavaScript, so you can retry, and you avoid that a timeout or slowdown doesn't block your clients. On the other hand, I really like to just throw HTML at the user without involving asynchronous JavaScript.
- gingerlime 9y ago
  It's an interesting approach. It's only async from the client perspective though. Right? The server still processes the action/render inline? (i.e. it's not spawning a sidekiq process as far as I can tell). We recently implemented something that's async on the server, using a combination of pusher and sidekiq. This was particularly useful for cases where we access an external API and don't want to hold the unicorn process for too long. So when the response comes back we push it back to the client and display it. Would be interesting to maybe combine this approach with some server-push and background workers and what this gem is doing.
matt4077 9y ago
I don't quite get the reference to "magic"... It's quite easy to get what this does, and surely not every function call can be considered "magic"?
- matthewmacleod 9y ago
  You're right, of course – I would consider this 'Rails magic' because it fits the general pattern of all those cool UJS helpers that are available. Things like `form_for(remote: true)` or `link_to remote: true`. This is just an extension of the same principle, which I think of as being basically magic!
  - tomphoolery 9y ago
    I kinda wish it worked more like UJS though, rather than rendering a partial with <script> tags it could be just rendering some arbitrary <div> tag that, when it exists on the page, fires an event for rendering a partial asynchronously on the page. the UJS helpers for doing this already exist, because `link_to remote: true` is a thing. instead of making the GET request when the link is clicked, we're just triggering the link to be clicked right there in the page.
tomphoolery 9y ago
just use regular <frame>s and <frameset> ;-)

marsRoverDev 9y ago

At the very least, it's a very nice stopgap until a full JS frontend is in place. I intend on throwing this into my existing rails app for various optimisations while it awaits an SPA frontend.

tbranyen 9y ago

How would an iframe help avoid needing JS?

matthewmacleod 9y ago
Well in this case, it feels like you could easily substitute out the AJAX request with an inline iframe that would embed the asynchronous content into the page. That's not possible, unless you have fixed-size elements or Javascript, since you won't be able to have the frame adapt to the size of its content. It's definitely useful in some cases though – I know that various social plugins used to work like this (I don't know if they do any more!)

realusername 9y ago

I'm also using react-rails on my case to make a bridge between rails and react and it has been very useful so far, you can even render components server-side to test them with rspec.

kawsper 9y ago

I was the original author of this gem, so it is nice to see it here on HN, I have since passed it on the the caring hands of Semaphore since they wanted to maintain and improve it :-) The software was built for a forum where the admin buttons was only for specific users, but the rest of the frontend was the same, so we used render_async to render some content for some users, and other content for admins, and the rest of the page could be cached statically. We later changed it to use edge side includes with Varnish. An example of this is where you add the to your HTML: <esi:include src="http://example.com/1.html" alt="http://bak.example.com/2.html" onerror="continue"/> This will make Varnish fetch the URL(s), assemble the page and present it to the client, so your backend might see more requests, but the client only sees one.

ksec 9y ago
So you are suggesting using a front end cache server like Varnish is better then what you originally programmed for?
- kawsper 9y ago
  It depends - Varnish is great, but in case of error-handling I think it is better to handle that with JavaScript, so you can retry, and you avoid that a timeout or slowdown doesn't block your clients. On the other hand, I really like to just throw HTML at the user without involving asynchronous JavaScript.
gingerlime 9y ago
It's an interesting approach. It's only async from the client perspective though. Right? The server still processes the action/render inline? (i.e. it's not spawning a sidekiq process as far as I can tell). We recently implemented something that's async on the server, using a combination of pusher and sidekiq. This was particularly useful for cases where we access an external API and don't want to hold the unicorn process for too long. So when the response comes back we push it back to the client and display it. Would be interesting to maybe combine this approach with some server-push and background workers and what this gem is doing.

matt4077 9y ago

I don't quite get the reference to "magic"... It's quite easy to get what this does, and surely not every function call can be considered "magic"?

matthewmacleod 9y ago
You're right, of course – I would consider this 'Rails magic' because it fits the general pattern of all those cool UJS helpers that are available. Things like `form_for(remote: true)` or `link_to remote: true`. This is just an extension of the same principle, which I think of as being basically magic!
- tomphoolery 9y ago
  I kinda wish it worked more like UJS though, rather than rendering a partial with <script> tags it could be just rendering some arbitrary <div> tag that, when it exists on the page, fires an event for rendering a partial asynchronously on the page. the UJS helpers for doing this already exist, because `link_to remote: true` is a thing. instead of making the GET request when the link is clicked, we're just triggering the link to be clicked right there in the page.

tomphoolery 9y ago

just use regular <frame>s and <frameset> ;-)