
Regressive Web Apps - thekingshorses
https://adactio.com/journal/10708
======
iLoch
I'm so tired of people using "it doesn't work without JavaScript!" as an
argument. To me it sounds as relevant as saying "it doesn't work without
HDMI!"

What is so bad about JS that you just can't use the web with it enabled? Grow
up.

The web is a platform that is _evolving_ far beyond its original intent. In a
few years its going to be a binary delivery platform. _And that 's great
news._ The idea that the web needs to stay the way it was designed in the 90s
is what's really regressive.

Here's what matters about the web:

\- Linking

\- Standards for Web APIs

\- Content delivery protocols

Everything else - as far as I'm concerned - is a transient feature which will
eventually be superseded.

The mentality that nothing should change about the web is incomprehensible to
me. I just don't get it.

Edit: Inevitably, someone will tell me that the web is faster without JS, and
another might claim accessibility as a problem.

\- A faster web is made possible by faster devices on faster networks. Current
constraints are far less relevant when we're discussing future technology. For
now, yes page size is a problem but I absolutely wouldn't want that to shape
future technology. ISPs have the power to improve their services as required.

\- Accessibility is a standards problem, not a content type problem.
Accessibility software should be expected to adapt to new technology like
anything else. As long as we provide the tools for these platforms to succeed,
the type of content that is being served (whether it's plain text, JS, or
binary) shouldn't affect anything.

~~~
alistproducer2
I disable JSbecause, on a lot of sites, I'm only there to read words on a page
and those words come up instantly without JS and in as long as 30 seconds with
it.

Why do you think Google created AMP (which is just a fancy way of telling devs
to stop using JS for text sites)?

Look, there are plenty of site for which JS makes a huge difference - proper
web _applications_. For every one of those site there are 9 that load half a
MB of cruft so they can animate their stupid banner.

~~~
iLoch
I'm not saying text content doesn't have its place, but what I am saying is
that unless you're absolutely certain your users aren't going to be using JS
(hint: that's effectively no one) then it's just not worth your time to
accommodate those users - especially when they _optionally_ disable JS, AND
you have to degrade the experience for the rest of your users in most
practical applications. How often do you design features for 1% of your users?

~~~
kinlan
A lot of it is about performance, if you need JS to fetch the content of your
site after the SPA or Shell has loaded then you are incurring a significant
amount of overhead for something that could have been streamed from the server
and rendered as it was parsed by the browser.

~~~
iLoch
Performance will come as the need develops. Yes it's faster to render
something on the server right now, but that may not be the case in the near
future. The concept of loading something from the server is also only
accounting for a very specific use case. These days most websites will require
more data from the server after the webpage has been loaded anyway.

Server rendering simply wont make sense for some binary applications, such as
games.

~~~
robin_reala
Playstation Now exists and is server rendering for games:
[https://en.wikipedia.org/wiki/PlayStation_Now](https://en.wikipedia.org/wiki/PlayStation_Now)

------
alistproducer2
I'm a JS evangelist for sure. I love the language, but I'm not a true
believer. Believe it or not, I keep JS turn off on my mobile browser because I
enjoy instant page loads. I remember the first time a coworker asked me "but
what if they have JS turned off?" I thought "what a dinosaur. Who doesn't have
JS turned on?" Obviously I had a change of heart on the subject.

I never write JS > ECMAScript 5. Why? Because I want my apps to work in as
many places as possible and I don't feel like arrow functions are worth
breaking backwards compatibility. I know there are those who will disagree.
I'm all for pushing the web forward, but I feel like, in the process, some of
us have lost sight of what the web is ultimately about.

~~~
supster
I feel like JS is an expected part of the web just like HTML and CSS. How can
you build engaging web applications if you are not even allowed to rely on
standards like JS (e.g. if the user turns off JS)?

~~~
zeveb
> I feel like JS is an expected part of the web just like HTML and CSS. How
> can you build engaging web applications if you are not even allowed to rely
> on standards like JS (e.g. if the user turns off JS)?

The _web_ is not about 'engaging web applications'; the web is about webs of
interlinked documents. Every time you require JavaScript to display a simple
document; every time you load images with JavaScript instead of <img>; every
time you replace an <a href=> link with a JavaScript event handler; every time
you fail to even link to a page; every time you use JavaScript-loaded fonts to
display symbols: you break the web.

'Web application' is a misnomer: it should be 'browser application.' Despite
my loathing for documents (e.g. blogs, articles &c.) which require code
execution in order to be read, I don't mind browser apps where they make
sense. Google Maps makes sense: it doesn't bother me that it doesn't work in
eww, or links, or with NoScript.

Blogger doesn't make sense: there's absolutely no legitimate reason for it to
show an empty page with JavaScript turned off: Blogger is breaking the web.
imgurl's failure to show all images, and Cracked's failure to show any images,
without JavaScript makes no sense: they are breaking the web.

People who break the web should be deeply ashamed.

~~~
mynameislegion
> the web is about webs of interlinked documents

If this is true, and my browser can follow a link to a Blogger page,
displaying the intended document using universal browser features, then the
Web is not broken.

This kind of evangelism makes no sense. The whole idea that "the Web is about
documents, specifically" was shattered as soon as Javascript was added over
two decades ago. It's no longer about that idea and hasn't been for a long
time. Interlinked resources, yes, and documents became a subset of that idea
in 1995.

The desire for document-type content to display without JS stems from a
strange desire to see the technology used how it was invented in 1990. The Web
was hodge-podge of technology then, and it's even more so now. If you intend
to pick and choose what parts of the hodge-podge to use, you will find
yourself frustrated forever. And you gain no advantage by arguing "but I want
the _original_ hodge-podge to work with the type of content it was design
for!".

JS _is_ the Web just as much as HTML because all (Edit: popular) browsers
support it. As soon as that happened, compatibility with the Original Hodge-
Podge was dead, permanently. For better or worse, that is the reality.

~~~
zeveb
> If this is true, and my browser can follow a link to a Blogger page,
> displaying the intended document using universal browser features, then the
> Web is not broken.

Your second premise doesn't hold for all browsers: links cannot display
Blogger pages; Firefox with NoScript cannot display Blogger pages; the Tor
Browser with high security cannot display Blogger pages.

The Web is, fundamentally, about resources — documents — and their state, not
about behaviour.

> JS _is_ the Web just as much as HTML because all browsers support it.

No. They. Don't. eww doesn't. w3m doesn't. lynx doesn't. links doesn't. elinks
doesn't. Firefox with NoScript doesn't. The Tor Browser with high security
doesn't. _That_ is the reality.

The reality is also that allowing JavaScript exposes users to severe privacy
and security threats. Disabling JavaScript is the _only_ way to control those
threats.

Every site which requires JavaScript to function is like a serpent tempting a
user into giving up his privacy and security. _That_ is the reality.

~~~
mynameislegion
> Firefox with NoScript cannot display Blogger pages; the Tor Browser with
> high security cannot display Blogger pages.

These configurations disable universal features, so the premise holds.

> The Web is, fundamentally, about resources — documents — and their state,
> not about behaviour.

Yes, in 1990. Also, you choose to conflate "resources" with "documents".

> w3m doesn't. lynx doesn't. links doesn't. elinks doesn't

These are browsers that choose parts of the standard hodge-podge and they
suffer for it by not being able to display all pages.

_

I'm not arguing the situation is great or that you should like it. Hell, I
don't even like it. Your criticisms of JS are valid. But your expectations of
how the Web should work are _broken_ and they would have been broken 20 years
ago. Whether it's 1996 or 2016, the only way your reality could come true is
if there was an HTML-first programming style enforced universally. It's so
impractical it's barely worth mentioning, so why evangelize?

~~~
zeveb
> These configurations disable universal features, so the premise holds.

> These are browsers that choose parts of the standard hodge-podge and they
> suffer for it by not being able to display all pages.

So, the Web is not broken because all browsers which use a feature are able to
display pages which use a feature — anyone who disables that feature is
responsible for breakage due to pages using it, and anyone using a browser
which doesn't support that feature is responsible for choosing such a browser.

Your logic would justify every vendor-lock-in attempt from Apple & Microsoft;
it would support the idea that all the Internet's IE.

> But your expectations of how the Web should work are _broken_

No they most definitely are _not_. My expectations of how the Web should work
are based on mathematical truth. REST is symbolic manipulation: it's correct
in the way that only math can be.

> Whether it's 1996 or 2016, the only way your reality could come true is if
> there was an HTML-first programming style enforced universally.

Not HTML-first, _resource_ -first. Figure out what your resources are, figure
out how they are related, figure out what behaviour makes sense, then wire it
all together. Once you have all your resources (images, HTML, whatever)
working well, then feel free to wire it up with JavaScript.

HTML's power is that it is declarative, not imperative. It shares that
character with plain text: when you read my words you do not give me root
access to your brain. No-one should be forced to execute unknown, newly-served
code in order to read a document.

When you require JavaScript, you break the Web. Please don't.

~~~
mynameislegion
> Your logic would justify every vendor-lock-in attempt from Apple &
> Microsoft; it would support the idea that all the Internet's IE.

Except in this case the "vendors" are the makers of every popular browser and
the standards body governing Web technologies. Not exactly apples-to-apples.

> My expectations of how the Web should work are based on mathematical truth.
> REST is symbolic manipulation: it's correct in the way that only math can
> be.

Right, a programming style. Your 'mathematical truth' is arbitrary given
current web standards. The lack of it does not break interlinking, which, by
your own admission, is what the Web is about.

> Not HTML-first, resource-first. [...]

You didn't actually address the fact that you would need to have everyone
follow this style. You expect the Web to work in a way that can never be
enforced; that is a broken expectation. I agree, this is the way it should be
done but it's completely obvious it won't ever happen. The incentive to follow
that style is no where near enough to generate any sort of defacto standard.
So why evangelize?

------
jakub_g
I always say that URLs are the best invention since electricity and cars. Just
a few bytes of text but convey so much information, and are universally
supported by virtually all software. This is huge. Don't take it away from the
people.

~~~
CognitiveLens
URLs are not going away - like you point out, they are a reasonably good way
for software to pass around a few bytes describing a resource location. Their
usefulness for humans, particularly within a single site/web app, is less
clear - e.g. if we ignore the domain name (which would be constant across a
web app), this comment thread is described by 'item?id=11770774' \- it doesn't
mean anything, and so arguably is not worth displaying anywhere within the HN
'app'.

~~~
wwweston
It absolutely means something: it's an article/thread ID number.

Now, that's not as transparent to grok or as high resolution as something like
the date and title path schema that's become popular, but it's still something
that _some_ users will recognize and possibly even know how to get some
utility out of -- if nothing else, by copying the URL and pasting it somewhere
for sharing or use or storage.

And that's the _worst_ case scenario for URL utility. If we get into a
recognizable scheme like the date-title path, there's a lot more apparent
information and it can often be transparent how changing the URL can be an
interface.

We've had an interface that allows users who don't grok URLs to ignore them OR
learn by observation and experimentation how they work -- and allows users who
are already there to easily note and access them for two decades.

This trend towards leaving them out doesn't allow that progression or utility.

~~~
CognitiveLens
The argument is about whether they mean anything to _people_, though, as part
of the user interface.

URLs are hugely meaningful to software, and the ability to share them is
critical, but that's independent of whether they are shown at the top of the
window.

Semantic URLs are helpful, but they're an awkward tool for changing the
interface as you describe it. If a web application is relying _at all_ on
people moving URL path elements around to access the content they want, it has
already lost.

I think URLs are fundamental to the web, but not fundamental to the user
interface, which is an important distinction - I don't mind at all that in my
native mobile and desktop application, there is no unique view identifier
displayed at the top of the application window for every view available, and I
think a mature web can equally hide, but not eliminate, that identifier.

------
CognitiveLens
I wanted to like this article, but it's not helpful to argue against
assertions by making evidence-free counter-assertions.

> The end result may feel very “app-like” if you’re using an approved browser,
> but throwing the users of other web browsers under the bus is the very
> antithesis of what makes the web great.

1\. The Polymer demo app is a _demo_ app - it's a tech preview, not a
recommendation to drop support for any other way of delivering web content.
2\. Who decided "what makes the web great"? One of the things that makes the
web great is that people can build powerful app-like experiences using
standardized tools. Some browsers don't (yet) support those standards, and
some users opt-out of allowing these standard tools to run (Javascript), but
that's not the fault of the web, is it? Is the argument that the lowest common
denominator must be served before spending any time and effort on making
something more advanced? Count me 'regressive', then.

> The inability to pinch-zoom in native apps is a bug

I disagree with this assertion, although I acknowledge that it does have
accessibility costs. It's at best naive and at worst disingenuous to claim
that disabling pinch-zoom on the web is "slavishly copy[ing] whatever native
is doing" \- rather, some web apps are choosing to make similar tradeoffs as
native apps.

> To declare that _all_ users of _all_ websites will be confused by seeing a
> URL is so presumptuous and arrogant that it beggars belief.

This is laughably hyperbolic. The linked Chrome issue simply disables an
automatic prompt on websites that are configured in a very specific way - it
isn't making a universal statement about URLs or whether or not they confuse
users. To declare that the Chrome issue does otherwise is so presumptuous and
arrogant that it beggars belief.

The final complaint that Lighthouse (a Google application) has a different
standard for "best practices" than the author doesn't actually help his
argument. Lighthouse isn't _the_ reference point, it's _a_ reference point,
and one thing that web developers learn very early in their careers is that
when it comes to the web, there is no one right way of doing anything.

------
carsongross
Eventually the pendulum will swing back. The web app model beat out native
apps (then called client-server apps) for very good reasons (no install, REST-
fulness, simplicity, transparent linkability) but we've become blind to them
through long exposure.

As surely as Water will wet us, as surely as Fire will burn,

the gods of the HTTP Headers, with terror and slaughter return.

~~~
Freak_NL
Amen I guess?

I expect that for a lot of apps-that-really-should-be-websites their owners
will realize that having to (pay to) maintain both their Android and IOS apps,
and the 'normal' website is a costly affair, and that maintaining one
responsive website is a lot more efficient.

------
potch
"Progressive Web Apps" is a Google brand. It's made of some good best
practices and great technologies, but they reserve the right to re-define it
and change the rewards around it however they choose. Install buttons are the
carrot, and search rankings are the stick. Will non PWA-compliant but
otherwise fast, well-made mobile web sites rank as highly as PWAs?

~~~
lucasmullens
Google isn't trying to make every website a PWA. Why would they punish all
non-PWAs?

~~~
kinlan
The current way that we see the banner is that it is the equivalent of an App
install banner for web sites that meet the rough idea of what a Progressive
Web App is and would be something that you would want to install or act like
an installed app on the system.

The thought at the time of the change wrt to the fullscreen or standalone is
that to get that app like treatment in the OS you would expect it to launch as
an app would on the system (sans-url bar).

Note: we are also thinking of ways to get the URL bar back to the user when it
is launched standalone or in fullscreen. It's a complex UX problem but we want
to get the best of both worlds.

------
emodendroket
You can't please everyone, I guess. Who but the largest organizations has the
resources to make a fully-responsive SPA that also has non-JS fallbacks for
everything?

------
kinlan
I think Jeremy's post resonates with a lot of our team (Chrome, DevRel etc),
we want all experiences to be responsive, accessible, content visible without
JS being required and most of all solid design that takes advantage of good
URLs.

The App Shell model has worked well for a first set of experiences that have
shipped and I don't think that it is inherently mobile only, many sites work
well on desktop, instead I think I think a lot of it is a matter of resourcing
and staffing. After working with a number of developers who are building
Progressive Web Apps, one thing that I have noticed is that many of the teams
building sites are still split between a "mobile web team" and a "desktop web
team" and that is one of the reasons why I think we are seeing some of the
sites being accessible on mobile first.

The place we want to get to is one experience that works well for all users in
all browsers.

Specifically wrt to Banner prompting our thoughts around this have always been
consistent, when an site meets the criteria of something that could be
experienced as an app the user would see a prompt to "install" it (after
meeting some engagement criteria). The thought was that prompting is a
powerful feature and one we don't want to see abused and thus the criteria is
quite strict and our expectation is that the site when launched should launch
like an app would on the system. The user can still add to homescreen, we just
reserved the prompt.

Some interesting bugs for people to follow wrt to Propmting.

* [https://bugs.chromium.org/p/chromium/issues/list?q=component...](https://bugs.chromium.org/p/chromium/issues/list?q=component:UI%3EBrowser%3EAppShortcuts) \- prompting and add to homescreen bugs

* [https://bugs.chromium.org/p/chromium/issues/detail?id=604390](https://bugs.chromium.org/p/chromium/issues/detail?id=604390) \- Minimal UI mode for access to URL

* [https://bugs.chromium.org/p/chromium/issues/detail?id=601624](https://bugs.chromium.org/p/chromium/issues/detail?id=601624) \- Discussion on criteria for prompting

* [https://bugs.chromium.org/p/chromium/issues/detail?id=601337](https://bugs.chromium.org/p/chromium/issues/detail?id=601337) \- Mandating Offline to get banner.

------
cwisecarver
This all boils down to compatibility. You can make your webpage or webapp work
on a majority of devices by rendering most of it on the server and delivering
it as html with javascript handling the bits that can't be handled by
html/css.

Or you can make your blog, which is essentially text on a webpage, that is
rendered entirely by javascript. You can have your css download as javascript
and be processed and rendered by the browser ... but why? Because they're new
toys?

I think our infatuation with javascript has led us to the "when you have a
hammer everything looks like a nail" situation.

Javascript is great but most developers I interact with aren't writing
javascript. They're writing jQuery or Ember or Angular. They don't understand
javascript as a language, they understand the flavor of javascript their
library of choice gives them. They don't think about the fact that sorting a
table in a browser will be a problem until it hits production, with 10,000
rows, and users without the top-of-the-line hardware are screaming.

It reminds me of the Windows vs Mac debate, which is really just a debate over
control. Windows didn't control the hardware it was installed on; MS couldn't
be sure everything would work so there were layers upon layers of
compatibility solutions. Apple controls (most) of it's hardware so it has a
smaller playing field and it knows what the next commit to it's repo will do
to the majority of it's users' experiences.

Javascript is the same way. As web developers, you (should) know what your
servers can do. You can plan for capacity. Offloading everything to the users'
browsers is just evil. Think about the kid with his $200 hand-me-down
chromebook who really wants to learn about programming or the guy in Africa
trying to visit your site over GPRS on his mobile phone. They shouldn't need
the newest version of chrome with ES6 to view a blog entry.

There are times where a SAP is the right choice for the user. We just have to
realize everything isn't a nail.

[edit: english]

