Evernote's popular note-taking technology has recently moved to release version 4.0 with some major structural changes in terms of the technology's previous adherence to Microsoft .NET and the Windows Presentation Foundation (WPF), versus native code.
The company says that Evernote 4 is a major departure from Evernote 3.5 in every way, but that there were some problems that it simply couldn’t fix while using Windows .NET and WPF.
According to Evernote's official blog announcement, "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 was incapable of resolving. As a result, we ended up chasing down platform bugs rather than adding the great features our users wanted."
Evernote says that it decided to start over from scratch and use speedier native C++ code that it felt it could rely on.
Writing on his "IT Writing" software application development blog, British journalist Tim Anderson says that the WPF as part of Windows Vista was originally intended to be the main GUI API for Windows, until the notorious "reset" midway through the Vista development cycle marked a retreat from managed code back to native code in the operating system.
So what are the lessons here? Is WPF no good asks Anderson?
"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," suggests Anderson.
"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," adds Anderson.
Balancing his argument, Anderson finishes by saying that if a development team faced with these predicaments lacks the resources to build WPF-equivalent functionality in native code, then there may be another way without abandoning .NET — since Silverlight has many of the features of WPF, is lightweight, and runs on the Mac as well as Windows.
