
What Web Can Do Today - porsager
https://whatwebcando.today
======
majika
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>`.

~~~
bad_user
You're talking about " _progressive enhancement_ ". It's a romantic idea, but
it never happened, probably because it's too hard and the cost is not
justified given most users run with their browser's default settings.

The precursor of the web made by Tim Berners-Lee dates back to 1980, but it
was not based on HTML or HTTP. These happened later in 1990 and early 1991.
But then CSS happened in 1994. And Javascript happened in 1995 at Netscape,
but then Javascript was completely useless until Microsoft came up with the
iframe tag in 1996 and then with XMLHttpRequest in 1999, which was later
adopted by Mozilla, Safari and Opera. And people still couldn't grasp its
potential until Google delivered Gmail in 2004 and Google Maps in 2005.

Not sure what the " _the web was meant to be_ ", we should ask Tim Berners-Lee
sometimes, but in my opinion the web has been and is whatever its developers
and users wanted it to be, with contributions from multiple parties such as
Netscape, Microsoft, Mozilla, KDE/KHTML, Apple, Google and many other
contributors, being a constantly evolving platform.

~~~
jacquesm
CSS happened in 1996, the first couple of years of the web we had no CSS, all
styling was done with inline attributes up to that point.

The frustrating bit is that CSS was supposed to separate content/structure and
markup, but now we have pages _without_ content but with markup where the
content is loaded after the fact. This really overshot the mark.

~~~
TeMPOraL
Also note tat the separation of content and structure is mostly nonexistent as
it's currently practiced. People like to talk about it as a Golden Rule, a
holy virtue, and then proceed to write _even worse_ code than they did with
tables. Generally, if you find yourself writing a tangled mess of divs in
order to support CSS tricks, you're not really separating content from the
structure. HTML5 semantic tags helped a little, but I still rarely see them
used live.

(I'm not really convinced that separation of form and content is a feasible
goal anyway - some elements of form are also content at the same time - but
it's still a good goal to have.)

> _now we have pages without content but with markup where the content is
> loaded after the fact_

This is absolutely ridiculous and it, combined with the idea of routing
everything through the cloud in IoT / home automation applications, makes me
wonder what happened to some good old-fashioned _engineering sanity_. It's
like people are trying to create wasteful and insecure systems on purpose.
("And what would that purpose be," \- the cynic in me asks - "maybe monetizing
people's data?").

~~~
spion
Have you considered that there may be an actual reason _why_ people write a
tangled mess of divs. Could it be because the entire model is crappy and
people don't know what to do to make it show things the way they (or their
client) want(s)?

~~~
talmand
In my experience, as a front-end developer, the usual reason I need a mess of
divs and spans is to support a design that's not a good idea for a web page to
begin with.

~~~
spion
What is a web page, and why would a particular design not be a good idea for
it?

If a web page is not a good idea, then what other technology should be used to
achieve that design, as well as remain equally easy to distribute?

This mindset is precisely why native mobile applications continue to exist on
the market, and why articles like this one fail to convince me. Nobody (except
perhaps Facebook with React) tries to really fix the web to meet the demands
its been given. Instead everyone insists that the demands should change to
meet the original vision and limitations of the web.

Regarding the HTML/CSS interplay, flexbox gives me some new hope that
reconciliation is possible (getting both semantic markup and powerful /
precise styling).

~~~
talmand
It's easy to find designs that are bad ideas for web pages. The most obvious
culprit is a design that's excellent for a magazine layout. Such designs
typically don't take into account the document flow nor the idea that
different people open their browsers to different resolutions and browser
window sizes. Heck, some won't even take into account different browsers with
different capabilities. I think I understand where you're going with the "what
is a web page?" bit, but it doesn't necessarily apply. Especially since a web
page can be whatever anyone wants within the limitations of a browser, but
that doesn't mean a design works based on some person's idea of what they
think a web page is. In most cases a design is limited by the browser, not
necessarily by the code of the page.

I have no idea what you mean by your second sentence.

And then, are you referring to my mindset or some other mindset? Because I
fail to see how you can know my mindset on the matter. If it's the other, I
would agree. Except I would say that "fixing" something in terms of making it
do something it wasn't intended in the first place may possibly create more
problems than we are attempting to fix. I would suggest attempting new things
to see if they work, which there are some doing just that. I would point out
that flexbox is an example of this.

I'm excited with flexbox and have started pushing to make use of it more
often, when warranted. It's hard to switch current code to it, but I think
it's worth it. But, in the end, someone will eventually start complaining
about its limitations and that it needs to be "fixed". Then we'll be back
where we started, it's inevitable.

~~~
spion
My second sentence was the entire point. If a web page is not a good idea
because it can't support certain designs, then what would you suggest instead
(that also has the other properties of the web such as easy distribution and
is ubiquitous)?

I was referring to the whole mindset of "the web was not meant to do that".
Well, yeah, it wasn't. But its already doing that, so we have to do something
to make it properly rise up to the challenge.

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

~~~
mmahemoff
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.

~~~
pi-rat
Through DHCP, the DHCP server can set different DHCP-options to notify clients
what type of connection it is. For example: Android Phones set up to be a
hotspot will set DHCP option 43 to a value indicating that it's a metered
cellular connection.

~~~
sohcahtoa
I had no idea DHCP could even do that. What do Android devices do on unmetered
cellular connections? How do they know if the connection is metered or not?

~~~
HappyTypist
In android settings you can set if your connection is metered or not, and set
thresholds / warnings.

------
dheera
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
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?)

~~~
tschuy
> Are there common devices out there with these?

Most Android devices since maybe late 2012 have had one. It's used for
enhancing GPS lock, and whatever developers can dream up. All I've heard about
it being used for is a distributed air pressure sensor network used for
weather prediction, tracking, etc. [0[

0: [https://www.pressurenet.io/](https://www.pressurenet.io/)

~~~
dheera
Yes. The barometric sensors in the iPhone 6 and most high-end Android phones
of past 2 years are sensitive enough to determine +/-1 floor of building
movement, among a whole lot of other things. Very useful if you're writing a
hiking app, want to determine if the user is in an airplane or not, trying to
do vertical geolocation in a vertical city like New York or Hong Kong
(subtract user's barometric reading from the weather station and you'll have
it accurate to +/-a few floors), and a whole lot of other endless
possibilities.

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

------
slimsag
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
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
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
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).

~~~
bobajeff
The web does things those other platforms don't. Like run unsigned
applications from any server ephemerally on any machine or system.

It's not playing catch up so much as adding powerful features without
sacrificing it's core attributes.

~~~
TimJYoung
Yes, and yes. The things it can't do are a pain, but the things that it _can_
do are things that are _very_ difficult to do in a standardized way with
desktop/mobile. A cross-platform UI that simply works on just about any device
was considered the holy grail of computing at one point. Everyone gave up on
it after a while, and very quietly the web just "became" the platform that
enabled such a UI, without limiting how such a UI can be created.

------
r3bl
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
Just click in on any of the features and you'll get details including the full
cross-browser support.

~~~
marcoperaza
This only works for some of them.

------
lucb1e
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!

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

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

------
kristopolous
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).

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

~~~
Arcsech
It's on GitHub[0], looks like Bootstrap with a material design addon.

[0]
[https://github.com/NOtherDev/whatwebcando](https://github.com/NOtherDev/whatwebcando)

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

------
adevine
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_
The ticks/crosses on the front page are related to "your current browser" (see
key). Click through for detailed stats from caniuse.com.

------
sawwit
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
This is pretty great! Looking forward to more service worker support for more
offline and push notifications.

------
azakai
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
It looks like version number, which seems like a really dumb metric to put on
the X axis.

~~~
azakai
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.

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

------
asdfprou
Excellent choice of colour and tasteful use of animations =)

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

------
ericjang
what a time to be alive!

~~~
Geee
You can't be serious.

~~~
throwaway533634
I'm a troll and even I find you unbearable!

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

~~~
placebo
_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.

------
hitekker
>Behave Like A Native App

The keyword is "like".

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

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

------
joeyspn
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/)

------
cft
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
what does python or go have to do with this web page? what does go have to do
with making web apps faster?

