Hacker News new | past | comments | ask | show | jobs | submit login
Native Client d**k-swinging met with fake Googasm (theregister.co.uk)
5 points by twampss on Dec 15, 2008 | hide | past | favorite | 11 comments



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?


> 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.


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


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.


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.


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.


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.


> 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.)


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. :)


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.


Sugar: Connect to the mesh, join the 'write' activity, sugar automatically downloads and runs the correct software.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: