<story><title>Why I believe Rails is still relevant in 2019</title><url>https://devbrett.com/2019/03/why-i-believe-rails-is-still-relevant-in-2019.html</url></story><parent_chain><item><author>danmaz74</author><text>Having worked with many different languages and frameworks over the years, I have to disagree: when creating web applications, starting from scratch or from a minimal base is massively slower, more error prone and less safe than starting from a well developed and maintained framework, where so many of the things you&amp;#x27;re going to need have already been solved and battle tested.</text></item><item><author>mikekchar</author><text>I work on a Rails system.  It&amp;#x27;s fine.  Just like everything else is fine.  I have problems, but I have problems with everything else too (sometimes different problems, but not always...).&lt;p&gt;I think my main complaint about Rails is that it&amp;#x27;s pretty heavy weight.  Lately we did a Sinatra app because we didn&amp;#x27;t really need anything that rails was giving us.  Fairly quickly I realised that I didn&amp;#x27;t need anything that Sinatra was giving us either.  Rack was fine.&lt;p&gt;I think especially after your app gets to be a certain size, you are either writing your own framework, or fighting with the framework you chose at the beginning.  It&amp;#x27;s just the nature of the beast.  From there it&amp;#x27;s more of a training issue than anything else.  You can hire &amp;quot;Rails developers&amp;quot; (or whatever developers), but you can&amp;#x27;t hire people who are specifically trained in a system you&amp;#x27;ve built.  Depending on the kinds of developers you hire, this may or may not be a problem.&lt;p&gt;Personally, I like writing code and I like small, light systems that are easy to move around in.  Usually that means trying to avoid large frameworks.  However, not everybody I&amp;#x27;ve worked with is comfortable with that experience, so normally we pick things people have worked with before.  Either way it&amp;#x27;s not a big deal in the end.</text></item></parent_chain><comment><author>lmm</author><text>A summary of my experience would be: libraries are good, frameworks are bad. (Indeed possibly the best &amp;quot;framework&amp;quot; I ever used was TurboGears which is very deliberately just a collection of dedicated libraries, all of which you can replace piecemeal as and when you need to).&lt;p&gt;Rails raised the bar for how little custom configuration should be necessary to do a simple, straightforward thing. But it turns out being a framework is not integral to that; modern libraries have been able to adopt the &amp;quot;opinionated&amp;quot; (which seems to be just a fancy term for having sensible defaults) approach of rails without having to grow into all-encompassing frameworks.</text></comment>
<story><title>Why I believe Rails is still relevant in 2019</title><url>https://devbrett.com/2019/03/why-i-believe-rails-is-still-relevant-in-2019.html</url></story><parent_chain><item><author>danmaz74</author><text>Having worked with many different languages and frameworks over the years, I have to disagree: when creating web applications, starting from scratch or from a minimal base is massively slower, more error prone and less safe than starting from a well developed and maintained framework, where so many of the things you&amp;#x27;re going to need have already been solved and battle tested.</text></item><item><author>mikekchar</author><text>I work on a Rails system.  It&amp;#x27;s fine.  Just like everything else is fine.  I have problems, but I have problems with everything else too (sometimes different problems, but not always...).&lt;p&gt;I think my main complaint about Rails is that it&amp;#x27;s pretty heavy weight.  Lately we did a Sinatra app because we didn&amp;#x27;t really need anything that rails was giving us.  Fairly quickly I realised that I didn&amp;#x27;t need anything that Sinatra was giving us either.  Rack was fine.&lt;p&gt;I think especially after your app gets to be a certain size, you are either writing your own framework, or fighting with the framework you chose at the beginning.  It&amp;#x27;s just the nature of the beast.  From there it&amp;#x27;s more of a training issue than anything else.  You can hire &amp;quot;Rails developers&amp;quot; (or whatever developers), but you can&amp;#x27;t hire people who are specifically trained in a system you&amp;#x27;ve built.  Depending on the kinds of developers you hire, this may or may not be a problem.&lt;p&gt;Personally, I like writing code and I like small, light systems that are easy to move around in.  Usually that means trying to avoid large frameworks.  However, not everybody I&amp;#x27;ve worked with is comfortable with that experience, so normally we pick things people have worked with before.  Either way it&amp;#x27;s not a big deal in the end.</text></item></parent_chain><comment><author>smt88</author><text>&amp;gt; &lt;i&gt;starting from scratch or from a minimal base is massively slower&lt;/i&gt;&lt;p&gt;This isn&amp;#x27;t the better alternative to frameworks.&lt;p&gt;The better alternative is using libraries and optionally a bootstrap code generator, which is not at all &amp;quot;starting from scratch&amp;quot;.&lt;p&gt;The major difference is that you tell the libraries how to work together, rather than the framework telling you how to work.&lt;p&gt;Some frameworks become like a terrible DSL that you could never translate back into idiomatic code.</text></comment>