Tags: mobi

319

sparkline

The “Developer Experience” Bait-and-Switch | Infrequently Noted

JavaScript is the web’s CO2. We need some of it, but too much puts the entire ecosystem at risk. Those who emit the most are furthest from suffering the consequences — until the ecosystem collapses. The web will not succeed in the markets and form-factors where computing is headed unless we get JS emissions under control.

Damn, that’s a fine opening! And the rest of this post by Alex is pretty darn great too. He’s absolutely right in calling out the fetishisation of developer experience at the expense of user needs:

The swap is executed by implying that by making things better for developers, users will eventually benefit equivalently. The unstated agreement is that developers share all of the same goals with the same intensity as end users and even managers. This is not true.

I have a feeling that this will be a very bitter pill for many developers to swallow:

If one views the web as a way to address a fixed market of existing, wealthy web users, then it’s reasonable to bias towards richness and lower production costs. If, on the other hand, our primary challenge is in growing the web along with the growth of computing overall, the ability to reasonably access content bumps up in priority. If you believe the web’s future to be at risk due to the unusability of most web experiences for most users, then discussion of developer comfort that isn’t tied to demonstrable gains for marginalized users is at best misguided.

Oh,captain, my captain!

Tools that cost the poorest users to pay wealthy developers are bunk.

Chrome’s NOSCRIPT Intervention - TimKadlec.com

Testing time with Tim.

Long story short, the NOSCRIPT intervention looks like a really great feature for users. More often than not it provides significant reduction in data usage, not to mention the reduction in CPU time—no small thing for the many, many people running affordable, low-powered devices.

Disable scripts for Data Saver users on slow connections - Chrome Platform Status

An excellent idea for people in low-bandwidth situations: automatically disable JavaScript. As long as the site is built with progressive enhancement, there’s no problem (and if not, the user is presented with the choice to enable scripts).

Power to the people!

Google AMP - A 70% drop in our conversion rate. - Rockstar Coders

Google hijacking and hosting your AMP pages (in order to pre-render them) is pretty terrible for user experience and security:

I’m trying to establish my company as a legitimate business that can be trusted by a stranger to build software for them. Having google.com reeks of a phishing scam or fly by night operation that couldn’t afford their own domain.

Joymaker by Frederik Pohl from The Age of The Pussyfoot

From Frederik Pohl’s 1966 novel:

The remote-access computer transponder called the “joymaker” is your most valuable single possession in your new life. If you can imagine a combination of telephone, credit card, alarm clock, pocket bar, reference library, and full-time secretary, you will have sketched some of the functions provided by your joymaker.

Essentially, it is a transponder connecting you with the central computing facilities of the city in which you reside on a shared-time, self-programming basis.

Altering expectations by improving PWA on iOS | Responsive Web Design

Justin responds to a post of mine which was itself a response to a post by Luke.

I love having discussions like this!

The Cost Of JavaScript In 2018 – Addy Osmani – Medium

Addy takes a deep, deep dive into JavaScript performance on mobile, and publishes his findings on Ev’s blog, including this cra-yay-zy suggestion:

Maybe server-side-rendered HTML would actually be faster. Consider limiting the use of client-side frameworks to pages that absolutely require them.

General Magic

A forthcoming documentary about the company spun out of Apple to create a handheld communication device …in 1990.

From mobile computing, social media, downloadable apps and e-commerce to touchscreens, emoji and USB, the products and services that now dominate the tech industry and our day-to-day lives were born at General Magic.

The Official NoPhone Store

Like a nicotine patch for your phone hand.

#davewentandroid - daverupert.com

Yeah. Fuck this. That’s creepy. Technically I opted into this feature because Google Maps asked “Google Maps would like to know your location, YES or NO?” Of course my answer was “YES” because, hey, it’s a fucking map. I didn’t realize I consented to having my information and location history stored indefinitely on Google’s servers.

I began all the work of disabling this “feature” but it seemed like a fruitless task. Also worth noting, Google Maps for iOS keeps Location History as well.

Winning on Mobile

This looks like a handy tool for doing some quick’n’dirty competitor analysis when it comes to performance: create a scoreboard of sites to rank by speed (and calculate the potential revenue impact).

Many factors contribute to an engaging mobile experience. And speed is chief among them. Most people will abandon a mobile site visit if the page takes more than a few seconds to load. Use our Speed Scorecard to see how your site stacks up to the competition.

The Two Faces of AMP - TimKadlec.com

So, to recap, the web community has stated over and over again that we’re not comfortable with Google incentivizing the use of AMP with search engine carrots. In response, Google has provided yet another search engine carrot for AMP.

This wouldn’t bother me if AMP was open about what it is: a tool for folks to optimize their search engine placement. But of course, that’s not the claim. The claim is that AMP is “for the open web.”

Spot on, Tim. Spot on.

If AMP is truly for the open web, de-couple it from Google search entirely. It has no business there.

Look, AMP, you’re either a tool for the open web, or you’re a tool for Google search. I don’t mind if you’re the latter, but please stop pretending you’re something else.

Can You Afford It?: Real-world Web Performance Budgets – Infrequently Noted

Alex looks at the mindset and approaches you need to adopt to make a performant site. There’s some great advice in here for setting performance budgets for JavaScript.

JavaScript is the single most expensive part of any page in ways that are a function of both network capacity and device speed. For developers and decision makers with fast phones on fast networks this is a double-whammy of hidden costs.

Microsoft Edge for iOS and Android: What developers need to know - Microsoft Edge Dev Blog

This is such a strange announcement from Microsoft. It’s worded as though they chose to use the WebKit engine on iOS. But there is no choice: if you want to put a browser on iOS, you must use the WKWebView control. Apple won’t allow any other rendering engine (that’s why Chrome on iOS is basically a skin for Safari; same for Opera on iOS). It’s a disgraceful monopolistic policy on Apple’s part.

A word to the Microsoft marketing department: please don’t try to polish the turd in the shit sandwich you’ve been handed by Apple.

When the news goes sideways – James Donohue – Medium

The BBC has been experimenting with some alternative layouts for some articles on mobile devices. Read on for the details, but especially for the philosophical musings towards the end—this is gold dust:

Even the subtext of Google’s marketing push around Progressive Web Apps is that mobile websites must aspire to be more like native apps. While I’m as excited about getting access to previously native-only features such as offline support and push notifications as the next web dev, I’m not sure that the mobile web should only try to imitate the kind of user interfaces that we see on native.

Do mobile websites really dream of being native apps, any more than they dreamt of being magazines?

Understanding the WebView Viewport in iOS 11 - Ayogo Health Inc.

One more reason not to use sticky headers on mobile.

Removing the White Bars in Safari on iPhone X

You could add a bunch of proprietary CSS that Apple just pulled out of their ass.

Or you could make sure to set a background colour on your body element.

I recommend the latter. Because reasons.

Betting on the Web

Along the lines of John’s recent post, Henrik makes the business case for progressive web apps.

He also points out how they can be much better than native apps for controlling hardware.

They can be up and running in a fraction of the time whether or not they were already “installed” and unlike “apps” can be saved as an app on the device at the user’s discretion!

Essentially they’re really great for creating “ad hoc” experiences that can be “cold started” on a whim nearly as fast as if it were already installed.

Left to our own devices. — Ethan Marcotte

Your website’s only as strong as the weakest device you’ve tested it on.

Daring Fireball: Scott Gilbertson: ‘Kill Google AMP Before It Kills the Web’

If you are a publisher and your web pages don’t load fast, the sane solution is to fix your fucking website so that pages load fast, not to throw your hands up in the air and implement AMP.

Pretty strong meat there from Gruber.

(I’m not going to link through to the Register article though—that rag does not deserve our attention.)