Следует ли избегать написания Javascript в пользу GWT / WebSharper или какой-либо другой абстракции? - PullRequest
11 голосов
/ 10 июля 2010

Мне интересно, каково мнение о «вещах, которые компилируются в javascript», например? GWT, Script # и WebSharper и им подобные. Похоже, что это довольно нишевые компоненты, нацеленные на то, чтобы позволить людям писать javascript без написания javascript.

Лично мне комфортно писать javascript (используя JQuery / Prototype / ExtJS или какую-либо другую подобную библиотеку) и рассматривать такие вещи, как GWT, как ненужные абстракции, которые могут в конечном итоге ограничить то, что требуется разработчику, или в лучшем случае обеспечить затянувшийся обходной путь. В некоторых случаях вы все равно в конечном итоге пишете JavaScript, например JSNI.

Еще хуже, если вы не знаете, что происходит под покровом, вы рискуете непредвиденными последствиями. Например. откуда вы знаете, что GWT создает замыкания и правильно управляет пространствами имен?

Мне любопытно услышать мнение других. Это где веб-программирование движется?

Ответы [ 5 ]

20 голосов
/ 13 июля 2010

Следует ли избегать JavaScript в пользу X?Во что бы то ни стало!

Я начну с заявления об отказе: мой ответ очень предвзят, поскольку я работаю в команде разработчиков WebSharper.Причина, по которой я в этой команде, в первую очередь, заключается в том, что я совершенно не смог написать чистый JavaScript, а затем предложил моей компании попытаться написать компилятор с нашего любимого языка F # для JavaScript.

Для меня JavaScript - это портативная сборка в Интернете , выполняющая ту же роль, что и C в остальном мире.Это портативный, широко используется, и он останется.Но я не хочу писать JavaScript, не больше, чем я хочу писать ассемблер.Причины, по которым я не хочу использовать JavaScript в качестве языка, включают:

  1. Нет статического анализа, он даже не проверяет, вызваны ли функции с нужным количеством аргументов.Опечатки кусаются!

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

  3. Инструменты (редакторы кода, отладчики, профилировщики) довольно скудны, и большинство из них из-за (1) и (2): JavaScript не поддается статическому анализу.

  4. Стандартная библиотека отсутствует или очень ограничена.

  5. Существует множество грубых краев и смещений в использовании мутации.JavaScript плохо спроектирован, даже в нетипизированной семье (я предпочитаю Scheme).

Мы пытаемся решить все эти проблемы в WebSharper.Например, WebSharper в Visual Studio имеет автозавершение кода, даже когда он предоставляет сторонние API-интерфейсы JavaScript, такие как Ext Js.Но неважно, добьемся ли мы успеха или потерпим неудачу, на самом деле это не главное.Дело в том, что это возможно и, я надеюсь, очень желательно решить эти проблемы.

Еще хуже, если вы не знаете, что происходит под одеялом, вы рискуете непреднамереннопоследствия.Например, откуда вы знаете, что GWT создает замыкания и правильно управляет пространствами имен?

Это просто правильная запись компилятора.WebSharper, например, отображает лямбды F # в лямбды JavaScript 1-1 (фактически, он никогда не вводит лямбду).Возможно, я бы принял ваш аргумент, если бы вы упомянули, что, скажем, WebSharper еще недостаточно развит и проверен, и поэтому вы не решаетесь верить ему.Но затем GWT существует некоторое время и должен генерировать правильный код.

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

8 голосов
/ 11 июля 2010

Хотя я лично не одобряю один стиль над другим, я не думаю, что абстракция от Javascript - единственное преимущество, которое эти платформы приносят на стол. Конечно, при абстрагировании всего языка будут существовать вещи, которые станут невозможными, что было возможно ранее, и наоборот. Решение использовать такую ​​среду, как GWT, вместо написания обычного JavaScript зависит от многих факторов.

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

Проблема незнания того, что происходит внутри, относится к JavaScript так же, как и к любому переведенному источнику. Как вы думаете, сколько людей будут точно знать, что происходит в jQuery, когда они попытаются сделать сравнение, например $("p") == $("p"), и в результате получат обратно false. Это не гипотетическая ситуация, и есть несколько вопросов относительно SO. Изучение языка или среды требует времени, и при наличии достаточного времени разработчики могли бы также понять скомпилированный источник этих структур.

Другой связанный с этим вопрос аспект - это доверие. Мы постоянно строим абстракции более высокого уровня на абстракциях более низкого уровня и полагаемся на тот факт, что вещи более низкого уровня должны работать так, как ожидается. Когда вы в последний раз копали в скомпилированный двоичный файл программы на C ++ или Java, чтобы убедиться, что он работает правильно? Мы не потому, что доверяем компилятору.

Более того, при использовании такого фреймворка стыдно возвращаться к JavaScript, например, с помощью JSNI. Все дело в том, чтобы решить проблему наилучшим образом с помощью имеющихся инструментов. В JavaScript, или Java, или в C #, или в Ruby и т. Д. Нет ничего священного. Все они являются инструментами для решения проблем, и хотя они могут стать для вас препятствием, они могут сэкономить время и принести пользу кому-то еще.

Что касается направления веб-программирования, я думаю, что есть много интересных тенденций, которые, скорее всего, преуспеют, например, JavaScript на стороне сервера. Это решает очень реальные проблемы для меня, по крайней мере, в том, что мы можем легко избежать дублирования кода в веб-приложении. Одинаковые проверки, логика и т. Д. Могут быть общими на стороне клиента и сервера. Это также позволяет написать простой (де) механизм сериализации, так что RPC или RMI связь становится возможной очень легко. Я имею в виду, что было бы здорово написать:

account.debit(200);

на стороне клиента вместо:

$.ajax({
    url: "/account",
    data: { amount: 200 },
    success: function(data) {
        ..
    }
    error: function() {
        ..
    }
});

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

5 голосов
/ 13 апреля 2011

У меня есть три большие практические проблемы, которые я имею с websharper и другими компиляторами, которые утверждают, что избегают боли Javascript.

  • Если вы не будете хорошо знать Javascript, вы не сможете понять большинствопримеры использования в Интернете DOM / ExtJ и т. д., поэтому вы должны изучать Javascript.(По какой-то причине все программисты F # должны иметь возможность по крайней мере читать C # или VB.NET, в противном случае они не могут получить доступ к большей части информации о .net framework)
  • В любом веб-проекте вам нужно несколько веб-экспертов, которые знаютDOM и CSS наизнанку;будет ли такой человек готов работать с F #, а не с Javascript?
  • Будучи привязанным к провайдеру компилятора, они будут примерно через 5 лет;Я хочу, чтобы Microsoft полностью поддерживала открытый исходный код или инструменты.

Четыре больших плюса, которые я вижу в этих платформах:

  • Обмен кодом между сервером / клиентом
  • При наличии меньшего количества языков, которые должен знать программист(javascript - это настоящая боль, поскольку он выглядит как Jave / C #, но не похож на них)
  • Среднее качество программиста на F # намного лучше, чем на jscript.
2 голосов
/ 10 июля 2010

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

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

1 голос
/ 10 июля 2010

Я знаю, что это чрезмерное упрощение, потому что есть много других вещей, которые предлагают фреймворки, такие как GWT, но вот как я это вижу: если вам нравится JavaScript, пишите JavaScript; если вы этого не сделаете, используйте GWT или Cappuccino или что-то еще.

Причина, по которой люди используют фреймворки, такие как GWT, - это не обязательно абстракция, которую они дают, - вы можете иметь это с помощью фреймворков JavaScript, таких как ExtJS, - скорее, тот факт, что они позволяют вам писать веб-приложения не на JavaScript. Если бы я был программистом на Java, который хотел бы написать веб-приложение, я бы использовал GWT, потому что мне не пришлось бы изучать новый язык.

Это все предпочтения, правда. Я предпочитаю писать JavaScript, но многие люди этого не делают.

...