

Sergey Brin: Native Apps And Web Apps Will Converge Soon - stanleydrew
http://techcrunch.com/2010/05/19/chrome-os-versus-android/

======
greyman
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
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
Maybe thats why Google develops native client:
<http://code.google.com/p/nativeclient/>

Still looks pretty alpha.

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

~~~
arethuza
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
Never get between a Teamster and his drayage pay. It's fun paying $1000 to
move stuff 200 feet isn't it?

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

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

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

------
Aegean
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?

~~~
jimbokun
"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.

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

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

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

~~~
retube
isn't this what X does?

~~~
arethuza
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
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
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
Um, Air, Silverlight, Java? A prediction of equal insight, "The sun will rise
tomorrow."

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

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

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

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

