Home > Django > Web framework focus

Web framework focus

September 7th, 2011 Leave a comment Go to comments

Over the years I’ve used, read about, and played with lots of different web frameworks. One of the things I’ve concluded is that none of them are perfect. As with the languages they live on top of, each of these frameworks is a tool that fits certain tasks better than others.

One other thing I’ve realized is that the focus of the community effects the type of web sites that are made. In some frameworks there’s a huge emphasis on Ajax integration (such as web2py), then there are others that are more focused with data manipulation and control of flow (such as Django). Now one other interesting thing is that this focus leads to different types of sites being made.

Two mammoth examples that come to mind are Amazon and Google. While they’re not the most perfect examples for these purposes, I bring them up because they both are layered more than the average site we work on. There’s Java or C++ behind doing all the number crunching. Then layers of other languages in between. One thing about sites like these is, although they all have Ajaxy components, not one of those pieces is superfluous. It takes so much work to tie one of these features in that there just won’t be anything extra.

With a site made with Lift, Wicket or Web2Py I think you get the sense that they’re giving away Ajax for free and they feel that they have to make use of it. Rails sites also seem to be heavier on Ajax than the average site. Django sites on the other hand for the most part are lighter on this feature since it’s not as simple as to tie in these pieces.

These are just observations I’ve made and I’m making no judgment call on what the right amount of Ajax is, or the right framework. It’s just interesting to see how tools seem to be effecting what gets produced even though you could essentially produce the same exact sites with all of these tools.

Categories: Django Tags:
  1. hutch
    September 7th, 2011 at 13:53 | #1

    I’ve never had any issue doing ajax in django. since ajax is really just like any other request, you just write your views like normal. if you need to change up what you do slightly you can just check for is_ajax()

  2. September 7th, 2011 at 14:01 | #2

    Right, but on the view (template) side other frameworks make things much simpler to tie together. I’m not saying it’s hard, it’s just not super easy and also it’s definitely not the focus of the framework.

  3. September 8th, 2011 at 00:54 | #3

    AJAX is a tough one because it’s promoted as being it’s own technology and as such people often think they need something more to do AJAX or they need to learn AJAX. It’s just a web request like any other, if you understand how web requests work then you can already do AJAX. I like how django does it because it’s the DRY principle. A request handler exists once, that handler should work with a traditional GET or POST but the same handler can also work with AJAX. No more code required because AJAX is nothing more than a GET or POST.

  4. September 8th, 2011 at 03:07 | #4

    The only problem with AJAX in Django that you may have is if you lack the CSRF token. As hutch says it is just an request as everyone else. To describe a bit further you may use the is_ajax to detect the call type and serve a different response html or json.

    Also (IMHO) using a framework for building a site with the size and load of Amazon or Google will be a suicide. If you have so big project you will face a lot of problems using a standard framework and maybe the first one will be the ORM.

    To get back to Django, from my current experience I found it very easy to extend and modify without changing the core code.

  5. September 8th, 2011 at 09:05 | #5

    Tom, totally agree with you. I chose Ajax as an example because it effects the “feel” of the site. My main point is the trade-offs framework writers make end up effecting the kind of sites that get produced. As mentioned in the post, you can make the exact same web sites with all these different frameworks, but you probably won’t. The setup and features of the framework will probably have a hand in the type of site that gets produced.

  6. Tom Coote
    September 8th, 2011 at 10:16 | #6

    @michael
    yeah its an interesting one. It’s certainly useful to keep an eye out to see what all the big frameworks are up to.

  1. No trackbacks yet.