Tags: Rich Internet Applications
I found an InfoQ article,
What is Needed for the Next Level of Browser Applications?, which brought to mind a couple recent postings I made. The InfoQ article is very well thought out and discusses how to improve the state of applications running inside a web browser.
Ian Roughley starts with: The current level of Ajax toolkits are a result of IE winning the browser race, and all browsers vendors entering a period of stability. Stagnation in browsers features meant that to provide new application features, libraries needed to be developed. And the libraries today have provided good solutions to the holes in browser functionality, as well as providing a browser compatibility layer for developers. and ends with Fortunately the web has already gained huge momentum, being the preferred delivery mechanism of today's applications. And for the web, developers are providing mass and the number of deployed browsers providing velocity.
See, what he's described is the quandry I discussed a couple weeks ago. The Internet is being trapped within a jail called the Web Browser. The limitations inherent in the web browser are limiting the abilities of application developers to provide applications for their customers.
Yes some amazing things have been accomplished with the web, with web browsers, and with the DHTML toolkits. My point is that one can only go so far in application features using an application development framework hosted inside a web browser. Stagnation in browsers, as Ian put it, means application developers have had stagnancy in the capabilities they could code into their applications.
So let's dive into this a bit. An application always runs in a container, whether that container is an appserver, a web browser, or an operating system. We don't write code in machine language (any more) because high level languages make application development easier, and to make high quality multimedia-rich applications requires a high level of abstraction from the underlying machine. To write an application is to use and exercise the capabilities of the container.
You can point to any number of causes for Stagnation in browsers ... the fact is the capabilities of web browsers haven't appreciably increased over time. How can I say that while at the same time being a Firefox user with several extensions installed? Well, the issue is the underlying capabilities Firefox can put into a browser frame are limited by the overall definition of 'what is a Browser'. Also the firefox extensions I find useful are outside the browser frame, and in the surrounding chrome. Like the Web Developer toolbar, or Firebug, etc. The Mozilla Foundation has a bit more freedom in terms of what the XUL application framework can do, but what happens within the browser frame is what I'm discussing here.
Ian discussed 'Features' saying 'new features' are required but they need to be added with care. That could well be, but it seems to me that the programming model in a web browser isn't low level enough. An advantage of a desktop application GUI platform like Swing is that while it provides you with similar basic components (JTextArea, JButton, etc) you can also dive beneath the covers and do your own painting or start with a raw JComponent and build from there. Comparatively in a browser you can start with a <SPAN> or <DIV> tag and use CSS and Javascript to build up look and behavior but some things are difficult because you don't have strong graphics capabilities underneath you (like Java2D) and you don't (so far as I know) have the capability of designing an animation framework like https://timingframework.dev.java.net/ or https://animatedtransitions.dev.java.net/.
While application development is easier with a high level of abstraction, there are times you have to get close to the metal to make the app do what you want. There's a level where the browser-based application development platform simply prevents you from going.
Ian discussed 'Trust' and this is a big thing for Internet applications, whether they live inside a web browser or not. An Internet application takes part in exchanging data over the Internet, uses several protocols, etc, and it doesn't take a rocket scientist to realize a nefarious person could send out a naughty Internet application. Fortunately the Internet community has several years experience with developing these things. For example in the Java app development model you can have several levels of trust with security managers etc. However a desktop Java app running outside a browser generally doesn't have a security manager installed, and the end user probably doesn't have the expertise or capability to add a security manager to a desktop Java app that doesn't have one.
This is something a web browser does bring to this problem, that there is an assumed level of security when an application runs inside a web browser container. Applications running outside the web browser container don't have that assumed security container around them.
Source:
weblogs.java.net
