We’re introducing calendar-based versioning for our REST API, so we can keep evolving our API, whilst still giving integrators a smooth migration path and plenty of time to update their integrations.
First, the elephant in the room: why? Rewrites are rarely a good idea. Why did we decide to walk away from two codebases and rewrite?
From the start, GitHub Desktop for macOS and Windows were two distinct products, each with their own team. We worked in two separate tech stacks using two different skill sets. To maintain parity across the codebases, we had to implement and design the same features twice. If we ever wanted to add Linux support, we’d have to do it all a third time. All this meant we had twice the work, twice the bugs, and far less time to build new features.
As it turns out, building native apps for multiple platforms doesn’t scale.
This isn’t a new or unique problem. Over the years we explored various ways for evolving the existing applications towards a shared codebase, including Electron, Xamarin, a shared C++, or in our wildest dreams, Haskell.
We’d already experimented with web technologies to share work. The gravitational pull of the web was too strong to resist.
Beyond our own experience, we had to acknowledge the critical mass accumulating around web technologies. Companies like Google, Microsoft, and Facebook, not to mention GitHub, are investing incredible amounts of time, money, and engineering effort in the web as a platform. With Electron, we leverage that investment.
The web isn’t a perfect platform, but native apps aren’t built on perfect platforms either. Rewriting on Electron does mean swapping one set of tradeoffs for another.
Now we can share our logic and UI across all platforms, which is fantastic. But Windows and macOS are different and their users have different expectations. We want to meet those expectations as much as possible, while still sharing the same UI. This manifests in a number of ways, some big and some small.
In the small, some button behaviors vary depending on your platform. On macOS, buttons are Title Case. On Windows they are Sentence case. Or on Windows, the default button in dialogs is on the left, where on macOS it’s the right. We enforce the latter convention both at runtime and with a custom lint rule.
On macOS, Electron gives us access to the standard app menu bar, but on Windows, the menu support is less than ideal. The menu is shown in the window frame, which doesn’t work with our frameless window design. The built-in menu’s usability is also rough around the edges and doesn’t support the keyboard accessibility Windows users expect.
We worked hard to recreate a Windows-appropriate menu in web technologies, complete with access keys and appropriate focus states.
There were times when the web platform or Electron didn’t provide us with the APIs we needed. But in contrast to building a web app, building on Electron meant that we weren’t stuck. We could do something about it.
The web’s internationalization support doesn’t provide fine-grained localization information. For example, we can’t format numbers in a locale-aware manner, distinct from the preferred language defined by the user. Similar to adding the import certificate support, we plan to add better localization support to Electron.
Our best two options were Flow and TypeScript. We landed on TypeScript. At the time we started the project, Flow’s Windows support lagged far behind macOS. For a team like ours where more than half of the engineers live on Windows, this was an instant deal-breaker. Thankfully, TypeScript has been fantastic. Its type system is incredibly expressive, the team at Microsoft moves fast and is responsive to the community, and the community grows every day.
We learned to take the long feedback cycles of native development as a given. Change the code, compile, wait, launch the app, wait, see the change. This doesn’t seem like much, but it adds up. But every minute spent waiting for the compiler to compile or the app to launch is waste. It is time where we could lose our focus, fall out of the flow, and get distracted.
Using web technologies tightens up our feedback cycle. We can tweak designs live, in the app, as it shows real data. Code changes reload in place. Our feedback cycle went from minutes to seconds. It keeps us motivated!
We’ve been working on GitHub Desktop Beta for just over a year. We’re happy with how far we’ve been able to come in that time, but it’s far from done. Check it out, leave us your feedback, and get involved!