Blog Archives

Speculations on Google Browser (GBrowser) ?

I have read this morning an article speculating on the arrival of a new Browser on the market, a Browser labelled “Google” (or Gbrowser).
The few readers of my blog can immediately imagine that this is not the kind of news that I would have liked to hear. I personally do not like this invasion of things from Google which, under the cover of being “free for everybody”, tie us to a new monopoly (see my previous post “Internet Search should be property of no one“).
I state this even if I have no problem admitting that most of the technologies that Google, in its immense altruism, offers us are very cool and really innovative and really pushing for significant progress in the Web space.
The problem is not around how cool the presents from Google are… it is about the concept of “present” itself !

Anyway, in this specific case (GBrowser… yes, you can see that the domain name has already been registered by Google!) I think that, if the speculation actually reflects a reality, it may become something very significant, and perhaps not completely bad.

If really Google will put on the market its own branded Browser, I think that :

  1. Google will finally admit that some “footprint” is required in order to properly run today’s internet applications (this will have consequences on AJAX as we see it today, I think)
  2. Google will automatically transform what they published as “contribution” into a de-facto standard (because it will be working naturally with the new browser….)
  3. Google will create a platform onto which developers will build RIA applications

Yes, in the last bullet I wrote “RIA applications“. Because, if the Browser from Google will become true, it will obviously promote the use of Google Gears and of all the other G* things that invaded the web. A couple of months ago, I wrote my first reaction to Google Gears:

[with Google Gears] Google starts to install something else than the browser in order to keep the browser relevant”

The advent of Apollo AIR (paved by Flex) and the approaching of Vista (via Silverlight) may create serious alternatives for running applications delivered over the internet (see here and here and here for a summary of my opinion on this topic); the default mean to access to applications delivered over the net, will no more be the browser, at least when some significant experience and richness of functionality will be required.

Will Google redefine what we know today as “the browser”? Will Google remove the impedance that somehow forced the two main actors in this space (IE and Firefox) to comply (at least formally) to standards?

Again, if Google will indeed go into the Browser business, all what it gave away so far could be interpreted as a way to create “addiction, so that people will find it normal that Google will also revolutionize the browser space. After all, Google is not perceived as the “bad boys in the block“, so it is likely that this move will find only few opposers.

Despite these considerations, though, I initially wrote that this may not be a bad outcome for the web. My readers know that I consider that the browser needs a big evolution in order to support the new challenges and the execution of applications delivered over the internet. So, this move may represent a shock that will benefit the whole community.

I wished Firefox and XUL could have become this shock!!!! Perhaps they will anyway (why wouldn’t the GBrowser be based on Firefox after all?)

Of course, this is all speculation at this moment….

Firefox as a Phoenix

I am starting to digest and sediment a series of articles that recently popped out on Mozilla. The one who hit me most was Chris Messina’s Thoughts on Mozilla, but also Alex Faaborg’s Web2.0 Expo presentation. I will certainly add more comments in the next few days.
For the moment I would like to comment on the Innovation aspect.

Imho, Firefox should not bet its future on “being the best browser”. In this way it will simply set its path, in one way or the other, “on respect to something else” (notably IE).
What the user interface of Linux already did (KDE or Gnome for that matter) in trying to, first “catch” and, then, “be better than” Windows… did not produce any significant result in terms of innovation (in fact if the price wouldn’t play a role, most of the people would choose a Mac because of its interface, certainly not Linux).

So, if from the phoenix (of Firefox as we know it) could raise something new, a platform where applications delivered through the web could be executed, then, I think, it will be great. Yes, certainly, this is the domain in which Adobe and Microsoft are also directing their efforts (I tend to agree with Scoble that JavaFX is more for the mobile-phones) .
But Mozilla could consolidate the effort from the Open Source community and this would be really a great advantage.

Let’s dream about XUL+SVG ….

Does JavaFX Spell The End Of ….?

Strange logic in this article titled Does JavaFX Spell The End Of AJAX? After reading it I would think that the title would better be Does JavaFX Spell The End of Swing?

Flex opensourced: the battle of the giants. Towards a new Rich Client?

So, just few days after Microsoft announced its SilverLight platform, Adobe answered making Flex an Open Source platform. I suggest you have a look at Scoble‘s page “Adobe opensources Flex“, especially for the two videos he recorded with some of the Adobe thinking heads.

Wow! How things are changing fast!

There is one consideration that I want to make here. Now, both Adobe and Microsoft have the following approach to their flagship UI technology:

Microsoft Adobe
Express – Entry Point SilverLight Flex
Full Product Vista –
Windows Presentation
  • An “entry point” offer, freely available or even Open Sourced, which paves the road to the flagship product.
  • In both cases, the technology behind is the same (MXML/ActionScript for Adobe and XAML for Microsoft). In both cases, the technology behind is Declarative!
  • In both cases, the Entry Point offer is helping making more popular, especially with developers, the technology, so that it can be more used as the basis for building applications using the Full Product version.
  • in both cases, the Entry Point makes a tactical use of the Browser (at least, in the Full Product version the browser is not playing the important role that we are used to)
  • in both cases, AJAX is used as a programming approach instead than as the overarching foundation.
  • SilverLight

    I have been reading about SilverLight, the new technology from Microsoft that has been labeled as the Flash-Killer.
    What I find interesting is that the positioning of SilverLight on respect to Windows Presentation Foundation (and Vista in general) from Microsoft seems, to me, very similar to the positioning of Flex with respect to Apollo from Adobe..

    It is very much another example of a client-side container that replaces the role played by the Browser so far. With this move, not only Microsoft provides container functuionalities inside the Operating System itself (WPF) but, also, provides an “express version” of it (SilverLight), which does not require Vista and that can work on the Mac.

    I am still unclear why Microsoft does not also target Linux. But, probably, there will be someone who will do on their behalf….

    Are Mashups Web-based only offering?

    An interesting article “Barrelling Through The Web 2.0 World” highlights parts of a recent Gartner’s report on Web2.0. The article features my friend and IBM colleague Dan Gisolfi.

    I extrapolated the sentence

    Who is to say the mashup has to remain a Web-based offering ?

    because I think that it is very interesting… Not because of its “Web 2.0” bias (as the article implies) but because of the implications that the mashup technology could have well outside pure browser-based technologies.

    Web-based technologies go well beyond their utilisation in browsers. I think that they have their place in Rich Client applications also.

    I am thinking here to technologies I know, such as Lotus Expeditor or Lotus SameTime. Where the Composite application model actually allows the integration of content and application delivered over the internet with content and application aggregated from the enterprise SOA.

    Thoughts around REST

    It is quite sometimes that I have in mind to write down this little comment. I know that, in doing this, I am probably going to be ignored or to be blamed.
    But, for all my readers, I am doing this exercise with true humble and open spirit; I am sure that many things I write here represent only a part of the truth, perhaps so little a part…. or perhaps no part at all 🙁 My objective is to understand where I am wrong: so, please, accept my apologies in advance. After all, the motto of this blog is to have “opinions”…. not “truths” 😉 !

    So, here is what I do not like in the REST Hype that is around.

    • despite it is “de facto” the way the Web works, REST is counter-intuitive to me.
      It is counter-intuitive because since when I first started to program, I was told to use “subprograms”.
      And, when I moved to Object Orientation, I was told to invoke methods on objects.
      In summary: if we need to use an “addressing space” that is as wide as the whole Internet (and, not simply constrained by the virtual memory given to my executable), I do not see why I should change the way in which I am programming…why should I avoid the “invocation” paradigm ?
    • I think that REST does not add anything on the top on SOAP (or its XML-RCP ancestor).
      It is isomorphic to SOAP. Just using “nouns” instead of “verbs” simply shifts the complexity from one part to the other…. with the side effect of making the things less clear (at least for me, as I am used to add meaning to the verbs I use to describe “actions”)
    • I think that REST assumes that the world is painted with one color only: stateless.
      The reality is seldomly “stateless.
      A lot of times, it is “stateful”. And, maybe I am wrong, but I think that it is better to consider “stateless” as a subcase of “stateful” than the viceversa.
      Statelessness is great for scalability; of course! The Web is so scalable because it is stateless; sure! But, here we are not talking about pages, we are talking about an “addressing space as wide as the whole internet. We are talking about applications that use such a big space.
      I understand that the use of REST makes it possible the different caching levels the internet provides; but in so many cases, the data that are manipulated by internet-wide applications are changing so frequently that caching is not an option.
    • With REST, the “state transition” is in the protocol. I am used to manage the “state transitions” in my code.
    • I fear that REST brings back two-tiers architecture.
      Issuing GET, POST, PUT and DELETE operations on remote resources looks, to me, very much like performing CRUD operations on a remote database: something we have learned not to do.
      I understand that the implementation of a REST service makes sure I am not actually accessing the physical row in a database… but this is true for any RDBMS, actually.

    I realize that an important part of the hype on REST is due to the fact that SOAP is so complex!

    And I agree that REST is, certainly, a great way to address resources; it is really great when you can easily put an URL into some code and create those cool mashups!
    But I would not like to extrapolate that, since something is so easy to use, then it is the only way (or the correct way) to accomplish a given task.

    As I said, these are just few thoughts that I have in mind on this subject. I know that there will be arguments to address each of those concerns and to take me back on the “right way of thinking“….

    P.S. : By the way; few of the previous thoughts would also apply in favor of an RPC approach to WebServices!

    • RSSRSS
    • Social Slider
    • RSS
    rss Follow on Twitter facebook linkedin