In discussions with my friend Kevin, I have come to realize that we have arrived at the same conclusions about the use of web application frameworks. Much of these conclusions have driven from 12+ years in building applications using them, with various rates of success. Suffice it to say, only the most l33t programmers out there are using their own frameworks, be it a custom one or contributing to the creation of an open-sourced framework. Everyone else is like me: a user of frameworks, and extremely rare contributor back to those frameworks.
Since Kevin and I are travelling together through the world of snake handling, we have been looking at the available options for building web applications in that environment. Our conclusions have been surprising to ourselves, but I think they can be very instructive to others. These two lessons are applicable to other programming languages as well, so feel free to substitute your favourite language where applicable.
Lesson 1: Full-stack gets you in the door, lightweight lets you find your niche
If you want to learn Python for the web, the first place you go is Django. It is a full-stack solution for building things in Python. Awesome documentation, and with some help from Python’s online documentation, you can build an app in a reasonable time frame without knowing a ton of Python. Awesome tutorials and code samples FTW! I have built a Django app and briefly made it public. It was, like so many other things, a piece of crap missing functionality so I am trying to rectify that in my ever-dwindling spare time. I did not find any serious obstacles to building this app, except for figuring out how to do some dynamic form-field-generating code. It took me a while to find the right info (amazing how having the correct keywords in your search helps) but I did.
As an old warrior of frameworks (10 and counting across 3 languages) I found that because I already understood the concepts behind MVC (or MVT in the case of Django) I could concentrate on learning Python first, and then the unique features of the framework after that.
In many ways, my early experiments with Rails (back in 2004-2005) helped me understand frameworks a lot better. All frameworks have their own magic methods for doing things, with Rails making heavy use of Ruby’s ability to create Domain Specific Languages to make Rails the incredibly useful framework that it is today. But eventually, your skill with the language and the framework gets to the point where you see the limitations of the conventions and magic methods the framework uses.
Now that I’ve gotten my hooks into building stuff with Django, I now recognize the same seductive promises that I found in things like CakePHP: the full-stack takes you away from actually figuring out how to code things, and instead you find yourself just using all the built-in methods. Don’t get me wrong, the built-in stuff for Django is awesome. But if I want to push my skills forward so I can say “I can build stuff for the web using Python” instead of “I can build stuff for the web using Django” I need to use other tools. What if I want to run my stuff on Google App Engine? Sure, there are these hacks available for Django that make it “usable” on GAE, but that’s not what I want. And what about the use of WSGI instead of relying on mod_python? Forgive me if this stuff comes across as technobabble. It was technobabble to me at one time too.
So now the next step is (after finishing the current Django app) is to build an application using a much more lightweight framework. Why? Because it’s time to actually learn how to do something instead of relying on magic methods. Because once I learn to write code to duplicate those magic methods, I’ll be able to use Django *and* Flask. And that, my friends, is how you make yourself useful. That and the ability to run the app both as a standalone WSGI app or on Google App Engine seems like a bonus to me.
So now that you’ve gone from full-stack to lightweight, it’s time to look at the next lesson…
Lesson 2: Don’t use anything made by One Guy
This will undoubtably be a touchy subject for some. Let me try and explain it.
In the quest for the lightweight solution, I ran across web2py. Nice and lightweight, awesome documentation, but it’s all driven by ONE GUY. Experience has taught me that projects driven by ONE GUY end up looking like how the ONE GUY would do it. Sometimes the ONE GUY is brilliant and it all works out. That is rare, in my experience. Open source projects are littered with the wreckage caused by egos and control freaks who were unwilling to accept outside help to solve problems.
So look for projects where it appears there are solid contributors beyond ONE GUY. web2py sure has an impressive list of people who contribute, but is Massimo the ONE GUY when it comes to actually making non-trivial code changes? I sure hope not.
There will be no test afterwards
While I do not expect other people’s experiences to be the same as mine, I’m pretty sure I am not the only person who has learned these lessons. So the next time you are evaluating using a web application framework (in a new language or an existing one) think back on these lessons.
Tags: Django, Flask, frameworks, full-stack, lessons learned, lightweight, Python
It’s been fascinating watching your various struggles with different frameworks, and your insight in this post is quite refreshing.
On the ZF mailing lists, it’s not uncommon to find questions asked that are clearly the result of a lack of fundamental PHP knowledge. This always surprises me — it’s as if somebody came to a construction site and wanted to start doing framing without ever having picked up a hammer before. And yet, for many, the first question they ask when starting a language is, “What framework should I learn?”
Looking forward to reading your next adventures in coding!
MWOP
I think programmers (and I am not alone having gone through this) are seduced by tools that promise them the ability to rapidly build something with minimal code. Given that message, it’s easy to see why people pick the framework instead of the language.
I mean, I cannot be alone remembering what it was like to build web apps before all these frameworks came along. My apps were all of the page-controller-driven type, with the action it performed based on what was passed in as a parameter. Yes, I did check to make sure it was a valid action too. Ah, the good old days.
Given how many frameworks exist for the various scripting languages, I totally get why people do not learn the language first, then pick a framework that fits their needs. It’s too easy to grab a framework and start coding, without really understanding what you’re doing.
Add in cutting-and-pasting of code samples found via search engines and you’ve got a semi-working, semi-incomprehensible code base.
If you want to get a feel for what it would take to build an application using bare metal Python, I’d recommend building on top of WSGI. If nothing else, it’ll give you a feeling for what Django does before your code is even executed.
Regarding lesson 2: that means you’ll miss out on a lot of interesting projects. Those “one guys” need help forming a community around their project to get people involved in it. Node.js and CoffeeScript both come to mind as “one guy” projects that have gotten some traction and are starting to amass communities around them.
Travis
You definitely walk a fine line when looking at projects run by the One Guy. One the one hand, you might have someone who is really good at it and creating a brand new paradigm. But on the other hand, if the One Guy isn’t good at accepting outside help then you are screwed.
If the One Guy is into sharing, then that is good. If they are not, stay FAR away from the project. As far as I can tell, Node.js is gaining traction because Ryan isn’t acting like a spoiled kid, unwilling to listen to others.
Reminds me of the day Rasmus posted his famous “no framework framework”. We all saw it. Kind of wrote it off. Came back to it. Thought about it. Loved it. THEN decided it wasn’t quite right for us… but we needed to go through those phases of evaluation & synthesis to come to that decision.
So many people just compare feature bullets, or just use whatever their friend recommends. It’s not about that. it’s about what’s right for you at this point in your personal development, for this particular project, taking into account what resources you have available right now.
@Derek
In many ways, this argument is also about what is good for the developer vs. the business that is relying on the application in question. No doubt, a finely tuned “No-Framework Framework” makes sense from the developer’s perspective. Who wouldn’t want a finely tuned application, specific to the needs of the biz.
But it becomes very hard for additional developers to pick up a custom framework and figure out how to start contributing right away to adding value to the business.