ну мне нужна типизация

Kotlinjs > TypeScript > ES6 > Flow

там даже в react-create-app недвано смержили тайпскрипт

новое писать )

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

Kotlinjs > TypeScript > ES6 > Flow

в твоей иерархии выходит что флоу (ES6 + типы) хуже чем ES6?

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

а тайпскрипт простой=тупой как пробка

для меня флоу это что-то типа хака, оно есть, но его никто не юзает

поэтому и на проект бы не стал тащить

для меня флоу это что-то типа хака, оно есть, но его никто не юзает

один из бывших меинтейнеров тайпскрипта сейчас хак пишет в фейсбуке)

и флоу юзают поактивнее хака все-таки

один из бывших меинтейнеров тайпскрипта сейчас хак пишет в фейсбуке)

ну хак активно развивают, а в свете последних событий у него появился шанс

Никита Попов ушел из универа

и интеерсуется в сторону Rust

ну а что с движухой Zend думаю уже все в курсе

ну раст очень интересен но работы на нем 0

ну hhvm та же симфони поддерживали, потом дропнули, сейчас хз. А флоу/тс особо не требует поддержки от меинтейнеров каких-то там либ, тем не менее у кучи либ при себе еще и типы имеются и поддерживаются

и время на раст мне уже год не хватает найти

флоу оч круто, только порог входа приличный, кмк

ну и тулзы ваще не помогают(

у флоу беда с тулингом, как я вижу

у ts лучше, хотя тоже иногда косячит

так в итоге что юзать где меньше гемора ?)

и больше возможностей

мне нужна типизация и чтобы ide понимала это и помогала

флоу - круче типы, тс - проще стартовать

флоу вообще вебшторм поддерживает?

мне кажется, флоу проще интегрировать в существующий проект

да ну, какой вебшторм, он и тс особо не вывозит

и время на раст мне уже год не хватает найти

а зачем он тебе? о_О

чисто интересен язык )

ну так если интересен, то всегда время найдется

можно включать работу через тссервер или flow-lang-server, но зачем тогда шторм)

только вим только emacs ?))

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

имхо хороший путь)

но это уже оффтоп)

да ну, какой вебшторм, он и тс особо не вывозит

тогда точно надо пробовать котлин?

только вим только emacs ?))

atom, vscode, nuclide, neovim, emacs

для neovim есть всякие обертки аля onivim

тогда точно надо пробовать котлин?

самое приятное в языке - быть гвоздями прибитым к инструментам, ага)

для neovim есть всякие обертки аля onivim

хм, интересная штука, надо пощупать

самое приятное в языке - быть гвоздями прибитым к инструментам, ага)

если б у инструмента еще были альтернативы

если б у инструмента еще были альтернативы

они есть обычно, просто их игнорируют

ну и тулзы ваще не помогают(

Блокноты, не тулзы

писать в блокнотах в 2018м году

Блокноты, не тулзы

ну я про сырость того же flow-language-server (

Для того, чтобы увидеть разницу достаточно открыть cli обоих инструментов и сравнить разницу

У флоу уже десятки команд,с описаниями: кодген, coverage, средства для рефакторинга, управление сервером, короче вплоть до рендера .dot графа зависимостей модуля. Тс из консоли компилирует, всё;

был бы какой-то получше)

ребят, если у меня контроллер преобразует входные данные после миддлвари в DTO, отдает их сервису, тот что-то делает и отдает в обратку тоже dto - кто должен преобразовывать DTO для уровня представления (в какой-нибудь ViewObject или я хз)? Ну то есть, я вижу это так Middleware converts raw transport agnostic query to Query Object -> Controller recieves it -> Controller converts Query to DTO for Service call and waits -> Service returns DTO with updated data (if it should be) -> Controller doing... what???

ребят, если у меня контроллер преобразует входные данные после миддлвари в DTO, отдает их сервису, тот что-то делает и отдает в обратку тоже dto - кто должен преобразовывать DTO для уровня представления (в какой-нибудь ViewObject или я хз)? Ну то есть, я вижу это так Middleware converts raw transport agnostic query to Query Object -> Controller recieves it -> Controller converts Query to DTO for Service call and waits -> Service returns DTO with updated data (if it should be) -> Controller doing... what???

я сталкивался с подходом, где это делала та же мидлварь (дата трансформер)

кто короч должен заниматься преобразованием DTO для специфичного транспорта? (ЗЫ.: я пишу на Nest.JS, тут есть преобразующие перехватчики, типа как миддлвара только уже с респонзом)

ну вот да, типа того как сказали выше, НО. получается что на входной контракт контроллер работает с QueryObject'ом, а на выход дает DTO - я так слои вместе мешаю, поэтому у меня когнитивный диссонанс и возникает

причем я даже прекрасно понимаю что у DTO должны быть типа там всякие toString, toJON, toHTTP, - что угодно еще, но это картины не меняет

если я правильно понял, то на вход миддлваре летит DTOшка какая-то?

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

если я правильно понял, то на вход миддлваре летит DTOшка какая-то?

не не не

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

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

кмк, контроллер должен вернуть ResponseObject, отдать его мидлваре, а та уже скормить что-то транспорту

ну вот я тоже к той мысли склоняюсь, но надо остальных коллег услышать. Главное что мне после всего этого непонятно - кто тут Presentation Layer

ну вот я тоже к той мысли склоняюсь, но надо остальных коллег услышать. Главное что мне после всего этого непонятно - кто тут Presentation Layer

мне кажется это сильно зависит от точки зрения: под разным углом один и тот же узел может быть и бэкэндом и фронтэндом

тут вопрос скорее в том что для чего угодно что угодно может считаться этим слоем. я ж не конкретно про раздление бэк/фронт, так-то и для слоя служб ДТО = презентация. ну притянуто конечно, но все же

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

при условии, что всё так, как я описал выше