Application Streaming – Why Bother? – 1st installment

I've been working with application streaming for the past year or so and often when I go to other groups within Intel to try and convince them that streaming is the way to go - they ask me - why bother? They reason that they are moving more and more to web based applications so why would they implement streaming for the applications they might have left written in a client side language.

Well - that's a good question - but it's interesting that when I speak to the management team this is their response but when I talk to developers - they are very excited (usually) about this possiblity.

Why? Because most developers would rather develop in a language that is more robust than you typically get with a web application tool. They like the ability to have more control over the graphical experience for the user and the ability to do more powerful things within the language. The management team is looking at where current momentum is going and they don't want to change the direction. But should they?

Is there a compelling reason to move to more client based applications and away from web applications?

Should we have both in our toolkit? - If so - where should we use which one - why would we ever build more client based (not sure what to call this, where the execution of logic happens on the client) applications?

To evaluate this question I think it would be good to go back to why we started to move to web based applications in the first place - for those that have been around long enough to remember when all we had was client based execution of applications (after mainframes of course). Unfortunately I have been around for all of the above and have been working with applications the entire time (since 1976).

So I find this interesting - anyone else?

In my next entry - I will start to explore this question to see if we can build a case for moving to at least a more balanced view of where we put logic execution.