17 ms·

What Web Can Do Today

354 points by porsager 11y ago

sawwit 11y ago
I've been imagining a website lately that displays progress in a similar way for all kinds of things. Sort of like a global to-do list. Should be fun to build.
kalmar 11y ago
This is pretty great! Looking forward to more service worker support for more offline and push notifications.
ericjang 11y ago
what a time to be alive!
- Geee 11y ago
  You can't be serious.
  - throwaway533634 11y ago
    I'm a troll and even I find you unbearable!
AdmiralAsshat 11y ago
What's the framework powering the site itself? I'd assume Bootstrap, but it has a Material Design look to it.
- Arcsech 11y ago
  It's on GitHub[0], looks like Bootstrap with a material design addon. [0] https://github.com/NOtherDev/whatwebcando https://github.com/NOtherDev/whatwebcando
adevine 11y ago
I think this should be called "What the web can do someday." I mean, push notifications? If it's not supported by mobile safari, it's a non-starter for actual widespread adoption.
- djm_ 11y ago
  The ticks/crosses on the front page are related to "your current browser" (see key). Click through for detailed stats from caniuse.com.
- JohnTHaller 11y ago
  While this will affect the 44% of users that are locked into Mobile Safari IE6-style, there's no reason not to start adding the features supported by the open mobile platforms and desktop OSes to your web app.
slimsag 11y ago
This is really awesome :) The truth is that the 'web' is really becoming the cross-platform application architecture. Just a few years back I despised the very idea of this -- I want to program in my favorite language, not JavaScript (no matter how nice it is these days). I'd love to write applications that can act like native ones while also being cross platform (and use multiple threads at that!). The fact that WebAssembly[1] intends to eventually add support for multi-threaded programs and languages aside from JavaScript (including GC'd ones) is amazing. Personally I believe these are the two biggest blockers for most people who would want to write an app using web technology. Although they explicitly mention that their goal is not to replace JS in their FAQ, that IMO is more akin to a _"nothing will ever replace C"_ statement rather than a _"no apps will be written using other languages than C"_. [1] https://github.com/WebAssembly https://github.com/WebAssembly
- rimantas 11y ago
  The truth is that web is getting deeper and deeper into identity crisis. And if any platform is further away from having coherent architecture, it is web.
  - placebo 11y ago
    Exactly the same could have been said 15 years ago, and yet I'd argue it is the platform which has advanced the most in terms of both use and technology, and all this in spite of great standardization difficulties that other platforms didn't have to deal with. I expect the same to happen in the future on both desktop and mobile platforms, despite the FUD.
    - vezzy-fnord 11y ago
      It certainly has advanced the most, but that's a misleading presentation. It has advanced the most technologically only relative to its own starting position, i.e. it spent all this time catching up from blank state to where everyone else already was (and still is).
      - 11y ago
phonyphonecall 11y ago
It's interesting to compare the site opened in Chrome vs. Safari. I count 12 features desktop Chrome supports that desktop Safari does not (on El Capitan). A mobile comparison would be intriguing as well.
r3bl 11y ago
I really wish there's a way to check what other popular browsers can do without having to install them and open up the website.
- paulirish 11y ago
  Just click in on any of the features and you'll get details including the full cross-browser support.
  - marcoperaza 11y ago
    This only works for some of them.
- metasean 11y ago
  I like the concept, but I'm with you r3bl, for it to really be useful it needs to be more explicit –at a glance– about which browsers support which features. For example, more like https://kangax.github.io/compat-table/es6/ https://kangax.github.io/compat-table/es6/
- afandian 11y ago
  Do you know about http://caniuse.com/ http://caniuse.com/ ?
Sephr 11y ago
Why is the Network Information API still a thing? I don't feel like it should even be listed on this website, as it's an anti-feature. It only encourages discrimination on connection types, as it doesn't expose the only important part: is this connection metered? Developers are going to use this API to serve me higher resolution assets over my metered WiFi & Ethernet connections (assuming they are unmetered) and lower resolution assets over my unmetered cellular LTE connection (assuming it's metered). WiFi vs cellular vs Ethernet is not important. What's important is the usage policy behind the connection, and in its current state, the Network Information API can only be used to harm my user experience.
- Raed667 11y ago
  I think this is important in case of 2G/3G/LTE distinction. Where phones that can access only 2G networks should get served "light" version of websites.
  - thrownaway2424 11y ago
    I think it's likely that most people would prefer the "light" version.
    - Raed667 11y ago
      Absolutely not, have you tried 0.facebook.com ? Ux nightmare !
  - Sephr 11y ago
    This use case is already handled by navigator.connection.downlinkMax. There is no reason to include navigator.connection.type in this API if you want to serve different content based on downlink bandwidth.
- mmahemoff 11y ago
  How can a web browser or even native OS determine if a user's wifi network is metered? I agree it would be nice in theory if there was some kind of "dollars per MB" API, but I don't see how web browsers could implement that in practice. I work on a podcast app. When people are downloading hundreds of MB or more daily, they emphatically want control over when downloading takes place. In practice, almost all of them are satisfied with a binary choice between cellular or not. Those who do sometimes use expensive or slow wifi networks can blacklist them, which is also what network info APIs support. There are also other applications such as metering apps, utilities that trigger actions upon network changes. Some very popular Android apps (e.g. Tasker, IFTTT) rely on network info for that; web falls further behind if web apps can't access that data.
joeyspn 11y ago
Good as a quick reference for the cross-browser state of HTML5 in mobile devices, but highly misleading for building mobile apps with web technologies, because if you plan to build an APP for mobile, chances are you'll end using Crosswalk/Chromium. https://crosswalk-project.org/ https://crosswalk-project.org/
fiatjaf 11y ago
Still, people think the web is going to die and native apps are going to rule.
- placebo 11y ago
  some people think the web is going to die and native apps are going to rule. I'm not one of them. I'm guessing the "web based apps are crap" agenda is important to those who stand to lose from less people developing native apps (less chance for platform lock in, less projects for native app developers etc. ), and from those who used web based apps developed by not so capable developers. That does not mean that web based apps will (or should) replace native apps. There will always be enough applications where native will do the work better, even as processing power grows, but to say the web is going to die is just wishful thinking on the part of those who want it to die. Ain't gonna happen.
thrownaway2424 11y ago
One of the things the web can do, apparently, is animated transitions with very poor frame rates :-/
eridius 11y ago
I'm very surprised to see this claim that Safari on OS X[1] can't handle Push Notifications, because it's been able to do that for a few years now. It's just not using Service Workers. It uses a separate solution built around the Apple Push Notification service. Granted, this isn't cross-platform and isn't a W3C standard, but it is a capability that can be used today. But of course the whole section on "Push Notifications" is actually just a description of Service Workers. [1] Which isn't actually a listed browser, but it has the X next to it when viewed in Safari and the underlying caniuse.com data is for Service Workers, which Safari doesn't support.
- Navarr 11y ago
  This website is about implementation of W3C standards, from what I grasped. So it is not surprised that it doesn't claim Safari can handle push notifications. As it cannot.
  - eridius 11y ago
    No it's not. It's about HTML5 device APIs. > Can I rely on the Web Platform features to build my app? An overview of the device integration HTML5 APIs It's just relying on data from caniuse.com about W3C standards, but the page itself does not say anywhere that I can see that it's ignoring non-W3C browser-specific APIs. Which is rather misleading.
- realityking 11y ago
  If I'm not mistaken on iOS you can only do it if you wrap you r web app into a native app. On OS X however you can actually get real push notifications even for websites.
azakai 11y ago
What does the X axis in the "browser support" graphs mean? It seems to go up to 30, and has fractions along the way, both of which suggest it isn't a simple version number. A percentage of something, perhaps? edit: I guess it's market share? but which measurement?
- strange_quark 11y ago
  It looks like version number, which seems like a really dumb metric to put on the X axis.
  - azakai 11y ago
    If it's a version number, it seems out of date - Firefox is at 42, Chrome at 46, but the axis only goes up to 30. That's why I suspect it's market share, but that's just a guess.
- kevinbowman 11y ago
  If you hover over the bars, the "Global Market Share" numbers seem to match up so I guess it's that.
kristopolous 11y ago
There's some issues with the code. navigator.contacts for instance, is not supported in my browser (or any browser at all, except for the most recent mobile firefox - I'm on a desktop) yet the website says that indeed, my desktop browser supports it. Same is true with navigator.getBattery() which supposedly will run fine in my console (it doesn't).
hitekker 11y ago
>Behave Like A Native App The keyword is "like".
deleted 11y ago
[deleted]
majika 11y ago
What the web is increasingly unable to do today: provide text content without requiring a code execution environment. This site is another example of that. All non-application websites should provide all their content in semantic HTML at appropriate HTTP endpoints, with CSS styling (in as few requests as possible) as required per the design, and JavaScript (in as few requests as possible) that takes the semantic HTML and makes it interactive (potentially adding and removing elements from the DOM) as required per the design. The CSS should not depend on mutations resulting from the JavaScript, nor should the JavaScript assume anything of the applied styles (as the user agent should be able to easily apply custom user-styles for your site; e.g. Gmail only providing a limited set of styles that are managed server-side is laughable). Thus, all content is readable and styled properly without requiring an arbitrary code execution environment. That is what the web was meant to be. Unfortunately, most "web developers" have made the web worse over the past 10 years because simple, functional, minimal technology is not impressive, and hipsters love to show off. Nor does it help that there are few capitalist incentives for the web being open and malleable -- e.g. so users can easily use a different front-end for Facebook, or users can easily choose to avoid analytics or advertisements, or users might prefer to use the website rather than the app (providing access to personal details, contacts, location, tracking, etc). The state of the web is emergent and I'm not sure what anyone could do about it (perhaps make a better browser?), but it really irks me when web developers pretend like they're actually doing something good or useful, or that the web is actually in a healthy state. In my experience, it's the people who don't talk about web development who are the best web developers; these are the people who don't wince when they write a HTML document without a single `<script>`.
- nandhp 11y ago
  > What the web is increasingly unable to do today: provide text content without requiring a code execution environment. This site is another example of that. I was about to argue that this website is actually an excellent example of what you seek -- each link has a separate URL associated with it that returns a page containing that content. The links point to these real URLs so they work with "open in new tab" and "copy link" and in browsers without JavaScript enabled, while the JavaScript that runs when you click it changes the page content via AJAX (possibly saving a few round-trips) and updates the current page URL so that back/forward history and the address bar both work just like you're navigating between real webpages. And this works perfectly in Firefox (with JavaScript) and almost perfectly in Lynx (the table of contents still fills the first screenful, but that's hard to fix since Lynx doesn't support CSS). But it completely fails if you have JavaScript disabled in Firefox. Every page starts with the table of contents visible and the content collapsed (through CSS). The page then seems to assume that JavaScript will be able to immediately switch the page to the correct view (i.e. the site is broken if you have working CSS but not JavaScript). Navigation to a given page directly should start the other way by default, and to make that happen is just 21 missing characters (` class="page-feature"` on the <body> tag). However, this unfortunate error completely ruins this otherwise beautiful example of progressive enhancement.
dheera 11y ago
More stuff the web can't do that native apps can do: * Request stuff from arbitrary URLs without a CORS proxy * Open TCP and UDP sockets * Be in the play store/app store AS a web app (home screen installation isn't enough; people still search for your thing in the app store, so even if the other problems aren't issues for your app, you still have to wrap your web app in a dummy native framework and upload it if you want users to discover you) * Scroll like a native app without Safari's stupid rubber band scrolling the entire app at very erratic times * Barometric sensors * Background geolocation, background anything really * launchActivityForResult so you can work with other native goodies * Intent resolution for native actions * Geolocation when the user has inadvertently blanket-blocked Geolocation for all of Safari instead of per-webpage. Thankfully Chrome comes pre-approved on Android and you can't accidentally make this mistake as a user * Face tracking and other OpenCV-based stuff (it's been done, but JS is still not fast enough on mobile to handle these jobs) * Display long lists of styled content and scroll without stalling Still though I think touch gestures is really the killer missing feature. There isn't any canonically-supported way to do things like a simple Android ViewPager or pinch-to-zoom. You end up implementing a bunch of spaghetti code to do these things even in the best frameworks (Meteor, Phonegap + Polymer, Angular et al.). And then you find out the way your spaghetti code reacts is a tad different from the way someone else's spaghetti code reacts to the same gestures. This stuff really needs to be standardized on a OS, browser, or at least JS-framework level.
- deathanatos 11y ago
  I'm not saying that native apps > web apps isn't true, but… > * Request stuff from arbitrary URLs without a CORS proxy CORS isn't a proxy; it's a browser policy/algorithm that allows a site the opportunity to say "yes (or no), other websites may (or may not) make AJAX requests here". The native app (unless you've informed it somehow, or it has done something malicious) doesn't have the user's cookies, whereas the browser does, and needs to be a bit more cautious. > * Open TCP and UDP sockets There are websockets, which aren't the same, I'll admit. Frankly, I'm not sure I want my web pages to be able to arbitrarily open TCP/UDP sockets. (I don't really want my native apps to be able to on whim, either…) > * Barometric sensors You mean like current air pressure? Are there common devices out there with these? (None of my computing devices have anything like this, for example.) (and what would I want this for?)
cft 11y ago
What can Go do that Python cannot? Nothing. Why are there droves of projects that are migrated from Python to Go? Because Go is fast. Web apps are too slow on mobile.
- dsjoerg 11y ago
  what does python or go have to do with this web page? what does go have to do with making web apps faster?
asdfprou 11y ago
Excellent choice of colour and tasteful use of animations =)
deleted 11y ago
[deleted]
deleted 11y ago
[deleted]
hugozap 11y ago
The Web Platform will be always criticised and that's a good sign. So many eyes on it are improving it much faster than other platforms.
wener 11y ago
I just want to know what the web can not do today,because I think the web can do everything today.
lucb1e 11y ago
Proximity sensor, ambient light sensor, vibration, access to contacts, change screen orientation... gee, I didn't know Firefox could do all that on my laptop!
djtriptych 11y ago
Great site - quick usability notes: - Left align all features - Align icons - Align check marks - Consider using heavier-looking icons for supported/not-supported. - Promote the checkmark / ex legend to the top of the page.
faizanbhat 11y ago
I think this is a well thought out list. I find it saddening that the 'health' of the web has deteriorated to a point where it's arguably uncompetitive for a vast number of modern applications including information discovery. I find it troubling that information discovery is moving away from the open web into non-neutral native application environments such as Facebook, Snapchat, and Twitter. Sure, information discovery on the web was driven by search engines. But I think search engines are really just part and parcel of the web (and arguably a feature that ought to have been built into web browsers from the beginning). A search engine doesn't express bias towards any information source (at least not by principle). What troubles me is imagining a future where a vast majority of information that we consume is selected and curated by commercially driven, black box, non-neutral platforms. I read an article recently about how Google is experimenting with removing the need to download apps by 'streaming' app content through a search box. Presumably, this is how Google search stays relevant in the post-web era where more and more information flows through walled gardens installed on mobile devices. Now, instead of re-inventing the web, shouldn't we be working towards 'fixing' the one that exists? This list provides a decent 10,000 ft overview of the problems. Eager to hear your thoughts.
jorangreef 11y ago
Browsers are great at rendering. But they are terrible when it comes to exposing the raw power and capability of a machine to web apps that the user wants to trust. They spec their API implementations by committee (and committees of committees) and they rarely implement any spec in its entirety. The web is becoming increasingly fragmented as a result. The web is good for "web pages", but bad for "web apps". The web currently has no concept of a trusted web app. For example, we have been waiting for years for browsers to give web apps some way to access the filesystem, and all we have is an open dialog and a file instance (and the debris of the failed filesystem api). And when will web apps (not "web pages") get TCP or UDP? The browsers will never be able to match the module ecosystem and core power of Node. The way forward: 1. Give the power back to users. Give them a boolean way to indicate that they trust and want to install a web app. 2. If the web app is trusted and installed, give it access to Node. In a matter of months, this could exponentially boost web apps, lighten the bloated browser codebase, keep the focus on browser rendering, and keep committee fingers off web app innovation.
- pdkl95 11y ago
  > The web is good for "web pages" That is, after all, what it was designed for. Making web pages interactive in any way beyond a <form> has always been a hack. > give web apps some way to access the filesystem > And when will web apps (not "web pages") get TCP or UDP? First, if it's in a browser, there isn't much of a distinction between "web apps" and "web pages". The browser, by definition, exists as a sandbox that renders unsafe data and code. Allowing any kind of access to the filesystem or TCP or UDP will hopefully never happen. All networked software needs to implementing security concerns as the first and highest priority, If you aren't, you're putting the people that use your software at risk. The browser must always[1] be limited in what it an do. If you want to do more (which is fine), write a standalone application. If your favorite platform doesn't let you write such applications, complain to the vendor or change to something that isn't hostile to software development. > the module ecosystem and core power of Node. That ecosystem is tiny compared to what is available in /usr/lib64/. I like Javascript, but there is a lot more to computing outside that single ecosystem. [1] Unfortunately current browsers are already over the line with what they allow pages to access.

354 points by porsager 11y ago

I've been imagining a website lately that displays progress in a similar way for all kinds of things. Sort of like a global to-do list. Should be fun to build.

kalmar 11y ago

This is pretty great! Looking forward to more service worker support for more offline and push notifications.

ericjang 11y ago

what a time to be alive!

Geee 11y ago
You can't be serious.
- throwaway533634 11y ago
  I'm a troll and even I find you unbearable!

AdmiralAsshat 11y ago

What's the framework powering the site itself? I'd assume Bootstrap, but it has a Material Design look to it.

Arcsech 11y ago
It's on GitHub[0], looks like Bootstrap with a material design addon. [0] https://github.com/NOtherDev/whatwebcando https://github.com/NOtherDev/whatwebcando

adevine 11y ago

I think this should be called "What the web can do someday." I mean, push notifications? If it's not supported by mobile safari, it's a non-starter for actual widespread adoption.

djm_ 11y ago
The ticks/crosses on the front page are related to "your current browser" (see key). Click through for detailed stats from caniuse.com.
JohnTHaller 11y ago
While this will affect the 44% of users that are locked into Mobile Safari IE6-style, there's no reason not to start adding the features supported by the open mobile platforms and desktop OSes to your web app.

slimsag 11y ago

This is really awesome :) The truth is that the 'web' is really becoming the cross-platform application architecture. Just a few years back I despised the very idea of this -- I want to program in my favorite language, not JavaScript (no matter how nice it is these days). I'd love to write applications that can act like native ones while also being cross platform (and use multiple threads at that!). The fact that WebAssembly[1] intends to eventually add support for multi-threaded programs and languages aside from JavaScript (including GC'd ones) is amazing. Personally I believe these are the two biggest blockers for most people who would want to write an app using web technology. Although they explicitly mention that their goal is not to replace JS in their FAQ, that IMO is more akin to a _"nothing will ever replace C"_ statement rather than a _"no apps will be written using other languages than C"_. [1] https://github.com/WebAssembly https://github.com/WebAssembly

rimantas 11y ago
The truth is that web is getting deeper and deeper into identity crisis. And if any platform is further away from having coherent architecture, it is web.
- placebo 11y ago
  Exactly the same could have been said 15 years ago, and yet I'd argue it is the platform which has advanced the most in terms of both use and technology, and all this in spite of great standardization difficulties that other platforms didn't have to deal with. I expect the same to happen in the future on both desktop and mobile platforms, despite the FUD.
  - vezzy-fnord 11y ago
    It certainly has advanced the most, but that's a misleading presentation. It has advanced the most technologically only relative to its own starting position, i.e. it spent all this time catching up from blank state to where everyone else already was (and still is).
    - 11y ago

phonyphonecall 11y ago

It's interesting to compare the site opened in Chrome vs. Safari. I count 12 features desktop Chrome supports that desktop Safari does not (on El Capitan). A mobile comparison would be intriguing as well.

r3bl 11y ago

I really wish there's a way to check what other popular browsers can do without having to install them and open up the website.

paulirish 11y ago
Just click in on any of the features and you'll get details including the full cross-browser support.
- marcoperaza 11y ago
  This only works for some of them.
metasean 11y ago
I like the concept, but I'm with you r3bl, for it to really be useful it needs to be more explicit –at a glance– about which browsers support which features. For example, more like https://kangax.github.io/compat-table/es6/ https://kangax.github.io/compat-table/es6/
afandian 11y ago
Do you know about http://caniuse.com/ http://caniuse.com/ ?

Sephr 11y ago

Why is the Network Information API still a thing? I don't feel like it should even be listed on this website, as it's an anti-feature. It only encourages discrimination on connection types, as it doesn't expose the only important part: is this connection metered? Developers are going to use this API to serve me higher resolution assets over my metered WiFi & Ethernet connections (assuming they are unmetered) and lower resolution assets over my unmetered cellular LTE connection (assuming it's metered). WiFi vs cellular vs Ethernet is not important. What's important is the usage policy behind the connection, and in its current state, the Network Information API can only be used to harm my user experience.

Raed667 11y ago
I think this is important in case of 2G/3G/LTE distinction. Where phones that can access only 2G networks should get served "light" version of websites.
- thrownaway2424 11y ago
  I think it's likely that most people would prefer the "light" version.
  - Raed667 11y ago
    Absolutely not, have you tried 0.facebook.com ? Ux nightmare !
- Sephr 11y ago
  This use case is already handled by navigator.connection.downlinkMax. There is no reason to include navigator.connection.type in this API if you want to serve different content based on downlink bandwidth.
mmahemoff 11y ago
How can a web browser or even native OS determine if a user's wifi network is metered? I agree it would be nice in theory if there was some kind of "dollars per MB" API, but I don't see how web browsers could implement that in practice. I work on a podcast app. When people are downloading hundreds of MB or more daily, they emphatically want control over when downloading takes place. In practice, almost all of them are satisfied with a binary choice between cellular or not. Those who do sometimes use expensive or slow wifi networks can blacklist them, which is also what network info APIs support. There are also other applications such as metering apps, utilities that trigger actions upon network changes. Some very popular Android apps (e.g. Tasker, IFTTT) rely on network info for that; web falls further behind if web apps can't access that data.

joeyspn 11y ago

Good as a quick reference for the cross-browser state of HTML5 in mobile devices, but highly misleading for building mobile apps with web technologies, because if you plan to build an APP for mobile, chances are you'll end using Crosswalk/Chromium. https://crosswalk-project.org/ https://crosswalk-project.org/

fiatjaf 11y ago

Still, people think the web is going to die and native apps are going to rule.

placebo 11y ago
some people think the web is going to die and native apps are going to rule. I'm not one of them. I'm guessing the "web based apps are crap" agenda is important to those who stand to lose from less people developing native apps (less chance for platform lock in, less projects for native app developers etc. ), and from those who used web based apps developed by not so capable developers. That does not mean that web based apps will (or should) replace native apps. There will always be enough applications where native will do the work better, even as processing power grows, but to say the web is going to die is just wishful thinking on the part of those who want it to die. Ain't gonna happen.

thrownaway2424 11y ago

One of the things the web can do, apparently, is animated transitions with very poor frame rates :-/

eridius 11y ago

I'm very surprised to see this claim that Safari on OS X[1] can't handle Push Notifications, because it's been able to do that for a few years now. It's just not using Service Workers. It uses a separate solution built around the Apple Push Notification service. Granted, this isn't cross-platform and isn't a W3C standard, but it is a capability that can be used today. But of course the whole section on "Push Notifications" is actually just a description of Service Workers. [1] Which isn't actually a listed browser, but it has the X next to it when viewed in Safari and the underlying caniuse.com data is for Service Workers, which Safari doesn't support.

Navarr 11y ago
This website is about implementation of W3C standards, from what I grasped. So it is not surprised that it doesn't claim Safari can handle push notifications. As it cannot.
- eridius 11y ago
  No it's not. It's about HTML5 device APIs. > Can I rely on the Web Platform features to build my app? An overview of the device integration HTML5 APIs It's just relying on data from caniuse.com about W3C standards, but the page itself does not say anywhere that I can see that it's ignoring non-W3C browser-specific APIs. Which is rather misleading.
realityking 11y ago
If I'm not mistaken on iOS you can only do it if you wrap you r web app into a native app. On OS X however you can actually get real push notifications even for websites.

azakai 11y ago

What does the X axis in the "browser support" graphs mean? It seems to go up to 30, and has fractions along the way, both of which suggest it isn't a simple version number. A percentage of something, perhaps? edit: I guess it's market share? but which measurement?

strange_quark 11y ago
It looks like version number, which seems like a really dumb metric to put on the X axis.
- azakai 11y ago
  If it's a version number, it seems out of date - Firefox is at 42, Chrome at 46, but the axis only goes up to 30. That's why I suspect it's market share, but that's just a guess.
kevinbowman 11y ago
If you hover over the bars, the "Global Market Share" numbers seem to match up so I guess it's that.

kristopolous 11y ago

There's some issues with the code. navigator.contacts for instance, is not supported in my browser (or any browser at all, except for the most recent mobile firefox - I'm on a desktop) yet the website says that indeed, my desktop browser supports it. Same is true with navigator.getBattery() which supposedly will run fine in my console (it doesn't).

hitekker 11y ago

>Behave Like A Native App The keyword is "like".

deleted 11y ago

[deleted]

majika 11y ago

What the web is increasingly unable to do today: provide text content without requiring a code execution environment. This site is another example of that. All non-application websites should provide all their content in semantic HTML at appropriate HTTP endpoints, with CSS styling (in as few requests as possible) as required per the design, and JavaScript (in as few requests as possible) that takes the semantic HTML and makes it interactive (potentially adding and removing elements from the DOM) as required per the design. The CSS should not depend on mutations resulting from the JavaScript, nor should the JavaScript assume anything of the applied styles (as the user agent should be able to easily apply custom user-styles for your site; e.g. Gmail only providing a limited set of styles that are managed server-side is laughable). Thus, all content is readable and styled properly without requiring an arbitrary code execution environment. That is what the web was meant to be. Unfortunately, most "web developers" have made the web worse over the past 10 years because simple, functional, minimal technology is not impressive, and hipsters love to show off. Nor does it help that there are few capitalist incentives for the web being open and malleable -- e.g. so users can easily use a different front-end for Facebook, or users can easily choose to avoid analytics or advertisements, or users might prefer to use the website rather than the app (providing access to personal details, contacts, location, tracking, etc). The state of the web is emergent and I'm not sure what anyone could do about it (perhaps make a better browser?), but it really irks me when web developers pretend like they're actually doing something good or useful, or that the web is actually in a healthy state. In my experience, it's the people who don't talk about web development who are the best web developers; these are the people who don't wince when they write a HTML document without a single `<script>`.

nandhp 11y ago
> What the web is increasingly unable to do today: provide text content without requiring a code execution environment. This site is another example of that. I was about to argue that this website is actually an excellent example of what you seek -- each link has a separate URL associated with it that returns a page containing that content. The links point to these real URLs so they work with "open in new tab" and "copy link" and in browsers without JavaScript enabled, while the JavaScript that runs when you click it changes the page content via AJAX (possibly saving a few round-trips) and updates the current page URL so that back/forward history and the address bar both work just like you're navigating between real webpages. And this works perfectly in Firefox (with JavaScript) and almost perfectly in Lynx (the table of contents still fills the first screenful, but that's hard to fix since Lynx doesn't support CSS). But it completely fails if you have JavaScript disabled in Firefox. Every page starts with the table of contents visible and the content collapsed (through CSS). The page then seems to assume that JavaScript will be able to immediately switch the page to the correct view (i.e. the site is broken if you have working CSS but not JavaScript). Navigation to a given page directly should start the other way by default, and to make that happen is just 21 missing characters (` class="page-feature"` on the <body> tag). However, this unfortunate error completely ruins this otherwise beautiful example of progressive enhancement.

dheera 11y ago

More stuff the web can't do that native apps can do: * Request stuff from arbitrary URLs without a CORS proxy * Open TCP and UDP sockets * Be in the play store/app store AS a web app (home screen installation isn't enough; people still search for your thing in the app store, so even if the other problems aren't issues for your app, you still have to wrap your web app in a dummy native framework and upload it if you want users to discover you) * Scroll like a native app without Safari's stupid rubber band scrolling the entire app at very erratic times * Barometric sensors * Background geolocation, background anything really * launchActivityForResult so you can work with other native goodies * Intent resolution for native actions * Geolocation when the user has inadvertently blanket-blocked Geolocation for all of Safari instead of per-webpage. Thankfully Chrome comes pre-approved on Android and you can't accidentally make this mistake as a user * Face tracking and other OpenCV-based stuff (it's been done, but JS is still not fast enough on mobile to handle these jobs) * Display long lists of styled content and scroll without stalling Still though I think touch gestures is really the killer missing feature. There isn't any canonically-supported way to do things like a simple Android ViewPager or pinch-to-zoom. You end up implementing a bunch of spaghetti code to do these things even in the best frameworks (Meteor, Phonegap + Polymer, Angular et al.). And then you find out the way your spaghetti code reacts is a tad different from the way someone else's spaghetti code reacts to the same gestures. This stuff really needs to be standardized on a OS, browser, or at least JS-framework level.

deathanatos 11y ago
I'm not saying that native apps > web apps isn't true, but… > * Request stuff from arbitrary URLs without a CORS proxy CORS isn't a proxy; it's a browser policy/algorithm that allows a site the opportunity to say "yes (or no), other websites may (or may not) make AJAX requests here". The native app (unless you've informed it somehow, or it has done something malicious) doesn't have the user's cookies, whereas the browser does, and needs to be a bit more cautious. > * Open TCP and UDP sockets There are websockets, which aren't the same, I'll admit. Frankly, I'm not sure I want my web pages to be able to arbitrarily open TCP/UDP sockets. (I don't really want my native apps to be able to on whim, either…) > * Barometric sensors You mean like current air pressure? Are there common devices out there with these? (None of my computing devices have anything like this, for example.) (and what would I want this for?)

cft 11y ago

What can Go do that Python cannot? Nothing. Why are there droves of projects that are migrated from Python to Go? Because Go is fast. Web apps are too slow on mobile.

dsjoerg 11y ago
what does python or go have to do with this web page? what does go have to do with making web apps faster?

asdfprou 11y ago

Excellent choice of colour and tasteful use of animations =)

deleted 11y ago

[deleted]

deleted 11y ago

[deleted]

hugozap 11y ago

The Web Platform will be always criticised and that's a good sign. So many eyes on it are improving it much faster than other platforms.

wener 11y ago

I just want to know what the web can not do today,because I think the web can do everything today.

lucb1e 11y ago

Proximity sensor, ambient light sensor, vibration, access to contacts, change screen orientation... gee, I didn't know Firefox could do all that on my laptop!

djtriptych 11y ago

Great site - quick usability notes: - Left align all features - Align icons - Align check marks - Consider using heavier-looking icons for supported/not-supported. - Promote the checkmark / ex legend to the top of the page.

faizanbhat 11y ago

I think this is a well thought out list. I find it saddening that the 'health' of the web has deteriorated to a point where it's arguably uncompetitive for a vast number of modern applications including information discovery. I find it troubling that information discovery is moving away from the open web into non-neutral native application environments such as Facebook, Snapchat, and Twitter. Sure, information discovery on the web was driven by search engines. But I think search engines are really just part and parcel of the web (and arguably a feature that ought to have been built into web browsers from the beginning). A search engine doesn't express bias towards any information source (at least not by principle). What troubles me is imagining a future where a vast majority of information that we consume is selected and curated by commercially driven, black box, non-neutral platforms. I read an article recently about how Google is experimenting with removing the need to download apps by 'streaming' app content through a search box. Presumably, this is how Google search stays relevant in the post-web era where more and more information flows through walled gardens installed on mobile devices. Now, instead of re-inventing the web, shouldn't we be working towards 'fixing' the one that exists? This list provides a decent 10,000 ft overview of the problems. Eager to hear your thoughts.

jorangreef 11y ago

Browsers are great at rendering. But they are terrible when it comes to exposing the raw power and capability of a machine to web apps that the user wants to trust. They spec their API implementations by committee (and committees of committees) and they rarely implement any spec in its entirety. The web is becoming increasingly fragmented as a result. The web is good for "web pages", but bad for "web apps". The web currently has no concept of a trusted web app. For example, we have been waiting for years for browsers to give web apps some way to access the filesystem, and all we have is an open dialog and a file instance (and the debris of the failed filesystem api). And when will web apps (not "web pages") get TCP or UDP? The browsers will never be able to match the module ecosystem and core power of Node. The way forward: 1. Give the power back to users. Give them a boolean way to indicate that they trust and want to install a web app. 2. If the web app is trusted and installed, give it access to Node. In a matter of months, this could exponentially boost web apps, lighten the bloated browser codebase, keep the focus on browser rendering, and keep committee fingers off web app innovation.

pdkl95 11y ago
> The web is good for "web pages" That is, after all, what it was designed for. Making web pages interactive in any way beyond a <form> has always been a hack. > give web apps some way to access the filesystem > And when will web apps (not "web pages") get TCP or UDP? First, if it's in a browser, there isn't much of a distinction between "web apps" and "web pages". The browser, by definition, exists as a sandbox that renders unsafe data and code. Allowing any kind of access to the filesystem or TCP or UDP will hopefully never happen. All networked software needs to implementing security concerns as the first and highest priority, If you aren't, you're putting the people that use your software at risk. The browser must always[1] be limited in what it an do. If you want to do more (which is fine), write a standalone application. If your favorite platform doesn't let you write such applications, complain to the vendor or change to something that isn't hostile to software development. > the module ecosystem and core power of Node. That ecosystem is tiny compared to what is available in /usr/lib64/. I like Javascript, but there is a lot more to computing outside that single ecosystem. [1] Unfortunately current browsers are already over the line with what they allow pages to access.