

The Promise of the Web - kr589213
http://www.alertdebugging.com/2011/09/22/the-promise-of-the-web/

======
tlrobinson
I think Google's Native Client is our best chance for something like what he
describes.

It provides a sandbox for executing untrusted machine code (or PNaCl for more
portable LLVM bytecode), downloaded on the fly, which would enable efficient
implementations of things like HTML/CSS/JS.

I look forward to the day someone gets a browser rendering engine compiled and
running in NaCl.

~~~
leoc
You also need some extra content-negotiation abilities, but that shouldn't be
too hard: <http://news.ycombinator.com/item?id=2131870> . I'll pull out this
bit:

> Finally, the process can chain, so a particular [data/DSL] file might be
> given to a display program which is a Ruby script which would in turn be
> given to a generic-runtime interpreter for the appropriate version of Ruby.

So it's untrue that using NaCl or something similar means that all code (let
alone all _data_ ) has to be sent to the browser already compiled down to
assembler (or PNaCl bitcode or whatever). Among other things, this is one
important reason why Mozilla is wrong to claim that adoption of NaCl (or
whatever) would mean that HLL/scripting-language/whatever code distributed
over the Web would no longer be able to benefit automatically from speed
improvements to the browser's HLL runtime(s). Chained content negotiation is
your friend TM.

------
daleharvey

        "Now imagine a world where the browser ran something
        lower level. Where Google, Mozilla, Microsoft, Opera, 
        and Apple’s jobs in providing a browser more resembled 
        Intel’s job of providing a chipset: they simply 
        provided hooks for basic technologies like sound, 
        camera, movies, geolocation, etc. And on top of that,
        we the developers wrote HTML, CSS, JavaScript"
    

here lies the problem, coffeescript was cited in the article, you yourself
wrote or at least worked with obj-j, there is haml and sass, writing
alternatives to javascript / html / css is not a problem, people are doing it
all the time. If browsers cant provide access to higher level API's in a
complete and consistent manner, how do we expect them to provide low level
ones?

There are 2 main problems with the web right now that I can see being brought
up repeatedly

1\. Devices / Lower level API's, new android devices have access to the camera
but all things considering that is very weak, why do we not have standard
solutions for clipboard access, device apis, filesystem apis, storage etc

Phonegap are doing great work for this on mobile, Mozilla have also talked
about this in their mobile browser, if phonegap can do this cross platform
then how in the hell can browser manufacturers not? why doesnt firefox already
ship with this support on the desktop?

2\. is performance, is javascript going to ever be fast enough that we can
build rich applications and games, right now the smallest page animation
triggers ridiculous stuttering, is it javascripts problem or the doms? is it
fixable with current solutions? blazing fast hardware accelerated webgl or
canvas doesnt matter if the host language cant lookup a variable without
random second long pauses.

nacl is often brought up as the solution here, but I have a hard time seeing
how providing a sandbox to execute native code is gonna help me build a nice
mobile app that uses web technologies (forms, links, standard tools for
accessibility) and can still do a decent page transition without stuttering

This article doesnt seem to draw any conclusions about how to solve these, and
the "everyone can be the owner of the web" seems almost like its apologizing
for Joe Hewitts confusingly completely off base conclusions.

I dont have any answers either, but happy that the conversation is being
started.

~~~
Me1000
Your second point is moot. 280slides proved high quality desktop class
applications are possible on the web. Cappuccino helped reinforce that fact by
providing several more apps, some of which rival even their desktop
counterpart (picsengine, which no longer accepts new subscribers, is just as
capable as iPhoto. In fact my father actually like Picsengine better!)

Recently the new iCloud applications show that sexy animations are also
possible on the web, if you're willing to put time into polishing it!

Performance on the web hasn't _really_ been an issue in years. The real issue
is bad developers set the bar for web applications very low.

~~~
nupark2
_Your second point is moot. 280slides proved high quality desktop class
applications are possible on the web ..._

So ... where are they now? It was a nicer webapp, but no substitute for
Keynote. Having worked with ObjJ/Cappaccino, I found it to be a frustrating
attempt at _working around_ the browser, rather than an actual solution.

 _Performance on the web hasn't _really_ been an issue in years. The real
issue is bad developers set the bar for web applications very low._

That's poppycock. In terme of performance, you simply can't come close to what
native apps are doing. We invest enormous effort in leveraging threading and
extremely low cost implementations in native code, even dropping down to
NEON/etc where appropriate.

There is room for higher level languages (arguably that's what ObjC _is_ ,
plus ARC) but JS simply is not a replacement for what native app developers
are doing. NaCL is.

~~~
Me1000
280slides was nothing more than a demo app that hasn't been touched in 3
years. Atlas was the real product of 280north. I suggest trying Cappuccino
today. If you're dealing with any significant browser issues, the problem is
certainly not Cappuccino.

You can talk benchmarks all you want, but it doesn't change the fact that for
99% of consumer facing applications you won't have any noticeable benefit from
those native speed.

~~~
nupark2
_You can talk benchmarks all you want, but it doesn't change the fact that for
99% of consumer facing applications you won't have any noticeable benefit from
those native speed._

I'm not talking about benchmarks, I'm talking about actual application
development, and the real impact the tremendous number of hours we spend as
consumer app decelopers on performance has on the user experience.

I honestly can't even fathom your position, given the context of my experience
maximizing application performance. All available CPU cycles are spent quite
directly on performance and functionality.

Your position implies to me a myopic inexperience with development beyond the
web.

~~~
Me1000
Exactly what kind of applications are you building that require lower level
languages in order to be performant? I can't think of an application I use on
a daily basis that can't be done equally well in the browser. Of course there
will always be certain applications that will need lower level support, but
those are a very small minority.

Your position implies to me a myopic inexperience with web development.

~~~
nupark2
_Exactly what kind of applications are you building that require lower level
languages in order to be performant?_

All of them. You don't necessarily need C, you simply need to not waste CPU
cycles on things that neither improve the user experience nor decrease
development costs. You could achieve this with a higher-level language,
including something like ObjC and ARC.

 _Your position implies to me a myopic inexperience with web development._

I'm very familiar with the space. Every cycle counts -- if a cycle is not
spent on user experience or decreasing development costs, it's a completely
wasted cycle. Browsers waste mountains of cycles.

Modern desktop and mobile software makes heavy use of SMP (threads), SIMD,
specific CPU-optimized code paths (in addition to SIMD, and requires that the
basic platform infrastructure be as low cost as possible. You simply could not
achieve glassy-smooth scrolling and other near-instantaneous UX otherwise.

I seriously doubt that you've _ever_ built a desktop/mobile application given
that you "can't think of an application I use on a daily basis that can't be
done equally well in the browser.".

------
cousin_it
The article does a really good job outlining the problem:

1\. The web is losing ground to mobile apps. The New York Times should have
been the perfect use case for the web, yet they are a native app on mobile
platforms. If we extrapolate this rate of change, five years from now people
will be self-publishing blog apps instead of sending you a URL.

2\. That's because the web lags behind native apps in features and polish of
user experience.

3\. Which is because innovation on the web is gated on major browser vendors,
who are slow and prone to political infighting (e.g. over video codecs).

4\. The only way for little guys to add features to the web (e.g. video) is to
make browser plugins (e.g. Flash). So the crusade against Flash and plugins
was a bad thing.

Then the article goes on to propose a solution that I don't think is very
good, but hey, at least it's a try.

------
nupark2
While it's great to see web guys confronting the very real failings of HTML/JS
as an application platform, I think the cultural inertia is practically
insurmountable.

Web developers will be the least receptive audience possible to the idea that
web applications can't compete as-is with native platforms. Native development
requires a whole new skillset -- one that is likely beyond that of many
existing web developers, and it requires abandoning years of cognitive
training. It requires admitting that you can't necessarily have both a great
app and search engine indexible app.

Google may succeed with NaCL, but I don't see how anyone else will. Mozilla is
steadfastly opposed to progress beyond HTML/JS, and Apple has no interest in
undercutting their own platforms.

------
kr589213
A response to Joe Hewitt's "Web Technologies need an Owner"

~~~
rbranson
Suffers the same problem: long on words, very short on evidence. It's
theology.

~~~
tolmasky
Care to elaborate? I feel that I went out of my way to provide a number of
pertinent examples.

I pointed to the trend of traditional web properties moving to native apps
when it came to mobile. Things like nytimes, economist, and even Facebook.

I discussed how most new social networks on mobile that have gained any
traction or attention (such as FourSquare and Path) were largely a native
phenomenon (even Google+ chose to have a native iPhone app).

I talked about very real examples of how Flash was important in the
development of the web.

I believe that there are a lot of valid counterpoints to my argument, and I'm
actually really interested in hearing and thinking about them. However, I
don't think hand-waiving it away as "theology" is one of them.

------
johngalt
If you look at the old OSI model and the original thoughts of the way the
internet was supposed to work you see that it was supposed to be vastly more
diverse than simply a browser window rendering HTML.

------
icebraining
Terrible, just terrible ideas.

This is looking only through the perspective of the content creator, ignoring
the client. We're only just know trying to add some structure to the content,
and we already have Microformats, RDFa and Microdata, all with incompatible
formats and semantics. Now we couldn't even rely on the semantics of HTML?

He sees the web as a app distribution mechanism and the browsers as just dumb
viewers. I think the web is much more than that: it's an information
distribution mechanism, and that's only possible if there is standardization
of protocols and formats.

~~~
tolmasky
I think you are focusing too much on the admittedly very unfleshed out
proposal for a solution, and less on what I think matters most, which is the
acceptance of what I believe to be a problem with the web.

Perhaps this is my fault for ending on that point, but do you also disagree
with all the other paragraphs? I ask this honestly, because if we can just
agree on that much, then I totally agree that there are a number of options
that are worth discussing to make the web competitive in a way that scales
again.

~~~
icebraining
I think the HTML/CSS/JS part of the web is competitive in certain domains, and
native apps on others. Frankly, I don't see the problem with this. Walled
gardens are certainly a problem, but there's no need to throw out the baby
(native apps) with the bathwater.

As for plugins, I've never seen them as benefit. Either you're a big player
and then you can influence the direction of the web, or you're just some
random guy and your plugin is irrelevant because no one will download it just
to see some websites.

There was an SVG plugin way before browsers supported it natively, but could
any web dev actually rely on it?

~~~
tolmasky
So you honestly never saw the benefit in having video on the web thanks to
Flash? Remember that even today HTML 5 video is not fully supported.

~~~
icebraining
I think Flash gave browsers the 'excuse' to postpone the implementation of a
real standard solution, that we're only know seeing the first steps of.

I bet we'd have seen the video tag on browsers years ago if Flash wasn't there
with a poor (GPU acceleration only last year, FFS!) but working solution.

