
If we stand still, we go backwards - callum85
https://jakearchibald.com/2015/if-we-stand-still-we-go-backwards/
======
steego
Calling for a moratorium sounds very dramatic, but I suspect PPK wanted to use
dramatic language to make the point that we're not putting enough thought and
exercising enough caution about what we're introducing to the web. These are
not free experimental features we can add willy-nilly that we can easily
remove when we don't like them anymore. They have the potential to introduce
an incredible amount of globally shared technical debt if they're bad enough.

Between standing still, and desperately adding features to make the web
competitive with native platforms, I'm inclined to slow it down. I don't think
the web is seriously threatened by native platforms. Even when we did
experience feature freezing between 2001-2007, the web remained king despite
attacks from Flash.

I don't think the web is under real threat from mobile native platforms. It's
nothing that performance tuning and Moore's law can't address in time.

~~~
technojunkie
"I don't think the web is under real threat from mobile native platforms."

The main argument against this statement is home screen icons. iOS and Android
home screens, among others, do not feature, have not featured, and will not
for months or possibly years, feature mobile web icons to launch websites in
the browser of choice. Most or every icon on these home screens are native
apps because mobile websites do not easily allow or make obvious that it's
possible to have an app icon on the home screen. Thus, native will always win
this battle.

When the day comes that it might be easier to see a mixture of native and web
apps on the home screen, unless mobile web is faster than it currently is
(meaning updating changing best practices, using excellent APIs like SW and
designing for offline first access), users will STILL choose native over web
when half or more than half the time they do exactly the same thing.

Native is here to stay for years to come unless the mobile web can offer a
compelling reason to switch to browser based layouts. I'm cheering for the web
to provide a better content experience but we're still a long way off and can
expect web based layouts to be wrapped with native code and wrappers. Maybe
web isn't the place for everything but a universal bytecode for everything is
a dream that could be reality as long as progress is made.

~~~
swsieber
I for one will not choose native apps (not as long as they have a half decent
app). I choose my banking website over their app anyday. And the same with
Facebook. I think for me though, part of the aversion is how invasive apps can
be.

~~~
technojunkie
I am not patient enough to wait for poorly developed web pages to load when a
native app offers the same functionality at a fraction of the load time. My
bank's native app is the only way I can deposit my checks and the web site
does not offer this functionality. Thus, it's imperative that I use the native
app today. If this changes tomorrow or in the future, I'll be giving it
another look in the browser but right now, the bank app I use has similar and
better functionality natively than in the browser.

Same with FB, it's not tuned to perform well on the browser and takes longer
to load. I hate the FB app for privacy reason and would MUCH rather use the
browser FB site but it doesn't compare most of the time.

------
vezzy-fnord
The author's examples of inflated user expectations are unconvincing.
Transferring data across the globe is the whole point of wide area networking,
far predating WWW. Making online purchases has been possible since the early
days of the web.

Furthermore, the author's definition of "native" is revisionist, placing it at
a highly recent time frame, and categorizing it by features that are
semantically disparate.

So-called "progressive loading" and no installation process have been traits
of native applications for a long time. In fact, at a primal level, the
process of installing a program boils down to a copy operation.

Notice how in the last paragraph, the examples of the web's feature richness
are all intrinsically limited browser reimplementations of native interfaces
that exist in parallel with the host OS.

~~~
cromwellian
They have? I've been using computers since the mid 80s, and unless you think
loading apps from floppy disk, datasette, or cartridge, counts as "install
less", this is a disingenuous rebuttal.

The Web brought with it portable executable content that ran without escalated
privileges or install, and this did not exist before in any widescale
deployment accessible by endusers.

Prior art is General Magic Telescript and SafeTcl, or perhaps PostScript or
NeWS if you want to count those as wide deployment.

The difference between the Web and Install models, is that installation
doesn't scale to the long tail because it places shit work on the user to
manage limited resources (screen real estate, disk space). The Browser Cache
doesn't impose this cognitive burden. There is no cost of cleanup imposed on
you by clicking a web link. The back button takes care of it.

That's why it's "surfing" because it is effortless and imposes no long term
transaction cost. To try out a web site, you click it, if it sucks, no harm no
foul.

Native apps are completely different. To check and see if you'll like an app,
you have to install it. It consumes permanent resources. If you then decide
you don't like it, you have to permanently uninstall it. Many people are so
burdened by this step, they leave unused unliked apps on their device. Then
one day, they run out of space when trying to take a photo or download a new
app and find that they must then go clean up their memory and delete a bunch
of stuff. An incredibly shitty experience that the Web Browser solved ages
ago.

Android and iOS apps should work more like Java Applets or Flash. You should
be able to run them without install, and then only if you like them a lot and
run them many times, should you optionally pin them from being purged.

------
dmschulman
"Just because it's there, doesn't mean you must learn it and use it"

You're correct! Except that this is not the way things work in the
professional world, and by refusing to learn or use a new technique or library
you're stunting your personal development as a tech professional.

ppk's argument boils down to progress outpacing need. Businesses desire the
bleeding edge in their online-facing products and if you want to be attractive
as talent you need to keep up with the latest development trends. This can
lead to frustration, barely getting the time to build stuff with your new
skills before the next big framework comes along. The latest and greatest is
hip but might not be entirely necessary. This is where we need to focus our
attention and strike a balance.

~~~
technojunkie
"Businesses desire the bleeding edge in their online-facing products"

What kind of businesses? In multiple enterprises I've worked with/for, they
move at a snail's pace and are resistant to change. I feel like most larger
enterprises are at this snail's pace, whether it's b/c of outdated security
practices they can't let go of, control issues, IT incompetence, or
complacency in the way things are.

The businesses which might be more forward thinking are agencies and some
small businesses but I think these are less common. Why do you think it took
years to let go of IE6, then IE7, and now IE8 and IE9 in the enterprise world?

------
hellbanner
"Hello world" is doable in 3 lines instead of 5, granted. But for more
complicated development.. [http://www.allenpike.com/2015/javascript-framework-
fatigue/](http://www.allenpike.com/2015/javascript-framework-fatigue/)

Question: is there ANY environment or language that has fantastic support and
is continually improving? Any _open source_ one?

------
bcg1
I agree with all of the points in this article. Even if you believe that PPK
is 100% right about the "problem", I truly can't grok the notion that a
moratorium would somehow "solve" anything. From my observation, when standards
are actually under development and look like they will have first class
support in the browser, proliferation of stopgap solutions is much lower
because people would rather wait for "standard" support of whatever feature
they're trying to implement. Also I think that aside from IE, browsers do a
good job of getting standard features done, which is sort of amazing
considering they don't have the "benefit" of top-down bureaucratic governance
like the "native" platforms. As a notable exception WebRTC is a bit of a
clusterfog it seems, but I'm sure that will get worked through without too
much ado.

~~~
mattmanser
How would you know?

We've only had two modes of standards development in recent history. Bugger
all (the age of IE6/Firefox/IE7) and constant churn (pretty much since the
iPhone/Chrome was released).

------
amelius
> "Hello world" is simpler now than it has ever been.

Yes, it is simpler for ordinary people. For developers, however, the web is
getting more and more convoluted.

~~~
wstrange
Agreed. There is nothing wrong with the growing richness of the underlying web
platform (the gist of the article). GPS, 3D graphics and what not all enhance
the user experience.

The challenge is that languages, frameworks, and tooling are are not shielding
the developer from the growing complexity.

The level of abstraction is rather poor , so that for any any non trivial web
application, you quickly _do_ need to know the gory details of CSS, layouts,
web components, shadow vs. lite DOM, and so on.

I agree with the premise of the article (we can't stop the forward progress of
the web ), but we desperately need better tools.

------
angrybits
Who cares how many lines it takes to do Hello World? Honestly, that isn't a
benchmark for any meaningful thing.

~~~
jaffathecake
Good job it's only a very small bit of the article, then.

------
stephengillie
The connection kept resetting for me, so here is the Google Cache link:
[http://webcache.googleusercontent.com/search?q=cache:f-pnPOu...](http://webcache.googleusercontent.com/search?q=cache:f-pnPOuBD-
wJ:https://jakearchibald.com/2015/if-we-stand-still-we-go-
backwards/+&cd=1&hl=en&ct=clnk&gl=us)

\---

I don't web develop often. As a user, mobile web is usually more usable than a
native app - not in terms of whether or not it works, but in terms of
usability, flow of actions, and predictability. Cut, copy, and paste work in
the browser but rarely in native apps. Other little things too, items too
little for a project architect to notice or a punch list to pick up.

The other half of what killed Blackberry was Microsoft Activesync.
Blackberry's email service required you have set up their Blackberry
Enterprise Server (or their lower-performing cloud-hosted Blackberry Internet
Service) and connected this to your email account. BES had an "agent": a
service that would log into your email account every 30 seconds, check for new
email, and then forward this to your Blackberry over the Blackberry network
(which is why you had to pay the $10 "Blackberry Fee"). Activesync (I think)
used Exchange mail rules to do the same thing, and the iPhone mail client
could use Activesync.

It was that "one-two punch" that took out Blackberry:

    
    
      * iPhones were cool. Androids were cheap.
      * Activesync comes with Exchange, no other server setup necessary. 
      * Works with normal carrier service; no $10 Blackberry fee.

~~~
klagermkii
I think you give too much credit to ActiveSync. That was available on Windows
Mobile and I'd say the heyday of that was well before the era of Blackberry
domination.

From my own usage of ActiveSync I remember the data networks of the era were
not great with push protocols, at least not compared to the almost magic
instantaneousness of Blackberry email and their custom solution.

~~~
stephengillie
Activesync was good enough that a lot of smaller customers could stop paying
the extra Blackberry fee to their carrier, the extra Blackberry fee to their
cloud host (OR the cost of maintaining an extra server in their colo), and
stop carrying their 2nd phone.

------
jaffathecake
Something like "If the web stops, it goes backwards" or "The web must develop
to survive" would be a more contextual title here.

~~~
detaro
HN rules highly frown upon submitting links with changed titles.

~~~
jaffathecake
The title was changed before you made your comment btw. Current title is fine.

------
barnacs
"Native apps are looking to gain the web's advantages too [...] If we stop, we
lose."

Who is "we" and why are they competing against some implied "them"? When are
we going to accept the shortcomings of both the web and native applications
and figure out a solution together to benefit humankind?

------
ewzimm
I appreciate that this comes across perfectly formatted for w3m. Just shows
that we can push for advanced features while maintaining compatibility for the
simplest experiences.

Some of the frustration for new features comes when developers ignore
compatibility, but that's not a necessary part of pushing the web forward,
just an indication of sloppiness.

Every new feature brings new challenges. The solution is not to solve
challenges by stopping progress but rather to respond to challenges as they
come. This means more work, but that's okay. There are more people to do the
work every day.

------
draven
"Also, world's first web site[1] still works in modern browsers".

... and half the links on it are broken. That's one of the things I don't like
on the web, content slowly disappear, links are unidirectional, etc.

[1]
[http://info.cern.ch/hypertext/WWW/TheProject.html](http://info.cern.ch/hypertext/WWW/TheProject.html)

------
spectrum1234
Exactly. Users control the internet. Almost everyone has this backwards.

