|
I think his thesis is that Rails should help developers avoid those pitfalls. That's half the point of a framework (as opposed to a library): to show you how to structure your code better. That's actually a big part of the value of Rails: it picks one of the many ways to structure a web application (MVC with templates and an ORM), provides code to support that way, and (relevantly) sets conventions for code structure, directory layout (app/models/, lib/, etc). It could have left some of those as plugins - like how Sinatra provides only routing and templating, and if you want MVC or ORM, you have to add them. But by making them part of the framework, Rails declared "here is one good way to structure a web app". By pushing MVC, Rails helped developers avoid the pitfalls of one-page-PHP apps (mysite.com/index.php?page=news) - big entangled codebases with database access, HTML generation and business logic all intermixed. ActiveRecord helped developers avoid SQL injection attacks, repetitive query generation, and sprawling ORM config files. They made those problems trivial to avoid, and thus advanced the state of web development. The OP acknowledges those contributions of Rails and ActiveRecord, but argues it's time for them to advance again, as there are new problems they need to tackle. |