I'm pretty sure that the examples with Ruby code embedded in the HTML document are primarily intended as examples rather than as a template for production deployment. They seem to use Reactrb Express (http://ruby-hyperloop.io/gems/reactrb-express/) to perform the Ruby->JavaScript compilation in the browser. For production use this would be done as a build step to produce a compiled JavaScript file that you can include in Rails' asset pipeline (for example - see http://ruby-hyperloop.io/tutorials/showcase/#step-3-webpack-...).
I don't necessarily disagree with your other points, but I think this looks like it's reasonably well put together. If it works well the ability to reuse Rails models on the client might be handy for example.
> Not to contort solutions into our preferred form, at the expense of the product.
A lot of this depends on your starting point (what you already know) and what you have to deliver with the resources you have available. Sometimes building and using abstractions that increase a team's leverage is the right approach for the product, even if it's a limited tactical step rather than a strategic direction.
I'm pretty sure that the examples with Ruby code embedded in the HTML document are primarily intended as examples rather than as a template for production deployment. They seem to use Reactrb Express (http://ruby-hyperloop.io/gems/reactrb-express/) to perform the Ruby->JavaScript compilation in the browser. For production use this would be done as a build step to produce a compiled JavaScript file that you can include in Rails' asset pipeline (for example - see http://ruby-hyperloop.io/tutorials/showcase/#step-3-webpack-...).
I don't necessarily disagree with your other points, but I think this looks like it's reasonably well put together. If it works well the ability to reuse Rails models on the client might be handy for example.
> Not to contort solutions into our preferred form, at the expense of the product.
A lot of this depends on your starting point (what you already know) and what you have to deliver with the resources you have available. Sometimes building and using abstractions that increase a team's leverage is the right approach for the product, even if it's a limited tactical step rather than a strategic direction.