The Modern FrontEnds conference was held last week in London. It wasn’t a small conference, as the website touts over 100 speakers and more than 3000 developers attending. Not only that, the conference had some big sponsors and a hefty ticket price. 

But before the conference even began, I heard about some serious issues with how the organisers treated their speakers. That immediately raises some red flags. After the event, some speakers spoke publicly about their experiences. 

Now, I wasn’t there. I spoke at a different event in London the day before. But I chatted with some of the Modern FrontEnds speakers about this. And it still feels weird commenting about a conference I did not speak at or even attend. So I am not going to do that.

Continue reading “Red flag: Speakers having to cover their own travel”

I bought an Apple Studio Display. But unlike most people, I intend to use it for my Windows machine, which does not make much sense but hear me out.

I run Mac and Windows because I develop software for both Mac and Windows and am currently using an ageing iMac Pro and a pretty good HP Elitedesk Mini connected to an awful Samsung M7 display. The only thing okay about that monitor is its size and resolution: 4K at 32 inches, but otherwise, it is terrible.

Once the Mac Studio becomes available again, I intend to buy one to replace my iMac Pro. But I had the opportunity to order one for pickup on day 1 of the Studio Display launch date. So I did. I figured I could use it for my upcoming Mac Studio, but in the meantime, it would be an excellent replacement for that terrible Samsung display. And now that I tried it, I think I might need to buy another Studio Display for the Mac Studio. I am now spoilt, and there is no way to return to that awful Samsung display.

Continue reading “Using the Apple Studio Display on a Windows machine”

Lately, web developers have begun to question Apple’s monopoly over browser rendering engines on iOS. The App Store rules force browsers on iOS to use the same rendering engine as Safari instead of using their own, as they do on every other platform, including macOS. I’ve written about this before and why this is a problem.

Even some market regulators have picked up on this sentiment. And last year, the British CMA published a preliminary report which may result in rules being imposed on Apple to force them to allow other rendering engines.

But I’ve also seen some responses that argue that having less choice is good for users. Apparently, iOS is the last bastion of WebKit that can prevent a Chromium monoculture. And if we allow Chromium on iOS, WebKit will be doomed, and we will end up with Chromium everywhere.

Continue reading “Why Safari does not need any protection from Chromium”

About a year ago, Apple released a list of Web API’s they were not going to implement in Safari due to privacy and security issues. They worried that these API’s were going to allow fingerprinting and tracking of users. And that is, of course, a big privacy no-no. Sounds reasonable, right? 

But what kinds of API’s were actually on that list? Well, among others, the hardware APIs that have been shipping in Chrome and Edge during the last couple of years: WebBluetooth, WebHID, WebMidi, WebNFC, WebSerial and of course WebUSB. Those sounds really dangerous, right?

Continue reading “Hardware and the web: the balance between usefulness, security and privacy”

If you go to the App Store on your iPhone, there are many browsers to choose from. And with the latest version of iOS, you can even set these browsers as the default browser. So why are some people complaining about browser choice on iOS?

You may not realise that all browsers on iOS are required to use the same rendering engine as Safari. On other platforms, this is not the case.

Take, for example, Chrome. On Android, Windows and even macOS, they are using the Chromium rendering engine. But on iOS, it is using WebKit. Or look at Firefox, which uses the Gecko rendering engine on all platforms. Except on iOS, where it uses WebKit.

Continue reading “Chrome is the new Safari. And so are Edge and Firefox.”

It is not difficult to find some incredibly shitty takes on Electron, and every time it boils down to: It’s slow. Downloads are huge, and it uses a lot of memory. Electron apps are just websites. Developers that are using Electron are taking the lazy or easy approach to cross-platform development. Native apps are just better in every single way. 

And somehow, these arguments often come from Apple fans when they discover one of their apps isn’t “native” or when a macOS favourite is considering moving to Electron. How dare they!

And on the surface, I agree with pretty much everything that people say about Electron. And at the same time, I don’t care at all. And neither should you.

Continue reading “Why Electron apps are fine”

I love conferences. I love learning about new developments in our community. I love being able to talk to the speakers and other attendees. Conferences have allowed me to grow as a developer and improve myself. I visited conferences long before I started speaking. And the last couple of years I even became involved in organising one.

So far, this year has not been easy for conferences. And it is only March. 

With the novel coronavirus spreading we’ve seen several conferences moving to an online format, postponing or even outright cancelling. For conference organisers, everything is up in the air. And that is okay. There are more important things than conferences right now.

Continue reading “Cancelling conferences in the face of novel coronavirus”

With Progressive Web Apps, you can now use the web to build full-blown apps. Thanks to an enormous amount of new specifications and features, we can do things with the web that you used to need to write native apps for. However, talking to hardware devices was still a bridge too far up till now. Thanks to WebBluetooth, we can now build PWAs that can control your lights, drive a car or even control a drone.

Read more at Smashing Magazine…

What was a major annoyance during the development and especially the debugging of my WebBluetooth demos has now turned into a real proposal to extend the console API in the developer tools for all browsers. It is still early, so this may never really happen, but so far the response has been fantastic.

Continue reading “The case for console.hex()”

Last Friday was a bit unreal. I find myself on stage at HalfStack talking about WebBluetooth. A couple hundred people look at me and listen to me. When it’s time to show some really cool demos, I explain that this is experimental technology and may not work. No, I explain, it will probably not work. And that was not a lie. In fact, before I started the talk I knew there was a very large chance the demos would not work. And indeed, none of the demos worked. Complete and utter demo failure.

Continue reading “Complete and utter demo failure”