Evernote has released version 4.0 of its excellent note-taking product. Software developers have taken particular interest in the blog post announcing its release, because of what it says about .NET, in this case the Windows Presentation Foundation, versus native code:
Evernote 4 is a major departure from Evernote 3.5 in every way. While 3.5 added tons of great new features, there were some problems we simply couldn’t fix: the blurry fonts, slow startup times, large memory footprint, and poor support for certain graphics cards were all issues that the technology behind 3.5 (Windows .net and WPF) was incapable of resolving. As a result, we ended up chasing down platform bugs rather than adding the great features our users wanted.
So we decided to start over from scratch, with fast, native C++ that we knew we could rely on. As you’ll see, the results are amazing. This new version will set a foundation for rapid improvement.
Evernote 4 is designed to give you a great experience on any computer that you use, whether you’re on a netbook, a five year old Windows XP machine or a super fast top-of-the-line Windows 7 computer.
On our test hardware, Evernote 4 starts five times faster, and uses half the memory of Evernote 3.5.
A bit of background. WPF was introduced in Windows Vista and was originally intended to be the main GUI API for Windows, until the notorious reset midway through the Vista development cycle which marked a retreat from managed code back to native code in the operating system. I’d guess that the issues faced by the Evernote team were not so different from those faced back then by the Windows team at Microsoft.
WPF is not only based on .NET. It also uses DirectX and hardware acceleration under the covers, enabling rich multimedia effects. The layout language of WPF is XAML, giving freedom from scaling issues which cause hassles in the native API.
So what are the lessons here? Is WPF no good?
It is not so simple. WPF is brilliant in many ways, offering the productivity of .NET coding and a powerful layout framework. However it was a technology which Microsoft itself hardly used in its key products, Windows and Office – a warning sign.
When Microsoft built Visual Studio 2010 and .NET 4.0, the development team used WPF for the Visual Studio shell. This move by an internal team to create such a complex product in WPF was good for the framework itself. The font issue was addressed, performance improved. Evernote might not have found all its issues fixed in version 4.0, but it would likely have been better.
After I tweeted about Evernote’s experience, a couple of Microsoft folk contacted me to make this point. The trouble is, even version 3.5 of WPF was not the first version, and it never sounds altogether convincing if, when a customer complains about your product, you tell them everything is fine in the latest and greatest build. Why did Microsoft not get this right before?
That said, I am sure the latest WPF is better than before, though it is still heavyweight relative to native code. Factors that might suggest a WPF solution include:
- The application only needs to run on Windows
- There is no need to support older machines
- The application makes use of data visualisation or other multimedia effects
- The development team lacks the resources to build equivalent functionality in native code
The last point is important. Maybe a hotshot team of C/C++ developers could make a better job, but if you don’t have such a team or the money to hire it, it is not so relevant.
There is another possible approach, without abandoning .NET. Silverlight has many of the features of WPF, is lightweight, and runs on the Mac as well as Windows.