Архив недели @raxpost
Понедельник
Утречко! На этой неделе с вами @raxpost - человек фулстек из Франкфурта
Будем много говорить о типах, ноде и фулстеке. Думали не будет реакта? Хренушки, от него никуда не деться
Давайте начнем с небольшого опроса, а чуть позже я расскажу что сам думаю по теме. Нужны ли в js типы?
🤔
56.8% Да🤔
43.2% Нет@jsunderhood я не могу определиться. С одной стороны типизация добро-меньше ошибок. С другой стороны-уже поздно :)
Есть опциональная, будем считать, что она относится к ответу Да twitter.com/dcromster/stat…
Думаю все поняли, но на всякий случай суть сабжа: js типы очень слабые, но есть возможность вводить типизацию посредствам доп инструментов
Вот лишь некоторые из них: TypeScript, Flow, Elm, PureScript, Dart
Самому мне очень симпатичен Haskell, но еще не доводилось его использовать на продакшене. В вебе он непопулярен
И во многом именно благодаря сильнейшей типизации. Когда хаскелист пишет программу, ему нужны 100% гарантии бизнес требований
В реальном же мире, пока вы допишете ваши базые типы, к вам 10 раз прибежит проджект и скажет, давай по новой, миша, все ху%$я
Поэтому типизация несет оверхед на этапе прототипа, а бизнес от веба ждет всего очень быстро
При это она сильно помогает при рефакторинге, все ошибки отлавливаются почти сразу
Более того, вы экономите на тестах, потому что чем строже типизация, тем ближе вы приближаетесь к описанию всех возможных кейсов уже в коде
Я к сожалению совсем не знаком с Elm и PureScript, если кому-то есть что сказать про них в плане нашего топика, пишите
Однако на хайпе, столь для нас родном, сейчас TypeScript и Flow. По этому поводу второй опрос
🤔
58.2% TypeScript🤔
41.8% Flow@dcromster @jsunderhood Про меньше ошибок — абсолютный миф. Не влияет. А вот удобочитаемость, по-моему, страдает. medium.com/javascript-sce…
Эта статья всех бомбанула пару месяцев назад. Не сказал бы что она что-то доказывает, но - попытка разобраться twitter.com/ruGreLI/status…
Соглашусь, с TS вы получаете все новые ES фичи бонусом. Тогда как в 6 бабеле в это время выпиливают декораторы twitter.com/twenty/status/…
Не был бы так категоричен, например буквально недавно TS добавил descriminated unions, которые уже были в Flow twitter.com/twenty/status/…
А есть кто за Flow? Давайте сравним, что там есть, чего нету в TS. А пока посмотрим маленькую презу djcordhose.github.io/flow-vs-typesc…
Например @vkurchatkin собирает коллецию сниппетов, где Flow ведет себя лучше чем TS github.com/vkurchatkin/ty…
И у меня есть вопросы к обоим сторонам: например есть ли во Flow параметрические типы данных?
И как с помощью TS проверять типы, описанные в JSDoc. Говорят так можно
Напомню, что JSDoc имеет тэг usejsdoc.org/tags-typedef.h… который поддерживает композитные типы и юнионы
Why do I prefer jsdoc3 instead of TypeScript/Flow? Types is meta information, like Contract in DbC. We should separate it from program code.
И например @DenisIzmaylov считает, что это лучше, чем типы в коде twitter.com/DenisIzmaylov/…
Вторник
@jsunderhood github.com/Microsoft/Type…
Да, но почему-то он не проверяет типизацию. Съедает
/**
@type {number}
*/
var var1;
console.log(var1.length); twitter.com/chicoxyzzy/sta…
@jsunderhood а расскажешь про typelint?
Сейчас как раз плавно к этому перейдем :) twitter.com/myjsalterego/s…
Продолжим о типизации. По моему опыту большинство проблем возникают при обращении к несуществующему свойству объекта. Пресловутый undefined
Потому что сложно держать в голове все структуры и интерфейсы приложения. Где-то вы обязательно промахнетесь
Поэтому я например вижу мало смысла использовать транспайлеры лишь в сборке. Разработчик должен видеть ошибку, пока он в контексте
Поэтому меня огорчило, что у WebStorm'a до сих пор нет полноценной поддержки Flow. C TS у них все отлично
Так вот, если большинство проблем в объектах, давайте посмотрим откуда они приходят: модели из API, локальный стейт приложения
Если вы пишете апи и не используете что-то типо Swagger, API Blueprint итд, то для вас уготован отдельный котелок в аду
Возьмем локальный стейт и самое популярное решение - Redux. У него есть структура, описанная редюсерами и initialState'ами
Возьмем пока чуть менее популярное решение - Relay, у него вообще типизированные схемы данных для GQL
Как мы видим в хороших приложениях большие данные всегда описаны, а в очень хороших еще и типизированы. Почему бы не использовать это?
Так родилась идея github.com/yarax/typelint -- сделать линтер, который знает о данных приложения и помогает писать код безопасно
Пока он поддерживает только JSON Schema как формат описание данных (используется в Swagger), но я планирую добавить поддержку Redux и GQL
Кстати JSON Schema по-моему недооцена. Эот хорошо описанный универсальный формат для JSON. Почему все постоянно изобретают что-то свое?
JSON Schema поддерживает algebraic data types за счет енумов, allOf и anyOf. И если не нужна хитрая динамика, этого зачастую достаточно
Например уж mongoose и thinky точно могли бы его использовать. Было бы универсальнее + толчок к развитию единого стандарта
Говоря об API, в Haskell есть фреймворк Servant, который описывает все ваше апи в типах. АПИ в ТИПАХ Карл. Вот это высота
Но зато такое апи нельзя будет использовать в typelint :)
Ладно, больше не буду про хаскель, а то все разбегутся
@jsunderhood @twenty синтаксис ещё не утверждён — правильно делают, что выпиливают. Всегда можно плагин поставить, если очень нужно.
Полгода собачку утверждают? А в это время полвеба юзает декораторы в TS, вторая половина через легаси бабель плагин twitter.com/ilnurkhalilov/…
@vkurchatkin @jsunderhood Спрос на эту фичу есть, значит рано или поздно примут. Только вот поведение может отличаться от нынешнего
Именно. Только смысл было ее убирать полностью, если все равно продолжают пользовать с таким функционалом какой есть twitter.com/boriscoder/sta…
Завершая тему типов, кто еще не знает есть телеграм чатик по TS telegram.me/typescriptru Может кто-то знает/создаст по Flow?
И небольшая шпаргалка по типам в TS, Flow, JSON Schema и Haskell, круто если кому-то есть что исправить/дообавить github.com/yarax/typescri…
Давайте начнем с небольшого опроса, а чуть позже я расскажу что сам думаю по теме. Нужны ли в js типы?
Голосование нужна ли в js типизация: 57% Да, 43% Нет. Подтверждает ощущение, что "хорошо бы, но дорого" twitter.com/jsunderhood/st…
Выход - опциональная и без дополнительного писания типов, юзайте typelint :D
Голосование TS/Flow: TS: 58%, Flow: 42%
@jsunderhood было бы неплохо, но вроде бы в русскоязычном мире Flow мало используют
По ходу да, кроме тебя про Flow все молчат) twitter.com/vkurchatkin/st…
Среда
@jsunderhood Многи ли в js архитектурных подходов\решений для приложений? Как происходит выбор для нового проекта? Где подобное почитать?
MVC умирает вместе с ОО подходом, компоненты могут решить почти любую задачу и дают больше гибкости twitter.com/ivkinovich/sta…
В продолжении вчерашней темы про API, немного о REST. REST - говно
Но от него никуда не деться, потому что он по сути есть HTTP. А HTTP это наше все. И низкий уровень REST'a увеличивает прозрачность
Но чаще всего, если решение прозрачное, оно не богато возможностями.
Ограничения REST думаю всем известны: недостаточность ресурсной модели, ограниченность GET запросов, неуклюжий PUT
А если вы захотите поменять транспорт например на сокеты, то вообще будете переписывать слой работы с данными
На этом фоне даже JSON-RPC выглядит более привлекательным. Но если вы на реакте, то для вас открыт целый преферанс-бордель: Relay
Если безусловно талантливая команда фб что-то придумает с неудобными мутациями, конкурентов в асинхронном хендлинге данных у Relay не будет
@jsunderhood Relay/GraphQL не всем подходит, он сложный, имхо
Кстати да, почему он считается сложным? twitter.com/roman01la/stat…
В OOP-MVC переиспользование - наследование, компонентная структура ближе к FP, когда чистая ф-я может юзаться везде twitter.com/vladimore/stat…
Сама природа UI - компоненты, мне кажется это естественно
@roman01la @jsunderhood самый простой путь – сделать прослойку для агрегации REST-запросов.
Вот я сейчас точно так же буду пытаться мигрировать систему на GQL. REST при этом должен остаться twitter.com/maxmaxmaxmax/s…
@jsunderhood наследование - механизм subtyping-а, ad-hoc полиморфизма.ООП-инкапсуляция и мессаджинг,то-есть компоненты в чистом виде
Совершенно верно,но так сложилось у всех в головах,что ООП-это наследование. Инкапсуляция и полиморфизм универсальны twitter.com/8gene/status/7…
@jsunderhood effectful компоненты /= чистые функции, и не композятся в общем случае.Кроме того, ф-ции слишком низкоуровневые
Мы говорим про переиспользование 2. В чем проблемa объединения в модули? twitter.com/8gene/status/7…
@jsunderhood чистое фп и всякие редуксы не решают проблем инкапсуляции стейта, то-есть не решают вообще ничего.MVС как раз и есть компоненты
Инкапсуляция стейта (если она действительно нужна) решается как и инкапсульция скоупа функций - локальным стейтом twitter.com/8gene/status/7…
@jsunderhood и еще: MVC /= OOP
В MVC без OOP не остается вообще никакой системы, кроме ненужного разделения логики от представления twitter.com/8gene/status/7…
@jsunderhood переиспользование стейтфул компонентов /= пересипользованию чистых ф-й. Модули не помогут инкапсулировать стейт.
Вопрос: зачем инкапсулировать стейт, который мешает переиспользованию? Ради инкапсулирования? twitter.com/8gene/status/7…
@jsunderhood попробуй сделать такое в языке з правильной системой типов и типизированными effect-ами - сильно удивишься)
В strong type FP данные пайпом проходят через ф-ии. В реакте это усложняется необходимостью дублировать пропсы twitter.com/8gene/status/7…
Есть контекст, но он все еще не стабилен
@jsunderhood инкапсуляция - необходимое,но недостаточное условие переиспользования,и самой вожможности существования больших, сложных систем
Я с тобой согласен, что в реакте есть проблемы со стейтом. Но есть серебряная пуля? twitter.com/8gene/status/7…
@roman01la @jsunderhood jsonapi же.
Я с ним мало знаком, но по-моему он работает поверх реста, нет? twitter.com/blia/status/75…
@jsunderhood расскажи про проблему стейта плиз
То, что глобальный не дает инкапсуляции, а локальный мешает переиспользованию twitter.com/mr_mig_by/stat…
@jsunderhood а зачем инкапсуляция?
Например для связи компонентов со стейтом, она чаще всего прослеживается. Но как я говорил выше глобал - это решение twitter.com/mr_mig_by/stat…
@jsunderhood лучше почитать jsonapi.org/format/ Скажу, что там лучше работать с релейшенами, выводить одним запросом детей(с фильтрами)…
Формат это формат. Но в основе рест - все те же GET, PATCH twitter.com/blia/status/75…
@jsunderhood я ничо не понял. Как инкапсуляция связывает состояние с компонентом?
Вам с @8gene надо дебаты устроить :) Один говорит везде инкапсуляция, второй инкапсуляция не нужна twitter.com/mr_mig_by/stat…
Возвращаясь в API, кто-то пробовал Falcor?
В нашем случае GraphQL позволит разгрузить клиент от кэширования, асинхронных экшенов и более точно и гибко запрашивать данные
Но меня смущает существование 2 стейтов (Редукс и Релей) одновременно. Есть механизмы поддержания консистентности, но все равно стремно
@jsunderhood А какой у вас продукт?
Огромная админка управления рекламными компаниями. Много форм, поэтому без локального стейта не обойтись twitter.com/roman01la/stat…
@jsunderhood мы в редаксе держим только состояние UI: табы, комбобоксы и т.д.
Да, в идеале хотелось бы так же twitter.com/roman01la/stat…
@jsunderhood У нас много такого кода и мы не храним такие данные в редаксе. Обычно родительский компонент собирает эти данные и отправляет.
Да, я тоже считаю, что форма должна быть в стейте компонента, но у нас это легаси redux-form twitter.com/roman01la/stat…
@jsunderhood про ваше решение для форм. форм может быть много и интересно как вы описываете формы и шарите общий код между @roman01la
Когда-то мне нравилась идея построения форм на основе моделей, но в реальном мире это не работает twitter.com/myjsalterego/s…
Форма рисуется вручную и к полям биндится специльный пропс field, содержащий value, onChange итд. В hoc field связывается с redux
Возможно когда-нибудь @nosovsh выложит это в опен сорс :)
Кстати также мы юзаем довольно удобное решение для работы с редакс-стейтом github.com/nosovsh/reduce… тоже от @nosovsh меньше мороки с экшенами
@jsunderhood а можно подробностей про то как Редукс и Релей живут вместе?
Они в общем друг другу не мешают. Главное держать данные консистентными. У редакса стор через dispatch, relay - hoc twitter.com/dmzkrsk/status…
Кстати поигрался с github.com/gyzerok/adrena… и понял, что без Relay чистый GraphQL - сомнительное удовольствие
@jsunderhood у нас была одна итерация декларативно описывать формы на сервере, но отказались из-за необходимости свой язык поддерживать
Мне раньше нравилась эта идея, но в реальности UI должен быть очень гибким twitter.com/myjsalterego/s…
@jsunderhood @8gene я считаю, что состояние нужно выносить вовне. Это должна быть отдельная ось композиции компонента
Это интересная тема. Но как например обеспечить неизменение куска стейта другим компонентом? twitter.com/mr_mig_by/stat…
@jsunderhood @8gene к примеру, Symbol в качестве имени компонента в глобальном состоянии. Но вопрос - зачем обеспечивать неизменность?
Например пришел новый человек в команду, не разобрался и записал не в свой кусок стейта, все сломалось twitter.com/mr_mig_by/stat…
@mr_mig_by @jsunderhood композятся интерфейсы - поведения, view. Стейт не имеет интерфейса, он просто есть.А стейт с интерфейсом-это инкапс.
Да, но при этом я не вижу решения как разрулить strong coupled data между компонентами, кроме глобального twitter.com/8gene/status/7…
Пока что мне видится оптимальным - там где возможно использовать локальный стейт - юзать локальный, где нет - глобальный
@jsunderhood @mr_mig_by @8gene как предсказать, что эти данные не понадобятся кому-то ещё в будущем?
Никак, только рефакторить twitter.com/ALF_er/status/…
@jsunderhood @mr_mig_by @8gene и по этому мне больше нравится идея Лёхи: данные - отдельная ось
Но если не рефакторить, стейт превращается в огромную помойку twitter.com/ALF_er/status/…
@jsunderhood @nosovsh connectSlicedState('pages.blogs.data.activePost') - это не очень хорошее решение. компоненты привязаны к форме стейта.
А вот это второй вопрос что есть связь компонента и глобального стейта? Соответствующий ключик редюсера? twitter.com/smashercosmo/s…
@jsunderhood я оч устал рефакторить, поэтому сторы редакса у меня это "база данных". локальный стейт — для UI штук (eg dropdownIsVisible).
Еще кстати из базы данных нужно гибко выбирать и кэшировать новые данные. Поэтому мне нравится подход Relay twitter.com/alexfedoseev/s…
Кстати пока у нас тут жарко, прогоню телегу. Нам во Франкфурт нужен реакт удаленщик. Пишите кому интересно в лс @raxpost
Четверг
Буквально пару лет назад мне было интереснее на сервере. Сейчас все наоборот
В бекенде все кристализовалось: devops, data analysis, API. Конечно все еще есть интересные задачи (gamedev например), но их все меньше
При этом есть вероятность, что API скоро кристализуется в BAAS, потому что это рутина
А на клиенте вот можно вместо работы спорить нужно ли разделять view и где должен быть стейт,параллельно играясь всякими rx и прочими сагами
И пока на клиенте весело и задорно с реактом, на сервере царит мракобесие во главе с Express
Несколько месяцев назад я написал статью почему экспрес зло yarax.ru/2016/02/26/exp…
Туда пришел TJ и сказал, чувак, мопед не мой, дизайн node/http - говно
И это отчасти правда, но node/http это низкий уровень. Задача прикладных библиотекарей - делать правильные абстракции
Поэтому нет смысла спорить что лучше koa или hapi, пока все они наследуют дизайн node/http лишь обрастая сахаром
Не может же быть такого, наверняка кто-то уже написал либу с правильным разделением http имплементации от логики ручек?
Это же делается элементарно, я даже накидал небольшой гист gist.github.com/yarax/e68c7623…
Объясню чуть подробнее. Довольно очевидно, что апи должно описываться декларативно.
То есть у либы есть вся информация в каком формате данные приходят из http и в каком должны туда уходить. http - это контекст
Очень хочется сказать слово монада, но обещал этого не делать
Так почему этот мутирующий непредсказуемый req носится по всему приложению, собирая в себе все что не попадя?
Если задача ручки - сделать запрос в базу, обработать данные и вернуть их, зачем ей этот req?
Ладно, не пошло, давайте лучше посмотрим как енот ездит на велосипеде
@jsunderhood это Backend as a Service? Почему тогда рутина?
В том смысле, что все сводится к декларативному описанию апи, а дальше банальные запросы к базе twitter.com/Copypasting/st…
А имея какой-ть full text search engine и GQL на фронте, можно делать вот такие штуки почти вообще без бекенда github.com/nordsimon/elas…
Пятница
@jsunderhood абстракции текут (с)
Текут конечные монструозные низкоуровневые решения. Не просто текут, а находятся постоянно на грани фола twitter.com/evgeniy_moroz/…
Говоря об абстракциях, @nikitonsky недавно написал довольно очевидную (почему-то еще не для всех) статью про это tonsky.livejournal.com/307231.html
Ну да бог с ней с философией, нравится людям express, пусть старадают :) Давайте поговорим о реактивном программировании
Я использую
🤔
9.9% Rx🤔
2.7% Bacon или Kefir🤔
8.1% Другую библиотеку🤔
79.3% Не использую FRP@jsunderhood если быть точным, то Rx, Bacon, Kefir не есть FRP :-)
Расскажи подробнее twitter.com/8gene/status/7…
@jsunderhood rx etc-это императивные effectful реактивные не-формальные системы.
А ну я понял что ты имеешь, меня тоже смущает, что почему-то все добавляют в аббревиатуру букву F twitter.com/8gene/status/7…
Говоря о событиях, например нам нужен момент, когда на серв все асинх сервисы готовы. Это можно сделать например так gist.github.com/yarax/3dac9ae1…
Neat redux-observable example with RxJS 5: github.com/redux-observab… pic.twitter.com/19gj1Z9lOR
А вот пример использоваться Rx в Redux. Как вам такой подход? twitter.com/dan_abramov/st…
Люди, указавшие в опросе вариант "другая" напишите плз какая именно и почему
Тем временем нам поступает интересный фидбек от слушателей
@8gene @nikitonsky @jsunderhood на уровне котика квантовых полей нет - они схлопываются ещё до зачатия котика.
От экспресса до котика в квантовых полях twitter.com/taujavarob/sta…
Мое мнение, что использовать стримы там, где можно промизы, избыточно и непрозрачно. Но возможно я не прав, раскажите, про ваши юзкейсы
@jsunderhood @raxpost На промисах всегда нужно ждать их окончания, со стримами же можно начинать отправлять ответ клиенту почти сразу же.
Окончание промиза означает что данные fulfilled и с ними можно работать. Можешь код привести? twitter.com/canvaskisa/sta…
@jsunderhood 1) если надо (будет) результаты резолва промисов комбинировать, 2) если везде стримы и есть два промиса в коде
Да, в этом случае оправдано twitter.com/NikitaDyumin/s…
@jsunderhood свою пилю :D npmjs.com/package/rstore
Круто! twitter.com/NikitaDyumin/s…
Еще немного о типах. Недавно пришлось работать с кодом, который делает всякую арифметику с бюджетами.
Значения приходят извне и могут быть чем угодно. Что мы имеем: undefined, null, NaN, String, Number и никакой определенности
Тайпчекеры (например Maybe во Flow) не позволят вам cложить number с undefined
Это лучше чем ничего, но недостаточно, т.к код обрастет страшными ифами и станет нечитабельным
Очень хочется изобрести свой тип Maybe, но такие попытки выглядят немного смешными github.com/chrissrogers/m… по сути они ничего не решают
Как вариант - сделать вид, что Maybe у нас есть и написать арифм ф-ии работы с ним: gist.github.com/yarax/841ea9df…
В итоге null рассматривается как у Flow - тип Nothing и с этим уже можно работать
Строгая типизация не избавляет от разруливания union типов, просто не будет NaN и undefined twitter.com/shevasya/statu…
Почти 100 человек проголосовало и из них целых 83% вообще не используют FRP. Отсюда у меня следующий вопрос
🤔
81.5% Не знаю/Не вникал🤔
18.5% Считаю ненужным@jsunderhood кстати, о нашем милом и добром реакте: twitter.com/forwebdev/stat…
Cons какие-то мутноватые twitter.com/taujavarob/sta…
@vladimore @jsunderhood иногда в JS что-то не прокатывает. Например в JS4 не прокатило полноценное ООП. И это на пике популярности ООП. 👻
Да, было время все пытались притягивать за уши js к ООП twitter.com/taujavarob/sta…
Суббота
Норм визуализашка по Rx методам rxmarbles.com
Давайте чуть-чуть про фулстек.
🤔
28.5% Я кайфую от UI🤔
26.7% Я - фронт, так получилось🤔
25.3% Был на беке, нра фронт🤔
19.5% Был на фронте, нра бек@jsunderhood @raxpost есть распространенное мнение что человек-фулстек это как "не вашим и не нашим". Что думаешь про это?
Есть такое, частенько это ощущаю. Всегда тебя будут считать квалификацией ниже, чем профильные twitter.com/as_Crazy/statu…
Но я с собой ничего не могу поделать, есть Computer Science и мне интересно все, что с этим связано
Еще для понимания всей системы в целом и принятия правильных решений полезно знать как работает каждая часть
Времени конечно на все не хватает не будет хватать, но хорошо знать самые важные элементы нужно
Поэтому я запланировал себе на этот год получить сертификат lpi.org
Расскажите про ваш опыт и ощущения фулстека
К тому же все меняется каждую неделю только на фронте, информатика с математикой не меняются
@jsunderhood отличный опыт, отличные ощущения. Но печаль, потому что работать приходится с людьми, у которых такой суперсилы нет
Это да, но оно в твоей голове, я писал про мнение окружающих. Тут как обычно, каждый считает себя самым умным twitter.com/mr_mig_by/stat…
Бек мне не нравится тем, что все самое интересное там происходит на нагрузках. А настоящие нагрузки редко где есть
Получается такой кружок избранных, если ты получил там опыт, тебе открыта дорога дальше по соотв технологии
@jsunderhood Без понимания бэка фронту жить будет очень тяжко. Это отсутствие возможности общаться на одном языке.
Если нет базового понимания, то все совсем плохо twitter.com/webholt/status…
А быть одновременно на беке в нагрузках/биг дате и на фронте - нереально, тут хочешь не хочешь надо выбирать
А уметь написать апи + базовое знание основных БД, не весть какой скил
@jsunderhood Расставлять приоритеты. Можно в одно погружаться по полной, а в остальное — по остаточному принципу, по чуть-чуть.
Вот в бек с нагрузками к сожалению нельзя погрузится частично. И даже дома пет проджект будет бесполезен twitter.com/webholt/status…
По поводу ноды, да очень удобно не переключать синтаксис языков.
Забавно, раньше все думали что смогут переиспользовать код клиент-сервер. Оказалось это не нужно. Но сработало в плане npm
Хейтеры обычно говорят что на беке есть языки лучше. Типо вот в питоне тоже появился евентлуп
И что js ужасен. Но, если вы страдаете от типизации - берите typescript. От колбеков - async/await
Единственное что нельзя поменять - дебильные методы, половина которых мутирует обьект, половина - нет
@jsunderhood В питоне зато все методы мутируют.
Ну хоть какая-то определенность twitter.com/freiksenet_ru/…
@jsunderhood JS решает проблемы без понтов, макро и штанги. Никто не ценит идейность JS, поэтому его просто развивать.
Да, идейность это ограничения. Поэтому безыдейный js получился таким гибким twitter.com/freiksenet_ru/…
@jsunderhood И я не говорю что питон или хаскель плохие (хотя питон конечно плохой), просто объясняю почему мнение "js говно" это отлично.
Проблема в том, что можно добавлять новый функционал, но нельзя выпиливать старое говно из-за бекворд компатибилити twitter.com/freiksenet_ru/…
@freiksenet_ru @jsunderhood поэтому чистый питон стоит дешевле чем фулстек? )
Вакансий кстати именно на фулстек мало почему-то по моим наблюдениям twitter.com/antonplankton/…
@jsunderhood делаю фронт, бек, архитектуру, big data, machine learning, semantic web и R&D - по-моему, это лучшая работа в мире :3
Воскресенье
@webholt ты опять взял интерпретируемый язык. сравни с чем-то побыстрее) @jsunderhood
А это тоже вопрос. Все помешались на Go, потому что он быстрый. А зачем им скорость еще не придумали twitter.com/indieloki/stat…
Сишники при этом как сидели, так и сидят, их все устраивает. Нет, вот теперь каждый пхпшник считает своим долгом написать на Go
На моей памяти, узким местом всегда были базы данных и никогда - сам язык. Для этого нужны нагрузки уровня fb/badoo/vk
@jsunderhood Ну, хз. Когда та же запросы к базе занимают 90% бюджета быстродействия, наверное, нужно, чтобы всё работало быстро.
Это как так, открыть сокет и начать слушать данные это 90% бюджета? twitter.com/ruGreLI/status…
Если запросов очень много, то это либо кривость архитектуры, либо половина из них не нужна клиенту. И тут нода хороша евент лупом
Поскольку у нас получилась неделя абстракций, давайте посмотрим выступление на эту тему Cheng Lou на React Europe youtu.be/mVVNJKv9esE
@jsunderhood вполне себе нужно, с изоморфными приложениями
Кстати интересная тема. Давайте посмотрим кейсы изоморфа: сервер рендер, валидация. Что-то еще? twitter.com/operatino/stat…
У нас мы используем одну валидацию на клиенте и сервере, основанную на свегер схеме. Пока полет нормальный
@jsunderhood @operatino переиспользование логики
А вот это как раз то о чем я писал,как мне кажется это не взлетело. Потому что общих кейсов не так много. Как у вас? twitter.com/roman01la/stat…
Расскажите кто использует React сервер рендер, чем это вам помогает?
Еще один базворд не затронули - микросервисы
Сама по себе модульность - вещь хорошая и работающая, но как любое хорошее дело ее легко запороть
Вам нужны микросервисы, если: нужна распределенность, знаете как разделить бд, знаете как настроить кластер и CI
Конечно докер. Но контейнеризация-вещь молодая, мало утилит, они сырые, бест практикс нет. Мы потратили несколько месяцев только на кластер
Что касается разработки: все выносить в либы (npm через git), никогда не лезть в зону другого мс, заложиться на разные транспорты
В общем никто не мешает использовать разные языки в контейнерах, если есть кому эти языки потом поддерживать
В целом эти советы полезнее, чем вся эта книжка
Ну и традиционная рубрика других посмотри, себя покажи. Кидайте ссылки на ваши личные проекты
Вот и время прощаться. Кстати через час финал ЧЕ. Как вы к футболу?
🤔
31.2% Мне он скучен🤔
34.8% Изредка смотрю🤔
16.2% Люблю, слежу🤔
17.8% Футбол для тупых. Я умныйСпасибо всем, кто участвовал в дискуссиях, это была классная неделя. Пишите фидбек по github.com/yarax/typelint, мне он очень важен :)
