I don't agree about JQuery. The learnability is good and it's really easy to get things done very fast. But when the code base grows it becomes really hard to maintain the code if you don't know JavaScript very well and know how to structure the code.

That's why many people have started to use CoffeeScript and/or Backbone.js to write more maintainable JavaScript. But the CoffeeScript/Backbone.js route is harder for beginners but in the long run it's a much better choice.

  > But the CoffeeScript/Backbone.js route is harder for
  > beginners but in the long run it's a much better choice.

What you say makes no sense. Ok it makes sense, but does not make sense in context of jQuery. jQuery was never intended to be a framework or tool to organize your code. It is just a DOM/events/Ajax library, that's it. Its purpose is completely orthogonal to what Backbone does and even more so to what Coffeescript does. You don't manipulate DOM with Coffeescript or Backbone, but you may use Coffeescript to write your DOM manipulation code and you may use Backbone to organize your code.

Yes, I understand what you mean and when I wrote this I knew that someone would comment on it :)

This is how I see it:

Pure JavaScript + JQuery = Very easy to get started but very hard to maintain when the code base grows if you don't know JavaScript very well.

CoffeeScript + JQuery + Backbone.js = Harder to get started but the code becomes easier to maintain when the codebase is big.

I know that JQuery is not about organizing code.

The problem with cakephp is that every book written on this subject surpasses the quality of the framework itself. cakephp is easy to learn, but for me it's unusable in the long run. Easy stuff get's even easier, hard stuff get's harder. That's exactly what David meant. If you trade everything for learnability, it's not usable.

That sums up my experience with cakePHP too. I don't know what's happened with this framework in the last couple of years, but when I was first learning Rails and enjoying it, I used cakePHP for a big project because I knew PHP well, and didn't yet feel comfortable with committing to using Rails for it.

That was a decision I regretted many times. The hoops I had to jump through to deal with complex database queries were ridiculous. The difference in quality and robustness between ActiveRecord and cakePHP's ORM (at that time, anyway) were pronounced, with AR coming out way, way ahead.

There's no doubt, in my mind, that if you are going to take on a large, ambitious web application project, you'll be better served by Rails.

Yes, CakePHP's "ORM" isn't a real ORM - it was built when Objects were awesomely broken in PHP4 - but I've actually found it much more usable than the current state of Ruby's ActiveRecord/Datamapper. Manipulating arrays to get just the SQL you want is sometimes annoying, but for the queries that you honestly can't get out of the ORM in CakePHP, it's also likely you wouldn't be able to do the same in any other ORM.

You'll also have to note that both frameworks have progressed significantly in the last few years - CakePHP actually just released a new major version, as did Rails a few months ago - so your experience a few years ago - was this in the 1.1 era - would just be indicative of the framework's beginnings, not where it currently is.

Feel free to message me with your thoughts if they still conflict; I'd love to hear the other side of the story since improving CakePHP as a framework helps not just my ego, but other developers who are using CakePHP to make a living :)

Two things:

- In my very humble opinion, only one - English! I can't comment on the international community - book has been any good (That by Mariano Iglesias) and they all tend to either have outdated information or just bad code samples. So no, they do not surpass the quality of the framework. - Hard stuff is always hard, regardless of the framework. At a certain point, you start butting heads with limitations in the language, at which point no framework will help. I've also found "hard stuff" to be fairly easy in CakePHP due to the large plugin base I can reach into - only Django and Ruby Gems really solve this sort of problem - so no, the hard stuff doesn't get harder.

Regardless, I'd be more than happy to get your feedback on this though. Send me a message :)

Can't comment on CakePHP, but I think jQuery is actually an example that favors DHH's view: It really simple to get started with, and there's tons of cools stuff you can accomplish. But try building a full web app along the lines of GMail or Google Docs with it and you'll quickly see that there's only so much you can do well with $(). In a simple website, jQuery can take care of all your JS needs. In a full fledged web application, it's mostly magic in the View.

Read closer. Never does he say usability and learnability are opposed, just that there are opposing cases and that he doesn't agree with optimizing for learnability first.

But he's saying like you can only choose one from the two.

>There are plenty of cases where learnability and usability are in conflict

>That's where learnability and usability are again in conflict

But it is hard to work on both so you may need to work on usabilitiy first then work twice as hard for learnability.