Подтвердить что ты не робот

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

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

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

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

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

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

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

account.debit(200);

на стороне клиента, а не:

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

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

Ответ 2

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 3

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

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

4 больших позитива, которые я вижу в этих рамках:

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

Ответ 4

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

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

Ответ 5

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

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

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