Comments 17
Нам нужно другое имя, потому что <code>type</code> это зарезервированное слово в Scala.
С экранированием не работает?
@JSExport
def `type`: String
+1
Правильно я понимаю, что проект — компилятор scala в клиентский javascript? Т.е. по сути аналог GWT, но с функциональным программированием.
Что из базовой библиотеки функций scala поддерживается на клиенте?
Что из базовой библиотеки функций scala поддерживается на клиенте?
0
Почти все кроме описанного вот тут http://www.scala-js.org/doc/semantics.html
+1
0
GWT — это громадный фреймворк, а ScalaJS — просто компилятор из Scala в JS. То есть тут никто не навязывает подходов — просто дают возможность писать фронтенд на Scala.
Практически вся стандартная библиотека Scala поддерживается, к тому же многие популярные библиотеки также уже поддерживают ScalaJS.
Практически вся стандартная библиотека Scala поддерживается, к тому же многие популярные библиотеки также уже поддерживают ScalaJS.
+1
0
Смотрю на список аргументов «за» использование ScalaJS
Очевидно, первое и четвёртное ничто не мешает писать на JavaScript-е. Третье я не понимаю (во всяком случае, на JS хватает фреймворков для работы с REST-сервисами без всяких Скал). Остаётся один действительно валидный аргумент — реюз серверного кода.
Признаться, к аргументации «у нас на фронте и бэкенде используется один и тот же язык» и вообще ко всей концепции я отношусь, кхм, с некоторым подозрением. Всё равно фронт придётся писать на JavaScript-е. Не собираетесь же вы в самом деле писать работу с HTML/CSS на Scala. Во-первых, библиотек на каждое браузерное API не напасёшься делать; во-вторых, это [написание типизированных обёрток к браузерному JS, который чуть менее чем полностью, состоит из сурового легаси] — попросту выбрасывание времени и денег на ветер; в-третьих, представить себе типизированную обёртку над jQuery/jQuery UI я не могу при всём желании, а разработка веб-приложений без них я иначе как мастурбацией вприсядку не могу назвать.
Фактически, использование Scala в этом месте необходимо в основном затем, чтобы бесшовно транслировать объекты как они представлены на сервере в идентичные на клиенте. ИМХО, накладные расходы в виде кучи бессмысленного для JS синтаксиса это сомнительное удобство не оправдывают — работать-то с объектами всё равно придётся по-разному на клиенте и сервере.
спрятать сложную или неочевидную клиентсайд логику в ней и предоставить удобное API;
в библиотеке вы сможете работать с моделями из backend приложения;
изоморфный код из коробки и можете забыть про проблемы синхронизации протоколов;
у вас будет публичный API для разработчиков, как у Facebook’s Parse.
Очевидно, первое и четвёртное ничто не мешает писать на JavaScript-е. Третье я не понимаю (во всяком случае, на JS хватает фреймворков для работы с REST-сервисами без всяких Скал). Остаётся один действительно валидный аргумент — реюз серверного кода.
Признаться, к аргументации «у нас на фронте и бэкенде используется один и тот же язык» и вообще ко всей концепции я отношусь, кхм, с некоторым подозрением. Всё равно фронт придётся писать на JavaScript-е. Не собираетесь же вы в самом деле писать работу с HTML/CSS на Scala. Во-первых, библиотек на каждое браузерное API не напасёшься делать; во-вторых, это [написание типизированных обёрток к браузерному JS, который чуть менее чем полностью, состоит из сурового легаси] — попросту выбрасывание времени и денег на ветер; в-третьих, представить себе типизированную обёртку над jQuery/jQuery UI я не могу при всём желании, а разработка веб-приложений без них я иначе как мастурбацией вприсядку не могу назвать.
Фактически, использование Scala в этом месте необходимо в основном затем, чтобы бесшовно транслировать объекты как они представлены на сервере в идентичные на клиенте. ИМХО, накладные расходы в виде кучи бессмысленного для JS синтаксиса это сомнительное удобство не оправдывают — работать-то с объектами всё равно придётся по-разному на клиенте и сервере.
+1
Для jQuery есть обертки: jquery-facade, scala-js-jquery. Вообще не полный список типизированных фасадов можно посмотреть здесь.
Я пробовал писать на scalajs-angular — очень понравилось.
Есть scalajs-react.
К сожалению на боевых проектах опробовать scala.js не довелось. На моем текущем проекте мне бы разделение кода между клиентом и сервером очень не помешало бы. У нас огромное количество довольно сложных проверок данных, которые приходится дублировать на клиенте (чтоб быстро подсказывать клиентам) и на сервере (чтоб не пропустить не валидные данные).
Я пробовал писать на scalajs-angular — очень понравилось.
Есть scalajs-react.
К сожалению на боевых проектах опробовать scala.js не довелось. На моем текущем проекте мне бы разделение кода между клиентом и сервером очень не помешало бы. У нас огромное количество довольно сложных проверок данных, которые приходится дублировать на клиенте (чтоб быстро подсказывать клиентам) и на сервере (чтоб не пропустить не валидные данные).
0
Про третий пункт: scala.js, например, позволяет использовать одну и ту же библиотеку сериализации на клиенте и сервере. Не подобрать похожие и синхронизировать поведение, а действительно использовать одну библиотеку.
0
представить себе типизированную обёртку над jQuery/jQuery UI я не могу при всём желании
Не надо представлять: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/jquery/jquery.d.ts
а разработка веб-приложений без них я иначе как мастурбацией вприсядку не могу назвать.
Да ладно? Ну вот зачем например jquery в angular2 приложении?
0
Такой момент.
ScalaJS несет с собой рантайм, который дает минимум порядка 170кб оверхед.
Соответственно, каждая библиотека, в проекте, будет иметь минимум 170кб вес. А если их 4-5 надо в проект?
Не многовата ли цена, за не очень большое удобство разработки?
ScalaJS несет с собой рантайм, который дает минимум порядка 170кб оверхед.
Соответственно, каждая библиотека, в проекте, будет иметь минимум 170кб вес. А если их 4-5 надо в проект?
Не многовата ли цена, за не очень большое удобство разработки?
0
Можно использовать один рантайм для всех библиотек. Это же просто js скрипт.
0
Это если бы рантайм был просто библиотекой.
Так то он компилится вместе с библиотекой, и из него выкидывается все, что не используется в коде библиотеки.
Так то он компилится вместе с библиотекой, и из него выкидывается все, что не используется в коде библиотеки.
0
ну либы по идее поставляются в Scala коде, а потом уже все приложение компилируется в js, т.е. рантайм все равно будет один, хотя да любая отдельная либа собирается вместе с рантаймом
0
Можно лишь добавить, что потенциальные области применения именно js-библиотек написанных на scalajs практически исключают возможность поключения более одной такой библиотеки. Даже если такое произойдет, скорее всего будет возможность подключить их вместе в sbt и скомпилировать в одну большую либу с одним общим рантаймом
0
Sign up to leave a comment.
Как написать JS-библиотеку на ScalaJS