Most of the 'mess' I see is the current state of Javascript frameworks, which are in the Cambrian explosion phase of things.
I'd just use Rails as a default for most things I do these days, and if it's not a good fit, evaluate other technology.
I'd just use Rails as a default for most things I do these days, and if it's not a good fit, evaluate other technology.
There are good reasons to get the HTML formatting off the server and into the client, so the new style JS is all going in the right direction. So another metaphor:
All these frameworks are trying to solve the right problem in the right direction - which one will win out eventually - who knows, but even if you hitch a ride on one that stops half way, you are half way closer to the right destination than if you wait.
It alos makes my server software conceptually simpler - which is always nice
This has gigantic performance increases for servers under heavy load, and it puts the display logic in a domain that is more naturally suited to dealing with it (JavaScript and the DOM instead of treating HTML as just a string).
The pattern also promotes the use of RESTful APIs for data access from the server, which has the wonderful bonus of allowing you to make your data publicly accessible for free if you want to.
My client side user should know nothing about Dbase lookups or persona verification - just as server model should not care about displaying addresses. Overall I think getting the crap out of the server makes it much much easier to reason and architect
But ZOMG RAILS IS INSECURE, quick, switch to something else! [/sarcasm]. Evaluating other technology is the opening of the rabbithole.
Slowly but surely Rails will become robust because of this.