Ну... что тут поделать... грешно смеяться над ними...

Та и я бы не стал... жизнь заставила

Королев рулит и разруливает.

Мы запилили прототип пока в вилобаджо только спорили и выбирали что юзать, флукс редакс или вуй )

а дальше что с этим прототипом?

переписали на флукс редакс или вуй

а дальше что с этим прототипом?

Дальше он превращается из прототипа в продакшен систему.

Интересует кто ее пишет. Скалисты либо usual middle frontend react developer?

А какие минусы? Например, есть ли всякие библиотеки кастомных web-контролов? Т.е. вот это все писать самому... Верно?

Да. Королев какбы совместим с веб-компонентами то они обычно 1) адски тяжелые, что срезает преимущества Королева 2) написаны не по стандарту, из зачего Королеву отрывает бошку. Так что только чистые CSS-фреймворки типа https://bulma.io.

Интересует кто ее пишет. Скалисты либо usual middle frontend react developer?

Разработчики пишут. Мы бульму используем, поэтому требования к знанию фронтендерской части минимальны. И у нас нет этого мещанского деления по группам разработчиков)

А какие минусы? Например, есть ли всякие библиотеки кастомных web-контролов? Т.е. вот это все писать самому... Верно?

Есть всякие узкие места, которые надо доделывать. На пример @tvaroh реквестировал возможность прелоада -- показать что-нибудь пока БД думает. DSL на сложных кейсах становится неудобным. В Левше висит задача на XML-литералы, но я что-то как-то не доберусь до нее.

http://blog.kubernetes.io/2018/03/apache-spark-23-with-native-kubernetes.html

О лала

Заживём

для скалистов которые хотят в фулстек возможно хороший вариант, обычных фронтендеров конечно не убедить, им реакты и вебпаки подавай

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

К сожалению множество из них потом уходят потому что не используют react/angular/vue/other buzzword которые могут написать в резюме и перепрыгнуть на +500 в другой компании. А со скалы им пригать не так весело.

Последняя фраза получилась двусмысленной :)

@fomkin А почему пошел по пути условного dsl, а не шаблонизатора?

как шаблонизатор заставить типы проверять?

@fomkin А почему пошел по пути условного dsl, а не шаблонизатора?

А чем, по твоему, шаблонизатор лучше?

тем что не надо изучать dsl, проще отдавать на доработку верстальщикам

как шаблонизатор заставить типы проверять?

как заставить компилятор проверять типы твоей портянки которую ты в блокноте написал (в файлах .scala)?

хотя dsl dsl-лю рознь, JSX тоже dsl, но максимально близкий к html

как шаблонизатор заставить типы проверять?

https://medium.com/@dempfi/typescript-jsx-syntax-as-typed-dsl-97c052b825c8

ну и state, props типизированы в tsx, можно это считать типизированным шаблоном?

тем что не надо изучать dsl, проще отдавать на доработку верстальщикам

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

Автодополнение на html тэги? Потому что автодополнение на типы данных которые рендерятся есть в любом статически типизируемом compile-to-js

как шаблонизатор заставить типы проверять?

Ну в дотнете Razor с этой проблемой справляется

А чем, по твоему, шаблонизатор лучше?

Ну, как минимум разметка отделена от кода модели/прочего бойлерплейта. Хотя на данный момент набирает популярность elm архитектура, конечно

Ну, как минимум разметка отделена от кода модели/прочего бойлерплейта. Хотя на данный момент набирает популярность elm архитектура, конечно

А чем такое разделение лучше?

Автодополнение на html тэги? Потому что автодополнение на типы данных которые рендерятся есть в любом статически типизируемом compile-to-js

ну, я рад за них :)

Шаблонизатор это зачастую тоже html+какойтоязыкдляподстановок, который верстальщику нужно будет учить. Логика на фронтенде может быть весьма развесистая, и отделение разметки от кода не просто не дает преимуществ, но напротив - все усложняет

Шаблонизатор это зачастую тоже html+какойтоязыкдляподстановок, который верстальщику нужно будет учить. Логика на фронтенде может быть весьма развесистая, и отделение разметки от кода не просто не дает преимуществ, но напротив - все усложняет

еее, jquery

Шаблонизатор это зачастую тоже html+какойтоязыкдляподстановок, который верстальщику нужно будет учить. Логика на фронтенде может быть весьма развесистая, и отделение разметки от кода не просто не дает преимуществ, но напротив - все усложняет

Ну в случае Королева верстальщиком становится разработчик backend, как я понимаю, что тоже чревато

Ну почему, просто фронтенд-разработчику нужно будет освоить scala)

Ну так бывает... чего уж тут...

Ну почему, просто фронтенд-разработчику нужно будет освоить scala)

Нужно будет освоить очень простое подмножество, которые выглядит так же, каки в любом с-подобном языке

Нужно будет освоить очень простое подмножество, которые выглядит так же, каки в любом с-подобном языке

+ И вон у них Elm есть - почти хацкел, и - что бы вы думали - полульзуется популярностью)

+ И вон у них Elm есть - почти хацкел, и - что бы вы думали - полульзуется популярностью)

Ну не совсем так. Он пользуется популярностью у жс разрабов, а мы тут о верстальщиках. Плюс, популярность у него не такая уж и большая, как кажется.

просто многие про него слышали

+ И вон у них Elm есть - почти хацкел, и - что бы вы думали - полульзуется популярностью)

Все кто пользовался из знакомых отзывались негативно

стоит сказать что они фронтендеры пришедшие с react/redux а не бекендеры пришедшие с haskell/scala

От пары фронтендеров, которые пришли один с js, другой с php -> js, слышал напротив положительное мнение

Вообще, вроде верстальщик и не занимается шаблонами и подобными штуками

хождение в апишки, наполнение верстки данными, ее оживление это уже фронтендер

хождение в апишки, наполнение верстки данными, ее оживление это уже фронтендер

да, но в случае классического js стэка тот же верстальщик потихоньку начинает это все делать и натурально растет в js frontend. В случае scala.js он может начинать подключатся в логику фетча данных но вырастет получается в скалиста ?

да, но в случае классического js стэка тот же верстальщик потихоньку начинает это все делать и натурально растет в js frontend. В случае scala.js он может начинать подключатся в логику фетча данных но вырастет получается в скалиста ?

и мир станет чуточку лучше

прекрасно же, что можно и туда, и сюда расти)

Я много не пробовал scalajs, но возникло ощущение, что у него interop так себе

Я много не пробовал scalajs, но возникло ощущение, что у него interop так себе

интероп норм, можно выразить всё

но сам жс такой, что иногда всё это плохо ложится на типы

тут уж дело не в скале

По поводу верстальщиков без всяких теоритезирований - на практике они отлично осваивают Королев. Программист делает "инженерную верстку" -- тупо дивы на которых мапятся данные и баттоны для обработки кликов. Это отдается верстальщику и он уже наводит красоту.

тут уж дело не в скале

пожалуй, да)

По поводу верстальщиков без всяких теоритезирований - на практике они отлично осваивают Королев. Программист делает "инженерную верстку" -- тупо дивы на которых мапятся данные и баттоны для обработки кликов. Это отдается верстальщику и он уже наводит красоту.

ты не думал добавить мета информацию в верстку (в дебаг режиме как минимум), чтобы верстальщикам было проще определить класс-метод в котором нужно менять верстку для конкретного блока хтмл? если вдруг кто дорастет на королеве до серьезных приложений с кучей компонентов - поиск нужного файла может стать маленьким адом)

По-моему интероп там отличный

На уровне с пьюрскриптовым

Ещё более нативный - это действительно опциональная типизация как в typescript

ты не думал добавить мета информацию в верстку (в дебаг режиме как минимум), чтобы верстальщикам было проще определить класс-метод в котором нужно менять верстку для конкретного блока хтмл? если вдруг кто дорастет на королеве до серьезных приложений с кучей компонентов - поиск нужного файла может стать маленьким адом)

А чем обычные комменты через // не подходят?

Или ты имеешь в виду чтобы через DOM-инспектор можно было переходить?

Или ты имеешь в виду чтобы через DOM-инспектор можно было переходить?

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

Не знаю на счет верстальщиков, но тестировщики добивали в код qid /= "the-emelent-should-be-clicked" чтобы селениум мог ориентироваться. Это видно через DOM-инспектор. Дальше Ctrl+C, Ctrl+F, Ctrl+V, Enter

@fomkin просто представь, что новому верстальщику дают скалапроект с королевым в котором куски верстки размазаны на сотню файлов хотя бы и говорят - поправь вон ту кнопку, причем тыкают на экране, а не в коде

Такое решение норм?

Такое решение норм?

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

ERROR: S client not available

Я понял идею. Хороший фича-реквест.

Это типа source map, только для html?

@fomkin просто представь, что новому верстальщику дают скалапроект с королевым в котором куски верстки размазаны на сотню файлов хотя бы и говорят - поправь вон ту кнопку, причем тыкают на экране, а не в коде

Ни разу в жизни с такой проблемой не сталкивался. 1. Отрываешь форму 2 находишь где конопка 3 переходишь в ее компонент 4 профит... Если это только не говнопроект где говнецо ровным слоем размазано по всему проекту)

Это типа source map, только для html?

типа того, но не слышал чтобы браузеры поддерживали подобное. поэтому просто упрощенный костыль в атрибуты узлов автоматом добавлять метаинфу. я делаю примерно так implicit meta:MetaSource и микро-макрос который отдает c.internal.enclosingOwner.owner.fullName && c.enclosingPosition.line - в самом простом виде. кстати в сложных монадках-их-трансформерах и т.д. бывает теряется контекст и не совсем в курсе что именно навернулось. И поскольку я крайне ленивый и не всегда пишу фейл политики на все случаи жизни, то использую подобный макрос и для них тоже

интересно, вспомнились сишные макросы с подобной инфой

Ни разу в жизни с такой проблемой не сталкивался. 1. Отрываешь форму 2 находишь где конопка 3 переходишь в ее компонент 4 профит... Если это только не говнопроект где говнецо ровным слоем размазано по всему проекту)

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

Ну вот мой експириенс в ангуляре... А я не эксперт ав ангуляре... 1. Мне тычут на кнопку на экране, говорят поправь. 2. Я смотрю на адрес 3. Лезв в app.routing.ts там ищу подходящий шаблон, там компонент

4. В компоненте ищу сопутствующий шаблон... Там кнопка... Ну выпонели, карочи

Так что у меня тоже на ангуляре уходит порой пара минут...

Для SPA -аппликух имхо это неизбывное зло

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

Да, переход на личности это круто. Очень по взрослому... 2-3 минуты это только в первые дни отнимает. Потом не нужны подсказки и знаешь где что лежит. Я просто к тому, что это не такая большая проблема, чтобы ее прямо серьезно решать и возводить в абсолют.

Для SPA -аппликух имхо это неизбывное зло

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

http://slick.lightbend.com/news/2018/03/06/slick-3.2.2-released.html

Да, вероятно это решение

http://slick.lightbend.com/news/2018/03/06/slick-3.2.2-released.html

воу воу

не судьба ему умереть пока что)

> Do not generate constructor methods for more than 254 columns

Когда мы уже слезем с RDBMS и вернемся к старой доброй работе с файлами

dbf?

Да, переход на личности это круто. Очень по взрослому... 2-3 минуты это только в первые дни отнимает. Потом не нужны подсказки и знаешь где что лежит. Я просто к тому, что это не такая большая проблема, чтобы ее прямо серьезно решать и возводить в абсолют.

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

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

А где ты там обиду увидел? )) Я просто отфильтровал тебя как школьника, по твоему тексту) Взрослые люди обычно не кичатся тем, что они какие-то большие проекты делают, а все во круг в песочнице возятся с танковыми хоумпагами))

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

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

golang_ru?

golang_ru?

Почему го, а не котлин например?

не знаю, как в котлине выяснять размер проекта

в го - посчитать кол-во if err != nil { return err, nil }

А где ты там обиду увидел? )) Я просто отфильтровал тебя как школьника, по твоему тексту) Взрослые люди обычно не кичатся тем, что они какие-то большие проекты делают, а все во круг в песочнице возятся с танковыми хоумпагами))

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

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

Ок, я буду ждать)

и ладно б, о чём-нибудь дельном посрались

так вот "нужно ли отлаживать CSS" в скалачате главная беда

Да вроде не срались вообще) обменялись любезностями и все)

да с рудогмой по-моему это постоянная история выяснения кто школьник, а кто нет)