Здравствуйте, MxMsk, Вы писали:
MM>Мне вообще теперь кажется, что весь топик для adontz'а был чисто поржать. А что, судя по смайликам, ни один ответ он всерьез не воспринял
Дорогой Марат, ты сперва внедри приложение с компании с >100 рабочих мест и инфрастуктурой проектировки 5-летней давности, а потом мы поговорим о том как это ржачно.
Моё личное мнение заключается в том что:
1) WinForms — ужасно. Причём даже не WinForms, а оконная система Windows, которую WinForms оборачивает и немножечко улучшает (как и MFC). Делать нестандартные элементы управления трудоёмко, делать резиновые интерфейсы трудоёмко.
2) WPF — перспективная система. Я не считаю что она перешла в состояние mature, к 5-6 версии будет окончательно понятно куда она двигается. Но уже можно пользоваться.
3) Ничего лучше HTML + CSS человечество пока не придумало. Я бы с огромным удовольствием делал все интерфейсы на HTML, если бы текущие движки не интегрировались с .Net так плохо.
4) Моё мнение в трх предыдущих пуктах никого на хер не волнует. Надо писать то, что потом можно безболезненно внедрить. Важна полная стоимость владения и интеграторы могут отыгрываться за счёт программистов, требуя программы работающие в устаревших, нестандартных, ограниченных средах. Это нормально, так устроен бизнес. Я уже не раз переступал через себя, создавая идеологически неправильные решения. И ещё не раз переступлю, потому что идеологически правильные решения обходились в конечном итоге дороже, а желание кушать приоритетнее желания гордиться собой.
Давай я тебе объясню проще, с описанием тех этапов, которые тебе, как программисту, не видны.
Хороший, но идеологически неправильный, сценарий:
1) Создать приложение на WinForms — 1000 человеко-часов.
2) Внедрили в срок. Потрачено 1000 часов программистов, все довольны.
Плохой, но идеологически правильный, сценарий:
1) Создать приложение на WPF — 300 человеко-часов.
2) Объяснить менеджменту клиента почему старая программа не тормозила, а новая тормозит. Вероятность потерять контракт — 35%.
3) Оптимизировать конкретные окна WPF приложения, вычищая всю ту красоту, которую раньше наворотили — 100 человеко-часов.
4) Обновить драйвера видеокарты на всех целевых компьютерах — 200 человеко-часов.
5) Объяснить менеджменту клиента зачем это было надо.
6) Узнать что из 100 компьютеров на 20 программа вообще не запуститься и их надо заменять...
7) Объяснить менеджменту клиента зачем это надо, подобрать минимальную (самую дешёвую) конфигурацию. Трата незапланированная, финансовый менеджер смотрит на вас как на врагов.
8) С ужасом обнаружить что сама дешёвая конфигурация, пожалуй, слишком дешёвая.
9) Оптимизировать конкретные окна WPF приложения, вычищая всю ту красоту, которую раньше наворотили, чтобы работано на самой дешёвой конфигурации, — 200 человеко-часов.
10) Выяснить что ест удалённый офис в крыжопинске откуда заходят по терминальной сессии. Пообщаться с сисадмином который категорически откажется что-либо менять. Будет представлено множество обоснований: мнешных для вас, весомых для его начальства. Многократно прозвучат слова безопасностьи стабильность.
11) Надо покупать новый терминальный сервер/менять процессов в старом. Сервер скорее всего с процессором Intel. Это вам не AMD, где в материнку трёхлетней давности можно запросто воткнуть новый процессор и запустить его перепрошив БИОС. Придётся менять с процессором материнку и память. И винчестеры, потому что HP. Финансовый директор ведёт себя вызывающе, откровенно подтрунивает над навыками планирования и бюджетирования.
12) Кое-как внедрили с опозданием. Потрачено 600 часов программистов, 200 админов, миллиарды мёртвых клеток в головном мозге менеджмента. Клиент не особо доволен, финансового менеджера вы избегаете.
Здравствуйте, adontz, Вы писали:
A>Дорогой Марат, ты сперва внедри приложение с компании с >100 рабочих мест и инфрастуктурой проектировки 5-летней давности, а потом мы поговорим о том как это ржачно.
Хорошо.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, MxMsk, Вы писали:
MM>>Мне вообще теперь кажется, что весь топик для adontz'а был чисто поржать. А что, судя по смайликам, ни один ответ он всерьез не воспринял
A>Дорогой Марат, ты сперва внедри приложение с компании с >100 рабочих мест и инфрастуктурой проектировки 5-летней давности, а потом мы поговорим о том как это ржачно.
А нахрена в такой ситуации внедрять чтонить кроме веб-решений с его html\css?
Здравствуйте, gandjustas, Вы писали:
G>А нахрена в такой ситуации внедрять чтонить кроме веб-решений с его html\css?
Часто приходится общатся с разной аппаратурой.
1) Печатать сразу на нескольких принтерах в рамках оформления одного документа: счёт-фактуру на матричном, чтобы пробило на все страницы (там копирка), накладную на лазерном, стикер для коробки с товаром на термопринтере.
2) Получать данные со сканеров штрихкода сидящих на СОМ порту (да такой ужас ещё встречается).
3) Бывают случаи, когда надо уметь отличать ввод одних и тех же данных (последовательности символов) между клавиатурой и USB сканером.
Время отклика очень важно опять же. Реальный случай. Складские работники жаловались на время отклика при сканировании. А склад это вообще место очень бурной деятельности. По утрам писки от сканеров штрихкодов сливаются в непрерывный звук. Им уже всё вылизали как могли. Так вот, эти товарищи замечали смену размера MTU. А от склада до серверов была выделенная волоконно-оптическая гигабитная линия. И вот им подобрали такой MTU, чтобы пакеты не фрагментировались и они это заметили. То есть сами(!) позвонили и спросили "У нас лучше стало работать, вы что-то поменяли?". Я бы не поверил, если бы не присутствовал сам.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>А нахрена в такой ситуации внедрять чтонить кроме веб-решений с его html\css?
A>Часто приходится общатся с разной аппаратурой. A>1) Печатать сразу на нескольких принтерах в рамках оформления одного документа: счёт-фактуру на матричном, чтобы пробило на все страницы (там копирка), накладную на лазерном, стикер для коробки с товаром на термопринтере. A>2) Получать данные со сканеров штрихкода сидящих на СОМ порту (да такой ужас ещё встречается). A>3) Бывают случаи, когда надо уметь отличать ввод одних и тех же данных (последовательности символов) между клавиатурой и USB сканером.
А как же кейс с удаленным рабочим столом?
Веб-интерфейс удовлетворит 99% пользователей, а оставшийся 1% можно покрыть другими способами: activex или отдельное приложение.
A>Время отклика очень важно опять же. Реальный случай. Складские работники жаловались на время отклика при сканировании. А склад это вообще место очень бурной деятельности. По утрам писки от сканеров штрихкодов сливаются в непрерывный звук. Им уже всё вылизали как могли. Так вот, эти товарищи замечали смену размера MTU. А от склада до серверов была выделенная волоконно-оптическая гигабитная линия. И вот им подобрали такой MTU, чтобы пакеты не фрагментировались и они это заметили. То есть сами(!) позвонили и спросили "У нас лучше стало работать, вы что-то поменяли?". Я бы не поверил, если бы не присутствовал сам.
Отзывчивость интерфейса зависела от латентности сетевого взаимодействия? Видимо надо было асинхронные сетевые вызовы делать. В вебе кстати так и делают.
Здравствуйте, gandjustas, Вы писали:
A>>1) Печатать сразу на нескольких принтерах в рамках оформления одного документа: счёт-фактуру на матричном, чтобы пробило на все страницы (там копирка), накладную на лазерном, стикер для коробки с товаром на термопринтере. A>>2) Получать данные со сканеров штрихкода сидящих на СОМ порту (да такой ужас ещё встречается). A>>3) Бывают случаи, когда надо уметь отличать ввод одних и тех же данных (последовательности символов) между клавиатурой и USB сканером. G>А как же кейс с удаленным рабочим столом?
RDP позволяет прокидывать принтеры (несколько) и порты. Для принтеров есть ещё ThinPrint.
G>Веб-интерфейс удовлетворит 99% пользователей, а оставшийся 1% можно покрыть другими способами: activex или отдельное приложение.
Ну знаешь, нет никакого смысла писать веб И отдельное приложение. Это разнопрофильные группы разработчиков и многие другие проблемы.
G>Отзывчивость интерфейса зависела от латентности сетевого взаимодействия? Видимо надо было асинхронные сетевые вызовы делать. В вебе кстати так и делают.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>1) Печатать сразу на нескольких принтерах в рамках оформления одного документа: счёт-фактуру на матричном, чтобы пробило на все страницы (там копирка), накладную на лазерном, стикер для коробки с товаром на термопринтере. A>>>2) Получать данные со сканеров штрихкода сидящих на СОМ порту (да такой ужас ещё встречается). A>>>3) Бывают случаи, когда надо уметь отличать ввод одних и тех же данных (последовательности символов) между клавиатурой и USB сканером. G>>А как же кейс с удаленным рабочим столом?
A>RDP позволяет прокидывать принтеры (несколько) и порты.
То что можно так делать, не значит что нужно.
G>>Веб-интерфейс удовлетворит 99% пользователей, а оставшийся 1% можно покрыть другими способами: activex или отдельное приложение.
A>Ну знаешь, нет никакого смысла писать веб И отдельное приложение. Это разнопрофильные группы разработчиков и многие другие проблемы.
Как раз-таки смысл есть. Отдельное приложение общается с сервером и вся логика находится там. На клиенте только простой интерфейс и взаимодействие с железками.
Сейчас вообще есть отличная возможность с out-of-browser silverlight в elevated режиме. Можно и печатать и com вызывать, и веб, и не нужны терминальные сессии.
G>>Отзывчивость интерфейса зависела от латентности сетевого взаимодействия? Видимо надо было асинхронные сетевые вызовы делать. В вебе кстати так и делают. A>Приложение находится в терминальной сессии.
Здравствуйте, gandjustas, Вы писали:
A>>RDP позволяет прокидывать принтеры (несколько) и порты. G>То что можно так делать, не значит что нужно.
В действительности, бывает что нужно. Если, например, используется ThinPrint.
A>>Ну знаешь, нет никакого смысла писать веб И отдельное приложение. Это разнопрофильные группы разработчиков и многие другие проблемы. G>Как раз-таки смысл есть. Отдельное приложение общается с сервером и вся логика находится там. На клиенте только простой интерфейс и взаимодействие с железками. G>Сейчас вообще есть отличная возможность с out-of-browser silverlight в elevated режиме. Можно и печатать и com вызывать, и веб, и не нужны терминальные сессии.
Терминальные сессии нужны по многим причинам. В плане железо+лицензии рабочее место может обходится даже немного дороже, выгода там в простоте администрирования. Ну и в любом случае, это не программисты решают.
G>>>Отзывчивость интерфейса зависела от латентности сетевого взаимодействия? Видимо надо было асинхронные сетевые вызовы делать. В вебе кстати так и делают. A>>Приложение находится в терминальной сессии. G>
Ну да, представь себе что отзывчивость терминальной сессии зависит от MTU настолько, что это заметно человеку.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>Ну знаешь, нет никакого смысла писать веб И отдельное приложение. Это разнопрофильные группы разработчиков и многие другие проблемы. G>>Как раз-таки смысл есть. Отдельное приложение общается с сервером и вся логика находится там. На клиенте только простой интерфейс и взаимодействие с железками. G>>Сейчас вообще есть отличная возможность с out-of-browser silverlight в elevated режиме. Можно и печатать и com вызывать, и веб, и не нужны терминальные сессии.
A>Терминальные сессии нужны по многим причинам. В плане железо+лицензии рабочее место может обходится даже немного дороже, выгода там в простоте администрирования. Ну и в любом случае, это не программисты решают.
Суть в том что обе рассматриваемые технологии winforms и wpf для решения таких задач подходят крайне плохо. Первая по причине ущербности, вторая по причине прожорливости, обе по сложности установки\обновления или использованию терминалов. Как я уже говорил решение на вебе подойдет в подавляющем большинстве случаев, там где не хватит возможностей html\css\js можно подключить sl\flash\activex\java, самый крайняк использовать отдельное приложение которое общается с сервером.
Здравствуйте, evo, Вы писали:
evo>Как вы считаете, если сейчас начал изучать .NET и C# стоит ли учить winforms или сразу переходить к WPF. Немножко пробовал winforms и на первый взгляд все просто и логично. С WPF почти не знаком. Читал, что учить значительно труднее. Сложно сделать выбор, когда так мало знаешь. Гуглил этот вопрос и однозначного ответа не нашел. Лично мне было бы интереснее начать с WPF, но не хочется, чтоб получилось так, что много где еще нужны winforms, а я не буду их знать.
Винформы до безобразия просты, хватит буквально одной недели чтобы изучить все, причем большую часть времени ты потратишь на databinding и grid.
WPF гораздо сложнее, библиотека классов побольше и возможностей больше на порядок, кроме того подмножество WPF используется в Silverlight и Windows Phone 7, поэтому изучать его обязательно. Кстати начинать изучать я бы рекомендовал именно с Silverlight.
Здравствуйте, gandjustas, Вы писали:
A>>Терминальные сессии нужны по многим причинам. В плане железо+лицензии рабочее место может обходится даже немного дороже, выгода там в простоте администрирования. Ну и в любом случае, это не программисты решают. G>Суть в том что обе рассматриваемые технологии winforms и wpf для решения таких задач подходят крайне плохо. Первая по причине ущербности, вторая по причине прожорливости, обе по сложности установки\обновления или использованию терминалов.
Честно говоря, я даже не понял что ты хотел сказать.
G>Как я уже говорил решение на вебе подойдет в подавляющем большинстве случаев, там где не хватит возможностей html\css\js можно подключить sl\flash\activex\java, самый крайняк использовать отдельное приложение которое общается с сервером.
ИМХО это решение может быть оптимально при командах от 10 выделенных разработчиков на проект.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>Терминальные сессии нужны по многим причинам. В плане железо+лицензии рабочее место может обходится даже немного дороже, выгода там в простоте администрирования. Ну и в любом случае, это не программисты решают. G>>Суть в том что обе рассматриваемые технологии winforms и wpf для решения таких задач подходят крайне плохо. Первая по причине ущербности, вторая по причине прожорливости, обе по сложности установки\обновления или использованию терминалов. A>Честно говоря, я даже не понял что ты хотел сказать.
В этом и проблема. Надо это понимать.
G>>Как я уже говорил решение на вебе подойдет в подавляющем большинстве случаев, там где не хватит возможностей html\css\js можно подключить sl\flash\activex\java, самый крайняк использовать отдельное приложение которое общается с сервером. A>ИМХО это решение может быть оптимально при командах от 10 выделенных разработчиков на проект.
Я один поднимал такое решение.
Здравствуйте, gandjustas, Вы писали:
A>>>>Терминальные сессии нужны по многим причинам. В плане железо+лицензии рабочее место может обходится даже немного дороже, выгода там в простоте администрирования. Ну и в любом случае, это не программисты решают. G>>>Суть в том что обе рассматриваемые технологии winforms и wpf для решения таких задач подходят крайне плохо. Первая по причине ущербности, вторая по причине прожорливости, обе по сложности установки\обновления или использованию терминалов. A>>Честно говоря, я даже не понял что ты хотел сказать. G>В этом и проблема. Надо это понимать.
Напустить на себя таинственность ты сумел, теперь расскажи по существу почему WinForms и WPF одинаково плохо подходят для терминальной сессии.
G>>>Как я уже говорил решение на вебе подойдет в подавляющем большинстве случаев, там где не хватит возможностей html\css\js можно подключить sl\flash\activex\java, самый крайняк использовать отдельное приложение которое общается с сервером. A>>ИМХО это решение может быть оптимально при командах от 10 выделенных разработчиков на проект. G>Я один поднимал такое решение.
Решения которые может создать один программист вообще не интересно рассматривать.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>>>Терминальные сессии нужны по многим причинам. В плане железо+лицензии рабочее место может обходится даже немного дороже, выгода там в простоте администрирования. Ну и в любом случае, это не программисты решают. G>>>>Суть в том что обе рассматриваемые технологии winforms и wpf для решения таких задач подходят крайне плохо. Первая по причине ущербности, вторая по причине прожорливости, обе по сложности установки\обновления или использованию терминалов. A>>>Честно говоря, я даже не понял что ты хотел сказать. G>>В этом и проблема. Надо это понимать.
A>Напустить на себя таинственность ты сумел, теперь расскажи по существу почему WinForms и WPF одинаково плохо подходят для терминальной сессии.
Вообще терминальная сессия плохо подходит для решения бизнес-задач, независимо от того что там крутится. Повышенная нагрузка на сеть, ограничение на UI, доступно далеко не с любого устройства, сложно масштабировать\балансировать нагрузку, повышенные административные затраты на управление правами пользователей. Короче дофига недостатков, которые в вебе не появляются вообще никак.
G>>>>Как я уже говорил решение на вебе подойдет в подавляющем большинстве случаев, там где не хватит возможностей html\css\js можно подключить sl\flash\activex\java, самый крайняк использовать отдельное приложение которое общается с сервером. A>>>ИМХО это решение может быть оптимально при командах от 10 выделенных разработчиков на проект. G>>Я один поднимал такое решение.
A>Решения которые может создать один программист вообще не интересно рассматривать.
А какая разница? Если у меня хватило навыков чтобы создать веб-приложение, которое работает на десктопе, на киоске с тачскрином и на мобильном устройстве, а также написать на SL код, который позволил печатать на киоске и на десктопе то что нужно, то почему другой программист не сможет такое сделать? Если будет больше одного такого программиста, то результат будет только лучше.
Здравствуйте, gandjustas, Вы писали:
G> Повышенная нагрузка на сеть
Это неправда. Нагрузка, в действительности, снижается. Есть некоторый порог, после которого объём изменений видеокадра меньше объёма обрабатываемых данных. К тому же отпадает вопрос о постраничном выводе как таковой. Ч терминалом можно (правда плохо, но можно) работать даже через GPRS.
G> ограничение на UI
По сравнению с чем? Ты утверждаешь что веб (HTML или Silverlight) лучше WinForms или WPF. Разница между Silverlight и WPF не заметна в микроскоп. Веб-браузер не даст тебе свободы в UI. Даже клавиатурное сокращение толком назначить нельзя. Про принтеры я уже говорил.
G> доступно далеко не с любого устройства
Silverlight или продвинутый движок HTML тоже.
G> сложно масштабировать\балансировать нагрузку
Это неправда. Ставишь второй терминал, настраиваешь NLB, забываешь о проблеме. Я работал с фермами терминалов, никакой проблемы масштабирования там нет.
G> повышенные административные затраты на управление правами пользователей.
Тоже не правда. Наоборот, в среде развитого домена Active Directory тебе вообще не надо что-либо настраивать, потому что все пользователи уже есть, уже объединены в группы и т.д.
G> Короче дофига недостатков, которые в вебе не появляются вообще никак.
В общем ты просто не умеешь их готовить.
A>>Решения которые может создать один программист вообще не интересно рассматривать. G>А какая разница? Если у меня хватило навыков чтобы создать веб-приложение, которое работает на десктопе, на киоске с тачскрином и на мобильном устройстве, а также написать на SL код, который позволил печатать на киоске и на десктопе то что нужно, то почему другой программист не сможет такое сделать? Если будет больше одного такого программиста, то результат будет только лучше.
Сколько стоит программист у которого хватит навыков? Сколько стоят два таких программиста (один мало, риски)? Зачем платить больше?
Здравствуйте, gandjustas, Вы писали:
G>Кстати начинать изучать я бы рекомендовал именно с Silverlight.
Я бы не рекомендовал. Оно безумно урезано, особенно SL 3. То, что в WPF решается не задумываясь, в SL регулярно превращается в ругань и гору костылей.
DataTrigger-ы, команды, multibinding, FlowDocument, {DynamicResource}, биндинг к xpath, объединение ресурсов, наследование стилей — это только то, что я с ходу вспомнил; если покопаться — наберу раза в 2 больше. Большей части нет в SL4 и даже в 5. Ну и нафига?
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, MxMsk, Вы писали:
MM>>Мне вообще теперь кажется, что весь топик для adontz'а был чисто поржать. А что, судя по смайликам, ни один ответ он всерьез не воспринял
A>Дорогой Марат, ты сперва внедри приложение с компании с >100 рабочих мест и инфрастуктурой проектировки 5-летней давности, а потом мы поговорим о том как это ржачно.
Рецепт от adontz: выбрать технологию неподходящую для чего-либо и на этом основании раскритиковать ее целиком забив на все остальные возможности применения.
Как насчет того, чтобы сравнивать WinForms и WPF там где ОБЕ технологии уместны?
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>> Повышенная нагрузка на сеть A>Это неправда. Нагрузка, в действительности, снижается. Есть некоторый порог, после которого объём изменений видеокадра меньше объёма обрабатываемых данных.
У нас видимо разные "действительности". Веб + ajaj + json + http compression, и меньше передавать уже вряд ли получится. Около килобайта на раундтрип при очень data-intensive приложении. Еще и клиентское кеширование есть.
A>К тому же отпадает вопрос о постраничном выводе как таковой.
Не отпадает потому что постраничный нужен в первую очередь для человека.
A>Ч терминалом можно (правда плохо, но можно) работать даже через GPRS.
Очень плохо, но можно — считай нельзя.
G>> ограничение на UI A>По сравнению с чем? Ты утверждаешь что веб (HTML или Silverlight) лучше WinForms или WPF.
Угу, потому что работает на любой оси и на мобильных устройствах.
A>Разница между Silverlight и WPF не заметна в микроскоп.
Ты видимо очень много на SL писал что так утверждаешь.
A>Веб-браузер не даст тебе свободы в UI. Даже клавиатурное сокращение толком назначить нельзя.
Перехватывай нажатие клавиш и обрабатывай, в чем проблема?
G>> доступно далеко не с любого устройства A>Silverlight или продвинутый движок HTML тоже.
Да ну? HTML4 доступен чуть менее чем везде, HTML 5 доступен на любом десктопе. А что насчет remote desktop?
G>> сложно масштабировать\балансировать нагрузку A>Это неправда. Ставишь второй терминал, настраиваешь NLB, забываешь о проблеме. Я работал с фермами терминалов, никакой проблемы масштабирования там нет.
Это на словах просто, а на деле не каждый админ потянет. По сравнению с масштабированием веб-решений на порядок сложнее.
G>> повышенные административные затраты на управление правами пользователей. A>Тоже не правда. Наоборот, в среде развитого домена Active Directory тебе вообще не надо что-либо настраивать, потому что все пользователи уже есть, уже объединены в группы и т.д.
Я не про AD, его можно и в вебе использовать, я про разрешения на сервере терминалов и в приложении.
G>> Короче дофига недостатков, которые в вебе не появляются вообще никак. A>В общем ты просто не умеешь их готовить.
Недостатки? Конечно!
A>>>Решения которые может создать один программист вообще не интересно рассматривать. G>>А какая разница? Если у меня хватило навыков чтобы создать веб-приложение, которое работает на десктопе, на киоске с тачскрином и на мобильном устройстве, а также написать на SL код, который позволил печатать на киоске и на десктопе то что нужно, то почему другой программист не сможет такое сделать? Если будет больше одного такого программиста, то результат будет только лучше.
A>Сколько стоит программист у которого хватит навыков? Сколько стоят два таких программиста (один мало, риски)? Зачем платить больше?
Ну программисты на вебе, как ни странно, стоят дешевле админов, умеющих NLB поднимать.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Кстати начинать изучать я бы рекомендовал именно с Silverlight. S>Я бы не рекомендовал. Оно безумно урезано, особенно SL 3. То, что в WPF решается не задумываясь, в SL регулярно превращается в ругань и гору костылей.
Дык если изучать, то SL5.
S>DataTrigger-ы, команды, multibinding, FlowDocument, {DynamicResource}, биндинг к xpath, объединение ресурсов, наследование стилей — это только то, что я с ходу вспомнил; если покопаться — наберу раза в 2 больше. Большей части нет в SL4 и даже в 5. Ну и нафига?
1)Большинство нафиг не нужно
2)SL это не только веб, но и windows phone
3)SL используется сейчас гораздо чаще WPF
ЗЫ. Мне вообще-то искренне жаль людей, которые сначала освоили WPF, а потом пересели на SL.
