JavaScript / CSS против Silverlight против Flex - PullRequest
6 голосов
/ 25 января 2009

В настоящее время у нас есть довольно сложное бизнес-приложение, которое содержит огромное количество кода JavaScript, чтобы пользовательский интерфейс и взаимодействие были максимально приближены к работе с традиционным настольным приложением (так как этого хотят наши пользователи). С годами этот код Javascript рос и рос, что усложняло управление и поддержку, а также увеличивало вероятность того, что добавление новой функциональности нарушит существующую. Излишне говорить, что многие из этого кода больше не являются современными.

Таким образом, мы продолжаем некоторое обсуждение того, должна ли клиентская часть приложения быть переписана заново во Flex или Silverlight, или переписана заново с использованием какой-либо современной JavaScript-инфраструктуры, такой как jQuery, или нам следует просто продолжить с тем, что мы имеем и постепенно пытаемся заменить наихудшие биты существующего кода. Что еще труднее решить, так это то, что переписывание пользовательского интерфейса будет стоить нам 6-12 человеко-месяцев.

Мне бы хотелось услышать ваши мысли по этому вопросу (возможно, некоторым из вас уже приходилось принимать подобное решение).

РЕДАКТИРОВАТЬ: Чтобы ответить на некоторые вопросы, которые возникли с ответами: Внутренний код написан на C #, целевая аудитория (обычно) нетехнических пользователей из компаний, которым мы продаем программное обеспечение (не для широкой публики, но не только для внутренних пользователей), программное обеспечение «только» должно запускаться в настольных браузерах, но не обязательно на мобильных устройствах, а клиентское приложение представляет собой полноценный пользовательский интерфейс.

Ответы [ 8 ]

15 голосов
/ 25 января 2009

Честно говоря, я бы реорганизовал старый код JavaScript, а не переписывал приложение. Поскольку вы спрашиваете, на какой платформе это сделать, я полагаю, что ваша команда не является экспертом ни в одном из них (не бросая вызов команде, это просто простой факт, который вы должны учитывать при принятии решения). Это сработает против вас, так как у вас будет двойной долг переписывать и учиться делать что-то на новой платформе.

Сохраняя его в JavaScript, вы можете медленно внедрять фреймворк, если вы решите и сделаете это итеративно (замените фрагмент кода, протестируйте его, отпустите и исправьте все ошибки). Это позволит вам делать это в более медленном темпе и получать обратную связь по пути. Таким же образом, если проект отменяется на полпути, вы не пропустите всю работу, потому что конечный пользователь использует обновленный код. Помните модель водопада, которая, по сути, является полной заменой почти никогда не работает.

Как бы мне не хотелось это признавать, так как это всегда приносит наибольшее удовольствие разработчикам, смена платформ и одновременная замена всей системы работают редко. Есть бесчисленное множество примеров этого, Netscape для одного. Вот сообщение от Spolsky об этом. (Я также рекомендовал бы книгу Мечты в коде . Это отличный пример программного проекта, который потерпел неудачу и как и почему). Не забудьте переписать систему с нуля, вам, по сути, придется пройтись по каждой строке кода и выяснить, что она делает и почему. Сначала вы думаете, что можете пропустить это, но в конечном итоге все сводится к этому. Как вы сказали, ваш код старый, а это значит, что в нем, скорее всего, есть хаки, чтобы что-то сделать. Некоторые из них вы можете игнорировать, а другие будут: «Я не знал, что система нуждалась в этом для этого».

5 голосов
/ 25 января 2009

Эти вещи приходят на ум:

  • Поскольку у вас есть .Net-сервер и у вас есть возможность заставить своих клиентов переходить на конкретную платформу, Silverlight является опцией;
  • Поскольку ваш клиент представляет собой полноценный пользовательский интерфейс, вам нужны виджеты и, возможно, другие функции, такие как Drag and Drop;
  • Я не видел каких-либо требований, которые бы оправдывали мне начинать сначала (что часто не получается) в Flex / Silverlight (например, потоковое видео, поддержка SVG. Добавив к знакомству вашей команды с Javascript, я думаю, вы можете не дает убедительных аргументов в пользу чего-либо кроме Javascript.

Но, конечно, Javascript - это много вещей, и существует [множество Javascript-фреймворков 1 . Наиболее важным делителем является то, является ли ваше намерение «украшать» набор веб-страниц, или вам нужен полный набор виджетов для создания настольного приложения в Интернете. Ваш вопрос указывает, что это последний.

Как таковой - и я могу быть опущен за это - я не думаю, что jQuery - это ответ, и я говорю это как кто-то, кто любит jQuery. jQuery (imho) отлично подходит для улучшения веб-страниц и абстрактной кросс-браузерной низкоуровневой функциональности, но наиболее важным фактором для сложного разработчика пользовательского интерфейса является:

Это все о виджетах.

И да, я знаю о jQuery UI , но он намного меньше, чем другие, когда дело доходит до виджетов. Я предлагаю вам взглянуть на образцы и галереи виджетов некоторых фреймворков:

Остальные (jQuery, Dojo, Mootools, Prototype) - более «компактные» фреймворки, возможно, менее подходящие для ваших целей.

Также при принятии решения учитывайте лицензию каждой платформы.

Мои мысли о трех вышеперечисленных:

  • ExtJS имеет несколько разозлило сообщество в том, что он начал как LGPL, но был противоречивым изменение лицензии (что нить на 76 страниц!) В GPL / коммерческой в ​​версии 2.1. Проблема в том, что сообщество больше не принимает активного участия в разработке структуры. Во всяком случае, не основная версия. Это означает, что он разрабатывается и поддерживается небольшой командой (возможно, одним человеком), а не сообществом. ИМХО, не стоит платить за это коммерческую лицензию, и GPL, вероятно, запрещает в вашей ситуации;
  • YUI поддерживается Yahoo и доступен по гораздо более разрешительной и гораздо менее агрессивной лицензии BSD. Это зрелый, хорошо используемый и заслуживающий серьезного рассмотрения; и
  • SmartClient меня очень впечатляет. Он имеет, пожалуй, самую разрешительную лицензию из всех (LGPL), ему около семи лет, и он имеет невероятно впечатляющий набор доступных виджетов. Ознакомьтесь с их проводником функций.

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

  • Кодирование виджетов пользовательского интерфейса, таких как деревья и аккордеоны;
  • Тестирование и устранение кросс-браузерных проблем с Javascript и CSS;
  • Создание доморощенных фреймворков, которые в значительной степени дублируют то, что делают и делают существующие фреймворки.

Я бы серьезно отнесся к одному из трех выше как к твоему пути вперед.

5 голосов
/ 25 января 2009

Это решение обычно зависит не от технологии, а от ваших навыков и зон комфорта.

Если у вас есть парни, которые едят и дышат Javascript, но ничего не знают о .net или Flash / Flex, тогда нет ничего плохого в том, чтобы придерживаться Javascript и опираться на библиотеку, такую ​​как jQuery или Prototype.

Если у вас есть навыки в любом другом, вы можете получить более быстрый результат, используя Silverlight или Flex, так как вы получаете довольно много функциональных возможностей «бесплатно» с обоими из них.

4 голосов
/ 25 января 2009

Мое мнение по этому вопросу довольно простое: если приложение не должно быть общедоступным, если оно не должно быть оптимизировано для поисковых систем и доступно для поиска, и / или нет других веских причин для того, чтобы оно оставалось строго текстовым, затем чипы стекаются в пользу полнофункциональных клиентских сред, таких как Flash или Silverlight, прямо из шлюза.

Основная причина, если не самая большая, заключается в том, что они устраняют сложности разработки для нескольких браузеров и платформ. Опять же: они исключают переменную среды выполнения . Больше не нужно отлаживать старые версии Netscape и IE, больше не нужно обнаруживать объекты и, как следствие, делать ветвления, нет больше дурацких хаков CSS - одна база кода, и все готово. Выгрузка среды выполнения в Adobe или Microsoft сэкономит вам время, деньги и головные боли, при прочих равных. (Конечно, есть YUI, JQuery и т. Д., Но они не удаляют эту переменную - они просто абстрагируют ее. И они не абстрагируют все , либо только ее часть; в конечном счете, вам все еще предстоит тестировать, отлаживать, повторно тестировать, отлаживать, повторять.)

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

Со своей стороны, я давний парень на стороне сервера, ASP.NET/C# в течение последних нескольких лет, и в свое время я написал много текстовых бизнес-приложений, последнее немногие с сильным акцентом на предоставление богатых соверигн интерфейсов с JavaScript. Я также провел последние пару лет почти исключительно с Flex. У меня есть опыт в обоих мирах. И я могу без колебаний сказать, что прямо сейчас, , победить Flex - это задача всех остальных: это просто удивительно универсальный и производительный продукт, а для бизнес-приложений он остается на пределе возможностей Silverlight. Я просто не могу рекомендовать это достаточно высоко; одни только функции привязки данных и обработки событий невероятно экономят время, не говоря уже о полной свободе, которую вы будете иметь над макетом, анимацией и т. д. Список можно продолжить.

Итак, мой совет: внимательно и внимательно посмотрите на Flex . В конце концов, вы можете обнаружить, что предварительное переписывание является слишком масштабным мероприятием, чтобы оправдать его, и это нормально - только вы можете сделать это определение. (И, честно говоря, у вас столько же возможностей создать беспорядок в проекте Flex, сколько и в проекте JavaScript - я знаю. Я сделал это.) Но все же, Flex, вероятно, наименее Ограниченный, самый гибкий, самый многофункциональный и продуктивный вариант прямо сейчас, так что это, безусловно, стоит рассмотреть. Удачи!

2 голосов
/ 25 января 2009

Любой ваш javascript, который был разработан «За эти годы», вероятно, не похож на то, что возможно сегодня. Там, несомненно, много полезного кода. тем не менее. Поэтому моя рекомендация будет переписать в javascript с использованием jQuery и использовать одну из доступных надстроек GUI, возможно, посмотрите на материал Yahoos. Вы также будете ориентированы на самую широкую аудиторию.

1 голос
/ 19 ноября 2010

Мы разработали чрезвычайно богатое приложение, использующее EXTJS с C # и немного C ++ на сервере. Мало того, что у нас есть клиенты, которые довольны интерфейсом в своих браузерах для настольных компьютеров, но и с минимальной настройкой Javascript, мы смогли обеспечить поддержку веб-браузера. Кроме того, у нас есть клиенты в странах третьего мира, которые не могут использовать приложения Flash или Silverlight из-за того, что их сотрудники на местах используют киоски в интернет-кафе (у многих из которых не установлен Flash - забудьте Silverlight!) Я думаю, что эти и другие проблемы компенсируют сложность кодирования сложного приложения в javascript ...

1 голос
/ 31 июля 2009

Проверьте эту таблицу сравнения для Flex и Javascript:

1 голос
/ 25 января 2009

Технология GUI должна в первую очередь определяться вашей целевой аудиторией. Например, если вы нацелены на пользователей iPhone англобов, я бы не рекомендовал Flex, потому что на данный момент у iPhone нет флеш-плеера.

Имейте в виду, что если вы переключитесь на полноценный инструментарий GUI, такой как Silverlight, ваши пользователи могут счесть L & F неестественным, поскольку обычный цикл запроса-ответа не так очевиден для клиентских сред.

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

Я предлагаю вам придерживаться javascript, поскольку ваши разработчики знакомы с ним, и постепенно заменять старый javascript новым инструментарием, таким как prototype, jQuery или любым другим. Вы, вероятно, будете переделывать некоторые старые вещи быстрее, используя современный инструментарий. Помните, что вы можете создавать прекрасные приложения с любым взятием.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...