On embracing the web

HTML is not the Holy Grail

There were a few talks at GUADEC that were around the topic of web and trying to figure out ways to build bridges to the web world from the GNOME community and technologies.

It was praised by some, most notably Luis Villa, that HTML/CSS/JS was the way to go. However I think that this is grabbing the stick from the wrong end in many ways.

The interesting parts of the web are not its front end technologies as such (the fact that they are standards and you can assume everybody has a browser is though). The interesting bit of the Web as a platform is the ability to syndicate, publish and aggregate content.

I actually think that the so called fact that people love HTML+CSS+JS is sort of a myth. The reason there's so many people doing stuff with it is not because it is a great technology, it's because:

  • You can reach a huge user base deploying a web app
  • It has a lean learning curve

People go through the pain of building apps with these technologies because it's worth the pain, and actually, for a lot of applications it's the better option. But it's still a pain.

However, suggesting that this is how GNOME should move ahead is in my opinion not the fastest path to provide a great user experience. Which is what GNOME is all about.

It's all about the data!

In my opinion, what we really fail at is at providing tools to create rich user experiences for data driven applications, and ways to feed data from the web more specifically. This has a lot to do with the poorness of our platform when it comes to ways to talk HTTP, libsoup for example is not such a great API for application developers for many reasons.

Then there's Gtk+'s lack of proper views for large datasets and GtkTreeModel is not necessarily a general purpose data model API. This is why, by the way, we developed libmodel at Codethink and created a GtkTreeModel wrapper around it.

I think the ones really pioneering in this field are the Intel guys with libsocialweb and Adrien Bustany on online providers for Tracker. But we still miss the "glue" for our great front end technologies (Gtk+/Clutter/MX) so that application developers can put together apps consuming and pushing online data real quick.

The browser is nice and all but…

There is a reason why Google, one of the main pushers of the web
technologies, still have Java based apps in the android platform. There is a reason flash is not going away and Silverlight and JavaFx are here to stay as well. The
closer you are to the hardware, the better the user experience can be. The quicker you can put together your apps, the better.

Pushing the boundaries of HTML is a nice thing and I'm happy to see Flash, Silverlight and JavaFx going away as substitutes of content that could be deployed as web content in the first place, but innovation and design by committee are not real good friends. We need a platform that can move as quick as hardware does, as much as we need a web platform as well that can cherry pick the innovations

Opportunities for collaboration, our friends from Mozilla

G3428

There is however a huge opportunity for the GNOME community, if we start making steps towards a better toolchain for data driven applications, I think building bridges with the Mozilla community can be a major win. I know what you're thinking, Gecko. No, I actually think WebKit is the way to go as our rendering engine, Gecko is there to follow Firefox's agenda. Fair enough.

There's a space in which building bridges with the Mozilla community can be even a biggest win for both ends, the web services space. Mozilla is creating amazing web services and tools, Firefox Sync, Bespin, Contacts.

GNOME seriously lacks of a community of people dedicated to build web services around the platform, and Mozilla is has that sort of focus. Together I think we can join forces solve this ongoing problem of closed source web services and all the privacy concerns around them by building a truly rich and open ecosystem of server and client side technologies.

Advertisements

16 thoughts on “On embracing the web

  1. In short: we need to offer more online data storage like Tomboy Online possibly formalizing privacy and security policies for this hosting. But first, we need hardware, bandwidth, and people. Hardware and bandwidth could be donated, of course. I can’t help but think the Foundation is a little strapped right now trying to boost the 3.0 launch, however.
    Another option would be to extend libgdata and libraries like it to make it trivial for GNOME application developers to make use of third-part online storage backends. (Think syncing your Epiphany bookmarks or GNOME Games high scores to your GDrive, if Google ever launches it.)

    Like

  2. @Jason:
    I’m more concerned with the lack of web developers in our community than with the lack of hardware/bandwidth.
    As per the libraries, I think what we lack is a coherent story for software developers, the pieces we have are not really coupled in any way for them.
    But yeah, overall you have a few good points there.

    Like

  3. I agree about the lack of libraries: for example, when it comes the moment to add miner-rss in Tracker I had to create my own RSS Glib-oriented library (isolating the usefull code from the Liferea core, which is just a mess), it was quite surprising that even the so common syndication duties were no managed by any existing shared library.

    Like

  4. Wow. We actually mostly agree on something. 🙂
    I don’t think having a billion different libraries to deal with all the different services, is important at all. As a developer, I don’t want to have to go add more new code/ui/etc… to my app, every time some new web service starts up. All I should have to care about is that I want to get a certain class of data, or store it somewhere if need be.
    There really should be ONE library, with a stable API that all GNOME apps can use, and the actual pulling from and pushing to of data with different services, is done in a separate process.

    Like

  5. @Rodney, you are describing Conduit.
    I wrote it two years ago with this exact goal, in fact it already does many of the things you describe. It even got accepted into GNOME as an external dep. Then no-one used it, no one helped me maintain it so I gave up and started a PhD instead.

    Like

  6. @John Really? I love Conduit and was hoping to contribute to it as my programming and GNOME knowledge increases. Maybe it can be resurrected.
    Anyway, could not agree more Alberto. In fact, it’s one way I feel MS has the right idea – desktop software which harnesses the power of the cloud at the backend. We can’t let the desktop die!

    Like

  7. @John
    I am not describing Conduit. Conduit is about synchronization, which is exactly the wrong answer. Having the same data everywhere is the wrong way to try and solve the problems.
    Tracker is somehwat closer to what I’m describing, though not exactly what I’m looking for.

    Like

  8. @Trevor
    You must let the desktop die. Trying to keep it from dying is the exact problem with GNOME, Windows, OSX.
    The term ‘desktop’ must stop being used. It makes absolutely no sense in modern computing and the way forward.

    Like

  9. “The closer you are to the hardware, the better the user experience can be.”
    Umm, the more like a browser, the better the user experience usually is. The browser gives me a zoomable UI, text selection everywhere integrated with a great context menu, View > Source, a consistent native way of dealing with links, the deep innovation of URLs, the incredibly powerful navigation metaphors of back-forward-bookmarks-new tab built on URLs, etc., etc.
    Whenever possible, do stuff in the browser. Face it, your beloved desktop interfaces are just the thin strip underneath or above the browser window where users do most of their work.

    Like

  10. “I actually think that the so called fact that people love HTML+CSS+JS is sort of a myth.”
    Yeah, it’s more like people hate them less than C and C++ 🙂
    However, in my experience using declarative languages like HTML and CSS for describing the UI is much better way to do it than using an imperative syntax. Even if browsers have their quirks, IE6 is still not dead, etc., the basic model for developing UIs is actually quite good compared to a lot of the traditional desktop widget toolkits.
    You also get a natural separation of roles with web technologies: UI designer, front end developer, back end developer. These people have different skill sets, yet they can effectively collaborate thanks to the flexibility of the technologies.
    It kind of validates the web dev way of doing things when many programs are starting to use SQLite for local storage and Qt and JavaFX are using CSS-esque declarative syntax for UI and Javascript-esque languages for scripting.
    The question is, will Gnome decide to take the benefits of web development to the desktop (as Nokia is trying with Qt) or take desktop development to the browser (which is what Google wants to do)? I don’t know which option is better, but the latter is a lot easier. The former means trying to compete with the likes of Nokia and Microsoft, who can afford to spend big money on their toolkits and marketing.
    Caveat: I’m writing under the assumption that Gnome wants to gain developer mindshare. If the goal instead is just keeping existing Gnome devs happy, my conclusions might be wrong.

    Like

  11. @Random Guy:
    Moving to the web is not easier than coming up with something to compete with QML or XAML. Both have quite big challenges and positive things.
    However, the amount of innovation you can come up using HTML5 is capped by the amount of features you are able to expose in a browser which is my big concern.
    In many ways, HTML is playing catch up with Flash, Silverlight and friends.

    Like

  12. @Rodney
    Please trust me qualified to describe the features of the application I wrote. Synchronization was but one use. Everything else you describes in your post was/is possible with conduit.

    Like

  13. @Alberto Ruiz:
    I agree that there are challenges in web development too. For the record, I don’t think the desktop is dead 🙂
    However, if Gnome developers pursue the first route, they’re working alone. Nokia pours money on Qt? Great for Qt devs, but it’s not much help for Gnome. The second route is much more collaborative. Google pours money on Webkit? Gnome can use the improvements immediately.
    I think ultimately it depends on what the Gnome community thinks they can accomplish and how big changes they are willing to make to attract new developers.

    Like

  14. @Random Guy:
    I think you overestimate the value of money pouring, and at the same time, underestimate what a community can achieve with enough momentum.
    @John:
    I don’t think people ever understood Conduit as an actual platform component. Specially because it was presented in a form of an app, no app integration or client libraries was ever pushed enough.

    Like

  15. @Alberto:
    Fair point. TBH this is the predominant reason I have backed off FOSS development. I could not handle the cheer-leading that is required to accompany the development of a FOSS app.
    Now I just write code for fun and post it on my github. School takes most of my time now anyway.

    Like

  16. @John:
    Well, there FOSS and there’s FOSS, GNOME is quite a large community these days and a lot of the efforts are more about the politics than the technology.
    Don’t think is necessarily a bad thing but it does harm sometimes.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s