Google Rebuilds Docs Platform 194
mikemuch writes "In addition to offering faster, desktop-like performance, better imported document fidelity, and more features found in standard Office apps, Google's new infrastructure for its web-based office suite will enable the company to more easily update the apps. A side effect (or benefit, depending on where you sit) is that the new platform will ditch Gears in favor of HTML 5. For a while starting May 3 there will be no offline capability whatsoever. Collaboration is a big focus, with a new chat sidebar and real-time co-editing. The new Docs and spreadsheet apps will be opt-in previews, but a new drawing app is launching fully. Both go live later today on the Google Docs site."
Slashvertisement? (Score:3, Interesting)
Re:Slashvertisement? (Score:3, Interesting)
Nah, not really.
it's something used by tons of people, and switching to HTML 5 here is a good deal *and* significant for cross platform use.
Still sounds shittier than OpenOffice.org. (Score:0, Interesting)
It still sounds like a shitty web app, less usable and practical than OpenOffice.org. And OpenOffice.org is pretty bad to begin with, too.
Web apps just can't compete with real apps, and will never be able to as long as we're using JavaScript as the programming language to implement these apps. JavaScript is just not suited to large-scale application development, especially something as large as a full-featured word processor.
Re:Still sounds shittier than OpenOffice.org. (Score:5, Interesting)
I'm sure Google is using something similar to their Google Web Toolkit [google.com] to write the applications in Java and have the code compiled into JavaScript.
The thing to take away from this (and everyone should already be aware of this if they're making claims as to the usefulness of a JavaScript) is that JavaScript is Turing complete. So it clearly can be used to develop an Office-like suite of tools.
The only real concerns are:
Since the Google toolkit is converting Java to JavaScript, the answer to #1 seems obvious. And while it's not quite as clear-cut, recent (and ongoing) improvements in browser JavaScript interpretation speed seem to indicate that #2 is likely true, too.
JavaScript (Score:5, Interesting)
Re:JavaScript (Score:3, Interesting)
Why?
There are loads of Javascript frameworks out there to basically give developers any functionality they might require. Speed isn't the issue anymore since Javascript engines have become multithreaded bytecode interpreters and as of late even offering hardware acceleration.
What's wrong with Javascript?
Re:HTML5 Features (Score:3, Interesting)
Seriously, who cares?
Because the native desktop is managed by a typical user who is not really dumb, but has no inclination to manage the machine correctly. They usually lack the security implications of their actions. They have a nebulous understanding of how the computer works. They don't get the difference between their local computer, their files in their machine, the web site they visit. They don't even know the difference between the OS and the browser and the applications.
The situation is so bad, the shills are actually touting the advantages of the closed software, saying that is the only way to get secure applications without viruses and worms. The shift to cloud essentially forces the user to learn a new security paradigm.
Yes, it is buggy and inefficient. But that is now. As technology improves, the simple browser will serve the 95% of the needs of 95% of the population.
Re:HTML5 Features (Score:5, Interesting)
I am just pissed off that no one seems to want xhtml2. It is generally better than html5 in most ways, though it could use a few minor features from html5.
Re:JavaScript (Score:3, Interesting)
What's the point of using an interpreted language when you could compile to, download and execute bytecode much more efficiently?
Please define "much more efficiently". Sure, it's more efficient from the computer's standpoint to run native code, but that's only part of the equation. From the user's standpoint, running something like this as a web service rather than a stand-alone executable means not having to install, never having to upgrade, and automatically having their documents available from any other computer that has an Internet connection. Yes, it may be slightly slower, but that slowdown may be well within tolerable limits, and there are added benefits. Whether those benefits outweigh the costs is up to the individual to determine for their particular circumstances, and what's "much more efficient" in a technical sense may not be more efficient from the user's point of view.
Re:HTML5 Features (Score:3, Interesting)
You could just substitute research for "betting" and observe what MS is actually doing with their next release: building a limited online version of Office, but selling the usual feature-complete local tools which take advantage of the speed, reliability, connectivity and UI of a native app.
I could research, but having been in IT for over a decade at this point, I will continue to "bet" until applications are actually in production. Until then, it's all vapourware as far as I'm concerned. In this case my bet is based on Microsoft's claims that they are going to offer Office online. We'll see how it works. A couple of months ago, I read a few reviews where everyone was bemoaning how much it sucks and how far it has to go.
Seriously, a reason to use Google Docs over Office is that it's harder to install Office than a web browser?
If you want to get technical, it IS harder to install Office than a browser. The browser (IE) comes pre-installed. Office requires an installer. Even if you are pushing it out via GPO, or Systems Center, you still have to have a mechanism to get the application configured on the end user's device. If you move it onto the web, all you have to do is provision it once and maybe authorize the user's account in Active Directory or whatever.
I find Office much easier to deploy than Firefox...
As for Firefox versus Office, they're pretty much the same. You configure your installer package and associate it with whatever OU you want to deploy it. The rest is automatic.
Re:JavaScript (Score:3, Interesting)
Well I used to think that. There's one problem I encountered, which is that gzipped, optimized JavaScript is mindblowingly concise compared to most other forms of compiled code. You can fit a staggering amount of functionality in only a kilobyte of this stuff.
This may sound absurd, but try it for yourself. Write a piece of JavaScript to do something generic and non-platform dependent like calculate MD5. Run it through the Closure Compiler [appspot.com] which is the same tool that Google uses to optimize and check its JavaScript. It will tell you the gzipped size. For a simple MD5 impl I got off the web, it boils down to 1.4kb gzipped. Now try compiling and gzipping a C implementation and a Java .class file. In both cases the result was about 5kb - that's a pretty big blowup! JavaScript has the advantage of having a basically overhead-free yet semantically very rich format: source code. Other languages compile down to quite complicated header formats that are full of version identifiers and symbol names.
Given that modern browsers like Chrome convert your JavaScript to native code anyway, it may well make sense to slash your code size by using JavaScript and take the better loading times along with a hit on runtime performance.
Re:JavaScript (Score:3, Interesting)
It would sure as hell beat crazy hacks like compiling other languages to JavaScript.
Yes, it would have made much more sense to come up with a decent IDE for web javascript development than to do wacky hacks like that. But since they work, they'll stay with us for quite some time. In the mean time, various agencies have proven that JavaScript does not have to be slow. With some additional help, it can surely be even faster.