Pixel Picture Clearer? Google Ports Office-Substitute To Chrome OS, Browser 158
CWmike writes "Google confirmed on Tuesday that it has ported part of QuickOffice to a technology baked into Chrome OS and the company's Chrome browser. The popular iOS and Android app substitute for Microsoft Office that Google acquired last year will run using 'Native Client,' a technology that lets developers turn applications written in C and C++ — originally intended to run in, say, Windows. With that it will execute entirely within a browser, specifically Google's own Chrome. Google claims that Native Client code runs almost as fast inside the browser as the original did outside. QuickOffice viewers come bundled with the $1,300 Chrome OS-based Chromebook Pixel notebook, and Google will add editing functionality in the next two to three months. Does this all make the Pixel make more sense?"
Re:Translation (Score:4, Informative)
...except for the use of annoying cliches and the incomplete sentences.
You're looking at the glass as half empty instead of half full here. it's a start ....
I know, folks are penny wise and pound foolish with some of the Chrome book .... of course there's a silver lining here - it will make Chrome OS more usable outside of a dumb terminal for the cloud.
anyway, I'll make like a tree ....
Re:Translation (Score:5, Informative)
Google figured out that a computer that runs only cloud based stuff isn't such a good idea. But, since Chrome OS doesn't have native apps, they had to hack those native apps into Chrome, where they run "almost as fast" as they would if they were proper applications under a real OS. As a demonstration of how great this technology is, Google hacked an entire open source office suite into Chrome.
That certainly does explain why you'd want to buy a Chromebook that costs more than an ultrabook or an Air.
It almost sounds like Google wrote the summary... except for the use of annoying cliches and the incomplete sentences.
Quickoffice [wikipedia.org] isn't open source - it's a proprietary IOS and Android app... Google bought the company last year.
I'd be more impressed if they *did* port Openoffice/Libreoffice to Chrome.
Re:Does all this make the Pixel make more sense? (Score:3, Informative)
Agreed, but what does this have to do with the Pixel??
I can see this as a story about MS vs. Google, or about Google's Native Client technology - which, incidentally, is supported by the Chrome browser. It is not - as this story seems to suggest - limited to ChromeOS or the Pixel.
Re:Translation (Score:4, Informative)
Your 'translation' is wrong on every point.
- Native Client apps are cloud apps - they just use a different client technology.
- Second Chrome OS (and Chrome) does have native apps - via NaCl - and has for a while. This isn't new at all.
- This isn't hacked into Chrome - it's not part of Chrome at all.
- There is no way that anyone at Google would want to write such a misleading and confusing summary.
This is just a new cloud app, that runs on an existing client technology that's been built-into Chrome and Chrome OS for a while.
Re:Everything old is new again (Score:5, Informative)
The big difference between ActiveX and NaCl is that the latter has a sandbox - a very smart one, actually, which lets it run native code directly while remaining secure.
The other big difference is that they are also tackling the architecture portability issue by the PNaCl project (basically downloading LLVM bitcode and compiling it for the current architecture).
So, yes, this is like ActiveX - but done right. All the perf of native code with none of the security issues.
I really, really hope it catches on - especially PNaCl. If it does, we can finally ditch JS as the web client language, and move on to something more decent (and better yet, you and me can make different choices about the languages that we want to use).
Well, not until IE has it (Score:5, Informative)
In my opinion the whole application on a browser thing happened because MS has (had?) a monopoly on desktop. So if you wanted to develop something cross-platform that has a UI, you had following options:
* Do it in a cross platform language that has UI programming. The only one I know is Java. 10 years ago, computers were much slower, and Java on desktop was quite worse than it is right now, so this would result in sub-par applications.
* Do it in C/C++ and use a cross-platform tookit. The only ones worth talking about are wxWidgets and Qt, and again, 10 years ago they weren't mature. On top of that you need to deal with tons of "backend" programming hassles, as windows is not really posix compatible. Again, cross-plaform toolkits like Qt or wxWidgets help here, but only some.
* Use some kind of thin client technology and do all the heavy lifting on the server. This basically evolved into a web server + a browser as a thin client. And until AJAX, your applications could not offer much interactivity.
All thigs considered, for many things browser-as-a-thin-client model makes a lot of sense. You always get the latest version immediately, you don't need to install anything (installing/removing/updating software is a huge hassle on windows. I'm appalled windows still doesn't have any package management and repositories). You get decent security- you can trust a web page will not screw up your computer (well, except some exploits in the browswer, but that's nothing compared to installing and running a native app from untrusted source).
Looking back I always think if this could have been done better. HTML+JS is quite nasty from an application development point of view. First of all, JS works differently on different browsers, and these differences are hardly documented. Things like GWT or jQuery help, but the problem is still there. Again, Microsoft and IE screw things up badly for everyone time and time again. Another two things- running inside a browser you don't have propper networking support and access to local storage. Both are required for complex interactive applications. HTML5 is an attempt to improve both, but it remains to be seen how successful it is. HTML/CSS layout is hard. There are still few to none WYSIWYG tools to drag and drop UI elements and construct a web-app in this way. And web-apps have a different look & feel than native apps- you still need to think in terms of URLs, "back" buttons, tabs, browser menus, etc. And not all hotkeys work either.
In general, I think a browser using HTML/JS/HTTP is a bad to mediocre thin client for applications. The only reason its so widely used is because it comes preinstalled on all new computers/tablets/mobiles shipped. If Microsoft wasn't a monopoly, it would have been possible to ship some other better thin-client with all the machines sold, and we would not have to deal with all this mess. I would probably prefer to have a browser just for reading PAGES, and a dedicated thin client for running remote apps. Hopefully things will get better with HTML5, and Microsoft has less influence on internet standards these days...
Sorry for the long rant,
--Coder