- 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:
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.
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!
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 |
- 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]](https://i0.wp.com/img.zemanta.com/reblog_e.png?w=1000)
Hey Terry,
I just wanted to point out that Lifehacker (and all Gawker Media sites, such as Gizmodo, Kotaku, and io9) do not run on WordPress, nor have they ever. A few years back, we were running on MT, but that has long been scrapped for a custom-built PHP framework.
-Ian
Sr Platform Engineer
Gawker Media
@Ian Van Ness: Thanks for the correction, and sorry about that error. I should be more careful when I refer to blogs run by Gawker, Weblogs, Inc., and HuffingtonPost.
I guess the Pareto principle holds with large blogging networks, though I think these days that’s getting squeezed by WordPress MU: http://wordpress.org/showcase/flavor/wordpress-mu/
Rails has failed for many reasons, but I say that coming, Christ I had said as much on Sitepoint a few years ago.
My… how I laughed at those who jumped on the RoR bandwagon and how I still laugh today, knowing then and been proven now just how much of a failure RoR has been.
A complete waste of time, so for those who took it up, congratulate yourself for picking a donkey.
There are a few jobs in Rails development so I suppose it hasn’t been a complete waste for some. The LifeHacker article is advocating learning a framework (and Rails gets top billing) so that would imply learning Ruby and Rails is still heavily advocated as a first language (and bad advice).
I know someone who talked to a product manager about learning web software development and the PM suggested learning Ruby on Rails as a first language/framework. (Though I think this advice speaks volumes about the PM).
I also think a lot of good stuff recently has come from the Ruby community (and dare I say Rails?): GitHub for one, a lot of cloud computing management tools, etc. It’s probably an interesting article to discuss how and why that happened. 😉
While some of your thoughts are valid, they're just blasphemy unless you first straighten up some facts. The biggest one is the statement that RoR comes with script.aculo.us. Well, that's not true, at least not in the way you've meant it. RoR comes with http://prototypejs.org and http://script.aculo.us is an extension to prototype, just like jQuery UI is an extension to jQuery and dijit is an extension to dojo. You see, your lack of knowledge makes every other statement about Ruby and RoR pointless, because you can't comment on something you don't know. You make yourself look like a Klugscheisser.
Another bold statement is that script.aculo.us (actually prototype) is tightly coupled with RoR. That's not true. Prototype is a stand-alone JS framework. It is just nicely integrated into prototype. And how about dojo and ZF? Are they loosly or tightly coupled? Well, in both frameworks there are ways to use different client-side library, it's up to the developer, it's up to the project.
I think you really should try to overcome your hatred about Ruby and RoR and first try to achieve something with this tool before commenting on it. After all programming languages are tools and there is one right tool for a given job, you won't bang a nail into the wall with a rubber hammer, now won't you?
@Nikola: I appreciate your response. While I admit that I gloss over the details and my analogies are not perfect in order to emphasize a general point (the general point is that Ruby on Rails was a marketing success to the extent that they "hitched their cart" to Web 2.0), where did I actually claim that Ruby on Rails comes with script.aculo.us? Even if you take my analogy of PHP and MySQL to an extreme, PHP never came with MySQL—it just came with libraries to bind with MySQL.
Furthermore, if you mouseover the word "script.aculo.us" when it is highlighted in my article, you see I actually acknowledge that it is an extension of prototype, which is a javascript framework library. The analogy is actually very strong because the library to "bind with" script.aculo.us is prototype which is practically bundled with Rails (I had forgotten that it was actually bundled, so thanks for that correction).
As for jQueryUI, I ran into this same argument months ago when discussing flaws in jQuery's base library design someone in person, and I pointed out that rarely (never, really) does someone use jQuery's base libraries without the intent to use the UI portion of jQuery (similarly when one says the term, colloquially as "jquery" one really means jQuery ad jQueryUI). That's like talking about how small YUI is when really the starting point of almost all YUI developers begins with utilities and not core. (Time and again at JavaOne in 2007, I'd talk to enterprise javascript framework developers only to find out the "small" 150k library they were talking about only covered the core and not any of the UI!).
To be honest, I stopped developing in Dojo before the namespace was split between dojo and dijit (Plaxo, 2006 was the last time I used it), which I believe was with the time Dojo 1.0 came out, but my memory is failing. My guess is that DojoToolkit without any widgets is probably non-existent in the consumer web space we talk about (frankly, Dojo is about as popular as Prototype/script.aculo.us in that space, but it tends to creep into the enterprise space where jQuery and YUI and script.aculo.us don't have much presence). Your point is that if I use script.aculo.us as the name instead of prototype/script.aculo.us, then I should have used dojotoolkit/widgets and jquery/jqueryui is well taken though. I believe I made this error simply because the day I realized that javascript frameworks instead of self-made frameworks would take off was sometime mid-2006. At that time, there was no use of prototype, without script.aculo.us, dojo widgets hadn't been split into its own namespace, and jquery was either non-existent or not in any use (at least we never considered that as an option, and I didn't start hearing any buzz about it until 2007).
Which is to say, I do appreciate the correction, but not the spirit of the correction. Given the already large size of the article as well as the target audience (first time developer using web-based development as the model of immersive learning), I'd be lucky if they sit through the article, let alone have gone through this entire bit.
Regarding your second statement in the same way, I hope you see I'm correct in the same manner. First it's not like MySQL is the ONLY database PHP uses, far from it! The only real thing that marks the key to its symbiotic relationship (to the extent that both are successful and their success is paired) is that MySQL has a special position among databases in the PHP world, not to the extent that you can't do PHP without MySQL. Compare this to your criticism of me my "bold statement" that it is "tightly coupled." It certainly would not be bold at all to say that PHP and MySQL are tightly coupled, though you could argue differently in detail.
As for your final paragraph, perhaps it is you who needs to overcome an inferiority complex that drives an incessant need to defend against imaginary attacks on your favorite language. In one of the comments above, I chastized an anti Ruby on Rails tirade by pointing out that for the better the Ruby language (and dare I add Rails) has given the programming world some nice things like GitHub and a bunch of tools for managing cloud computing (and continuous integration). But the tirade was correct in spirit, if not detail. To the extent that Ruby on Rails grew in Web 2.0, it was inevitable that this growth would be temporary. Remember, digg was using script.aculo.us before there was any Rails website of note. Compare your correction to the developer at Gawker. Even though his correction was much more damning to the thessis of my article than yours, and yet he didn't do it in a manner that took any offense. One can argue about whether or not I have "hatred" about Ruby and RoR, but it's clear by comparison that you are overly defensive about a perceived slight when none was given nor intended.
I should probably mention that in late 2005, I once fielded a query about someone looking for a javascript developer, and the person didn't care about prototype…they were looking for someone to do script.aculo.us. In other words, prototype is only of interest because script.aculo.us. Similarly nobody now uses YUI without the intent to use the gui tools, nobody uses jquery without jqueryui, few use dojo without at least a little bit of require into dijit. In much the same way as Application Kit, not Core Foundation is the interesting part of Cocoa. This was a central thesis: the attraction to any framework and its continued success rests almost entirely on how easy they make it for the programmer to code a graphic user interface, and almost not at all on how the core architecture is structured. How many complaints has Apple fielded on reference counting? How many times have people pointed out the wastefullness encouraged by the $() function in jQuery (and prototype)? But can we overlook them when we get something that allows us to build what we can so easily? I’d say damn straight.
Finally, are you honestly going to argue as a first language a beginner should learn HTML/CSS/Javascript/Ruby/Rails/MySQL/mongrel(or find and pay for Rails based hosting)? Are you going to, with a straight face, tell me that this is going to be a better track than PHP (whose hosting is ubiquitious and nobody is recommending ZF to be learned), or even Python (given that Google Gears is out there)? Especially in light of my first articles admonition against PHP as a first language unless you already know HTML/CSS/(rudimentary Javascript), have some savviness in the command line, and intend for web applications to be your immersion?
(BTW, if your question about ZF and dojo is not rhetorical, I claim that the two frameworks are tightly bound and have a shared destiny—more that ZF’s success is contingent on Dojo's and not very much vice versa. That seems like a pretty savvy relationship because among PHP's frameworks ZF is successful mostly in the enterprise space, but the extent they are successful vis a vis various J2EE solutions is ZF is more modular and much lighter in weight. Similarly, Dojo is, in this authors opinion, extremely modular (almost too much so) and too "heavy" for consumer facing web—multiple page loads, 15-20K in javascripts being the current limit in acceptable file size—but much lighter than TIBCO GI or whatever the frameworks du jour are in enterprise.)
When you learn the initial level programming then you can switch over the second level of the programming like the advance c++, advance Java etc.. But the choice is depend on you.
I definitely agree that learning a full stack frameworks is not the best way to start out. Instead, new programmers should look to component libraries like PEAR or ZendFramework (not the MVC). This gives a nice balance of learning how to do things yourself while not leaving a bunch of security holes in your application.
I always suggest Python as a first language due to its structure structure and PEP's, but if someone is trying to crank a website out it is hard to argue against PHP.
My recent post Why I am not running to Solar
Couldn't agree with you more. Learning jQuery & YUI was a life-changing experience for me, but learning the Zend Framework I was like… meh… nothing I couldn't really slap together with a few PEAR packages. The first time I'd started to question frameworks was when I'd read an article by Lars himself saying not to bother with them… too much overhead… all you need is YUI. Btw I've jumped ship from PHP & JavaScript over onto the GWT bandwagon. I have to say I'm really enjoying the client and server side integration! Again the focus here is on the UI and not forcing an architectural design down your throat.
Whoops did I say Lars, I meant Rasmus… damned Northern European names… they all sound the same 😉
here is obviously a lot to know about this. I think you made some good points. Congratulations