I’m (quite:-) closely following the Morfik saga since late 2005 and did have many long discussions with Aram, Fuad, Mauricio and Shah about direction in the past three years, sometimes pretty heated chats about the vision and execution, so I’m not an unanimous supporter of everything Morfik, but version 2 is a very significant step in the good direction.

The new visual design concept with themes, states, popup customization, etc. is a major step forward for web application design. I see real innovation here.  Go and check out the tutorial videos, it is worthwhile! I wouldn’t say that I’m fond of the sixties look of the new demo apps (and of the new Morfik site itself), but the design flexibility is impressive and the functionality seems to be very well thought out.

I’ll be looking into the new version in the coming days and weeks (we do have some projects that now will have to be ported anyway, especially our PMAP controls and libraries), so stay tuned for new comments to come.

First of all, do read the comic strip by Scott McCloud and the Chrome Team. It is in itself a piece of marketing art and although its primary intended audience may be journalists and less technical people, it is a statement of how serious Google is about Chrome and full of hints for conspiracy theorists among us.

So some of my first thoughts will follow…

OS-within-the-OS

Chrome will be the OS-within-the-OS for Google: most productivity and line-of-business applications can now be successfully turned into web applications. Arguably more and more of them are better in ease of use than the original apps, due to the richness of the platform and due to being re-engineered from scratch (UI wise) with many usability lessons learned since.

The big issue is compatibility. There are at least four major players now: IE, Firefox, Safari, and Opera (plus the mobile editions), and their abilities are spread on a wide spectrum, to say the least. The unquestioned market share leader (IE) is trailing behind in almost all important areas (like performance, usability, standards conformance) and there are subtle but important differences among the others. This makes web application development very costly and time consuming. Even with frameworks like DOJO, Prototype and tools like GWT and Morfik you will encounter compatibility issues and missing functionality (e.g. lack of a consistent graphics layer, like SVG or Canvas).

If we had a browser that

• has #1 market share,
• is consistent among all the major operating systems (Windows, Mac OS X, Linux) and mobile OSes like Android and iPhone OS X (probably Symbian and Windows Mobile, but I would not hold my breath for those),
• is performant, secure and robust,
• and has some additional features like support for off-line operation, a strong graphics layer (for graphs and graphical apps), sandboxed native filesystem access, support for push technology (like COMET), drag & drop desktop integration, and a mature, efficient and familiar development platform (e.g. Eclipse/Java/GWT),

then most applications can be implemented on this platform regardless of the underlying native operating system.

Just think for a second when you used Microsoft Word the last time: I used to be in-and-out all the day, but recently it happens that I don’t open Word for weeks, and then only to edit a “legacy” document that originated from the “old era”. Most of my new documents are emails, Google Docs, or some other on-line properties (god, what that does to privacy, though, so don’t put all your documents on-line!).

Technology tie-ins

There will be technology tie-ins all over the place. Although Google is a huge animal and its projects are only loosely coupled (waving off the monopoly power arguments), saying that the Chrome team accidentally asked the Android team about WebKit love is amusing.

Gears integration is only for starters. I expect that GWT and Chrome will be “optimized together” pretty soon. Google Docs, Maps, etc. will gain in performance, stability and functionality if run on Chrome.

Then the primary business of Google is ads: now it will be able to collect even more information about us (although since gMail and Desktop Search they already have some data on you ;-).

BTW I wonder when Desktop Search will be integrated into Chrome…

Head start

Chrome may have a head start over all other browsers.

Current generation Firefox, Safari and Opera are pretty level on performance (relative to lackluster IE) and at least Firefox and Safari are engaged in further speeding up JavaScript with adding virtual machines similar to Chrome’s V8 (on paper); they are also keen to match each other in standards compliance and usability, but while Chrome addresses all these issues, it also brings a new architecture to the table with the promise of marked enhancement in security, memory performance and robustness, plus the native integration of Gears.

The others will have to play catch-up. And Google has the resources to compete — it is single-handedly financing Firefox at the moment.

Market share

In order to be successful, Chrome will have to establish market share.

In the consumer space all the good virtues (speed, stability, security) will play well, together with the hippie word of mouth marketing of comic strips and oh-so-accidentally-released-a-bit-ahead-of-time trickery.

The much harder nut is the corporate market. It takes years for corporate IS departments to certify products for use. Here being OSS will help (the corporate world is getting into love with OSS), but the primary message can be security: if Google can deliver on its promise of security (both process separation and malware filters), it will be salvation to IS departments fighting with the dilemma of supporting more and more intranet/extranet web applications and weak security of the very same applications.

Being a consistent web application platform on all important OSes will also come handy – it makes corporate web app development much simpler.

Google will definitely push Chrome with subliminal tactics (e.g. “off-line mode and advanced features of our web apps working best with Chrome” splashes).

Still, it will be a hard sell — they’ll need some killer apps to get rolling.

Missing bits

I’m also missing a few things, the most prominent being additional web application security.

Chrome is a rich client platform, and rich clients run most of their code on, well, the client. This used to be the case with traditional apps, but those were compiled to binary, so poking around required some skills. Now Web 2.0 rich clients are generally made of JavaScript, which is quite readable and even can be changed on the run, making attacks against the code much easier than before.

Of course tools like GWT or Morfik will scramble and optimize the client code making it not a pleasure to read, but it is still the source code of the app that is downloaded and run in the browser. So it would be fine if some kind of run-time protection would be in place to prevent code morphing and allow code verification. The fact that each tab runs in its own process is promising, though.

Phew! So here are my first impressions — what if I stared thinking about this :-) Now it’s your turn!

What’s going to happen? The winners are going to do what worked at Bell Labs in 1978: build a programming language, like C, that’s portable and efficient. It should compile down to “native” code (native code being JavaScript and DOMs) with different backends for different target platforms, where the compiler writers obsess about performance so you don’t have to. It’ll have all the same performance as native JavaScript with full access to the DOM in a consistent fashion, and it’ll compile down to IE native and Firefox native portably and automatically. And, yes, it’ll go into your CSS and muck around with it in some frightening but provably-correct way so you never have to think about CSS incompatibilities ever again. Ever. Oh joyous day that will be.

Good to see that other visionaries have the same vision, too :-)

Dan Webb has some important thoughts about the Flash v.s. Ajax debate and the comments on his site and on the Ajaxian site are also thought provoking.

Indeed it is anyone’s guess how WPF/E, Flash/Flex/OpenLaszlo, AJAX (Backbase, YUI, Dojo, Prototype, Qooxdoo,…), GWT, Eclipse/RAP and Morfik will mature but this year will be definitely very interesting for web application development!

I won’t repeat the press release at the MorfikWiki site. What’s important, though:

• Morfik has improved tremendously in the last two months;
• stability is much better;
• the Framework is streamlined and got rid of some fat (more about this later);
• there is now good documentation in the form of the Developer’s Guide by Mauricio Longo (excellent, even I could learn a few new things;-) and the MorfikWiki site (that contains some of my tips and overall will be a perfect platform for documentation).

Stoicho just released a blurb at his “The Morfik Watch” blog about the release and he is also amused by the name (Morfik 07) and how close it is to 007: IMHO it would have been more appropriate, considering the disruptive lethalness of the new technology to the current, stone-age way of developing web applications :-)

“Sitemaps are an easy way for webmasters to inform search engines about pages on their sites that are available for crawling.” (sitemaps.org)

Their solution does not in itself solve the AJAX problem but can augment my proposal quite nicely ;-).

ACAP (Automated Content Access Protocol) is a new initiative from the international publishing community to turn the challenges facing the industry from web technologies (especially search) into opportunities in a win-win way, and as a side effect can help Web Applications out, too.

First a summary of the publishing angle.

Right now major search engines (especially Google) are crawling (retrieving), indexing and storing web content without being aware of the special needs of publishers. This leads to well documented cases when Google faces charges of massive copyright infringement for its activities. In some special cases Google stores a copy of content publicly available on the net, and later when the publisher changes its policy about a particular piece of content (going from public to a fee or membership based structure) the content is still present in the search results of Google and can be retrieved from it.

It must be underlined that Google (or other search engines) cannot be faulted (at least morally) for doing this since they are indexing millions of web sites automatically and it is impractical to implement special cases for certain specific sites at this scale. On the other hand, publishers do have their moral and legal rights to protect their intellectual property.

A special twist of the situation is that for publishers it is indeed important to be indexed: this helps them to generate major exposure for their content.

This creates a challenging case that seems to be a loose-loose situation: either search engines are constantly sued for copyright infringement (where they can fight back with fair use, etc.), or publishers instruct the search engines not to index their content at all (e.g. with robots.txt) that means lost exposure and thus lost revenue.

An important element of the case is that both parties want to cooperate so if there were a technical means of communicating the intentions/requirements of publishers, it could be converted into a win-win opportunity.

That’s where ACAP comes into the picture. The publishing community has decided to establish a standard way of communicating permissions information, that can be automatically adhered to by the search engine crawler.

Technically it is a challenge to implement such a solution. Although there are a handful of major search engines, there are literally millions of publications on the web that are created and maintained with a lot of different tools in varying structures. Thus such a solution has to be established that can integrate well with all these various platforms and technologies.

In a well designed solution search engines would be able to index even copyrighted material and during a web user search session return only contextual excerpts with proper attribution and in case of non-free content even pointers to how to access the full content, thus creating an invaluable means of dissemination of such content. This could be augmented with publisher-provided taxonomy and auxiliary information that would help the crawler to set the Page rank (or similar) of the particular material.

Now how can this be utilized for Web Applications?

Of special interest is the upcoming Web 2.0 and web application technologies that make it very difficult for crawlers to index content properly. ACAP could be extended in a way to solve this issue so that search engines would benefit from an easier to crawl content with better signal-to-noise ratio and publishers would be able to have fine-tuned search results.

A trivial way of making AJAX apps search-friendly is to fundamentally prohibit indexing the AJAX application itself and direct the crawler to an (otherwise “inaccessible”) area of the site where all the information that the content owner wants to be indexed is available in a search friendly form. An interesting twist is to use such an URL scheme, that when the web server detects that the incoming request is not a crawler, then it redirects the request (based on the URL) into the AJAX application.

This way crawlers would only receive content that is really valuable, they would be more effective with less effort and search results would improve significantly. Content owners would be able to make their AJAX sites searchable the way they like it.

Combined with ACAP (for IP protection) and with the probable extension of the protocol to include “nice permalinks” in the searchable content into the AJAX site this may be a good solution for search in the Web 2.0 era.

Would be a way cool project to work on the specification/implementation…

Fortunately, Pong and Sweeper have made onto the list, but they need some promoting to get into the top ten, so do not hesitate!

Ed has some good ideas on Pong and Sweeper features that I should add ASAP.

Notable items are: the context menus, a direct-mode graphics canvas, inline popup windows, and server-sent
events.

The latter is especially interesting for load/performance considerations: fundamentally all web applications have to maintain a channel to the server to learn about events that are important for the user (think of a chat app, for example). At the moment this is done by the client (browser) periodically polling the server, which is a recurring load for the server (it happens even if you are not doing anything). The server-sent events technology promises to turn this into server-push: the clients will not have to poll, and the server will rather push the information to clients that are interested.

Opera seems to be the first to implement the technology in the 9.0 browser. It seems Opera is working hard to become the darling of web applications developers: first their rendering and editing improvements, and now this starts to make Opera a very compelling platform for web apps.

Morfik is (in my view) not one technology, but rather a synergic integration of technologies with the ultimate goal of making web application development much more efficient than it is today.

There are many specialist tools on the market, some for web UIs and AJAX, others specifically for efficient browser-server communication, then frameworks for server-side operations, database access, etc., which are very professional and high quality in what they are doing but these are all separate initiatives and integrators are very few and far between. Then there are things like Ruby on Rails, J2EE, .NET, etc. that do play the integration notes with varying success. Sometimes not enough coverage, other times big complexity or prohibitive costs inhibit application for small to medium real-world problems.

That’s why creating web applications today is a challenge: you have to master many separate technologies and make sure that they work together harmoniously that puts a great burden on the developer, and instead of focusing on the business case we have to deal with low-level technical details (which is fun in itself, just a bit frustrating when deadlines loom).

Just think of this question for a moment honestly: how many times did it happen to you that you had a great plan for an application, but as the deadline approached and show-stopper technical issues arisen you had to cut-cut-cut the really valuable functionality to deliver on time/within budget? The resulting solution is OK, but far from the vision.

Morfik right now integrates the web UI, efficient browser-server communication, server-side business logic, database access, the web server and database system itself, interactive UI editing, the build process, debugging and profiling in an integrated development environment. This is already a powerful combination: all you need is to develop first-class web applications is a machine with an operating system and the Morfik WebOS AppsBuilder. Can any other tool match this simplicity? If they make sure that the platform is open and ready to absorb additional third-party technologies with ease (as it is demonstrated with the current UI toolkit integration) and consistently, then they can embrace the OSS community (some OSS-friendly steps would be welcome:-) and commercial toolkit developers too, to augment the system with additional components so that we can have the same kind of component ecosystem that makes Windows RAD so efficient.

There is still a lot to do, but the potential is there.