﻿ What is a WebOS? | ZDNet

What is a WebOS?

Summary: "A webOS is less about being a 'real OS' and more of a human interface for the types of apps that require that quality."I'll move onto a new topic in the next post, but before I do I wanted to clear up some confusion about what exactly *is* a WebOS.


In a way the term is a misnomer, because it doesn't mean a 'real' Operating System in the traditional sense - like Linux or Windows. A better term is probably 'Web Desktop', because it at least moves the "I already have an OS, why do I need another one?" argument out of the way.

In any case, today Mikael Bergkvist from XIN (which just got funded!) wrote a very good definition of 'WebOS', which I'm going to re-publish here because it's so good:

There are many levels of a webOS at this point.

a) A window manager running on the client, where apps are located in these windows as iframes. This is not really an OS, rather a window manager, regardless if they contain the most impressive serverapps avaliable. - Those can be cool too, though.

b) A window manager, where apps are in draggable layers/windows as a part of the webpage, running javascripts supported by a javascript library and possibly by the server with a public API for that purpose. This API would have to have some limitations/restrictions or it would be plain dangerous securitywise. However, everything mentioned above is true for exactly 100% of all webapps today, if only you put a window manager ontop. If this is a webOS, then every webapp online is one too. The same applies if you replace 'javascript' with 'flash' or 'java'.

c) The above, and then also a system for adding/removing apps on the fly, both on the client and on the server. Nice, but there are still things missing. This sounds more like a portal, like Netvibes, doesn't it?.

d) The above, and then also the managing of multiple users and their individual settings. But still there are things missing, and this still sounds very much like a portal.

e) The dynamic negotiation of resources, supervising the apps so that they are as lightweight as possible when running, preventing collisions, conflicts, and making sure they all play nice together, done by the webOS and not the apps themselves. This means that they exist within an enviroment that controls their existence and what they can and cannot do. This is true for apps running on any OS, which is supposed to let you now if you don't have enough memory to run something. It's also true for Windows live's Gadgets, also runnable on Windows Vista.

This is about as far as a true 'webOS' can go as I see it, since there are even more levels, all the way down to the hardware when you boot the machine, which a webOS cannot do, even if you can fake it starting a browser onstart, taking the user to a webpage. - But it's still just faking it.

A lot of the hype driving this webOS thingie seem to be the desire to fake a 'real' OS, and that's another thing that separates the different approaches that I've seen sofar. The ones with a practical and technical reason for it are the ones I tend to root for. Otherwise, it's just the internet hype all over again.

The first window manager using DHTML I ever encountered was Windows ME actually. Now and then I get a javascript-error using the fileexplorer in windows for example, so I guessing it's a dhtml app, albeit hiding it maybe a bit. ;-) There are also some cool HTA-apps that I've come across in this vein.

I have also worked with a lot of embedded systems that have a (d)html interfaces. It's not very uncommon, they can be designed and deployed easily, and be quickly updated when needed to.

On the web, Google has something of a OS going with it's many API's already, and all they would need would be a window manager to tie it all together, but they dont see the point of it, and neither do I, to be perfectly honest. They dont want it all neatly in one place, do they, they run on ads, that's how they make their money, and that means pageviews, lots of pageviews, and people jumping around within Google generates more of those precious pageviews with their displayed ads/links/paid links/etc.

But an email app like Gmail is different in nature..

It makes more sense to have an 'app' feel to it if you have a fairly complex application with a dynamic workflow, like Gmail, where the serverload can change violently from one person to another, because we have different approaches, workstyles if you will, to get things done. You open one dialogue, minimize another, jump back and forth, getting it done as a chaotic human, and not as a rational computer. That was the great alure of the desktop anology to begin with, and Gmail also has some of that 'human element' in it's design, using Ajax to achieve it.

Man is chaotic and using windows responds well to that.. um.. 'quality', it's like papers all over the desktop, but YOU know where everything is, don't you?

In the end, it's not a real OS unless it's GOD for the apps it runs, and has a direct relationship with the hardware. A webOS is less about being a 'real OS', and more of a human interface for the types of apps that require that quality, and about relieving the serverload when there's a lot of apps running simultainiously, that can be open/closed erratically at any time.

This discussion should be where a webOS should be used, and not IF it should be used, based on the (false) assumption that it's somehow a 'real' OS. We know it's not, we didn't design it as such either, it's a interface approach, plain and simple, and the discussion should be where this approach best applies, and how far the 'desktop' anology should be taken online.

Topic: Mobile OS



Log in or register to join the discussion
  • Either way, WebOS makes no sense

    If you create your own "programming language" for the "apps" that run on WebOS - then it IS a real OS, and it comes with all of the attendant learning-curve/adoption issues.

    If you are JUST doing Javascript, then it sucks.

    Javascript should be killed - put out of its (and my) misery. Why not spend your "energy" trying to get browsers to use a BETTER scripting language - then to found a company based on the COBOL of web languages.
    Roger Ramjet
    • Ok..

      "trying to get browsers to use a BETTER scripting language"

      That's just wishful thinking at this point in time, and while we are waiting for this new and bright future of yours, we still need to build better webapps and take into consideration the interface issues related to those.
      • Not really

        All it takes is effort. If you can get W3C on-board - then mozilla and opera and safari/konqueror will follow suit.

        I see three (main) candidates - Ruby, Perl and Python. Ruby is a better-designed OOL than Perl and just as flexible. Python has its supporters, but I would bet that most of them would like Ruby too. This , PLUS the Ruby-on-rails work would make Ruby the likely candidate.

        Ruby and JS (for backward - and I MEAN backward - computability) on every browser shouldn't bloat things too much . . .
        Roger Ramjet
        • Yeah..

          Ok, reality check..
          There's no way this is going to happen in any forseeable future, if at all, and meanwhile you got all these companies online, who are supposed to suspend their onging development, waiting for you to achieve this?
          What you are saying is like 'not really, we just need everybody to support this', and sure, then you can do anything.. but they wont, will they?
          Because they have all these ongoing investments in current technologies and present services, and this is just too far off.
          Html and javascript have been pronounced dead more times than I can remember, but the simple fact remains, it's still here, and it doesn't look like it's going to go away any time soon.
          • COBOL is a disease that cannot be cured

            The only browser that had a chance at breaking the javascript strangle hold was - HotJava. Write the browser in java, then everything that runs on that browser gets to use java (with no slow loading phase). Too bad its the only browser to ever really die . . .
            Roger Ramjet
    • Sadly...

      ... Roger, myself, George Ou, and only a handful of other people on this planet (certainly not in ZDNet) seem to understand this. Ou isn't even a programmer, but he has enough sense to see the truth in what we're saying.

      The AJAX system is just complete kludge. I wouldn't drive a car that was designed the way AJAX apps have to be designed. If cars were powered by a common fuel that caused seizures in about people 20% of the time they caught wind of the exhaust, they would not be seallable, let alone legal. That's how AJAX is. A huge portion of the users can't use it or it pukes or whatever. Yet people keep pushing it.

      Meanwhile, my Web dev customers are delsighted with their super-fast loading sites that use basic HTML and a touch of CGI (for forms), that are accessable by the handicapped, never throw out JavaScript errors, and take only a few days to a few weeks to completely assemble. Oh yeah, and since the search engines can easily consume the site, they consistently get top search engine listings without having to spend a dime on paid, sponsored search. Plus they save a bundle of money on development, and my frustration is lower.

      Who's laughing now?

      Justin James
      • You can't go home

        As I stated in an earlier post, once the users & the market has accepted a feature, you can't go back on it.
        - Not that I dont want to, mind you.
        I really miss the uncomplicated page-based web that was, which had very few javascript errors and focused on readable, useful content, but it's gone now.
        Today, the web has something of an identity crisis, trying to decide what the heck it is and what it's about, but whatever happens, it can't back down..
        Google seemed to be about simplicity at first, but in the end, they started the whole Ajax thing with Gmail.
        Whatever happens next, it will continue to build on this trend one way or another.
  • This

    What is a WebOS?

    [url=https://www.linode.com]This[/url] is a WebOS.
    Albeit a full-fledged Virtual Private Server, and unmanaged with root access.

    You control everything.

    Ajax and browser enabled O/S is futuristic.
    Have you ever tried to write AJAX?
    Not your average task and things like Object Frameworks will eventually make the task of writing AJAX enabled browser apps feasible for the average programmer.

    With VPS, you just send over the entire Linux Desktop with X11 over [url=http://www.nomachine.com]NX[/url].

    BTW, [url=http://developer.berlios.de/projects/freenx/]FreeNX [/url]is a GPL implementation of NX and is not only free, but comes as standard equipment in SuSE Linux.

    Presto chango. (Waving the magic wand now...)

    There. Magic.

    A WebOS! Or better put, a full-blown virtual Desktop on the web, for all intents and purposes.

    Well, not quite that easy, but, I would wager that as more and more VT-enabled servers ramp up you'll see some very smart ISVs purveying this technology as a subscription-based service to the 'general public'.

    Ok, thanks. ;)
    D T Schmitz
  • Ilustrating the need for a web desktop

    This link is to Yahoo's developer site and their API for webapps, http://developer.yahoo.com/yui/examples/container/dialog.html
    and this is where the desktop analogy comes into play.
    This is a draggable dialogue window, where you can input data, click 'ok' and return to the main interface.
    Yahoo is just one of the many big time players that are starting to develop and support this design philosophy.
    When we start building more complex webapps, the conventions we are accustom to from the desktop starts coming into play, and Yahoo and Google both recognizes this, and they have already started to prepare for it.
    Users expect more than before, and up until now we havent had very sophisticated apps online, because there has been no need, noone asked for it, but now they do.
    To solve the new issues, old analogies comes to mind, and the best sofar has been the introduction of a 'desktop' with 'windows'.
    And there's no turning back once the users started to expect something from a product or a media channel.
    For example, who would buy a black and white tv today?
    But when color was introduced, a lot of people thought it would go nowhere fast, that it was just window dressing.
    The web is no longer the relativly uncomplicated interface it once was, and which many still hope for, with clean coded hyperlinked documents in an elegant internet structure - it's no longer 'black'n white'.
    And you know there is no going back, once down this 'slippery slope'.
    It's like in the saying: "You can't go home".
  • Web OS

    I work for a workflow software company http://www.webandflo.com. It has a web interface for designing web applications. You can design them completely through a web browser. Is this a web OS? Well I guess it kinda depends on how you look at it.

    It is in no way a replacement for a currently available OS and there is no way you can modify anything similar to a 'kernel' or the OS itself through the web. It does not have the complexity or functionality of modern OS by any means.

    However it does fit all 5 of the criteria mentioned in the article. Also it is not meant to be a replacement for a modern OS. When I look back to my early days on a VIC 20 I can think of the workflow system as having more OS type features then the VIC 20 OS in respect to it being an operating system.

    I suppose it is all just a question of symantics.
  • A Web OS That Actually Works...

    I found this free Web OS at http://www.gopc.net that worth a look. It emulates a regular desktop but uses Suse Linux for it's framework and is pre-installed with a whole bunch of Open Source applications so there's nothing to install or configure.

    Not sure how they can do it for free but it's cool idea and seems to work really well.

    There's also a funny video of a couple of mad Australians on the website.
  • Soongy webOS

    Current [b]web operating systems[/b] have no chance to be used, if they will not use light weight client side scripts, because browsers not work correct with big amount of client side scripts.