Записи JavaScript нужно избежать в пользу GWT/WebSharper или некоторой другой абстракции?
Мне любопытно, как что представление о "вещах что компиляция в JavaScript", например, GWT, Script# и WebSharper и их. Они, кажется, справедливо нишевые компоненты, нацеленные на разрешение людям записать JavaScript, не пишущий JavaScript.
Лично я - удобная запись JavaScript (использующий JQuery/Prototype/ExtJS или некоторую другую такую библиотеку) и вещи представления как GWT они как бесполезные абстракции, которые могут закончить тем, что ограничили то, что разработчик должен выполнить или лучший случай, обеспечивающий очень многоречивое обходное решение. В некоторых случаях Вы все еще заканчиваете тем, что писали JavaScript, например, JSNI.
Хуже все еще, если Вы не знаете то, что продолжается под покрытиями, Вы рискуете непреднамеренными последствиями. Например, как Вы знаете, что GWT создает закрытия и руководящие пространства имен правильно?
Мне любопытно услышать мнения других. Это то, куда веб-программирование направляется?
4 ответа
Хотя лично я не предпочитаю один стиль другому,Я не думаю, что абстракция от Javascript является единственным преимуществом, которое эти фреймворки приносят на стол. Конечно, при абстрагирование всего языка будут невозможны вещи, которые были возможны ранее, и наоборот. Решение использовать такой фреймворк, как GWT, а не писать ванильный JavaScript, зависит от многих факторов.
Делать это обсуждением JavaScript против языка X бесплодно, поскольку каждый язык имеет свои сильные и слабые стороны. Вместо этого провести объективный анализ затрат и выгод того, что можно получить или потерять, идущей с такой структурой, и это может быть сделано только вами, а не сообществом SO, к сожалению.
Проблема незнания того, что происходит под капотом, относится к JavaScript так же, как и к любому переведенным источнику. Как вы думаете, сколько людей будут точно знать, что происходит в jQuery, когда они попытаются сделать сравнение, такое как $("p") == $("p") и в результате получить обратно false.Это не гипотетическая ситуация, и есть несколько вопросов по СО относительно того же самого. Для изучения языка или фреймворка требуется время, и при наличии достаточного времени разработчики могут с таким же успехом понять скомпилированный исходный код этих фреймворков.
Другим аспектом, связанным с вышеупомянутым вопросом, является доверие. Мы постоянно строим абстракции более высокого уровня на абстракциях более низкого уровня и полагаемся на тот факт, что материал более низкого уровня должен работать так, как ожидалось. Что было в последний раз, когда вы копались в скомпилированном двоичном файле программы 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() {
..
}
});
Наконец, здорово, что у нас есть все это разнообразие в фреймворках и решениях для создания веб-приложений, поскольку следующее поколение решений может учиться на неудачах каждого и сосредоточиться на своих успехах, чтобы построить еще лучше, более быстрые и удивительные инструменты.
Я знаю, что это грубое упрощение, потому что есть много других вещей, которые предлагают такие фреймворки, как GWT, но вот как я это вижу: если вам нравится JavaScript, пишите на JavaScript; если нет, используйте GWT или Cappuccino или что-то еще.
Причина, по которой люди используют такие фреймворки, как GWT, не обязательно заключается в абстракции, которую они дают - вы можете получить ее с помощью таких JavaScript-фреймворков, как ExtJS - а скорее в том, что они позволяют вам писать веб-приложения на чем-то другом, чем JavaScript. Если бы я был программистом на Java, который хочет написать веб-приложение, я бы использовал GWT, потому что мне не пришлось бы изучать новый язык.
На самом деле, это все предпочтения. Я предпочитаю писать на JavaScript, но многие люди так не считают.
Я считаю, что у каждого фреймворка есть свои плюсы и минусы, и проектная группа должна оценить свои варианты использования, прежде чем включать один из них. Для меня любой фреймворк - это просто инструмент, который можно использовать для решения проблемы, и вы должны выбрать лучший для работы.
Я предпочитаю придерживаться чистых решений JavaScript, но при этом я могу вспомнить несколько случаев, когда GWT был бы полезен. GWT позволит команде обмениваться кодом между сервером / клиентом, уменьшая необходимость писать один и тот же код дважды (JS и Java). Или, если кто-то переносил Java-клиент в веб-интерфейс, ему может быть проще придерживаться GWT (конечно, опять же, это может усложнить задачу :-)).
Следует ли избегать JavaScript в пользу X? Во всех смыслах!
Я начну с отказа от ответственности: мой ответ очень предвзят, поскольку я являюсь членом команды разработчиков WebSharper. Причина, по которой я нахожусь в этой команде, в первую очередь, заключается в том, что я обнаружил, что совершенно не умею писать чистый JavaScript, а затем предложил своей компании попробовать написать компилятор с нашего любимого языка F # на JavaScript.
Для меня JavaScript - это переносимая сборка Интернета , выполняющая ту же роль, что и C в остальном мире. Он портативный, широко используется и останется. Но я не хочу писать JavaScript, не больше, чем хочу писать сборку. Причины, по которым я не хочу использовать JavaScript в качестве языка, включают:
Статического анализа нет, он даже не проверяет, вызываются ли функции с нужным количеством аргументов. Опечатки кусаются!
Нет или очень ограниченная концепция библиотек, пространств имен, модулей, классов, поэтому каждая структура изобретает свои собственные (ситуация аналогична схеме R5RS).
Инструменты (редакторы кода, отладчики, профилировщики) довольно плохи, и большая часть этого из-за (1) и (2): JavaScript не поддается статическому анализу.
Стандартной библиотеки нет или она очень ограничена.
Есть много острых углов и предубеждений в использовании мутации. JavaScript - плохо спроектированный язык даже в семействе нетипизированных (я предпочитаю Scheme).
Мы пытаемся решить все эти проблемы в WebSharper. Например, у WebSharper в Visual Studio есть автозавершение кода, даже если он предоставляет сторонние API-интерфейсы JavaScript, такие как Ext Js.Но суть не в том, добьемся ли мы успеха или проиграем. Дело в том, что можно и, надеюсь, очень желательно решить эти вопросы.
Еще хуже, если вы не знаете, что происходит под одеялом, вы запускаете риск непредвиденных последствий. Например. откуда вы знаете, что GWT создает закрытие и управление пространствами имен правильно?
Речь идет только о правильном написании компилятора. WebSharper, например, сопоставляет лямбда-выражения F # с лямбда-выражениями JavaScript в порядке 1-1 (фактически, он никогда не вводит лямбда-выражения). Я бы, возможно, согласился с вашим аргументом, если бы вы упомянули, что, скажем, WebSharper еще недостаточно зрел и протестирован, и поэтому вы не решаетесь ему доверять. Но затем GWT существует уже некоторое время и должен выдавать правильный код.
Суть в том, что строго типизированные языки строго лучше, чем нетипизированные языки - вы можете легко написать на них нетипизированный код, если вам нужно, но у вас есть возможность использовать проверку типов, которая является средством проверки орфографии для программистов. . Почему бы и нет? Отказ сделать это для меня звучит немного глупо.