Google Native Client challenges Microsoft and Adobe RIAs Google is entering the rich-client game with a project allowing online applications to tap your desktop through the browser. The search giant has revealed its Native Client project, intended to run native code from web-based applications on x86 Windows, Mac, and Linux. Native Client will use JavaScript in the browser. Google …
Hehehe.... so you can put your pics and texts and other, hem, "intellectual property" online, effectively giving every right you might have had on it to the hosting service. Now, on top of that, you have to provide the processing power. Next step: files are actually hosted on your computer, with the "hosting" service's webpage deep-linking to it through a backdoor. They might have you pay for that, too. Why not?
Serves them web2.0 lusers well.
A whole article on running code natively from your browser, and Sun doesn't get mentioned once.
It shows how badly they have misjudged Java, not just once, but consistently throughout it's lifespan. Sun really doesn't 'get' client computing, and no end of researchers and clever little projects that don't actually go anywhere will change that.
They are missing someone who understands the desktop, and who has the authority within the company to architect a project that will address their deficiencies. JavaFX is clever but really repeats many of the mistakes they have made when it comes to client side environments. Until someone high up in Sun understands that, they are going to continue to be left out of articles discussing the technologies that they pioneered.
x86 Native Client works how well on a PPC-based PS3 browser or X360 browser? How well on an ARM-based palmtop?
The correct solution is JIT compiling, but Silverlight already does that and so, I understand, does Chrome's Javascript. So ... why?
The only explanation is that Googlebots get to work on whatever they think is cool and then they throw it and see what sticks.
If only I had those kinds of resources :(
Hang on, let me get this straight, rather than all the processing taking place on the server, it's a good idea to have all the processing happen at the user end, and the means of accomplishing this should be compiled binary code, native to the platform ?
You mean, exactly like the 'traditional' desktop applications that we've all been using since the nativity of the PC ? And which, in fact, almost everybody who isn't a foaming at the mouth fanboi still uses for most of their day to day data processing ?
What happened to the 'cloud' then ? Sun come out, did it ?
The problem i have with all of these projects is that i can't see any benifit in them....
Why would i want to edit a photo that is stored online via my web browser when i can just save it to my computer and use a local app - Say Photo Shop or Paint Shop Pro. The best "onine" apps will probably be about as useful as Paint!
Or have i missed the point (Just like i have with Web 2.0)...
Javascript sucks. Maybe Google can force it to be better? I've been working on a Java back-end and Flex front-end project for a while. It's much much better because you don't really need to worry about the interference between the HTML and JavaScript. Not to mention that you have to deal with the "name space" issue with that if it's in a portlet type of environment...
Adobe Flex / ActionScript is a much better environment to work with. Also, it will only be getting better with more integration with the Flash. In addition, Adobe is doing the right thing to work with SpringSource to utilize the open source power further more and I can see a bright future because I like everything has been done by the SpringFramework team so much. It makes my J2EE life much easier. (That and the Eclipse & Maven and all the Java Open Source communities.)
Here is that exciting news,
http://www.internetnews.com/webcontent/article.php/3789821/Adobe+SpringSource+Team+For+Enterprise+RIAs.htm
To me, it's a much better news from Enterprise developer's point of view.
Now when the inevitable security flaw rears its ugly head it will be able to directly run native code. Sigh. Will we never learn? Okay Google, repeat after me, separation of privileges is a GOOD thing!
Ah well, I suppose us firefox folks can whip up a NoCode or CodeBlock Plus.
Besides, how silly it is to wrap a native client inside a browser instead of just distributing the client directly?
Mine's the one right next to the one with the pocket full of holes!
Ok, so we will have the ability to run x86 apps in a browser. But then we will need APIs to make it useful. And if we want to have "browser neutral" applications, which GUI will we choose (so that users are not confronted with something entirely different for each app)?
It seems that Sun has already struggled with all these questions in the past, and succeeded somewhat. It has addressed the issues of security, cross platform GUI and provides a host of APIs all in what would appear to be a more elegant solution (processor independent, not just platform independent).
If I were Google I would help Sun with the big area that it has failed: deployment. Java can work well on the client side, but Sun have made a big mess when it comes to browser integration and compatibility. It is not that difficult, Adobe get it right with Flash (how many flash runtimes do you have on your PC?). Sun have even made some good efforts of late (Java kernel) but the response is all too confused. Sun is a company which develops good technology but can't package it properly for the intended audience. Google is a company which gets the packaging aspect just right.
We seem to see this all the time in IT circles: a technology matures to a point where it is just about usable and then someone throws their hands in the air and starts again in an opposite direction only to end up at the same point 5 years later.
Think how XML-RPC was first portrayed as being a much simpler solution compared to the "overly complex" CORBA. After it became SOAP and then web services and we added all the required WS extensions (security, asynchronous transactions, messaging, etc.) I would argue that it is no less complex than CORBA was. And we lost over 5 years in the process.
Sometimes we would be better of fixing existing technologies which are "almost there" rather than blindly starting again...
Dominic.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
