A selection of programming language textbooks ...
Image via Wikipedia

(Full disclaimer: I work at Automattic and am a speaker at PHP conferences.)

A couple days ago, Gina Trapani posted an interesting article on learning to program.

This reminds me that some people may take the wrong points away in my last article on the subject, the priority shouldn’t be what language you should learn, but rather, what is going to get you motivated to learn. PHP is a popular language because it naturally invites “immersion” style learning, not because it makes a good teaching language—which it doesn’t. That is, assuming the thing you are immersing in is “building a website”. As I like to say:

PHP is the shortest distance between two points on the web.

In the comments, I wrote:

After [the first] chapter, I’d say [PHP and MySQL Development]offers the most “immersion” gratification (at the least cost) than any other language’s textbook. The chapters are easy and by the end of it you have an eStore written and working from scratch. What do you get at the end of the Learning Python book? And how easy was each subsequent chapter? I’d say much less and much harder.

…

[Unfortunately,] it’s that first chapter that does the first timer in.

HTML, CSS, and Javascript

But what Gina’s article reminds me was something very important I forgot to mention: If you are using a web language as your choice, then it is vitally important you learn HTML, CSS, and Javascript.

The caveat here is that while HTML and CSS are languages—they are not programming languages; they are markup languages. Learning them is no different than “learning WordPerfect” back in the 80’s. You are not a programmer if you have learned HTML or CSS.

Javascript, on the other hand, is a programming language. It’d probably become your first programming language if you do this approach, but you do not need mastery (yet) of it to become a web programmer, so you might not feel that it really is your first language. But a real language it is: having all the constructs that define modern software programming languages, being Turing complete, and actually being quite ubiquitous—you see it in Photoshop, Adobe AIR, Dashboard, CouchDB, and countless other applications and systems.

Taking exception

Now here is where I take a big exception to Gina’s piece:

Frameworks: Over the years, web developers have had to solve and resolve the same problems and rewrite similar code to build dynamic web sites. To avoid making everyone reinvent the wheel for every new web development project, some programmers have come up with development frameworks that do some repetitive work for you. The popular Ruby on Rails framework, for example, takes the Ruby programming language and offers a web-specific structure for getting common web application tasks done. In fact, Adam used Rails to build his first serious (and impressive!) web application, MixTape.me. Here’s his take on how to build a web site from scratch with no experience. Other popular web development frameworks include CakePHP (for PHP programmers), Django (for Python programmers), and jQuery (for JavaScript).

First things first, you shouldn’t put jQuery into the same category as Ruby on Rails, CakePHP, and Django. The former is a client-side Javascript framework (which I’ll get to later), and the latter are server-side web frameworks.

But more importantly, I have a problem with server-side web frameworks in general:

About Web Frameworks

One day, I was at a ZendCon and I happened to be eating dinner where three other PHP developers were talking amongst themselves—one developed Zend Framework, another develops Symfony, and the third develop CakePHP. All three are server side-web frameworks, and I had a well-known reputation for disliking all web frameworks. (Some of you misinterpreted this as a dislike for the Ruby on Rails framework, but I’m actually an equal-opportunity hater. :-) )

So I said:

“Hey what are you guys doing talking to each other? You should all be talking to me. Convincing me to use your framework would be a ‘Nixon Goes to China’ moment!”

We all had a good, content-free laugh.

The history of frameworks

But seriously, it’s not like the web world invented software frameworks. There are many of them out there. Here are some (off the top of my head): Boost, MFC, Cocoa, J2EE…

But if you look at it, most frameworks fall into two categories:

programmatic architectural frameworks user interface frameworks
Boost MFC
J2EE Cocoa

By and large, this categorization has had two historical outcomes:

programmatic architectural frameworks user interface frameworks
FAIL success

With few exceptions, to the extent that frameworks have tended to providing user interface they have succeeded/supplanted their competitors, to the extent that frameworks have abstracted core algorithms, they have failed.

So what is my problem with web frameworks?

They very clearly fall into the former category.

Rails Fails

Let’s take this hypothesis even further: to one of the most successful web frameworks out there (and my perennial punching bag)—Ruby on Rails. Ruby on Rails and a Javascript user-interface framework known as script.aculo.us have had a symbiotic and paired history, much like PHP and MySQL.

To the extent that Rails was the first web framework to have paired so intimately with a Web 2.0 Ajax framework like script.aculo.us, it has succeeded among its peers. In fact, in the comments of my original article on Rails, I wrote:

Ruby hitched their cart to the Web 2.0 bandwagon and then claimed that they were the ones pulling it.

Smart.

To the extent that Web 2.0 was a buzzword and in vogue, Rails was the Web 2.0 language du jour and successful. But when script.aculo.us began to be supplanted by other more successful Javascript frameworks like DojoToolkit, jQuery and YUI—which are only loosely-coupled to the server-side web architecture—Rails has seen their success rate dwindle.

 

Purchase some Fails buttons designed by spooons.

Today, I wouldn’t be surprised to find out that there are as more Zend Framework developers out there than Ruby on Rails ones.

While a viable business segment by itself (much like J2EE), because it doesn’t live up to its hype, this goes down as a FAILS.

The rock and hard place

A more interesting question is: why do programmatic architectural frameworks “fail”?

I believe because they are often stuck between a rock and a hard place.

The “rock” is the fact that there may already be an application written that meets your needs already: like WordPress, Drupal, Joomla, MediaWiki, phpBB, Magento, SugarCRM, etc.. As Chris Shiflett once quoted::

“Ruby [on Rails] is really good at what it does. The problem is, for what [Rails] does really well, I can download WordPress.”

The “hard place” is that a project that is long-lived ends up falling victim to the Pareto Principle: the 80% of the codebase the framework wrote for you would have only taken 20% of your time had you written it yourself. The code you visit all the time might have taken less time had you written it from scratch to consider your application in mind.

“Ruby on Rails is making it easy to develop the sites that have been already been developed, but it is not necessarily making it easier to develop the websites of the future. And maybe at that point, the Pareto Principle becomes the determinator and we meet the hard place.”

It’s not that there are no uses for a framework. It’s the space of problems between the rock and the hard place is rather narrow.

The missing framework

Which finally gets me back to the issue I have with Gina’s article. A suggestion to learn a web framework is a bad idea, because the usefulness of a framework is mitigated by the time it takes to learn a framework in the first place.

The only exception is that general purpose languages like Ruby and Python have a huge barrier for web programming at all. This barrier is partially mitigated by learning a framework like Rails or Django. There is nothing wrong with learning Rails if you are already a Ruby programmer (and have a web project) or learning Django if you are already a Python programmer (and have a web project), asking you to learn Rails in addition to programming Ruby, or Django in addition to programming Python is really like asking you to learn two languages to code one.

Learning a language in order to use a framework is as absurd as saying you should learn PHP just so you can use Smarty!

Vote on some creative WordPress logos created by our users.

But most importantly, the example that Gina uses is a lie. I’ll bet the first serious (and impressive) web application that the editor, Adam, built with a web framework was not in Ruby on Rails, but in PHP on WordPress. WordPress? You know, the software framework which powers that website as well as his personal blog?!

Not “built?” Then why is one of LifeHacker’s most popular article on how to trick out your WordPress blog?

Not in a “programming framework?” Well, maybe not initially. But I find it hard to believe that LifeHacker doesn’t have more than a few custom plugins. Just the other day, I had an editor of TechCrunch mention to me about the problems of managing WordPress plugin and custom plugin compatibility there. Read the documentation on developing a WordPress plugin and tell me that this is not similar to developing inside a web framework.

Not “impressive?” I’ve actually heard of LifeHacker (and you probably have also). I have not heard of (and neither have you) of whatever that website was that Adam built.

Not “serious?” What do you think will get you more serious about programming: starting with blogging software, tricking it out with a couple plugins, and then fixing them or filling the gaps with your own coding in order to make your web site unique. Or learning two markup languages (HTML, CSS), two programming languages (Javascript, Ruby), at least two other applications (MySQL, mongrel), and one framework (Ruby on Rails) simultaneously in order to build the skills to build something that you’re not too sure yet what it is, but you know it better not be anything resembling blogging, web publishing, community publishing, content management, forums, eStore, or customer relationship management, nor anything on the scale where it would actually need to be maintained for a long time (Facebook, Tagged, WordPress.com, etc.).

Sure, it is good advice to not advocate a particular programming language. But to turn around and advocate that people learn a web framework tied to a language when such things have very limited uses and a more immersive strategy is staring you in the face?

You just fell victim to others telling you how to learn experience, instead of examining your own experiences learning!

About Javascript frameworks

Now back to the Javascript frameworks.

Not all frameworks fail, the ones that don’t seem to focus on providing libraries that assist in user-interface. Programmers don’t like to do user-interface because it is a pareto-trap: a huge amount of code that takes a huge amount of your time to write or debug. This makes frameworks that provide graphical user-interfaces very attractive.

In the web world, the user interface is on the web browser: HTML, CSS, and Javascript (the three pillars of DHTML).

Let me complete the hypothesis:

programmatic architectural frameworks user interface frameworks
server-side frameworks client-side dhtml frameworks
Rails, Django, J2EE, CakePHP YUI, jQuery, script.aculo.us, DojoToolkit
FAIL success
CakePHP
Image via Wikipedia

I’m not saying it’s worthless to learn Rails, Django, J2EE, or CakePHP. There are many gainfully employed Rails, Django, and J2EE developers out there…and maybe one or two CakePHP ones ;-)

I’m saying if you are doing web work, you’ll get more out of learning YUI than Rails, more out of jQuery than Django, more out of script.aculo.us than J2EE, and more out of Dojo than Cake.

Further reading

If you’re interested in more about learning and teaching programming, I highly suggest Eugene Wallingford’s blog… and not just because he quotes my article twice. ;-)

Reblog this post [with Zemanta]