4 ms·

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

by gonyea 10y ago

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.

gleenn 10y ago
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.

by gonyea 10y ago

gleenn 10y ago

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.