<< Not For You, But With You | The roads I take... | Integration eines Magento-2-Webshops mit FreeFinance und selbstgebautem Warenmanagement >>

Bridging Web and Local App(lication)s

A major belief among a large part of the Mozilla community appears to be that 5-10 years in the future, the desktop or local applications will be extinct, and all we'll be working with will be "web apps".

Now, as with many other things, I don't think this extreme will be the common case (or else we should stop caring about Windows, Mac OS or any other "fat" operating system and all jump fully on ChromeOS) - but I'm sure that "web apps" will play a very much larger role, and I agree that almost everyone will at least use some of those.

In such a future, where the common case will be to use both web and local applications to some extent, probably also with a mixture of cloud and pocket data, it will matter a lot to have solid and well-thought-out ways of bridging their differences and working well with both - esp. for professional and advanced users, who spend a lot of time "in front of the screen" (whatever that will look like).

Also to keep in mind is that pure web applications in the currently done ways pose a problem for some people - I had an interesting conversation recently with a guy working in development aid for some African regions where he said there are entire communities of people that share a 256 KBit/sec Internet connection and things like Facebook or GMail cause nightmares for him.
That surely doesn't mean they should not exist, but those cases need thought, just like cases where you (intentionally or unintentionally) have no or a very bad network connection but might want to do work with your (mobile) computer (device). Not every place where people go in or around this world will have high-volume Internet access available for everyone all the time. We don't even have light all the time on this world, even though life on this planet heavily depends on it, and we have a transmitter right in our neighborhood (well, in terms of what we need there, 8 light-minutes are right next door).

Still, web applications allow the incredible stunt to have the same software on a free and open platform that runs on all kinds of devices with mostly quite permissive licensing. And they allow getting productive immediately, without long install procedures or continuous updating - as well as unprecedented collaboration and other features only the web can make possible.
On the other hand, they're currently one of the worst examples in cross-application consistency, easy adaptation to the personal look and feel preferences and integration with the people's work environments, leaving any current or past desktop environment looking like a champ in comparison.

To improve those situations, we of course need to have possibilities for web applications to cache code and data locally so they don't need to load everything a new all the time, they need ways to adopt to a common look and feel defined by those accessing them, ways to integrate with the work environments - and a richer toolkit of easy-to-use controls to match desktop applications. All those are being worked on by the teams of Mozilla and other browser vendors in committees working on improving HTML, CSS, ECMAScript and other web technologies as well as in implementations in our web runtimes ("rendering engines" is not the correct term any more, I guess).

What we also need, though, are smooth transitions between desktop and web applications - in both ways - and between local and cloud/remote data, both in terms of the user-facing side and in terms of writing applications. We need local and web applications that can work with local and cloud/remote data, we need technologies to write local application with (basically) the same set of technologies as we're writing web applications, and we need to be able to convert one to the other rather seamlessly.

The Mozilla platform already works very much with the a lot of the same set of technologies as the web, so we are in a good position in this area already, but we need to become even better by making the technologies even more similar (and there's a lot that future HTML can learn from XUL, too, even if XUL is being treated a lot like the ugly stepchild nowadays). A lot of awesome things can be done today, but I'm convinced that's nothing compared to what we'll be able to do tomorrow if we follow those paths we're already on to the most part.

And then, I'm quite convinced that there's a tremendous potential on an application that bridges web browsing, running web applications, and running local application code built around web/Internet communications. All those things should seamlessly integrate, work together, be able to exchange data where the user allows it, and give us the power of being productive, social, communicative, efficient, informed, and interconnected all at once. Right now, there's nothing as productive and efficient than fast, organized local application interfaces, and there's nothing as social and interconnected as some web applications. An integrated Internet application could build a bridge between them, bring that together and beat all the single offers out there, and there's none better situated in that particular race than SeaMonkey. We just need to grab the chance and bring it there.

Who is with me in that?

Entry written by KaiRo and posted on September 4th, 2010 18:37 | Tags: future, Mozilla, platform, SeaMonkey | 5 comments | TrackBack



Koen De Groote

from Belgium

WebApps and Local Apps
To quote Walt Mosspuppet: WebApps are for people who are too lazy find the install button.

On a more personal matter: I can not image ever chatting in IRC, in my web browser.

Having the ability to put the individual tasks away in the task-bar is not-negotiable for me. If everything is in the browser, then everything goes down when your browser goes down. That will never be acceptable for me.
2010-09-04 19:38



1) An increasing number of people are actually doing IRC in the browser, with mibbit for example.

2) We're working on having every web page / tab run in its own process, so when one crashes, the rest will stray alive. In the SeaMonkey context, I just hope we can isolate parts of mailnews in the same way.
2010-09-05 01:02

Tony Mechelynck

from Brussels, Belgium

When I run ChatZilla as part of SeaMonkey, is that "in the browser" or not? When my browser crashes, so does my IRC client; OTOH, the browser, mailer and chat "feel" like 3 different applications, and each of them uses a different set of protocols to access the Web; also, when I run Konqueror and Konversation (the KDE applications homologous to Sm-browser and Sm-chatzilla) it's two different applications handled by two different binaries. Actually, what Koen is saying here could quite well be seen as an argument against the whole Suite concept ("if my browser goes down, so does my mailer").
2010-09-05 07:20



Currently, the whole app goes down if the website crashes, I only said we are working on that, not that we are there already. SeaMonkey doesn't even have plugins in separate processes yet, though it looks good that we will have that in 2.1 (hopefully by beta).
And yes, the different parts of SeaMonkey feel way too much like different applications while running in one. That's something we need to work at.
My whole article is talking about the future, not the present.
2010-09-05 13:44

Frédéric Buclin

from Switzerland

We should stop relying on the Web for everything. I want to be able to run apps without being connected to the web. I want to have all my data stored locally (much easier for backups and when my connection is down). I don't trust remote servers to store my data. They could suddenly change their policies and start using them for statistical analysis or to advertise users or what else.
2010-09-05 16:50

Add comment