What the hell is happening to rails?
blog.stevecoast.com
blog.stevecoast.com
This is nothing new. He's been doing this every 6 to 12 months since Rails 0.13 (at least). Here are some of the bigger disruptions:
- Rails 1.2: Rewrite all your controllers to use the new REST model. (This was annoying, but the results looked a lot better.)
- Rails 2.0: Change from ";" to "/" in standard resource routes, and rewrite controllers to use respond_to.
- Rails 3.0: Deal with bundler, ActiveModel, Arel, a total overhaul of ActionMailer, etc., etc.
By historical standards, the asset pipeline is a medium-sized change, and certainly much smaller than the Rails 3.0 changes. And unlike the Rails 3.0 changes, you can turn it off in about 2 minutes.
Personally, I rather liked most of these new features at the time: They addressed my day-to-day pain, they made my code cleaner, and they helped me keep in sync with other programmers. Rails is optimized for a certain set of opinions, which overlap about 80% with my own, and that's usually good enough for me. If your tastes diverge from DHH's tastes to a greater extent, it won't be as much fun.
The point? If you want stagnant frameworks there's plenty to pick. A lot of them aren't easier to learn, but none of them require you to keep learning. This is great because it tends to attract all the programmers you want to avoid into obvious communities.
I skipped the Rails 3 upgrade just simply because I couldn't justify the time sink. rspec made it ridiculously worse with the difference in Rails support between 1.x and 2.x. I'm guessing with Rails 3.1 coming out I'll have to upgrade just because most of the plugins I use have moved on and don't backport bugfixes.
It'd be nice to evolve an app without having to constantly wasting time on version compatibility. It's an absolute nightmare if you have any non-trivial-sized app.
Also there are a lot of deprecated things that must have been removed in 3.1 ― TBH I haven't kept in touch with 3.1 development but I'm sure a lot more has happened besides the default switch and Asset Pipeline. :)
Basically in the end, Rails is a curated framework. It either fits your requirements or it doesn't. There is no need for it to work for "all possible" cases.
Also like I said you don't have to use the defaults. :)
"Opinionated" was the original description. "Curated" is just some buzzword that means "people look after it" rather than "automatically generated", which is, uh, pretty much going to be par for the course for a maintained framework.
"Opinionated" communicates the idea so much better - it means not only that yes, some choices were made, but that some of them are the result of strong opinions, and do not necessarily try and accommodate all points of view.
Very true. Frameworks should strive for a solid API that makes it easy for people to write add-ons, and avoid adding anything that is not essential.
Of course, one hacker's essential is another's bloat, but developers should give things a long hard look before adding stuff.
It's the reason I like Ramaze so much. Has what's needed, gets out of your way, it's easy to evolve or extend if you know Ruby, and it respects your opinions.
This is where you lost me. I spent about 2 hours, aggregate, spent solving upgrade-related problems across a bunch of different apps.
Where is the time sink?
There are entire sites like http://railsplugins.org/ to help you figure out if your plugins are Rails 3 compatible. Unfortunately, there simply aren't enough users to crowdsource the compatibility of all the plugins out there.
But, if you think backward compatibility is vastly overrated, there's really no seeing eye-to-eye on this.
If you knew C really well, and someone said "Hey, you can be more efficient building a website in C#/ASP.NET", would you have that hard a time believing them?
I wouldn't. But if they said that I could write systems code better with Objective-C I'd say prove it.
Unfortunately whenever I see RoR people talk about ROR vs anything else, including ASP.NET MVC, they talk in broad strokes with statements like, "Obviously dynamic languages are far more productive than static ones." Or "People who program in Ruby are much better developers -- which is obvious to prove, because they program in Ruby."
I'm a former ASP.NET MVP, a codebetter.com blogger, I wrote Foundations of Programming, I own a handful of .NET OSS libraries. Yada, yada, yada..
All of that is pretty meaningless, I'm not saying to show off (most of that stuff isn't show off worthy). However, by all accounts, I'm an expert C#/.NET programmer who's been in the thick of of any progressive .NET movement. I know C# and ASP.NET (MVP or WebForms) much, much better than I know Ruby and Rails. Yet, somehow, I'm still more efficient in RoR (and thats only getting more true). I can get as low level about this discussion as you want, it won't change my opinion.
The two big wins for me: I write a ton less code and code is easier to test (this is largely since IoC is a language feature).
I know C# and ASP.NET (MVP or WebForms) much, much better than I know Ruby and Rails.
The norm in the community is to actively refactor.
That's it. When the Rails folks redesign the routes system, not only does my app get cleaner, but I learn stuff about how to write a good DSL. When Blake Mizerany wrote Sinatra, not only did we all get a super simple new tool for prototyping web apps in, like, zero seconds.... but we all learned something about how far you can take the "hello world" simplification trend.
We're all trying to get better at programming. We're all trying to advance the state of the art in software design. And we're all learning from each other, and it's awesome.
In many ways it's just a microcosm of what's happening in the Open Source world at large. Node.js is teaching Ruby devs important stuff, just as the Node authors seem like they probably took a cue or two from Sinatra. It's why I left the Microsoft world years ago.
Loose federations of heterogenous interests with high incentives to integrate are so much more interesting than centralized organizations.
When the rails folk redesign the route system it's not a refactoring cause a refactoring keeps functionalities unchanged, it does not add/remove/change corner cases. Which has happened in all major rails releases and some point ones.
"Refactoring" as a term was defined in that book. It has very much been diluted into "I changed some code because I think this is better," which is a shame because it has a very clear definition.
I should also note that having a test suite allows you to refactor with more confidence, but it's neither a requirement nor changes the definition at all. So a "TDD-assisted refactoring" isn't different from a "refactoring."
There's a difference between stagnant and growing in the right direction. I think the author believes that RoR is moving away from what many thought was one of its core pillars: The ability to go from nothing to an up and running web app quickly.
Lots of things aren't stagnant -- few things move in the right direction. I'm not saying that RoR isn't moving in the right direction, but I think you've created a strawman of sorts.
IMO, as long as Rails is being driven by real application development, I'm happy. Compared to "enterprise" frameworks which are built in isolation from the real world, Rails movement seems more grounded in pragmatism.
How in the world do the changes lead to a situation where you can't get an app up and running quickly? I don't see that at all.
There are other points where the article is plain wrong to. "It used to be that you just used Prototype, now it goes to vast efforts to be agnostic." No, it switched the default to JQuery, thank god.
I came from PHP and did a lot of work with CakePHP and some with Zend Framework. I found CakePHP fun to work with but often limiting. I found ZF unpleasant to work with and often just as limiting because the effort involved in doing certain simple tasks was often too much.
With Rails I was able to crank out some basic functionality quite quickly and the only hang up I've come across is learning how to create plugins. Then again, the plugins I need are often out there in the world and I could probably get away with never having to write one.
I still think Rails is incredibly easy to learn the basics of but it also is well developed and thought out leaving plenty of room for more advanced behavior without running into the same walls I feel I ran into with PHP development.
Since I started with Rails 3, I don't have any perspective on how difficult it is to keep up with the changes but I must say I'm excited about 3.1 and I don't mind having to dig into whatever information I can scrounge up to familiarize myself with it.
So basically you agree with point that Rails' rapid changes are making it less approachable, but see it as a good point?
Worst. Advice. Ever.
Once you’ve figured that all out then upgrade and expect to spend the same amount of time learning all the new stuff. You don’t save any time jumping to Rails 3+.
This just isn't true.
As a front-end developer with little back-end experience, I was able to get the basics of Rails with just a few hours working through Hartl's tutorial.
I strongly urge the author to change this suggestions because it's a dangerous one. You don't want newcomers learning an older version of Rails and then struggling to upgrade.
There are a lot of resources to help you out. The API Docs[1], Official Rails Guides[2] are excellent and Railscasts[3] are also awesome.
[1] Rails API Docs http://api.rubyonrails.org [2] Rails Guides http://guides.rubyonrails.org [3] Railscasts http://railscasts.com
Rails has been improving over the years, and I think excellent design decisions have been made. I do not think it is the fault of rails that the author feels that rails is less approachable.
You mean:
Rails for Zombies (http://railsforzombies.org/) Michael Hartl's screencasts/tutorial (http://ruby.railstutorial.org/) Stack Overflow (not a blog, but a really good resource).
I think the number of blogs doing Rails 101 type posts has changed, because there are existing resources that do a great job, and developers/bloggers recognise that.
Of the top rails documentation resources:
* Rails Guides are still out of date and incomplete for 3.x series. I often have to go to the API docs since some big topics just aren't covered in any level of detail.
* Railscasts deals exclusively with deltas-- new features, new techniques, etc, and no longer has a nice pedagogical sequence. The original tutorials are just plain out of date. (Maybe the peepcode tutorials are more up-to-date and comprehensive?)
* Google. The biggest of all. Rails pace of change and its agnosticism means that the corpus of blog posts with recommendations, bugfixes, tips, tweaks, tutorials, etc, become out of date quickly, and more importantly it's extremely hard to tell what version of rails or of a plugin a given post or thread is referring to.
A secondary issue: Rails newfound agnosticism (compared to its previous "opinionated" nature), along with the culture of the "flavor of the week" creates problems in the development and documentation ecosystem:
* The plugin ecosystem: the "flexibility" of rack means that there are so many plugin options it's blinding, and the flavor of the week changes so often that it's hard to know if you're on a dead-end track or not.
* Google: the same issue with Rails core changes applies manyfold to the development ecosystem: blog posts, stackoverflow threads, forums, etc are quickly obsolete and it's difficult to determine staleness and whether the recommendations are pointing to a development dead-end where the project is no longer under active development.
The panoply of options and the chaotic development ecosystem can equally be attributed to Rails' newfound agnosticism, the development culture that engenders, and that chaos multiplied by the huge popularity of Rails makes navigating and getting things done difficult.
It's my experience that Rails involves a lot more yak-shaving than it used to due to the issues above.
I kind of wish there were a more conservative Rails community/blog/resource that issued recommendations and documentation/tutorials about a more stable way of doing Rails, making sure that the surrounding ecosystem is more stable and has less entropy than the community at large.
I started learning rails just as 3 was coming out. I had made a site with rails 2 and while googling around for help I found all these tutorials about rails 3 and they definitely made everything much easier. Sure, if I had more time invested in 2 (like this guy?) I'd be peeved, but I'm luckily more aligned with the direction of rails rather than its past.
This sounds like an old person ranting about the good ol' days
when it's probably a personal phobia against change.
Some of my best decisions as a software craftsman required change. Subversion to Git, PHP to Ruby on Rails, VPN to Heroku, all helped me build great stuff far more effectively. And some of my biggest problems came from attempting to adopt new technology x instead of building something great quickly with what I already knew.
I don't have a simple answer for maintaining that balance. It's hard. Being aware of needing that balance is a great first step. Complaining about change, though, seems to be the least productive response. Can I build something great right now? No? OK, can I learn something new right now? No? OK, then some downtime might be my best choice.
For right now.
------------------------
I think this is more my problem with the whole thing. The coffeescript thing just bugs me for some reason, it seems a bit like the javascript helper, rjs days and look how those panned out.
There's a Joel Spolsky article making fun of the way .NET releases come thick and fast just to keep Microsoft developers constantly worrying about catching up ... I just have this weird feeling that we're becoming the punchline in that joke.
-------------
Judge for yourself. http://www.joelonsoftware.com/articles/fog0000000339.html
Back in the day, I remember writing reddit comments and blog posts to explain the relative popularity of Rails over Catalyst. It was usually along the lines of, "people want to be told what to do. given a screw, they would rather bash it in with a hammer than to read about what a screwdriver is." Posts like this reinforce that point: people don't use Rails because they want to use Rails, people use it because they're afraid of anything else. Rails gave them everything that they thought they needed, and no easy way to back out of the defaults. It was a comfortable world where you could never do something wrong. Now that Rails is becoming a meta-framework like Catalyst, people are being driven away because they have to think before they program, and they have to customize Rails into the framework they want instead of just using the framework that dhh wants.
You can even see this in the Perl community; people are switching away from Catalyst in favor of mini-frameworks that barely meet their needs, just because they feel like the framework author has thought of everything and they will never write a line of boring code again.
If only.
Nonsense. Almost doesn't deserve a response, but...people use Rails because they agree with many of the choices made by the framework. Where they don't agree, and are willing to absorb the cost to maintainability, they override the framework.
(Not you, but the legions of people who think they're web developers because they learned RoR and never bother to learn anything else are pretty annoying.)
Just the other day I was writing a similar piece about Django on my blog. Back in the day it used to be damn-simple to start a Django project (compared to starting a Zope project, for example). Download the thing, change a line or two in settings.py, and you were done. No need to worry about what ORM was Django using or about how some people thought that the templateing system was un-pythonic. Things just worked.
Now I see that more and more people decry the fact that Django is not "modular" enough or that you cannot change its default ORM with any other one just by editing one line of code. Guess what? Your boss or the client doesn't care one bit about the virtues of SQLAlchemy compared to Django's default ORM, they only want to know how long it will take for you to implement the features they want. Now, if you, as a programmer, have enough spare time to handle all the loose bits (custom ORM, better templateing systems, custom URL dispatch mechanisms etc.) then chances are you shouldn't be using an existing web-framework (like Django, for example), and that you should build your own. But don't forget to finish your projects on time.
And, for anyone interested, here's Martijn Faassen's recent Euro DjangoCon keynote about what Django could learn from Zope: http://reinout.vanrees.org/weblog/2011/06/07/zope.html . The thing is, I'm old enough to remember about how Zope 3 was supposed to be the "best Python web-framework ever. It lets you do everything you want, you just have to understand interfaces". Six years on, and nobody cares anymore.
A major issue with some parts of the community is that some programmers think that being rubyists automatically makes them elegant programmers even if they don't have a clue about proper algorithms and that's probably why others call them "hipsters". The general disregard for improving performance, inherited from Ruby, is also something endemic from a while back. Sure programmer time is important but how many successful companies have started with Rails only to end up with a patchwork of Java, Scala, C++, etc. after lots of downtime and growing pains.
Getting your app into production is also another pain point with the all the dirty tricks you need to master, not to mention an array of lackluster choices be it nginx, passenger, unicorn, rvm, REE, bundler, etc.
So with that background, I think the author's gripes are understandable but it really doesn't touch on the undercurrent of discontent surrounding the current ecosystem.
So how many? I've hardly heard of this as the 'norm' for growing companies on rails... ? This sounds like 'Does Rails Scale' FUD.
Getting your app into production is not a pain point at all, services like heroku, or engineyard have made this as simple as 'git push'. Which nirvana of release management are you coming from where this is a 'pain point' ?
I'm objecting to the parent stating that deployment is a serious pain point for rails.
I would like to know what the 'simple' deployment stack people are comparing the Rails stack too?
But the main point is that since Rails/Ruby requires a lot more resources (cpu, ram, etc.) and wraps a lot up into a black box (auto-generated queries that might have a deadly join or two), when you deploy it's more "thrilling" for want of a better word.
I'm not saying Rails sucks completely, but the programmer productivity thing is oversold because in a small shop, the dev guys are usually babysitting servers too. This and some whimsical api changes can dampen your enthusiasm a bit. I just wanted to emphasize that some Rails enthusiasts are zealously in a state of denial of Rails/Ruby short-comings and putting a Rails app in production/deployment can be a bit challenging. Like others have said, the number of startups focused on making deployment and scaling of Rails apps "easy" kind of says something.
For a serious project I think rails is great but you can't deny it involves lots of abstractions which sometimes break down and then necessitate expert knowledge that most people don't have.
Deployment of PHP is the same as deployment
of static HTML
For rails you need to understand version control,
webservers and scripting
you can't deny it involves lots of abstractions
which sometimes break down and then necessitate
expert knowledge
Rails is not for contact forms. You are better off using PHP for that - but I saw contact forms evolve into big piles of unmaintainable crap and developers doing that because they thought a mature framework was too complicated and haven't evolved since then - shouldn't have a place in this industry.
Horrible yes. State of the art in most web consultancies also yes.
Passenger allows one to basically work this way with ruby too and it is sorely needed because there are 'developers' out there that seemingly haven't worked with Sourcecontrol in their entire career. If you need to give them access to some templates it is nice if you don't have to bring them up to speed on git first.
I wouldn't hire those people but I was forced to work with some.
My point: Allowing a less robust but easier deployment method is a pareto improvement because I can now choose. It is also a path towards sane practices used by experts when you start with a big pile of unmaintainable crap.
However, Ruby on Rails was never good for shared hosting. It was never designed or intended for this purpose. The deployment solutions available are not doing so good in a shared hosting environment. Or at least, not as good as PHP (nothing is as good as PHP in shared hosting).
The deployment story got a lot better when Passenger came along in 2008, which is a self-healing and easy to configure server, capable of functioning with Nginx or Apache in front. You wouldn't believe the shit you had to pull before that for reliable servers.
Personally, I hate Heroku because their prices are for the moment too high and I could partly replicate their environment on my own, using already available tools. But such hosting services will become the norm as they are so kick-ass and convenient; for instance I just received an invitation for Gondor, a Heroku-like service for Python and Django.
Heroku exists because Ruby deployment
is a major pain point
In fact, I found the deployment story of Rails (with the help of Rvm, Rake, Bundler, Capistrano and Passenger) to be the best one yet and no other environment can really match it (although you get pretty close with Python, Django, VirtualEnv, Pip, Fabric and mod_wsgi for example).
And I'm not using something like Heroku btw, as I consider it to be seriously overpriced - I'm maintaining my own Linux servers on top of EC2 (which still involves pain, that I can handle nonetheless, but then again I also have sysadmin skills). Deployment for me is literally just "git push && cap deploy".
As far as I can tell, I need the V8 code built on my production boxes! That seems insane, unless I want to switch to using node.js....
On my FreeBSD system, I still have no idea how to get V8 built correctly. I've bailed on it for now and am running my 'production' server with the 'development' environment.
Remember, I'm not running beta software, I'm running a 'release candidate'.
When this works, it'll probably be great, but stick with 3.0 if you actually want to make progress on your application.
Assuming you have a compiler on the production box, you're fine.
If you're on Heroku, you may need 'therubyracer-heroku' instead - there are compilation issues. Hopefully this will be fixed soon.
This deployment scares me a lot -- partly because I haven't yet made it work in an RC build, and mainly because it adds more moving parts to my production servers.
Coffeescript is rad as hell, but making Rails depend on it by default without a really great way to install it seems foolish.
Automatic compilation of coffee scripts is nice in development, but not overhead you want to add for production anyway.
You could look at using something like a Git pre-commit hook to do that pretty trivially. I personally use a rake task that compiles all my Sass and Coffeescript to their respective CSS and JS files, then packs it into minified-and-gzipped files with jammit, then commit the resulting bundle. I end up serving pre-baked-and-concatenated assets and it works just fine.
We use Capistrano to deploy our app, so packaging assets on the way to the server is as simple as an additional deploy task for the production environments. We have a task named precache_assets that uses Jammit [1] to compile assets based on the Jammit settings (stored in a yml file, imagine that).
<satire> My guess is that eventually there will be another golden boy and a whole new generation of programmers will swear that it is the best thing since the invention of the wheel while at the same time complaining of all the baggage and bad decisions made in Ruby/Rails and ridiculing anybody that still uses it. Meanwhile the Ruby/Rails developers will look and scratch their heads wondering what all the hate is about. After all, Ruby/Rails gets the job done even if it is not perfect and anybody that is a language fanboy does not have a brain. After all, a programming language is just a tool. A whole generation latter the cycle repeats itself with yet another golden boy language. Sigh! To be young and stupid. Those were the days. </satire>
Members of the Rails core team recognize that growth has limits. They are looking for ways to reduce the stack to improve the design and make things more performant. See Aaron Patterson's RailsConf 2011 keynote.
Also, I think the switch from prototype to jQuery will help beginners.
But what do you do? Slow down? Not sure that's good either.
At one point in time, you did forms like <%= form .... and then they switched to <% form .... do and now they've switched back to <%= form ... do again.
Also, the upgrade to Rails 3 is not an easy one. Yeah, you get some nice stuff, but because it's so painful, it's not happening for a lot of people, which is causing more problems.
All in all, I still think it's the best thing going in web development today for what I do, and am not contemplating alternatives.
Edit: are images not supposed to be served through /assets? They were loading too slowly for me, that was my major complaint.
The asset pipeline can be a development concern only, if you want it to.
In regards to the framework being too opinionated and/or moving too fast, its the exact opposite of the landscape in PHP, where there is a splintered and slow moving culture, with no one framework and certainly nothing as technically advanced as Rails.
If I had to pick I'd take the Rails culture everytime, its more exciting and fun for one.
Many big names are still on Rails 2.3.x, too. Forgive me if I go astray here, but GitHub and DocumentCloud are two examples that come to mind.
That being said, nobody is forcing you to jump on a release candidate. Just use the latest released, stable version. In this case Rails 3.0.x.
I agree with the author that (2) is getting harder - but this is the price you pay for improvement.
I disagree that (1) is getting to be overly difficult. By and large, the changes to Rails 3 and Rails 3.1 make it easier for developers to do more advanced things with Rails. If you just look at the simple tutorial applications that newcomers to Rails are starting out with, I don't think their complexity has increased very much from Rails 2 to 3 to 3.1. Yes, they are different from version to version, but this doesn't matter to the newcomer.
TL;DR - the framework has more functionality, which makes it more difficult to learn the entire framework, but it is not significantly more difficult to learn how to accomplish any given task.
If you are having trouble with rails, it's for two possible reasons... 1) you won't accept that it's opinionated software and throw out your preconceptions or 2) you're just not trying hard enough. The amount of books, screencasts, tutorials, podcasts out there for rails is just insane. I'm completely jealous these things weren't around in '06 when I started.
Edit: Should have mentioned that he did the Michael Hartl screencasts/tutorial (http://ruby.railstutorial.org/)
That's a brilliant point. Some time ago I wanted to try out RoR to create a fast prototype. It turned out, that if you need just one prototype and if you don't know RoR, you'd be way faster if you use things you already know or just read the short Sinatra manual instead of spending weeks of learning only to be able to START the development.
* A new language
* A new framework
* A new programming paradigm
* A new set of libraries
This is going to be really hard if you're currently a spaghetti coder. Will you learn a lot? Will you become a better programmer? Will you enjoy coding more? I say yes!
Also the barrier to any framework in any language is the same.
Defaults, conventions and DSL's are for less code only. You still have to know the rules. (Both DSL and what's underneath it.)
Javascript is not simple - so we have CoffeeScript. HTML isn't - there's HAML. (1 line of code to add it to Rails 3.1) Web applications are now more complex - client logic finally moved to /app folder.) We can still enable old routing (uncommenting one line).
But you have to learn bundler for dependency management, know application.rb configuration options, etc.
So I don't get what 'simple' about that technology stack. It's DRY and rather flexible, but not simple.
Part of that is changing things to make things more orderly, so you can actually find your way around a complex application without too much wasted effort. That places demands on developers, especially when migrating, but makes it easier in the future.
The amount of power you can weld in the present is dependent on how much capability you acquired in the past. You can always enter a battle with your bare fists and no learning curve, but if someone gives you a free sword, learning to use it before the battle is more likely to lead to victory.
This is not learning for the sake of learning. But even learning for the sake of learning grows your ability to learn.
Why? Why is Rails changing to handle this, instead of add-ons, plug-ins, and gems changing?
So we've been pursuing this mission for 7+ years. We've just gotten better at it.
Instead of downloading downloading code and then moving files to their proper locations, the new asset pipeline lets developers package such assets so bundler can accomplish that for you. You'll just specify what the asset is and what version you want in Gemfile.
That's a change that you can't just rely upon some gem to make. It's really the responsibility of the framework. And it creates order, making Rails easier to work with, especially when the app gets complicated.
Similar changes have similar rationales and these can be understood by watching videos like this one:
http://www.youtube.com/watch?v=cGdCI2HhfAU&list=PL379EA9290474C86CWhile this is common, it doesn't really have anything to do with Rails itself. I can't think of any Rails dependencies that have mandatory native extensions off the top of my head.
Are you on a Mac, by chance? With XCode/GCC + MacPorts, I've not had many issues with gems. Add to Gemfile, run bundle. Done.
http://pine.fm/LearnToProgram/ (probably not relevant for HN) http://ruby.railstutorial.org/ruby-on-rails-tutorial-book http://devcenter.heroku.com/articles/quickstart
Make the base setup as such that it minimizes what they have to learn to achieve some success, and let them turn on technologies such as HAML/SASS/Coffeescript later on once the cognitive load of switching to Ruby and Rails has decreased.
Try learning spring mvc to see what it's like to give lots of options.
As oppose to Ruby, Rails, ERB, CSS, and Javascript?
- CSS is valid SASS - Coffeescript is closer to Ruby/Python than javascript and is possibly an easier learning curve (if you don't already know javascript) (You can use javascript if you want as well).
Call it FUD (despite the fact that I do all my development in Rails) but the issue isn't the reality, it's the perception. You make these the defaults for Rails and/or you write the new user tutorials in them, and you increase the perceived difficulty of starting to use Rails. You make them options that more advanced users can choose to turn on, you reduce that friction. That's all I'm saying.
To clarify: I'm pro HAML, SASS/SCSS and I like the idea of Coffeescript even though I'm not using it. I just think that some of the way the've been going with Rails is not great from the perspective of growing the adoption of the platform.
And yeah, my mistake about HAML. I've been using it so long with Rails I've forgotten it's not a default.
I've found a lot of devs while they have been 'trained' in C/Java/Pyhon/Ruby have kind of just picked up bits and pieces of javascript without a really a firm understanding of how it works or it's idioms. Coffeescript on the other hand, has a very (python-esque) prescriptive set of idioms that produces very decent javascript, if you don't follow the idioms, it doesn't compile.
For an absolute "i know nothing" I think the Ruby, Rails, HAML, SASS, Coffescript is a smaller learning curve than ERB, CSS, Javascript.
In a world where some time on the core team can land someone $300K per year in salary + speaking + book deals, there is bound to be this sort of chaos. I view the push toward agnosticism as a misguided attempt to be the "one true framework" and also to salve the egos of those whose decisions and work are being undone.
That's a bit disingenuous, isn't it? Yehuda was offered an opportunity that makes sense for him. It's not as if he's abandoned the Rails community in a flurry of drama.
DHH is the kind of guy that is going to speak his mind, and if you're wise you'll at least listen to what he has to say. If you find yourself agreeing 100% of the time, it's time to find different company.
Similarly Yehuda and Carl spearheaded Bundler development. They bit off a massive problem that touches anyone doing large scale ruby development and through sheer force of will hammered out a powerful solution that solves the majority of common issues in a relatively straightforward manner. There's lots to argue with, for sure, maybe it's over-engineered, maybe they didn't work closely enough with RubyGems core, etc; but at the end of the day they solved a problem that was too hairy for the average dev to have much hope of solving.
Yehuda's been there, done that. He doesn't need to stick around and be Rails core forever, there's plenty of new blood to pick up the torch, and bigger problems to solve elsewhere.
I've also been contributing more code recently, and after taking something of a hiatus, have gotten back into it a bit.
No drama here!
Also, please back up your core theory with something else than wild conjecture. Core is more stable and uniform than it's been in years.
Remove these lines:
*= require_self
*= require_tree .
We're building client heavy apps, though, and haven't felt a need for it. But now it's there if you need it. Enjoy!
However, I'll be honest, I find it completely unbelievable that you don't have a problem debugging in one huge js file. I guess when using coffee script the connection between what you are debugging and what you are editing is already completely severed so maybe at that point it doesn't matter anymore.
django on the other hand is not there yet, compared to rails.