Web as a platform is an interesting topic for most people in the software industry. Marc Andreessen (Ning) recently made an attempt to classify this platform in his post The three kinds of platforms you meet on the Internet. In the follow up analysis posted by Josh on ReadWriteWeb Platforms on the Web are Platforms on a Platform, this classification and value of different platform levels is questioned. Before I state my views on this, let me capture Mark’s classification in a summary below:
L1 platform. Loosely coupled REST/SOAP based API integration. Example: Flickr API.
L2 platform. More deeper integration of developer’s application injecting into the platform UI. Example: Facebook API.
L3 platform. A runtime that hosts developer code. Example: Ning.
Marc’s argument that L3 platform are the best, is certainly questionable and Josh makes points in this line. While a scalable web platform with Social Networking API is a powerful one, expecting others to bring their users and user data to your hosted platform is not in the best interest of the company/group that wants to add those features to an existing site/application.
A better solution could be a add-on social networking platform with API which the company/group can co-host and integrate. They get to keep their users and user data and can achieve better integration.
This is like a “Web 2.0 Application Server” as shown in the picture below. Deployed alongside the current Web 1.0 website and can provide social networking features overlayed on top of it.
Would this be more acceptable to those currently on using web as a Web1.0 platform and would like to add social networking among their users (use web as a Web2.0 platform)?
Technorati Tags: Platforms, SAAS, Web Services, Web 2.0
I was heartned to find this early posting on Netwizard’s blog that points to the thinking behind Dekoh.
Writing applications using markup instead of platform-API-based code is so much more easier. Browser-based UI brings significant advantage of using combined teams with programmers (who generally can’t build great looking UI) and graphics and UI specialists (who can’t wire it up with the backend). The last decade of focus for developers has largely been on building to the web. The programming model and the deployment environment are all too familiar.
A browser-based application need not necessarily mean a hosted application, when a desktop runtime such as Dekoh can serve to your local browser. You have the twin advantage of a common environment for quickly building to the desktop (and web) as well as a fluent integration between the such desktop applications with existing web applications. The best way to build web-desktop integrated applications of the future.
Dekoh is starting public alpha program to get feedback from larger community.
We are very excited to show to people at the Web2.0 Expo (San Francisco) starting tomorrow. If you are at the show, drop by at booth number 330 for a demo or discussion with us.
Here is a quick look at the applications we will be demoing.
Adobe has 2 of the most popular browser plugins (see Common plugins for Firefox). Flash is by far the best way to deliver multi-media content to web users because of 2 reasons.
1. Same user experience on all platforms and browsers
2. Ability to stream
Flash Player Penetration is 98% of Internet viewers. This is great for any software! Adobe loves browsers.
Then why did Adobe choose to write Apollo outside the browser? Which clearly puts them On A Collision Course With Web Browsers. Here is why Adobe hates browsers:
From a end user perspective Flash has remained at (in)famous “skip intro” on web sites or as a media player to watch videos or listen to music inside the browser. Flash is not as popular for writing web applications as AJAX is.
The main reason for this is the “back button” in the browsers. Hitting the back button unloads the Flash application losing the application context and any interim session data.
Back button is one of the most used features in browsers. It is hard to change user behavior. This has restricted Flash usage to just media delivery on the web. This I suspect is also the reason why Apollo did not leverage existing browser plugin installations, instead decided to keep it outside the browser chrome.
Ed Burnette has written a blog post Is Flash better than Java? there is a lot of interesting discussion happening on the thread. The comparison needs to be sliced and seen from various angles.
Flash and Java is not apples-apples comparison
Flash is most popular for delivering media content. Most of Flash content is delivered thru browsers. Flash installations on desktops is predominantly because of browser plugins. Whereas Java can be used either as client-side applet for rich application UI or can be used on the server-side for writing the application code delivered to browsers thru HTML/AJAX.
Flash wins hands down if the comparison is with Java applets. But, the number of websites and applications that are powered by Java on the server-side out number Flash applications on the web.
Apollo and Java is not apples-apples comparison
Adobe Apollo is a cross-OS runtime for delivering Web-Desktop integrated applications. Java is a cross-OS platform not specifically for writing web-desktop applications. Java has a huge collection of platform neutral API for accessing OS, hardware, network, graphics, database etc. One part of Java is Swing (UI) which can be used for writing rich UI applications, again swing is not meant for specifically writing desktop-web applications. Swing is traditionally used for desktop only applications. So I would say Swing is more comparable to VB or X-windows rather than Apollo.
A more near comparison of Apollo on the Java side is Dekoh, which is a open source Java based platform for writing desktop-web integrated applications.
Which is better Java or Flash?
Depends on which aspect are you looking at.
Media delivery on the browser: Flash
Better execution (installation, upgrade, version changes) on client side: Flash
Number of web applications written using the technology: Java
In the last week there has been a lot of debate about Desktop RIA applications. Starting with Alex’s article on Read/Write web Adobe Apollo – On A Collision Course With Web Browsers and then a discussion Which is better, an offline Web App or an online Desktop App?. There were other articles including Zimbra offline announcement and a big discussion on need/use of offline apps here. Finally, I read this nice post from Mike Chambers of Adobe on Why Apollo?. He explains very clearly what Apollo is. There are a few problems Mike outlines about delivering applications in the browser. Here are my thoughts and ways Dekoh overcomes them.
Conflicting UI: Since the time Netscape introduced Back button, it has been one of the most used features of the browser. Most sites and web applications work fine with back button and expect people use them. How many popular web applications have you seen that do not work when you use back button? Back button is a problem for Flash based applications, it is not a problem for “web applications” in general.
Distance from the Desktop: For any browser based application there are 2 portions, UI on the browser and a server that serves the logic. When you include the server as part of the desktop platform (as Dekoh does), the distance between desktop goes away. Applications can very well render UI on the browser, as well as integrate with other native desktop apps.
Primarily online experience: Accessing exact same online application in a disconnected mode (Firefox 3?) is different from writing a desktop application that can provide some functionality offline and sync with online counterpart (like ebay demo of Apollo or Google calendar demo of Dekoh). The online experience problem is relevant to former type. Writing desktop applications and accessing them thru the browser creates a consistent user experience, works across browsers.
Lowest Common Denominator: I agree there are differences between browsers when it comes to complex AJAX applications. But it is not too difficult to write applications that are very usable and run well on all browsers. There are also a number of toolkits that abstract the problem. Mike’s concluding paragraph coincides with my thought. He says The fact that web applications have flourished despite these drawbacks is a testament to the attractiveness of having a platform with a good development model that has the ability to deliver applications to multiple operating systems.
Jay Fortner wrote this article Dekoh Challenges Apollo As Desktop/Web Platform on Read/Write web. One observation he made was “…makes it hard to describe what Dekoh is in a sentence”. He is probably right to some extent because Dekoh offers several different things, at a first glance it appears it is doing too many things. That got me thinking about how Dekoh evolved…..Here is the story.
In middle of 2005, few of us at Pramati were discussing about development skills needed for desktop applications development and web applications development. We started to think why should it be so different? How about creating something to merge the two. Chandru played a prank, he created a one-page brochure (pdf) of a product called “Butterfly” that did everything we were thinking and sent it the next day to Jay (CEO). That was the first seed of Dekoh. We made a quick prototype (project codenamed Butterfly)….and story continues. Now coming to the point of one sentence description…
The problem statement we started with was a single sentence “Creating platform to provide seamless user experience for desktop and web applications”. This is stated in the press release. Now, trying to create the platform required bringing the best features of desktop and web together which people are used to, I have explained it in this post. When you try to create a platform, it needs to be beaten up by developers to put the right features in and make sure it is usable. We don’t have the luxury of existing developer base as Adobe, nor can we convince ebay to try our platform before it is popular. So we started eating our own dog food and started writing applications (like photos, music, books, calendar…). Another reason to write such elaborate applications rather than eye candy demos is to make it usable to end users. I am sure developers who adopt Dekoh will come up with smarter and cooler applications, but for initial users Dekoh applications are very compelling.
I made my first attempt at recording a video! The demo shows Dekoh photos application features. This is a AJAX application running on the desktop. Some highlights:
1. Tagging, commenting, sharing features come as part of the platform, it is not coded in the photos application. Dekoh portal API and widgets are used to get this functionality into the Photos application
2. The personal server running on the desktop is bound to local port. No one can connect to your desktop from anywhere directly, even if you had a public IP address, opened all ports or had another machine on the same subnet. So it is fully secure.
3. Front end is Javascript and AJAX. Backend is Servlet/JSP/Java. Application size is about 2mb to download and on disk after install about 4mb.
4. Tagging saves tags onto the picture IPTC/EXIF block. So if you upload the picture to Flickr, you can still see the tags.
5. Unlike a traditional web based application, you can see that Photos application has access to local filesystem (see import feature, tag/meta data editing).
6. Photos application runs on Windows, Mac and Linux. On IE, Firefox and Safari browsers. I heard there are some browser issues on Linux at this point.
The main idea of Dekoh is to bring the best of features on Desktop and Web to end users and developers. Jay in his presentation had a nice slide that captures this.
Here is a brief description:
Universal Data: Applications can blend data on their file system with data on the web (website APIs) in their applications.
Control over sharing: While desktop is a fully private environment, the concept of social web is community based sharing. Dekoh desktop applications can be shared thru Dekoh Network. It is your private network.
Benefits of a hosted application: Desktop applications are self contained and rich in user interface (also easy to install and manage). Deploying and managing web applications is a little geeky job (folks in enterprise software world know this, the reason why SaaS model is becoming popular). Dekoh camouflages all the complexity. Installing and running Dekoh desktop and applications is just a one-click operation. It is totally end consumer usable.
Bringing web 2.0 to desktop: Use your personal media (photos, music, video, blogs, books….) and collaborate with your personal network. Run your web applications on the desktop
Developer friendly: Dekoh is based on open standards and is an open source platform. Developers with wide ranging skills like HTML, CSS, Javascript, Flash, Java, JSP/Servlet, PHP, .Net can write applications on their desktop and share it over the web securely (Read FAQ). More exited? participate in Dekoh development by joining the Dekoh community
End user applications: End consumers can install Dekoh Applications and organize their personal media and share it with their personal network.
There are many pieces to the puzzle of building an integrated desktop and web application platform. Ted has interesting posting today on this and Ryan has also commented on it.
Here is my opinion on what the architecture of such a platform could be and approaches taken by Dekoh and Apollo (from Adobe).
1. Cross-OS base: Required to run the same application software on multiple OS platforms. Adobe has picked Flex/Flash runtime and Dekoh is built on Java runtime. More here on why a RIA envinronment should be cross-platform.
2. Common desktop-web UI: Pure web and desktop-web hybrid applications
should be rendered using same UI elements. Adobe has integrated a browser built with Webkit. Dekoh lets you use your favorite browser to view both type applications.
3. Application model and choice of languages: The core of the application (‘application/business logic’) needs wide range of services (application model). Apollo provides Apollo runtime and programming using Flex or ActionScript for this. Dekoh applications can be written using JSP, Servlet or simply plain Java. Other engines like .Net or PHP may also be used through thin connectivity layer such as Java-COM bridge or PHP-bridge.
4. Platform Integration services: Providing a secure environment for applications and native services integration (like desktop icons, system tray…) is essential for applications running on the desktop. Adobe is doing this with Apollo services. On Dekoh this can be done through java wrappers like JDIC or native calls.
5. Community services. Since most hybrid application could be building on user-generated content, platform support for social networking could make application development easier. Apollo does not look to be providing this support, but Dekoh Network and web2.0 kind of facilities of Dekoh Desktop, provide community services to applications.
del.icio.us
digg
Technorati 
Yahoo My Web
.
