Tim Berners-Lee: If I can't give power to web apps, they can't compete
lists.w3.org
lists.w3.org
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
...
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.
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.
PS: DNS
Exactly, that's clearly what Google are thinking too, as you can install apps from the Chrome web store with elevated privileges today, e.g. the Secure Shell app: https://chrome.google.com/webstore/detail/pnhechapfaindjhomp...
That's very easily solved. We just need a w3c spec for auth and payments in the browser, using browser-native UI and a pluggable framework so different identity providers and payment processors can hook into your browser.
If you think about it, the current system is equivalent to permanently giving a copy of your credit card to every shop you visit and telling them "bill me if you think i owe you something". The level of trust involved is mind boggling, and a system like that cannot ever become secure.
Nobody should see your cc details except your payment processor. Nobody should see your e-mail address except your identity provider (if a site wants to send you a mail, they should be using a browser-based notification api). The native app platforms have shown this works way better than the current browser model, so browsers need to play catch-up here.
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.
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?
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. :-(
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.
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?
TCP sockets in Javascript are getting standardized.
http://1997.webhistory.org/www.lists/www-talk.1993q1/0186.ht...
Maybe in the mildest sense imaginable, because he thought there was a better way of implementing it.
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
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.
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".
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.
I don't know what you mean by "truly excellent software", but I'd rather make imperfect, useful software than perfect software no one uses, wouldn't you? And it is certainly possible, and nowadays routine, to create simple, elegant, well-architected, maintainable, efficient, performant, small-footprint Web applications.
Yes, the Web platform has all kinds of warts and scars. In and of itself, all else being equal, they are of course strictly a bad thing. But the principle of openness and cross- and backwards compatibility--the principle that technical concerns must be balanced against community concerns--that is their root cause, I believe to be superior to any of the alternatives we've seen, which have given rise to proprietary standards, walled gardens, dependency and upgrade hell.
I agree that "throwing" more code at problems rarely results in elegant and efficient solutions, but disregarding existing community concerns, like legacy software or standards, rarely results in successful solutions.
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:
I don't think that makes it a semantic argument. I think it's more of semantic confusion. Too many people wanting different things are assembling under the one banner without realising how different their goals are.
I can make an app that does 90% of what I want quite quickly in HTML+JS, but I don't use that because I know the critical remaining 10% is impossible.
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.
a web browser
a calendar client
an IMAP client
I am currently writing a web browser in JavaScript for boot2gecko, there is a need
"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!
similarly, an online calendar is a calendar client. It interacts with some server somewhere. Same idea with mail - Gmail is an IMAP client.
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.
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.
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.
Downloading an app, worrying about spyware, having something run constantly in the background, no thanks
Got to love that sandboxing
The browser as application can also be exploited...