Sergey Brin: Native Apps And Web Apps Will Converge Soon | Hacker News Reader

Sergey Brin: Native Apps And Web Apps Will Converge Soon

techcrunch.com

46 pointsstanleydrew32 comments

I understand the Google's vision of OS-agnostic computer experience, but anyway, I fail to see how will Sergey solve the inherent problem that the native app programming will usually give the developer more possibilities. I still prefer the model like one being used by Evernote - the client is native, and only data is synced on the cloud.

I find using native apps with files in Dropbox works better for me (docs, Freemind mindmaps) than using web-based equivalents.

Of course, things like Google Docs win if you want to eventually share the document, but for personal stuff I'll be sticking to Dropbox.

Maybe thats why Google develops native client: http://code.google.com/p/nativeclient/

Still looks pretty alpha.

I've just had a flashback to the original JavaOne conference.

Care to elaborate a bit?

I think he might be referring to the "write once, run anywhere" slogan, about how Java via the JVM would free users and developers from the tyranny of any particular OS.

The OS might be a tyranny, but it's also a tremendous resource. Just because one is in a totalitarian regime, it doesn't mean that one can't do business.

Smalltalk eschewed the OS for true write once, run anywhere freedom. One result was that the community missed out on the synergies of both the Windows and FOSS ecosystems. (This is one thing Perl, Python, and Ruby do right.)

In the case of Google: they too have established their own ecosystem. They can extend their ecosystem and increase synergies with Web Apps in general. The OS won't go away, but it has ceased to be the central focus of computer use. Apps (web or otherwise) and the networks they provide access to are the central focus of most users today.

It took me quite a long time to remember that I spent that conference doing booth duty. I seem to remember some rather large gentlemen getting rather upset with us when we tried to carry our own boxes from our rental car to our stand....

Never get between a Teamster and his drayage pay. It's fun paying $1000 to move stuff 200 feet isn't it?

They really were quite menacing in a professional kind of way - even more so than corporate lawyers.

I just don't get why everyone is sold on web apps. They are an absolute pain to develop compared to writing native apps.

I know people talk about deployment and so on, but really, that is easily solved with auto-updating clients.

I for one wish web apps would go away and we could go back to native clients.

(For LOB anyway which is what I spend a lot of my time on)

I still believe that a best-of-both-worlds is possible, and probably coming. But I sort of agree with you in the sense that I would much, much rather have only Internet-connected native clients, than only web apps. Fortunately it doesn't have to be one or the other.

I agree - I'm not sold on web apps in general, but they do work very well for certain things (email is the classic example).

Despite the hype, I'm not sure how many people are really sold on them. In practice I use native apps 99% of the time. When I'm number crunching Excel, Matlab, Python are all native. When I'm programming (even developing webapps!) Emacs, Mercurial, etc are all native apps.

Web apps still have a long, long way to go before I will be ready to do my day to day work in them.

I dont think they will converge that fast. I definitely don't see myself writing html and javascript code for a computer program. The web languages unfortunately are ad-hoc pieces of different technologies shuffled together. Ad-hoc is generally good, but its done in a disorganized way which is what I don't like about it. Why bring the same chaos to native?

"I definitely don't see myself writing html and javascript code for a computer program."

XAML and C# are rather close in comparison. The capabilities of HTML and JS are only limited by what the browser allows.

I understand your point, but I don't think the HTML/JS/Server Side language setup is far off the mark.

html and javascript are like assembly language. when/if this convergence happens you'll be using something like GWT or NaCl.

Now, once we get there, can we ditch the brainfuck-quality intermediate layer and just go from GWT or whatever to native code?

But... isn't that called a native Java app?

i hope so and i think that's the kind of convergence he's talking about, being able to compile GWT to either target.

"Ad-hoc is generally good, but its done in a disorganized way which is what I don't like about it."

I think each piece does it's job well, and better than if someone tried to somehow consolidate multiple web languages into one.

HTTP has proven itself robust and versatile, especially with the wide spread adoption of REST development strategies. It also allows you free choice of language to implement on the server. Before the popularity of web development took off, language choice was largely circumscribed by the environment to which you wanted to deploy (the current controversy over iPhone OS hearkens back to those days).

That's true of JavaScript in the browser today, but Javascript has proven flexible enough to allow for many different ways of programming in the browser (Cappuccino, jQuery, etc.). And simply by the size of its installed base, it is inspiring innovations in dynamic language performance that remind me of what happened with Java and byte-code virtual machines.

HTML and CSS split the job of content form and appearance nicely, and the speed of HTML5 adoption by competing browsers has been impressive, in my opinion. I think that the CSS approach of separating styling from the content is superior in many ways to traditional desktop development.

I think the situation with web languages and technologies is vaguely like the situation with C++ in one particular way: It isn't that they're really good, it's more that they've been around so long, evolving at glacial pace, and there is such a huge community compelled to use them, that we've collectively figured out how to make them passably effective.

If I were designing a web application platform on purpose, major design criteria might be: 1) data and apps hosted remotely, 2) discoverable apps/services, 3) hypertext-style linking of resources, 4) ability to fully exploit client CPU and GPU power for UI, and for compute where appropriate, 5) consistency with common desktop UI concepts (like drag/drop), 6) flexibility in languages and developer tools, allowing for compiled, statically checked languages for those who like them. With the current web, I think we have 1-3, but not 4-6. (I think I would trade the enforced niceties of HTML/CSS for more flexibility in the UI.)

What I want to see is a platform where native software is accessed in terms of resources, aliased locally and cached. Why should software need to be downloaded and installed? Something like apt or ports but on-the-fly and more fine-grained, for things like controls and graphics.

why can't my PC/netbook/phone mount a remote drive on which software is all installed? I never have to worry about upgrades, installing anything, plus it runs locally meaning i have full OS hooks for peripheral devices etc.

The only thing that I've seen that tried to split executing application code between the display server (i.e. the bit you have locally) and the application process was NeWS:

http://en.wikipedia.org/wiki/NeWS

I had great fun programming with this (especially with the Hypercard-like HyperNeWS environment).

Once you the hang of interactive programming in PostScript it was a lot of fun.

Of course, you could argue that web browsers are doing this with Javascript - but that's at a different level of abstraction.

isn't this what X does?

Not really (at least not unless X has changed a lot since the last time I had much low level dealings with it) - NeWS allowed the client application to sent chunks of code to the display server, not just commands to display things. And not just chunks of any old code, but a full PostScript environment with all that it implies.

There was also a shell (psh) that allowed you to log in directly to a display server and interact with display objects. I remember logging into a colleagues NeWS server process (we had security turned off for some reason) and rotating one of his windows by 20 degrees just by running a single PostScript command.

Please excuse my ignorance but can someone explain to me what message is being given to developers? Is it to develop in Java (for Android) or to develop in HTML/css/Javascript combo?

Google is not giving a message, they are listening for the message that the developers are sending to them. That is the reason they gave for having separate but overlapping development stacks.

Um, Air, Silverlight, Java? A prediction of equal insight, "The sun will rise tomorrow."

Let's use the app:// protocol to deploy native C++ apps over the web with full access (in a non linkable way, so grannies don't get their computers pwned). Just drag and drop app://myfunnycat to your toolbar and run it from there.

Just a thought

PS. hmm, let's drop the double slash and the TLD, just the app name will suffice, and make the DNS understand it.

Interesting. Isn't this kind of exactly what Paul Graham's been talking about for years?

Please don't joke, in some way they will converge, but my quad core is not a dumb terminal executing javascript.

This discussion is more about how the code that runs on your machine gets to be there, and when it runs, and less about where it runs (client vs server).

The way things are, this requires way too much admin on the part of people who would rather not have to think about it.

Reply on news.ycombinator.com