Не буду перечислять орфографические и грамматические ошибки в этой статье Enterprise-уровня. Перейду к основным замечаниям по существу.
>> Некоторый отличия я перечислю:
[Список достоинств языка А]
[Список недостатков языка В]
Очевидно, что в оба списка можно добавить пунктов типа «плюс» и типа «минус». Здесь результат зависит от цели. Начиная с этих двух списков, первый из которых перечисляет достоинства языка А, а второй — недостатки языка В, цель становится достаточно ясна.
Тем не менее, стоит отметить, что «недостатки» языка легко становятся его достоинствами. Так, Actionscript намного проще для изучения веб-разработчиками, поскольку он имеет много общего с очень популярным Javascript. Он добавляет строгую типизацию, отладку, профайлинг, многократное повышение производительности, продвинутую работу работу с бинарными данными, видео, и звуком, сообщения об ошибках времени выполнения, полную поддержку ООП. И что именно Actionscript стал первым языком, для которого разрабатываются расширения на недавно вышедшей системе мета-программирования MPS 1.0 (скринкасты — по требованию).
По поводу языков хотелось бы также заметить, что Microsoft разрабатывает несомненно инновационные и просто качественные языки — C# хорош. Странно на этом фоне выглядит продолжающееся продвижение VBA / VBscript. Об их противоестествеенные языковые конструкции ломают головы многие программисты, на чью нелегкую долю выпала задача автоматизаци продуктов от Microsoft от Word до Visual Studio. Написание макросов на VBscript до сих пор продвигается Microsoft. Это не вяжется с инновационностью и настощим удобством для разработчика.
>>… код в результате будет неизбежно дилетантский, менее типобезопасный и его сложнее поддерживать.
Столь категоричное утверждение недостойно статьи, претендующей на объективность. Или эта статья на нее не претендует? Хабрахабр всегда казался мне объективным ресурсом, хотелось бы видеть его таким и дальше.
>> Проще говоря — Actionscript работает гораздо…
После этого подозрения в качестве статьи начинают быстро расти. Вообще, стандартном де-факто для сравнения производительности является проведение тестов производительности и анализ их результатов. Здесь этого почему-то нет. Ни стандартных, ни нестандартных, но конкртеных сравнений.
>> Отладчик. Flex Builder 3…
Стоит отметить, что отладчик Flex Builder 3 создается одними из опытных разработчиков дебаггеров, Майком Мориарти, который до Adobe разрабатывал отладчик для Visual Studio. До Adobe он работал десять лет в Microsoft.
>> вам придется убить вашу IDE и перегрузить…
Знаете, во Flex Builder довольно удобный рефакторинг. Конечно, не такой продвинутый, как в Idea, но работает устойчиво, использую его регулярно.
>> Если тест неудачный, достаточно нажать на нем, и он откроет неудачный тестовый метод.
Вообще, это уже сейчас есть во Flash Builder 4. Этим тоже регулярно пользуюсь, и каждлый раз радуюсь. Но стоит отметить, что хотелось бы и поддержки более инновационного Flex Unit 4. Сейчас она требует дополнительных усилий.
Вот иллюстрация: как Flash Builder открывает неудачный тестовый метод:
Как видите, хорошо работает.
>> Статистика производительности берется со старта приложения, а не между двух с слепков.
Ошибка. Во Flex-профайлере можно делать сколь угодно много слепков и сравнивать их. Пожалуйста, вот официальная документация к Flex Builder 3:
Обнаружение проблемных участков приложения. Описаны слепки памяти (Memory Snapshot), обнаружение «блуждающих» объектов (Loitering Objects) и утечек памяти, анализ времени выполнения и т.д.
Проверим это все еще раз, когда у SL будет такой же набор возможностей, как у Flash Player. Начнем после полноценной реализации работы со шрифтом (о типографике пока не говорю):
«Turning the ClearType off will improve the text rendering performance when animating it, since antialiasing requires some additional calculations and performing that for several times per second might result in a jerky animation.»
Ну так когда ставили бету-версии Silverlight 3 Dev Runtime (а то и SDK), вы уже перешли в разряд людей, которые понимают, что такое бета, что такое после беты ставить релиз итд :)
У пользователей таких проблем нет. У них обычный рантайм автоматом обновился до последней версии.
Да, это так, просто я не ожидал, что моя попытка заглянуть в Сильверлайт SDK даст такие глубокие корни… Кстати, с флэш-плейером бывает отдаленно похожая ситуация, когда дебаггер во Flex Builder предупреждает о том, что в браузере установлена «не та» версия плейера, для отладки не подходящая.
Что C Javой сравнение… что тут…
Не ну ествественно ,, Я годами разрабатывал на NET,, ну молодец автор статьи, там и нужно было разрабатывать, зачем пересели, и о какой объективности может идти речь?)
Черкану про подоплеку.
У майкрософта есть определенная политика в отношении партнеров. Это заключается в поддержке партнерской сети за счет предоставления скидок, бесплатное или не сильно платного обучения, материалов, иногда даже готовых к работе клиентов. Майкрософт в создании партнерской среды сейчас, одна из самых, если не самая, успешная компания в мире. Есть разные уровни партнерства. Если вы партнер компании Microsoft, то вы можете претендовать на более близкие отношения за счет улучшения различных показателей, в которые в том числе входит ведение каких-то мероприятий, а так же информационных блогов. В блогах специалисты описывают обычно преимущества решений Microsoft, иногда удачно, иногда не очень. В итоге это все пораждает движуху, когда коллеги этих товарищей, тоже пишут подобные посты. Это очень правильная политика Microsoft. Кстати, если через форумы и блоги помогать людям, можно получить некоторые, очень престижные статусы. Насчет этой статьи высказываться не буду :-)
>> Имея опыт разработки enterprise ПО на .NET платформе фактически с ее зарождения, я недавно сделал перерыв и потратил несколько месяцев на работу с очень большими Flex приложениями.
Не внушает доверия. И хоть сказано, что сравнение сделано в разрезе enterprise приложений, на самом деле все свелось к ахам по поводу плохой «Математики с плавающей запятой», все остальное достаточно надумано, за исключением достаточно отвратного Flex-builder, но кто спорит — VisualStudio очень мощный инструмент.
А вообще если сравнивать по возможностям технологий то, пожалуй, начиная с третьей версии Silverlight уже можно говорить о некоей конкуренции. Хотя на сегодняшний момент все таки Flash/Flex приложения более распространены за счет более раннего старта, а что будет дальше посмотрим.
Строгая типизация просто быстрей. Удобней разработка, поддержка основных принципов ООП, проще реализуются паттерны.
Думаю для больших проектов, где трудится по 20-50 человек, не должно стоять вопроса, какая типизация «лучше».
Было бы интересно еще сравнить JavaFX 1.2 vs. Flex 3 vs. Silverlight 3 в Enterprise разработке.
Не смотря на свою сыроватость, я считаю, JavaFX довольно не плохой игрок в этом разрезе и имеет свои преимущества.
>>В результате этого и других недостатков Actionscript компилятор менее эффективен в определении проблем в момент компиляции. Компиляция медленнее, чем у C# (Flex’у нужно 2 минуты на 100 000 строк кода). Проще говоря — Actionscript работает гораздо медленнее C#.
Откуда из более медленной компиляции берется факт разницы скорости языков?
Несколько однобокая статья, хорошо хоть (буржуйский) автор честно признается, что является фанатом C#.
В качетсве среды разработки не рассматривается IntelliJ IDEA, хотя ReShaper от тех же парней фигурирует.
И вообще, чувствуется неприязнь к динамическим языкам как классу, ведь Actionscript суть Javascript, который хоть и не является ООП-языком в стандартном понимании, объектым и подходящим для больших приложений быть не перестает.
А вы в идее пробовали что то делать для флекса? Эйр к примеру официально поддерживаться будет только в 9 версии. Даже то что есть сейчас выглядит довольно сырым. Хотя некоторые возможности реализованы лучше чем в билдере.
Мне лично пока спайкет для js больше понравился, за счет поддержки ExtJS наверно. Но как 9 ветка идеи, более стабилизируется обязательно посмотрю. Пока у меня сложилось мнение что Idea более удачна как редактор но дебагер в то время отлаживал только веб приложения, в то время как мне более интересны air версии.
Вы пользовались Visual Studio? По-моему из тех, кто ей пользовался хотя бы пол года, еще не видел достойной конкуренции.
И фишка не в подсветке кода или интеллисенсе, а именно в мощном дебагере, который позволяет залезть практически куда угодно.
Плюс к этому мощная поддержка юнит тестов.
> Языки — C# vs. Java
Java. Комментировать не буду.
C# однозначно! Язык Java медленно впитывает инновации (ФП), да и предлагает кучу всяких путей, когда достаточно одного (я люблю, когда есть один хороший путь дклать что-либо, чем несколько так себе путей, особенно в UI).
> MXML vs. XAML
> UI Binder в версии 2.0 вместе с HTML. Можно даже давать править верстальщикам.
Это Вы вашим дизайнерам Expression не давали ))) Мои знакомые дизы пищат
от отсутствия проблем и качественной шаблонизации.
> Компоненты фреймворка
> Базовый набор, работает без нареканий. Ограничения = функционал браузера.
Согласен.
> Сторонние компоненты
> Куча: от официальных интеграций с ExtJS, SmartClient, Dojo до проектов, основанных на самом GWT: Vaadin.
Та же фигня у SL.
> Шаблоны и Практики, Фреймворки и Инверсия управления(IoC)
> Google Guice, Spring.
Тут SL впереди, ибо для .NET очень качественные библиотеки.
Устарело… Правда, и SL тут слаб… Мне в этом плане нравится Ruby.
> Профайлинг
> Java Profiler в Hosted Mode. Firebug/Webkit в поле.
> Примеры кода и документация
> По Java? В избытке. По GWT? Большое сообщество + сам проект OpenSource.
Ява ни разу не клиенский язык не сегодня. А документация в MSDN лучшая на рынке.
> Опыт разработчиков
> Измеряя годами переплюнуть Java-истов сложно. А GWT хоть и молодой, но почти весь на POJO и похож на Swing.
ОоО… мне вот пофиг на чём писать :)
> Установочная база
> 100% — в том числе и мобильные телефоны(по словам разработчиков Google Wave — мобильная версия потребовала лишь небольших изменений в огранизации UI).
Единственный плюс — мобильники и BD. там Java рулит!
> Резюме
> Если нужно RIA без мультимедиа, а back-end на Java: GWT идеальный выбор.
> Это Вы вашим дизайнерам Expression не давали ))) Мои знакомые дизы пищат от отсутствия проблем и качественной шаблонизации.
Наши дизайнеры просят под Mac. Где скачать?
> Тут SL впереди, ибо для .NET очень качественные библиотеки.
Что значит «очень качественные»? На Google Guice работает GMail и вся реклама Google. А через приложение на Spring выплачивается, например, вся зарплата в UK.
> Устарело… Правда, и SL тут слаб… Мне в этом плане нравится Ruby.
Ruby — тормоз, если тестов много. Но если хочется — есть Groovy.
> Ява ни разу не клиенский язык не сегодня. А документация в MSDN лучшая на рынке.
Google своими проектами Google Wave & Android пытается доказать обратное. Если у меня жопа внутри SL — я сижу и жду Microsoft, если жопа внутри GWT — я залезаю внутрь и исправляю: viva la OpenSource!
> Единственный плюс — мобильники и BD. там Java рулит!
Большой минус Silverlight на данный момент — отсутствие поддержки камеры и микрофона.
Но ребята из Microsoft уверяют, что работа в этом направлении ведется…
Каждый, кто работает с флэшем/флексом, представляет недостатки своей платформы, среды разработки и т.п. Со многим из статьи можно согласиться. И все равно текст неприкрыто предвзятый, чего только стоят фразы «дилетантский код», «у флекса предложения ограничены», «Flash/Flex разработчики… не всегда пишут надёжный поддерживаемый код»! А с# разработчики все лапочки и умнички? Ну хвалите себя, хвалите…
И что значит«внутренние модификаторы доступа кажутся слегка бессмысленными»?
Таким образом, при обсуждении модификатора internal можно говорить о дополнительном средстве разделения доступа в Actionscript. Это средство полезно в арсенале разработчика. Internal позволяет обозначить в архитектуре приложения дополнительный уровень доступа, т.е. это фича, добавляющая в Actionscript еще больше ООП :)
Ria это, как правило, тонкий клиент, тесно взаимодействующий с бекендом. И от удобства их связи для програмиста зависист очень многое. Будь то json, или xml по http проколу, или даже rmtp. Соответствующие библиотеки есть почти для всех языков.
Говоря о java посмотрите на эту вещь: ru.wikipedia.org/wiki/BlazeDS
>Flex может работать с любым бэкендом — Java, PHP, Cold Fusion,
Почему Silverlight не может работать с Java, если Java генерирует для работы с ria: xml, json…
Там выше уже сказали о AMF. У Adobe есть реализации для PHP(Zend AMF) & Java(BlazeDS) + есть версии для Python&Ruby от сообщества. Чем AMF лучше XML/JSON написано в Wikipedia.
Что-то я не пойму, к чему вы клоните у Flash есть родной формат AMF, как он связан с SL? Как это связано с заявленной yateam фразой «Flex может работать с любым бэкендом — Java, PHP, Cold Fusion, с тем же .NET, Silverlight — нет»
AMF — это удобный и компактный формат, на основе которого реализована масса серверных Remoting-технологий ( Java, .NET, PHP, Python) для работы с Flash / Flex. Это означает, что с помощью AMF можно обмениваться типизированными объектами между клиентом и сервером и более того — оба могут прозрачновызывать метода друг друга ( коротко и ясно: Пример автоматического type-cast между клиентом и сервером. )
В сравнении с этим сервер, генерирующий для работы с ria: xml, json… выглядит как лопатка для детской песочницы в сравнении с экскаваторным парком :)
Fluorine Fx — поддержка AMF0, AMF3 и не только для .net. Есть еще flex bridge для .net, который сейчас уже неплох, и очень активно развивается.
Если вам не нравится xml для бекенда в принципе, юзайте hessian — байндинги есть как для flash/flex и для .net. Вопрос бинарности протокола тут непринципиален, и не является преимуществом.
Имхо, тема сисек супермеговости бекендов 'flash-only, not silverlight" не раскрыта чуть более, чем полностью.
А кто говорит что не может? Все всё могут, протоколы открыт пиши в свое удовольствие. Вопрос в том в наличии существующих библиотек. Flex имеет все это уже в комплекте как в составе самого фреймворка так и серверные части, заточены под него. Причем на стороне сервера это как официальные фреймворки типа того- же блейза (см выше), так и неофициальные написаны на java, python, php. Возможно есть и еще но лично сталкиваться не приходилось.
Согласен очень категоричное утверждение, правильнее сказать так
Существуют решения позволяющие flex работать с любым бекендом — Java, PHP, Cold Fusion, для Silverlight готовых решений еще нет.
Всего там хватает. Я про серверные библиотеки. Их пока както маловато будет. Если завязывать на .NET — все хорошо. Остальное требует напильника, а чаше написания с нуля.
Если я ошибаюсь, что вполне вероятно ибо Silverlight не находится в сфере моего внимания, то был бы рад паре другой примеров меня поправляющих.
Silverlight — клиентская технология, приложение на SL может спокойно обмениваться с сервером данными в нужном формате, включая как XML/JSON (в SL есть готовые .net библиотеки для работы и (де)сериализации), так и бинарные.
Что касается серверной части, то какая разница, что стоит на клиенте (AJAX, Flash, Silverlight и т.д.), если коммуникация идет через стандартные протоколы и по стандартным форматам представления данных? Причем тут конкретно .NET и что именно требует напильника?
Мы о разных вещах гворим похоже. Вы средне крупная контора, у вас есть готовый сервесайд и решив пойти в ногу со врменеи решили переписать клиенткую часть на flex. Положим у вас есть набор доменных моделей. Ваша задача написать приложение-клиент манипулирующие этими моделями. Как вы бы решили это с мнимальными затратами?
А вот пример решения подбной задачи для flex + blaseds:
Ага. С наличием подобных решений для .NET я спорить и не собираюсь. Я бы сильно удивился если MS их не имело. Есть ли у меня возможность написать клиент на SL и иметь нечто подобное по функционалу на Java или Python?
.Net RIA Services работают поверх ASP.NET, соответственно, на серверной стороне может использоваться все, что дружит с ASP.NET.
Python и Ruby можно использовать через Iron*-реализации. Насколько я понимаю, с выходом .NET 4 (и CLR 4) обе реализации должны начать работать еще лучше, сейчас над этим как раз трудятся разработчики.
Java — наврядли.
Можно, кстати, плясать и с другой стороны… тот же FluorineFx, реализующий поддержку AMF под .Net, содержит в себе библиотеки для Silverlight. Здесь можно посмотреть, как подружить ColdFusion и Silverlight.
Рост, только это ответ на другой вопрос — типи «почем AMF лучше XML/JSON». Понятно чем — бинарный формат занимает меньше места и при соответствующей нативной поддержке не требует больших затрат на (де)сериализацию.
Кроме того в Silverlight есть нативная поддержка формата Binary XML, в котором можно передавать данные через WCF. Не уверен, что уже успели появиться реализации под другие платформы, но формат открыт.
Понял. Своим ответом я хотел сказать, что именно отсутствие многоплатформенной серверной поддержки качества такого же, как у формата AMF, мешает Silverlight работать со многими бэкендами так, как это уже сейчас делает Flash / Flex / AIR.
Именно, всё у Adobe уже готово, никто не спорит. Но Apple противится, не знаю почему и как… а Silverlight будет работать, об этом уже весь интернет начинает говорить…
haXe с Flash API компилируется как C++ под iPhone — gamehaxe.com/2009/07/28/haxe-iphone-cpp-at-last/ :)
работает, пример физического движка на реальном девайсе — gamehaxe.com/2009/05/27/haxe-on-real-iphone/
Дело в том, что этот движок работает точно так же — он транслирует код в нативный Obj-C/Cocoa и уже компилирует его. Та мнет никакого нативного Silverlight'а ;)
Собственно в этом главная фишка .NET, изначально так и задумывался, как платформа, которая будет работать на любой платформе. Silverlight это лишь Compact .NET, который включает в себя ряд готовых инструментов и поддержку языка C#, а во что они на конкретной платформе транслируются — это дело 10ое.
Причем тут дотнет? Это *не* дотнет работает на iPhone. Это *не* Silverlight работает на iPhone. То, что движок Unity позволяет генерировать код для различных платформ — это заслуга авторов Unity, а не .NET'а.
Повторяем до полного понимания:
— .NET от МС не работает на других платформах, кроме Windows
— Silverlight работает только на Windows и MacOS
— Unity3D — это не Silverlight
>> То, что движок Unity позволяет генерировать код для различных платформ — это заслуга авторов Unity, а не .NET'а.
Нет, это заслуга авторов .net и Mono :) Unity == .net; любая игра или сцена на Unity — это огромная .net программа с включенными в нее медиаресурсами, откомпиленная Mono AOT до состояния большой нативной программы. То, что такое можно сделать — однозначно свойство и заслуга CLS/CTS == ms.net/Mono.
С чего это весь мир решил, что .NET от МС? МС агрессивно его продвигает, но изначально это не заслуга МС.
Silverlight работает и на Linux (не заставляйте делать скриншоты моей убунты на виртуалке), читайте Mono (moonlight).
Unity 3D это не Silverlight, но .NET, Silverlight будет с выходом Mono Touch.
.NET работает на ВСЕХ платформах, которые его реализуют. Он так устроен, что не зависит от платформы. Просто не везде еще реализован. Mono активно развивается. ru.wikipedia.org/wiki/Common_Language_Runtime
Тогда вот это ложно:
> И SL будет работать на iPhone, а Flash нет ;P
> Уже даже какая-то игрушка у них есть, попробую отыскать…
> Нашел: blogs.unity3d.com/2009/08/01/unity-iphone-demo-penelope-hits-the-app-store/
То есть даже не столько Сильверлайт, а компиляция сильверлайта в статические бинарники (то бишь просто реализация .NET'а для айфона). То есть Сильверлайта в браузере на айфоне мы так и не увидим
В любом случае, .NET на iPhone это уже реальность. Silverlight (.NET в браузере) пока нет, но нужен ли он на этом девайсе, это еще вопрос. Многие, даже простые приложения, которые могли бы работать в браузере, всё-равно часто оформляют в виде отдельных iPhone приложений. Так зачем тянуть кота за хвост?
Оказалось, что будет он работать или нет — большой вопрос. Нужен он там или нет — большой вопрос.
А то, что маленькие игрушки все равно оформляют в виде отдельных приложений — так это все известно. Потому что это единственный способ оказаться на этой платформе. И к Flash'у и Silverlight'у это никакого отношения не имеет :)
Ни в какой obj-c он не транслирует, не рассказывайте сказки :)
AOT-компилятор моно (ahead-of-time) выполняет ту же функцию, что и ngen в MS CLR — выполняет прекомпиляцию в нативный код не на этапе запуска программы, а на этапе установки ПО на iPhone.
Разница в том, что ngen, как правило, компилирует только «горячие» участки и оставляет внешние ссылки на сборки из CLR, а mono aot прогоняет весь IL и смерживает ваш код и все необходимые ему внешние сборки в одну большую нативную программу.
А как же пункт «Установочная база», где ясно написано, что это не важно для enterprise приложений, вы ощущаете разницу между массовым софтом и enterprise?
На самом деле и тут у СЛ не так уж плачевно — www.eclipse4sl.org/
Так что под Мак / Win есть среды разработки — там же где и есть и собственно Silverlight
Автор статьи немножко торгует прошлогодним снегом… Enterprise-уровень (информационные системы корпораций) долгое время не претерпевал таких качественных изменений, какие произошли, например, с мобильными платформами и встроенными системами. Между тем, здесь огромный пласт возможностей, и новые платформы RIA могут оказаться весьма выгодным делом. Видеокастинг, ip-телефония, совместная работа, активный обмен данными, «богатые» интерфейсы, дистанционное обновление, обучающие видеопрограммы и прочая — становятся доступны на простых рабочих местах где-нибудь в Ханты-Мансийске без астрономических затрат и мега-сроков, свойственных промышленным системам.
Возьмите платежные терминалы — их уже, наверное, сотни тысяч. И они исправно работают. Их интерфейсы понятны даже джамшутам. И они приносят неплохие деньги владельцам. И чаще всего, это именно Flash/Flex-платформа.
Реализация сложного бизнес-функционала в RIA, на который кивает автор, — это вообще-то не дело клиента. Сложный бизнес-функционал реализуется на серверах в дата-центрах, а задача клиента — сделать быстро, красиво и надежно. На это нужно смотреть в первую очередь.
Статья в тему. Спасибо за обзор. Выбираю как раз для RIA. Сам разрабатываю под .NET. Единственное, меня смущает кросбраузерность / кроcсплатформеность 3-го Silverlight'a
Уж не знаю как там в silverlight, а с DataGrid'ами во Flex я намучался, пытаясь сделать нормально работающую колонку чекбоксов. Хотя в итоге она таки заработала как надо =)
Отсутствие строгой типизации в некоторых случаях считаю только плюсом. В остальных случаях любую переменную можно насильно типизировать. Кстати, Flex Builder постоянно напоминает о нетипизированных переменных.
Flex 3 vs. Silverlight 3 в Enterprise разработке