
Tim Berners-Lee: If I can't give power to web apps, they can't compete - jorangreef
http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0464.html#start464
======
asolove
I love the web, but let's be serious here.

    
    
      As a user when I install an app, I want to be able to give
      it access to a selection of:
      
      - Program storage, to a limit
      - Whether it is permanently available or downloaded or cached for a while
      - Access to RAM at runtime, to a limit
      ...
    

No no no. Normal people want to install an app and just have it work. They
trust iOS apps because of a perception that they are carefully monitored, and
because nothing particularly bad has ever happened. They don't trust the web
because everyone has heard of email, credit card, etc. scams. One big reason
for Apply to only allow in-app purchases through their system is that,
therefore, third-party apps never see credit card information and can't do too
much damage.

If you want web apps to succeed, figure out how a normal person is going to
find, install, and trust a web app not to steal their credit card info. The
only answer I can think of is through app stores run by trusted browser
vendors.

~~~
chubot
I see your basic point, but in the iOS case, something bad HAS happened --
your personal contacts may have been uploaded to the servers of many different
companies without your permission.

The crux of the issue is that the web can't be designed like Apple. The reason
the web took off is that it's decentralized. You don't need anyone's
permission to set up a web site.

And in fact the contacts fiasco kind of illustrates the point. That happened
because a company has monopoly on the (hidden) policies of their ecosystem.

I think one solution is to have programs that manage other programs in a
future operating system. You could configure that Berners-Lee mentions by
hand. But more likely you there could be a very simple system level app that
presents a wizard: "You're running out of storage. Here is a list of all apps
and how much storage their using." And it will guide the user through some
actions to adjust the capabilities.

It is an open problem to determine whether general users can infer "access to
my address book" + "network connectivity" -> "company can permanently store my
contacts and spam my friends", and the like.

~~~
Retric
You did need someones permission to setup a website and the web still took
off.

PS: DNS

~~~
Zaak
As far as I know, there was never any registrar who insisted on approving your
site's content before they would give you a DNS entry. Even if there was,
there were many other places you could register that didn't.

~~~
phillmv
If memory holds, it wasn't until relatively late that they allowed you to use
swear words in .com domain names.

~~~
Zaak
Good point, but you could have as many swear words as you want in your page
content.

------
jorangreef
There's a difference between a sandboxed web page, and a web app that you want
to install and use as a trusted application.

If UDP, TCP and POSIX were possible in the browser, with a simple permissions
dialog, web apps would be competitive with native apps. As Douglas Crockford
said, HTML5 has become everything but the kitchen sink.

It's not more high-level APIs that web apps need. It's three brilliant low-
level APIs implemented properly in Chrome and Firefox and Opera and Safari
with simple permissions. UDP, TCP, POSIX. Node has already done the work of
providing a cross-platform implementation and reasonably well-accepted
interface for these, that vendors could adopt. With these basic building
blocks in place, the community would be able to do the rest.

There's no reason why a web app should by definition not be able to do
anything that a native app can do.

~~~
mtgx
What about Native Client? If he wants "web apps" to be as powerful as native
apps, isn't that a good direction?

~~~
mindcrime
_What about Native Client? If he wants "web apps" to be as powerful as native
apps, isn't that a good direction?_

That's another option. But don't forget about using JNLP / Java Web Start if
you want the power of "native" apps, but delivered over the web. Trying to
turn a web browser into an Operating System + Crappy X-Server is just silly.
We're layering hacks on top of hacks on top of hacks, to use a web-browser to
do something it wasn't meant to do: remote application delivery / UI remoting.

Web browsers are great at browsing hypermedia, is it _really_ necessary that
they also try to replace the OS, networking stack and implement a poor man's X
server?

~~~
ZenPsycho
yes

~~~
mindcrime
Why? What are we gaining by cramming everything into the browser? We already
_have_ OS'es, networking stacks, and technologies for remoting out the UI of
server based apps, as well as techniques for delivering code to where the data
lives. Why not just use a tool that was designed for the task in question,
instead of building some unholy golem-like chimera of parts and bits and
pieces cribbed from here and there...

Seriously, a modern web-browser /web-app combo seems like something better
suited for a Lovecraft story (I'm thinking "Herbert West: Reanimator" in
particular) than real life. :-(

~~~
ZenPsycho
So I assume you use a desktop email client, and not gmail, or any other web
mail app, then?

~~~
mindcrime
Actually, yes, at least sometimes. Web based email clients are useful on
occasion, but that has nothing to do with the point I'm trying to make, which
is that we could do something _better_ than either "traditional" desktop apps,
or golem-like chimera apps crammed into a web-browser.

Why not use the browser for navigating hypermedia and then let the browser
handoff to a different app to do things that require richer interaction? It
doesn't have to be a pre-installed traditional desktop app... there's the
aforementioned JNLP, and who-knows-what-as-yet-uninvented approach. I'd love
to see more people spending time on that "as yet uninvented" thing that trying
to turn a browser into a crappy X server, and goofing around with nasty,
brutal hacks like AJAX.

~~~
ZenPsycho
I think you are overselling X server, I don't know if you've ever tried to use
X over a network but it's pretty awful. The web is not a crappy X server. It's
a much much much superior approach to the X server- in that it allows code to
run in the gui without the latency of sending every single mouse click and key
press over the network, and every single low level drawing command and
uncompressed pixel put back.

I think what you want has already been tried with Java applets. Java applets
had 10 years to establish themselves as the one true way to make professional
web apps and replace the OS. It was a monumental failure of epic proportions,
and javascript+html won that battle a thousand times over. Now you want to try
it again because .. why? Because you think it's a technically better approach.
It's just history disagrees with you.

The web can work over a modem and crummy mobile phone connections. X would be
hopelessly unusable under such conditions so it's a complete mystery to me why
you are claiming that the web is a "poor man's" X-server. You'd have to be
half mad to think that. The web could be 10 times more shitty than it is and
would still beat X for quality and responsiveness. So really... HUH!? WHAT?

------
danso
I think it's great that Tim Berners-Lee is still chiming in on the
contemporary issues involving the Web. From a latecomer like me, it seems the
Web (and the whole of society) has incomprehensibly changed since he first
specced it. That he can stay still be a leader goes to show how solid his
original proposals were.

~~~
lmm
Didn't he react quite negatively when someone else added images to the web?

~~~
ktizo
_Hmmm. But I hadn't wanted a special tag._

[http://1997.webhistory.org/www.lists/www-
talk.1993q1/0186.ht...](http://1997.webhistory.org/www.lists/www-
talk.1993q1/0186.html)

Maybe in the mildest sense imaginable, because he thought there was a better
way of implementing it.

~~~
tedsuo
Funny, I went back up a post and noticed it was Marc Andreessen who proposed
the img tag: [http://1997.webhistory.org/www.lists/www-
talk.1993q1/0182.ht...](http://1997.webhistory.org/www.lists/www-
talk.1993q1/0182.html)

------
Kilimanjaro
Let's say we have a calendar web app that we can run in the browser, or as a
chromeless popup, or downloaded as a chromeless app.

That calendar.app is a container to all the resources that conform the app,
made from html, css, js and varied media (img,audio,video) in plain readable
code, which has made the web safer, so everybody can poke under the hood.

    
    
        calendar.app
            /media
            /storage
            config.js
            main.js
            style.css
    

That app must explicitly say what resources it will access in a config.js json
file but still, all resources will be off by default, so the first time it
uses a defined resource it asks the user for permission, like location,
network traffic, storage, webcam, mic, etc. and it can never use any resource
not defined in the config.js file so no sneaky pics from the cam if webcam is
not define in the config.

The app would be sandboxed in its own installation folder and would have
access only to its own storage folder, plus, as TBL suggests, a shared storage
folder.

This all can be done today, we just need to put all the pieces together, so I
see that vision fully implemented in the very near future.

------
programminggeek
You can do this right now, it's called Apache Cordova(Phonegap) or
Appcelerator. He's right, without giving a web app a more direct interface
into your device, they can't compete with web connected "native apps".

It is not that you can't write highly complex native feeling things in HTML
and JS, it's that without real native hooks (both UI and hardware), it is
simply impossible to do things from the web that a user would expect their
device to be able to do.

If the user expects to be able to do something and they can't, it is a bad
experience and they find a better alternative, which right now means "native
apps".

------
bendemott
This all seems to assume that Javascript,css,html and the web 'stack' in
general are reasonable and efficient ways to write robust applications. I
fundamentally disagree.

~~~
gue5t
Finally some reason. Tried and true native methods are superior in just about
every aspect except 'shininess' (the DOM-based styling of CSS) and simplicity
for end-users that wish to not understand even the basic concepts behind the
systems they use. There's no reason to build on the abstraction of a browser
in order to build applications /except/ that it's ubiquitous/instant. This
seems to attract developers that want to get users more than they want to
develop truly excellent software.

Just about every other property of the web as a runtime makes a solid argument
against its usability: stability (browsers are trying to implement a process
model now because the JS/DOM sandbox/environment is not sufficiently robust to
be depended on to not crash), standardization ("use webkit" or "use
compatibility libraries in js" is a weak answer compared to real guarantees
from fairly static and mature standards), efficiency (everything goes through
at least: parsing, the DOM, javascript's broken (mostly-missing) typesystem,
etc., all at runtime or application startup), and simplicity (more layers mean
more complexity; we have various openGL standards and now also WebGL,
implemented on top of one or more of them on each platform; javascript as a
'bytecode analogue' for slightly more usable languages such as coffeescript).

Throwing more code at problems has rarely resulted in an elegant and efficient
solution, but that's the approach we're taking to try to get back the
performance and featureset lost from running web apps in a JS/DOM container.
We've wrapped enough fundamental OS features in JS libraries/DOM
extensions/HTML features. It's time to end this nonsense and create a real
standardized and generalized sandboxing model if that's what we want.

~~~
coopdog
I think the web could handle a fully re-imagined stack. So long as it adhered
to well defined standards and kept dns, with buy in from the major browsers
the two stacks could co-exist.

~~~
bendemott
+1 Agreed! Javascript has been in the bath too long, and it's looking pruny.

------
julian37
TBL's proposal reminds me of OLPC Bitfrost, which blew me away in 2006 (?)
when I first read about it (and OLPC was still hot.)

I don't actually know what became of it--unfortunately, I didn't yet get a
chance to play with an OLPC device, and after they forfeit large parts of
their vision in favor of a Microsoft-based solution I admittedly lost some of
my interest--but at any rate, looking over the Bitfrost spec again today I
think it is still relevant, and fairly close to what TBL has in mind:

<http://wiki.laptop.org/go/Bitfrost>

------
famousactress
He's just described native apps, but called them 'web'. The argument is
semantic at this point.

~~~
laughinghan
No, he didn't. Native platforms simply don't have the commitment to openness
and cross- and backwards-compatibility that the Web does. He described all the
advantages of native apps, but the disadvantages, the advantages of the Web,
are so uncompromisable they were implicit, so he didn't mention them.

There's a reason that compared to native platforms, the Web has way fewer
problems with proprietary standards, walled gardens, dependency and upgrade
hell.

~~~
floomp
> There's a reason that compared to native platforms, the Web has way fewer
> problems with proprietary standards, walled gardens, dependency and upgrade
> hell.

Compared to proprietary platforms like Windows or OS X, sure, but free
platforms like Linux and *BSD avoid all of that except maybe upgrades, and
that's only a minor inconvenience since package managers are pretty good.
Plus, you have the advantage of not being beholden to the web app provider's
upgrade schedule, where you can almost never revert to a previous version.

And while web apps (at least in their state today) are necessarily open in the
front-end, they're usually very closed on the server-side, which is definitely
a step backwards from Linux/BSD.

------
lifeisstillgood
TBL hits the nail on the head again CORS is a massive and crippling
restriction and needs to be overcome. Signing packaged js apps is one method
perhaps - but whatever we do we need to over ome the app store gatekeeper
somehow.

------
simonbrown

      a web browser
    

Why would I want a web browser inside a web browser?

    
    
      a calendar client
    

There are plenty of online calendars. I'm not familiar with calendar clients,
but what's the advantage of setting up a calendar protocol server rather than
using an online calendar or installing similar software?

    
    
      an IMAP client
    

Webmail?

~~~
daleharvey
Web apps cannot talk imap or to ical whatever, they need to be able to talk to
another non web platform that can do these things, usually via requests to a
web server.

I am currently writing a web browser in JavaScript for boot2gecko, there is a
need

~~~
MatthewPhillips
Do you work for Mozilla or is this your own project?

~~~
fzzzy
He works for Mozilla. (As do I)

"writing a browser" is a little bit of an exaggeration, since it's just all
the chrome being implemented, and HTML rendering is handled by gecko. But,
it's still a browser being implemented in js. It's pretty sweet.

I'm working on a tcpsocket API for js for the same project. It's being used to
implement an imap client in js. It's all part of the boot 2 gecko project.
It's quite fun!

~~~
jorangreef
Sounds good. Any chance you can encourage Mozilla to share UDP, TCP, POSIX
with those outside of boot2gecko? i.e. someone else who wants to build
something like boot2gecko but outside of Mozilla?

~~~
MatthewPhillips
B2G is 100% open-source and developed in the open. They even take pull
requests and have open meetings. They are going to be taking their work to
standards bodies and hopefully a lot of it gets picked up.

------
Lerc
I came up with a simple idea that will demonstrate when web-apps can compete
with native apps.

Replace notepad.exe with a webapp. Let it launch by double clicking on a .txt
file. Let you edit,open..., save, save as..., print, exit etc.

If you can't do everything notepad.exe does, your platform is crippled.

By all means allow protections so that this behaviour isn't available to every
app, but without those basics I'm not interested in using them, and it is
certainly a blocker for me to be developing them.

~~~
ZenPsycho
replicating native file system functionality is not necessarily desirable from
a ux perspective.

~~~
Lerc
It's not something that everything should be able to do, but it needs to be
possible.

It doesn't actually matter in the long run what the specific capabilities are,
The important thing is for web apps to be genuine apps that matter they need
to do anything that would be allowed from native code.

I don't actually mind them making a crippled platform, as long as they admit
that it is a crippled platform that can't do much of what I want.

Selectively disallowing certain behaviours is really something that should
occur at a different level that affects native and HTML/JS apps equally.

~~~
ZenPsycho
I think that's the theory behind Chrome OS.

~~~
Lerc
Except Chrome OS is developed by people who are motivated to hold your data
for you. I don't have a lot of faith in Chrome OS's ability to be independent
of a server model when it so much in Google's interest for you to be
effectively tethered to their servers.

~~~
ZenPsycho
have you seen this? <http://www.w3.org/TR/FileAPI/>

------
showwayer
Isn't HTML5 the effort of making web apps comparable to native apps?

------
pjmlp
And gladly so.

The Internet is for network protocols and documents.

Although I develop web applications, not by choice, I'll take a native desktop
application always over a so called "web application", when possible.

~~~
coopdog
What I love about web apps is that they're so ephemeral. You open it, try it,
close the window, and it's gone. And it only comes back if you ever go to that
domain again

Downloading an app, worrying about spyware, having something run constantly in
the background, no thanks

Got to love that sandboxing

~~~
pjmlp
> Got to love that sandboxing

The browser as application can also be exploited...

