If we stand still, we go backwards | Hacker News Reader

If we stand still, we go backwards

jakearchibald.com

93 pointscallum8533 comments

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.

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

What a great idea.

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.

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.

"Calling for a moratorium sounds very dramatic, but I suspect PPK wanted to use dramatic language to make the point"

Good points can be made without hyperbole. I think ppk's article had much value to offer, but it drowns under the weight of a clickbait headline causing people to debate the wrong things.

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.

"Furthermore, the author's definition of "native" is revisionist, placing it at a highly recent time frame" - this is the usage in the article I'm responding to.

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.

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

"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?

The "need" is this case is being demanded by the end users, not the businesses. ServiceWorker for example solves real user needs, especially in the developing world. This is not "let's use bleeding edge features for bleeding edge sake" but "our users are abandoning our product, so we either need to rewrite as a native app, or lose business"

If these new technologies and frameworks don't have business case to justify their adoption or make any sense from a practical standpoint, believe me they will not pick up and will eventually fall down however hip or cool they sounded or looked right after their debut or launch.

So, I say embrace progress and let the market decide what technologies stay and what to leave behind.

Calling for deliberate stagnation for the web is intellectually disingenuous in light of the Great Web Depression during 2000 - 2005 and the following recession 2005 - 2008 right before iPhone 3G & Chrome launches followed by NodeJS and the HTML5 debut.

For all people worried about the seemingly neck-breaking rate of progress, I assure them that we will sooner or later hit some roadblocks that will slow down the progress and usher in a new era of stagnation for the industry as whole, that has been the case all along for all business and scientific, literary activities, that is the cyclical nature of human activities, but to do it on purpose and to have the audacity to advocate and brand it as a respite or out of concern for the well-being of the developers community is dishonest and totally unacceptable.

I don't buy this idea that everyone has to learn the latest framework or tool to stay competitive. Competitiveness comes from being able to make good work, repeatedly. 'Knowing the right framework' means very little, a good developer will just pick it up on the job anyway. I'd much sooner hire someone with a track record of building good things than one who just happens to 'know' whatever tool or feature we're using.

I feel zero pressure to learn every shiny new thing that comes along. If a new tool/feature seems to be gaining traction or generating a lot of discussion, then yeah I'll read up on it, but I mean reading for an hour or less. It's not a big deal to keep up.

"Hello world" is doable in 3 lines instead of 5, granted. But for more complicated development.. 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?

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.

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

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

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.

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

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

The connection kept resetting for me, so here is the Google Cache link: http://webcache.googleusercontent.com/search?q=cache:f-pnPOu...

---

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.

Hm, that's upsetting, I just added CloudFlare, I'd have hoped they wouldn't do that kind of thing.

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.

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.

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

HN rules highly frown upon submitting links with changed titles.

Except when the original title is unclear/clickbait. -> "If we[b] stand still, we[b] go backwards"

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

"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?

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.

"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

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

Reply on news.ycombinator.com