8 ms·

Sergey Brin: Native Apps And Web Apps Will Converge Soon

46 points by stanleydrew 16y ago

deleted 16y ago
[deleted]
greyman 16y ago
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.
- arethuza 16y ago
  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.
  - buddycasino 16y ago
    Maybe thats why Google develops native client: http://code.google.com/p/nativeclient/ http://code.google.com/p/nativeclient/ Still looks pretty alpha.
Angostura 16y ago
I've just had a flashback to the original JavaOne conference.
- mrvir 16y ago
  Care to elaborate a bit?
  - joe24pack 16y ago
    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.
    - stcredzero 16y ago
      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.
- arethuza 16y ago
  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....
  - dugmartin 16y ago
    Never get between a Teamster and his drayage pay. It's fun paying $1000 to move stuff 200 feet isn't it?
    - arethuza 16y ago
      They really were quite menacing in a professional kind of way - even more so than corporate lawyers.
Aegean 16y ago
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?
- jasonlotito 16y ago
  "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.
- spot 16y ago
  html and javascript are like assembly language. when/if this convergence happens you'll be using something like GWT or NaCl.
  - ori_b 16y ago
    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?
    - spot 16y ago
      i hope so and i think that's the kind of convergence he's talking about, being able to compile GWT to either target.
- jimbokun 16y ago
  "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.
wslh 16y ago
Please don't joke, in some way they will converge, but my quad core is not a dumb terminal executing javascript.
- vdm 16y ago
  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.
jcromartie 16y ago
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.
- retube 16y ago
  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.
- arethuza 16y ago
  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 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.
  - retube 16y ago
    isn't this what X does?
    - arethuza 16y ago
      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.
Mark_Book 16y ago
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?
- jimbokun 16y ago
  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.
njharman 16y ago
Um, Air, Silverlight, Java? A prediction of equal insight, "The sun will rise tomorrow."
oconnor0 16y ago
Interesting. Isn't this kind of exactly what Paul Graham's been talking about for years?
smiler 16y ago
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)
- andywood 16y ago
  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.
- deleted 16y ago
  [deleted]
- tphyahoo 16y ago
  what's LOB?
- stoney 16y ago
  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.
Kilimanjaro 16y ago
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.

46 points by stanleydrew 16y ago

deleted 16y ago

[deleted]

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.

arethuza 16y ago
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.
- buddycasino 16y ago
  Maybe thats why Google develops native client: http://code.google.com/p/nativeclient/ http://code.google.com/p/nativeclient/ Still looks pretty alpha.

Angostura 16y ago

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

mrvir 16y ago
Care to elaborate a bit?
- joe24pack 16y ago
  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.
  - stcredzero 16y ago
    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.
arethuza 16y ago
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....
- dugmartin 16y ago
  Never get between a Teamster and his drayage pay. It's fun paying $1000 to move stuff 200 feet isn't it?
  - arethuza 16y ago
    They really were quite menacing in a professional kind of way - even more so than corporate lawyers.

Aegean 16y ago

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?

jasonlotito 16y ago
"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.
spot 16y ago
html and javascript are like assembly language. when/if this convergence happens you'll be using something like GWT or NaCl.
- ori_b 16y ago
  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?
  - spot 16y ago
    i hope so and i think that's the kind of convergence he's talking about, being able to compile GWT to either target.
jimbokun 16y ago
"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.

wslh 16y ago

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

vdm 16y ago
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.

jcromartie 16y ago

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.

retube 16y ago
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.
arethuza 16y ago
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 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.
- retube 16y ago
  isn't this what X does?
  - arethuza 16y ago
    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.

Mark_Book 16y ago

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?

jimbokun 16y ago
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.

njharman 16y ago

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

oconnor0 16y ago

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

smiler 16y ago

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)

andywood 16y ago
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.
deleted 16y ago
[deleted]
tphyahoo 16y ago
what's LOB?
stoney 16y ago
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.

Kilimanjaro 16y ago

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.