Google announced today the availability of a new open-source browser plug-in, Google Gears, that promises developers the ability to create applications that work within a browser – even without Internet connectivity.
Google announced today the availability of a new open-source browser plug-in, Google Gears, that promises developers the ability to create applications that work within a browser – even without Internet connectivity.
I was discussing the future of Google and application platforms just the other day, and we reached a conclusion that Google has a major problem with the fact that the user has to rely on an internet access. Moving browser applications to a local platform will surely be a great leap.
Just imagine “Google Spreadsheets” represented as a shortcut in your applications menu. Clicking it launches your browser and then wupti, you have a spreadsheet application.. totally equal to any other spreadsheet application except that it doesn’t take up so much hdd space and the user interface could be just about anything – not just standard Win32 or GTK.. and updating the program would be a breeze, printing it would be a breeze, customizing the code would be a breeze… and most importantly: Creating cross-platform applications would be a total breeze!!
You forgot the fact that it’s also going to be slower and probably still lack TONS of functionality.
Yeah it’s called XUL and it works great!
The site says “Google Gears (BETA) is available for Windows, Mac, and Linux”, but I couldn’t find the Linux or Mac version.
Is there any response from them on why they didn’t use an existing framework to develop their application in?..for example flash.
Edited 2007-05-31 18:20
From what I read it requires Firefox (which I am currently downloading in order to test that Google Gears thing)
well, initially I was wondering if there’s a Windows version because I visited the Google Gears page on Fedora 7 and there was a button Install for Linux and below it there’s a requirements section which listed Linux as required OS 🙂
I’m running linux and firefox and it installs just like a regular firefox plugin. Didn’t have to search for it.
I tested it a bit and it’s very interesting technology!
You could write cross-platform applications who work off-line and later synchronise with on-line data. That is just awesome but coding a total application (like a GUI one) is so much work you could do it faster in Flash or Java.
Hopefully they will develop a new scripting language who can replace HTML/JavaScript with something that is easier to code and still is cross platform and cross browser (although IE doesn’t do a good job at JavaScript at the moment either).
Java webstart is better and now with javafx you can create java2d application (flash like ) more easily.
Coding standard application in javascript for me is pure s*it…
Javascript is a fine language. Using a toolkit like Prototype will solve many of the cross browser issues.
Refried java applets (aka: javafx) doesn’t sound like much fun to me.
You obviously do not know much about JavaFX if you think it is “refried java applets”.
-G
You obviously do not know much about JavaFX if you think it is “refried java applets”.
Sure I do. And that’s exactly what it is.
Yes. Javascript is a fine language. It’s so easy to debug cross-browser problems. Every web browser has excellent support for Javascript debugging. It’s wonderful. Building really large Javascript apps is great too because the dynamic typing never makes you sit back and scratch your head and wonder what you’re supposed to pass into a particular function. It’s also nice that Javascript separates things up into their own name spaces so you don’t have to worry about variable or function naming collisions when you start including third-party Javascript libraries.
</sarcasm>
Yes. Javascript is a fine language.
Indeed it is.
It’s so easy to debug cross-browser problems. Every web browser has excellent support for Javascript debugging.
I rarely ever have a cross browser javascript problem (in the past I’ve had issues with certain regular expressions in IE). More likely I’ll have a cross browser css problem.
It’s wonderful. Building really large Javascript apps is great too because the dynamic typing never makes you sit back and scratch your head and wonder what you’re supposed to pass into a particular function.
I’m NOT getting into the whole dynamic typing vs. static typing debate. It’s been well covered before, and I certainly have no problems with a dynamically typed language.
Also, if you’ve never used Firebug, I highly suggest it. It allows you to inspect and interact with javascript objects on a live web page.
It’s also nice that Javascript separates things up into their own name spaces so you don’t have to worry about variable or function naming collisions when you start including third-party Javascript libraries.
It’s not my problem that you are using crappy third party libraries. The ones that I use handle name spaces just fine. You DID read my comment about Prototype, didn’t you?
Yet Another Buzzword…
This is nothing but what has been possible all along. And the word “webapplication” is a misnomer. This is not a web-app but a browser-app. Two quite different things. Webapps can run without a browser, and a browser-app can run without a net-connection.
What is done here is simply caching the app locally in an effective way (opposite the normal lousy caching so far) using the locally cached copy instead of downloading the app every time it is used.
Big words for nothing, as usual. We did this already in 1997. It just didn’t have a word.
Did you even look at what Google Gears does? Saying that it’s just a glorified web cache is naive at best.
Google Gears provides a local relational database for web applications (or browser-app to satisfy your pedantic definition). This means I can store whatever data I want locally. That goes far beyond mere caching.
Granted there are other people developing similar technology (Mozilla, Dojo, Zimbra). It looks like Dojo is going to migrate to Google Gears instead of Flash for its API. The Mozilla solution is interesting but specific to Firefox. I haven’t looked at Zimbra in detail.
And sure you could do this with a Java applet but Google Gears loads up much faster than an applet would.
I did take a look. And it is even less than a glorified web cache, IMHO.
Call me pedantic if you want to. But it doesn’t change facts though.
I agree. I was completely unimpressed. It’s basically a few javascript classes built on sqllite with the ability to store data locally (beyond cookies which are less reliable and hard to store a lot of data in).
I’ve had an idea for a while that is similar to this, but much more in depth. This seems like a real half-assed effort.
Google Gears may load faster, but I’m guessing the Java app will respond faster to user interaction once it’s already open. Plus the Java applet can run with or without a browser.
Wasn’t there a recent story about technology similar to this being built-into Firefox 3?
…
Yes Michael, there was:
http://www4.osnews.com/story/17406/Firefox_3.0_Opens_Door_to_Web_Ap…
Instead of finding good ways of rapid developing good native gui applications, everything has to be done inside a browser, where simple things like using the “back” button can corrupt the complete application.
I just don’t believe this is happening, why do we have GUI toolkits at all, just for Firefox to wrap them to another GUI toolkit (XUL) to provide the frame for writing a completely new GUI toolkit (AJAX app) on top of it, which is the slowest of all of them and has less features than all of them (for example, accessibility suffers a lot!).
But perhaps in some years, after every shitty spreadshet and image manipulating application works inside a browser, someone will find a way to get the stuff working outside a browser and we get back to where we are, but cross-platform.
Disturbing…
Where did you get the name “Ford Perfect”? ha ha ha
BTW: I agree with your rant.
I don’t know if there is a hidden joke I didn’t get somewhere, so excuse me if this explanation is absurd
Ford Prefect (yes, it is not Perfect) is the name of a character in Douglas Adams’ “Hitchhiker’s guide to the galaxy”.
(I don’t know if this is the exact original name, never read anything but the portuguese edition of the series)
I great read if you ask me… although it can be a stupid one, depending on whose opinion you ask (my girl simply hated it)
Edit: Fixing typo
Edited 2007-05-31 20:52
I need to watch more TV. I thought the name was a ironic reference to the quality (or lack there of) of the Ford Motor Company.
I guess actually you probably need to read more, given the origin…;-)!
Actually, the name _is_ based on the Ford Motor Company, as there indeed was a “Ford Prefect” model on the market for some years. That’s the one Douglas Adams got the name from.
Actually, the name _is_ based on the Ford Motor Company, as there indeed was a “Ford Prefect” model on the market for some years. That’s the one Douglas Adams got the name from.
The joke being that when Ford (an alien) landed on Earth, he assumed cars were the dominant species and so took the name of a very common one to fit in. He got knocked down trying to “make friends” with one, which is (IIRC) how he met Arthur Dent.
Ford Prefect (yes, it is not Perfect) is the name of a character in Douglas Adams’ “Hitchhiker’s guide to the galaxy”.
(I don’t know if this is the exact original name, never read anything but the portuguese edition of the series)
Yes the character Ford Prefect in the series took the name from the Ford Prefect car, a popular British family car in the 1950’s. The alien Ford when he arrived on Earth, had thought the vehicle was the dominant life form and adopted its name.
The nice thing about web apps is that you only need one application to run them – the browser. That solves a lot of deployment headaches when you’re trying to build cross-platform apps.
Still though, if we’re going to make all of our apps run inside one application, let’s build something else that runs along side a web browser .. something that is optimized and specifically designed from the ground up with this kind of use in mind. Then we have the browser for web pages, and then this other program for applicaitons.
Yeah and after that, we don’t want an application, but just a toolkit. So we end up with QT, being cross platform, and out there for ages.
Or, we don’t want only the toolkit to be cross-platform, but a whole virtual machine, so we end up with Java, being cross platform, and out there for ages.
So it’s again been there, done that.
There are problems that are best solved with web apps and there are problems best solved by thick applications. Saying that we shouldn’t add functionality to web apps because it can already be done with thick apps is myopic at best.
There are websites which should be viewed by a browser and there are non-websites which should not be viewed/processed by a browser.
That’s my take on it. Sure server-side applications have many purposes, and sharing functionality between server and client, too. It’s just that the webbrowser never was the best tool for the job and in my opinion it never will be.
Even something as simple as Google Maps is a good example of a webapp, that shouldn’t run inside a browser at first place.
Except native apps need to be installed, and web apps don’t. Native apps need to be upgraded by the user, and web apps get upgraded automatically every time the user logs in. Web apps are simply much more dynamic in nature (in the sense of being instantly updateable).
On the other hand, I’m still not convinced AJAX is the end-all be-all. AJAX is decent and has a low overhead when it comes to simple applications like GMail or Google Calendar, but once you reach a desktop-app level of complexity it starts to get very slow and seems much less appealing. Java 6 with its improved performance and Flash-like additions seems to be an excellent candidate, esp given that its performance is generally better than AJAX in everything but initial startup of the JVM. Adobe’s Flex platform also looks promising, and so do solutions like OpenLaszlo.
Ultimately AJAX has caught on though since it’s the only thing that doesn’t require a plug-in. If on the other hand a popular OS were to come about that had a Java VM installed and running in the background by default, then Java would probably become the preferred solution. But until that time the lowest common denominator will be targeted, and that is AJAX.
I fully agree with your posting. I know the benefits of webapps. It’s just I never have seen _real_ benefits of running them inside a browser, instead of having a more sophisticated design (in the end, I think about having a GUI that can be created over network – X applications already can be run over network, but it’s too slow, as every single line drawn is sent instead of “draw a button here and a checkbox there”).
“the lowest common denominator” – that sums up my feelings towards AJAX applications.
Isn’t that the fundamental principal behind both the JVM and CLR? Essentially the virtual machine provided by each is the “application” that your applications run in. And similar to everybody having a browser installed to run these apps, just about everybody has the JVM installed and most windows users and many *nix users have a CLR installed (via Microsoft.NET or Mono). So those virtual machines are your universal application platforms but instead of using AJAX to develop them you use either Java for the JVM or C#, F#, VB.NET, IronPython, etc. for the CLR. And it’s not exactly rocket science for an app to check for a new version of itself on a server every time it starts up.
From the sample code available at google.com I see that Javascript code can now store data in local databases, which is good. But I see no way to protect those databases from being tampered by other Javascript code that knows you have Google Gears and use the same database links.
Of course, you can store databases like cookies, per domain, but these scripts are going to be all off-line 🙂
Will have to dig more. But now I think Javascript is going to be very-very usable with FF and GG.
The Google Gears security model is similar to that of cookies. It’s well documented here: http://code.google.com/apis/gears/security.html
Firefox 3 has added this technology straight into the browser. I wonder if this Google Gears will take advantage of that support or if it bypasses it completely?
I’m sure they will bypass it. otherwise they would have to develop a different plug-in for IE and FF.
The browsers are so different I’m pretty sure they’ll have to create different code for each one anyway.
Wouldn’t you just use the Google Web Toolkit with this to build your apps? On to the next monopoly!
A few people seem to believe that this is about cross-platform support. I would say that it is more of a side-effect of rather than a justification for this technology.
People currently use a lot of applications online. Even reading an online newspaper involves making database queries. They do so for a variety of reasons. From the end user perspective, you can access your data anywhere. (Just consider the popularity of webmail.) It is also more convenient for people maintaining networks since software can be deployed centrally without the, well, deployment process. Unfortunately, the big hitch has been accessing data while offline. That seems to be one of the goals of this software. Intelligent caching is another goal. And there seems to be something to do with multi-threaded web-applications running in the background.
Just remember, even if you don’t like it other people may need it.
I like the idea. Kudos to Google (and Mozilla) for working on it. As a web developer I can fully appreciate the value and flexibility that local data storage will bring. I’m particularly happy that Google has chosen the open source SQLite engine as the database driver. The notion of being able to open databases, run queries, populate lists and tables, etc, all within the browser, is tremendously cool.
Certainly it has been technically possible to achieve this in various ways, but none of those methods have felt truly robust, integrated or satisfactory. Javascript is the scripting language of the browser.
No one is saying that the browser should replace proper desktop apps for everything, but there are times when it is a perfect solution. Ease of development, instant cross platform support, the ubiquity of web developers, etc. Bring it on.
Edited 2007-06-01 14:51