Apple Announces the Safari Technology Preview

Today Apple made an interesting announcement for developers regarding Safari. Safari is Apple's browser across all of their iOS and OS X devices, and the layout engine at its core is WebKit. WebKit was originally started as a project within Apple as a fork of KHTML, a layout engine developed by the KDE project. Today it's widely employed in many browsers on many platforms, with Google and Opera formerly using it and now utilizing a fork of WebKit called Blink.

Traditionally developers who want to use the latest improvements to WebKit have had to download WebKit nightly builds, which as their name implies, are builds that reflect the latest changes to the WebKit code base and are released on 24 hour intervals. This allows developers to test and develop against new features being added to WebKit, which later make their way to Safari and other WebKit-based browsers as well. Distributing nightly builds for developers is a common practice for large software projects, but in the case of Safari and WebKit it was not ideal in many ways. For one, it essentially made the version of Safari on a computer use the new nightly WebKit back end that was installed, which can lead to annoyances when trying to compare between the existing public release and the nightly build. It also disables features like iCloud integration for tabs, bookmarks, passwords, etc, as the builds are not signed by Apple.

The Safari Technology Preview is Apple's attempt to address some of these problems, and make it easier for developers to keep track of what changes are being made, and to submit feedback or bug reports based on what they experience. What the preview consists of is an application separate from Safari that uses a more up to date version of WebKit than what the public version of Safari that comes with OS X uses. It's available from Apple's developer website, and updates will come every two weeks via the Mac App Store. This makes the list of changes and additions easily accessible with each update, and because the builds are signed by Apple there's full support for iCloud integration. Having a separate application means that comparisons and regression testing between the current official version of Safari and one with a more up to date version of WebKit can be done easily. 

One important thing to note about the Safari Technology Preview is that, while the app is available from Apple's developer site, you don't need to be a registered developer paying the yearly iOS and OS X publishing fee to access it. Since the target audience consists mainly of programmers building websites and web applications, it doesn't make sense to limit it to developers building native apps for iOS and OS X.

Apple is highlighting some key things that are new in the initial release of the Safari Technology Preview. The first is that it has what they claim to be one of the most complete implementations of ECMAScript 6 (ES6), which in less precise but simpler terms means the latest version of JavaScript, as JavaScript was standardized as ECMAScript and now can be considered an implementation of the standard itself.

Image source: Mozilla

ES6 comes with some key features for developers, including support for classes as part of the object oriented paradigm, iterators, and many new APIs. I am personally not a web developer, and the fact that JavaScript is just now adopting more explicit class declarations on top of the existing function prototype based declarations comes as quite a surprise to me.

Another key feature of the Safari Technology Preview is the new B3 Just-In-Time (JIT) JavaScript compiler. B3 is the new compiler backend for WebKit's FTL JIT compiler which was introduced about a year ago with LLVM acting as the backend. At that time there was a great deal of info about the work that went into making LLVM, traditionally a production grade compiler for native applications, usable for compiling JavaScript on the fly within the constraints of something like a smartphone. Since Apple has been a major part of both WebKit and LLVM, using LLVM as the backend to achieve greater optimization of JavaScript code made sense. However, LLVM was architected as a compiler that would be used for optimizing and compiling code on large powerful desktop computers where power usage and compile times were not a large concern, as the code would simply be compiled and shipped to be run. In the context of a mobile device, you'll be visiting various sites and compiling a great deal of different JavaScript code, and so a different strategy needs to be employed.

This is where B3 comes in. According to Apple, LLVM's optimizations often are overkill for the task of JavaScript compilation. There are cases where it's actually faster to just compile some lines of code and run them than to take time to optimize, compile, and then run. In these situations, there are performance gains to be made by moving away from LLVM, as you need to work on minimizing compile time rather than generating the most efficient code possible. On a high level, B3 looks at the JavaScript code that needs to be executed and decides whether it's actually worth optimizing it or not. For complex code that may be run many times it makes sense to spend the extra time optimizing, but for small groups of simple statements it may be better to just compile it without optimizations. 

Of course, a big question may be why you wouldn't just apply tweaks to LLVM. Apple says that B3 was designed from the ground up with a focus on quick JavaScript execution, but it wouldn't be surprising if there are ties to LLVM which already exists to provide a solid foundation.

For developers and other interested parties looking for more info on B3 there's a post on the official WebKit blog about other improvements that have been made. They also highlight some improvements in compile time that have been observed with popular benchmarks, while also demonstrating the fact that performance doesn't regress from the LLVM backend despite the significant reductions in compile time. Right now B3 isn't fully ported to ARM64 and that will be necessary before we see it debuting on iOS.

The last two major inclusions in the first release of the Safari Technology Preview are an updated IndexedDB implementation and support for the newest standard of Shadow DOM. The former is a way of storing data on a client device for quick access, and the changes are the result of developer feedback, with Apple claiming that the new implementation is more stable and better compliant with established standards. A simple explanation of Shadow DOM is that it provides a way for developers making websites and web apps to better define the style of widgets and controls while keeping them independent from other styling options that apply to the page.

The Safari Technology Preview is available now from Apple's developer website. As mentioned before, it only needs to be installed from the developer site, with future updates coming every two weeks via the Mac App Store, with the latest changes to WebKit and Safari in tow.