oleg008

26 октября 2015, Berlin, Germany

# Понедельник 63 твита

Привет, на этой неделе с вами @oleg008. Я занимаюсь фронтендом, раньше также писал на ноде. Работаю на @chatgrapecom.

9:08

Трачу кучу времени на опен сорс. Вот мой эккаунт github.com/kof. Один из моих последних проектов github.com/jsstyles/jss

9:09

Буду говорить о десктопном и мобильном фронтенде ну и обо всем что с ним связано. Сегодня темя дня #css написаный на #javascript.

9:11

Когда-то я написал вводную статью о #jss medium.com/@oleg008/the-i… чтоб обьяснить какие проблемы это решает в двух словах.

9:14

чтобы не повторять то что уже написано в блоге и на гитхабе, было бы интересно услышать вопросы по github.com/jsstyles/jss а так же критику

11:00

кстати @cssunderhood моя тема сегодня плотно пересекается с твоей)

11:00

кстати jss нужен как бы не всем, обычные лэндинги - врядле, весь упор на компонентизацию, в реакт оно идет лучше github.com/jsstyles/react…

11:02
@jsunderhood есть пример сложного компонента, такого когда используется пару экранов css, выраженный в jss?
11:19

сложных компонентов быть в принципе не должно) они на то и компоненты чтоб быть простыми @yuritkachenko

11:22

проект над которым я работаю написан с #jss но он не открытый, хотелось бы портировать todo app на него, есть jsstyles.github.io/jss-examples/c…

11:31

вот накидал просто примеров из проекта c #jss и #es6 gist.github.com/kof/96dad9a4d6… @yuritkachenko

11:37
@jsunderhood А не изобретаете вы велосипед? Я о CSS module которые прогнали через stylus (сахар) и postcss(все!) при сборке webpack'ом.
11:38

мне почему то кажется что stylus + postcss + webpack вот это велосипед, причем такой очень сложный с кучей привязок, в jss все проще

11:39
@jsunderhood сейчас расстояния между JS и CSS стремительно сокращаются. Это удобно. Про компоненты в верстке я тоже собираюсь поговорить.
11:40

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

11:41
@jsunderhood а как вы изолируете компоненты от наследуемых свойств, например, line-height?
11:42

наследование реализуется более прямым способом github.com/jsstyles/jss-e…

11:43
@jsunderhood ну или если в окружении виджета стоит * { box-sizing: border-box }
11:43

вопрос чье это окружение, если ты пишешь виджет который встраивается в чужой сайт то тебе надо перегрузить глобальные рулы @andrey_sitnik

11:45
@jsunderhood как же там много кавычек и не нужных синтаксических конструкций типа конкатинации и rgbaString
11:45

согласен, некий шум есть, но есть консистентность и четкая логика @andrey_sitnik

11:47

если очень хотеть избавиться от ковычек можно придумать свой язык on top of js и сделать все значения встроенными @andrey_sitnik

11:49
@jsunderhood мне вот не нравится работать с css в JS, есть проблемы например с редакторами, надо переписывать snippet, подсветка и т.п.
11:50

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

11:51

поэтому я считаю скорость печати ВООБЩЕ НЕ ВАЖНА, важна четкая логика - легкость понимания и отсутствие багов ... @cssunderhood

11:52

всегда хотел увидеть людей которые строчат css с такой скоростью чтоб без автокомплитов прям процесс разработки замедляется @cssunderhood

11:53
@jsunderhood а есть данные по производительности, допустим сейчас есть фича css, которую можно делать js (циклическое движение облаков)
11:54

jss производит обычные стили, вставляет style элемент, поэтому нет разницы в данном примере @ErrorSoul

11:55
@jsunderhood так как именно это автоматически делается в JSS, если его цель компонентная изоляция CSS?
11:57

магии нет, хочешь перезагрузить глобальный css - делай это ручками, это впринципе легко смотри jss-extend и es6 {...} @andrey_sitnik

11:59
@sapegin @jsunderhood я, конечно, стили в js писал только для React Native, но мне вполне понравилось и ада не видел )
12:03
@jsunderhood ну изоляцию селекторов руками через БЭМ тоже можно сделать. Всё таки смысл компонентного прохода в автоматической изоляции
12:05

да, с БЭМ можно жить, но наименования остаются глобальными и их надо хорошо продумывать и это не легко и не красиво @andrey_sitnik

12:06
@jsunderhood я не считаю БЭМ — хорошим решением. Конечно же надо изолировать автоматически.
12:07

именно поэтому все классы в #jss сгенерированы, именования локальные и могут быть плохими, это не растекается по приложению @andrey_sitnik

12:09
@jsunderhood а что если просто использовать css-modules? @andrey_sitnik
12:16

все еще только пол решения, нужны константы, функции итд. и в идеале доступные из js, кстати функции в css всем нравятся? @alexeyraspopov

12:17
@jsunderhood изоляция классов — только половина решения. Сейчас CSS Modules + postcss-autoreset + postcss-initial даёт и изоляцию свойств.
12:22

это можно и нужно добавить в jss, возможно в виде плагина @andrey_sitnik

12:22
@jsunderhood в css этот стафф нахер не нужен. Нормальный декларативный язык.
12:23

тебе не нужен ... в css это все не зря добавляют ... @alexeyraspopov

12:24

впринципе добавить all: initial; в каждую рулу тривиально через плагин для jss, надо срочно сделать) @andrey_sitnik @iamstarkov

12:37
@jsunderhood полифил не забудь, так как IE не держит свойство all
12:46
@jsunderhood если взять тот факт, что существующие проекты используют webpack+preCSS+postCSS - какой профит от перехода на jss
12:50

не зная проект сказать не могу, #jss это не швецарский нож, даже если очень хочется засунуть его везде, лично мне @blia

12:53
@jsunderhood какие проблемы нельзя решить через postcss, которые решает jss?
12:55

с postcss можно решить большинство проблем, нельзя автопрефиксинг в рантайме - тоесть надо грузить все префиксованые декларации @gusnkt

12:57

автоматизированой изоляции от наследуемых свойств пока что нет, идею мне подкинули тут сегодня и я создал ишью,а так ручками @ierhyna_web

13:00
@jsunderhood @gusnkt PostCSS можно и в на клиенте запускать с помощью github.com/postcss/postcs…
13:01
@cssunderhood @jsunderhood вообще CSS-in-JS — это 3 разных вопроса: трансформации CSS на клиенте, JS-синтаксис для CSS и изоляция
13:30
@cssunderhood @jsunderhood например, есть Styling с JS-синтаксисом, но на сервере и через PostCSS с CSS Modules github.com/andreypopp/sty…
13:31
@cssunderhood @jsunderhood а есть react-postcss с динамическим CSS на клиенте, но без JS-синтаксиса github.com/mungell/react-…
13:31
@listochkin моей вахты еще не было, там будут темы поинтереснее :) @jsunderhood
14:12

давай @alexeyraspopov порви всех чувак!

14:13

готовься, подмывайся, будешь следующим) @alexeyraspopov

14:25

для тех кому собственно проект интересен: мне нужна помощь в его развитии: новая документация, интересные примеры, todo app итд

14:41

вот кстати табличка с популярными css in js решениями, правда критерий мало github.com/MicheleBertoli…

14:58
@andrey_sitnik @jsunderhood потому что писать надо на clojure
20:24

кстати да вот интересно было бы посмотреть как jss стиль на clojure будет выглядеть @mr_mig_by

20:25

вот кстати вам пример не тривиальный использования, пока что еще в работе, мигрирую библиотеку @elementalui на #jss github.com/elementalui/el…

20:34

вот таких контрибутеров я желаю всем кто делает свои опен сорс проекты github.com/jsstyles/css-v…

21:46
@slonoed @jsunderhood @mr_mig_by а какие у CSS концепции что не могут быть представлены данными в clojure? Просто наборы правил, нет?
22:15

# Вторник 50 твитов

@andreypopp @slonoed @jsunderhood да ну, забейте, это все привычки.
Стоит попробовать поюзать пару раз, чтобы понять всю прелесть подхода
8:19

всем доброе утро, сегодня можем поговорить о кроcсплатформенной разработке ui на js

9:24
@jsunderhood в смысле десктопной разработке на js?
9:29

в смысле о мобильно вебной разработке

9:29

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

9:31

В общем пару лет назад я работал над своей идеей и решил делать мобильное приложение на js) В тот момент очень шумела одна либа famo.us

9:33

То что вы видите сейчас на их сайте это их новое направление к которому они перешли потерпев неудачу со старым.

9:34

До этого они подняли 25мио на js framework который должен был позволить писать нам приложения со сложными переходами и жестами как на нэтив.

9:36

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

9:38

вобщем ишью я насоздавал там немало github.com/Famous/famous/… как выяснилось потом они уже ждали с нетерпением меня) github.com/Famous/famous/…

9:41

продолжу через пол часа, митинг)

9:42
@andreypopp @jsunderhood Они вроде тут теперь famous.org
10:12
@jsunderhood famo.us? Хороший pivot у них произошёл :)
10:15

Вобшем проблема у этой компании в странном понимании опен сорса. Как выяснлилось позже они уже работали над новой версией.

10:18

они как бы открыли свой фреймворк, но никогда не говорили что они там делают и куда ведется разработка.

10:18

вобщем по мне это не опен сорс, это freeware

10:19

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

10:20

вобщем компания famo.us мягко сказать стремная. За то я так познакомился с их на тот момент главным архитектором @dmvaldman

10:21

он вскоре ушел из этой компании и на данный момент разрабатывает на базе своего кода написанного тогда новую штуку samsarajs.org

10:22

он в этом году приезжал в берлин и много об этом рассказывал, в частности вот его видео c @jsconfeu youtube.com/watch?v=biJXpv…

10:25

идея в #samsarajs в том что лэйоут это набор стримов которые надо координировать. Ведь если вы посомтрите на переходы в ios меню с гамбургер

10:28

то это не одна анимация, их целая куча. Вот реализация этого меню на #samsarajs samsarajs.org/examples/

10:29

восновном все движки которые пытаются симулировать такие переходы на js они кастрированые. Просто переход это не все.

10:30

нужно обрабатывать поток ивентов от жестов к примеру при ведении палца и реагировать соответственно координируя ВСЕ анимации для перехода.

10:31

и это сделать совсем не просто, а в частности сделать это эффективно и читабельно.

10:31

АПИ которая позволит самому создавать такого рода переходы не супер сложно насколько я знаю кроме как у этого проекта не существует.

10:32

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

10:33

кто верит что мы сможем писать мобильные ui по качеству не хуже чем нативные на js ретвитьте samsarajs.org @dmvaldman

12:09

давайте перечислим все методы оптимизации перформанса рендеринга на js, я начну а вы добавляйте)

12:58

Проблема с DOM это количество собственно элементов которые находятся в render tree, его надо держать на минимуме.

12:59

Также проблема с DOM в том что очень много медленных методов а также свойства являются сеттерами и неожиданно делают много всего под копотом

13:00

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

13:01

на тему перфоманса скоро будет интересный воркшоп smartme.university/workshop/chall…

13:04
@jsunderhood DOM нормальный. Проблема в том, что мы его дергаем когда нам захочется, а не когда есть для этого ресурсы.
13:24

соответственно проблема с абстракциями ... тк в пользовательском коде ты дергаешь то что надо когда этого требует бизнес логика @roman01la

13:25
@jsunderhood `requestIdleCallback` вроде как призван помочь решить эту проблему
13:26

Следущая оптимизация рендеринга - requestAnimationFrame developer.mozilla.org/en-US/docs/Web…

13:39

если нужна поддержка старых девайсов, есть кроссплатформенный shim для requestAnimationFrame github.com/kof/animation-…

13:40
@AndrewHalych @jsunderhood Ускорения не достаточно. DOM уже говорилось - сложная модель, двигаешь картинку на пиксел=меняешь массу пропертей
14:08
@jsunderhood проблема в том, что порой чтение приводит к reflow

такого не встречал, если есть пример то в студию twitter.com/oelifantiev/st…

15:28
@jsunderhood проблема в том, что порой чтение приводит к reflow
15:28

еще есть проблемы с полупрозрачностью, особенно если такой элемент анимировать

15:44

а еще у нас есть уборщик мусора garbage collector который может заморозить весь ui thread в любой момент, поэтому надо всегда делать паузы

15:47

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

17:19

для этого используется свой кастомный layout engine которые знает где какой контейнер в любой момент времени из js

17:20
@jsunderhood а я давно говорю - даешь возможность менять layout engine в каждый браузер!
19:30

# Среда 7 твитов

по поводу justgetflux.com : я пользовался ей пол года, сначала было непривычно, потом привык

11:48

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

11:49

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

12:07

а вообще может есть какое то грамотное исследование на эту тему? @WarEnek

12:08
@jsunderhood @WarEnek
вот еще: health.harvard.edu/staying-health…
Плюс ко всему синий цвет “насилует" зрение: texyt.com/bright+blue+le…
19:26
@jsunderhood @WarEnek русский вариант статьи: geektimes.ru/post/94441/
19:27
@WarEnek @jsunderhood +1, года 3 уже использую, без нее быстро глаза начинают болеть, отвык от яркости.
19:32

# Четверг 14 твитов

@jsunderhood Я на эту тему заметку писал habrahabr.ru/post/210558/ Не касался там проблем оптимизации самого js (в частности GC)
11:01

расскажу о том как мы на @chatgrapecom мигрируем все на #reactjs

11:10

тк взять все и переписать слишком долго времени займет, нужен процесс миграции. Мы используем github.com/PixelsCommande… @PixelsCommander

11:12

плюс полифил для кастомных элементов github.com/WebReflection/…

11:13

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

11:14
@jsunderhood @PixelsCommander аналогично! Отличная штука
12:12
Object.create(null), ебаный стыд
19:52

Object.create(null) это впринципе простая версия Map, если обьект используется как хранилище данных и ключи вне контроля, то это норм.

19:53
@jsunderhood это стыд, а не норм. Норм это Map.
19:55

для Map нужен полифил, если тебе нужен микро мэп то это Object.create() к примеру использовать это в небольшой либе - ок. @mr_mig_by

19:56

конечно я бы предпочел Map в приложении плюс полифил, там где микро оптимизации размера не важны @mr_mig_by

19:58
. @jsunderhood Если бы разработчики firefox extensions API дизайнили апи жаваскрипта, ajax выглядел бы вот так: developer.mozilla.org/en-US/Add-ons/…
20:28

насколько я знаю фаерфокс сплошной говнокод плюс на экстеншены никто апи не стандартизирует вроде. @mr_mig_by

20:30
@jsunderhood пытаются какбэ слить всё в wiki.mozilla.org/WebExtensions
Но до результата как раком до Китая :(
20:38

# Пятница 57 твитов

А кто может обьяснить почему многие разработчики не любят фронтенд? мне лично не раз попадались ...

12:05

Я когда-то перешел с фронтенда на ноду, года 2 работал, вернулся в фронтенд. Здесь постоянно что-то новое происходит. А там скукота.

12:07

Болшинство бэкендов сводятся к передачи данных из базы кудато еще и к пользователю ...

12:08

Бэкендлеры этакие переносчики стримов)

12:08
@jsunderhood большинство фронтэндов сводится к формошлепству на жквери/ангуляре
12:10
@jsunderhood фронтэндщики этакие преобразователи жсона)
12:10
@jsunderhood Потому что у JS всегда была плохая репутация среди хардокрных программистов. А html/css - это вообще не про программирование))
12:12

незнаю я это вижу до сих пор ... причем даже у людей которые вплотную занимаются фронтендом @Xvakin

12:13
@jsunderhood на бэкенде таки много сложных заморочек типа кеширования, шардинга, поисковых алгоритмов, не знакомых фронтендерам
12:14

по хорошему, шардингом занимаются devops а не бэкендлеры, а поисковыми алгоритами - математики @Xvakin

12:15

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

12:18
@jsunderhood да, но эта нелюбовь к фронтенду отчасти может быть связана с причастностью к верстке
12:23
@jsunderhood @Xvakin UI верстается на CEF/Electron в 4-5 раз быстрее, чем его могут кое-как реализовать на Qt/XAML. Хлеб отнимают!
12:23

Qt это не бэкенд, опять таки я сейчас имел введу только веб @sergo_vitkovsky @Xvakin

12:24
@jsunderhood Там еще и большое количество ненавистников JS как языка.
12:25

да но если учитывать ноду то язык тот же @webholt

12:25
@jsunderhood @Xvakin веб-фронтэнд - это уже не только про веб )
12:26
@jsunderhood ого, фронтенд-инженеры. Так и до фронтенд-CTO недалеко.
12:26

тоесть ты никогда не слышал такой профессии Frontend Engineer? @twenty

12:27
@Xvakin @jsunderhood хардкорные программисты это асм или плюсы?
12:28
@jsunderhood А разработчики на ноде более лояльны к фронтэнду, как мне кажется. Они с ним слишком тесно связаны. Либо не любят и саму ноду.
12:28

кроме языка связи нет. @webholt

12:28
@twenty @jsunderhood Ну а что, на фронтэнде нынче что угодно воспроизвести можно. Упереться можно, в основном, лишь в производительность.
12:29

поздравляю, иди читай что нибудь, повышай развитие @twenty

12:30

определение термина "инженер очень размазанное" поэтому в теории можно, но есть общепринятые понятия поэтому @twenty

12:33

поэтому верстальщики пожалуй пока останутся верстальщиками en.wikipedia.org/wiki/Engineeri… @twenty

12:34

есть кстати Rendering Engineer но это не верстание. @twenty

12:34

как я и сказал в теории могут. @twenty

12:38

ню-ню @twenty

12:39
@twenty @jsunderhood реквестирую название "нормальных компаний"
12:42
. @jsunderhood фронтэнд для молодняка, бекенд для пенсионеров! 👻😱
12:42

забываю) я же инженер, пытаюсь еще и работать между делом)))) @iamstarkov

12:47

нам нужен специальный клиент для твиттера чтоб это все удобно было @iamstarkov

12:48

на данный момент frontend engineer .... покрайней мере так написано в контракте ))) @diedsmilling @iamstarkov

12:51

к счастьтю всем пофиг что эты это сказал) @twenty @diedsmilling @iamstarkov

13:00
@twenty @diedsmilling @jsunderhood @iamstarkov серьезная тема. Т.е. на фронте инженерить нечего? Поддержка не нужна?
13:04
@mr_mig_by @jsunderhood логика такая: если фронтендеры — это инженеры, то тестировщики, дизайнеры и продукт оунеры — тоже инженеры.
13:07

а слышал test automation engineer? наверно я тебя сейчас взорвал @twenty @mr_mig_by

13:08
@mr_mig_by @jsunderhood в таком случае, вот этот твит twitter.com/jsunderhood/st… выглядит как-то оскорбительно.
13:11

лично я просто еще не слышал о html engineeri ... @twenty @mr_mig_by

13:11
@jsunderhood @mr_mig_by я правильно понимаю, что тестировщики — это инженеры? Дизайнеры — инженеры? Верстальщики — инженеры?
13:11

test automation engineer и мануальный тестер этот разные вещи, остальных не слышал таких .. но все может быть) @twenty @mr_mig_by

13:13
@jsunderhood @mr_mig_by UX engineer не слышал?
13:18

у меня был такой титул когда-то, но я впринципе был frontend engineer, это просто дураки писали. В теории да должно быть @twenty @mr_mig_by

13:19
/@twenty @jsunderhood @mr_mig_by я правильно понимаю, что без звания "инженер" программист чувствует себя каким-то неполноценным?
13:20

не знаю насчет полноценности, но разница в зарплате может быть точно) @rubyunderhood @twenty @mr_mig_by

13:20
/@jsunderhood я наблюдал в совковых конторах, что должность "инженер-программист" дают всем, у кого ВО, а "программист" тем, кто без ВО.
13:23
@rubyunderhood @jsunderhood вот вам на всякий случай: slideshare.net/alexeymigutsky…
И вот еще: slideshare.net/zhellaanne/int…
13:26
@rubyunderhood @twenty @jsunderhood @mr_mig_by слово «инженер» по своей этимологии означает тупо «конструктор». То, что сюда приплетают ВО..
14:07
@rubyunderhood @twenty @jsunderhood @mr_mig_by ..просто следствие сакрализации академического подхода. Степень автоматизации -- не критерий.
14:07
@rubyunderhood @twenty @jsunderhood @mr_mig_by инженером является любой собравший из говна и палок по мануалу из "очумелых ручек" скворечник

так и есть. twitter.com/Chudesnov/stat…

14:08

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

14:10
/@Chudesnov @twenty @jsunderhood @mr_mig_by значит я уже к 13 годам был сеньор-инженером!

почему бы и нет! twitter.com/rubyunderhood/…

14:11
I like #javascript more than other languages because...
18:41
@mr_mig_by @jsunderhood cuz `[1] + [1] === 2`

а вот и нет) twitter.com/roman01la/stat…

19:06
@roman01la @mr_mig_by @jsunderhood I like JavaScript because undefined is not a function
19:13

# Воскресенье 22 твита

Вопрос: чем пользуются у вас в командах для коммуникации кроме эмаила?

15:54
@jsunderhood google hangouts, slack, appear.in, github PRs/issues
16:35
@jsunderhood @fuckingsun Slack, еще в прошлой команде Hipchat юзали, но он грустненький
16:35
@jsunderhood skype, telegram
16:35
@jsunderhood @fuckingsun скайп, слэк, вк
16:35

А какие являются основные критерии или функции по которым вы выбирали чат?

16:36
@jsunderhood хипчат + телеграм
16:47
@jsunderhood разграничение, доступность клиента, управление файлами прозрачное, простая разметка
16:48
@jsunderhood пиздюли, давление авторитетом, запугивание и угрозы, вера в то, что босс умней
16:49
@jsunderhood Skype, Lync (Skype for business), Outlook Express, короче полный ад.
17:18
@jsunderhood slack, disqus
17:52
@a_novok @jsunderhood любые устройства, в том числе и просто веб-версия есть, можно создавать чаты, упоминать людей, защищенность тоже норм
18:52
@jsunderhood @a_novok телеграм в основном
18:52
@jsunderhood только телеграм
18:53
@jsunderhood скайп, много скайпа, все на расстоянии одного клика
18:53
@jsunderhood, телеграм.
19:33
@jsunderhood чем угодно, кроме email, я бы сказал - всем, кроме него)
19:33
@jsunderhood перенесли все чатики в Telegram
19:33

я работаю на chatgrape.com , фокус на безопасность, интеграцию сервисов, встроенный поиск по сервисам, попробуйте ...

19:39

и так моя неделя подошла к концу, с вами был @oleg008, желаю всем поменьше говнокода)

20:44

github.com

other