Apple takes course for PWAs | Frontend Weekly vol. 126

1. A pack of new features in Safari

TLDR:

Web Push Notifications are heading to Safari 16.4
Web Push Notifications will only work for apps added to the home screen.
Adding apps to the home screen will be still hidden in a hard-to-reach place.
Users will manage PWAs settings in the same place as native apps.
There are quite a few new APIs coming to the Safari: Badge API, WakeLock API, UserActivation API, ScreenOrientation API and others.

In the context of Safari and PWA apps, Apple has recently undergone a massive change. For years, Safari was considered the Internet Explorer of our time, and developers were constantly complaining about missing functionality and minor glitches. Interop 2022, is a set of tests developed by Google, Mozilla and Apple to unify browser APIs. In this ranking, Safari ended the year with a sizable lead over Chrome and Firefox, and announced that it would continue to work on getting the best out of Interop 2023. It looks like these were not empty words. Last week we saw the release of the iOS 16.4 beta and iPadOS 16.4 beta. Alongside new operating systems we go new Safari. The list of changes and new features is really long – the longest in years.

Probably nothing pic.twitter.com/n0OUWQAwdo
— Guillermo Rauch (@rauchg) February 19, 2023

The biggest news from iOS 16.4 is support for Web Push Notifications. Why did Apple delay implementing this fundamental functionality for so long? Officially, it was for the interest of users. However, an alternative theory is circulating in developers community. Apple charges a hefty commission on every transaction in AppStore, and fully developed PWA apps would be a way to avoid the this “Apple Tax”. Apple can remove Fortnite from App Store if it’s not following the rules, but it has no power to remove it from the Internet.

So what has changed? To begin with, in recent years Apple has been developing a branch of subscription services like Apple Music or Apple TV. The successfull subscription model means they can slowly start moving away from a commission-based model. Another important factor might be European Union’s Digital Markets Act, which aims to increase competition in European digital markets by preventing large companies from abusing their market power. There is speculation that the act will force Apple to add a USB-C port to the iPhone and to allow alternative app stores on iOS. If this speculation proves true, Apple’s arguments against the PWA will automatically disappear.

Are we in for a renaissance of PWA applications? Unfortunately, I have to cool down the optimistic mood. Support for Web Push Notifications comes with an asterisk – it will only work if the app has been added to the home screen. At first glance, this doesn’t sound alarming, but adding an app to the home screen is still hidden in the least intuitive place you can imagine – in the menu that appears when you click the Share button. Sure, you can include a proper tutorial in your app, but I’m afraid anything above “One-Click Install” will discourage most users.

I have to admit one thing – with the implementation of Web Push Notifications Apple really took care of their users. We will control the settings of apps added to the home screen in the same way we control settings for native apps. Also, the range of settings (fous mode, grouping, style etc.)will be the same. Thus, the difference between PWAs and native apps should be unnoticeable.

Support for Web Push Notifications is also accompanied by a number of smaller support features. Starting with iOS 16.4, it will be possible to control the badge displayed next to the app. The way the app icon is generated will also change. Until now, if developers did not provide special apple-touch-icons, a screenshot of the page served as the icon. From now on, in the case of basence of apple-touch-icons, data from manifest.json will be used. When this data is also missing, the initials of the application name will be used as the icon.

That’s not the end of what’s new. iOS 16.4 comes with Wake Lock API, which allows you to delay locking the screen if you’re currently performing a long operation that doesn’t require user interaction, Screen Orientation API, which lets you know what orientation the phone is currently in, and User Activation API, which lets you know if users is currently using an application. For a minor version of the browser, there are a lot of novelties here.

2 Is this the end of RxJS? Angular is working on a new reactivity model

TLDR:

For the last year the Angular has been working on an optional zone.js cut-out. The first step in this direction is a new reactive primitive: Signals.
We will see the first Developer Preivew of Signals in early May in Angular 16. The first RFC should land in the coming weeks.
You may recognise Signals from other frameworks such as SolidJS or Vue.
Singals are much simpler than RxJS and resemble the hooks from React.
RxJS works best for handling events spread over time. Signals work best for managing application state.

For the long time Angular team have been working on an option to cut-out zone.js – the library fundamental for the framework. zone.js is responsible for monkey-patching native browser methods (for example click or fetch) so that Angular can respond to user interactions and asynchronous events. Without zone.js we couldn’t imperatively change the variable and expect it to automatically refresh in the user interface. Unfortunately, zone.js is also one of the most common reason for performance problems. It’s not surprising that the Angular team is actively exploring some alternatives.

The first step towards removing zone.js is an introduce of a new reactive primitive: Signals. You may recognize this primitive from other frameworks like Vue (the Reactivity API from Vue 3 can be considered an implementation of Signals), SolidJS (useSignal() is the default way to manage state there), or the numerous libraries for React (the most popular is the one created few months ago by the creator of Preact).

You can think about Singnal like a “box” for the value. We can insert new content into the box, but the box itself remains the same. We can also create “matryoshkas” out of the boxes. – Whenever a value changes in any box, it will automatically change in the other boxes as well. We can listen for changes in the box contet, or simply check what is the currently in the box.

const counterA = signal(2);
const counterB = signal(5);
const sumOfCounterAandB = computed(() => counterA() + counterB());

const sideEffect = effect(() => 
    console.log(`Sum is: ${sumOfCounterAandB()}`
);                                // Console output: Sum is: 7
counterA.set(3);                  // Console output: Sum is: 8
console.log(sumOfCounterAandB()); // Console output: Sum is: 8
counterB.set(10);                 // Console output: Sum is: 13

More about signals:
📝 Signal – a new way to manage application state | Frontend Weekly vol. 104
📝 Preact – Introducing Signals
📝 SolidJS – Introducing Signals

Because the reference to our box never changes, aggressive rendering optimization is possible. The template observes changes in the boxes and refreshes the HTML accordingly. Components at any level can observe the contents of the boxes, so we avoid the situation where a state change at the root of the tree refreshes the entire tree. We also have a built-in mechanism for subscribing to changes, so zone.js is no longer necessary.

If you’re using Angular on a daily basis, some questions has probably already crossed your mind. How is it actually different from RxJS? Why we need to provide yet another primitve to the framework? The above snippet can finally be rewritten as follows:

const counterA$ = new BehaviourSubject(2);
const counterB$ = new BegaviourSubject(5);
cost sumOfCounterAandB$ = combineLatest([counterA$, counterB$]).pipe(shareReplay(1));

const getSum = async () => `Sum is: ${await firstValueFrom(sumOfCounterAandB$)}`;

sumOfCounterAandB.subscribe(value => 
    console.log(`Sum is: ${value}`)
);                                    // Console output: Sum is: 7
counterA$.next(3);                    // Console output: Sum is: 8
console.log(getSum());                // Console output: Sum is: 8
counterB$.next(10);                   // Console output: Sum is: 13

If you already have a lot of experience with RxJS, you will probably find the two snippets equally readable. However, I guarantee you that for those unfamiliar with RxJS, a lot of black magic has just happened. What is BehaviourSubject and how does it differ from Subject? How does combineLatest work and what does shareReplay(1) actually do? When is the sum function actually exectured? RxJS consists of more than 50 operators, often differing only in minor details. In order to operate RxJS smoothly, we need to understand the differences between hot and cold observables. We also need to have an in-depth understanding of asynchronicity mechanisms in JavaScript. Quite a bit of this for computing a simple sum of two varaibles.

More about RxJS:
📝 Hot vs Cold Observables
📝 Real World Examples of 5 Common Observable Operators
📝 What’s new in RxJS 7

As the Angular team admits (and I agree with them 100%), RxJS works great wherever we need to model events over time. When it comes to modeling the state of an application, there are quite a few better solutions and Signals is one of them. Don’t expect RxJS to disappear completely from our applications. Signals will simply put tools in our hands that will allow us to hammer nails with a hammer and drive screws with a screwdriver.

More about Signals in Angular:
📺 Angular is about to get its most IMPORTANT change in a long time…
📺 SolidJS interviews Angular creators about Signals (5h!)
📝 Angular Proposes Fine-Grained Reactivity With Signals
📝 I changed my mind. Angular needs a reactive primitive
📝 [Watch This Space] Angular Reactivity with Signals
🎮 Angular Signals Demo

1. A pack of new features in Safari

2 Is this the end of RxJS? Angular is working on a new reactivity model

Discover more great content!