The code inside the blocks are uncacheable; it's an expensive novelty. Plus these abstractions always break down. Our job is to build products that meet people's needs. Not to contort solutions into our preferred form, at the expense of the product.
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 a happy user of Fortitude which is the real successor to Erector. I find it delightful to use over any of the other common templating languages like Erb or Slim, etc. I consider myself as having seen a large breadth of Rails apps over the years and can count on probably less than a hand how many times I needed caching. As a plus, it is the fastest rendering library available meaning you get a little perf for free everywhere (emphasis on small, and definitely not the reason I choose it). It may be a limitation, but Rails let's you use multiple templating libraries simultaneously so if some page is really that performance sensitive, nothing is stopping you from switching to a cacheable one. As always, right tool for the right job.
I'm honestly not so sure I'd accept it as the "fastest rendering library" for a variety of reasons:
- micro-benchmarks are really good at telling you the story you want to hear.
- profiling erector revealed that it placed a lot of pressure on the garbage collector. This was back when it too was the "fastest templating library." Micro-benchmarks won't really tell that story.
Other issues:
- blocks are a good abstraction until they aren't. No doubt backtraces are better than with erector. This was seriously traumatic to debug, templates were a gigantic ball of mud.
- "_I_ don't need caching" isn't a counter-argument. The reality of using blocks to nest elements is that the boundary between "cacheable, static content" and "dynamic stuff" is indistinguishable.
It's not like caching is turned off in erector (or fortitude). People were constantly making changes to templates, shipping them, and having changes not show up because memcache isn't running in development.
You COULD try to argue that it's the same problem in erb or slim, except it mostly isn't. When ALL your code is ruby code, seeing the "cache below this line" is a lot harder.
I knew I was asking for trouble mentioning the perf thing. Let me roll that whole argument back.
The reason I use Fortitude (and love it) is that writing loops and conditionals and extracting methods or variables is trivially simple, you get great IDE support. It's just Ruby. And it is remarkable easy to write, factor, reuse chunks of code, import modules, etc. You can do all these amazing code-like things because it's code. Not some weird DSL that requires an extra parsing step (both mentally and on the comp) or you have to remember to add the equals sign so that it prints etc etc etc.
I think it is incredibly relevant that I haven't used cacheing much, I lose that with Fortitude but I don't care 98% of my day. Maybe y'all work on ridiculously performance intensive codebases, but there are so many other things slowing you down like the DB, or I/O, etc. I'd happily prefer to tune my db, prune some n-queries, etc than go trying to get silly Rails template-cacheing right. It is so error prone it's ridiculous.
Use Fortitude for the perks, not the missing feature that is incredibly painful to get right.
The code inside the blocks are uncacheable; it's an expensive novelty. Plus these abstractions always break down. Our job is to build products that meet people's needs. Not to contort solutions into our preferred form, at the expense of the product.