Journal tags: cma

The Competition and Markets Authority (CMA) recently published an interim report on their mobile ecosystems market study. It’s well worth reading, especially the section on competition in the supply of mobile browsers:

On iOS devices, Apple bans the use of alternative browser engines – this means that Apple has a monopoly over the supply of browser engines on iOS. It also chooses not to implement – or substantially delays – a wide range of features in its browser engine. This restriction has 2 main effects:

• limiting rival browsers’ ability to differentiate themselves from Safari on factors such as speed and functionality, meaning that Safari faces less competition from other browsers than it otherwise could do; and
• limiting the functionality of web apps – which could be an alternative to native apps as a means for mobile device users to access online content – and thereby limits the constraint from web apps on native apps. We have not seen compelling evidence that suggests Apple’s ban on alternative browser engines is justified on security grounds.

That last sentence is a wonderful example of British understatement. Far from protecting end users from security exploits, Apple have exposed everyone on iOS to all of the security issues of Apple’s Safari browser (regardless of what brower the user thinks they are using).

The CMA are soliciting responses to their interim report:

To respond to this consultation, please email or post your submission to:

Email: mobileecosystems@cma.gov.uk

Post: 


Mobile Ecosystems Market Study
Competition and Markets Authority

25 Cabot Square

London

E14 4QZ

Please respond by no later than 5pm GMT on 7 February 2022.

I encourage you to send a response before this coming Monday. This is the email I’ve sent.

Hello,

This response is regarding competition in the supply of mobile browsers and contains no confidential information.

I read your interim report with great interest.

As a web developer and the co-founder of a digital design agency, I could cite many reasons why Apple’s moratorium on rival browser engines is bad for business. But the main reason I am writing to you is as a consumer and a user of Apple’s products.

I own two Apple computing devices: a laptop and a phone. On both devices, I can install apps from Apple’s App Store. But on my laptop I also have the option to download and install an application from elsewhere. I can’t do this on my phone. That would be fine if my needs were met by what’s available in the app store. But clause 2.5.6 of Apple’s app store policy restricts what is available to me as a consumer.

On my laptop I can download and install Mozilla’s Firefox or Google’s Chrome browsers. On my phone, I can install something called Firefox and something called Chrome. But under the hood, they are little more than skinned versions of Safari. I’m only aware of this because I’m au fait with the situation. Most of my fellow consumers have no idea that when they install the app called Firefox or the app called Chrome from the app store on their phone, they are being deceived.

It is this deception that bothers me most.

Kind regards,

Jeremy Keith

To be fair to Apple, this deception requires collusion from Mozilla, Google, Microsoft, and other browser makers. Nobody’s putting a gun to their heads and forcing them to ship skinned versions of Safari that bear only cosmetic resemblance to their actual products.

But of course it would be commercially unwise to forego the app store as a distrubution channel, even if the only features they can ship are superficial ones like bookmark syncing.

Still, imagine what would happen if Mozilla, Google, and Microsoft put their monies where their mouths are. Instead of just complaining about the unjust situation, what if they actually took the financial hit and pulled their faux-browsers from the iOS app store?

If this unjustice is as important as representatives from Google, Microsoft, and Mozilla claim it is, then righteous indignation isn’t enough. Principles without sacrifice are easy.

If nothing else, it would throw the real situation into light and clear up the misconception that there is any browser choice on iOS.

I know it’s not going to happen. I also know I’m being a hypocrite by continuing to use Apple products in spite of the blatant misuse of monopoly power on display. But still, I wanted to plant that seed. What if Microsoft, Google, and Mozilla were the ones who walk away from Omelas.

ES6 introduced a whole bunch of new features to JavaScript. One of those features is the class keyword. This introduction has been accompanied by a fair amount of concern and criticism.

Here’s the issue: classes in JavaScript aren’t quite the same as classes in other programming languages. In fact, technically, JavaScript doesn’t really have classes at all. But some say that technically isn’t important. If it looks like a duck, and quacks like a duck, shouldn’t we call it a duck even if technically it’s somewhat similar—but not quite the same—species of waterfowl?

The argument for doing this is that classes are so familiar from other programming languages, that having some way of using classes in JavaScript—even if it isn’t technically the same as in other languages—brings a lot of benefit for people moving over to JavaScript from other programming languages.

But that comes with a side-effect. Anyone learning about classes in JavaScript will basically be told “here’s how classes work …but don’t look too closely.”

Now if you believe that outcomes matter more than understanding, then this is a perfectly acceptable trade-off. After all, we use computers every day without needing to understand the inner workings of every single piece of code under the hood.

It doesn’t sit well with me, though. I think that understanding how something works is important (in most cases). That’s why I favour learning underlying technologies first—HTML, CSS, JavaScript—before reaching for abstractions like frameworks and libraries. If you understand the way things work first, then your choice of framework, library, or any other abstraction is an informed choice.

The most common way that people refer to the new class syntax in JavaScript is to describe it as syntactical sugar. In other words, it doesn’t fundamentally introduce anything new under the hood, but it gives you a shorter, cleaner, nicer way of dealing with objects. It’s an abstraction. But because it’s an abstraction taken from other programming languages that work differently to JavaScript, it’s a bit of fudge. It’s a little white lie. The class keyword in JavaScript will work just fine as long as you don’t try to understand it.

My personal opinion is that this isn’t healthy.

I’ve come across two fantastic orators who cemented this view in my mind. At Render Conf in Oxford earlier this year, I had the great pleasure of hearing Ashley Williams talk about the challenges of teaching JavaScript. Skip to the 15 minute mark to hear her introduce the issues thrown up classes in JavaScript.

More recently, the mighty Kyle Simpson was on an episode of the JavaScript Jabber podcast. Skip to the 17 minute mark to hear him talk about classes in JavaScript.

(Full disclosure: Kyle also some very kind things about some of my blog posts at the end of that episode, but you can switch it off before it gets to that bit.)

Both Ashley and Kyle bring a much-needed perspective to the discussion of language design. That perspective is the perspective of a teacher.

In his essay on W3C’s design principles, Bert Bos lists learnability among the fundamental driving forces (closely tied to readability). Learnability and teachability are two sides of the same coin, and I find it valuable to examine any language decisions through that lens. With that mind, introducing a new feature into a language that comes with such low teachability value as to warrant a teacher actively telling a student not to learn how things really work …well, that just doesn’t seem right.