11 ms·

Tim Berners-Lee: If I can't give power to web apps, they can't compete

134 points by jorangreef 14y ago

asolove 14y ago
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.
- bthomas 14y ago
  Agree, but only because the items you cite here are too technical for an average user. I think the way the iPad implements location API is an example of permissions working really well.
- icebraining 14y ago
  I think he's making a different point. He's talking about what capabilities web apps should have, not necessarily about the UI. The user will have to give it those permissions; it's irrelevant to this discussion whether the user understands those details and if these are defined one-by-one or by a combination of trusting the app store and clicking "install".
- dreamdu5t 14y ago
  Why can't we have both? It can be easy for "normal" people to install while also giving "advanced" users the control they desire.
- chubot 14y ago
  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 14y ago
    You did need someones permission to setup a website and the web still took off. PS: DNS
    - Zaak 14y ago
      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 14y ago
        If memory holds, it wasn't until relatively late that they allowed you to use swear words in .com domain names.
        Zaak 14y ago
        Good point, but you could have as many swear words as you want in your page content.
- IsaacL 14y ago
  It sounds like he's taking about the "permissions model" that exists on Android, Facebook, etc. That is, before the user installs the app, they're given a list of what operations that app will be allowed to perform. It's a very simple interface, just one screen with "accept" or "decline".
- nilliams 14y ago
  > The only answer I can think of is through app stores run by trusted browser vendors. 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/pnhechapfaindjhompbnflcldabbghjo https://chrome.google.com/webstore/detail/pnhechapfaindjhomp...
- ktizo 14y ago
  Yes yes yes. Normal people want to install an app and just have it work. Which is exactly what Tim is describing the technical requirements of in terms of web apps.
- Joeri 14y ago
  "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." 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.
danso 14y ago
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.
- notatoad 14y ago
  note that he's not just "chiming in", he's employed by the W3C. It is his job to be a part of discussions like this.
- lmm 14y ago
  Didn't he react quite negatively when someone else added images to the web?
  - ktizo 14y ago
    Hmmm. But I hadn't wanted a special tag. http://1997.webhistory.org/www.lists/www-talk.1993q1/0186.html 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.
    - tedsuo 14y ago
      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.html http://1997.webhistory.org/www.lists/www-talk.1993q1/0182.ht...
    - guelo 14y ago
      And really Tim was right, a more general embedding tag, including text chunks, would have made the web better over the last 20 years.
jorangreef 14y ago
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 14y ago
  What about Native Client? If he wants "web apps" to be as powerful as native apps, isn't that a good direction?
  - mindcrime 14y ago
    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 14y ago
      yes
      - mindcrime 14y ago
showwayer 14y ago
Isn't HTML5 the effort of making web apps comparable to native apps?
famousactress 14y ago
He's just described native apps, but called them 'web'. The argument is semantic at this point.
- Lerc 14y ago
  I don't like the term web-apps for this reason. Some places refer to them as apps using web technologies to indicate that the things involved are HTML+JS rather than things that come via a Web Server. 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.
- laughinghan 14y ago
  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 14y ago
    > 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.
  - throwaway64 14y ago
simonbrown 14y ago
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 14y ago
  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 14y ago
    Do you work for Mozilla or is this your own project?
    - fzzzy 14y ago
      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 14y ago
        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 14y ago
        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.
lifeisstillgood 14y ago
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.
Kilimanjaro 14y ago
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.
bendemott 14y ago
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 14y ago
  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.
  - laughinghan 14y ago
    I consider ubiquity and instant-ness (i.e., accessibility) to be quite important aspects in which the Web platform is superior to native platforms. 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.
Lerc 14y ago
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 14y ago
  replicating native file system functionality is not necessarily desirable from a ux perspective.
  - Lerc 14y ago
    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 14y ago
      I think that's the theory behind Chrome OS.
      - Lerc 14y ago
        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.
julian37 14y ago
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 http://wiki.laptop.org/go/Bitfrost
programminggeek 14y ago
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".
pjmlp 14y ago
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 14y ago
  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 14y ago
    > Got to love that sandboxing The browser as application can also be exploited...
impldefined 14y ago
I know I'm not in the majority on this site, but I personally hate web apps. I hate how they look, I hate hearing about how they will replace native. Personally, I'd like to see native app front ends backed by REST web services that have a cheesy default "web" front end that will work but also tells you how much more powerful the native client is. Do people really want an OS to be nothing more than "the thing that opens the web browser"? Further, as long as the programming language of web apps has to be or compile to Javascript I'm against it. If it's going to be a platform then it should have a language neutral VM that we can all target. At least give me that.

134 points by jorangreef 14y ago

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.

bthomas 14y ago
Agree, but only because the items you cite here are too technical for an average user. I think the way the iPad implements location API is an example of permissions working really well.
icebraining 14y ago
I think he's making a different point. He's talking about what capabilities web apps should have, not necessarily about the UI. The user will have to give it those permissions; it's irrelevant to this discussion whether the user understands those details and if these are defined one-by-one or by a combination of trusting the app store and clicking "install".
dreamdu5t 14y ago
Why can't we have both? It can be easy for "normal" people to install while also giving "advanced" users the control they desire.
chubot 14y ago
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 14y ago
  You did need someones permission to setup a website and the web still took off. PS: DNS
  - Zaak 14y ago
    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 14y ago
      If memory holds, it wasn't until relatively late that they allowed you to use swear words in .com domain names.
      - Zaak 14y ago
        Good point, but you could have as many swear words as you want in your page content.
IsaacL 14y ago
It sounds like he's taking about the "permissions model" that exists on Android, Facebook, etc. That is, before the user installs the app, they're given a list of what operations that app will be allowed to perform. It's a very simple interface, just one screen with "accept" or "decline".
nilliams 14y ago
> The only answer I can think of is through app stores run by trusted browser vendors. 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/pnhechapfaindjhompbnflcldabbghjo https://chrome.google.com/webstore/detail/pnhechapfaindjhomp...
ktizo 14y ago
Yes yes yes. Normal people want to install an app and just have it work. Which is exactly what Tim is describing the technical requirements of in terms of web apps.
Joeri 14y ago
"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." 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.

danso 14y ago

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.

notatoad 14y ago
note that he's not just "chiming in", he's employed by the W3C. It is his job to be a part of discussions like this.
lmm 14y ago
Didn't he react quite negatively when someone else added images to the web?
- ktizo 14y ago
  Hmmm. But I hadn't wanted a special tag. http://1997.webhistory.org/www.lists/www-talk.1993q1/0186.html 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.
  - tedsuo 14y ago
    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.html http://1997.webhistory.org/www.lists/www-talk.1993q1/0182.ht...
  - guelo 14y ago
    And really Tim was right, a more general embedding tag, including text chunks, would have made the web better over the last 20 years.

jorangreef 14y ago

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 14y ago
What about Native Client? If he wants "web apps" to be as powerful as native apps, isn't that a good direction?
- mindcrime 14y ago
  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 14y ago
    yes
    - mindcrime 14y ago

showwayer 14y ago

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

famousactress 14y ago

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

Lerc 14y ago
I don't like the term web-apps for this reason. Some places refer to them as apps using web technologies to indicate that the things involved are HTML+JS rather than things that come via a Web Server. 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.
laughinghan 14y ago
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 14y ago
  > 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.
- throwaway64 14y ago

simonbrown 14y ago

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 14y ago
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 14y ago
  Do you work for Mozilla or is this your own project?
  - fzzzy 14y ago
    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 14y ago
      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 14y ago
        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.

lifeisstillgood 14y ago

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.

Kilimanjaro 14y ago

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.

bendemott 14y ago

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 14y ago
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.
- laughinghan 14y ago
  I consider ubiquity and instant-ness (i.e., accessibility) to be quite important aspects in which the Web platform is superior to native platforms. 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.

Lerc 14y ago

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 14y ago
replicating native file system functionality is not necessarily desirable from a ux perspective.
- Lerc 14y ago
  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 14y ago
    I think that's the theory behind Chrome OS.
    - Lerc 14y ago
      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.

julian37 14y ago

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 http://wiki.laptop.org/go/Bitfrost

programminggeek 14y ago

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

pjmlp 14y ago

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 14y ago
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 14y ago
  > Got to love that sandboxing The browser as application can also be exploited...

impldefined 14y ago

I know I'm not in the majority on this site, but I personally hate web apps. I hate how they look, I hate hearing about how they will replace native. Personally, I'd like to see native app front ends backed by REST web services that have a cheesy default "web" front end that will work but also tells you how much more powerful the native client is. Do people really want an OS to be nothing more than "the thing that opens the web browser"? Further, as long as the programming language of web apps has to be or compile to Javascript I'm against it. If it's going to be a platform then it should have a language neutral VM that we can all target. At least give me that.