

Native Client d**k-swinging met with fake Googasm - twampss
http://www.theregister.co.uk/2008/12/15/dziubba_nativ_client/

======
old-gregg
If he turned down his sarcasm just a bit, more people would actually see the
point he's trying to make.

I too believe that browser-based HTML/CSS/Flash/Silverlight platform _is not_
the future. If some mad genius with a bunch of free time on his hands takes
Cocoa, makes it _truly_ cross-platform and merges it with something like
Debian apt and manages to achieve Flash-like market penetration, _that_ would
be a killer platform to develop for: huge market (OSX/Windows/Linux + mobile
devices that run them), native CPU speed, rich graphics, joy to develop for,
seamless distribution - typing "apt-get install foo" is no harder than typing
"<http://foomaker.com/downloads/foo>" plus your users won't have to deal with
fucking login screens for everything and their shit keeps working on a plane.

I suspect the reason for web-app proliferation isn't technical, developing for
the web just makes more business sense: you don't have to share your precious
code because of those sweet GPLed tools you use, you cover Windows and OSX
with one shot, you don't have to worry about folks pirating your software, and
distribution/updates are much easier. Seriously, nobody needs a fucking web-
based photoshop. What for? Collaborative red eye removal?

~~~
randrews
> Seriously, nobody needs a fucking web-based photoshop. What for?
> Collaborative red eye removal?

Maybe so that their images are available from whatever computer they happen to
be sitting at. That's what I use Google Docs for.

~~~
old-gregg
That is a simple function of _storage_. There is no need to push tons of code
around only to share a freaking document. Microsoft could have built a "cloud
collaboration" tool into MS Word if they wanted to. In fact they have, but
AFAIK it works only on Intranets and only if you purchase their proprietary
server-side BS

~~~
randrews
Okay, so I go over to my girlfriend's apartment and want to show her something
I wrote.

MS Word: Buy a copy of the server-side component for my server, set it up
beforehand, buy a second copy of MS Word, remember to bring it with me,
install it on her machine, set up the cloud collaboration tool to read from
wherever I stored the document, display it.

Google Docs: Open a browser, log into Google, click on the document.

Right now the only reason all this stuff is web-based is because browsers are
everywhere. If you think about it, your cross-platform environment basically
_is_ a browser. You type in a URL, it downloads some code and runs it. It
saves back the data you make to the place it downloaded the code from.

You just want a browser that's more designed for applications than documents,
which is (I think) what Google was going for with Chrome, only it's not that
popular yet because most of their early adopters are on Macs now.

~~~
old-gregg
_Google Docs: Open a browser, log into Google, click on the document._

At the cost of being basically a Notepad with fonts. Which is probably less
than 1% of what MS Office can do. Oh, and if your favorite Starbucks loses
Internet connection you're fucked. During startup school 2008 Paul Graham was
asking the audience to "stop using the Internet" because his freaking
presentation wouldn't load.

I think the "dream runtime" I envisioned above beats this nightmare hands
down.

 _If you think about it, your cross-platform environment basically is a
browser_

Yes, the browser is the runtime stack, albeit a very crappy one with big
limitations and huge legacy, which is why, I believe, browser-based apps are
not the future.

JavaFX, Gears, Flash, Silverlight - they don't exist because someone was
bored. The pressure of going back to desktop-style development is growing.

~~~
randrews
You don't want desktop apps, you want a better browser. Put in a URL, download
software from it, run it locally. That's a browser.

The only thing that Google Apps is missing from that is that it periodically
has to hit the server to save your documents, and that its interface isn't as
flashy, because current browsers suck.

Bringing out MS Word into your argument only confused things, because
traditional get-it-on-a-CD software is a huge step backward no matter how much
nicer the GUI toolkits are.

~~~
old-gregg
If you want to make a point, you better come up with arguments better than
"because I say so". I have given you fairly detailed technical advantages of
native software and offered an explanation why we have (temporarily, I hope)
moved back to the stone age, only to hear nothing but heard-it-before Web 2.0
marketing pitch devoid of any factual support.

BTW it's 2008, nobody installs shit from a CD. Ever heard of a package
manager? Also look at iPhone apps: here we have a computer which is online
100% of time by definition, yet all that neat software for it is strictly
"traditional". That's because "traditional" kicks ass, users like it, plus
Apple solved the distribution problem. Solve that problem on a generic PC and
you don't need the browser anymore.

~~~
randrews
> I have given you fairly detailed technical advantages of native software and
> offered an explanation why we have (temporarily, I hope) moved back to the
> stone age

I don't think you really understand why we moved back to the "stone age" at
all, or exactly what kind of stone our age is. I also really don't think
you're reading my comments, because fundamentally, we agree.

Just making something "native code" isn't a silver bullet that automatically
makes it awesome, you know. If it's really native code, then it's only going
to run on one OS and one architecture. You would have to make it something
slightly higher-level, like a VM, or an interpreted language. Have it talk to
a native API.

Then, of course, the API should be a least-common-denominator of a bunch of
different platforms. So fancy Quartz effects that won't work on Windows,
you'll need to either not provide them or mark them as platform-specific (thus
making people not use them).

Think about what you want here. You have an application, your dream platform
thing. It connects to a remote server, downloads some code written for it, and
runs it locally. That code talks to an API provided by the dream platform that
lets it draw GUI widgets and take input, in a manner standardized across a
bunch of platforms. It then (in my ideal world) uses the server it got the
code from for storage.

 _That is a browser._ It's the same thing. All you want is a browser that uses
Cocoa instead of HTML/CSS, and can store apps in a cache and run them offline.
Which, don't get me wrong, is a great idea. It means throwing away backward
compatibility with the web, but it's still a great idea.

Thing is, congratulations, you're the ten millionth person to have this idea.
It's not a bad idea, but it's by no means new. And the problem it solves is
the same one that's how we got into the "stone age": distribution.

Browsers suck? Great, make a better browser then. I'll download it. Probably
even write apps for it. Just stop pretending it's a "return to desktop apps".

(As for the iPhone, I think it's a long way from having "solved the
distribution problem". Very onerous terms of service and approval process mean
that most of the apps suck, and probably always will.)

~~~
old-gregg
Ahhrr... Sorry I must have misunderstood you then. If you insist on calling
any dev stack with built-in code fetching capability a browser, then I think
we both agree we need a better one. :)

~~~
randrews
Yeah, really the only part of your comment I was replying to was "why would
anyone want web-based Photoshop?"

Sorry if I flamed you.

