Комментарии 13
Я пробовал биндинг ReactJs — остались положительные впечатления.
Я использовал scalajs-react + diode.
Для первого angular есть фасад. Я его года 2 назад пробовал использовать — понравилась типизация $scope. Но глубоко не копал.
Для второго ангулара фасад в разработке: angulate2.
По мне так 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!, и прочие плюшки.
Согласен. Но от этого больше смысла в его изучении я не вижу).
>намного элегантней и более востребованным для 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.
Scala.js легко и просто