VioletTape Mar 18 2015 at 07:40

Почему WPF живее всех живых?

9 min

62K

GeekFamily corporate blog.NET*C#*Development for Windows*

+24

Comments 65

sidristij Mar 18 2015 at 08:28

Потому что вариантов других нету :) WinForms? XWT? Gtk#?…

codecity Mar 18 2015 at 08:44

Для Store/Win Phone есть JS. Учитывая любовь индусов к JS, Сатья сделает его же и для всего остального.

bstdman Mar 18 2015 at 09:20

WPF — сейчас фактически единственный инструмент для настольных корпоративных решений для ОС Windows

З.Ы. Эх, ну почему 11 апреля? Ну не могу я в свой день рождения работать =)

zipo Mar 20 2015 at 11:27

Если работать не хочется ради прикола, что бы размять мозги можно пройти симуляцию теста: onlinetestcentre.com/70-511.html
Иногда обнаруживаются пробелы, в общем штука интересная.

UFO just landed and posted this here

Funbit Mar 18 2015 at 10:24

К сожалению, не могу не согласиться. Мне тоже кажется, что у WPF нет будущего. Да и жив он только благодаря огромной инерционности ОС и корпоративных приложений.
Делаю ставку на WinRT (C# или JS, и то и другое будет популярным). Мне кажется его популярность вырастет очень сильно после перехода на Windows 10, где можно запускать WinRT приложения в обычных окнах.

EngineerSpock Mar 20 2015 at 09:34

Тут прошла какая-то странная противоречивая новость, что WinRT умер.

Funbit Mar 20 2015 at 10:23

Вы путаете версию Windows RT (продолжение которой не будет), с фреймворком, который составляет основу современного интерфейса — Windows Runtime (позволяя создавать так называемые универсальные приложения — Universal Apps).

EngineerSpock Mar 20 2015 at 12:13

А вы под WinRT имели ввиду Runtime? Я знаю разницу, ничего не путаю :)

Nagg Mar 18 2015 at 11:56

Увы, это правда. Даже жалко времени, потраченного на XAML related технологии (wpf, sl, wp8, win8). Прошло много лет — ничего не поменялось.
2015ый год, чтобы забиндить !IsBusy на IsEnabled мы пишем:

"{Binding IsBusy, Converter={StaticResource InverseBooleanConverter}}"

SL мёртв (даже презентации МС проводит во флеше), WPF жив старыми ентерпрайзоными проектами, WP8 имеет долю в пару процентов в мире. Win8 приложения вообще никому не нужны.
Опять ждать/надеятся на Вин10, как ждали вп8+вин8… нет сил.
Как не прискорбно, но будущее видется за js.

exvel Mar 18 2015 at 14:23

Хм, а если применить DataTrigger?
Хотя, в любом случае, громоздко выходит для такой простой операции.

Nagg Mar 18 2015 at 14:27

Во-первых, более громоздко, да. Во-вторых, в WP8/Win8 даже дататриггеры не завезли.
Кстати, в том же Android+MvvmCross такой биндинг бы выглядел так:

local:MvxBind="Enabled Inverse(IsBusy)"

int19h Mar 20 2015 at 00:58

Это из коробки. Но при этом там вполне хватает хуков для того, чтобы реализовать вот такое:

<Menu IsEnabled="{Binding Loading, Converter={wpf:Lambda '(bool x) => !x'}}" ...

(Кому интересно, покопайтесь здесь и здесь)

Nagg Mar 20 2015 at 12:14

Выглядит интересно, но нет нативной поддержки — не type safe (переименовки, подсказчик при написании лямбды).
И вопрос перфоманса интересует, используется GenerateCodeFromCompileUnit (а wpf и так медленный).
На мобильном XAML (wp8, win8) такое и работать в принципе не будет.

int19h Mar 20 2015 at 12:25

Да, это, разумеется, WPF. Его «наследники» намного более убоги.

Насчет нативной поддержки редактирования (это все-таки не то же самое, что type safe) — ну так её нет и у обычных биндингов. Хотя это в принципе можно сделать, возможности редактора VS такое позволяют — аналогично тому, как в ASP.NET редактор поддерживает смешанный HTML и C# код.

На производительность генерация кода не влияет, так как происходит целиком на этапе компиляции — обратите внимание, это MSBuild-таск. По сути он вклеивается в обычный пайплайн для генерации кода для WPF, и вшивает тело лямбд в partial class. Потому и все ошибки в лямбде, будь то неверные типы или переменные, вылезут на этапе компиляции (ну, если вы не используете dynamic — а по умолчанию, если не указать тип параметра у лямбды, то он там будет именно dynamic).

Производительность в рантайме — один словарный поиск по строке для каждой лямбды один раз при загрузке XAML, плюс два косвенных вызова на каждый вызов лямбды (там несколько оберток). По сравнению с накладными расходами на сам биндинг, вы это вообще не заметите.

Nagg Mar 20 2015 at 12:30

Интересное решение, спасибо за объяснение. Давно не использовал WPF. Но все равно биндинг немного монструозненько выглядит для такой простой операции.

UFO just landed and posted this here

Nagg Mar 20 2015 at 15:31

и даже без DataContext, решарпер (будем считать, что это нативная поддеркжа) будет следить за тем, что бы биндинги тоже переименовывались после переименовки свойств во вьюмодели.

Nagg Mar 20 2015 at 15:30

Ogoun Mar 18 2015 at 13:15

Не могу согласиться, отличий от WinForms настолько много, что непонятно как вообще можно их сравнивать (да тот же отказ от GDI/GDI+).
Да, у привязок есть ограничений, но достаточно написать несколько своих хелперов (или взять готовые), чтобы стало комфортно.
По быстродействию возможно вы правы, я не вывожу в списки больше 500 элементов, к тому же есть пейджинг, на моих объемах тормозов не видел.
Если учесть направления в которых сейчас развивается Microsoft, то что они внесли линукс в список поддерживаемых систем, то, вполне вероятно, скоро мы увидим и кроссплатформенный WPF.

Vedomir Mar 18 2015 at 13:29

Главная проблема WPF вовсе не в его архитектуре и идеях — о том что они хорошие никто не спорит — главная проблема в том что уже почти 8 лет он никак не развивается.

И есть проблемы гораздо серьезнее кроссплатформенности — начиная с синтаксиса (где Razor для WPF?) и не заканчивая кривым движком рендеринга, из-за за которого даже HTML в браузере временами работает быстрее (повторю комментарий ниже — подробное исследование и опыт Evernote которые ради повышения производительности переехали на Chromium Embedded Framework).

Конечно было бы очень хорошо если бы на него снова обратили внимание и начали так же активно развивать, как ASP.NET.

areht Apr 1 2015 at 17:11

> где Razor для WPF?

А что вы в MVVM хотите делать с Razor?

Vedomir Apr 1 2015 at 17:30

В соседнем комментарии уже цитировали статью на эту тему Семь лет WPF: что изменилось?:

Вот как в далёком 2006-м году выглядела разметка относительно простого окошка (код позаимствован из проекта, над которым я тогда работал):
    <Window x:Class="PaulStovell.TrialBalance.UserInterface.MainWindow"
      xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
      xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
      xmlns:tb="clr-namespace:PaulStovell.TrialBalance.UserInterface"
      xmlns:tbp="clr-namespace:PaulStovell.TrialBalance.UserInterface.Providers"
      xmlns:system="clr-namespace:System;assembly=mscorlib"
      Title="TrialBalance" 
      WindowState="Maximized"
      Width="1000"
      Height="700"
      Icon="{StaticResource Image_ApplicationIcon}"
      Background="{StaticResource Brush_DefaultWindowBackground}"
      x:Name="_this">
Только взгляните на все церемонии! x:Class! Пространства имён XML! Почему бы не объявить всё это в одном месте, почему бы стандартные пространства имён не включать неявно?

К счастью, сейчас 2013-й год, и WPF был проделан огромный путь. Вот так код будет выглядеть сегодня:
    <Window x:Class="PaulStovell.TrialBalance.UserInterface.MainWindow"
      xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
      xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
      xmlns:tb="clr-namespace:PaulStovell.TrialBalance.UserInterface"
      xmlns:tbp="clr-namespace:PaulStovell.TrialBalance.UserInterface.Providers"
      xmlns:system="clr-namespace:System;assembly=mscorlib"
      Title="TrialBalance" 
      WindowState="Maximized"
      Width="1000"
      Height="700"
      Icon="{StaticResource Image_ApplicationIcon}"
      Background="{StaticResource Brush_DefaultWindowBackground}"
      x:Name="_this">
Видите разницу? Я тоже не вижу. Да, за семь прошедших лет никто пальцем не шевельнул, чтобы избавиться от избыточности кода.

Давайте для сравнения взглянем на код странички ASP.NET 2006-го года (тоже из проекта тех лет):
    <%@ Page Language="C#" MasterPageFile="~/TrialBalance.Master" AutoEventWireup="true" EnableViewState="false" CodeBehind="Builds.aspx.cs" Inherits="PaulStovell.TrialBalance.MainWebsite.Builds" Title="Downloads - TrialBalance" %>
    <asp:Content ID="Content1" ContentPlaceHolderID="MainContentPlaceholder" runat="server">
      <asp:PlaceHolder runat="server" Visible="false" ID="_downloadAreaPlaceholder">
        <h1>Download</h1>
Как эта разметка выглядит сегодня?
    @model BuildsViewModel	
    @section Main {
      <h1>Download</h1>
    }
Изначально я стал разработчиком WPF, потому что мне были не по душе ASP.NET Web Forms и модели вроде View State. Но сейчас, когда я оглядываюсь на проделанный ASP.NET путь, я вижу огромные изменения. От модели Web Forms до модели MVC, от синтаксиса ASPX до Razor — в лагере ASP.NET действительно занимались инновациями.

Вот неполный список того, что сделано в ASP.NET и не сделано в WPF:

Создан новый, дружественный человеку язык разметки (Razor). Когда пишешь на Razor, получаешь удовольствие. Написание XAML никогда не доставляло удовольствия. Более того, до того, как в ReSharper'е появился «Импорт пространства имён», оно было сущим кошмаром.

Избраны дизайн-паттерны. И не говорите, что в WPF есть MVVM — да, WPF поддерживает байндинги, но в ядре WPF нет ни единой фичи, сколь-нибудь помогающей с MVVM. Это всё прилеплено сбоку через Blend Behaviors и сторонние фреймворки. В ASP.NET же весь стек построен на MVC.

Попал в пропасть успеха. Вы реально можете написать поддерживаемое приложение на ASP.NET MVC, используя стандартный шаблон проекта. А стандартный шаблон WPF без сторонних фреймворков — это путь мучений и невзгод.

Избрана расширяемость. Практически всё в ASP.NET MVC основано на интерфейсах и абстрактных классах, которые вы можете расширить, изменив тем самым поведение фреймворка. Готов поклясться, команда WPF слыхом не слыхивала про интерфейсы, а немногие абстрактные классы имеют internal конструкторы.

Избран опен-сорс. ASP.NET включает jQuery и JSON.NET, и прекрасно совмещается с бесчисленными опен-сорсными инструментами. WPF, несмотря на нескончаемый список MVVM фреймворков, и несмотря на полную невозможность разработки поддерживаемого приложения без такового, до сих пор их не включает.

Стал опен-сорсом. Исходники ASP.NET MVC были открыты с самого начала, но сейчас вообще весь стек ASP.NET стал опен-сорсным и принимает исправления извне. WPF — нет, и, откровенно говоря, вы бы и не захотели смотреть на код WPF: он ужасен (прим. перев.: можно оценить VirtualizingStackPanel).

Статья написана в 2013. Что изменилось в 2015? Только одно — в заголовке статьи надо писать Девять лет WPF: что изменилось?

areht Apr 1 2015 at 18:18

То есть разработка в ASP.Net с прикрученным сбоку jQuery — это хорошо,
а разработка на WPF с прикрученным сбоку mvvm-фреймворком — это плохо?

Ну вот когда появится не «бесконечный список», а MVVM-фреймворк, претендующий на промышленный стандарт — тогда можно думать о его включении. А пока как обычно, поставил решарпер (куда ж без него), прикрутил любимый фреймворк (куда ж без него)

Возвращаясь к, с Razor можно разве что пару строчек xmlns: сэкономить, а всякие WindowState=«Maximized» всё равно писать придётся (ну или сразу можно удалить — будет как в примере «Как эта разметка выглядит сегодня?»). А всяких ASP.Net-овских ID в WPF писать никогда не заставляли.

Только я вот ни разу не видел попыток от xmlns избавится. Похоже никого не беспокоит. А вот биндинги облегчаются легко и непринужденно (скажем, github.com/Alex141/CalcBinding) — это обязательно в комплект класть?

areht Apr 1 2015 at 17:04

> И, мне кажется, что он умудряется работать быстрее, чем наше родное WPF приложение на Telerik.

Мне кажется это не проблема WPF, а проблема Telerik.
Попробуйте подгрузить 100500 данных в том же телерике в браузер — тормозить будет примерно так же, а памяти кушать больше.

Vedomir Apr 1 2015 at 17:33

Мнение перешедших на встроенный Chrome разработчиков Evernote:

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

areht Apr 1 2015 at 18:24

5 лет прошло, какой poor support for certain graphics cards?

iRumba Mar 20 2017 at 19:49

Устарел пост. Но я все же оставлю это тут! :)

Мы пользуемся DevExpress. Жутко тормозная штука. К тому же писались контролы явно для винформ, а потом портировались под WPF «как есть». Про MVVM они слышали краем уха. Короче все, за что их покупают — это обертка. А внутри какашка. Полагаю, что Telerik не сильно отличаются в этом плане. Контролы, написанные мной, работают в разы быстрее.

А что касается поддержки, я еще не встречал настолько гибкой системы. Это тот случай, когда допиливать новые фичи могут сами .net разработчики, и они не будут костылями.

hardex Mar 18 2015 at 10:26

Back in 2006, here's what the markup for a pretty basic Window looked like (taken from an app I worked on in 2006):

<Window x:Class="PaulStovell.TrialBalance.UserInterface.MainWindow"
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  xmlns:tb="clr-namespace:PaulStovell.TrialBalance.UserInterface"
  xmlns:tbp="clr-namespace:PaulStovell.TrialBalance.UserInterface.Providers"
  xmlns:system="clr-namespace:System;assembly=mscorlib"
  Title="TrialBalance" 
  WindowState="Maximized"
  Width="1000"
  Height="700"
  Icon="{StaticResource Image_ApplicationIcon}"
  Background="{StaticResource Brush_DefaultWindowBackground}"
  x:Name="_this"
  >

I mean, look at all that ceremony! x:Class! XML namespace imports! Why couldn't any of that stuff be declared in one place, or inferred by convention?

Fortunately, it's now 2012, and things have come a long way. Here's what that code would look like if I did it today:

<Window x:Class="PaulStovell.TrialBalance.UserInterface.MainWindow"
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  xmlns:tb="clr-namespace:PaulStovell.TrialBalance.UserInterface"
  xmlns:tbp="clr-namespace:PaulStovell.TrialBalance.UserInterface.Providers"
  xmlns:system="clr-namespace:System;assembly=mscorlib"
  Title="TrialBalance" 
  WindowState="Maximized"
  Width="1000"
  Height="700"
  Icon="{StaticResource Image_ApplicationIcon}"
  Background="{StaticResource Brush_DefaultWindowBackground}"
  x:Name="_this"
  >

Spot the difference? Of course not, it was a trick question, nothing has changed since 2006 that would have made that less verbose.

paulstovell.com/blog/six-years-of-wpf

Vedomir Mar 18 2015 at 11:40

Есть перевод на хабре
habrahabr.ru/post/165273/

PsyHaSTe Mar 19 2015 at 15:35

Вы статью наверное не читали. Это называется «зрелая технология». В мире WPF нет такой проблемы, как в вебе, что вы на 5 лет выпали из разработки — а вокруг куча непонятного, и вы даже не сможете найти работу! То ли дело WPF — вы спокойно можете взять отпуск на эти 5 лет, а после этого вернуться к проекту, и быть уверенным, что ваши знания ни капли не устарели. Уверенность в завтрашнем дне — наша цель.

hardex Mar 19 2015 at 15:37

Самое страшное здесь — то, что я даже не берусь утвеждать, пишете ли вы это в шутку, или серьезно.

a553 Mar 19 2015 at 17:44

Я думаю это было серьезно. По таким законам живет энтерпрайз мир.

Vedomir Mar 20 2015 at 08:56

Даже в энтерпрайз мире такой подход в лучшем случае означает потерю профессиональных навыков и самую тупую и скучную работу по поддержке старых систем. В теории конечно даже системы под DOS до сих пор кое-где живут и какими-то программистами поддерживаются…

a553 Mar 20 2015 at 13:02

Это выгодно компании. Всё остальное не важно.

Vedomir Mar 20 2015 at 16:21

Если это выгодно компании и не выгодно нам всегда можно уволится.

a553 Mar 20 2015 at 16:36

Ну, в энтерпрайз ходят не ради интересной работы.

Vedomir Mar 20 2015 at 16:38

Вроде как в нашей отрасли еще никто не жаловался на безработицу и невозможность заработать на жизнь программированием в более интересных сферах.

В том числе кстати и в энтерпрайзе, но других его областях.

a553 Mar 20 2015 at 16:42

В энтерпрайз не только, и не столько за деньгами ходят. :)

За деньгами ходят в стартапы. В энтерпрайз ходят за стабильностью и спокойствием.

semmaxim Mar 21 2015 at 08:16

Это очень сильно зависит от места проживания.

dordzhiev Mar 18 2015 at 10:29

Забыли ссылку на оригинал pragmateek.com/is-wpf-dead-the-present-and-future-of-wpf

VioletTape Mar 18 2015 at 11:50

Это не то, чтобы прямой перевод, а скорее вольное изложение с перепроверкой. Некоторые пункты в статье не соответствовали положению дел, какие-то лишь частично. Что-то дополнилось, что-то сократилось. Но в целом указать можно, как вдохновителя и отправную точку =)

Если указать, что это перевод, то будет больше наездов, что не дословно, а пересказ какой-то и мол отсебятины много. Так что взвесив все за и против, от перевода отказались.

cyber_roach Mar 18 2015 at 10:42

Могу лишь подтвердить фактом: уже 7 лет пишем различное ПО на WPF (в основном субподряд на интеграцию дизайна, но и под ключ решения тоже), и в последний год со стороны заказчиков крупного корпоративного сектора интерес большой к технологии, как никогда.

id9999 Mar 18 2015 at 11:52

Фриланс. По ощущениям заказов с WPF стало ощутимо меньше. Зато еще больше стало заказов на web решения.

hudson Mar 18 2015 at 11:54

Все-таки спрошу, а что дальше? Не смотря на наличие позитивных сдвигов, которые вы описали выше, WPF так или иначе будет сходить на нет после, скажем, релиза Win10 и его расползания по девайсам (десктопы, планшеты, телефоны...). Куда копать, чтобы не остаться на обочине?

Vedomir Mar 18 2015 at 11:59

Web и Xamarin?

hudson Mar 18 2015 at 12:04

Я как-то привык считать, что web это одно, а десктоп — совсем другое… Хотя сейчас конечно даже для мобильников пишут на HTML/JS (PhoneGap/Cordova), но оно ведь не сильно эффективно получается, очень непросто все с производительностью. Xamarin же сейчас насколько я понимаю на пороге большого прорыва, из-за открытия исходников .Net, но пока это все не Production-ready же?

Nagg Mar 18 2015 at 12:13

Есть еще новый www.telerik.com/nativescript он выглядит горааааздо интереснее Xamarin.Forms (который за год так и не стал менее унылым).
У обычного Xamarin ниша есть и спрос растёт, но не будет большим. На нем имеет смысл писать только при двух условиях:
— много общей логики на клиенте
— у вас под рукой дешевый дотнетчик
при этом оно не будет запускаться мгновенно и вы будете бороться с кучей утекающих грефов при сложном интерфейсе (android).

Vedomir Mar 18 2015 at 13:20

Для Microsoft-десктопа я вменямых перспектив не вижу. Microsoft просто полностью забросила это направление, что особенно хорошо заметно на фоне быстрого развития ASP.Net.

Чуть выше уже приводили ссылку на хорошую статью Семь лет WPF: что изменилось?, правда прошло уже 8 лет, но кроме описываемых в ней проблем, есть еще очень серьезные проблемы с производительностью двухмерной графики — причем проблемы именно из-за кривой архитектуры рендеринга, которые как не сложно догадаться тоже никто не собирается решать — вот здесь исследование A Critical Deep Dive into the WPF Rendering System, из-за чего даже HTML5 в современных браузерах работает быстрее. Добавим к этому принципиальное нежелание Microsoft пускать WPF приложения в магазин…

Одним словом еще одни WinForms, которые, кстати говоря, работают сильно быстрее и на старых и дешевых компах это хорошо заметно даже у очень простых приложений.

Xamarin же сейчас насколько я понимаю на пороге большого прорыва, из-за открытия исходников .Net, но пока это все не Production-ready же?

Я имел в виду скорее миграцию в веб-разработку и мобильные платформы, в случае с Xamarin все-таки значительная часть знаний по .Net будет использована повторно.

Когда я обдумывал перспективы для настольного хобби-проекта ничего лучше встраивание в приложение браузера и использования для интерфейса HTML не пришло в голову — в конце концов разработчик Evernote тоже пошли этим путем и перешли Chromium Embedded Framework из-за проблем с производительностью в WPF.

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

blog.evernote.com/blog/2010/10/26/evernote-4-for-windows-is-here/

hudson Mar 18 2015 at 13:33

Спасибо. Будем смотреть как оно попрет дальше…

PsyHaSTe Mar 19 2015 at 15:42

Ятп принципиальное нежелание выпускать WPF в магазин как раз связано с их желанием максимально быстро похоронить это направление.

naum Mar 21 2015 at 09:44

Xamarin, не смотря на периодические мелкие неприятности, чуть более, чем production-ready, и да, PhoneGap тоже.

FoxCanFly Mar 18 2015 at 12:20

А зачем он, если есть Qt?

Athari Mar 18 2015 at 14:55

Сделают Qt5 для .NET — сообщите. Желающих с C# переходить на C++ немного.

naum Mar 18 2015 at 15:48

Сделали, кстати, немного осталось. QtSharp вполне :)

Athari Mar 18 2015 at 21:24

Где можно больше почитать, посмотреть и пощупать? В документации нашёл только мутную инструкцию по сборке. На сайте Mono QtSharp упомянут как «in early development». В гугле хоть шаром покати. Количество звёзд у репозитория тоже не внушает уверенности в готовости решения.

AllexIn Mar 18 2015 at 20:31

Писать такие вбросы в статье про WPF, где очевидно большая часть читателей комментариев — пользователи и любители WPF — это хабросамоубийство…

Я тоже люблю Qt, но зачем об этом знать пользователям читающим про WPF?

Athari Mar 18 2015 at 21:31

Это не стан PHPшников, тут вбросы так близко к сердцу не принимают, если судить по соотношению плюсов и минусов. Всё-таки дотнетчики в себе и своём выборе больше уверены. :)

Но раскрыть тему не помешало бы, да. Qt — вещь кроссплатформенная и с байндингами для многих языков, потому потенциально интересна дотнетчикам. К сожалению, с дотнетовыми байндингами для актуальной версии Qt, которая и представляет интерес, всё не так хорошо, как хотелось бы.

Vedomir Mar 20 2015 at 08:57

Вопрос скорее в C++.

Shrike Mar 18 2015 at 22:25

Боюсь, что чтобы оживить wfp, недостаточно начать писать в блог спустя 5 лет. Кроме того, очевидно это уже другая команда.
Так что пациент скорее мертв.
На вопрос «что делать» ответ — web.

imanushin Mar 19 2015 at 01:40

Странное решение: ведь WPF сделан не для web'а. На тему мертвости: его же используют, хотя могли бы и развлекаться с WinForms, студия прекрасно их поддерживает.

Vedomir Mar 20 2015 at 08:48

Используют массу мертвых технологий вроде PHP4, Delphi 6, WinForms или вообще COBOL и программ под DOS. В промышленной среде старые системы вообще живут очень долго.

Вопрос в другом — есть ли смысл изучать и осваивать WPF сейчас если он до сих пор не используется? Оправдано ли такое вложение времени и средств с точки зрения дальнейших перспектив технологии?

Web здесь рассматривается скорее с точки зрения применимости в реальных задачах — которые в случае с LOB очень часто представляют с собой много-много форм и табличек с записью и чтением из базы, для чего современного Web вполне хватит и каких-то особых преимуществ WPF не дает.

toxicdream Mar 20 2015 at 20:33

Про Делфи тоже так говорили…

novar Mar 21 2015 at 05:11

в понедельник, 23 марта, команда WPF будет «вживую» отвечать на вопросы, в том числе о будущем WPF
blogs.msdn.com/b/visualstudio/archive/2015/03/20/connect-live-wpf-team-live-q-and-a.aspx

UFO just landed and posted this here