Will Low End Mobile Phones Make the Web Irrelevant?

General Prog (Archived)
, ,
1

Or more accurately:

Is the Web making itself irrelevant by making itself unusable on low end mobile phones?.

Alex Russell - The Mobile Web: MIA (Fronteers Conference 2019)

This is the latest edition of “reduce your JS-emissions” Alex Russell’s talk about the trends in the mobile web - but I think it’s the best and most compelling version yet as it reframes current trends in a slightly but more disturbing light.

Native apps have been threatening to make the Web irrelevant for some time now but some people believe “the War is over and the Web has won” - but nothing could be further from the truth if large parts of the Web don’t abandon the predominant desktop mindset sooner than later. Continuing to treat the Web as if it is primarily consumed through browsers on desktop computers could hasten the Web’s descent into irrelevance.

Viewing mobile first (not to be confused with responsive design) as some kind technological niche trend could be a big mistake when it needs to be treated as a survival strategy for the Web.

If you work in web development or plan to work in development - ignore the trends identified in this talk at your own peril. That being said there is so much going on here that it may be necessary to watch this talk twice to pick up on all the tidbits that are being offered.

The Web is … the content that is currently reachable by following links and which can be experienced on most devices

  • The Web evolved on the single core model but in the mobile space cores have been getting, on average, slower, trading instead for more cores.

  • Computationally, mobile device usage outpaces desktop computer usage.

  • In 2014 mobile users were believed to be spending only 14% of their time on websites (flurry). That time has now dropped below 7% and is falling.

The Web is not essential to the future of computing on mobile.

  • Desktop isn’t the growth market - mobile is

4.2 Minimum Functionality
Your app should include features, content, and UI that elevate it beyond a repackaged website.

2.5.6 Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript.

  • i.e. Apple is intentionally stalling the mobile Web on iOS by restricting the browser engine. Apple strategically underinvests in the mobile Web.

The Web can’t win when Apple sets the rules

JavaScript specifically taxes users at the lowest end the most

Phones aren’t getting faster, they are just getting cheaper

It’s time to give up on Responsive Design.

We have to start on phones and then scale up

small

Having money makes it possible to live and bear the Web today Not having (enough) money means you can’t get to it. JavaScript is a regressive tax on content. And it is our CO2. You have to have some of it.

When the Web is allowed to compete, it can win.

12 Likes
2

Nice talk. However, the provided trends and statistics only really matter if your project’s audience is “everyone”. And I’d argue that, at that point, you’ve already lost. :joy:

For instance, the meme at the end states that 80% of users cannot afford iPhones. Fine, but if my app is a B2B SaaS app then that statistic becomes completely irrelevant. The overwhelming majority of companies I’ve had as clients over the course of my consulting career paid for their employees’ phones (most of the time iPhones, high-end Android phones in one instance).

2 Likes
3

It all depends on the application. A good example is Grafana. It kinda works on mobile if you just want to have a quick view on the data, but some panels might be in a weird order. This kind of applications make no sense on a tiny mobile screen. Same goes for many other productivity applications.

I will never understand why people want to do everything from their phone. I can barely type on the touch keyboard.

If we are talking about content consumption, sure. Newspapers who bloat their websites with Javascript and with 90% of the space covered in ads shall just disappear.

6 Likes
4

The talk is about admitting the next generation of users onto the web - one can’t assume that the next generation “coming online” will use the web in the same way to solve day-to-day problems as we do today. Without “new blood” everything is lost - at that point the discussion turns to how much time the web has left before it becomes commercially extinct.

And one that isn’t essential to computing on the dominant platform of the day can be omitted be the next iteration hardware and software.
We don’t have to be included on every OS image. If you look at tvOS or watchOS, they weren’t there.

Web doesn’t have to be grandfathered in.

Apparently not everyone agrees:

As for the features you would like to see, it’s worth exploring if they couldn’t be done in a (mobile-optimized) progressive web app instead of a native app.

It’s natural to have your own preferences but it is important to recognize, identify and account for your own biases. Other people will be different.

If it was up to people like me, SMS messaging would have never found wide adoption.

  • Email already served my near instantaneous asynchronous communication needs
  • Typing text messages on a numeric keypad even with T9 seemed like a ludicrous workaround.

… and yet SMS messages came into widespread adoption.

As a software developer you are surrounded by keyboarded devices (and personally I wouldn’t want to go without them) but Alex Russell does explicitly state:

And this is the opportunity space, the set of internet users who have yet to come online. But those users in those markets don’t have iPhones.
They’re not buying the fastest, the highest end.
They’re not buying laptops generally speaking.
They’re not buying desktops.

It’s about keeping the Web relevant.

And so what this fundamentally means is that as long as we continue to make experiences this slow, this janky, this unwantable for our end users, we’re going to only get what we’ve got.
We’re in a hysteresis area.
That is to say, no one is going to come to the web who is not already using the web, because they already have the fast enough devices.
Folks who start from outside of this ecosystem won’t learn to want it.
We don’t make anything that will roll out the red carpet to them on average.

By not serving the low spec device users well, the web industry is essentially relinquishing the field to native apps which in turn is going reinvigorate the fragmentation of the markets by platform which really isn’t serving anyone on the user end.

The SPA movement was chasing the native-like experience but it fell into the same trap that native (and even desktop) apps have fallen into - massive bloat. However both desktop and native apps have been largely able to ignore this cost thanks to the shrinking of prices and size of persistent storage and memory. The Web (browser) can’t benefit from this directly, at least not without some additional help. It will be necessary to design new problem solving approaches that respect, not ignore, the constraints of the mobile web.

1 Like
5

While I agree with most of the talks of this kind, I find that most of them critic the status quo but very few give practical solutions.

Sure, it’s nice to be able to access the filesystem, face recognition, midi keyboard and that, but the “design for the cheapest devices” to stay relevant is vague, in fact the mobile first approach is vague and the line between “enough js to make it interactive” and “bloated website” blurred. Either your website has little to no js, or it’s completely “bloated”. And even if you design a very light website, the browser is doing a lot of crap in the background and hogging resources on it’s own anyway. Just trying to upload an image to a file input makes my phone reload the whole tab because it runs out of ram.

Also you should optimize the network use regardless of the client being mobile or desktop, a lot of people don’t have reliable internet connection.

If your app(and I mean a web app, not a port of a desktop tool like those photoshop clones or codesandbox) needs to be highly interactive to be relevant to the users, you will inevitably need to write a lot of js, and that impacts the bundle size and experience in low end devices. If such needed functionality can’t be achieved without javascript then all of that mobile first(or design for the lowest common denominator) movement becomes irrelevant.

Granted, there are A LOT of people using things like react with 5mb js bundles to show a slideshow and a contact form, that has to stop, but for legit use cases you either have to accept the bloat or write an ad hoc informally-specified bug-ridden slow implementation of half of some js framework.

The only practical advancement I’ve seen is svelte

2 Likes
6

Tonally, I think this is quite alarmist.

Practically, it is too vague and abstract, to the point where it cannot be effectively argued with and refuted.

2 Likes
7

One of the issues is that many believe that the mobile web is a solved problem.

What the talk emphasizes is that the approach using the current set of JS frameworks on high spec phones over idealized networks is just miniaturizing desktop style approaches which is fundamentally at odds with the physics of the mobile web.

In the end a lot of energy is being poured into these faux solutions - energy that isn’t being spent on finding and shaping the real, long-term solutions.

The issue is that on average the cores are getting slower (extending battery life is another issue) - but there will be more cores. Browsers can make use of multiple cores:

We have started to do massive projects at every browser engine vendor to rewire the way we work to make sure that we can take advantage of all of those cores.
We parse your images off the main thread.
We do as much parsing of JavaScript and CSS and everything else as we can off the main thread.
But when it comes too actually running your script we still do most of it on the main thread 'cause that’s where you asked us to run it.

But the it’s-just-JavaScript attitude of the current generation of tools makes it difficult to take advantage of these advances - making it necessary to make the runtime environment more complex by introducing JavaScript-based SSR, yet another band-aid to cover up earlier sins. CSS and (initial) HTML (in the form of templates) should be ready to go at deployment time - not rendered from nothing at runtime, even if that is done on the server side.

I think this is just one example of certain people and organizations wanting to be on the Web because of the reach it currently has while at the same time being unwilling to understand the Web (and its constraints).

MDN: Responsive Images

The facilities already exist to do the right thing - but in many cases people just can’t be bothered with these kind of details.

That is part of what Alex Russell calls the “privilege bubble” that many software developers experience.

A less inflammatory way of phrasing it is that one cannot assume that one’s own experience is representative. When making tools/products for others, one typically has to go out of one’s way to capture what experience is representative from the perspective of the prospective end user.

It’s the single page aspect of the SPA model that turned everything into a big ball of mud - it’s just another monolith.

SPA gave MPA a bad name. However designing a web application as set of pages, each with a highly focused responsibility and therefore a focused type of interactivity that may not need as much JS - at least not all in one place. Maybe if a page needs its own routing it is already doing too much.

Pages with focused responsibilities is where I see Service Worker API pointing to as the service worker can be automated to cache certain pages from the site on the device so that they are already available (the next time) even if the network is MIA.

I agree but as I stated elsewhere:

To my mind Svelte 3 is pointing in the right direction but as such is still flawed as it is an entirely JavaScript focused technology. The logical extension is a tool that outputs not just JavaScript but also platform independent templates for (initial) server rendered HTML and the supporting CSS.

That being said Rich Harris is a lot more knowledgable in the areas of visualzation and interactivity than most software (or web) developers - and I suspect that the most of the promising ideas will come from these kind of knowledge specialist turned developers rather than the “been there, done that - now how do I do the same thing over here” crowd.

It’s only alarmist for those people who still believe “the web is the future” come hell or high water and have a personal stake in it.

As long as the fate of the Web remains inherently coupled to the desktop mindset the truth may be closer to “this is as good as it gets - from now on things are only going to get worse”.

One of the issues is that most people in the industry primarily work with tools on desktop-like devices - so it’s only natural to have a desktop-centric mindset. It’s been well known that the desktop market has been stagnating and from a consumer perspective it’s turning toward a decline. Desktop devices are becoming less and less relevant to the average person.

Software developers will still use desktop-like devices as tools for some time to come but it wouldn’t surprise me if our “toys” are about to get more expensive again as the consumer market starts shrinking and more and more companies start to pull out of the desktop device market.

So the question is - will the decline of desktop take the Web with it?

Software developers need to be adaptable so one can always enter the market of native apps, backend whether it’s on-site or cloud; those opportunities aren’t going away any time soon and the Web will linger for some time to come - just like Cobol.

The reason why some people may seem alarmist is because whatever comes after the Web will likely not have the same reach as the Web has today - we’ll likely be thrown back to the much more insular communities that the Web has replaced.

There certainly is a sense of urgency because the Web is at an inflection point. There is a narrowing window of opportunity for the web to cross over to the new mobile user base but right now it looks like that opportunity is being squandered.

Despite the all time low web usage through mobile:

The same report also presents figures showing that it is much easier to reach a large audience on a mobile site than in a native app. There are close to 600 mobile web properties that reach audiences larger than 5 million visitors—nearly 4.5 times greater than the number of native apps with similar audiences. The top 1,000 mobile web properties have audiences that are almost 3 times the size of the top 1,000, apps and their audiences are growing twice as fast as native app audiences.

Majority of U.S. consumers still download zero apps per month, says comScore

i.e. there seems to be some end user resistance to store installed native apps (though once installed, they spend more time on them) - leveraging that resistance is the opportunity for the Web to transition to the mobile Web.

3 Likes
8

I have very hard feelings about this topic as both being a user and a developer on the frontend my experience is mostly frustrating. I really appreciate that you took the time and patience to reply to my comment.

This is also a problem for desktop, a lot of people have low end pc that can barely run youtube and facebook at the same time, the only difference being screen size and input method.

And because you often don’t have a choice. If you’re building a complex content creation tool there’s almost no way to leverage browser features to make it friendly to low end devices.

I completely agree, SSR “solutions” are just symptoms of a bigger illness.

When I said a file input, I meant a single file input in a page with no js at all. My phone specs are equivalent to a Nokia 2(4 cores, 1gb ram) and it runs out of memory if I don’t select the file quick enough. That isn’t a js problem, file inputs exist almost since forever. This isn’t a problem with native apps.

Not really. This issue is as true today as it was a decade ago with jQuery behemoths, back when SPAs weren’t even a thing. It’s a consequence of the complexity needed to add certain pieces of functionality and the overall irresponsibility of frontend developers. We just didn’t see it coming and now we’re violently hitting against a wall.
I agree, thought, that almost every spa out there doesn’t need to be an spa.

At some point in the talk he shows a chart with phone models and prices, and says that vendors are building cheaper devices because people demand cheaper devices. I think this is the wrong way to see it, to me people want vendors to lower their prices, not to make even lower end devices. Cheaper phones will only worsen issues like the file input one I mention above. For example, I bought my phone because I needed to use Whatsapp, and I can tell you, it’s painful to use it even for that. It almost feels like they make them cheap and bad for you to think “hey maybe I should just buy a better/more expensive phone”.

Given that most of those problems aren’t unique to the web but to the way client software is being developed overall(take a look at electron or some slow java programs), I don’t really understand where is everything going.

3 Likes
9

As a newcomer to this side of the ‘web industry’, for me it was worth the watch and irrespective of statistics etc. overall what is being said made sense to me. The fact that it doesn’t really focus on technologies and presents use of browsers, apps etc. and it’s his experience/insights, is more interesting to me.

Thanks for the link.

1 Like
10

I can empathize at least with the developer end.

It can really sometimes feel like the developer mindset gets in the way when trying to deal with the concepts behind markup flow, styling structure, layout, UX design, and information architecture. There is the recurring assertion that Design is About Solving Problems (Design For Developers - though there is also Design is not Problem Solving) but problem solving skills routinely applied in automation don’t get you anywhere when you are trying to address “design problems”.

This is why I’m wondering whether the developer mentality is contributing to some of the problems in the web space. As a developer I am prone to hide things I don’t want to continually deal with behind libraries, toolkits and tools but this can become problematic if I

  • wrap things I don’t understand
  • use other developers wrappers of stuff I don’t want to understand (while trusting that the authors of that wrapper sufficiently understand what they are wrapping to produce a competent wrapper to begin with)

People want to approach web applications via something like 4GLs when in fact dealing with a web browser may require adopting the same scarcity mindset as that of an embedded system developer.

I think there are very few if any performance standards when it comes to today’s digital devices. And even if the hardware specs look good, any architectural shortcomings can waste all sorts of potential.

I’m not saying you are wrong - but in every case I’m wondering if there might be a different way to break down that complexity to make it workable on low spec devices.

That being said I’m not sure how much you can accomplish on the 240 x 320 display on a Jio Phone (or 320 x 240 on the Jio Phone 2 - neither of which have a browser by default).

Is it perhaps a problem that the browser was implemented for a higher spec device?

Those jQuery behemoths were artifacts of the desktop era mostly using jQuery as a compatibility layer. jQuery really didn’t offer much in the way of complexity management. I think it is simply a human failing to prefer to add to something that already exists rather than starting something new - be it adding a few more methods to an existing class or a few more features to an existing page.

Not saying that some vendors don’t overcharge for their products but there is a real limit to how much can be offered for “a little” money.

Also in some markets consumers don’t even buy the device directly but it is included in the subscription contract - to my mind that puts pressure on subscription prices to go up (to cover the cost of the device - and then some) and wholesale device prices to go down (to minimize the cost to the service provider) which has a tendency to result in a drop in quality and performance.

Is that via a native app or via web.whatsapp.com (This is why WhatsApp Web sucks so hard (2015))?

I’ve noticed that WhatsApp seems to be popular in regions where low spec phones seem to be more common - is it because SMS is still too expensive there or because of its global reach?

Somebody published WebWhatsapp-Wrapper - it would be an interesting design study to have a mobile web (designer) evangelist create a low spec friendly UI for Web WhatsApp - think a Phoenix installation making the necessary wrapper calls while using EEx with lean-and-mean JS for the UI - of course that is never going to happen because they all hate Facebook.

There is likely a lot of that going on.

I see it all coming from “developer time is expensive” (which sometimes manifests like this).

Even outside the web, inside the corporate world it is not that uncommon for internal applications to be pushed into service even when it is clear that the end users hate and loath them - because nobody could be bothered to determine what has to happen for their goals to be hit in a smooth and efficient manner, and/or the because the low pay of the developers reflects their competency, and/or because all of this had to be delivered yesterday anyway.

So in order to deliver on time (and possibly with minimal expertise), products are aggregated from pre-fabricated (and sometime massively bloated) units of capability - and that approach seems to fail the mobile web.

The thing is, nobody is claiming that it is easy to develop for the mobile web, in fact quite the opposite. For the time being there is no mobile web toolkit - right now a lot of detail knowledge is required: low level web technologies, how the web works, how to automate browsers directly, what the shortcomings of some of the mobile browsers are and what tactics are required to be resilient in the face of these shortcomings - not to mention how to use a small display effectively.

2 Likes
11

Probably. Android itself seems to be implemented for higher spec devices than the ones it actually runs on. Vendors put a custom version of the latest android on a cheap device so that people buy it thinking it’s good because of the android version.

Via native, but the problem isn’t with whatsapp per se, it’s that even for that app the phone is painful to use.
The problem with this kinds of phones is the hardware(unresponsive touchscreens) and broken custom firmware provided by vendors(not to mention Android alone eats between 300 and 600mb of ram on idle which is a lot for a 512mb or 1gb ram device). Rooting and installing custom software is an option but non tech people don’t know how to do it.
At that point I don’t know how can you provide a good experience to cheap phones users when the phones themselves are flawed.

I’d say both. In many cases whatsapp is the only way to reach people because they use nothing else, even if that costs them money for the data consumption(though there are plans that include free whatsapp).

Back to the main topic, earlier you said(emphasis mine):

And also:

The Web is … the content that is currently reachable by following links and which can be experienced on most devices

I’ve been thinking about for quite a while but I’ve been unable to give shape to those thoughts. We want an universal way to create and share content and experiencies(kind of reminds me of the BYOND engine), but we also want to compete with the native app capabilities in terms of complex ui.
The browser has to do a lot of work to run scripts that enhance the webpage, ultimately degrading performance, and also hurting discoverability(aka SEO), which is the major advantage the web has over native apps(bots can’t crawl content accesible only via native apps).

We’re trying to fill the gap between native and web, but they are funtamentally two completely different things. Is this “gap” what you refer to as the mobile web?

12

Trying to fill the gap between native and web - at least as far as I’m concerned - is exactly what SPAs were attempting. However the hypothesis here is that the approach isn’t sustainable in the mobile space where high spec devices (and high quality networking) - on average - will be far less common than they currently are in many western markets and more specifically in the hands of the individuals currently participating in the western web industry (expectation of access to a quality, consistent and high speed network is another issue).

The mobile web is simply the web universally accessible and reasonably usable from mobile devices across a wide spectrum of device performance characteristics.

but they are fundamentally two completely different things.

I think that is the real issue here.

I remember going from “awful, primitive web frontends” straight to SPAs - I suspect in an attempt to simply leverage existing UX expertise from the native world - when in fact the development of entirely new design solutions were needed.

Places like http://www.csszengarden.com are great to show off design and layout capabilities but something similar is needed to show off simple (lean-on-JS) and effective interaction patterns (which if they compose well with others, so much the better) for the web, particularly those that work well on smaller-than-desktop screens.

In terms of the opportunities to enable the mobile web - browsers have over the past few years acquired some capabilities that were historically reserved for native apps - the Web APIs are usually referenced in connection to Progressive web apps.

  • With user permission web sites can be added to the home screen - and hypothetically an installed web app should have a much smaller storage footprint than a native app of equvalent capability.

  • With user permission they are capable of push notifications.

caniuse: Web App Manifest

In the simplest case the service worker acts as a proxy to the actual web site and in that position can cache key request/responses from the site that are available even when there is no network connection.

For example if you have a web page that lists your latest 10 messages the service worker can cache that page for later access. So if that page was fully rendered on the server and cached by the service worker, the “latest 10 messages” should be available almost instantaneously offline or not (typically a script will check for a fresher copy if the network is available and force a refresh once that copy is cached; of course a response with the supporting JavaScript can be cached as well but should be kept lean for obvious reasons).

caniuse: Service Worker

Furthermore you can store user actions inside IndexedDB while the page is offline (likely in combination with Optimistic UI) and synchronize them later when the network is available again. In this case the event-based asynchronous interface is a bit strange but can be converted to a promise-based interface (enabling the use of async/await if that is your thing) with the relatively tiny idb.

caniuse: IndexedDB

2 Likes
13

Betteridge’s law of headlines:

Any headline that ends in a question mark can be answered by the word “no”.

4 Likes
14

There are semi-technology factors to consider, getting addicted to small screen devices everywhere we go, I personally believe that is unhealthy. People do not like to keep Slack/company chat on their phone because they do not like anxiety from possible emergency. And for daily usage, there are a few type of app I would like to use while on the train if not use it at all. So what is the real mobile usage story for the “new blood”, I’d guess it’s TikTok kind of thing. Majority usage of business app will still be on desktop for me where I feel like it is a place to work on something seriously. Stagnant of app stores is another story. I could be wrong completely, but it’s hard to say.

2 Likes
15

One of Alex Russell’s earlier talks (2016-01-24) was titled:

The Future of the Web Platform: Does It Have One?

Little did I know that this topic title was actually more optimistic.

https://twitter.com/slightlylate/status/1181304390138753024

… from his point of view iOS (Safari/WebKit) is holding the web back - just like IE6 once was.

Though frankly other people have a different association with IE6 - browser monopoly:

16

This is a very apples-to-oranges comparison. Some of the standards that Apple is not in a rush to implement are of a very questionable value.

As you yourself said many times on this forum, a lot of the modern Web standards – and, by extension, JS itself – are solutions looking for problems. And nowadays many serious security researches are starting to notice a lot of gaping holes in people’s personal devices. The “run fast and break things” mentality has gone unchecked in the IT area for way too long.

I am pretty sure Apple is just being stubborn here and there, but for the most part I am actually with them on this topic – most of the modern Web standards are pretty meh and we can all do without them just fine.

Finally, the fact that Google pushes everyone to optimise their websites for Chrome shouldn’t make people angry at Firefox or Safari for not implement a plethora of “standards” aimed at crippling the browser competition. But alas, that’s exactly what’s happening pretty often.

P.S.: These days, the QUIC protocol is pretty much the only thing I like Google for. And I am still cautiously optimistic since I fear we might realise they rigged it to rat your personal data through sophisticated server tuning one day.

17

In this particular case he is referring to the web standards as they relate to Progressive Web Apps and Web Components (which in many cases have already been implemented by Mozilla in Firefox). In combination with Apple not allowing third party browsing engines on iOS (Chrome on iOS isn’t Chrome), it looks like Apple is strategically trying to give the walled garden of the App Store (and therefore native apps) any possible advantage.

18

Oh, it definitely does look that way, I agree. And it might be the only motive after all. But I am also saying it’s not as black and white as many Apple haters make it out to be.

A lot of the recent “progress” in Web standards by Google have been very obvious attempts to corner Firefox and Safari, and not a true progress that benefits Web consumers in almost any way.

19

But I am also saying it’s not as black and white as many Apple haters make it out to be.

I don’t think it’s about Apple hate - it has more something to do with trying to manipulate Apple loyals into downloading more native apps and businesses being nudged towards the additional expense of supporting an iOS native app besides their company web site/app (not a problem if you are Facebook - and some businesses seem to need a tighter leash on them).

Right now Safari iOS has become the lowest common denominator in terms of browser capability which is significant as it limits what the mobile web can broadly do on the high end.

This is the type of atmosphere that historically gave rise to jQuery as a platform homogenizer. However that was during the desktop age. Now in the mobile age the last thing we need is more boilerplate JavaScript. And while something WebAssembly based may require a smaller download that would just lead to standardization outside of the standards.

A lot of the recent “progress” in Web standards by Google have been very obvious attempts to corner Firefox and Safari, and not a true progress that benefits Web consumers in almost any way.

One should never lose sight of the fact that targeted adverts are Google’s money maker. To that end the browser is an advert projector and usage data collector.

But lets face it, advert driven content creation is the business model that US TV networks have been exploiting for decades. That is Google’s business on the web (only much more targeted - though it’s Amazon which is really using the data it has access to quite effectively/ruthlessly) and that is what is paying for the browser development.

Google AMP is pretty much seen as an attempt to take control of the web as a whole.

But fortunately in the browser department Mozilla is still acting as a competent alternate opinion and for the time being the communication between the Chrome and Firefox teams seems pretty good.

2 Likes
20

The main thread is overworked & underpaid

3 Likes