What should your framework do for you?

Posted by Ian Holsman Tue, 04 Jul 2006 16:46:00 GMT

James Bennett brings up and interesting viewpoint, about where he thinks django should draw the line on what it offers.

Which means that here and now, in 2006, if you call yourself a “web developer” you have absolutely no excuse for not knowing JavaScript. And if you don’t know JavaScript, you have absolutely no right to call yourself a “web developer”.

personally I can also see the same argument being made about a templating language, a ORM layer, and a HTTP webserver, and I think it is flawed.

let me first get back to the basics on why I develop.

my job is to create (and capture) value for my company. Value in this case is money and enjoyment. (I happen to like coding).

Do I know how how to write javascript? yep. I also know SQL, and have writen webservers modules (although not much lately) but knowing how to do it doesn’t mean I should be doing it every time  I want to develop an application if I don’t have to. Having me writing (and debugging) javascript is not a good use of my time. I should be spending my time doing more valuable things like creating job sites or content aggregators. If django had a fancy javascript layer those sites would be using it right now, instead of waiting for me to develop and integrate it.

Having django or any other framework provide a “optional” layer for me to use if I want to just makes good business sense. If I care enough to write my own javascript (or SQL layer) nothing is stopping me doing so.

but if can get get by with a ‘ok’ one shipped with the framework I’ll do that, and concentrate my time on adding value to my application in other areas. (the stuff where I can actually make money for my company)

The key point here is that it is OPTIONAL, just like generic views, and the admin app. I can choose to use them to do most of the boring stuff, and IF they don’t work out I can use a custom solution. That is the beauty of django to me. 

Posted in  | Tags , ,  | 7 comments | 1 trackback

Interesting Talk about Ajax Security

Posted by Ian Holsman Tue, 14 Feb 2006 22:19:00 GMT

I just stumbled onto this Talk about security and Ajax by a fellow Melbournian which serves as a good introduction to the topic, and highlights some issues to beware of.

The tool they are using to demonstrate stuff is called Paros which looks like a great ajax debugging tool, and I will be making use of it to debug my own code. (I was resorting to tcpdump in some cases)

Posted in  | Tags ,  | no comments | no trackbacks

Wishes can come true

Posted by Ian Holsman Wed, 01 Feb 2006 14:51:00 GMT

A while back I wished that a CDN would host all the ajax libraries so that people could make use of them.

Well.. Alex over @ Dojo says that AOL is hosting it!

FANTASTIC.

and I also hear that django is planning to use Dojo in their framework (for the admin side) this makes me happier even still.

Posted in  | Tags , ,  | no comments | no trackbacks

json+django

Posted by Ian Holsman Fri, 18 Nov 2005 02:16:00 GMT

There has been some discussion on whether django should choose a ajax toolkit to work out of the box with the framework. the basic gist of the discussion is should we select one, or let the developer decide.

This sample is more of a sidestep to this. It allows you to output your model as json so you can start working with ajax stuff now until the decision is made.

snippet is django+json interoperability.

you can see a working example here

Posted in ,  | Tags , ,  | no comments | no trackbacks

javascript hell

Posted by Ian Holsman Thu, 06 Oct 2005 17:16:00 GMT

I currently have a distributed monitoring application for which I need a central status.. excellent I thought I could get each server to serve a XML file of it’s status and have the client HTML poll each seperate machine and display it in a nice form which auto updates each servers status every X minutes.. no need for a central server.. just let the client do all the merging.

well unfortunatly It isn’t as easy as I thought.

attempt #1 .. use XMLHttpRequest.. bzzt no soup for you.. it doesn’t work across hostnames

attempt #2 .. use hidden IFrames.. load them up and have the content notify the parent when it changes .. bzzt.. damn security.

I don’t want to have the main page grab the status from the children.. as I don’t know when the children will have the data ready for reading by the parent.

so now my only recourse is:

  • load the status as a seperate javascript file on the page. and load them up as variables.. I’m thinking that this will work

or

  • use mod-proxy to create URLs on each distributed server which reference the other servers.. which isn’t going to work as they might not have access to each other ;(

if only the javascript security feature could allow me to turn off all this silly stuff..(or ask the user surfing the page)

Posted in  | Tags ,  | no comments | no trackbacks

Downloadable applications

Posted by Ian Holsman Wed, 17 Aug 2005 17:40:00 GMT

I just noticed James Duncan has announced a new (to me) online book selling service called Vitalsource. And it me got me to thinking .. is it really worth developing custom applications which run outside of a browser window?

The IE/Firefox incompatibilities are well known, and for the most part and no longer important insofar as project risk, and increased development time for a multiplatform browser platform (compared to writing native apps). Especially with stuff like openrico, a cross browser AJAX development platform, which does most of the heavy lifting for you.

The only real drawback for a web front end for this kind of application is the inital download time of the javascript which does all the magic, and if you have your cache headers set right it shouldn’t be such a big deal with the rate at which broadband is being taken up.

But when you have to develop (and test/debug) 2 seperate applications (where’s my linux download BTW?) like vitalsource has too going forward is the latency such a big issue, compared to cost of running 2 products?

Personally I hate downloading applications. I never know who is behind them, and what ‘surprises’ they have embeded in them. (spyware/advertising etc). The cheaper the application is the more nervous I am. This relucatance will also stop people trialing your product as well. you need people to download the viewer and have a little surf first, before they decide it is worthwhile.

The other problem you have is promotion/SEO for your business.

With a nice RESTful front end, google + friends can go crazy indexing all your content and giving you some free traffic…

I think this is the main reason why people like realestate.com.au have a directory area on their site.. so google can index all their database allowing people to find that property in hawthorn for rent.

Do you think the tides have changed where you have to go to your management team and defend you writing a native app, compared to 2-3 years ago when it was the other way around?

Update: It looks like the Mac version is using ruby on rails and apple’s webkit. I’m guessing the windows version would be doing something similar to this. so alot of the arguments about the downloadable app are moot I guess, as it is just a shell, and shouldn’t need much maintenance. But the SEO argument is still valid, as the download issue.. let me browse your catalog via a browser, BEFORE I download the client.. tempt me, make me have a need to download it, instead of forcing me to download it and find out how cool it really is.

Posted in ,  | Tags , ,  | no comments | no trackbacks

Javascript Templates + ajax == ?

Posted by Ian Holsman Tue, 08 Mar 2005 04:41:00 GMT

JavascriptTemplates allows you have a templating system like Velocity, but on the client side... now if you mix this with xmlhttprequest objects (aka ajax) you could have your view and controller parts of your applications on the client itself, leaving the model on the server, pushing out data as fast as it can. (just like gmail does now, but using a APL/GPL'd framework)

The javascript template example puts arrays of objects and templates inside the page served by the webserver, but you could change this quite easily into a cachable HTTP GET call.

Sounds like a nice new development model which is getting some tools+energy behind it.. Thank you google for lighting a fire underneath a whole lot of people.

Posted in  | Tags  | no trackbacks