ШайтанOYM,

MS обещали поддерживать SL только до 2021 г.
Так это ж целая вечность по айтишным меркам!

А вообще, видя, как "умирает" флеш, как мчится на всех парах в никуда джаваскрипт с ХТМЛ5, собирая и накапливая костыли со скоростью света, и как Гугл вовсю продвигает свои фреймворки (дартсы там всякие) на десктопы, МС может и продолжить разработку Сильверлайта. Тем более, что Виндоус имеет тренд превратиться в типабесплатную ОС (или очень дешёвую), нет смысла завязывать свои фреймворки на только Виндоус.

Шайтанесли бы M$ не слили SL, я бы лично с ним работал.
Если МС не против распространения своих фреймворков на другие платформы, то зачем тогда СЛ? Сразу весь Дотнет и портировать. Тем более, что в наше время космических скоростей Интернета заставить клиента загрузить полста мегабайт фреймворка (.NET 4.5) как нефиг делать - он даже не заметит. А работать с СЛ после WPF то ещё "удовольствие" - того нет, этого нет, то только наполовину реализовано, другое через задницу. Всё равно приходится искать сторонние библиотеки или самому писать, чуть дело выходит за рамки простейшего ширпотреба. Сконвертить картинку или отмасштабировать её - уже гемор.

OYMuser7320,

А кто из них двоих SL или WPF имеет более низкий порог вхождения?
Примерно одинаковый, т. к. фактически одна и та же технология для программиста и даже синтаксическое окружение (вплоть до названий классов и методов). Но с СЛ больше проблем, причём зачастую возникающих на "ровном месте" - которых в Дотнете нет. И всё из-за идиотских требований малого объёма. Это во времена, когда СЛ только задумывался, ещё как-то канало, чтобы уложить объём плагина-фреймворка в пресловутые 5-10 МБ. В наше время это только создаёт лишний гемор разработчикам. Ну ещё придуркам-МСненавистникам пуканы разрывает от того, что на их любимые линуксы и маки МС лезет, и они начинают придираться "а чё это он скачивается 10 секунд?! я же устану ждать!".

OYMШайтан,

А Вы сейчас работаете с WPF в своих проектах?
Если новый проект под Винду - то только WPF. Там "всё как в формах", и ещё больше. Т. е. тот, кто программировал на формах и привык к ним, может на WPF также продолжать. А кто хочет освоить новые техники и возможности - тоже добро пожаловать. В этом одна из особенностей WPF - угодили старичкам, и новичкам.

Единственное, что может в WPF быть "не так", это когда работа идёт с "высоконагруженным GUI". Т. к. по умолчанию формы работают быстрее WPF, то при перегруженности данными и контролами приложение на WPF требует особого подхода. Почему-то МС "забила" на оптимизацию графических отрисовок WPF, поэтому GDI+ на CPU отрисовывает быстрее, чем WPF на GPU. Ну и плюс WPF имеет вполне определённые требованию к GPU (по большей части к объёму видеопамяти), чтобы собственно отрисовываться на GPU, т. к. если эти требования не выполняются, то отрисовка идёт на CPU. По крайней мере, проблемы с производительностю были актуальны для WPF пару-тройку лет назад. Сейчас, думаю, мало что поменялось, т. к. МС WPF слабо развивает.

Вобщем, когда дело доходит до производительности и высоких нагрузок на десктопе, то если в формах достаточно поиграться с виртуализацией, в WPF надо к этому добавить игры с кешированием, компоновкой (неправильный порядок или использование "не тех" контейнеров может существенно сказаться на производительности) и аппаратным обеспечением (даже для HelloWorld надо 256 МБ видеопамяти, чтобы не знать проблем с переходом на софтовый рендеринг, для более крутых приложений - соответственно больше).

user7320Шайтанесли бы M$ не слили SL, я бы лично с ним работал.
Если МС не против распространения своих фреймворков на другие платформы, то зачем тогда СЛ? Сразу весь Дотнет и портировать. Тем более, что в наше время космических скоростей Интернета заставить клиента загрузить полста мегабайт фреймворка (.NET 4.5) как нефиг делать - он даже не заметит. А работать с СЛ после WPF то ещё "удовольствие" - того нет, этого нет, то только наполовину реализовано, другое через задницу. Всё равно приходится искать сторонние библиотеки или самому писать, чуть дело выходит за рамки простейшего ширпотреба. Сконвертить картинку или отмасштабировать её - уже гемор.

OYMuser7320,

А кто из них двоих SL или WPF имеет более низкий порог вхождения?
Примерно одинаковый, т. к. фактически одна и та же технология для программиста и даже синтаксическое окружение (вплоть до названий классов и методов). Но с СЛ больше проблем, причём зачастую возникающих на "ровном месте" - которых в Дотнете нет. И всё из-за идиотских требований малого объёма. Это во времена, когда СЛ только задумывался, ещё как-то канало, чтобы уложить объём плагина-фреймворка в пресловутые 5-10 МБ. В наше время это только создаёт лишний гемор разработчикам. Ну ещё придуркам-МСненавистникам пуканы разрывает от того, что на их любимые линуксы и маки МС лезет, и они начинают придираться "а чё это он скачивается 10 секунд?! я же устану ждать!".

OYMШайтан,

А Вы сейчас работаете с WPF в своих проектах?
Если новый проект под Винду - то только WPF. Там "всё как в формах", и ещё больше. Т. е. тот, кто программировал на формах и привык к ним, может на WPF также продолжать. А кто хочет освоить новые техники и возможности - тоже добро пожаловать. В этом одна из особенностей WPF - угодили старичкам, и новичкам.

Единственное, что может в WPF быть "не так", это когда работа идёт с "высоконагруженным GUI". Т. к. по умолчанию формы работают быстрее WPF, то при перегруженности данными и контролами приложение на WPF требует особого подхода. Почему-то МС "забила" на оптимизацию графических отрисовок WPF, поэтому GDI+ на CPU отрисовывает быстрее, чем WPF на GPU. Ну и плюс WPF имеет вполне определённые требованию к GPU (по большей части к объёму видеопамяти), чтобы собственно отрисовываться на GPU, т. к. если эти требования не выполняются, то отрисовка идёт на CPU. По крайней мере, проблемы с производительностю были актуальны для WPF пару-тройку лет назад. Сейчас, думаю, мало что поменялось, т. к. МС WPF слабо развивает.

Вобщем, когда дело доходит до производительности и высоких нагрузок на десктопе, то если в формах достаточно поиграться с виртуализацией, в WPF надо к этому добавить игры с кешированием, компоновкой (неправильный порядок или использование "не тех" контейнеров может существенно сказаться на производительности) и аппаратным обеспечением (даже для HelloWorld надо 256 МБ видеопамяти, чтобы не знать проблем с переходом на софтовый рендеринг, для более крутых приложений - соответственно больше).
Но если вы думаете, что после всего этого WPF надо послать далеко и надолго, то попробуйте какое-нибудь Qt или джаваскрипт с ХТМЛем. Там (особенно на ХТМЛ) люди до сих пор детсадовскими проблема занимаются, типа борьбы с фрагментацией платформ, совместимостью и неразберихой с библиотеками. И это не говоря уже об убогих возможностях по собственно построению интерфейса. Там, где на WPF просто берёшь и делаешь, на ХТМЛ маешься дурью и пудришь мозги работодателю в отчётах, типа "поправлял скруглённые уголки и градиентики - 12 часов".