UbuRus

Ну почему, еще как удивили отсутствием 32Gb версии MacBook.

Уже больше года как живу без флеша (отключил сам) firefox, chromium на GNU/Linux. Полет нормальный.

Ну что ж, видимо Kotlin окончательно победил в борьбе JVM языков

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

Назовите хоть одну FOSS лицензию которая это позволяет.

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

Ну это не совсем так, я же посмотрел скажем половину кейноута второго дня, и вроде доклад не пропускал и по одной половине отзыв писать не хочется.

Опрос обычно содержит отзывы на доклады, и они обязательны. Как я могу оставить отзыв на доклад если половину доклада так и не смог увидеть? :(

Anyway, еще в пятницу/четверг отправлял письмо то-ли на tickets@jokerconf.com, то-ли на questions@jokerconf.com но так и не получил ссылку на опрос

После этой ужасной трансляции считаю что нужно высылать ссылки на видео без стандартного опроса. Не то чтобы мне тяжело написать отзыв, нет, я всегда это делаю с удовольствием. Вот только нормально посмотерть смог только третью часть конференции :( А еще я так и не получил ссылку даже на опрос!

У любого кода, синтаксиса, DSL есть особенность — пока ты с ним плотно работаешь — он читается и понятен, как только ты его не видел какое-то время он забывается. Для меня возвращение к сложным регекспам на разных языках (с учетом того что тут 14 стандартов) всегда боль, и тут конечно же regex101 like удобно. Но зачем сервис, если есть такой приятный DSL, с которым я легко прочитал все примеры? При этом с Kotlin, в отличии от других языков, не нужно поддерживать хинты для IDE или еще что-то, IDE подсказывает мне что я могу использовать в конкретном месте без лишних телодвижений со стороны автора или пользователя.

Судя по всему меньше (около 2500mb), т.к. на /usr/lib/jvm/java-9-oracle/bin/java -Xmx3g -Xms3g у меня успешно выполнился приведенный выше код.

Как не грустно есть еще разработчики которые верят в System.gc() :sad:

> Работать с template во втором ангуляре довольно удобно. Пример приводить не буду, можно посмотреть в доках или англоязычных статьях.

Не нашел в доках как template помогает делать те самые порталы о которых идет речь, можно хотя бы ссылку на ту самые доки?

> И, кстати, пример использования и применения этого тега и технологии в реакте я нагуглить не смог.

Очевидно, потому что он там не имеет смысла и не нужен.

> Во втором ангуляре нет больше ни formatters, ни parsers.

Ура, что еще можно сказать.

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

Декларативно описывается только синхронная валидация, самый большой геморой всегда это асинхронная валидация, например описание ошибочных полей в ответе на запрос. И в тех же redux-form она выглядит очень понятно и просто. В первом ангуляре это был сущий ад, во втором не видно координальных улучшений.

> Не барское это дело, доки читать. А ведь во втором ангуляре это сделать не то что просто, а очень просто. Я, кстати, писал статью про DI в ангуляре, и там этот момент присутствует. Да и в доках это не так уж далеко спрятано.

Ну я хотел подтолкнуть дискуссию в сторону проблем иеархического инжектора, например когда в одном ветке мы имеем отдельную реализацию (subtree1), и в одном из компоненте этой ветке хотим достать другую (например root) реализацию, а не переопределенную.

> Если применять грамотно, то проблем не будет.

Утопично

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

Ну как минимум на сегодняшний день для реакта уже есть готовая экосистема (библиотеки, компоненты), а для второго ангуляра — нет. Совсем скоро я пророчу что они где-нибудь что-нибудь переделают, сломая обратную совместимость и усложнив апдейт. Для первого ангуляра кстати за всю его жизнь так и не появилось хорошей, простой библиотеки компонентов: обожглись на angular-ui (вроде так называлась) комонентах, которые были ужасно бажные.

> Новичкам в проекте. Когда новый человек приходит в команду, где используется ангуляр, он быстро сможет разобраться в проекте, ведь архитектура проекта и бОльшая часть используемых технологий заранее известна. Если проект на реакте, то из-за большого количества различных решений для одних и тех же вещей шанс, что ты будешь знаком со всеми технологиями в проекте намного ниже. Например, кто-то из реактовцев писал, что они используют аналог ангуляровского DI для построения архитектуры, кто-то берёт redux, кто-то использует flux и его реализации. Вот простенький пример: что в реакте обычно используется в качестве http-клиента? В доках берут jQuery, кто-то возьмёт fetch, кто-то городит свои решения. В ангуляре же этот частоиспользуемая часть входит в состав фреймворка, и либо используется напрямую, либо через парочку распространённых решений на базе оного.

Redux и есть Flux. Как раз таки на примере http: окей, кто-то взяли jquery — и? Главное знать маленький и понятный React и понимать Flux, а доступ к данным по http плюс-минус выглядит одинаково в любом фреймворке, тем более в проекте будут видны и понятны паттерны использования.

> Т.е., мол, когда ты учишь реакт — ты учишь JS и эти знания тебе пригодятся.

Так и есть, я знаю весь первый ангуляр вдоль и поперек, перечитывал сорцы десять раз и знаю что и как внутри устроенно. С выходом ангуляр 2 — 80% этих знаний — бесполезный мусор, хоть в целом подход не поменялся нужно всё учить заново.

> Однако, при использовании и изучении ангуляра (особенно второго), я стал лучше понимать принципы построения архитектуры приложений, больше узнал про DI, где и как его применять, как он устроен и т.д., узнал про всякие новые стандарты как ES (декораторы, новые методы из стандартной библиотеки, и прочие штуки), так и Web-технологий в целом: Web animations API, File API, html template, shadow dom и т.п.

Это не заслуга ангуляра, это недостаток вашего образования и познаний.

> А вот реактовцы часто не знают, что такое тот же DI и зачем он нужен, «ведь есть же import/require», говорили они.

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

> Вы спрашиваете про template, хотя это стандарт.

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

> Плюс, если в ангуляре класс-компонент — это просто обычный класс, без своих полей и методов, то в реакте компоненты наследуются от какого-то класса, в котором полно «зарезервированных» методов и полей: все эти this.props, this.state (и куча методов, относящихся к манипуляциям со state), render(), управление жизненным циклом компоненита и другие. Да, во втором ангуляре тоже есть методы для, например, управления жизненным циклом. Но, во-первых, в доках рекомендуется при их использовании добавлять к классу имплементацию соотв. интерфейса, а, во-вторых, почти все эти методы используют префиксы, что позволяет не засорять «пространство имён» и уменьшить вероятность конфликта с другими библиотеками. Т.е. сам фреймворк прививает хорошие практики написания кода.

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

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

Ух ты, принудительные inline стили, логика в шаблонах. Всё таки вам стоит написать to-do app на реакте, а еще лучше посмотреть видео-лекции Данила Абрамова на egghead прежде чем делать неправильные выводы.

Почитай-те 4 свободы свободного ПО, вы говорите про опен сорс.

> Copyleft означает свободное программное обеспечение. Потому что если я могу форкнуть, собрать и получить работающий продукт, то мне не надо за него платить.

Да, но в FOSS есть не только Copyleft лицензии, есть еще пермиссивные и они позволяют тоже самое. Так что упомимание тут именно Copyleft говорит о непонимании сути FOSS.

Любой FOSS имеет открытые исходные коды, о чем и гласит первая и третья свобода:

1. Программу можно свободно использовать с любой целью («нулевая свобода»).
2. Можно изучать, как программа работает, и адаптировать её для своих целей («первая свобода»). Условием этого является доступность исходного текста программы.
3. Можно свободно распространять копии программы — в помощь товарищу («вторая свобода»).
4. Программу можно свободно улучшать и публиковать свою улучшенную версию — с тем, чтобы принести пользу всему сообществу («третья свобода»). Условием этой третьей свободы является доступность исходного текста программы и возможность внесения в него модификаций и исправлений.

(спасибо википедии за перевод)

Т.е. FOSS говорит о свободе ПО, при этом copyleft лицензии могут быть «фатальны» для коммерчиских компаний т.к. требуют открытие производных работ.

В случае OSS достаточно иметь открытые исходники, при этом может быть запрещено модификация или распространение собранных программ и т.д.

Вообще вам стоит послушать Бородатого (Richard Stallman) чтобы уложилось в голове отличие FOSS и OSS. Либо почитайте FSD и OSD.

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

Что за бред

Подскажите же, покажите же! Кто же эта темная лошадка в мире JVM для которой всё это не новое?

Non-null не генерируют такие проверки повсеместно, а только когда идет интероп с Java кодом. На чистом Котлине их практически нету.

Read-only коллекции (справедливо) — это не сахар, это просто интерфейс, а реализация подкладывается JDK. Сейчас готовят именно immutable реализацию коллекций.

Вызовы extension методы не порождают обектов, это просто статические методы. Инлайн может сделать джит в этом случае.

Кстати про инлайн — возможность инлайнить лямбды по месту вызова это очень круто, особенно для тех кто вынужден сидеть на старых JDK.

Эм, вы не сходили в доку и хотите чтобы я вам перечислил фичи языка которыe могли бы сами почитать по содержанию в доке? http://kotlinlang.org/docs/reference/

А в Котлин 1.1 еще вот это всё: https://blog.jetbrains.com/kotlin/2016/07/first-glimpse-of-kotlin-1-1-coroutines-type-aliases-and-more/

А Java 8 всё еще далек от современного языка, Котлин на голову выше, но всё еще прост и понятен любому Java разработчику.

Новое например то, что с первой версии у него отличная поддержка IDE, для Scala IDE до сих пор тормозит.
Новое то, что много его абстракций «бесплатные» в рантайме: null типы, немутабльные коллекции, экстеншен функции, лямбды.
Котлин достиг скорости сборки такой же как у Java (реверанс в сторону Scala)
Для андроида у Котлина есть подаркок: малое количество методов в std, маленький вес std и Anko.

При полном интеропе с Java язык быстро развивается.

Наконец-то разработчики получили замену Java, а не скриптовый язык (Groovy) или вообще фп (Clojure, Frege, Scala).

Сорри, но template и DocumentFragment не как не помогут вам с производительностью. Вы все равно придете или к идеям idom или vdom, либо в процессе разработки приложения напишите свой велосипед.

Сравнивать нужно одинаковые вещи, компиляция и запуск веб-приложения на Котлин занимает на моем ульрабуке 4-7 секунд. Сборка и деплой на замарине скорее всего не отличается по скорости от Java/Kotlin, потому что львиная доля этого времени — старт эмулятора.

В общем начить спорить на тему Kotlin (+ Java Platform естенствено) vs С# не вижу смысла.

Уже подтвердили, Дмитрий Жемеров в одном из последних выступлений.

Какие тормоза? По сравнению с Java не ощущаю никакой разницы, тесты это в общем-то подтверждают: https://kotlin.link/articles/Kotlin-vs-Java-Compilation-speed.html

Котлин как раз таки повседневно используется. Сильно взлетел в мире андроид. А еще начали пилить Kotlin Native.

https://toddmotto.com/angular-3-alpha

Можно всё что угодно прокинуть корневому компоненту и детям через context https://facebook.github.io/react/docs/context.html

Пример с редакс-стором
https://github.com/reactjs/react-redux/blob/master/src/components/Provider.js#L23

В аурелии есть четкие импорты(в ES2015 нету же интерфейсов), или это не тот DI?: http://aurelia.io/hub.html#/doc/article/aurelia/dependency-injection/latest/dependency-injection-basics/1

Т.е. стандартный роутинг убог и ангуляру срочно нужен новый роутер? История повторяется, или просто парням с angular.ui очень хочется чтобы пользовались их роутером?

По сути сейчас весь DI в react делается через HOC, тот же connect, который делает инжекшен стейта и экшен крейторов в компоненты.

Я сам из мира JVM и весь DI который я видел в JS(angular 1, angular 2) видится мне убогим. У меня есть идеи как сделать правильный DI, но там нужен TypeScript, чтобы иметь интерфейсы и не писать лишний код.

Но можно сделать без TS, просто придется писать токены сервисов самому (аля angular1). Я вижу DI в реакте так: у нас есть Injector, которому мы регистрируем имена сервисов + реализация, мы можем создать несколько инжекторов и дать им имя, это удобно для создания разных контекстов (например http сервис для обращения к своему бекенду и отдельная конфигурация сервиса для обращения к бекенду site.com.

Далее инжектор строит «контекст» и мы можем прокинуть его через провайдер во все реактовские компоненты.

Остается написать свой HOC который будет брать инжектор и прокидывать желаемые сервисы в пропсы:

inject('myCustomInjector', ['http', 'base64'])(Сomponent)
// injector — myCustomInjector
// сервисы — http, base64

inject(['http', 'base64'])(Сomponent)
// injector — default (root для всех инжекторов)
// сервисы — http, base64

использование:

let Сomponent = (props) => {
const {http, base64} = props;

…
}

есть много проектов для DI, краткое гугление даже выдает нечто подобное описанное мной:
https://github.com/michael-shattuck/react-injector

но почему-то в целом DI не популярен в React, я не буду защищать эту позицию, просто скажу что тестирование компонентов на порядок удобнее чем в ангуляр, даже без DI

А вы в этом плане. Нет, обращение к нему конечно придется сделать, но манипулировать DOM'ом — нет. Самое главное что после мониторвания реакт в каком-то месте, больше не понадобится иметь не единого селектора в коде.

Сразу после того как вы напишите мне на чистом jquery тоже самое. Очень нужно, так нужно что даже в гугле забанили https://github.com/enaqx/awesome-react#forms

Afaik тут полная абстракция над DOM https://github.com/facebook/draft-js
Не понял почему какая-то галерея не может быть реализована

Спасибо что поддержали дискуссию!

> Если шаблон — просто кусок HTML без биндингов

нет, конечно же такой пример не интерестен, нам интересны шаблоны с биндигами, но даже на простом куске HTML React выглядит красивее и идеоматично с точки зрения HTML:

<...>
<JustFewHtmlTags/>
</...>


> А в реакте по-сути, тот же $compile

Вообще не так, плохая аналогия, $compile создает новый скоуп, вешает листенеры https://github.com/angular/angular.js/blob/master/src/ng/compile.js#L2750 и т.д. JSX же просто способ описать кусочек виртуального дома.

Мы делаем $compile когда нам нужно сделать динамический компонент. В реакте за счет jsx — всё динамический компонент.

> то используется специально предназначенная для этого штука — HTML templates

Могли бы показать где описана эта штука? Нет, в гугле не забанили, просто нету такого понятия в документации:

site:angular.io html templates


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

https://habrahabr.ru/post/305892/

> Да и в доках советуют обёртки создавать.

Прочитайте пожалуйста документацию еще раз, ничего такого там не написано.

> Они прекрасно подходят для расширения готовых компонентов. Так, например, я могу сделать директиву-валидатор и использовать её и со стандартными, и со своими кастомными контролами:

```

<my-custom-control myValidator></my-custom-control>
```

ух, это классный валидатор будет, особенно доставляет разбираться в то что где когда дернется, а если несколько директив повесить, самый сок, не забываем про formatters и parses на ngmodel.

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

А вот это выглядит отлично, после двух лет разработки на ангуляре как глокот свежего воздуха: http://redux-form.com/6.0.5/examples/simple/

> По-мне, это куда лучше, чем это…

По мне все директивы это 1% от того что я могу сделать в JSX

```
<li *ngFor=«item of items»>{{ item.text }}


const ItemsList = (items) => (
{items.map((item, idx) => {item.text}}

);


</...>
```

И то чего всегда не хватало в ангуляре:

```
<...>
<Component {...this.props}/>
</...>
```

> Второй ангуляр, в отличие от первого, супер гибкий.

Окей, как мне сделать два инстанса Http сервиса с разным списком интерсепторов? Если и есть способ из коробки, придется лезть в доки и разбираться. Но вообще речь шла про View, выше обсудили достоинства JSX.

> Да, и он очень часто более удобен, чем его односторонний вариант.

jQuery тоже удобно, но хочется писать понятный, поддерживаыемый софт. Двухсторониий биндинг битч первого ангуляра. Посмотрите на так называемые controlled inputs в Реакте.

Ну т.е. в целом вы к сожалению не разбираетесь в Реакте так что ничего конкретного про Реакт. Но Ангуляр хорошо защищаете.

> В итоге, у каждой команды получается свой фреймворк, который нужно самим поддерживать в актуальном состоянии.

Это беспорно, но зато легко апдейтить отдельные части, не будет таких проблем как апдейт с angular 1.3 на 1.4.

> Новичкам труднее вникнуть в новый проект, так как никакого более-менее единого набора нет.

Новичкам чего? Js? Это очень спорно, порог вхождения в ангуляр между тем огромен, и позновать его можно долго.

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

Моё мнение нужно взять то, что более предсказуемое и лучше масштабируется. Это явно не про ангуляр.

Да нет, вот например баги в firefox https://bugzilla.mozilla.org/buglist.cgi?quicksearch=dom

Отвечаю про то что реакт вьюха и мол без Flux или чего-то еще на нем нельзя выстроить архитектуру.

Можно, тут всё что нужно есть, для этого. Если что даже Данил Абрамов не советует брать редакс пока вам хватает просто реакта.

> Вы полагаете, что человек, который вот так вот заваливает гхм… модный блогодвижок wordpress десятками плагинов, не смог настроить frontend-сборку, прилепил на скорую руку корзину и пр. к своему монстру… ну и т.д… Вы действительно полагаете, что этому человек для полного счастья не хватает View на основе virtualDOM-а?

Я считаю что для этого счатья есть SPA. Но оно требует больше эффортов. Мир не идеален к сожалению.

> jQuery это набор инструментов для работы с DOM и не только. А React это вьюха. Причём вьюха такого толка, что по-хорошему к ней требуется грамотная инфраструктура, жел-но на ФП-основе.

Да из которых чаще всего используются только селекты, ajax и хелперы типо show/hide. В React не нужны селекторы и show/hide, а ajax добавляется любой библитекой. На Реакте очень просто выстроить архитектуру, а вот jQuery и архитектура вещи как правило не совместимые: вездущий coupling и отсутвие тестируемости.

Нет, мы серьезно обсуждаем плюсы и минусы Реакта и Джеквери?

Давай-те я выражу свою мысль по другому и думаю вы согласитесь: сегодня jQuery это отличная подпорка, до тех пор пока в проекте их не становится слишком много. И мой консерн был в том, что так происходит в реальном мире. Не всегда, не в каждом случае. Но происходит.

> Это куда проще, чем правильно выстроить тот же Redux. Да и вообще следовать методологиям из ФП.

Проще выучить особенности API всех брайзеров? Нет, React учится за день и работает сносно на большинстве задач. Есть готовые заоптимайзенные компоненты (например для больших гридов).
Есть виртуальный дом.

Если будуте писать всё это руками погрязнете в знаниях которые необходомы для этого и в итоге напишете свою библиотеку.

> Да и вообще, прежде чем использовать тот или иной фреймворк, нужно понять почему и как он работает. А не наоборот.

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

К сожалению часто на wordpress делают вещи сложнее чем обычный бложек, где сначала подпилят формочки, потом менюшечку, потом анимацию, добавят ленту твиттера, фейсбука, вк. Добавят корзину, чекаут. Видел сайты на wp с 30+ js скриптами. Конечно нельзя сравнивать плагинную систему предназначенную для простых пользователей и фреймворк для написания веб приложений. Я вообще говорил о том, что места где подключают jquery можно часто заменить на react и получить тот же эффект.

К сожалению специалистов которые понимают как правильно и прямо работать с DOM исчезающее малое колличество. Поэтому для продукта стоит в первую очередь взять фрэймворк/библиотеку, а потом уже пытаться быть оптимизатором. В общем случае попытка написать большой продукт «правильной, прямой работой с DOM» можно назвать преждевременной оптимизацией.

Реакт займет примерно те же кб что и jquery. Странички где вот тут чуть-чуть добавить интерактивности и там чуть-чуть добавить интерактивности обычно превращаются в монстров (примеры блоги на wordpress). Там я бы все же делал SPA + серверный рендеринг.

Vanilla js конечно нужна и важна, но всё таки у нас скоуп — SPA. Обсуждение React, Angular и т.п.

Кстати jquery может дружить и с ангуляром и с реактом, но писать на нем большие приложения себе дороже.

Надежный фундамент для лапши и проблем с производительностью.

Если вы в 2016 не поняли что руками DOM лучше не трогать, то мне вас искренне жаль.
И тем более делать селекторы в JS.

Да, понятно что flux и redux в частности это просто принцип, архитектура. Я пробовал ng-redux. И могу сказать что лучше всего сегодня flux всё-таки работает с React. Но и в ангуляре он неплох, просто производительность начинает страдать, нужно разбивать очень гранулярно компоненты, а это не всегда удобно.