I'm not knee-deep in this specific issue with the binstubs, but I generally agree about the legitimate grievances. The Merb effort and the Rails 3.0 refactor resulted from people unable to voice what they need. We seem to keep repeating history.
Asset Pipeline is also the wrong area of innovation to focus on. Rails should be baking in support for creating API only apps, make it easy to shed template-driven code and write UX-agnostic backends. Mobile is driving a need for creating API-only apps, and something like Asset Pipeline is an evolutionary dead-end. There are more smartphone-like devices in the world than personal computers; there are kids growing up with a smartphone as their first computing device; people of our generation have a bias towards thinking of UX and web-apps as desktop-first; when the tooling around API-only Rails apps mature, then template-driven apps will start dying into irrelevance.
But, I'm done with it. I'm looking at the next wave of leading edge of innovations for the masses, and it won't be in apps.
> Rails should be baking in support for creating API only apps, make it easy to shed template-driven code and write UX-agnostic backends. Mobile is driving a need for creating API-only apps, and something like Asset Pipeline is an evolutionary dead-end.
This has never been Rails' focus. Let Rails keep doing what it kicks ass at. Sinatra works great for API endpoints. There's probably an opportunity for an API-focused extension to Sinatra. Of course, Grape works too (https://github.com/intridea/grape).
The nice thing is that all of these are built on Rack now. GitHub.com runs as a Unicorn rack app that mounts over 30 Sinatra apps and a massive Rails app together. I'm not saying this is an optimal solution, it's just where the app is at in its current evolution. But it is very possible :)
I've taken a look at it. It does not really use the Rails 3 architecture (Russian Doll Pattern) to its fullest potential. I have written https://github.com/intermodal/intermodal back in 2010 to demonstrate it, and have put that code into production.
Maybe they will, maybe they won't. I got a polite brush-off so I doubt they really looked at it, but since I am exiting, whatever.
In writing Intermodal, I've had to muck around with some of the guts of Rails. I've found that Rails 3.0 very much follows the principle of Russian Doll Pattern, but Rails 3.1 onwards started moving away from it. There are baked-in assumptions in the code for a template-driven app. This is where the Rails leadership is focused on.
Sinatra is not actually all that good for writing API endpoints.
The Rails 3 architecture is very modular. It was designed as framework to write frameworks, of which a template-driven app is one such framework. I have written a different framework specifically for just an app focused on SASS that has an abundance of CRUD operations.
However, when Rails 3.1 started transitioning into Rails 3.2, the assumption that Rails is specific for a template-driven app started being baked deeper into it. It was moving away from the "Russian Doll Pattern" that was so useful for me.
>> Rails should be baking in support for creating API only apps
Right now, I can create a rails app that doesn't use templates at all. I can start with a basic rails 4 install and quickly prototype an API that communicates through JSON or any other format I can think of. I can leverage handlebars and ember.js if I want to go that route, or I can stick with dumb old 'templates' to display my data. When you start coding ruby on rails you quickly realize that 'template' is just a word and that you are free to do literally anything you can think of, easily.
>> people of our generation have a bias towards thinking of UX and web-apps as desktop-first
Let us assume this is absolutely true. Why does rails keep you from writing code that honors this bias? Rails gives you abstractions you can use to decouple. If I want local data persistence perhaps I'll need support from other libraries--but only if I'm too shy to take a shot at writing a tool myself.
I think you're on to something with the 'desktop-first' remark. We do need to be able to store data browser-side. We do need to address performance issues--especially as it relates to decoupling server-side data logic and application data logic. Rails is a very good tool for supporting solutions to these types of problems and packaging them in easy to implement applications.
>> But, I'm done with it. I'm looking at the next wave of leading edge of innovations for the masses..........
Obviously rails is useless if you don't want to make applications, but otherwise you can really do anything and it's not actually hard to configure rails.
I used to think that david hh and many other experts in the community were mean. Then I realized they have to deal with people all the time; not the 'grievances', but the attitudes. There are many trolls and one cannot be too careful.
If you're going to do API only apps then there are much better alternatives than Rails. Rails is heavy. It's like using a cruise ship to navigate a small creek.
Not so much recode by hand as actively choose components that provide the functionality. Sure, you might have to recode a bit of the between-components wiring if the separate components you choose don't natively support each other, but its hardly as if you'll generally have to recode the major components themselves.
Sure, Sinatra doesn't come with ActiveRecord like Rails does, but you can use ActiveRecord on its own with Sinatra -- or use Sequel or DataMapper or whatever other ORM [or non-ORM persistence solution] you prefer -- with Sinatra, you don't have to code your own by hand. Similarly with other components.
Sure. If you're building a traditional web app. The sort of web app Rails is good at. But if you are constructing an api, you can use ligher and alternate technologies that will get the job done faster and better.
Like what? Rails is great for APIs, because APIs, especially RESTful and Hypermedia APIs, can literally be a standard webapp with JSON views instead of HTML.
I've never built a SOAP API in Ruby, so maybe Rails wouldn't work with that very well. XML-RPC might also be a little tough, but I honestly can't think of any significant difference between a "traditional web app" and a RESTful API. They're a perfect example of code reuse in MVC (or Model2 if you want to be pedantic).
People keep repeating that like it's some commercial gimmick, but what does it really mean? How is Rails or rails-api not suited for APIs? What's lightweight? What's easy?
And more particularly since you seem to know about this, what other option would you favor?
Well Sinatra seems pretty nice. I'm a node.js developer so I use Restify and Express. But I practically build api's exclusively. I've spent a lot of time cleaning up after terrible Rails applications. Replacing bits that are too slow or difficult to maintain with smaller more nimble node applications.
It means he's a node troll. They take a shot at the dominant frameworks any chance they can get. Node trolls have reached the level of obnoxious arrogance that early Rails developers were once mocked for. Don't feed the trolls.
It's about using the right tool for the job. Most developers never seem to understand that. Everyone seems to want the same magic bullet for everything.
Asset Pipeline is also the wrong area of innovation to focus on. Rails should be baking in support for creating API only apps, make it easy to shed template-driven code and write UX-agnostic backends. Mobile is driving a need for creating API-only apps, and something like Asset Pipeline is an evolutionary dead-end. There are more smartphone-like devices in the world than personal computers; there are kids growing up with a smartphone as their first computing device; people of our generation have a bias towards thinking of UX and web-apps as desktop-first; when the tooling around API-only Rails apps mature, then template-driven apps will start dying into irrelevance.
But, I'm done with it. I'm looking at the next wave of leading edge of innovations for the masses, and it won't be in apps.