Dan Griffin's Blog
Comments on security, PKI, smart cards, cryptography, and entrepreneurship.
Windows Client Guidance paper by Tim Huckaby
June 18, 2009
Is here.
Primarily, Tim’s paper attempts to answer the question, “what do we call an application that doesn’t run in the browser?” and he defends his choice of ‘rich client’. I personally prefer ‘thick client’, since it clearly contrasts what the likes of Sun (moment of silence please) and Google have been trying to push as the thin client, or the equivalent of terminal- or browser-only, solutions that are in their best interest. However, I freely admit that ‘thick client’ doesn’t have all of the right connotations, especially in the PR department, and that my business is in the ‘thick client’ camp.
I disagree with some of Tim’s points. First, he says that some things are impossible to do in the browser. Given the extensibility of today’s browsers, and the software tools available to web application programmers, this is not true, even if we generously interpret ‘impossible’ as a relative term.
This serves as a segue (Segway?) to the next point, though, which is that just because you can do almost anything with an ActiveX control in IE, for example, doesn’t mean you should use that approach - security generally being the primary issue when it comes to browser plug-ins. However, this brings me again back to the first point, which is that just because the ActiveX approach is harder to do securely doesn’t mean it’s impossible to do securely. And - this is the key thing when it comes to the relative security of the “rich client” approach (another of Tim’s points) - regardless of where the application lives, inside or outside the browser, security requires diligence and careful analysis.
Thirdly, Tim’s points imply that richness is easier to achieve outside the confines of the browser. A relevant measurement for this claim would be the development cost of equivalent applications, one browser-based and one not, that solve a business problem. Admittedly, those are difficult data to obtain for a couple of reasons. First, the biases of the customer as well as of the developer influence technology choice. Second, my first point notwithstanding, I freely stipulate that many problems are more easily solved by one approach (in the browser) or the other (outside the browser), if for no other reason than industrial inertia.
Still, regarding the ease of achieving richness, I cite two counter-arguments to Tim’s viewpoint: first, there is tremendous competition in the custom web development market, both domestically (US) and overseas. This has driven down prices and driven up quality (although not uniformly). And second, while it’s not clear whether richness implies a professional design and UX, it should, and that’s neither cheap nor easy regardless of the technology. But, in my experience, it’s easier to find experienced web designers than experienced “non-browser-based-UI” designers (easier being, again, a relative term; it’s really hard to find either).
Permalink |No Comments »
No comments yet.
RSS feed for comments on this post. TrackBack URL
