Yep!<p>Nothing wrong with yesterday&#x27;s technology if you&#x27;re solving yesterday&#x27;s problems!  I don&#x27;t mean that in a sarcastic or glib way, most of your problems really are yesterday&#x27;s problems.  Or even yesteryear&#x27;s problems…. now that I think of it, when I depart from rails in a rails project (which is common), it&#x27;s usually to use raw sql, unix, various networking protocols, or other programming languages that predate rails and ruby.<p>There was a good book out recently from pragmatic bookshelf called &quot;rails angular postgres and bootstrap&quot;.  Not saying you should necessarily use this stack (I don&#x27;t), but the idea that you don&#x27;t need to do everything in rails to use rails is worth listening to.<p>Generally, you&#x27;re going to want to go back in time, to use tools that were designed for even older problems.  For instance, why reinvent sql in a new language?  If it&#x27;s convenient to use active record and there&#x27;s no performance hit, ok, use it, but don&#x27;t go into contortions to avoid sql.<p>On a similar note, for those parts of a project where you really should go forward in time and start using tools that haven&#x27;t withstood the test of time, by all means, go for it.  But you aren&#x27;t obligated to write the other 95% of the project in some new framework.