I programmed Aqua, Macintosh Quick Draw, Windows GDI and GDI +, Qt and .NET Winforms and WPF, by far the most complex API I used. Although it has a fairly functional feature set that is better than previous technologies such as swing, it is not suitable for WPF. It solves some serious problems that suffer from graphical programming. If you come from the world of HTML / JS, it is easy to recognize, but if you come from the traditional world of graphics programming, this is a big paradigm shift. Despite this, it is much simpler than CSS / HTML / JS. This is a clear break with outdated concepts that hit other graphical programming environments.
The biggest strength of WPF is that it is independent of permission. It can scale on all devices without any changes. This requires little work to get the on-screen version of the drawing and output it to a high-resolution printer without loss of resolution.
It also supports triggering events. User interface elements can respond to events of other user interface elements or your application code, which makes it possible to use dynamic interfaces. This makes it easy to separate your code from the user interface so that even HTML / JS cannot reach it. Elements can broadcast and listen to events and respond accordingly.
Another advantage is its highly object-oriented and declarative API. Using XAML, you can easily build a working interface quickly and efficiently with just a few lines. Unlike HTML / JS, itβs easier to learn and its output is much more predictable and efficient. You can even fully program WPF in code, but itβs usually not worth the slight increase in performance. The best way is to compile Xaml code in .NET.
In addition, the tools available for WPF are very extensive compared to JavaFX. There are many tools available, including Expression Blend. There are also numerous tools for receiving vector graphic formats such as SVG and Adobe Illustrator, and converting them to XAML. Now designers and programmers can collaborate in the field of desktop publications in such a way that it was very difficult to do before.
Thus, WPF is so comprehensive that the Mono team chose not to port it to the Mono code base. They stated that it would take many years to fully implement a reasonable set of functions. If there was a Mono-compatible version of WPF, this would make .NET a de facto cross-platform application platform. In fact, it can even replace HTML / CSS, as it is much more powerful and easier to circle your head. Unfortunately, Microsoft did not see a business example for cross-platform WPF. This is why SilverLight / WPF lost HTML5 / JS. Thanks to this error, they are now forced to transmit not only web pages, but also part of the desktop in HTML 5 / JS.
ATL_DEV Jan 16 '13 at 19:08 2013-01-16 19:08
source share