
Stop pushing the web forward - mmahemoff
http://www.quirksmode.org/blog/archives/2015/07/stop_pushing_th.html
======
rgbrenner
_We need a break. We need an opportunity to learn to the features we already
have responsibly — without tools! Also, we need the time for a fundamental
conversation about where we want to push the web forward to._

How about this.. YOU take a break. Stop trying to keep up with every little
new thing that comes out. Wait a while.

And you'll get exactly what you want.

The tools that it turns out were a bad idea will die. And those that are good
will thrive.

And you'll get more time to learn the actually useful ones... and you'll get
to learn from the mistakes others made early on.

Yes, you'll be a bit behind.. but you're apparently already ok with that
anyway.

~~~
pbhjpbhj
Do you know PPK and his work? He's been at the cutting edge of web-standards
and implementations for at least 12 years if my memory serves me correctly.

>And you'll get exactly what you want. //

If he wants to avoid the web being badly negatively effected by short term
views of current browser companies and standards bodies then he won't get what
he wants by sticking his head in the sand and ignoring the direction he sees
things going.

If this were the writing of a small time web-dev (like myself) then I think
your comment would work; but I'm assuming PPK is coming from a position of
experience that's given him an almost unique overview of the direction of
browser and standards development vs. the historic "feel" and integrity of the
web.

PPK is doing the equivalent of saying "let's stop and ask for directions [on
our car journey]" and you're saying "no, let's just keep driving I'm sure
we'll get to where we want to go".

He's up against it as, to my mind, cautious development doesn't serve the
needs of corporations and so won't happen.

>"We’re pushing the web forward to emulate native more and more, but we can’t
out-native native." (OP) //

I find it funny that web pages are trying to be native apps and many mobile
apps are shipping when they're ostensibly just web pages.

tl;dr I think the OP has more to say, and that it's more important, than
you're giving credit for.

~~~
tedunangst
> I find it funny that web pages are trying to be native apps and many mobile
> apps are shipping when they're ostensibly just web pages.

Which provides some insight into what's missing from the web. It's almost good
enough for most companies. They just need a little something extra so that
they can "own the experience." But soon the browsers will catch up and then
websites will be able to own your experience, too.

~~~
nitrogen
What if I don't want corporations to own my experiences? An information-driven
web with a document model is robust and can work with many different user
agents. An experience-driven web with an application model is very fragile and
will only be available to sighted, hearing, Mac-using people running a big 4
browser.

~~~
kbenson
Who needs flash when we can have 15 competing application frameworks for the
web that all just abuse the canvas as their medium, so we aren't even
authoring HTML/CSS anymore?

~~~
sanderjd
Honest question: is abusing canvas really becoming prevalent? The only web app
I've seen doing this is flipboard.

~~~
kbenson
Prevalent? I don't know. I do think it's just a matter of time before some
companies leverage this by providing a super simple web page developer tool a
la Frontpage Extensions.

Photography studio webpage that just wants a carousel and music playing?
Check.

Small companies that freak out about people stealing their inventory list?
Check.

Vendor lock in for the poor souls that fall for this? _CHECK_.

~~~
sanderjd
Hmmm, maybe I'm naive, but I really don't see anything to suggest that things
are headed this direction.

------
ixtli
> But why do web developers want navigation transitions? In order to emulate
> native apps, of course.

If we're doing unpopular opinion time, I think this is the real issue that no
one wants to talk about. I'm all for whatever feature development the
community can standardize. Apple, google, mozilla, and etc. all have smart
people working for them and when they cooperate things seem to work out fine.
The problem is trying to achieve the feel of native applications in a _non_
native application. Browsers should do one thing well, but that one thing has
no real business being duplication of mathematica, quake, or visual studio.

It's always interesting to see a Show HN where someone cleverly gets an
approximation of one or another of those things running in the browser, but
come on. Making the browser the operating system is simply going to push the
same old incompatibility problems into the browser. It's not going to solve
them.

~~~
rtpg
I'm sorry but how would making browsers the operating system cause the
incompatability problems to reappear? I think this is massively ignoring the
realities:

\- there's almost no native-feeling cross-platform UI library for native apps
at the moment

\- There's a standard for most things happening in a browser, which means that
things look pixel-perfectly the same on a huge amount of browsers. Differences
among current browsers are more among performance and experimental features

So currently, if Google, Apple, and MSFT decided to jointly ban all native
apps and only have a web browser on their smartphones, we would have a much
better compatability situation, since so much functionality has been
standardised on that end, and _actually respected_.

The browser is basically what the JVM tried to be, a write once work anywhere
solution that is pretty well sandboxed. It's miles better than pretty much
every other cross-platform piece of tooling in existence.

~~~
pikzen
>there's almost no native-feeling cross-platform UI library for native apps at
the moment

Xamarin.Forms is the closest I can think of. Qt too, kind of.

>The browser is basically what the JVM tried to be, a write once work anywhere
solution that is pretty well sandboxed. It's miles better than pretty much
every other cross-platform piece of tooling in existence.

It's true, the browser succeeded as a working everywhere JVM equivalent.

It also succeeded at reimplementing half of your OS features, being another
massive source of security issues, being inefficient with resources (chrome
memory usage lol), having piss poor perfomance and locking everything to
Javascript. Compiling to Javascript is not a solution. A proper bytecode is.
Which we may have with WebAssembly as soon as it's implemented and the
standard respected by browser builders (which will probably be around 2040).
Until Google decides to add a new WA feature that's incompatible with other
browsers because that's what Google does. Let's not get started on the fact
that HTML is a terrible language for UIs and that any Javascript based
solution is not a solution at all (i.e. React is still crap, as is Meteor and
javascript.framework.of.the.day.js).

The web as an application delivery medium is a failed experiment, patched up
on all sides and held together with 40MB of polyfills on every page.

> if Google, Apple, and MSFT decided to jointly ban all native apps and only
> have a web browser on their smartphones, we would have a much better
> compatability situation, since so much functionality has been standardised
> on that end, and _actually respected_.

1\. We've been hoping to get at least TWO browser vendors to fully collaborate
for the last 20 years and it has not happened. It won't happen.

2\. Performance will still be crap.

3\. I'd rather not get locked to Google's piss poor record of updating the
stock Android browser. In fact, I'd rather not get locked to Google's piss
poor software at all, thank you very much. The same argument applies to Apple
and Microsoft. Safari is awful, and so is IE/Edge.

~~~
apalmer
I get where your coming from, and agree with a lot of what you say.

BUT, Fundamentally...

>The web as an application delivery medium is a failed experiment, patched up
on all sides and held together with 40MB of polyfills on every page.

Is just not a true statement. Or rather, the web sucks, but it is the only
cross platform UI experiment that has 'worked' on any significant level.

~~~
ForHackernews
> the only cross platform UI experiment that has 'worked' on any significant
> level.

Users do not care about cross-platform compatibility, at all. They only care
that it works on _their_ platform. As developers, we should be cheering for a
diversity of widely-popular, mutually-incompatible platforms because there
will be more work for developers to port the iOS version to Android to
Windows, etc.

The only people who should be upset about cross-platform compatibility issues
are budget-conscious managers and unfortunate OSS devs.

~~~
MacsHeadroom
>As developers, we should be cheering for a diversity of widely-popular,
mutually-incompatible platforms because there will be more work for developers
to port the iOS version to Android to Windows, etc.

This is like saying "As construction workers we should be cheering for natural
disasters, because there will be more work for construction workers to rebuild
destroyed cities."

Job security is great- but at what cost? I'd rather see developers making
completely new things than wasting time porting from one native platform to
another.

~~~
yellowapple
And honestly, whether as a construction worker or a programmer, I, too, would
rather be building new things than rebuilding the same goddamn thing over and
over again.

------
cwyers
I think this is the key:

> The moratorium would hit Chrome much harder than it would the other
> browsers, since it’s Google that is proposing most of the new features
> nowadays. That may not be entirely fair, but it’s an unavoidable consequence
> of Chrome’s current position as the top browser — not only in market share,
> but also in supported features. Also, the fact that Google’s documentation
> ranges from lousy to non-existent doesn’t help its case.

I think the title and a lot of the rhetoric is misleading, really. It's not so
much "stop pushing the web forward" as it is "stop letting Google decide where
forward is and leaving everyone else to either ratify it or be irrelevant."
And, uh, good luck with that. I mean it. I would love to see that happen, but
I don't see how to get there.

~~~
aquilaFiera
I wouldn't categorize Google as the leader anymore. Mozilla and Microsoft have
caught up and are as much leading the charge as Google is. Four years ago I
would have agreed but four years ago we needed Google to push the browser
forward.

~~~
huskyr
The stats seem to disagree (1): Chrome has risen from a global usage share of
20% in 2011 to almost 50% today. Compare that to Firefox (2011: 28%, now: 16%)
and IE (2011: 44%, now: 18%).

(1): [http://gs.statcounter.com/#browser-ww-
monthly-201106-201506](http://gs.statcounter.com/#browser-ww-
monthly-201106-201506)

~~~
glandium
I'm pretty sure he's talking about W3C/WHATWG activity, not market share.

------
anp
I've seen this sentiment a few times: "don't try to replicate native apps in
the browser." Which makes sense from the standpoint that the browser is just
getting ridiculous, like a mini-OS unto itself.

However, web apps also allow organizations to write once for many platforms in
a much more seamless way than most cross-platform native toolkits I've seen.
It's the same reason that desktop Java was in vogue for a little while: you
only have to write one UI, and you can run it from a HTTP connection with
almost no local permissions. Of course, this was (and still is) a security
nightmare, but browsers now do a pretty good job of sandboxing individual code
blobs, and also do a pretty good job of abstracting away the native UI. Web
apps also provide low or zero installation overhead (low friction to getting a
user onboarded/working/monetized/whatever).

It would be nice to see some progressive enhancement folks address how to
resolve these pain points on the native side, rather than just saying web
shouldn't be like native.

~~~
adrusi
The cross platform experience will never match the native experience. Think
about on the desktop. The only cross platform apps that behave natively on
Mac, Windows, GNOME (and derivatives) and KDE are apps tha have completely
separate front-ends for every platform. Firefox is an ok example of this,
although it in a way forms its own platform rather than integrating with its
host, still it pulls it off better than other cross-platform apps. The
Transmission bittorrent client is perhaps a better example, it has at least 4
mature front ends: gtk, qt, cli and os x. This is only feasible for a little
free software project like Transmission because its UI is fairly simple, it
has a list of torrents, a settings dialog and a properties panel.

Most apps that try to be cross platform just use a UI toolkit that acts as a
cross platform compatability layer. Qt, GTK, Swing, WxWidgets and Tk all fit
the bill. The result is that the app doesn't look good or integrate especially
deeply into any platform, except sometimes with the platform the the
developers personally use.

There are few exceptions to this rule. One is Sublime Text 2+ which is built
on Qt. Without any customization, its theme looks OK, but doesn't match the
design language of any platform, and its integration with its host platform is
non-existant, everything happens within the sublime text window (no
notifications or system tray/menubar widgets, no quick-view previews in Finder
or Nautilus, etc). It's possible to improve integration by intstalling a
custom theme which lets the user override a lot of the UI design, including
the margins and padding, and plugins are written in python and can access a
lot of host platform features.

If you want a native experience, you have to write a native app. You can share
your business logic by linking to the same C++ code or in the future maybe by
using react native and sharing the same non-view code. But your UI-layer has
to be tailored specifically to the host platform in order to look good.

~~~
marknutter
Facebook.com and Hacker News are cross platform apps, and they work amazingly
well.

~~~
tracker1
Of course Facebook.com has been removing functionality from their mobile
website for some time. At this point when you post a link from mobile it
doesn't even add the thumbnails anymore. I know it's to drive people to use
the native apps (so they get much more tracking information, and run your
battery down faster). But the affect is just pushing me away.

------
skwosh
As a corollary I'd like to say: stop pushing JavaScript forward. There seems
to be a lot of focus on providing syntactic sugar for things that already
exist (like classes, decorators, etc) at the expense of flexibility and
composability (executable class bodies, @foo vs normal function application,
etc).

What JavaScript needs much more IMO is a (better) stdlib, with more datatypes
and procedures than currently available (including big numbers, the various
flavours of trees, better support for equality and comparison, etc).

~~~
bhousel
>What JavaScript needs much more IMO is a (better) stdlib, with more datatypes
and procedures than currently available (including big numbers, the various
flavours of trees, etc).

Isn't that "pushing JavaScript forward?"

~~~
apalmer
Agreed. However I think to build on his argument, we should push JavaScript
forward in a targeted fashion, based on its intended purpose.

Level 1: There are known huge missing chunks of JavaScript that should be
resolved as they severely limit the power of javascript as a development
platform which lives in a network application.

For instance modules, promises, etc...

Level 2: There are known huge missing functionality which are missing which
are well known elements of a sane UI framework which should be implemented
because bottom line javascript is a UI scripting language.

For instance properties and some kind of observable mechanism.

Level 3: IS all the highly subjective and often syntatic sugar intended to
make javascript work more like other programming languages like C# or Python.

For instance classes,. arrow functions, generators, let statements...

Generally the problem is the focus seems to be completely skipping Level 2, to
get to Level 3.

~~~
wging
This is being done! Level 3 is being done, but level 2 is not being skipped.

Modules: [https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Statements/import)

Promises: [https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Global_Objects/Promise)

Data structures: [https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Global_Objects/WeakSet)

Obervable mechanism: [https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Global_Objects/Object/observe)

~~~
apalmer
Yes thats the point really... Observable are scheduled for ES2016, which
satisfies a clear unamibigous and relatively not controversial 'need' is
coming out in 2016.

Meanwhile arrow functions, let vs var, generators, etc etc etc are coming out
in 2015. Why?

Its not skipped as in 'its not on the roadmap', its skipped like 'lets leave
it for now and do something else'. Its skipped over to add a bunch of shiny
bells and whistles and syntactic sugar. You shouldnt put in the leather seats
before the steering wheel.

------
robbrown451
"Native apps will always be much better at native than a browser. Instead, we
should focus on the web’s strengths: simplicity, URLs and reach."

For me, the web's main strength is that you have to write your application
only once. I don't have to think about redesigning the UI because "that's not
the iOS way" or "that's not the Android way." I don't have switch between
different languages and write the same damn thing one more time. I don't have
to hire a whole team to have an idea see the light of day and be accessible to
the great majority of people. And if my idea is a little idea, I don't have to
struggle so much to get people to check it out, given that installing an app
is a much bigger barrier than clicking a link.

I understand that if I want to be on the bleeding edge, and I want it to be
optimal whether it runs on a phone, a tablet, or a computer-proper, browser
dev can be challenging. But I don't always have to be on the bleeding edge.

Still, it's nice to know that browsers are becoming more and more capable, so
there isn't quite as huge a chasm between native apps and something that runs
in a browser. That's an artificial distinction.

~~~
bcheung
Agreed. I for one do not want to be forced to develop on 3 platforms just to
provide a decent user experience. Take all that effort and focus it in one
place to create a truly great experience.

------
cognivore
"However, web apps also allow organizations to write once for many platforms
in a much more seamless way than most cross-platform native toolkits I've
seen."

Does it? I used to think that. Until every medium-complexity or worse web
project I've worked on took forever as we went through all the different
browsers and OS's and now mobile and tablets and responsive and OMG just give
me a decent native app tool now please.

Browsers absolutely suck at UI beyond their original intended domain.

~~~
dikaiosune
Was this in reply to my top-level comment? Looks like this ended up a sibling
instead.

In reply to your comment:

Perhaps, and I lack the experience and evidence to contradict you. I work solo
on small to mid size projects that are mostly back-end. But I am fairly
confident that with the large number of mid+ size web app projects we would be
seeing a migration back to more native apps if the overhead is actually
greater than maintaining multiple native apps.

It's not like every company in the world is incapable of independently
assessing their needs. And bandwagons will form when independently-minded
companies change their processes. So why aren't we seeing a mass exodus from
complex web apps? And why are many orgs using native wrappers around these
supposedly terrible web apps to produce a pseudo-native app?

EDIT: Also, how would you address how much easier it is to try out a web app
without having to install it vs. finding, downloading, installing and running
a native/mobile app?

~~~
dkersten
The company I work for has a web app. Has had for years, yet have rebuilt the
exact same functionality a further three times as native apps for iOS, Android
and Windows Mobile.

Presumably the overhead of maintaining multiple native apps (on top of the
existing web app) is still cheaper for them than making the web app work for
mobile.

As a further anecdote, I personally don't know many people who like using web
apps on their phones. I certainly don't. On my phone I use my browser to read
HN and other articles and native apps for _everything_ else. Most people I
know are the same.

Re: your edit - finding is no different than your web app. Downloading, your
web app downloads too only everytime I load it instead of once. When
installing from one of the app stores, I've never found downloading or
installing any harder than clicking a button. Installing, sure, but only
because the term sounds like a crazy heavyweight thing to us. The process (for
mobile apps, not desktop) is generally a single click that you do once.

The thing that web wins at here is that it eliminates even these few clicks,
and since you don't "install" it, people feel safer and happier.

------
altcognito
ATM, The two top articles (Why Docker isn't Successful in Production) and this
one are both cries for the world to slow down. It's not going to and everyone
ought to strap in. If change is called for, it will be adopted. If not, it
won't. Some technologies were rejected simply because they came about at the
wrong time. Some technologies that are adopted now will later be deprecated as
better solutions are found. Change is constant.

The article is premised on a distinction between "apps" and "the web". No such
real distinction exists. The distinction is in the form factor and physical
interaction. The software distribution model that mobile apps utilize was
rejected outright in the 90's by both users and software companies. I don't
want to worry about what % of users have a particular version of an app, what
particular version of an OS a user is running (Android is not alone here),
have my apps approved and taxed by a third party, or whether that app is
properly discoverable. This is even before we get to the fact that developing
for multiple platforms in the mobile world involves completely different
skillsets and tools and therefore additional costs.

Furthermore, "performance" is a secondary (albeit important) concern. There is
no computing law that prevents the web from achieving reasonable parity with
native apps. Funtionality and usability will almost always trump performance.

The browser is a great VM, may the best features win.

~~~
chx
> If change is called for, it will be adopted.

Please elaborate. This does not seem to be true but it's too short to fully
understand.

~~~
altcognito
Well, if the market sees a technology as solving a particular problem it will
adopt it. As you suggest, this is more complicated than nine words can cover.
It may only be temporary -- like flash video. Up until flash video took over,
the existing solution were plugins like RealAudio/Video. If mobile application
development solve a pressing need better than other solutions, ideally it will
be adopted. Of course, technical merits are not the only issues at play here.
Marketing, costs both hidden and direct are all absolutely factors determining
whether change will occur.

~~~
chx
> Well, if the market sees a technology as solving a particular problem it
> will adopt it.

Bollocks. The "market" is not a sentient, rational entity. There are many more
factors that go into market adoption.

~~~
altcognito
I hear that people have written entire books on the subject. Do you have a
point you were trying to make other than "markets are not sentient and
rational"?

------
awalGarg
PPK raises very valid points. I further want to add that you do not need
flying boxes, fading tool-tips and what not to make your app look cool or even
beautiful. In-fact it is pretty silly to try to make websites look very
beautiful and cool because you can _never_ cater to the taste of every single
user. Your flying boxes which look cool to one person might look ugly and
distractive to another one. Do we not have enough flame wars on whether iOS
looks prettier than Android or the other way round?

Google is popularizing a set of styles called "Material Design" and it's
friends. Here is an example:
[http://www.google.com/design/spec/animation/responsive-
inter...](http://www.google.com/design/spec/animation/responsive-
interaction.html#responsive-interaction-user-input). Here is another example
of something more classy:
[http://motherfuckingwebsite.com](http://motherfuckingwebsite.com). Why the
first one is any better than the second one, only Google knows.

We can have simple sites, like the present google home page, like the blog
post you linked, like the second example I linked, etc. without emulating
native, which do their work, and users use them with a lot of love.

P.S. The question "why do you need smooth transitions" applies to native apps
as well, PPK ;)

------
sanxiyn
For comparison, see "Python Language Moratorium". I think its outcome was
positive.

[https://www.python.org/dev/peps/pep-3003/](https://www.python.org/dev/peps/pep-3003/)

~~~
drivingmenuts
Python is a language with one official supplier and many customers. Most of
the other Pythons base their functionality in the official Python and alter
the underlying code to suit the platform.

Browsers are supplied by at least three main sources and several smaller
sources, each trying to convince everyone that theirs is the One True Browser
by pushing forward at breakneck speed. There is never going to be total
agreement (or even sanity) as long as that is the case. It's a mixed blessing,
IMO.

------
lojack
While I agree with the general idea, I completely and utterly disagree with
both his examples and approach.

First, it's almost like he's arguing that IE6 was a good thing for the web.
This one completely boggles my mind. Yes, some people came up with some pretty
creative tricks. Did it stifle innovation? Absolutely. Countless hacks were
made that are arguably(?) worse than polyfills. These hacks persist even to
this days. Further, modern browsers must take all of these hacks into account
when moving the web forward. This is massive technical debt. Additionally, how
many man hours were spent creating these hacks to deal with the shortcomings
of IE6? That time could have easily been spent working on something awesome.

The other example on page transitions is a bit more reasonable, so I'm being a
little pedantic on this one. I agree that page transitions are a bit much,
however why is a polyfill really necessary?

All that being said, I agree with the general sentiment. We need to slow down
and put thought into the features we're creating. However, I don't think we
need to stop working for a year and see how everything plays out. What happens
after 5 years? We stop for a year and continue as if none of this ever
happened, then continue pushing things forward for 4 more years. Then we run
into the same exact problems. We need to have a way to vet experimental
features, and a plan to remove them (and old features) if they don't pan out.

We've progressed far enough to where removing legacy features is as (if not
more) important as introducing new ones.

------
buckbova
> We’re pushing the web forward to emulate native more and more, but we can’t
> out-native native.

I can do better than native.

I can update web apps without troubling the end user, fix bugs and make
improvements immediately.

I can balance processing where heavy lifting is done on my servers and simple
processing done on the client.

I can store immense data in the cloud freeing the end user's machine from any
such junk, aside from maybe a cookie, and stream it on demand.

Why should someone have to install anything on a phone, tablet or PC? Feels
archaic. Open browser. Navigate to URL. Do work, enjoy media, etc.

~~~
pdkl95
> I can do better than native.

No, you can't. Not even close. Just because you only ever use a subset of what
can be done in a native application doesn't mean the rest of us don't.

Also, which "native"? Win32 != OSX != X11 != mobile != ...

> I can update web apps without troubling the end user,

Which makes you the source of one of the most common types of user
frustration: apps that change without their authorization, sometimes breaking
important things that used to work just fine.

> ... processing ... done on my servers ...

Ahh, so you just want to lock people in using Service as a Software
Substitute[1]. Trying to do an end-run around "1st sale" rights to insert
yourself as a middleman where none was needed previously is terrible,
sociopathic behavior.

> I can store immense data in the cloud freeing the end user's machine from
> any such junk, aside from maybe a cookie, and stream it on demand.

The user also has to trust that you will handle their data sanely (and not
"monetize" \- including using or selling the analytics of their usage
patterns). They have to trust that you will not betray them and hold their
data for ransom. They have to deal with the fact that you will hand over any
of their data in bulk when the government shows up with a national security
letter. They have to trust that you are competent at programming and have not
stored passwords or allowed their data to be stolen.

The trade off being made by storing data remotely is huge, stop pretending it
doesn't exist.

> Navigate to URL

And when internet access isn't available? Don't believe for a second that this
isn't a problem. The reasons why are far too numerous to list; it would
require a lot of wilful ignorance to pretend otherwise.

> Why should someone have to install anything

Because they like to actually use all of the features a native app can
provide?

Because they don't want to risk their data with an external service?

Because they don't want to depend on the availability and whims of an external
service?

 _Because they are tired of the lies and doublespeak the computer industry has
been saying about "the cloud"?_[2]

[1] [http://www.gnu.org/philosophy/who-does-that-server-really-
se...](http://www.gnu.org/philosophy/who-does-that-server-really-
serve.en.html)

[2]
[https://projectbullrun.org/surveillance/2015/video-2015.html...](https://projectbullrun.org/surveillance/2015/video-2015.html#balkan)

~~~
NeutronBoy
All of those problems? Users don't know, don't understand, or don't care.

Native? Regular users don't care if an app is native or not - they just want a
well designed app that works across their laptop and tablet.

Updates? That's probably one they do care about - they want it to happen
without being interrupted.

SaaS? Users don't care - value for them is about 'it just works', not some
philosophical debate about if they only have a limited use license for the
music they stream on Spotify. If Spotify shuts down, they'll move to the next
service.

Cloud storage? Users want their stuff to be accessible from their phone,
tablet, and laptop. We need to educate them about risks with that, and put
_transparent_ controls in place to help them.

Installing apps? Users don't care - just make being able to use an app _easy_.
Website, app store, whatever.

As a developer, it's your (our) responsibility to help the user figure out
where it matters in terms of _getting the outcome the users want_. Hide the
shit they don't care about, educate them in language and terms they understand
about the things that do matter, and don't annoy them with inconsequential
stuff.

~~~
immibis
For how many apps do users want it to work on their laptop _and_ tablet?
Personally, if it works well on tablets only, I'd just get out my tablet when
I want to use it. It's not like I'm tied to using particular devices in
particular locations.

------
bshimmin
This was the first I'd heard of "Navigation Transitions" (perhaps I don't read
the right mailing lists), and ppk's right - this seems like an absolutely
crazy feature to add.

~~~
callum85
What about the idea turns you off immediately?

~~~
bshimmin
Two things: 1) it requires an extra stylesheet (from what I can make out, at
least); 2) you can already achieve this with JavaScript, if you really want it
(which is, itself, debatable), so why add extra cruft into the browser?

Also, from the page ppk links to:

    
    
       <link rel="transition-enter" duration="0.25s" href="URI" />
    

This makes absolutely no sense, though perhaps it has a place amongst the
wealth of gibberish we've seen stuck between <head> tags over the years -
<meta http-equiv="pragma">, anyone?

------
jscottmiller
> Instead, we should focus on the web’s strengths: simplicity, URLs and reach.

How does new browser feature X prevent a developer from doing any of these
things?

> Being forced to work around IE6’s issues required quite a bit of creativity,
> and although not every solution stood the test of time (most libraries and
> frameworks from that era, for instance), it still made the creative juices
> flow.

'Tools' are bad except when they are used to work around stagnant browsers, I
guess?

~~~
adrusi
Both of your points are right, but I'd like to point out that regarding:

 _How does new browser feature X prevent a developer from doing any of these
things?_

A moratorium on new features probably wouldn't help, but the reality is that
web developers _are_ focusing on new shiny browser features that allow for
deeper native integration, rather than on the core elements of the web that
work and carry greater usability gains, like offline support.

~~~
jscottmiller
That's a good point. I can see a progression like: developer finds new feature
X that solves problem Y, developer finds that feature X is only supported by
20% of customer browsers, developer adds polyfill in XXX kB, buggy javascript
library with other performance-related side-effects.

Maybe the issue is just educating web developers about what's available, and
the non-obvious side-effects using feature X.

Here's what I'd like to see: organize a site like caniuse not by feature, but
by tiers of support in the entire population of installed browsers. Something
like:

Supported by 99.99% of user-agents: image tags, ... Supported by 95% of user-
agents: XHR, ...

(I'm making those numbers up).

------
swalsh
The web is an ecosystem, browsers are species. They create new mutations in a
new attempt to thrive. The definition for what it means to thrive is always
the same. To replicate oneself the most. That means the largest user adoption.
If performance is what users judge by, then browsers will adopt to it. If
transitions are what users what, than browsers will adopt.

IE had trouble adopting, it had the wrong balance of features. That's why it
started to go extinct.

You can't DESIGN an ecosystem. You can't tell an ecosystem to stop churning.
It just keeps going.

Timing also matters. If a fish evolves a hand, does that make a better fish?
Maybe not, but if the fish starts breathing, and living out of water... maybe
those hands would be pretty useful.

------
IanDrake
In a way, I see what he means. Let's take a breather to let all the major
browsers support the existing standards before we give them more draft specs
to chase.

------
datashovel
I think we need two primary things to solve this "problem".

1) we need more browsers

I know this probably sounds counter-intuitive, but I think I have a good
explanation for it.

2) we need to allow developers to "choose" browser of choice that renders
their page / app / whatever in the (what I would call "meta-browser").

The architecture of browsers is incorrect in that instead of having a few
browsers, all of which developers must support, we need one (or a few) "shell
applications", which "host" browsers. Browsers can then begin to become
specialized and diversify in directions they want to (instead of forcing
everyone to stay up to date with everything).

Today I agree, it's a circus, trying to keep up with things, and figuring out
how to mash stuff together in order to ensure cross-browser compatibility.

So, how do we get things to a point where a developer gets to "choose" the
browser for the user? Probably one of the simplest would be to pass HTTP
headers which tell the "shell application" which browser to render the web app
/ site / whatever in.

There is not enough room in one HN comment to explain the nuances that I think
can be solved relatively easily (ie. security, user confusion, etc).

I did write a blog post that explains more or less what I am talking about
here:

[https://medium.com/@datashovel/why-isn-t-there-a-meta-
browse...](https://medium.com/@datashovel/why-isn-t-there-a-meta-
browser-204997473c61)

~~~
datashovel
With all that said, I really do hope the OP was saying all he had to say in
jest. It seems ridiculous that one person should have any expectation they (no
matter how well known they are to the community) can stand up in a crowd of 7
billion people and say "hold on, let's stop and think about what we're doing".
This assumes all 7 billion (or even most of them) are not thinking before
doing, or can't possibly be certain about what they're doing without express
written consent of OP.

Just because one person can't possibly keep up with all that is happening in
the world doesn't mean everyone should feel obligated to stop to allow them to
catch up.

OP also seems to imply it'll be near impossible to reverse out of what is
going into the web, no matter how good or bad those decisions are. I think
it's a bad assumption. Things will continue to move forward. Whether that
means one company or two decide to take two steps back is another question,
but in general the web will (and should) continue moving forward. It's a great
idea to have "web as platform", and not "web as html and links".

Please web, don't change direction of your thinking. You're on the right
track. We just need some relatively minor architectural changes to make it go
more smoothly for more people out here doing what we're doing.

------
392c91e8165b
One thing I do to try to slow down the rate of change on the web is to upgrade
my browser less often than most people.

Specifically, I use Firefox Extended Support Release (ESR).

Mozilla resisted providing this "update channel" (Firefox ESR) for years, but
eventually yielded to the desires of large IT departments. Despite Mozilla's
writing that "Firefox ESR is meant for organizations", with only one or 2
minor problems (with plugins IIRC), which I easily solved by upgrading
temporarily to Firefox's normal ("release") "update channel", I've used it
personally for years.

Below is a link to the best page I've been able to find to download Firefox
ESR, but note that both version 31esr and version 38esr are available from the
page below. Version 31esr is still supported with security patches and is what
I have been using. It is my understanding that before it stops getting
security patches, version 31esr will automatically upgrade itself to version
38esr.

[https://www.mozilla.org/en-
US/firefox/organizations/all/?q=e...](https://www.mozilla.org/en-
US/firefox/organizations/all/?q=english+%28US%29)

~~~
immibis
> will automatically upgrade itself

No no no no no no no no no no no no no no no no no no no. No. Just no.

------
raintrees
This viewpoint reminds me of an Attorney's, who used to be a City Attorney: He
felt that for every law passed, two should be struck from the books.

Or taxes: I have heard it said a politician rarely finds a tax they want
repealed.

Wouldn't focusing on core web infrastructure for a period of time encourage
addressing shortcomings, like the current state of security (and sometimes
lack thereof)?

------
agentultra
The cool thing about many of these features is that I can push out some code
that I can share with a hyperlink and other people can run it without
installing anything other than a browser.

The authoring experience is still terrible. And the user experience still
requires hopping over the secret, invisible wall into developer-tools land...
but the potential is there. If you're savvy enough to open your web console
and view source you can mess around with some code I wrote to demonstrate some
fundamental procedural algorithms[0].

I chose Javascript and <canvas> because everyone has a Javascript interpreter
and most browsers today support <canvas>. If I had chosen to demonstrate these
algorithms in Python, for example, I'd have to expect my reader to download
and install a Python interpreter for their system, download or copy/paste my
examples, and load them into their REPL before they could start playing
around. The browser experience requires fewer steps.

A moratorium would be a welcome change of pace, IMO. It'd be nice to close the
gap between the user and the developer and between document, code, and media.
It'd be nice if authoring tools for these environments could catch up with the
available features.

On the other side of the coin the proposed common byte-code format is really
exciting and practical for all sorts of reasons -- in the case of my
aforementioned blog post I think there are better languages to teach with than
Javascript and having that language be available as a first-class citizen in
any web document would be a boon.

I think some features would still be worth pursuing in favor of others.

[0] [http://agentultra.com/2015/06/24/introduction-to-
procedural-...](http://agentultra.com/2015/06/24/introduction-to-procedural-
algorithms/)

~~~
romaniv
_The cool thing about many of these features is that I can push out some code
that I can share with a hyperlink and other people can run it without
installing anything other than a browser._

What you describe is a hack for lacking isolation/security/permissions/package
management in the operating system. Seriously, if there was a sensible way of
isolating apps and handling dependencies, it would be perfectly sensible to
implement a lot of the current web "apps" as real applications.

~~~
agentultra
What I was attempting to describe was a document format the freely mixes code,
documentation, and interactive media. The present set of features in the
browser allows for a very fluid mixing of these elements but the authoring
tools and user experience are lacking in most browsers.

I can share similar documents via org-babel, iPython notebooks, or Matlab
notebooks, etc... but each requires the user to be accustomed with those
applications to install them, fetch my code from a URL, load it into their
environment, etc. With the present browser ecosystem they can fetch everything
as a single document and run the interactive examples and modify code on the
fly... if they're willing to hop over the developer-tools wall.

------
vbezhenar
I don't think web moved forward. There are some fun features, but the only
thing I really see in last years is HTML video replacing Flash. Otherwise it's
the same web as it was 10 years ago.

~~~
rocky1138
From a technology standpoint I agree with you, except that images have gotten
larger in file size.

Socially, we've lost the "anything is possible" vibe that the early web had,
thanks to oppressive governments and spying.

~~~
immibis
> Socially, we've lost the "anything is possible" vibe that the early web had,
> thanks to oppressive governments and spying.

I'm not sure those two things have anything to do with each other.

------
RubyPinch
slinging around "web trying to be native is bad" in the way the author does is
such a thoughtless argument: just because something exists in native land (a
land of a lot of well paid researchers and designers, etc etc), doesn't make
the idea bad for everywhere else. Maybe the idea is just a plainly good design
decision?

(I mean, do you have fond thoughts of the entire page flashing white, then
pieces of the page bouncing around the screen as they try to position
themselves based on content that hasn't loaded yet?)

~~~
JustSomeNobody
"(I mean, do you have fond thoughts of the entire page flashing white, then
pieces of the page bouncing around the screen as they try to position
themselves based on content that hasn't loaded yet?)"

You mean like it does now?

~~~
RubyPinch
yes, which is why "imitating native", aka not reloading the entire page, is
seen a lot more on sites like facebook and twitter (the ui stays the same as
the main page reloads), this is done to provide a more comfortable experience,
sans screen flashing rave party

navigation transitions (more of this horrible ugly "native" stuff) is
standardizing a mechanism for this

------
k__
We went from the stagnation to fast-forward.

I hated the old days because nothing seemed to change.

The browsers had slowed innovation because of IE and PHP didn't seem to try
much new things (besides the OOP additions) for a long time.

But it was easy money. I learned PHP, HTML and CSS and was set for about 10
years with subtle changes.

Since 2013 I went from ExtJS, to Ember, to React on the client and from PHP to
Node with Express and then Koa on the server.

It got a bit more exiting, with all the new features and a much faster
development pace, but I went from old, never fixed bugs to new unstable
libraries. So the rage stayed the same, hehe.

------
davesque
I can't disagree more with his critique of navigation transitions. Transitions
are the best way people can create a great user flow without needing to
structure their web app around the single-page, stateful, AJAX (or WebSockets)
paradigm. If you think transitions are a bad idea, I hope you think single-
page apps are a good idea. And if you think that the web just wasn't meant for
that level of native-app-like functionality, I think you're not going to win
that argument against the real demand for those kinds of offerings on the web.

------
MrDosu
The only reason web applications are such a big thing is discovery. It is much
easier to get someone to your page than it is to get him to install an
executable.

What we need is better app marketplaces with OS integration.

------
unabst
An experience is not a function of a feature. The browser does not define the
experience -- the web developer does. So to say creating too many tools is
bad, if anything, is an attack on the web developer for misusing their tools.
For this reason, we shouldn't be able to say navigation transitions are a bad
feature. The onus is on the web developer to create a positive experience.

>Do we want the web to be at whatever we push it forward to?

It never became what we pushed it to. A new feature is unusable. Nobody
building a critical page can use cutting edge features due to bugs and
compatibility, and they are mostly for experimentalists and fiddlers. Only
those with deep pockets can do the multi-platform web page which is building
multiple web sites just for a handful to have a cutting edge experience, but
even this trend is dwindling it seems with the death of Flash.

A new feature, if anything, is an offering. It is a question posed to the web
developers by browser developers asking them to examine a new opportunity for
new experiences. The web developers then tell the browser developer community
whether they love the feature or hate it, and this is how the web has
organically evolved.

Therefore, it can only be a good thing that finally all these features are
being pushed to production so that all these questions can be posed. So do we
love them or hate them? The browser developers focus should be on pushing
cutting edge features forward, and not on experiences. Leave that to the
professionals, and mock their work if you have to.

------
bcheung
If you can't keep up then don't.

Some of us have ideas we've been wanting to implement and are just waiting
until a browser feature becomes available and widespread enough that it is a
possibility.

I don't want to have to develop for the web and an Android app.

I don't want to have to develop for the web and an iOS app.

I don't want to have to develop for the web and a .NET app.

I don't want to pay 30% to a company just so they will let me deploy MY OWN
app to MY OWN users.

I don't want to have another company dictate what I can or can not provide to
my users.

~~~
grgbrn
I'm not sure how you square "If you can't keep up then don't" with what sounds
(to me) a lot like "I have an idea that I want to implement, but only if I
don't have to learn anything new"

To try to be at least somewhat constructive:

I took PPK's argument as: "Trying to cram everything and the kitchen sink into
your browser so that you don't have to ever write native code may be
appealing, but it risks collapsing under it's own weight."

Which, to me, doesn't seem so ludicrous that it deserves to be shouted down.

~~~
bcheung
It's not the learning or the hard work that concerns me. I'm all for that.
It's proprietary walled gardens for the most part. I want to build apps that I
already know Apple won't approve so that leaves me with a reduced ability to
service my users until mobile web gets better.

------
Johnny555
_Native apps will always be much better at native than a browser_

That may be true but I don't want to install dozens of applications, I _like_
being able to run apps in my browser. Google Docs is great... 99% of the
functionality i could ever use in an office app, and no need to install
software (if it even runs on my platform).

And I absolutely hate browsing the web on my phone to have every site pop up a
"hey, try our mobile app, its soooo much better" message that gets in my way.

------
rabbyte
Native emulation has been a goal of the web from the beginning. I can recall
several efforts as far back as '96 to create websites to replace desktop apps
and we arguably achieved that around 2005 with apps like Google Maps or
Writely. Two years before the iPhone was released we were chasing the tail of
"native". The web vs native debate skips over the idea that these two worlds
actually inform each other and are largely populated by the same developer
community.

As an industry, I think people are starting to place more value on the
comprehensibility of software over its capability and that's where I think PPK
hits home here. When you're building to satisfy immediate needs it makes sense
to eventually stop and revisit your implementation to make sure (1) those
needs are still relevant and (2) your implementation adequately satisfies
them. That's what I see this as, not a call to stop chasing native, but a call
for replacing the patchwork with comprehensible design. I think that's
perfectly reasonable and I would go so far as to say we should build it in as
a cultural value to pause every 10 years to both celebrate what we've
accomplished and refine the result.

------
ForHackernews
> Interestingly, Microsoft added a similar feature to IE4, and deprecated it
> as of IE9. The idea didn’t catch on because back then nobody wanted to
> emulate native apps (which didn’t exist), and therefore nobody particularly
> cared if the users had to briefly wait for the next page.

> native apps (which didn’t exist)

Does this writer believe that nobody installed software on their computers
before the iOS app store opened in 2008?

~~~
scholia
The usual meaning is "native apps" for smartphones, as opposed to traditional
programs like PhotoShop and AutoCAD.

It's a broadbrush description but almost everybody gets it.

Would you like to offer a simpler, shorter and more accurate way of making
this distinction?

~~~
ForHackernews
I think it's a silly distinction to make. Native applications (meaning
software running on a computer, outside a browser sandbox) have always offered
a smoother, more comprehensive user experience.

That doesn't mean users get no value from the web, or that they're so spoiled
by fast transitions in Microsoft Word that they won't want to use a website.

~~~
scholia
I agree, but that's not the point.

The point is that some -- perhaps many -- people want to distinguish between
smartphone apps and traditional programs, and that's one way to do it.

It would be nice if there was a better way, but I don't know of one.

Incidentally, it's a distinction that people also make between "universal
apps" (written for Windows Runtime) and desktop programs (written to the Win32
API) even when they do the same job on the same Windows 8 or Windows 10 PC.

~~~
bztzt
The meaningful difference is whether there are isolation and
distribution/update mechanisms so that users can install and maintain apps
with less risk and hassle. This doesn't have much to do with (in-app) UI per
se, though.

------
mkozlows
I've gotta say, I'm somewhat sympathetic to the idea that we'd be better
served by a period of focusing on stability and performance over new
features... but talking about the IE6 stagnation era as a good thing?

Yeah, no, that was awful, and if you're holding it up approvingly, well, now I
officially disagree with you.

~~~
scholia
The IE6 era (2001 to 2005 or 2006) was a period of great creativity, and it
was when a lot of dominant web properties became established. Examples include
Wikipedia, LinkedIn, Second Life, The Pirate Bay, MySpace, Orkut, Facebook,
Gmail, Flickr, OpenSreetMap, YouTube, MegaUpload, Pandora and Twitter.

Web 2.0 became popular during that era (2004 onwards).

That "stagnation" compares rather well with much of the flashy, transient
rubbish being launched nowadays.

Also, when it came out, IE6 was the most standards-compliant browser and
generally performed better than its main rivals.

------
Dysprosium
I don't see how pages transition is trying to emulate native apps. It still
falls under the paradigm of accessing a resource at a given URI, which is what
the web is. Personalizing the way the resource is loaded by the client and
displayed to the user? That's just cosmetics we should definitely care about.

Currently, the most popular way of implementing "native apps" in the browser
are Single Page Applications, which breaks the web paradigm and hence have
practical drawbacks such as the inability to open some resources in a new tab
or to bookmark them. One motivation of SPA is the fact that loading a new
webpage produces a blank intermediate screen during downloading, which is
lame, especially for pages which are almost the same. Pages transition can
change that, and in a beautiful way.

------
PSeitz
>But why do web developers want navigation transitions? In order to emulate
native apps, of course.

You got this one quite wrong. It's not about emulation, it's the feature.
Reducing the perceived delay with an animation. There is nothing wrong with an
improved webpage experience ...

------
drb311
Damn that page loads fast.

------
rythie
...meanwhile we still have flash video because HTML5 isn't good enough to
replace it yet.

------
Eric_WVGG
“Everybody will have a favourite upcoming feature that would be hit by the
moratorium — mine is offline capabilities.”

Mine would be next-generation image handling — <picture> tags* and some sort
of alpha-blendable lossy format.

I work for a lot of artists and designers, these guys want fast, retina full-
screen responsive images, and I’m not sure that it’s an unreasonable
expectation, but I’ve got enough technological hoops to jump through to recall
the days of “Netscape Now!” and “IE 5” badges.

* don‘t talk to me about the unholy abortion that is srcset

~~~
jacquesm
> I work for a lot of artists and designers, these guys want fast, retina
> full-screen responsive images, and I’m not sure that it’s an unreasonable
> expectation, but I’ve got enough technological hoops to jump through to
> recall the days of “Netscape Now!” and “IE 5” badges.

Do the users want those too?

~~~
Eric_WVGG
Do users want cellphones with 64bit CPUs, 1gb DDR4 RAM and an SSD, or a phone
that turns on instantly and has near perfect responsiveness?

When I get the visuals dialed in a way that is quick and responsive, yes, the
users seem quite receptive. I could do a better job for them with better tools
at my disposal.

------
jay_kyburz
I didn't see this discussed below, but I think when PPK says

    
    
        web’s strengths: simplicity, URLs and reach.
    

I think he misses an important feature for me, as a user: Security.

I just don't trust native apps. Even a non-malicious app can undermine your
systems performance and behave badly.

I've spent too many hours trying to "clean" windows systems, there is just no
way I want to be installing native apps on them any more. My windows machines
have the OS and its bundled apps, MS Office and that's it.

~~~
immibis
Mobile apps are sandboxed already.

Windows is also pushing towards sandboxing desktop apps, but look at the
backlash that's received. (Although they implemented it poorly - there are two
completely different types of apps, and you have to choose one?)

(Also, realistically, installing _trusted_ unsandboxed apps generally goes
fine, because if they were malicious you would've heard about it by now)

~~~
jay_kyburz
How do you define _trusted_ apps. The windows app store is full of junk.

------
pc86
> here is an artist’s impression of the modern browser

> _screenshot of Microsoft Word in a 14-year old unsupported OS on what is
> most likely a 1024x768 screen with all toolbars activated_

------
macu
I constantly get the sense that I am missing whole swaths of the configuration
options available in mobile and web development. The fact is, a dedicated team
with experience will know how to tweak variables for an excellent product. New
possibilities are continually arising but not everyone will use them. A lone
developer is likely to produce something more retro. Experience and dedication
pay off as you develop finer control.

------
applecore
Navigation transitions actually sound like a pretty good idea, considering it
emulates one of the most salient features of a single-page web application.

~~~
TazeTSchnitzel
And, ironically for an article calling for "care for user experience", is
proposed to _improve user experience_.

------
est
Anyone tried to use the HTML5 File API manually? It's a cluster fuck unlike
any of good old javascript.

> Navigation Transitions

Seriously? It's like Frontpage 99 again.

------
_pmf_
WebGL that more often than not crashes the browse, CSS animations that
saturate an octocore ... one wonders if there are no more pressing matters.

------
colemorrison
I'll make the opinion purely from a self-interested developer standpoint:

I'd rather push the web forward and have it at least stay "somewhat" close to
native (no it'll never be better) and constantly learn new features... rather
than:

.... have it lag behind native even more and thus create even more pressure on
myself, my company, and my career to adopt, learn, and build native alongside
web.

------
jv22222
Part of the beauty of new innovation and new features is that you don't know
what people are going to do with it.

Many of the best things about the web are features that we didn't originally
plan for but created using javascript and such, then we folded it back in to
the specs.

When you add something new, most likely someone somewhere will do something
very cool with it in ways we could not have envisioned.

------
overgard
Who's "we"? I know it's a blog and he's probably just going for a colloquial
tone, but I always find this notion of some great big web development
community weird. The web is countless tribes with differing goals, and if your
call is to non-action all you're really doing is leaving the future to those
that act.

------
intrasight
I'll state it somewhat differently: Stop pushing the specs forward - finish
implementing the specs.

If all those spec writing engineers were told "sorry, the spec store is
closed", they might actually get their hands dirty writing code for the
current specs. Hell, I might even lend my tired old hands if there were a
moratorium on new specs.

------
0xFFC
I think the answer to all question/problem get mentioned in comments is WebOS
or specifically ChromeOS.you have web cross platform app,without huge cost of
browser on top of os(so vendor can optimize the software stack very well).only
problem with ChromeOS is non organized native app development.which could be
solved by WebAsm.

------
w0und
I couldn't agree more, we need stop and take a break. Enjoy the stuff we have
now and fix what is not working correctly. Adding more features just adds more
bugs and exploits, if you have been paying any attention to the web lately you
would notice that the a lot of the bugs popping up are 10+ years old.

------
codeshaman
That happens all over tech, not just in web browsers.

Just for fun, I've spent a couple of minutes compiling a list of technologies,
_just for the backend side of things_ , which many of us know or have heard
of, which ilustrates the complexity and diversity that we have in our industry
atm.

It's both beautiful and scary at the same time - how will we be able to move
all of that into the future ? How will we scale our brains as we get older ?

So here it goes.

You want to implement something on the Backend ? Nothing can be easier!

Step 1. Pick a language.

 _C, C++, Go, Java, Ruby, Python, Dart, PHP, Hack, Erlang, D, Xhp, Javascript
/CoffeeScript, TypeScript, Perl, Scala, Scala, Clojure, Lisp, ColdFusion, or
ASP.NET (C#, VB, F#)?_

([https://en.wikipedia.org/wiki/Programming_languages_used_in_...](https://en.wikipedia.org/wiki/Programming_languages_used_in_most_popular_websites))

Step 2. Pick a framework for the selected language:

 _ASP.NET, Ruby on Rails, ASP.NET MVC, Django, Meteor, Laravel, Spring,
Express, CodeIgniter, Symfony, JSF, Flask, Flex, CakePHP, Zend, GWT, Play,
Yii, Sinatra, Tornado, Grails, Struts, Dojo, web.py, Wicket, Bottle, Pyramid,
Kohana, Koa, web2py, Yesod, Revel, (fab), Gin, Compojure, Martini, Vaadin,
beego, CherryPy, Ring, Scalatra, Mithril_ and many more
([http://hotframeworks.com/](http://hotframeworks.com/)).

Step 3. Pick a database:

 _Oracle, MySql, MSSQL Server, MongoDB, PostgreSQL, DB2, Access, Cassandra,
SQLite, Redis, SAP Adaptive, Solr, Teradata, Elasticsearch, HBase, FileMaker,
Hive, Splunk, HANA, Informix, Memcached, Neo4j, CouchDB, Couchbase, Firebird,
MariaDB, Netezza, Azure SQL DB, Amazon DynamoDB, Vertica, Riak, MarkLogic,
dBASE, Ingres, Sphinx, Endeca, Greenplum, Ehcache, Interbase, Amazon
Redshift……._ [http://db-engines.com/en/ranking](http://db-
engines.com/en/ranking)

Step 4. Pick a hosting provider: Classic or Cloud and pick from just _several
hundred_ providers with different APIs and architectures.

Step 5. You're all set! Enjoy your backend. Now it's time to pick a front-end
!

Given that most of these have been created in just the last 15 years or so,
what will the next 15 years bring ?

~~~
yellowapple
> Step 1. Pick a language.

Since the focus seems to be on _web_ backends (given the section following
this one), I'd imagine that trying to use C or C++ for such a thing would not
be one of the obvious choices.

Also, you've listed Scala twice, I'm pretty sure Xhp and Hack count under PHP,
and God help you if you opt to use ColdFusion or ASP.NET (or PHP, for that
matter) in anything new.

> Step 2. Pick a framework for the selected language:

Once you've picked a language, you can usually narrow down the selection quite
a bit. For some languages it's a bit harder, but for most, the choices are
manageable.

C/C++ -> Raphters, CppCMS, WSO2, Wt, ffead-cpp

Go -> Revel, Martini, Gorilla

Java -> Spring, JSF, Struts, GWT, Play, Grails (if we count Groovy as Java),
maybe some others that I haven't heard of yet

Ruby -> Rails, Sinatra, Padrino (which is basically Sinatra plus some helpers
for databases and views), camping (if anyone actually uses camping in
production, please let me know)

Python -> Django, maybe some others (but Django's the only one I hear about
regularly)

Dart -> does anyone even use Dart? I'm pretty sure even Google has moved on to
Go for backend stuff, and the plan to integrate Dart with Chrome was
apparently cancelled.

PHP -> Laravel... I can't think of any others that I've actually seen used.
Pretty much every PHP app I've encountered was CGI-based.

Erlang -> YAWS or ChicagoBoss. If you're counting Elixir with Erlang (we might
as well), then we can throw in Phoenix and Sugar.

D -> vibe.d is the only one I know of

Javascript -> Node.js, probably.

Perl -> Catalyst, Mojolicious. Or just use (Fast)CGI.

Scala -> Play, Scalatra, Lift, Sweet, Slinky

Clojure -> Compojure, Webjure, Conjure, Moustache

Lisp -> (Common -> Weblocks, possibly Hunchentoot), (Scheme -> SISCWeb (via
J2EE)), Racket

ColdFusion -> ColdFusion. I don't know if ColdFusion doesn't instead count
under the Java category, though.

ASP.NET -> I dunno, ASP.NET?

Basically, once you have a language picked (based probably on which one looks
the best to you), it's pretty straightforward to search the web for "$LANG web
frameworks" and find some sort of comparison between them.

> Step 3. Pick a database:

If you're not picking PostgreSQL, then you're wrong, end of story. _Maybe_
CouchDB or Mnesia if you know for sure that you need their replication
features and are aware of the tradeoffs of using a non-relational database.

SQLite deserves special mention, because while it's absolutely _wonderful_ for
end-user applications, it's not at all ideal for server software except for
specific use cases (like using it as an offline data storage format, e.g. for
backups or data imports/exports).

MongoDB, Oracle, MS SQL Server, and MySQL also deserve special mention
because, if you're using them willingly in a new application (other than to
interface with a legacy system that did involve such a regrettable choice),
you're probably not right in the head. In particular, there's pretty much zero
reason to use MySQL instead of MariaDB (which is also arguably marginal due to
its MySQL heritage, but at least it's _slightly_ better), using a commercial
database like MSSQL or Oracle is basically begging for vendor-lock-in-related
problems, and MongoDB... Jesus fuck-me-in-the-ass-with-a-pogo-stick Christ.
Might as well just pipe your data to /dev/null while ranting about how it's
"web scale" while we both transform into 3D-animated bipedal animals and I
resign from my job as programmer/sysadmin and go shovel pig shit for a living.

> Step 4. Pick a hosting provider: Classic or Cloud and pick from just several
> hundred providers with different APIs and architectures.

If you're smart, you'd go with Cloud Foundry, since a large number of PaaS
vendors support it, so you can pretty much just pick whichever one has the
best bang for the buck (might I suggest IBM Bluemix?) and use the `cf` tool to
deploy to it.

Additionally, if you're using containers of the Docker variety, the vast
majority of PaaS and hosting companies nowadays support them with little to no
modifications, so - again - the choice matters very little beyond one's
priorities regarding performance, location, and cost.

> Step 5. You're all set! Enjoy your backend. Now it's time to pick a front-
> end !

Now _that_ is a massive can of worms. So many frontend frameworks. So little
time. And pretty much all of them constrained to the quirks and pains of
Javascript.

Of course, you _could_ just go with straight HTML and CSS (plus a smattering
of JS using JQuery or Mootools), which is what I generally prefer to do in
most cases.

~~~
codeshaman
Nice write-up. I hope you do understand that the original message was a
sarcastic joke.

The point was - there's just so many technologies to consider and it's been
just 15 years.

When I got my first PC, my choice was: MS-DOS 3.3. QuickBasic, Pascal, C or
Assembler for writing programs.

There might have been other stuff, but I had no access to it. Ditto for
documentation, tutorials or books.

Things have definetely evolved and if the rate continues, we'll have thousands
of languages/frameworks in the next decade, unless something absolutely mind
blowing comes up and replaces everything forever.

~~~
yellowapple
> I hope you do understand that the original message was a sarcastic joke.

I'm aware. I just like taking things needlessly seriously. It's a hobby of
mine :)

> When I got my first PC, my choice was: MS-DOS 3.3. QuickBasic, Pascal, C or
> Assembler for writing programs.

Indeed, though those weren't the only choices even back then. Lots of
different microcomputers, all with their unique dialects of BASIC, up until
the late 80's and early 90's, when the diversity died off and IBM-compatibles
became the norm.

Really, the current evolution in software is more just a resurrection of the
diversity once strong in the realm of computers. Back then, one would actually
have to make conscious choices about CPU architecture of all things; nowadays
(for better or worse), we seem to be resigned to the idea of big machines
being x86(-64) and little machines being ARM or _maybe_ MIPS.

Not to say that languages weren't diverse back then, either. You still had
Lisp and FORTRAN and COBOL and Forth and C and assembly and PL/I and ALGOL and
Pascal and Logo (turtle power!). A little later there was C++ and Perl and Tcl
to join them as some others faded out.

Basically, the evolution now is less about the _quantity_ of platforms to
develop for and more about the _accessibility_ of those platforms. Pretty much
all the good ones are open-source, available on the internet, and have plenty
of online documentation. The free software and open source movements have been
a boon to those seeking to get their foot in the door.

> unless something absolutely mind blowing comes up and replaces everything
> forever.

I suspect that "something" will either be artificially intelligent or pretty
damn close to it. Development time and effort will decrease substantially if a
programmer can just tell his artificially-intelligent software maker what the
program needs to do - in a natural language - and the software-maker goes and
makes a program. I suspect there will be a couple of stepping stones before
that, including some existing stepping stones that we've already walked on.
One of them is LLVM, providing a common core that any language can use with
relatively-few obstacles. Another is the concept of programs that create other
programs; languages like Ruby, Tcl, and Lisp facilitate this quite well, and
it's probably a matter of time before those and similar languages are used to
do things like automatically generate HTML/CSS/JS for web apps (as one example
of potential usefulness in the short term). Natural language parsing by
artificial electrical systems is getting better and better, too.

------
return0
Things like webRTC are the _real_ push forward. It turns the browser to an
operating system that can do everything a native app can do. I agree about the
attempts to mimic "cool" animations from iphones - that's just cheap.

------
mildweed
This seems to be an appeal more to the W3C and browser developers than it is
to the rest of us. He's not asking us to stop, in fact, he's asking us to
double down and make use of the standards that we already have.

------
alricb
New features also mean new security bugs. A complete freeze might not be
optimal, but the "security cost" of new features could be given more weight
when deciding to add something to browsers.

------
eleitl
Much too late. If something is not plain text or PDF/A it has already
bitrotted away, or is well on its way.

The Web is an ephemeral enterprise.That's why everything relevant has a DOI
and not an URI.

------
qwtel
Just let the browser do what "applications" did in the 90s, while not breaking
the stuff that browsers did in the 90s.

------
PSeitz
> Quick, name all the new features browsers shipped in 2015! You see? I don't
> know all features shipped of any year, so I guess this point is invalid. I
> don't see anything bad in moving forward, when the things are well thought.
> And most are imho.

------
z3t4
Even though I'm a bit butt hurt about the new syntactic changes to JavaScript,
I very exited about the browser development.

Hardware accelerated Canvas 2d graphics and Web-sockets are the two I'm most
excited about because they are now stable across most browsers.

------
n0mad01
some truth has been spoken - broken features should be fixed first - then
we'll look again towards the future.

------
bla2
PPK really lost it some time last year :-/

------
frik
What's wrong with that site?

quirksmode.org used to be a great resource but it stopped being updated 10
years ago when IE 6 was still the "thing". Nowadays,
[http://caniuse.com](http://caniuse.com) replaced it.

So quirksmode transformed to a rant blog, like this one we had on HN three
months ago:
[http://www.quirksmode.org/blog/archives/2015/05/web_vs_nativ...](http://www.quirksmode.org/blog/archives/2015/05/web_vs_native_l.html)

~~~
notNow
He's clearly over the hill. He feels left behind with all the progress and
growth in the community and his cry wolf shouting style from the mountain top
is just pathetic.

As we say here, the dogs bark but the caravan moves on.

------
ommunist
Upvoted that article. I am tired too. I am not contributing to browser
development, but I just want to get more work done instead of spending more
and more time on learning.

------
bcg1
PPK, I'm sorry but you are midair, directly above the shark on this. Its not
too late to change course though.

We realize you are a mobile consultant, and standardizing many features in a
cross platform is a threat to you and your client base. But getting on your
soap box and telling people to not add features to browsers is unhelpful and
myopic.

Not everyone uses your stupid mobile platforms. Some people in the world don't
even have a phone at all. But they might be able to use a browser once in a
while. Do they not deserve features just because you have decided that it
would be too difficult to implement in the browser, and will "never be as good
as native" or however you put it. Your failure to see how things could be
implemented faster/better/cheaper does not preclude others from actually
getting things done.

I actually agree with many of the points that you make, but seriously... try
to see the forest for the trees and take a look at what you're asking of
people, and ask yourself why you are doing that.

~~~
kabdib
I've spent the last two years doing "full stack" [yeah, those words, sorry . .
. but going from bare metal to C++ to PHP/JavaScript to frobbing routers all
on the same day probably qualifies], coming from a background of C/C++ driver
and native code development for 30 years.

What I see is an immature community that cannot make up its mind. I see fads,
I see awful tools, and even more awful tools that try to fix the awful tools.
I see standards committees that pump out unimplementable garbage and I see
device manufacturers who think they are good at writing software (and they are
_not_ ). I see very bad, widespread and unpatchable security holes. I read,
every week, about the latest fad thing that will fix all your problems, just
install a list of 30 packages and suffer per-page downloads that are larger
than the native apps this mess is trying, badly, to replace.

I guess this will all shake out. But in the mean time, I am shaking my head.

~~~
bcg1
This is the problem with what PPK is suggesting.

The Firefox and Chrome developers are mostly certainly professional developers
who are well qualified to create a standardized cross browser feature set that
will obviate the need for the cruft.

Only recently have we started to emerge from the Silverlight-Flash-JavaApplet-
ActiveX-webish ghetto that we were mired in for years as Microsoft refused to
add new standard features to IE. His suggestion is essentially to return to
that paradigm. He should know better... he built a site called 'quirksmode'
after all...

~~~
kuschku
No.

His suggestion is to stop, and wait.

Spend a year on standardizing, fixing bugs (like the bug with chrome where it
sometimes just "forgets" float-css rules), a year spent on improving issues
and making everything behave consistently between browsers.

A year spent so that we won’t have to use jQuery afterwards anymore. Or
underscore.js.

A year spent on fixing all the little bugs, and making a consistent roadmap
where we actually want to go. Thinking about stuff like the Virtual-DOM of
Angular or React and finding a better solution than that.

This is what we need to focus on. Making stuff behave consistently. And with
one year, we can make sure that afterwards most of the market will actually
use our new version. We can finally get rid of all the polyfills.

~~~
bcg1
You're missing my point. The world won't stop just because you decide to
reflect on the situation and have small groups of people unilaterally decide
what will someday maybe be standardized in some browsers. In the meantime the
new features will get developed as non-standard features and you'll have even
more proliferation of cruft, "polyfills" and whatever else PPK is complaining
about.

~~~
kuschku
Why not? Why do we have to push new features every few weeks? The web still
works right now, and it did in 2009, too.

------
cromwellian
I think PPK is missing the point being "features" being added, and
rationalizing the design of the old Web APIs by making them a proper layered
stack of primitives. Much of the work being added to the browser recently
obviates the need for "high level" opaque features to be added, and instead
exposes enough low level primitives that these can be implemented by
developers in libraries.

If you get a good set of low level primitives exposed that are freely
composeable, then you can stop adding "features", and let third parties
develop those features.

The Web is missing lots of features for mobile that are being added today
which simply cannot be replicated by freezing features and using IE6 era
hacks. These are features that are needed not to emulate native apps but to
make the end user experience of the Web _better for end users_.

For example, ServiceWorker replaces the terribly designed Application Cache,
and enables better caching logic, offline use, and push message delivery. If
you're building a mobile site app for say, users in developing countries with
very restricted data plans, than using ServiceWorker to control and preinstall
cached resources, incrementally update those resources, possibly just by
receiving a push notification, and allowing users to browse the site without
even spinning up the cellular radio, that will be a huge boon to both the
economics of the app in those regions, but battery life too.

These rants don't come with any context of what the alternative is. The vast
majority of human beings are now online via mobile as their _only_ mechanism
for content. The Web wasn't designed for mobile. It needs updating, and simply
thinking we can return to the vision of XHTML Mobile/Mobile CSS circa 2004 era
is not going to convince anyone. Either it will encourage Facebook Instant
style destruction of the Web, with more and more content moved into
proprietary silos, or you'll see something like Flash come back.

Remember, we finally disposed of Flash by upgrading the Web to the point where
it wasn't needed anymore.

We don't want a similar situation to occur for the mobile web.

