And today I'm going to talk a little bit about the process of a P I and modernization.

For a little brief background on me, I work full time on the electron project on behalf of Get Hub, where I've been for the past about 2.5 years.

This work has also allowed me to explore an actively contribute to a pretty wide range of open source projects and committees, including node, chromium and T C 39.

I'm based in San Francisco, drink a lot of coffee and do a lot of crossword puzzles.

So what is?

Modernization?

Modernization means very little out of context, especially in the software world.

It's a fun, fancy buzzword, but I can't really give ah whole presentation on how you can apply its principles to your own organization without first establishing some shared context.

For what I mean when I say it in service of that goal, let's start with the most basic definition of the term I could find as it applies to software.

So as we see here, modernization can be understood as the conversion, rewriting or porting of a legacy system to a modern language software, library protocol or hardware platform.

That's an okay start, but it still leaves us with quite a lot of unanswered questions.

What does it mean for something to even be modern?

There's still a lot of wiggle room in that definition that I just gave.

And even some of its different components might not all be understood in the same way, even amongst you.

The audience, for example.

Ah, highly doubt that we all understand modern language to be the same thing.

For example, beyond Herb.

Sorry.

Beyond that, can modernization even be universally understood across contexts?

The answer to that question, for better or worse, is that it depends.

And I know that's probably not something a lot of you really love to hear.

It's kind of like running a non deterministic software program.

It doesn't really inspire a whole lot of confidence, but I'm not really here today to give you 30 minutes worth of maybe so.

Let's unpack that a little bit further.

Modernization is something that takes on different meanings in different contexts, and so for you to really understand and gain concrete lessons from its discussion, I'm going to ground it in practical examples from something I work on every day.

The electron framework modernization.

Alice, we'll soon see can also feel a little bit like this.

There's not always an obvious path to take on whichever one you do take can often Lee waste your best laid plans.

You may now be wondering why it's modernization, even something that we actively want to do in the first place.

I haven't exactly opened with the most shiny and positive take on the thing, so in principle we modernize in order to retain and extend the value of a legacy.

Investment, which is an investment that continues to provide core service, is to an organization.

There's a lot of different reasons that you, as a developer, might want to do this.

But for better or worse, it's something that almost all of us will at some point I need to do now.

Some of you might be familiar with electron, but before you really get to the good stuff, I think I'm gonna do a brief overview just to make sure that we all have the same base understanding of what it ISS Electron is a JavaScript framework that allows you to write desktop applications with Web technologies like Java Script, HTML and CSS.

It could be used on Windows, Mac and Lennox, as well as a variety of other architectures and platforms like Windows on Arm and even raspberry pi.

It works by integrating chromium a node in addition to a layer of C plus, plus an objective C, which allows it to create fully formed Do I Do I CZ as well as take advantage of file system and networking capabilities with note.

Typically, desktop applications for an operating system are written in the native language for each.

If we take Windows, Mac and Lennox, that now means that you have three teams reading three different desktop applications to do functionally the same thing.

This could be pretty costly, both in terms of monetary, your sources, feature and development velocity and developer hours.

With electron, you only need to write your up once, and then it will work on all applicable platforms, and we can't really understand how modernization affects users without first discussing a P I version ing an a p.

I is fundamentally ah, contract that you, as a maintainer establish with the people consuming your A P.

I about how it's going to behave when developers have their AP eyes consumed, the consumers are implicitly signing their end of a contract, and you, as the maintainer, are implicitly signing your end.

You can think of an A P I a little bit like buying a new car when you buy that car.

You've probably got a set of expectations for how that car's gonna behave and how various controls on the car or going to affect that car's movement.

Now let's say you bought that car and it's spree.

It's shiny and you get on the highway and you're going 80.

And then suddenly the accelerator and the brake they switch.

Now.

I don't know about you.

I love a good adventure, but I really like knowing what my gas pedal is going to do.

Ah, 100% of the time.

Your users are the same.

They don't want to risk their app on something they don't feel like they can trust.

So now, back to one of the questions I had on earlier slide.

How do you set these expectations?

One of the more common ways to set expectations for an A P I contract is known a semantic version ing December, and this approach to version ING aversion is specified with three numeric components.

First major, then minor.

Finally, Patch.

As its name suggests, each one of these components confers semantic meaning and allows a consumer to quickly understand how updating their app to a new version is going to affect their APS potential behavior.

Major version bumps are made when you add incompatible or breaking a P.

I changes.

Minor bumps, indicate new but backwards compatible functionality, and then finally, patch updates indicate fixes to existing functionality, but nothing new for our purposes.

Today I'm gonna focus on three main buckets modernization, spurred by updates to platform modernization related to dependencies and then, finally, modernization related to programming language specifications.

First, off platform modernization operating systems maintain their own unique AP I surfaces, which don't always adhere to the kind of a P I contract you might be accustomed to.

Platforms can't really adhere to something like somber when their version ing so.

Instead, they often choose to make updates to their AP I surface area based on updates with their operating system versions.

As you might imagine, this can create some mismatches with libraries which often need to work across multiple versions of a single operating system.

One example of this is Apples Op Kit framework, which contains all the objects that a developer needs in order to implement the user interface for a Mac OS app like Windows, panels, menus, scroll er's text fields, you get the idea.

As such, frameworks like electron, which hook into and depend on this framework, need to monitor and adapt for changes as Apple releases new versions of its operating system.

The question we then want to ask ourselves is, What's the optimal way to account for this?

Let's look at how electron handled a recent snafu with just such an issue.

If you've used Mac OS, you'll know that there's a tray bar at the top of the screen.

The trade bar can contain individual elements, which are known to Apple as Ennis Status items.

Electron exposes a module that enables you to create and control individual instances of these elements through the train module.

From the very first release of Mac OS until 10.14 Mojave developers could use instance properties on these NS status items to customize their appearance and behavior.

Then, in Mac OS 10.10.

They introduced a new instance property.

The Button Property, which also allows you to customize the appearance and behavior of the items at the same time they deprecate ID the previous instance properties.

And then finally, in Mac OS 10.15 Catalina, these deprecate ID instance properties finally ceased to work an electron.

This created some pretty nasty consequences.

We've been using the previous instance properties up until then, and only actually realize this issue.

It happened because the tray issues, when we're testing our Catalina literally just stopped showing up, which is, you can imagine, was pretty awesome.

So as a result, we had to quickly and efficiently modernize our own code for these new constraints.

But there is one catch.

The button.

Property no longer allowed developers to manually manage highlighting of NS status items.

Highlighting in this case is the way that the icon appears when you click on it.

Previously, you could set it to always appear highlighted on Lee appear highlighted when clicked or never appear highlighted.

So how do we handle this change by necessity?

This is a breaking change.

What we chose to Dio is to remove this method from electron version seven without replacement since at the time it was in an early beta and so we wouldn't be breaking our A P I contract by doing so.

We then noted that the tray would experience display issues in older versions of electron and encouraged users toe update where they could as you consider your own APS platform modernization strategies.

There are some things I think that electrons experience demonstrates here.

We don't always make the right choices, and so we want to share both our successes on the things that we think we can do better.

We determined these breaking changes in practice because one of the core team was doing some testing on Mac OS Catalina.

But this change was ultimately more reactionary than I think we wanted it to be.

It's important to strategize research around upcoming platform changes in advance so that you don't end up scrambling to minimize and user changes in the same way that we did.

How do we done that?

We could have avoided users experiencing any breaking changes in more than one supported version of electron.

Next stop is language modernization, language modernization is that relating to the programming language in which a framework or library is consumed.

That's important in the case of electron, because while electron is a Java script framework, its underlying architecture is actually written in a combination of Objective C and C plus plus and so modernization.

An electron is modernization that allows developers to use new additions or changes to Java script as their added to the Java script frame or to the job scruple language through the Atmos crypt specifications.

A variety of these are outlined here.

Some you might be more familiar with include promises, a sink await optional catch, binding or no wish coalescing.

Some of these capabilities get to electron for free when we update our dependencies like V eight, but we'll save that for later and focus on the more costly updates right now.

A notable effort in the electron code base this past spring was known as the Promise of Vacation Initiative, which took most of our asynchronous AP eyes and transform their usage from call back to promise based.

We undertook this initiative for a variety of the reasons I've already outlined.

Cole backs have their place undoubtedly, but developers can write arguably simpler and more elegant code and open the doors to even more functionality when they can write promise based code.

So how'd we do this?

And then how did we communicate this to our users?

We actually chose to do it natively.

Um and I can see some of you look a little bit confused by that Aren't promises of Java script thing.

So the answer to that is actually yes, but also no to do this, we actually used an engine called V eight, which Google wrote for Google.

Chrome implements the same specifications of Java script, but in C++.

By writing a rapper over its promise functionality, we could enable our AP eyes to cleanly return promises at the C plus, plus an objective sea level without needing to paper over them at the Java script level with something from node like you told our promise, Fi so basically promises, but with surprise multi threading.

Um, this looks a little horrifying, I recognize, but honestly, it was pretty fun on arguably a lot better for consumers.

We also created a document to truck progress of this migration and conform to our own semper contract by ensuring that the changes were backwards compatible where possible, which means that they supported both callbacks and promises simultaneously for at least one major version.

To ensure the developers had enough lead time to make necessary changes.

We also logged thes backwards compatible functions with deprecation warnings at runtime.

So was this a totally smooth process also know, On a high level, we accomplish our goal with relatively few hiccups.

But that's not to say we didn't hit any snags and one of our more fun bugs.

We actually found that if you called one a p I in just the right way, a native Promise chain would trigger an uncatchable promised rejection that the user would only ever see as a silent failure because we'd actually introduced a way to write non type safe c++.

Um, Jeff Goldblum was ashamed of us for that, Um, so what we learned from that adventure and what can you take away from it?

For starters, deprecating methods well is a non trivial task that shouldn't be done haphazardly.

We should have been more clear upfront that all changes wouldn't be taking place in one major version, since we occasionally still get issues saying that a promise based function didn't work for promises when it hadn't yet been converted.

We're looking towards our docks to help us better fill that gap.

We do want to continue our transition path pattern.

However, feedback from our users indicated that they felt we provided clear context and information on how to upgrade methods that they were already using in production.

Finally, we moved to dependency modernization.

This is modernization that enables access to more modern capabilities through dependencies and not through code.

We wrote ourselves for electron.

Three key dependencies of this nature are chromium vi eight.

A note updating each of these gives users access to new features but also brings with them potentially breaking changes.

And so we need to be very mindful about how we coordinate these upgrades.

Upgrading node, for example, gives us access to new file system and networking capabilities like, for example, recursive are under, since node also would.

Here's December minor bumps and node also necessitate minor bumps and electron and major bumps and node necessitate major bumps an electron By upgrading node, we ensure that we stay on top of security updates and see performance improvements thanks to the great work of the benchmarking working group within notes governance Chromium is a bit of a different story and that they don't really adhere to the same A p I contract we d'oh and they don't support older versions passed a fairly short tail.

We're therefore always chasing the tip of chromium sorcery.

Security and performance are our primary forcing functions here as the most secure chromium is always going to be the latest chromium on the performance of chromium, and therefore, electron is also going to be better, the more recent a version of chromium that were using.

We also do get some upgrades and new capabilities for free from chromium like, for example, the way clock a P I that allows you to control screen sleep on different platforms.

These capabilities are still a work in progress on are constantly being scoped out and experimented on here.

What's known as the Food Goo Initiative?

Finally, V eight I mentioned V eight a bit earlier on as Google's drove a script engine that implements the ECU, a script specification.

But in c++ for electrons purposes, it's also very important that we try to use the latest compatible version that we can this enables us to access the latest features of the job script speck, including some that you can see on the slide here on the left hand portion.