David Herron's Blog

What is Needed for the Next Level of 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.

Comments

• The 'assumed level of security' when the application runs inside a web browser is only due to the ineptitude of the browser as a platform for delivering sophisticated applications. If (as?) the browser expands to facilitate more powerful functionality, this "security by inability" will vanish.

  Posted by: javakiddy on November 27, 2007 at 03:50 AM

• For there there to be a "next level" someone needs to make a major breakthrough in distributed computing. Right now the systems we have for distributing applications are limited.

  
  Remote client, like VNC, takes LOTS of network bandwidth. Distribution is easy, systems requirements are small but it's limited in capability. All hardware acceleration goes out the window so no fancy transitions or animations. No access to the local machine, which is either good or bad.

  Local clients, like Java, very capable, full featured but requires a more complicated install. Platforms may not all be supported equally. Can be less bandwidth intensive and take advantage of hardware acceleration.

  Browser based clients are a 1/2 way mark where a thinner platform on the client side is supported by depending more on the server. Depending on the implementation it may depend too much on the server and suffer the same issues as remote clients. Also implementing too much on the client side may lead to depending on specific details of the browser (platform), and face issues like local clients.

  When there is a solution that is low bandwidth, capable of hardware acceleration, fully featured, cross platform and requires little or no install you will have the "Next Big Thing"
  

  Posted by: aberrant on November 27, 2007 at 09:23 AM

• I would be interested in some feedback about my own browser-in-browser soluation: http://juibrowser.sourceforge.net/

  It is basically a Swing-Browser which is able to "render" Swing-UIs which are created on the server as if they were running on the client. The browser itself is almost feature-complete, however the available components have still very small functionality.

  Its great (in my opinion) because:
  - Free
  - Only minimal server-side load
  - Program on Server as if it would the client (e.g. server-side swing), including using netbeans for layouting: http://juibrowser.sourceforge.net/UTestApp.html
  - Very little traffic requirements

  What do you think about it, what would stop _you_ from using it?

  Thanks, lg Clemens

  Posted by: linuxhippy on November 27, 2007 at 09:40 AM

• The limitations of the browser has been a known problem for a decade. That was (partially) why Microsoft went crazy with ActiveX controls for IE. In general, a plugin solution has been the way to go. Java applets were designed for that, but they failed for a variety of reasons. Flash has become a ubiquitous plugin. It provides very low level graphics (vector graphics) and Adobe has been making a big push to provide a developer friendly platform (Flex) for writing Flash apps. Microsoft's Silverlight and JavaFX are both trying to follow suit.

  Posted by: michaelgalpin on November 30, 2007 at 10:54 AM

This work is licensed under a Creative Commons License.