Flummoxed By Frameworks
Published 17 years, 11 months pastI used to be a programmer. Way back in the day, I wrote great big heaps of BASIC and Turbo PASCAL 4.5 and worked in a few other languages of that era (I may be one of the few people left who remembers Clipper). At one point, a high school friend and I worked on creating our own command-line environment for the C64, for no other reason than it seemed like a fun challenge. I’ve written quite a bit of JavaScript—not like a wizard, but well enough to get some things done—and a fair amount of PHP. These are languages that I understand, that make sense to me. I can make them do what I want to do.
But I just don’t get all these new-fangled programming frameworks. Is something wrong with me? Seriously. I have this grumpy, churlish feeling that I suspect is rather similar to the way SGML experts felt when they saw HTML becoming so popular, and that scares me.
People who’ve drunk the various kinds of framework kool-aid don’t make it any easier, though. “Oh”, they gush, “you should absolutely try Ruby on Rails! It’s so easy! It’s almost like writing regular English!” Which means they’re clearly on crack, because Ruby on Rails is so very different from a human-written language that the few ways in which it sort of resembles prose, assuming you look at it under a dim light through a heavily fractured fresnel lens, serve only to confuse me further. I have many of the same problems with MySQL, actually: by dint of its being sort of human-like in its syntax, I’m led into all kinds of incorrect assumptions about what I can do. Thus I spend a lot more time screaming at opaque error messages than seems necessary, just because I thought a comma made sense when the language didn’t.
I’ve looked at all kinds of different intros and tutorials and “for regular folks” resources, most of which I get from Simon‘s linkblog, for a number of different frameworks. They serve only to confuse me. The CakePHP 15-minute blog tutorial? Didn’t get it, and remember, I can write PHP relatively well (I wrote all of An Event Apart‘s registration stuff using PHP and MySQL, for example). The oft-recommended Tutorial in Ruby on Rails? Lost me, Coach. Even Jeff Croft’s Django for Non-Programmers left me in the dust.
All these frameworks’ proponents say “Just write in this totally simple and obvious way and the messy details will be magically handled for you!” but that’s just not how it works. You have to write in a very specific and unintuitive way, and unless you know specific magic words and what roles they can take then nothing will happen except the return of an error message. This is no different than any computer language, of course. What I think bothers me is that the cheerleaders always seem to believe, or at least pretend, otherwise.
Maybe it’s just that the tutorials never seem to clearly state what’s a piece of built-in magic that I’ll learn about later, what’s something that I’m building myself, or whatever. I mean, look partway through Jeff’s Django piece. I don’t mean to pick on Jeff, because he’s not doing anything worse or even different from the other stuff I’ve read; it’s just the one I happened to read most recently. Anyway, he says, and I quote:
These four lines create a very pretty admin area…. with appropriate entry fields for all of your fields. The “pub_date” field will automatically get a pop-up calendar for choosing a date. The “enable_comments” field automatically knows to use radio buttons for its interface. The “lead_image” field will be a browser-based upload tool. Et-cetera. Without doing a thing, you’ll get an admin interface the likes of this…
That whole interface just magically happens? How and why? Is it part of the Django core? Why? Is it useful for other stuff besides what we’re doing here? How? Did all this happen based on the class I created, or the variables I defined, or the values I gave them? How can I tell? Where can I find a list of the magic things? How can I re-use them; or, put another way, how far will the magic things stretch?
I feel like there’s some very basic, fundamental, obvious thing that I’m missing, but I don’t even have the necessary level of knowledge to frame the right question. Or questions. See? I don’t even know how little I know. Is it that I spent too much time doing old-style programming, and so I’m too suspicious of anything I didn’t write myself? (In which case you’d think I’d be an assembly-language kind of guy, but I’m not. At all.) Is it that for years I taught myself programming languages using reference manuals, so I need that kind of function listing before my mind will start to absorb a new language? Is it just that I’m too old now and my mind isn’t sufficiently elastic to take in radically new concepts?
Basically, my nose is telling me that I’m up a putrescent watercourse and I lack a means of locomotion. Maybe I’m not alone there, but sometimes it sure seems like it.
Comments (117)
I also don’t get the frameworks: I can almost always create the same functionality without the framework in less code, and therefore for interpreted languages, quicker.
I completely agree: I read a Ruby on Rails tutorial once, myself, and I was left with a complete lack of understanding of how everything was done. Then I read a Ruby tutorial and I thought: “Screw this Rails stuff.”
I confess I still haven’t really gotten much use out of Ruby, but at least I found it—or rather material written about it—much easier to understand than Rails.
Same here, i never get any of these frameworks introductions either…
I agree completely! I don’t particularly like such frameworks either. I don’t want a script/program that will magically do things for me, I want systems that let me do what I want, not what someone I don’t know thinks I might want, but usually don’t.
That’s precisely why I don’t particularly like Ruby on Rails. It tries to do too much behind the scenes without letting me know why or how it’s doing it, and then I have to spend even more time trying to work out how to override the mistakes.
I attempted to learn ruby on rails once and, while it was very quick and easy to set up and have it output a functional page, it felt like I didn’t have as much control over it as I do with other languages, simply because, when it all boils down, I basically did nothing. At least, I certainly didn’t write any of the HTML it output for me.
I always feel the same way! Online tutorials never seem to help that much for programming. Books help me much more. I looked up some tutorials for Ruby on Rails and it was just jibberish to me but after buying a book it all became a lot easier.
My other problem is that I like to know how and why something is done. It’s not enough to just be told it “magically” happens. I want to know the details and online tutorials seem to be there to show you how easy things are not how they work. Books can and do go into the details about how and why – with around 400 pages you would hope to get more from a 3 page tutorial I guess.
Maybe you’re just like me and it’s difficult to grasp something unless you know the how and why of it all?
I agree. I’m 18 and past my use-by date, it seems. Meh! I’ll go back to my boring markup and stick with my medicore coding skills, and eventually wind up teaching secondary English. Weird for a geek, but ah well…
Maybe it is an age thing. I am with you about the use of Frameworks. Although the argument about not needing to re-invent the wheel, does hold true, like yourself I prefer to have entire control and understanding of every element of the app.
PS with respect to Clipper
I was Winter 85, Autumn 86, Summer ’87 through to 5.2 !!!
I, too, have these same thoughts. Many times when working on something new I go looking for the answer. I usually find others with the same problem, but the only answer they get is “Read the Fine Manual.” Well, I’ve read the “manual” and there is nothing in it. Please someone tell me where I can find a decent “manual”.
I think perhaps there’s a natural watershed moment that people get to after spending all day, every day programming the same sort of tasks. The first thing you notice is that life just got really tedious because you’re spending most of your time building forms and doing validation and handling the input from the form to pass of to some class or other to process. Isn’t this what computers are supposed to be really good at – performing monotonous and boring tasks?
So you start poking around with Ruby on Rails or Django or favourite-framework-here and the reaction isn’t “Hey, I don’t know how it just did that! Grr! Evil!”, but more of “Thank heavens it JUST DID THAT and I didn’t have to think about it!”.
Sure, you have to learn some bits and bobs and subscribe to a few conventions, but the trade off is that you get the boring part of your job done for you, leaving you to work on the parts you got hired for in the first place. The stuff you’re good at. The stuff you enjoy.
So I don’t think any of these frameworks can make much sense until you feel the pain. You need to know the sickness before the cure becomes appropriate. If you don’t feel the pain at the moment, no point trying to solve a problem you don’t have.
Almost makes one long for a CMS that doesn’t need a database or scripting language. :-) You know a “framework” where you take an XHTML page and then insert simple variables where you want stuff.
Frameworks only begin to payoff when you don’t have to refer to the docs at every turn; short tutorials can’t get you to that point. Harder than learning one is judging whether or not it will improve your work without having used it, but generally server-side FWs are a Good Thing for security, rapid development and maintainability. It’s sure nice to be able to upgrade WordPress once other people have had to deal with the bugs/security breaches. Shudder to think how many hand-crafted apps we’ve left out there that are likely much harder to patch once the bugs are uncovered.
Sometimes I think the Rails “cool kids” get off on the lack of [good] documentation. Like it makes them part of a club to have hacked their way to Ruby nirvana. Don’t get me wrong. I absosmurfin’lutely love both Ruby and Rails. If you cut past all the hype Ruby is a wonderfully rich and pretty logical language. It’s just that the Rails “community” seems to me a bit excessively snobby and a hair obscure when it comes to helping others get things done. YMMV
Same problem and I’m 28. I don’t believe these things are created by people that are younger than I am, but I do believe a lot of these people lost grip with the essence of programming… getting something done…
(Design patterns???)
Same problem, and I’m 26! Do I win?
I feel like a curmudgeon sometimes, but I don’t necessarily think that’s a bad thing. So far I haven’t found anything the Ruby on Rails or Ajax or what-have-you advocates tell me I must use their language to do that can’t be accomplished with my old friends PHP, MySQL, and (if absolutely necessary) DHTML.
I’ve been using Cake for php (I didn’t want to learn another language, and none of my hosts support rails or python, anyway). I love it, but I can definitely understand how you feel. I already know php, but now I’m having to learn cake. In a lot of ways, it’s like learning, if not a new language, then a new way of writing/thinking. None of the frameworks are perfect, and none of them are as easy (while you are learning them) as they say. Once you learn how everything works, they’re great.
Some things you just have to take on faith. It just works. Don’t ask “Where did this Django admin interface come from, and why is it here?” Just accept it. One of my friends likes to say, “I could explain it to you, but you wouldn’t understand it . . .” Right or wrong, that seems to be the attitude of most of the frameworks (at least for beginners).
I know exactly what you’re talking about. In fact experienced the same troubles when starting with Rails. I don’t think Rails sucks or doesn’t ‘deliver’. In fact I think it’s very nice. However, it takes a skilled programmer to get the most out of it. In addition to that, one will have to do some serious studying on the Ruby language, which is what I’m doing right now.
The hype screencasts and tutorials are extremely misleading. They tend to show the one or two things that can really be done ‘automagically’ but as soon as you try something that wasn’t demonstrated in those you’re confronted with the fact that you still need to write code. I do believe the frameworks are beneficial in terms of shortening development time. I also believe things like ActiveRecord take away a lot of boring ‘plumbing code’ but in the end… It still takes blood, sweat and tears to build a good web app and no framework is gonna change that.
One vote the other way – I love frameworks.
Wherever possible, I try to use CakePHP for new projects, and if I’m lucky enough to have control over the server, I’ll use Ruby on Rails. Why? Because the monotonous, error prone stuff is done.
The less code you have to unit test, the less chance you have of a bug popping up.
Of course frameworks aren’t a silver bullet, but aynthing that speeds up development and leaves less room for error, I’m all for.
But, I don’t think frameworks should be a new coders introduction to a language – as you say, to much stuff is done for you, and often it is better to find out what is happening under the hood. But for experienced coders who just need it done – they are great.
I know this isn’t the point, but I can’t help answering the specific questions about the “magical” Django admin interface:
Q: That whole interface just magically happens? How and why?
A: It’s not actually “magic”, it’s built from introspection of the model class; data types are mapped to HTML form elements. The answer to “why” is “because Jeff installed the admin application that comes with Django, and put an inner ‘Admin’ class in his model”.
Q: Is it part of the Django core? Why?
A: It’s bundled with Django, but isn’t installed by default. This is because it’s useful, but at the same time not everyone wants or needs it, and so not everyone should be forced to install it just to use Django.
Q: Is it useful for other stuff besides what we”re doing here? How?
A: It can be, but I’ve seen people try to shoehorn things into the Django admin application that don’t really belong there. The admin app is good for site administration (managing content objects, users and permissions), but doesn’t try to be good at anything else.
Q: Did all this happen based on the class I created, or the variables I defined, or the values I gave them?
A: From the model class. Going beyond the field-type introspection, the optional inner “Admin” class indicates that an admin interface should be provided for the model, and has options which specify how that interface will work.
Q: How can I tell?
A: By reading the documentation and reading the code. Django’s codebase is pretty “view source” friendly ;)
Q: Where can I find a list of the magic things?
A: Good question, considering that a branch called “magic-removal” just merged to trunk (though it was concerned with removing some much deeper magic in Django). The documentation is a good start, and there’s a guy doing automated API reference stuff using epydoc (see here for a version based on the recently-merged branch).
Q: How can I re-use them; or, put another way, how far will the magic things stretch?
A: Django doesn’t aim to be one-size-fits-all; personally, I think it hits the 80/20 sweet spot pretty closely, and shouldn’t try to go too far beyond that (standard disclaimer: I work for the company which originally developed Django, but I did not work here while that original development was taking place — Django had already been public for a while when I was hired on, and my liking for it was a big factor in taking the job).
As to the broader issues here, well, I think frameworks are great for some things. I also think they’re overkill for some other things, and not enough for yet other things. There’s nothing radically new in Rails or Django or any of the other “new frameworks” — the MVC architecture has been kicking around for a while, ORM isn’t a new concept, etc. What is new, what’s driving all this sudden interest, is something that’s a little harder to pin down, and I’m still working on the pinning.
Next question? ;)
I think things such as Ruby on Rails, and the “me too!” CakePHP, are intended for the MSVC type programmer. The guy who knows how to get his project started by using a “wizard.” Those of us that prefer structured programming, or just getting things done, aren’t too keen on frameworks. I do see how something like Rails or Cake could be useful, but not for me.
Well, I was at that point. I despised OOP, I thought frameworks were for wusses, I figured that manly men (and women) wrote their own code. I just didn’t get it.
Now, don’t get me wrong, I’m not a frameworkist or anything, but I’ve been having some fun with CakePHP of late. Yeah, it’s a framework, and yeah, it has conventions that need to be respected, but it also has a great support system. Between the IRC, the google group, the wiki, and the site itself, the answers to many tasks are pretty easily found.
The key advantage to frameworks is that development time is cut WAAAAY down – the menial labor is done for you. So long as you trust the team who built the framework.
Well,i’ve been trying out rails lately and am onto my 3rd rails powered site, so coming from a PHP background here’s my insight.
For adding a tiny bit of dynamic content, they are just not worth it.
Basically, getting the most out of a Framework (like Rails) requires remembering a lot of short commands that then do a bunch of cool stuff for you (e.g. pagination).
It is still necesssary to know how to do stuff yourself, but the thing is, when you want to you can. Just code it in Ruby.
Rails is not particuarly straight forward, there is quite a bit to learn, and of course it’s more frustrating and tempting to go back to just doing it yourself when you start out. But eventually it becomes (or should become if the framework is any good) worth it.
For example, example, how many lines of PHP would it take to establish a DB connection, find a row matching a given field to a parameter and save that result (as a really easy to use object too!) 3?… 5?… I reckon at least 3 even if you’d saved the DB connection as an include, plus you need to write SQL and remember to close the connection.
In Ruby on Rails? 1
@myobject = find_by_columnName(params[:id])
But, the problem is you have to learn that there is functionality to do the find_by_columnName (where columnName is the name of a column in the database) before you can use it (you also need to know where to put it!).
Anyway, for medium/larger data driven sites I think frameworks are pretty handy. But you do have to be prepared to put some effort in learning the framework, much like when you decide to learn a new [programming] language.
Frameworks are not a tool for non-programmers to immediately be able to ouptut a polished, fully functional web application, but as Drew mentioned, they perform a very important role for programmers to eliminate recreating the same functionality over and over again.
If they are able to help a non-programmer get started, that’s great, but I don’t really feel like that is their function.
The other thing I like specifically about rails that is almost relevant to this topic is that it removes the process flow away from the design almost completely. I know this is almost possible with coding by hand, but the MVC structure takes it a step beyond. The designer stays away from the if/else clauses and the programmer stays away from the layout and doesn’t have to remember if he should put his content in a div and remember to close it …..
I would never pretend that building a Django app isn’t programming. it is. But, Django (and presumably Rails too, though I haven’t used it), does do most of the hard work for me. Forgive me for being a “cheerleader,” but it really does. If you (or anyone else) thinks for one second I could have built my new personal site in straight Python, PHP, or Ruby, without a framework to do the dirty work, you’re crazy. I wouldn’t have stood a chance.
I think all of these questions are answered in detail on the official Django website. My goal was the write a quick summary of how I was able to use Django to get my site up and running, not to write the definitive Django resource. I don’t even call it a “tutorial,” as I most definitely brushed over important steps. I wouldn’t expect someone to actually be able to get a Django app running from reading my piece alone. The goal was to get people interested, not hold their hand (that’s what the poll tutorial on the official site is for. My apologies if my piece seemed to be a step-by-step tutorial. It’s not, at all.
But, to attempt to answer these:
– I wouldn’t say the admin interface “magically” happens. It ‘s just a program that looks at your data models and creates the appropriate forms and fields and validation routines accordingly. It’s not magic at all, but it is a huge timesaver.
– Yes, it’s part of Django core. Officially, the administrative interface is an add-on application, but it’s one that comes bundled with Django (so, as far as I’m concerned, that makes it “core”). In addition to the administrative interface, there is also a bundled application that provides commenting functionality on any type of content, a bundled app that makes feed syndication incredibly simple, and a few others.
– Why? Because writing administrative interfaces is a boring, monotonous task that you have to do for every web single application you’ll ever build. Django’s goal is to take care of those things for you.
Here’s an example of why the built-in admin tool is awesome. At the newspaper company I work for, we often need web-based database to support stories, like (see this one. One of our programmers, Matt found out that database was needed a few hours before the deadline for the story. He was able to define his models in less than 20 minutes and get the Django admin interface available for that database. Then, the reporter (or maybe a producer) was able to go into the admin interface and enter all the salary data while Matt wrote the views and templates. Total development time: an hour-ish. If Matt had to build web-based forms for entering data, complete with validation and security, there’s no way that story would have made deadline. The admin interface let Matt ignore the tedious, boring stuff, and focus on what was really important: how the data was going to be presented to the end users and how it would support the story.
– Actually, the admin interface doesn’t happen when you creates your classes. t happens when you “install” your app after making the classes. You run a single command “manage.py install appname” and Django runs SQL against your database in the background to set up the database (which the admin interface is pointed at). This is something I skipped over in my piece (because it’s not a tutorial). Perhaps I shouldn’t have.
– I guess I’m not sure what you mean with “How can I tell?”
– The official Django site pretty much covers all the “magic” things (although they don’t really like the word “magic” around there). :)
– You can use the administrative interface for any app you create in Django. You can turn it on or off for any app. You can even let Django inspect a legacy database and use Django’s administrative interface against a database you already have.
Perhaps that’s exactly it. Does it make you feel better that Simon (whom you’ve linked) was one of the co-creators of Django? :)
Seriously, I know what you mean. Things magically happening is kind of scary, if you don’t understand how or why they’re happening. It took me a bit of playing with Django before I started to “get it.” In the interim, knowing that Django was built by some of the smartest people in the known world got me through.
I’m sure frameworks aren’t for everyone. But, they’re obviously working quite well for a lot of people right now. There’s simply no denying they allow you to write less code in less time and leave you to focus on the user experience, which is what I am truly passionate about. If you’d rather spend orders of magnitude more time programming, be my guest. But I don’t want to, nor do I have any delusions that I even could if I did want to.
Thanks a lot for your interest in the article, Eric. :)
This is an extremely important point that can’t be overstated. Django, like Rails, doesn’t prevent you from writing applications directly in Python. If you find something the framework doesn’t cover, you can still write it in Python. You can mix-and-match, too. For example, for my site, the flickr and ma.gnolia importer scripts I wrote are straight Python. Nothing Django about them. But, the views and templates for those apps are Django, and I can manage the contents in Django’s admin interface.
But the thing is, Eric (and most of us here, I assume) isn’t a beginner. Explain it to him, and he most likely would understand. I think ideally a framework should be equally accessible to beginners and power users alike.
For the record, I don’t think you should just take it on faith. I think you should strive to understand how and why it works. But, in order to do that, you’re going to have to play with the framework of your choice. You’re not going to fully understand it until you dive in, just like CSS or anything else. So, take it on faifth just long enough to give yourself a chance to understand it.
Or, if you really, really want a perfect explanation before you download and try Django or Rails or whatever — talk to someone who can really explain it all to you. That’s not me. But, it is Simon. :)
Frameworks can be very useful. Their usefulness generally increases with use, i.e. if you have a need for a tool, and will use that tool on a regular basis, then it is easier to use the tool than make your own.
On the flip side however, if you don’t use it regularly then you forget and they make life much harder.
Image writing a client’s site using Ruby On Rails then spending the next six months on a project that the client wants written in VB.Net. When the first client want an upgrade you might find it takes double the time, at least. If, on the other hand you can code all sites in Rails then chances are you will find it both quick and easy.
What I dislike is that when they try to take the work out of something you invariably find you want to do something very slightly different. Not different enough to look for a separate function, but different enough to get endlessly frustrated that the existing function doesn’t do what it obviously (to you) should.
I’m 22 years old, and I have the same apprehensions about frameworks. (Sorry Amber, I guess that makes me the winner?) I grew up learning dead and soon-to-be-dead languages, which I suspect is what puts me in the same boat as the rest of you folks. I started learning Visual Basic when it was at version 4 and progressed through to version 6; the .NET revolution left me out in the cold. I started learning HTML in the version 2 days and progressed throught to version 3 when it came out. I’ve managed to progress with it all the way through to XHTML 1.1 and I’ve been following XHTML 2.0, but it was a ten-year process and I still struggle with CSS positioning. In my post-secondary years I learned Ada95 (the 95 indicates the year it was written), C (but not C++), and Java.
I wish that I could say books helped me, but I got burned pretty badly by some very poorly-written books. It’s only been the past five years or so that some really awesome books have been published (or so I’ve been told, haven’t been able to buy any of them yet).
When I first heard about Ruby on Rails, CakePHP, and other frameworks that are emerging, I see that there are some major benefits, though I don’t really feel I know specifically what they are. I have far more experience with ASP than PHP, so quite often again I feel left out in the cold. I definitely prefer to be coding in PHP, but at work I don’t have the ability to make that choice because it would mean rewriting five years worth of code. All my PHP experience comes from dabbling around on evenings and weekends, and I’m still just learning what in my opinion is basic stuff (yesterday I learned some more string functions). But because I’m an experienced programmer in other languages, I feel like I’m in this odd state of limbo: not a beginner, but also not anything more than a beginner. I’m also in a state of limbo between procedural programming and object-oriented programming. When I was first learning Java I grew to despite OOP. I’ve started to see advantages here and there, but I don’t want the bloated baggage OOP comes with.
I’m definitely interested in learning these new frameworks, but what I’d really like to see are some tutorials on how the frameworks were built. I think that going through the process of building parts of a framework would give better insight into how the framework works, making it easier to jump in and use the framework as well as apply some of the techniques in other languages.
Eric, would it be possible to know why every single article before this one seems to be littered with css-hidden link spam? Some of them just showed up as updated articles in bloglines too…
I think part of the reason you get so much of this “cheerleading” from non-programmers about frameworks is because every designer secretly wants to be a programmer.
Web designers have been using these prepackaged tools for years and hacking some template code here or copying and pasting some PHP there and praying it works. Every now and then we start to think “I could do this”, but we dive in and try to “learn programming” and it just doesn’t work, because we’re going at it the wrong way and it doesn’t make sense to our brains.
Frameworks are like a programming erector set for designers. The barriers to entry and the cost of failure are both low. If you can build what you want to build with the pieces in the box, you’re golden.
The “oh shit” moment for designers with frameworks is realizing that we can actually build something that doesn’t fall apart AND doesn’t feel like matchsticks and airplane glue duct-taped to the top of a Hot Wheels car.
We open up the box, stick some pieces together and go “WOW THIS IS AWESOME!” A construction engineer would look at what we made and think it was ridiculously childish and limited. “You’ll never build a skyscraper with that,” they’ll say.
But that’s the point. We never wanted to build a skyscraper, and we never wanted to be engineers. We don’t know anything about laying foundations, or construction codes, or structural integrity, and we don’t want to. We love frameworks because we don’t have to.
Frameworks are nice for real programmers because they cut out a lot of the routine, boring or complicated parts of programming that they don’t want to deal with. As a side affect, they’re really appealing to designers because they cut out a lot of the parts of programming that they don’t know HOW to deal with.
So that’s why we get so damn excited. We’ve got a new toy to play with.
The problem may be irreversible brain damage. ;) Seriously, though:
Experience is non-portable with Ruby. It’s so different from other languages that your experience with them will not help you, and experience with Ruby cannot help you with other languages.
It doesn’t help that most Ruby people are cheerleaders and fanboys. (Just start an argument about Python with one–you don’t even really need to know anything about either language–and watch the fireworks.)
Magic is bad. Magic is bad because you have no way of knowing if it was your magic words or the magic itself that went haywire.
If you don’t understand how something works, yes, it’s magical. But that doesn’t mean it has to be. Some C++ as an example:
cout << "My favorite number is" << 5 << "!" << endl;This prints “My favorite number is 5!\n”. This statement is completely magical until you learn about operator overloading, which for some reason is tucked away in a corner late in the course or book, even though it’s not a particularly difficult concept, and in spite of casting magic spells with it from day one.
I (obviously) don’t like magic, which is why I avoid Rails and gravitate toward Django: aside from finding it inherently less magical, I know Python. I know why things happen, and when I get an error, I can dig through the stack trace and see if it’s my problem or theirs.
The more you know, the less magical something is.
As for Cake? PHP is awful for anything large-scale (or of nearly any scale, really) and I wouldn’t even bother trying to understand it.
I’m 14, so I’m well in the lead.
I learnt what programming languages I know by going out and writing things I want in them – not using other people’s code (such as frameworks) to do so. I still feel as if I can do what I want with less overhead without a framework (as they typically will have a heckuva lot I don’t need). I personally have a whole lot of classes, each in their own SVN repository, which each does a single, and very specific thing. They are also completely modular, allowing me to simply plug them into what I’m writing with minimal effort.
I think what all these frameworks need are *lots* of good examples which can be copy + pasted and then played around with, and a *really* clear API reference to accompany these.
I find the problem with such frameworks is ultimately that they basically end up being abstraction upon abstraction, such that one loses actual understanding of what’s going on behind the scenes, which helps foster actual understanding. APIs are useful, but once there’s too much abstraction, it’s just like a maze to understand what’s going on.
In this regard, Joel Spolsky explains what could be called the ‘death of programming’:
http://www.joelonsoftware.com/articles/LordPalmerston.html
“the law of leaky abstractions means that even as they built the abstractions that are supposed to make programming easier, the sheer amount of stuff you have to know to be a great programmer is expanding all the time.
[…]
You might think that basic programming, say, your expert C++ skills, are the 90% and all the APIs are the 10% fluff you can catch up on in a few weeks. To these people I humbly suggest: times have changed. The ratio has reversed.
Very few people get to work on low level C algorithms that just move bytes around any more. Most of us spend all our time these days calling APIs, not moving bytes.”
I think, Eric, that you understand frameworks perfectly.
Unfortunately you’re too busy trying to get things working than shoehorning your brain into someone else’s head just to look cool.
Rails is “opinionated”, apparently. If I don’t agree with David’s opinions, or want to do something he hasn’t thought of before, or want to do anything remotely complex with databases, I’m SOL. In RoR’s case, that’s fair enough because it’s not like they didn’t warn me.
Cake, on the other hand, takes it to new levels. Not only do they not provide documentation which succeeds in not mixing up several versions in the same page, but they then add to the insult by claiming the opposite. You’ve seen an example above. And woe betide the new person who asks a question which the project leader believes was answered in some comment in one of the half-dozen possible places to look – you won’t get a pointer, you’ll get publicly flamed.
(Note: An autogenerated function list with no actual descriptive text in it is not documentation. “What” is nothing without “When”, “How”, and “Why”.)
Some of us need to get stuff done to earn a living. If some new tool is so candy-ass that it has no docs, then why the hell should I care how cool its author thinks it is?
Django, on the other hand, looks like it’d be entirely logical. It’s simply leveraging the way Python works and giving you a nifty new library to include. Not knowing enough Python to get by, however, it’s not something I’m able to use.
Something which is logical to me for web work is Drupal. It’s not built with PHP classes, but procedurally. But it allows me to add new functionality as modules which are plugged in through an entirely clean method (I drop my new stuff into the file system in the right place), and — most importantly of all — it fully documents every single hook and function on an expansive site which correctly seperates each version of Drupal from every other, backed up with some walkthroughs in the main site’s handbooks.
You only need to look at the sheer volume of contributed modules to see what some decent docs bring to a project. So I’m spoiled now, and I’ll need some seriously good API documentation to move on from this particular Swiss Army Knife.
Plus, ya know, it all runs under Apache without any exra futzing. Mucking about with different web servers is something I’ll think about at deployment. It’s not something which should be a prerequisite to being able to try it out in the first place.
[Wow, that was longer than I expected.]
I don’t get the whole point behind frameworks either; it’s possibly because I don’t understand all about classes but I also get frustrated when someone says “magical natural language without code” and what you actually have to do is to learn yet another language. But oh well, being 19 I suppose I have a lot of years ahead to invest in understanding things beyond my skills.
By the way, (terribly sorry for double-posting) but that fish-y image on the header is amazing! Just keep that one!
That’s essentially how I feel any time I decide to do something in Linux… seems like an awesome idea at first, everyone talks up the latest linux-based buzzword (for example, mythtv), and then I actually dive in to it… and all hell breaks loose. So I check out the “insanely dumbed down tutorial that my mom read and now she’s a |33+ hax0r” type tutorials/faq/wikis/etc, and all I get out of it is a sense of smugness and vague references to the item I really need, but more in a “only an idiot wouldn’t know this” reference, lacking any real substance.
Eric – I must say I am in agreement with you on MANY of the points you made. There are good and bad to every framework – at least from what I had ‘surface’ tested. By that, I mean I went through tutorials on some of them. I have tested CAKE, Zend, and Symfony. They are nice, but all lack at different levels. I don’t have the time to learn an entire framework – I need to get things done now.
My solution has been to build my own framework. Where I work, we have many custom needs and the website needs to tie into several different areas. NONE of the above frameworks have worked for me. The big area that I found most to be lacking was the database. When dealing with normalized tables – these frameworks are weak. They expect de-normalized tables and duplication of data.
I have been programming PHP for several years now and love it. I have delt with a site that was completely procedural and found it HORRIBLE to work with (especially with NO documentation). Organizing the frameworks for our NEEDS has helped the most. This also helps against code bloat, where we dont need to include elements we will never use.
Two things:
1. I’ve never read anyone say that writing an app, in Django anyway, is “magical natural language without code.” Where are you guys getting this? I certainly didn’t say it in my post.
2. I hate to be an asshole type, but most of the questions Eric had in the original post (again, about Django anyway), could have been answered with a short look at the official documentation. I know it’s harsh to say “RTFM,” but…
Did anyone here understand CSS the first time someone mentioned it to you? PHP? I didn’t expect you to get Django after reading one short blog post about how I used it. If you want to understand it (or any framework), read the documentation, dive in, and get your hands dirty.
If the fanboys are annoying, skip the fanboys and go straight to the horse’s mouth. The official Django website is chock-full of well-written documentation, including everything from hand-holding tutorials to in depth API references.
As an experienced programmer, I resent it when people get snarky and tell me to RTFM. “The manual” isn’t always the easiest or clearest thing to read. That’s why I prefer books written by third parties who are very familiar with the topic, chock full of real-world examples and written in ordinary English.
Amber-
I totally understand. I hate that too. Which is why I said, “I hate to be an asshole type” and “I know it’s harsh to say…”
But the fact remains, you can’t really expect to learn this stuff by osmosis, can you? At some point, you’re going to have to read the documentation if you want to understand it. That sucks, but it is the way it is. If there are no “books written by third parties who are very familiar with the topic, chock full of real-world examples,” what else are you going to do?
For the record, a Django book is being published by Apress (but isn’t available yet).
The problem is overwhelming complexity. Shun it everywhere you can.
I would be delighted with frameworks and abstractions if I could actually understand them. But today we have a separate script language or what-have-you for every purpose — each with thousands of barely-documented or illegibly-documented methods. It’s an absolute wonder anything works at all on a computer.
Starting with limited programming experience and a manual, I wrote my first Pascal program about 20 years ago. It was a sophisticated communications and control package about 1700 lines long. It even used pointers–a big deal for me at the time. It’s still in daily service, and in that time only two errors in that program have ever surfaced.
I just tried to use the latest and greatest programming language, which, it is claimed, will simplify your life and solve all known programming difficulties (well, almost). I already knew the language, more or less. Nevertheless, my first real application simply exploded — I have no idea why. The libraries are so complicated that after two weeks of this, I haven’t actually figured out how to read a character from the keyboard!
Ruby is far from “so different from other languages”. You cite Python, well apart from a few mostly syntactic tricks, Python and Ruby are extremely close in the end, even though most fans of one or the other wouldn’t be caught dead saying that.
Experience in Ruby does help and is portable to other languages, as is experience with other languages. Ruby isn’t that original you know, in fact I don’t think it has anything truely original and innovative. What it has is a good mix of things it’s built upon, taken from other older languages.
What Matz did here was take Perl, remove the cruft, the bad things, everything that makes Perl a write-only language, and mix in some stuff from Smalltalk (quite a lot of Smalltalk in fact) and some other languages. And he did it well.
But Ruby is not an alien by far, it’s not really original, and it’s really not that different.
Purely functional languages are different (Haskell, OCaml or SML), even non-pure functional languages (Common Lisp and Smalltalk) are different, innovative languages (Smalltalk, Curry, …) are or used to be different.
Ruby isn’t, it does have interresting syntax and stuff, but no really original features, or syntax. It does expand the way you think about programming, but it won’t radically change the way you see programming as learning Lisp or Haskell can.
Now don’t misunderstand me, switching from FORTRAN or Cobol or C or C++ or PHP or Java to Ruby is more than likely a big shock, but saying that experience is not portable to or from ruby and that it’s “so different from other languages” is just plain wrong.
i understand what you say, but I think it’s nothing more than the first reaction to something you don’t inderstand (yet). Of course it’s not enough to do a smalll tutorial to “get” frameworks. You do need to understand about OOP principles and, specially, about Design Patterns (you gotta read about MVC for starters). Frameworks are suppossed to make things easier for experienced programmers (don’t get me wrong, I’ve got all of your books on CSS). Luckily, with all the info around you don’t really need to go to school for that.
Once you understand what a controller is, and how it is related to models and views, it becames so obvious that you wonder how could you write code whithout a framework before.
It is also not true that frameworks “limit flexibility” (a complaint common among PHP coders). Inside your models and controllers you can still do almost anything you want with your app. Frameworks are just the logic step to good coding practices like modularity and orthogonality.
As with Football, you gotta know the rules to play it.
I think the trouble with frameworks (a.k.a. platform) is that they are the single hardest thing to write well. Much like a good (or bad) UI design can make (or break) a product, when you’re talking a framework, platform or API, the public interface can make or break it.
Since Javascript frameworks are new for example, everyone’s giving their kick at the can, hoping that everyone will see the world they will, and that their way will be chosen as the new ‘standard’ way of coding. Trouble is, most of them don’t have the breadth (or length) of experience required to design something as challenging as a framework. So we get a lot of crap. Sometimes particular elements of the thing they design is ok, but as a whole, still needs a lot of work.
We’re probably a good 5 to 7 years away from having a really great Javascript framework. It’ll require a ton of experimentation and lessons learned before we figure out one that works for most people.
Then once we have it, it will need to be well documented (inside and out / implementation and public interfaces) so it can be adopted by us regular folk.
A good framework can multiply your productivity, but I haven’t seen many on the web yet. It’s still the wild-wild-west.
Poor Eric, they’re scaring you with all that. Stick to your procedural coding that works for inline and page centric kind of work. After all c’mon man you wouldn’t need any of that. You’re the CSS wizard ain’t things becoming specializing more and more for web? Well, that’s a good sign, and a start for web-jobs recognition.
Eric,
the main reason why a lot of the frameworks are so hard to understand properly is because they all offer way too much magic. In my opinion, that is the totally wrong approach, since you can never get it 100% right, and a framework must get out of your way so you can concentrate on the important matters, instead of confusing you with thousands of one-line helper methods that do a very specific thing but leave you SOL when you try to do something with them the authors didn’t think of.
I recently wrote two postings regarding these framework “philosophies”, check them out on my blog.
My main problem with frameworks comes from the other side – I can use them well enough to build the basics (although it’ll always be quicker to write something yourself than to grok a new framework), but as soon as you’re trying to do something new, something custom-built instead of mass-market assembled, something actually innovative and unanticipated by the hammer factory factory builders, you’re doomed. You’ll have come so far with your app already that you’re left with the feeling of having no choice but to do it within the framework of the framework, and then you’re finding yourself reading the (invariably horribly – or plain simply not – documented) code that makes up the framework itself, and figuring out where to fix its bugs or extend it, and never ever is there an overall structure document available for the way the framework does what it does, and then three days after you finally extended the thing you come upon the next limitation or unanticipated consequence in this other bit of obscure framework code, and…
*takes a deep breath and thinks happy thoughts*
…but let’s not go there. :)
Of course, being 26 and having done real programming for nearly a decade, I’m probably just ruined for the shiny beacon that frameworks really are, and should never even _want_ think to of doing things that frameworks won’t enable me to do.
You must love the fact that Django just removed all the “magic” in the latest version, then! :)
@Sander: Interesting take. I can see how this applies to many frameworks. But (and I’m sincerely curious here, as someone who works side-by-side with Django lead developers every day) what exactly have you found that Django limits from you doing?
#9 hits it on the money… You can’t really develop an appreciation for frameworks unless you’ve repeated spent time dealing with the same problems frameworks take care of; Things like separation of converns vis-a-vis matters such as separation of data access/logic/display.
There are basic foundations that each software project will need, and frameworks do save you a lot of time when it comes to laying that foundation.
They also let you carry forward lessons learned and components built from one project to another.
In short, frameworks (any framework, be it RoR, or home grown) saves you from doing the same old stuff over and over again, and to truly appreciate them, you must have wasted time doing the same stuff over and over again :D
Jeff,
You’re right, if there aren’t any other books available, there’s no option but to read the documentation in all its scary glory. Guess I was just playing devil’s advocate!
Listen: HTTP architecture is request and response. The user press something on your webpage and the browser sends a request to the server, which in turn sends back a request to the browser to display. Any kind of web stuff you make has to be built on top of this limitation. Good MVC frameworks as Cake or RoR just put a class listening to your request (the controller) and another one to print the response back to the screen (the view). Those two instances (request – response) are a given in the web development world and there’s no way around them. inside the controller, the model or the view you can do whatever you want and whatever you used to do with procedural coding. Frameworks just lay the ground for you to place your code in the right places and enforce task separation, which is a good thing. I really don’t see how a good framework can keep you from doing complex stuff for the web.
I remember having – and I’m showing my age here – the same feeling with the newfangled 4GLs in the ’80s (Informix 4GL in this case). I had to write an application for a nationwide contractors association and was given the i4GL and a couple of weeks to come up with the goods.
As an experienced 3GL developer at the time, the most memorable feeling I got was something close to claustrophobia. The 4GL demanded I alter my way of thinking about the structure of the application to suit its (or its developer’s) methodology. This is somewhat frustrating and presents two major problems; firstly, you have to thoroughly learn the methodology and, secondly, you have to accept the methodology. You have a real fight on your hands if you feel you need to alter the given structure. If you don’t fancy “going with the flow” you need to put in some serious effort at a low level, often coding by exception. My answer was to capitulate and submit to the “look and feel” of the 4GL despite my reservations as to the aesthetics and usability it gave.
Some of the frameworks I’ve been exposed to lately give me similar feelings. There’s often a lot to learn about the structure before being able to casually create applications with the “advertised” ease and speed (although the tutorial example usually comes out beautifully!). Often the manuals and reference materials have either not been written, written with a particular problem set in mind, or are incomplete. Again, if you want to circumvent the framework you have to write a lot of hacky code to deal with the exceptions.
Ironically, I’ve written my own framework to simplify the handling of our web applications at work and have come up against similar problems when the scope of the work starts to stretch the framework. Suddenly, there’s a heap of low-level functionality that must be written to deal with a situation that wasn’t on the radar when the framework was first developed.
The key observation is that if the framework doesn’t exactly fit either your situation or your way of thinking then it may well be an implementation fraught with difficulty.
I know I’m beating the same drum over and over, but no one is giving me much of a response, so here goes again…
I (as someone who really hasn’t used most of the web frameworks — only Django) fail to see how this applies to Django. Whenever Django has not had the functionality I needed built-in, I’ve simply written a Python script, mooching off what Django does offer (like built-in database connectivity, for example).
Django in no way limits what you can do. If what you’re trying to do has been foreseen by the Django developers and they’ve given you an easy way out, great. If not, you just write straight Python. I fail to see how this can be a bad thing.
Isn’t this exactly the same as using any plug-in architecture for any piece of software? Isn’t it the same as using an Apache module? A photoshop plug-in? Something like sIFR?
Django is nothing more than a set of Python libraries that makes my life easier. I’ve never written a web application from the ground up before I discovered it. Isn’t that success worth something?
As my friend and co-worker said today after reading this thread, the low barrier not only to entry, but to success is a major win for the frameworks. I can build something very quickly and easily using only the built-in functionality that Django offers. That gets me and excited, and motivated to learn more. I’ll go a little farther with Django. And then a little farther. Eventually, I’ll hit a wall where Django won’t be able to do what I need it to do. But guess what? In the process of using Django, I’ve learned Python, if only by accident. Now, I can probably manage to write my way around the wall I’ve run into it. This may sound like fluff, but I’ve actually done it. I now understand the basics of Python, and never set out to learn it. On the flip side, if I’d had to start with nothing but an empty text file and Python syntax coloring, I’d have been totally lost.
Now, I understand that Django may be unique in that it as purely “Pythonic” as possible. Learning Django is learning Python, because Django doesn’t deviate from the beat practices set forth by Guido (Python’s creator) and the community. My understanding is that some frameworks (such as Rails) aim to be a domain specific language built on top of an existing programming language (such as Ruby). I can totally understand why some people may not like this, because it means if you’re ever without Rails (or you run into that wall where Rails can’t do what you want anymore), you don’t know Ruby enough to write your way around it (i.e. you’ve only learned Rails, and not Ruby).
If you’ve got the time, skill, and motivation to write all of your web apps from the ground up, and/or build your own web framework, that’s awesome. I don’t. Frameworks (specifically, Django), let me get shit done.
In the end, that’s all that really matters.
I think the real reason you get cheerleading from people like Croftie is that Croftie was actually a cheerleader in high school. Say what you want, but he’s grabbed more ass than Joe Clark.
Moving along, however…
Why no criticism of Javascript frameworks in this comment thread? Those are the real mysteries to me. 160k of code downloaded onto a client machine so you can make an XMLHTTP call look a little nicer? At least Rails, Django, and Cake have no impact on bandwidth. I’m waiting for someone to write a javascript framework that does 95% of what people generally need to do with it and is like 20k. Save the other 140k for the 1% of apps that actually need it.
Jesus, Mike. Does Inman tell you everything?!
Pingback ::
EstadoBeta » Archivo » ¿Los Frameworks apestan?
[…]
Eric Meyer (si, el mismo gurú de CSS) y Jonathan Snook publican casi en paralelo unos posts donde postulan la inutilidad de los frameworks de desarrollo com […]
I saw the largely hyped Ruby on Rails tutorial, but that just confused me further. But, I couldn’t get they ease of building the initial framework out of my head. So in the past three weeks I got the Pragmatic Programmers book, Agile Web Development with Rails (first edition, second edition forthcoming and would be worth waiting for, or pre-buying it and getting the pdf’s as they are released, it’s a cool way to get the book before you get the book) This book, IMO definitely holds your hand thru building a web app using the framework, then breaking out of the framework and customizing each part and tweaking for a production environment. The authors tell you right off the bat that rails is just a well-written framework to easily get an app off the ground and running smoothly. You must still yourself go in and tweak it to perfection. Last comment about the book, the authors have done an incredible job marking up and commenting the code. If a new coding convention or new thing is intruduced, there’s a sidenote present with a page number that refer’s back to the condensed ruby guide for exactly what it is and what it does. But the code is so easy to “read” for people with even a basic background in programming. (I only did a semester of Java and two semesters of C++ two/three years ago)
That’s my two cents.
-David
BTW, I am starting to build an app using RoR to allow parents to review (and later read about) locations (either with an address, or by clicking on a map) for it’s friendlyness and feature set that’s geared for tot’s and make’s life easier for the parents of said tots.
Mike: true for Mochikit, Dojo and the like (although you can view them as Interface widgets libraries). Prototype, though, is about 40K, and after compressing / eliminating white space it must be about 20K. I find most of its features welcome when it comes to developing complex javascript functionality.
Jeff: keep beating that drum.
See, frameworks are not just “collections of libraries”. they are good practices condensed for you into a nice development environment.
I’m glad I’m not the only one who had the same impression as Eric about frameworks. Perhaps the “brain damage” comment above nails it, as I grew up with BASIC, Pascal, Forth, COBOL, and frightening Atari versions of Assembly.
I find PHP and Python very intuitive and easy to use, but every time I’ve tried to learn a framework I’ve just become frustrated, started over, and cranked out a working site in plain old PHP. (Version 4.x, because I’m scared of version 5.)
That said, Django does look promising and I had several “aha” moments reading the documentation. I’m going to give it a serious chance. If that doesn’t work I’ll invent a version of BASIC for the web.
As for JavaScript frameworks, I’ve been impressed with Prototype, but even at 40K, it’s adding a lot of bloat for anything but a GMail-level JavaScript app.
I’ve had a lot of, erm, discussions with hard-core table-layout zealots where their arguments sounded not terribly dis-similar to some of the things you’ve said about frameworks. I could never have understood CSS without the “community” documentation and books (and blogs) by professionals. I think if we don’t have the stomach to dig into the code or spend what seems like forever scouring whatever akward documentation exists, then we are just not prepared to be early adopters of these technologies. Just like I needed people like you and Dave Shea to lead the way with CSS, I will need people like Jeff Croft to lead the way with Django (or 37Signals with Ruby on Rails, or whomever with CakePHP).
That being said, there sure are a butt load of frameworks, and more every day (or so it seems).
Sorry Dude. You’ve gone and gotten old.
We absorb languages in meta meta meta now and by 2007 they’ll be a forth meta. It’s not so bad, you can join us, but you have to let go of the past. Espavo!
Sincerely,
Abraham Linclon
It depends on the framework, it’s modularity and the limits it places on your own programming style. A light weight framework that’s modular and makes few demands is a good thing generally speaking, even heavy frameworks that don’t demand too much have definite uses (.NET for example). Provided I can have my cake and eat it I’m happy :)
But as soon as a framework starts demanding that it’s way is the “one true way” then I’m not interested (I have to, for my sins, write and maintain an Oracle Forms app… a development environment, framework and language written by a saddly finite number of monkeys…)
Pingback ::
Eric Meyer on Frameworks at Davide Bocci in…
[…]
Post di un dubbioso degli ambienti di sviluppo
[…]
@Jeff: Sorry, I haven’t had an occasion to use django in any real world projects yet. Much as I’d like it to be otherwise, I don’t usually determine the language I work with, and Python never gets chosen for me.
I’ll be sure to let you know if and when I do and run into its limitations though. :)
Ruby sux0rz – long live batch files!!!!!!!!
…no, I don’t get RoR either. :p
I’m currently trying to learn rails (have some decent php-knowledge and very basic knowledge of java since before). The first thing I did was to read Why’s poignant guide to ruby and some other ruby-guide.
At first I was really confused. And I mean really. But after started reading “Agile web development with rails” I started to understand that the biggest benefits of rails isnt scaffold, but rather the MVC, easy Ajax the the automatic database -> object mapping. At least for me it is.
Perhaps you should try SQL on Rails. It’s a lot more simple.
Pingback ::
Elliot Swan | My $.02 on frameworks
[…] raphy
My $.02 on frameworksMay 9, 2006
There’s been a lot of commotion lately over the subject of frameworks. You’ve most likel […]
You have to use it on an actual project to get it. Once you do you’ll realize that the hype is well deserved because it gets past the menial programming tasks that a database driven site requires. Websites that interact with DBs boil down to 3 things editing, delteing, and adding records to the database, and Rails gets you doing that very quickly. Where you want to go after that is up to you, but half the work is done and now all thats left is the fine tuning.
God Bless
Pingback ::
/* Undocumented Code */ » Blog Archive » I can’t figure it out, so it must suck…
[…] ure it out in a 20 min tutorial, so apparently he’s flumoxed. The hype is deserved, I promis you. If you haven’t given […]
I knew the post probably provoke some response, but wow!
I couldn’t possibly respond to everyone’s individual points, but I’d like to share what I’ve gotten out of it so far. You can tell me what I got wrong.
1. A framework is a way to make certain tasks easier. It can be thought of as a collection of libraries, though in actuality a good framework is both that and a formalization of best practices, condensed into an efficient syntax and approach.
2. More experienced programmers tend to dislike frameworks because they’d rather build their own code, or even their own frameworks, than trust someone else to have “done it right”. This is not universally true, of course.
3. Jeff Croft and Django got beat up on a lot, which is not what I was trying to cause but was probably inevitable given I highlighted Jeff’s article in my post. Sorry, Jeff! I should have anonymized my example.
As a result of all the comments, I think I’ve begun to understand what it is I didn’t understand about frameworks, though what people say in response to this comment will help me know if I’m right.
No, I remember Clipper too. Because you reminded me. I hate you!
Off to rinse my brain in sulphuric acid and morphine until the shuddering stops. (And then I’ll read the rest of the article.)
The understanding of a framework boils down to the understanding of the Model/View/Controller (MVC) architecture. Frameworks are generally easy to use after you understand MVC just because it saves you from having to spend time working on the tedious portions of a web application. ASP.NET would probably be the best framework to start with as it has the most direct binding between the three portions of MVC.
As far as Ruby on Rails, having picked it up recently and also having experience in most major frameworks/technologies, I’d have to say that it is a bit obscure. Rails’ implementation is quite different that most frameworks, but I like it. Ruby has to be the most obscure language I’ve ever come across. I don’t think that experience with any other language will help you with Ruby simply because it is so different (other than the general fundamentals of course). I’ve started to enjoy Ruby too though, there is quite alot of coding shortcuts. It’s not quite as powerful as PHP but its pretty fun to use.
“Jeff Croft and Django got beat up on a lot, which is not what I was trying to cause but was probably inevitable given I highlighted Jeff”s article in my post. Sorry, Jeff! I should have anonymized my example.”
No sweat, man. I can take it. :)
“More experienced programmers tend to dislike frameworks because they”d rather build their own code, or even their own frameworks, than trust someone else to have “done it right”.
This is probably accurate, but I have to question this line of thinking. If you don’t want to trust that Django or Rails got it right, why are you willing to trust that PHP or MySQL got it right? If you don’t trust that PHP or MySQL got it right, why are you willing to trust that the Linux OS you’re running them on got it right? If you don’t trust that Linux got it right, are you going to build your own OS instead? If you do build your own OS because you don’t trust that Linux got it right, are you going to build your own chip, too, because you don’t trust that Intel got it right?
One could also ask why you, Eric, are willing to use WordPress — aren’t you relying on someone else’s code here?
At some point, we’re ALL relying on someone else’s work to make our lives easier. It’s just a matter of where you choose to draw the line of abstraction.
Thank god I’m not the only one who feels like this!
This article is exactly how I feel about some of these new frameworks…spot on.
Seems Ruby on Rails is magic if that is all it needs to know what host/database/table and server system I’m using. I don’t think that example can be used to show how superior it is to any other language or framework.
Unless I’m missing a huge part of the syntax that is :)
In Ruby EVERYTHING is an object. Can you do this in PHP?
my_variable = "Hi, I am a string".myMethod()
Egil: that line of code is possible because Active Record, the ORM that Rails uses, is so cleverly designed that it takes the most out of class reflection and a few conventions, so it can “guess” database schema and info from your class names. Just adding a bit of cleverness to automate trivial things thanks to a powerful language. A framework.
Learning a framework is half the battle. With well documented frameworks ( like Yahoo!’s YUI frameworks ;) ) it makes it easier to dive right in and get things done faster. However I’m still a true believer that they can be dangerous for the average newbie because if something goes wrong, then you’re left in the dust without knowing how to do it without a framework.
How much experienced programmers are willing to depend on frameworks depends on a lot of things, so I think it’s misleading to make a blanket statement on this point. Virtually everyone creating a GUI app, for example, is going to rely on toolkits and frameworks, because there isn’t much reward in churning out your own. In the business domain where you want to be able to wire up different components easily together, middleware like JavaBeans or .NET is widely used. Although you can roll your own, it makes sense to use a freamework that is widely used, so that the bugs can be found and fixed. And in the blogging world, though some do like to create their own software, many are relying on third party packages. Sure, a homegrown solution would do exactly what you want it to do, but is it worth the time spent to develop it, which is time taken away from actually writing?
Take S5 as another example: perhaps framework is a bit high-falutin’ as a description, but it is a piece of base software that provides ways for people to hook in their desired behaviour. If you know the right syntax, it seems natural; if you don’t, then you may be wondering things like how does defining this element with this class cause that behaviour? I could develop my own version that I understand thoroughly, but is it worth the effort versus the benefit gained?
CakePHP was great! i love to use it. Simple, clean and many more.. but if u want to see a great cms interface (the latest web technology) visit the mooflex cms..
username : demo
password : demo
enjoy :)
>>In Ruby EVERYTHING is an object. Can you do this in PHP?
It’s a common misconception: should everything be an object?!
It should if it allows for greater power and flexibility, yes. Also, it provides for a more standardized interface to any kind of data (for instance, you can redefine the toString() method diferently for integers, arrays, hashes, etc. This is just great for debugging).
And I’ve been a PHP programmer for 6 years now :)
Yeah, i remember Clipper!
It was 16 years ago. Clipper 5.0 (It was more than dBase), and i have some books about Clipper. (In Dutch en English)
I think, “Don’t throw your roots away”
Pingback ::
Episode 12: YUI Library Discussion
[…] ive you a taste of the quality of what the others have to offer. In the News Eric Meyer is Flummoxed by […]
I agree with this post on that, frameworks that have to magic are confusing and I don’t use them until I have investigated there magic and understand how it works. So I read a lot of documentation and source code before I start using the framework.
I wish people would just give a scary framework a try before they decide it’s “bad”. If they don’t want to give it a try, you have no right to say it is bad or good.
Saying that “true programmers” don’t use frameworks is absurd.
Which looks more natural way to say:
for ($i = 0; $i
my bad..
Let’s try again, which looks more natural way to say:
for ($i = 0; $i<10; $i++) {
..something..
}
or:
10.times do
..something..
end
Ruby is not natural English, but it is much closer than PHP, Java, etc, and I’d argue that it is more intuitve..
And its example does not require entity escaping ;p
Hey Eric. Thanks for the useful CSS lessons I’ve learned from you!
The for-pay Rails documentation
Your questions are answered, your concerns are allayed, your brow is unfurled.
The thing I like about Ruby on Rails is that as an old assembly language guy, Rails does know how to “Get out of my way” when I need it to.
Eric, this happens because you approach writing the web backend as a sort of “necessary evil”, and there is some research involved if you want to understand how Rails works under the hood. If you want to enjoy using it, first do some vanilla Ruby. It’ll be times easier from there (especially because you will have the chance to learn why Ruby is so insanely cool – Rails is built on it but you don’t get to use it much). And if you want these frameworks to be of any use you have to be ready to embrace OOP.
Or, hell, if you hate webapps (or OOP, for that matter) just delegate or stick with your own tools if they get the job done better for you.
Well, IMHO it is no longer just about coding but designing a program.
Sure, there will always be the way to just glue some code pieces together and you’re done. But honestly, I don’t want to maintain such a program. If it works for you, fine – but for the person after you: Horror!
Modern software engineering requires more than just writing the correct code lines: It’s about common sense (e.g. Software Design Patterns), maintainability (no more “untouchable legacy systems”) and concentration on the main thing: implementing business logic and no longer dealing with deficiencies of certain programming languages.
NOTE: This is NOT a rant just against Ruby on Rails. I wouldn’t claim to “love it to death” or anything, but I think its no worse or better than any other so called frameworks out there. I use it as one of many cases symptomatic of open source products out there. Zope did it before and now Rails is going down the same arrogant path in the most ominous fashion.
— Frameworks are like manufactured boy bands —
Thesis:
When you can’t charge the “customers” for the product, you charge them for services. If the framework was so easy that they could pick it up and do it themselves, they wouldn’t be asking for consulting time now would they?
RANT:
Frameworks, IMO, are written these days as much to create an ecosystem as they are to create an “easy to use tool” for a given domain. This means there are problems/challenges from the inception. These challenges are magnified and amplified when the so called framework is an “opensource” one.
the cycle for opensource kinds goes something like this:
1. The creator creates or extracts the bits of helpful code and re-christens this bundle a ‘framework’. the reasons for this maybe manyfold:
(a) something to help other people
(b) something to have on the resume
(c) a desire for geeky fame (and eventual consulting fortune)
2. A 10 minute screencast is developed because most framework writers these days secretly look at rails with contempt and think that the runaway success of rails was based on David Hannsson’s slick screencast not the actual merits of the framework itself. (this is why now there are 10 minute blog tutorials for everything .. as if creating a blog was the most important computing problem facing humanity).
3. Groupies, sychphants and cheerleaders arrive at the scene looking for the next panacea in terms of creating their web site/application without doing a whole lot of work.
4. A kernel of zealots is formed, lists are created, a trac site opens up, cool logos are devised and we’re underway.
5. The framework author gets to be BDFL and starts on picking fights with other framework authors to gain publicity.
6. Core team starts expanding and they start giving bullshit guilt trips to anyone and everyone who talks about anything which is not in line with the “vision” of the framework author. I’m old enough to remember the severe virtual beatings people got on the Zope lists when they dared to critique the “acquisition” method, which while being very arcane and counter intuitive, was near and dear to Jim Fulton who happened to be the BDFL of that ill fated python framework.
7. Time to rev up the eco system: Now that we have a thriving community, the nex task is to convert this to dollars. Publishers start jumping on the new buzzwords bandwagon and start getting books in the pipelline, conferences are set up with UNGODLY amount of entry fees, every thing that is supposed to actually help has a price on it.
8. Method is simple and it is kind of how organized religion works. Hook the converts in with some pitch, and once they’re in, you can start squeezing money out of them. The church says you’re not going to heaven because you didn’t give us X amount of money. The framework “gurus” keep telling you your stupid because you ask stupid freaking questions and if you bothered to read that message in that list that many months ago (or better yet, bought that horribly done “bible” on the framework) you wouldn’t be asking these questions.
9. Consulting outfits are formed which promptly proceed to hoodwink customers into thinking they not only need that but they need to hire “these guys” because they are the “in group” in framework x, y or z.
10. This method of generating money out of things that are SUPPOSED tobe FREE is a little bit sneaky. It is a conspiracey of silence and a confederacy of dunces (you and me) who want something that would not require ungodly amounts of obfuscated magic incantations because we all intuitively know that we’re at that stage of hardware/software advancement that we shouldn’t HAVE to know 500 magic incantations before we can hit the ground running.
This obviously runs right in the face of the revenue generation model. When you can’t charge the “customers” for the product, you charge them for services. If the framework was so easy that they could pick it up and do it themselves, they wouldn’t be asking for consulting time now would they?
So the trick is to make it look easy on the sell point, and when you’re deep into the commitment zone break it to you that you actually need to buy this, or attend this seminar or hire these consultants who just happen to be the main guys/(very seldom gals) on the project.
My analysis may seem cynical, but the evolution of Rails as an eco system has given us all a very nice opportunity to study the birth and lifecycles of wildly popular frameworks.
Anything which is remotely useful about this framework has a price tag on it. Heck they’re charging 500 to 700 dollar per head for the first rails conf and no one is batting an eye! When users of the 1st ruby on rails book ask for a discount on the second book which is essentially required because the framework is changing so fast, they are essentially hounded out of the mailing lists because they dared to be so un-grateful as to ask for something which most vendors would do anyways.
My question is, if the framework is SOOOOO easy to use, why are there workshops galore charging 1000-1500 per day to get you “bootstrapped” into understanding the “inner” workings of the product? Isn’t that what being opensource is all about? that I don’t have to pay IBM/CISCO/SUN douchebags for their propriety technology documentation?
And don’t give me the crap about it being free so take it or leave it..
(The individual user, by accepting the framework gives it life and meaning.. you can’t turn around and tell them its crappy because its free! The adopter’s time ISN”T free and never will be. They’re there to make their lives easier as should be the case. The fact that YOU happen to be out there hawking your snake-oil that claims to solve their problems in a “jiffy” is incidental.)
When someone asks for a change, if they’re not ridiculed, they are patronisingly told that Rails is a framework to scratch the itch of those who happen to be the core developers. And everyone should feel lucky they get to have it for free. Meanwhile people with very limited grasp of Ruby itself are running around giving 1000 to 1500 dollar per head “workshops” because the hype factor is so high. This thing is going to surpass java so we all might as well “learn” all about it, and what better way to learn than to pay a thousand bucks for a day of hey here’s how you create a weblog.
So, essentially, the frameworks which CLAIM to be free and lightening fast don’t make sense to ordinary developers (who are not 5 year java feinds) is because THEY ARE NOT! Its a Mirage! a way to attract a critical mass so you can create a self sustainging hurricane of steady revenue generation. When you’re outside the Jim Jones colony you’re enticed with the programming paradise where you would think something and it will just fall into your lap. Once you’re inside, you are given the same treatment which any cult gives to its doubters. Slowly but surely, you gotta loosen the purse strings because its not about YOU being able to put together an app together in the most logical and time efficient manner, its about YOU being part of the herd whose only job is to sustain the “popularity via downloads and adoptions” myth and to evangalize it further.
Stop asking for the framework to do the work in the way that the screencast promised.
Ask not what a framework can do for you …
You write: “I have this grumpy, churlish feeling…”
Eric, you *are* grumpy and churlish. I’ve seen you speak at several conferences, and been on the periphery of a bunch of group conversations at those events. And you can really be kind of a bitch. Yes, you contributed to the invention of CSS, but there’s a lot of stuff you could stand to be more curious about and open to. Frankly, it’s a little surprising to me that you’ve gotten to be so well-respected with what can come across as a pretty unprofessional attitude.
Re-read comments #9 and #50 if you don’t get frameworks. This will be the key to you getting it:
“So I don”t think any of these frameworks can make much sense until you feel the pain. You need to know the sickness before the cure becomes appropriate. If you don”t feel the pain at the moment, no point trying to solve a problem you don”t have.”
1. If you don’t get frameworks, YOU HAVEN’T WRITTEN ENOUGH CODE. PERIOD. Go write more code. Get it yet? No? Write more code.
2. You haven’t had to deal with clients changing how the webapp works every 30 minutes. Burning the midnight oil and money you thought would be profit because the client wants “just a couple tiny changes” that takes hours to implement.
3. You haven’t had to spend hours rewriting all your select, update, insert SQL statements because you needed to add or remove a field. (Or you’ve tried to do your own basic MVC modeling and creating data-bound objects, mmm…)
4. You haven’t been sickened-to-death of writing validation for forms. Sickened of returning appropriate form errors back to the user. (I don’t have to! My framework deals with this!)
5. You haven’t cut your teeth on writing procedural code enough to understand when OO-code starts to make sense.
6. You haven’t dealt with code-bloat. Scripts that are 50,000 lines and all stuffed in one file.
7. You haven’t dealt with enough code embedded in the middle of logic. (Think Perl in the pre-templating days.)
8. You haven’t been paid to fix someone else’s nasty programming mistakes on a project that is more than a few scripts.
9. You haven’t build a medium-sized web application — and then learned that 95% of your time is spent maintaining it.
Folks, if you look at any of these frameworks and don’t “get it”, you simply aren’t experienced enough. You DON’T have enough time under your belt to understand. Period. Go back to hacking procedural code. One day, you will start asking yourself the right questions and it will all make sense.
It’s cool — we all started there. The key is to start asking the smart questions NOW: “Why am I spending so much of my time writing duplicate code? Rewriting SQL? Having problems finding the code I’m working on? Copying-and-pasting from one page to another?”
Frameworks definitely have their places and in enterprises, defacto or common frameworks allow for a rapid communication of the basic structure of an application.
We have a handful of applications which, like or not, were built using Struts as a framework. Struts, with its popularity was a relatively easy skillset to look for when it came to screening candidates who would continue to mainain these applications. For all its faults, the fact that it was Struts allows the new developers to quickly know where to look.
Contrast that with a few ‘no framework’ or homebrew applications that we have. The original developers are long gone, and no one really knows how these work. Instead of a framework, they did it themselves, lots of servlets. Lots of custom classes doing the same plumbing that an established and well known framework does.
Guess which one of the two types of applications our production support team deals with in a more expedient manner? Where do we have fewer headaches when people inevitably leave and we have to conduct knowledge transfer?
That having been said, there is also significant risk in gambling on a framework or architecture that may become obsolete. So I, like many others, are waiting on the sidelines to wait for a favorite to emerge.
Pingback ::
Script Artists » Archiv » Frameworks?
[…] h? Einige andere haben sich das auch gefragt und verucht, Antworten zu finden: Eric Meyer: Flummoxed by Frameworks und Framework Fix Jonathan Snook: Why Frameworks Su […]
Andy Kant writes:
ASP.NET is very much not an MVC framework. For a start, where’s the Model part of the equation? Using DataSet and the other ADO.NET classes doesn’t count here because you can’t build a domain model with them directly.
The V and C bits are also rather suspect. Code-behind is not MVC, any more than using an
include()at the top of all your PHP files could be considered MVC. All you’ve got in ASP.NET is that the bulk of your code is held in one file, and you have a template file that is tightly bound to that code. That ain’t MVC by any measure.That’s not to say you can’t build MVC apps using ASP.NET, just that you need to do a bit of work to implement it.
Define ‘obscure’.
Again, define obscure. If you know JavaScript, there’s nothing particularly ‘obscure’ about it besides the fact that blocks are some mighty fine syntactic sugar for building closures. If you know Python, it’s all quite familiar though some parts of it small a little Perlish. If you know Smalltalk, it’s like somebody reinvented your favourite language with a more conventional syntax.
In fact, there’s nothing particularly obscure in Ruby if you’ve been exposed to more than C#, Java, and other such languages. The only thing is that Ruby combines a lot of features (such as Smalltalk-esque blocks (closures), mixins, a strongly reflective OO system, and so on) quite well.
Far from it. Anybody with a strong background in any of the four language I mentioned above will find nothing particularly strange about Ruby. We’re hardly talking Prolog or Lucid here.
No, it’s far more powerful. Now, I can give you a full list of how Ruby (or Python, or, heck, even JavaScript) divorced from all its non -core libraries (such as those for database access and so on) is a far more powerful language than PHP. Just give me an example of how you think PHP is more powerful, and I’ll show you how you’re incorrect.
JohnLen wrote:
Ask yourself the converse: why shouldn’t everything be an object?
Actually, there’s not a language on the planet where the values you deal with aren’t objects of some description. Now, the thing about an OO language is that you can attach behaviour to these objects.
Of course, not all language give the same esteem to various kind of object. Functions, for instance, are first-class objects in C, so it’s possible to pass them around as values, but you can’t do the same thing in, say, Fortran, where they’re not first-class objects.
Other languages, such as, until recently, Java, split objects into two sets: regular objects (objects as you know them) and primitive objects (things like ints, characters, &c.). Such splits are done primarily for the sake of run-time efficiency (or because the compiler can’t yet optimise the code well enough, so the work is thrown on the programmer’s shoulders).
Again, why shouldn’t everything be a (first-class) object? Why shouldn’t a function be an object? Why not an integer? Why not a file? There’s no particularly good reason why not, so the parsimonious thing is to not have an arbitrary split in the type system.
Pingback ::
outbreak » Frameworks in the future.. (written on May 14th, 2006 by Marko Mrdjenovic)
[…] in JavaScript and are not the primary targets of frameworks. A few days later Eric posted Flummoxed by frameworks that started a huge debate about it (he also posted […]
I used to detest frameworks. I rationalize them now as just a higher level of abstraction from the language they’re written on. A specialized abstraction.
Before Rail’s fame really took off, I learned Ruby and it completely made sense to me, it doesn’t for everybody, it does for many, but initially I just didn’t “get” Rails and had some of your same problems with frameworks, like “why did this happen?” “How did it happen?”, etc. until later I realized it is actually as Jeff puts it. I’m not asking myself (anymore) why floats in CSS behave this or that way. They simply do, so I learned, now I can use them effectively.
Why PHP’s attractiveness lies in the very fact that it abstracts away many common Web application related tasks into easy to remember functions (never mind the naming inconsistencies). Rail’s Active Record abstracts away a lot of database functionality: you can program table relationships in–yes–very english-like calls, you field names are converted into useful variables/objects for you, etc. for most data operations you can kiss SQL good-bye, and that is a good thing.
Of course, they’re not silver bullets. Each framework, as all abstractions that every programmer builds and collects over the years have their own “sweet-spot”, so they’re a gift from God in many situations but inevitably in others simply a nuisance. The famed Prototype Javascript framework breaks the default behavior of Arrays & Hashes, and in many cases it doesn’t matter, but it’s an absolute killer in others.
You must hate reading through 100 comments, but if I have anything useful to add: give it another try! You seem to imply some knowledge of Python already, so Django is there, or maybe TurboGears will do it for you, Zope? If you want to give Ruby another chance, there is not only Rails, Nitro is quite cool even in a more primitive state of development, but Rails has plenty documentation and several books available now. Never stop learning!
I haven’t read any of the comments here, but:
Rails is super easy if you’re familiar with writing MVC web applications . I come from a Java background, primarily coding Struts.
Now… try learning Struts… and have fun ! It’s 3 times as complex as Rails is in my opinion.
Rails looks like English, while some J2ee web stuff looks like Klingon :)
Re-read comments #9, #50 and #95. They explain pretty well why a framework is (or not) needed at some time in your daily job. #9 is just perfect, btw.
I don’t know why all these programmers under 62 think they need anythin other than assembler. i mean, what good is a what’s it called — “WINDOW” — or a “TEXT BOX” if I don’t know how it painted to the screen? I mean, what if I need to make every other pixel in the title bar a different color?
These people that use “OPERATIN SYSTUMS” er “GOOEY TOOLKITS” are too slimy by half. Give me an awl and some cardboard and I’ll give you a calculator program that’ll outperform his GOOEY web based spreadsheet ANY TIME OF THE DAY.
Byte Me,
Mel (you should read my story)
Pingback ::
Mostly Random
[…] b apps—you know, Ruby on Rails, Django and their brethren. Especially recently, with Eric Meyer’s flumoxing (and it’s subsequent fix) and Jeff Croft […]
Pingback ::
SyntheticRabbit: Blog > Hanso lo (Newsthings 9)
[…] n to watch Lost anymore. Django gets some love from an otherwise Rails-centric community. Eric isn’t convinced. New Superman Returns trailer It turns out that […]
Pingback ::
g.wp.com » Blog Archive » Frameworks
[…] ndom shit is posted. Frameworks Eric Meyer has done a brilliant post on frameworks, which I agree with completely. About t […]
Just wanted to pile on to say that #9 expresses it well.
Eric, you mention that you “wrote all of An Event Apart”s registration stuff using PHP and MySQL.” I take this to mean that you did it once. Imagine if you did it three times, or five times, or fifty times — for different clients, with minor variations. Imagne how sick you’d be of re-implementing the same core features over and over. Your approach would change a little bit with each job, as you discovered better ways to implement certain features. Imagine the nightmare of trying to support all those clients — each one using a slightly different snapshot of your learning process.
Now imagine how much you’d appreciate pre-written software that took care of the common pieces for you, allowing you to focus on the variations. That’s what frameworks are about.
Pingback ::
l i b b y :: m o l i n a
[…] e. But my feeling about it, and the prevalence of Frameworks out there has started some interesting debate.
This ent […]
Pingback ::
l i b b y :: m o l i n a
[…] en I get the time. The prevalence of frameworks out there has started some interesting debate.
This entry was posted
[…]
Pingback ::
XiAP GUI Studio
[…] he online store of my wife is officially opened! Now go buy some teeshirts for your kids ;)Flummoxed By Frameworks Where Eric Meyers has the guts to say outl […]
Clipper – blast from the past. It sure beat straight dBase :) How about Clarion? and Prolog? :)
Seriously I have some of the same complaints with frameworks. The thing is that, at least in my case, it really isn’t a problem with the frameworks themselves so much, as it is with their accompanying documentation which is written to a large extent as if you already know 1) how to use it, 2) its inner workings and 3) oh yes you need t do this first, etc. I have found this to be increasingly the case since (and call me old fashioned if you will) the demise of printed documentation and manuals. For example the last incarnation of Borland’s PASCAL product came with about 10 printed manuals. It was easy to find things, they were readily cross referenced and could be plunked (several if necessary) open on a desk for easy reference. They disappeared to reduce costs/price (though notice prices didn’t decrease)
Then again the first programming language I learned over thirty years ago was Ten Statement FORTRAN. :) And as I once had the indescribable experience of having to learn and spend a year using APL via a DECWriter terminal I am in some circles now considered beyond hope. :) And to clinch it I actually LIKE using ADA :)
I take my hat off to Ben fro hitting the nail on the head. I’m a PHP programmer (whose first love is Python BTW) and I’m tired of re-jigging the same old apps in ever-so-slightly different ways to suit the needs of customers. I don’t neccessarily want frameworks, but I need them to stop me going completely mad.
A nod also to James Bennett for commentary on Django and it’s documentation (yes, I might just go with with Django over all of the other frameworks).
In response to James’
I think the answer is Web2.0, or more precisely (and without the cruft), that web programming is struggling towards it’s second generation. Maybe the pundits think that we’re somewhere beyond Web2G already, but that’s simply not true. Developing for the web demands that we integrate the needs of graphic designers (with little or no knowledge of web design), as well as end users and clients across multiple platforms and programming languages; to a degree not seen in traditional software development. Our customers need it now. They need it to meet their expectations. But more importantly they need it delivered to a timescale and cost budget that competes in the same market as their web-host (all you can host for £0.33 per month).
Getting the job done does, or very shortly will, demand that you deliver cleaner, more secure code, on tighter deadlines, and at lower cost than ever before. The payoff for coders, if they pick the right tools for the job, are more time spent on really developing instead of re-hashing the same code over and over.
Frameworks are, in my view, the (sometimes painful) attempts of the coder-designer-customer triangle to evolve into a second-generation of web-development.
Realistically we’re not quite there yet, but I have a feeling that in a couple of years frameworks will become the next generation of web coding. Ubiquitous. Removing the need to generate all code manually, and with much more flexibility than we see now.
Maybe this is pure BS, but it might happen. That’s the joy of being a programmer – what comes next!
Pingback ::
SyntheticRabbit: Blog > Rabbit on Rails
[…] I think that having these things forced on me will help me in my mindset for programming in other languages as well. I’m still in the process of learning the most basic CRUD tasks in Rails, and I definitely share Eric’s feelings on the matter. […]
Josh wrote…
If it’s such a bad language for large-scale applications, why is it, Yahoo, IBM and many other companies use it. When a major myspace style app went from JAVA to PHP, they fixed the scalability issues they couldn’t seem to get right with Java.
Since you’re a JAVA guy, you shouldn’t obviously be posting about how bad PHP is, since you’re not using the language and tend to be biased.
Add my name to the loooong list of me-too’s here.
I love Spyce ( http://spyce.sourceforge.net ), it gives you the rapid development advantages of a very high level scripting language, but still retains the full control that comes with using a programming langauge and not a framework.
Used wisely, custom tags should give you a lot of the same rapid development speed of frameworks but without compromising control.
Pingback ::
Script Artists | Was sind Frameworks?
[…] Flummoxed By Frameworks von Eric Meyer und Framework fanatics von Wilson Miner « Ajax-Tutorial […]
Pingback ::
Friday on Rails | Creativity, cooking and a bit of politics: Jamie Rothwell's blog
[…] http://meyerweb.com/eric/thoughts/2006/05/08/flummoxed-by-frameworks/ […]