Comments 13
Инфраструктуры, кстати, уже не так мало. Есть как совместимые scala библиотеки, так и множество биндингов JS библиотек.
Я пробовал биндинг ReactJs — остались положительные впечатления.
Правильно ли японимаю, что scala.js можно использовать для разработки с React.js без танцев с бубном?
А как насчет Angular?

я так например жду, когда scala.js дозреет… Хотя и не слежу пристально…
На сейте есть список фасадов.
Я использовал scalajs-react + diode.

Для первого angular есть фасад. Я его года 2 назад пробовал использовать — понравилась типизация $scope. Но глубоко не копал.
Для второго ангулара фасад в разработке: angulate2.
А если кнопка меняет свое состояние (Enabled/Disabled) страница перезагружается?
Не совсем понял вопрос. Если про workbench, то страница перезагружается только, если меняется код, ресурсы (но это можно еще настроить). Если мы из кода биндим attribute на какое-то свойство (через ObservedValue например) и его меняем, страница не перезагружается. Это SPA и перезагружать его можно тогда, когда этого захочется самому.
Статья хорошая, 2 проекта у себя в компании завели на scala.js, идеально подходит для построения прототипов фронтенда под скаловский бэк.

По мне так Scala.js выглядит довольно таки неуклюже по сравнению с элегантностью Elm и другими функциональными языками доступными для веба. Какова ее ниша? Я например не представляю как вот это можно использовать с React или Angular.

Очень просто можно использовать.
Во первых, сам по себе язык хороший и достаточно мощный. Заметьте, не идеальный.
Во вторых, изучив язык ты можешь его использовать и на фронте и на беке. И даже бэк может быть например Node.js.
Единовая кодобаза и все плюсы проистекающие из этого.
Т.е. это не язык для обычной web разработки, как-то странички, информационные сайтики и т.д.
Это для, если так можно выразиться, web приложений. Более сложных чем обычные информационные сайтики.
И в этом оно очень удобно. Хотя и может конечно использоватья для них, если команда хочет.

Мне вот наоборот не понятно, зачем изучать «вещи в себе», такие как: cofe script, type script, elm и т.д. и т.п.
Это одноразовые вещи, эти знания больше нигде не применить. И тут уже не важна мифическая «элегантность языка», если для каждой новой задачи тебе надо учить новый язык, с новой инфраструктурой и со своими заморочками. Тем более, что эти одноразовые вещи довольно быстро умирают, т.к. более мейнстримовые языки впитывают идеи из них. Либо через развитие языка, либо через библиотеки.
В этом плане мне больше нравится подход Scala/Scala.js или Clojure/Clojurescript. Более прагматичный подход в целом. Когда инвестированное время не пропадает зря ради мифической «элегантности».

Ну следует заметить что такая вещь в себе как TypeScript навряд ли покинет сцену скоро. В том то и дело что Clojurescript и другие порты scheme-like выглядят намного элегантней и более востребованным для node.js, чем та же scala. Зачем кому-то писать на scala под node.js, когда есть акка, play!, и прочие плюшки.

> TypeScript навряд ли покинет сцену скоро
Согласен. Но от этого больше смысла в его изучении я не вижу).

>намного элегантней и более востребованным для node.js
Вы не поняли суть моего высказывания. В целом логика не верная, на мой взгляд.
Изучать язык «для Node.js» или для «декларативного создания графических интерфейсов» это не очень хорошая затея. Надо изучать хороший, мощный язык, который позволяет не думать в духе «Мне надо изучить язык X для платформы Y». А просто позволит реализовать необходимое. Scala и Clojure это умеют. Можно писать удобно и для бека (JVM, Node.JS) и для фронта (Web).
Если команда знает Scala, она просто не меня язык подберет себе библиотеки для бека и фронта. Если знает Clojure то же самое. Будет единая кодовая база, единый опыт разработки. Можно развиваться в подходах, методиках, и оттачивать свое мастерство именно как разработчик.
А когда у тебя вот тут у нас Elm, тут Go, тут Java и постоянно надо изучать новый язык, выходит хрень какая-то. Все по верхам изучается, на уровне копипасты с SO).

В общем я за подход «один мощный язык — много библиотек реализующих разные подходы», а не «много языков и много библиотек реализующих подходы». Имеется ввиду язык для команды или проекта. Кто-то хочет типизации, возьмет Scala, кто-то за LISP и возьмет Clojure, кто-то выберет что-то другое.
Но главное, чтобы не было зоопарка.

Нет я вас прекрасно понял, но у нас подходы разные. Я исхожу из того что один инструмент для одной определенной сферы. Зачем язык которые умеет запрашивать БД, делать кофе и его можно перевести без труда на перфокарты. Согласен с вами что когда у вас 35 разных языков это уже перебор, но когда один язык для клиентской части, один для бэкенда, один для скриптинга около DevOps-ых задач это уже не так уж и много. Не вижу смысла "притягивать за уши" бэкенд язык к вебу.


Как не крути у вас все равно будет как минимум 2 языка в команде, один системный другой для всего остального, если вы конечно не пишите на python.

Only those users with full accounts are able to leave comments. Log in, please.