Pull to refresh

Comments 17

Нам нужно другое имя, потому что <code>type</code> это зарезервированное слово в Scala.

С экранированием не работает?
@JSExport
def `type`: String
Вполне пригодный вариант, я просто визуально не очень люблю экранированые имена.
Правильно я понимаю, что проект — компилятор scala в клиентский javascript? Т.е. по сути аналог GWT, но с функциональным программированием.

Что из базовой библиотеки функций scala поддерживается на клиенте?
Почти все кроме описанного вот тут http://www.scala-js.org/doc/semantics.html
GWT — это громадный фреймворк, а ScalaJS — просто компилятор из Scala в JS. То есть тут никто не навязывает подходов — просто дают возможность писать фронтенд на Scala.
Практически вся стандартная библиотека Scala поддерживается, к тому же многие популярные библиотеки также уже поддерживают ScalaJS.
Смотрю на список аргументов «за» использование ScalaJS

спрятать сложную или неочевидную клиентсайд логику в ней и предоставить удобное API;
в библиотеке вы сможете работать с моделями из backend приложения;
изоморфный код из коробки и можете забыть про проблемы синхронизации протоколов;
у вас будет публичный API для разработчиков, как у Facebook’s Parse.


Очевидно, первое и четвёртное ничто не мешает писать на JavaScript-е. Третье я не понимаю (во всяком случае, на JS хватает фреймворков для работы с REST-сервисами без всяких Скал). Остаётся один действительно валидный аргумент — реюз серверного кода.

Признаться, к аргументации «у нас на фронте и бэкенде используется один и тот же язык» и вообще ко всей концепции я отношусь, кхм, с некоторым подозрением. Всё равно фронт придётся писать на JavaScript-е. Не собираетесь же вы в самом деле писать работу с HTML/CSS на Scala. Во-первых, библиотек на каждое браузерное API не напасёшься делать; во-вторых, это [написание типизированных обёрток к браузерному JS, который чуть менее чем полностью, состоит из сурового легаси] — попросту выбрасывание времени и денег на ветер; в-третьих, представить себе типизированную обёртку над jQuery/jQuery UI я не могу при всём желании, а разработка веб-приложений без них я иначе как мастурбацией вприсядку не могу назвать.

Фактически, использование Scala в этом месте необходимо в основном затем, чтобы бесшовно транслировать объекты как они представлены на сервере в идентичные на клиенте. ИМХО, накладные расходы в виде кучи бессмысленного для JS синтаксиса это сомнительное удобство не оправдывают — работать-то с объектами всё равно придётся по-разному на клиенте и сервере.
Для jQuery есть обертки: jquery-facade, scala-js-jquery. Вообще не полный список типизированных фасадов можно посмотреть здесь.

Я пробовал писать на scalajs-angular — очень понравилось.

Есть scalajs-react.

К сожалению на боевых проектах опробовать scala.js не довелось. На моем текущем проекте мне бы разделение кода между клиентом и сервером очень не помешало бы. У нас огромное количество довольно сложных проверок данных, которые приходится дублировать на клиенте (чтоб быстро подсказывать клиентам) и на сервере (чтоб не пропустить не валидные данные).
Про третий пункт: scala.js, например, позволяет использовать одну и ту же библиотеку сериализации на клиенте и сервере. Не подобрать похожие и синхронизировать поведение, а действительно использовать одну библиотеку.
представить себе типизированную обёртку над jQuery/jQuery UI я не могу при всём желании

Не надо представлять: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/jquery/jquery.d.ts

а разработка веб-приложений без них я иначе как мастурбацией вприсядку не могу назвать.

Да ладно? Ну вот зачем например jquery в angular2 приложении?
Такой момент.
ScalaJS несет с собой рантайм, который дает минимум порядка 170кб оверхед.
Соответственно, каждая библиотека, в проекте, будет иметь минимум 170кб вес. А если их 4-5 надо в проект?
Не многовата ли цена, за не очень большое удобство разработки?
Можно использовать один рантайм для всех библиотек. Это же просто js скрипт.
Это если бы рантайм был просто библиотекой.
Так то он компилится вместе с библиотекой, и из него выкидывается все, что не используется в коде библиотеки.
ну либы по идее поставляются в Scala коде, а потом уже все приложение компилируется в js, т.е. рантайм все равно будет один, хотя да любая отдельная либа собирается вместе с рантаймом
Можно лишь добавить, что потенциальные области применения именно js-библиотек написанных на scalajs практически исключают возможность поключения более одной такой библиотеки. Даже если такое произойдет, скорее всего будет возможность подключить их вместе в sbt и скомпилировать в одну большую либу с одним общим рантаймом
Sign up to leave a comment.