It’s hard to believe that it’s been a year since my “burrito” podcasts on JSF. So what have I done in this last year with JSF? What is my opinion now and how has it changed?
Have you ever skipped out on a movie that was popular? Decided not to see it because it either didn’t fit your taste or didn’t mesh with your life in some other way? I have. I usually look back later on without regret. That’s the way I feel looking back at JSF a year later, but let give you some details.
This is why JSF’s “everything-is-a-POST” approach is bad, but first let me give a bit of background information. I’m a Harry Potter fan. I like the books. I like the occasional conversation. I ususally keep my enthusiasm centered around new arrivals of a book or movie. A while back, my mom and I were talking Harry Potter. She tried to send me a few links. Here’s what I got:
Hi guys,
Here are a couple of links you might like:
Video stream of Radio City Music Hall reading:
http://www.the-leaky-cauldron.org/#article:8956Here’s a quick rundown of the above interview. You have to scroll down to “Coverage:Harry Carrie and Garp” There are some additional links to fan reaction toward the end of the article.
http://www.mugglenet.com/search/index.php
transcript of Richard and Judy interview:
http://www.mugglenet.com/search/index.php
Have fun,
loveya,
mom
Notice the last two links. They’re identical, and they clearly have no information about which particular search results should appear in them. They’re entirely dependent upon the state of the current session of the user. Yet they have interesting content that my mom wants to share with me.
With most other sites (including the first link in the email), you can simply cut-n-paste the URL and send something meaninful to a friend. Lots of people know this. But when you hide your search behind a POST, you break that tacit understanding between the user and the Big Web World. You violate a social moré. This isn’t just a problem with JSF (though their assertion that everything’s a POST is darn annoying) — even my example is from a PHP site.
Please stop breaking the web. Always use GET for your search options, and reserve POST for what it should be for: operations with such side effects that the user agent should prevent accidental replay of the request.
I’ve had lots of feedback from listeners of my JSF podcasts. Many of them have asked what I’d recommend instead of JSF. I think the best answer is no answer here. Matt Raible’s latest post is a great example of the process I’d actually recommend to make your own decision.
Look at your project, your people, and your skills. Look at the industry directions, and contrast the approaches each framework takes. Look at your existing tools, your budget, tool documentation, forum support, and a growing collective knowledge of how to solve hard problems with a framework. From there, take your best guess and try it out on something small, then add a bit of complexity in difficult areas like using complex objects to drive your UI or reusing chunks of UI and controller logic. See how well your framework front-runner does.
Have a junior developer try to complete a maintenance task on your prototype. Evaluate the options enough to get a feel for it, but take the plunge at some point. Recognize that you can change it later, and that will cost something, but you need a longer term experience to know the bumps, bruises and bright spots. Blog about your experiences on the way to clarify and catalog the evolution of your thinking.
Finally, don’t choose simply one framework and always use that. Matt’s a great example in this area as well. If you look back, he’s done several comparisons of various web frameworks; often the same frameworks are in all of the comparisons. He’s made different recommendations over time depending on the goals of his comparison. He’s also looked at fringe frameworks and disected them to understand what they offered, even if he decided not to use them. These are the kinds of things you want to do or see others do when making a choice about most technical recommendations.
