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.
It’s an interesting area, right tool for the right job.
Lots of companies in the finance sector (in the UK anyway) are building trading applications in WPF because they need the visualisations it offers.
If you need a grid and a button, it is probably overkill to roll it in WPF purely because it needs to be designed, that takes resource that most dev shops don’t naturally have.
Cheers
Phil
But that is always Microsoft’s marketting strategy, which I call “Now – Even Less Retarded !!” Microsoft has been doing the same things for twenty or more years now – why are we not learning ?
Or, given Apple’s brilliant ad campaign, we ARE learning =)
I think a great example for the disadvantages of WPF is the Microsoft Zune PC software.
It’s so awfully slow and clunky.
You can do everything WPF does using Delphi, having high performance application, small footprint, developer productivity and more open platform.
Try and you will see http://www.embarcadero.com/products/delphi
Regards,
Andreano Lanusse
Thanks Andreano, I didn’t know Delphi was so widely used..
@Bernd: Zune doesn’t use WPF.
The Zune PC client is not written in WPF. It uses MS’s Media Center UI framework (“Iris”).
People who abandon vector-based UI elements for raster-based UI elements baffle me.
What will your application look like if I run it on a 2000ppi monitor? I won’t be able to see it. And when you re-architect your entire application just to be able to support my 2000ppi monitor, it is going to be 500x slower than if you’d just done the smart forward-looking thing and moved to vector and surface-based solutions.
Pixel art is not a viable platform for future applications. Yes, today it will have your application running quickly even on those XP machines that still composite the entire screen in main memory and then transfer it over to the videocard instead of maintaining separate surfaces in video memory like any half-wit would have had it doing 10 years earlier. Tomorrow, your application will be broken. And it either flat out will not be fixable, or your fix will be an utter tragedy.
Go ahead, be that company that was certain GUIs were a flash in the pan and that character mode displays would dominate the world forever. Who needs more than 25×80, right? If you keep writing console mode applications, you can have a hyperfast app that launches in a millisecond on even the oldest, most terrible hardware!
And for those bringing up Apple… Apple was doing the terrible bloated awful approach of separate surfaces in video memory and video hardware screen compositing from day 1. It’s the not-retarded way to approach screen composition, and will continue to be so into the future. If people are annoyed by the “blurry fonts” then tell them to either turn off anti-aliasing or bump up their resolution.
Zune software isn’t WPF (its the framework used in Windows Media Center).
I’d be curious to know what were their bottlenecks, apart from font issues (solved in .Net 4).
>> You can do everything WPF does using Delphi
You made my day.
How about ignore .NET and go Web. You get lots of visualizations, stuff like Yahoo YUI and others for free, and your nextdoor webdesigner wannabe can fix any tiny design problem. The availability of equivalently efficient .NET designrs surely are more expensive and harder to get hold of.
Web gives no install issues and instant update, better “intra-application” security than on Windows. Remember that each windows application carries a potential for a local “root exploit”. Finance sector types might want to use something like Chromium (open source version of Google Chrome, with some Google-stuff cleaned out) and run in Incognito (“Private”) mode to make sure they are maximally protected from data leaks. Also install some ad blockers and good antivirus, and nothing more if at all possible.
I am not disputing C++ will do the job done with less startup time and memory. On the other hand the application will not look as good and will take way longer to develop. For a third party vendor this might make sense, for applications developed in house where you need maintainability, stability and visual rich interface it doesn’t make too much sense. Besides, I am pretty sure, Evernote 5 written completely in assembly will use 25% of the memory 4 uses and will start almost instantly.
Look at the evolution of ppi in monitors in the last 20 years.
Judging by that, 2000ppi monitors will be mainstream in the very very distant future. Some people need to ship working code today.
I also think the web idea is interesting, although a bit “out of the box”. It may not work as well for all scenarios, but at the same time, the time and effort spent by the browser vendors due to the competition these days should not be neglected. 🙂
.Net needs to die. It’s holding up the progression of the web.
Tim, nicely put:
“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?”
As a .NET developer (from the Beta days I might add), I too am finding the shine has worn off more than a little. It is more than a little disconcerting that Microsoft uses their own framework so little. It’s also a bad sign that you can usually tell a .NET app just by looking at it, much like Java before it.
I developed an app for the iPhone and so learned Objective-C and Cocoa (well, and Cocoa Touch; Cocoa is the desktop framework from which Cocoa Touch is derived). It was strange at first (hey, who knew C# is the grandchild of Objective-C? wild!). The Cocoa framework turns out to be a rich, mature framework that’s easy to develop with, mixes freely with straight C and even C++, leverages lots of fast, cool C and C++ libraries, many of which are open source, and compiles down to fast,, native code. Apple clearly uses it extensively for their own products; it revs frequently, it creates apps and UIs that are fast, responsive, and beautiful.
a 40 meg download for what should really be a web-app ?
Web apps suck. I write web apps. They suck compared to Windows apps, but companies like the deployment story (I think most users would prefer a Windows app as well). I bet not too many of you guys develop in a web IDE. 😛
“some problems we simply couldn’t fix: the blurry fonts, slow startup times, large memory footprint” — a note to Java folks: yes, large memory footprint is a problem (even though “memory is dirt cheap”)
It’s not so much where they jumped from, but where they didn’t jump to, that intrigues me. They didn’t decide to use Java, or Flex, or even Silverlight, they just abandoned the idea of a managed framework and decided to redevelop in unmanaged code.
Performance, small memory footprint, development productivity, extremely rich, hardware accelerated GUI experience… I think you are describing Qt4 and you just don’t realize. Plus your software will run unchanged on Windows, Mac and Linux, and you can share code with portable and embedded platforms. I don’t really understand what’s the point of sticking to WPF. Even the new Maya is moving to Qt4: http://qt.nokia.com/qt-in-use
WTG Ismael…..bringing in the Qt ! It’s been around long enough that I’d say if it weren’t for it’s costs in licensing for commercial applications, it would be even bigger than it is today.
That being said, who was the clown that said Delphi can do everything WPF can do ? What ? Delphi is development platform for the Pascal language under Windows and .NET. WPF is part of the .NET framework and a UI compositing and declarative UI building model ( looking strictly at it as a UI grammar which is what XAML is ).
Oh ? You mean VCL ? Visual Component Library controls within Delphi ? Is that what you meant ? Because those of us who’ve worked with VCLs in and out of Delphi ( And C++ Builder. And Kylix, oh my ! ), know better.
Delphi has it’s pluses, but please, the vast majority of windows developers left that train eons ago. Waiting for Borl…I mean Interpri…I mean Borlan…I mean CodeGea…I mean Embarcadero to catch up all the time.
If your .NET app is consuming that amount of memory and is performing that sluggishly….you don’t just blame that on the platform. Anyone can make a Win32 C++ MFC app that is as slow as a slug. I’ve seen it. How you know you’re application architecture/model weren’t flawed in some huge way. It might still be. Gains encountered by switching to C++, which I’m presuming you leveraged SOME UI library. Because no one but game developers go directly DirectX, and even then it’s usually within the Rendering engines they license from others.
Of course everyone PRESUMES you did your due diligence to assert for yourselves that indeed it was .NET’s fault ( and I’m by no means being an apologist for them, I’ve used this argument back at detractors of Java when some folks would complain about EJB this..EJB that. No one TOLD you you had to EJB this or that !).
We’re presuming someone debugged their own resource consumption and weren’t leaking unmanaged resource like a sieve. We’re assuming that someone picked up a juicy tool like dotTrace, AQTime or some such and profiled their application trying to determine where the sluggish performance was bubbling up from.
Given we’re not privy to that information, it’s just as plausible someone said, “I give up.” or, “I don’t know how to solve this”, and just used their glib tongue to convince the higher ups to “Hey, we’ll rewrite it in C++ and use that as part of the marketing push for the next rev !”
I’ve seen it before….and it wouldn’t surprise me.
@jabits: There are some wildmen out there who have built such things “web ide”. Having tried a couple to satisfy my own technical curiosity, I can say “an ide only it’s progenitor could love”. Because there are so many gotchas, that only someone who had a vested interest in it’s success could honestly overlook some of the glaring usability issues with just such a construct.
Carry on, soldier.
@Marcelo L – calm down, saying Delphi can do what WPF can do is obviously silly, but on the other hand, Delphi remains a regularly updated native code development tool for Windows (the language, for example, now has generics, attributes and closures), and the VCL has ‘kept up’ better than (say) WinForms.
‘Given we’re not privy to that information, it’s just as plausible someone said, “I give up.” or, “I don’t know how to solve this”, and just used their glib tongue to convince the higher ups to “Hey, we’ll rewrite it in C++ and use that as part of the marketing push for the next rev !”’
Only, porting to native code is said to have generated measurable performance and memory benefits. You’re in danger of sounding a wee bit precious about .NET…