I felt like I entered some time wrap, was this written in 2007/2008? Can't believe someone writing this in 2013 since so much of the arguments are from those days. That rails shops with more than 9 months of development are festering piles of magic code is not news. Let's take a step back and ask why would anyone write a new Rails app in 2013. When rails came out in 2003/4 (yes it is now a decade) it was really neat. However things have changed dramatically as far as client/server capabilities are concerned and it is wise to revisit assumptions. Key points
1. Javascript is now anywhere from 20 to 50 times faster than it was in 2003.
2. Javascript is supremely better than ruby in building UI and DOM manipulation. It is even faster in doing straight computations.
3. Clients are now 10 times more powerful (approx. memory/cpu-core wise) and even mobile phones have more memory/capability than a desktop computer of 2003.
4. Rails remains the slowest and least efficient server side language by a huge margin.
5. Mobile/Tablets have their own UI/View concepts and work best with a server API that just serves json type data.
So why would you bottleneck your application through a rails server. Best to have your server be a provider of services (security, data store, integration with backend etc). Most computation and UI manipulation is probably better done in javascript. What is that rails provides that say PHP cannot provide in this new way of doing things. It feels like with, say, AngularJS + server API (not doing everything) we are much better served by having computation distributed in the right way.
> Rails remains the slowest and least efficient server side language by a huge margin.
Rails is a framework, not a language, and its not clear whether this "slowest server side <foo>" is really directed at Rails (the framework), Ruby (the language), MRI (the main implementation of the language), or some combination of framework, language, and implementation.
Yes, I should have said framework instead of language. However, MRI also happens to be one of the slowest languages. What are proposing as a good combination that people are using?
There is also Rubinius, and JRuby. Not to mention a few versions of threaded servers for each. Rubinius + Puma shows huge potential, I am running very large Rails app on a DigitalOcean 512MB ram droplet using it, and not using more than 30% memory.
The problem with your comment is while Javascript has improved and while Rails is still relatively slow, both Rails, Ruby implementations, AND server speed in general has gotten faster AND cheaper.
Not to mention the absolute ease of setting up russian-doll caching throughout with (distributed) memcached, and potential further speedups for all the interpreters (and the upcoming Topaz) and I'd say you presented a very one sided response.
Why the proliferation of server side environment like: Node.js, ASP.NET (C#), Java, ColdFusion, PHP, Ruby, etc.? I've found nothing so complicated about old languages (C++, etc.) that could not of had a web library added around them to do the exact same thing. Is SSL, cookies, and the HTTP protocol that complicated to warrant all of this?
Was it because of shared hosting (and thus running your own custom executable) that gave rise to all this? The products I'm wanting to make for the web can't use PHP, Ruby type environments. I'm looking at Node.js or a C++ version of the same.
We'll most likely output JSON and have JavaScript assemble the GUI on the client side thus making what these frameworks do nothing but the most basic of tasks.
Well -- first thing is lets decouple your premise. You imply that all the technology you listed was designed with server side in mind. It wasn't: C#, Ruby and Java are general purpose languages not targeted at the server explicitly.
Second, if you don't think C++ gets complex (and has entirely different working models based on who is writing it) -- I recommend you use it more. C++ is a damn complex, deep, feature packed language. C++ server side frameworks exist (and are the fastest thing around: http://www.techempower.com/benchmarks/) but they take massive amounts of effort versus some of the newer languages.
PHP took off because of shared hosting, wordpress and pragmatism. People who were inexperienced could (1) get access to it, (2) deploy it and (3) get things done.
ASP.net survives (most would argue it didn't really take off) because if you live in the MS toolchain, it is a very nice experience.
I'm not sure about ASP.NET - projects I've worked with are utterly over-engineered with so many interfaces, services, factories, and service factories, that it's impossible to figure out where the code is that actually does anything, even in VS2012.
That played a huge part in things, yes. PHP and ASP gained a huge part of their popularity because they were designed to fit into existing shared hosting setups, so everyone could rely on them being available anywhere and everywhere. Hence mod_perl, mod_ruby, mod_python, etc. to try to get those languages into the same space. Now that virtual machines are the norm it is a lot easier to use whatever you want.
"this pragmatism produces elegant solutions"
I disagree. I think the pragmatism encourages one to "be clever" and just "get it done". Often this is not elegant.
In my experience, most clients we worked with did not request Rails, it was foisted upon by developers who say the five minute blog video, tried to model the business problem, failed, left for shiny new gig, the client is left vulnerable to the many, many security issues, and a code base that brings tears to the eye of even a hardened developer.
The worst development gig out there? Walking into a Rails code base more than six months old. You are probably the third person to attempt taming the stink feet of magic magic code and thousands of useless unit tests and cucumber drivel that looks fab in a pretty graph but tests almost none of the core important business logic nor really helps anyone understand what was actually requested.
IMHO, the pain of being handed code is related to its "magic". The more magic, clever, interesting contortions that are present, the less likely you are to get grips on it in any sensible time. Ruby & Rails give lots of tools to create insanely hard to unwind stacks, but I am not sure they are worse than Django & Python (custom loader [importer], decorators everywhere)...
The real bitter pill is that these systems are created with the best of intentions, to make them more maintainable, more DRY, more configurable, more portable... but they generally miss the mark and cause pain for all involved.
I guess that might be true of any inherited codebase in any language - i shudder to think of encountering something written in PERL from an other developer and having to maintain that code.
It amazes me that so many people cite the blub essay while behaving exactly as the essay describes a blub programmer. Ruby is not near the top of the spectrum, you aren't even aware of the languages that are at the top of the spectrum.
1. Javascript is now anywhere from 20 to 50 times faster than it was in 2003.
2. Javascript is supremely better than ruby in building UI and DOM manipulation. It is even faster in doing straight computations.
3. Clients are now 10 times more powerful (approx. memory/cpu-core wise) and even mobile phones have more memory/capability than a desktop computer of 2003.
4. Rails remains the slowest and least efficient server side language by a huge margin.
5. Mobile/Tablets have their own UI/View concepts and work best with a server API that just serves json type data.
So why would you bottleneck your application through a rails server. Best to have your server be a provider of services (security, data store, integration with backend etc). Most computation and UI manipulation is probably better done in javascript. What is that rails provides that say PHP cannot provide in this new way of doing things. It feels like with, say, AngularJS + server API (not doing everything) we are much better served by having computation distributed in the right way.