https://www.npmjs.com/package/babel-plugin-transform-react-stateless-component-name

Например для строгой типизации тех же css modules

https://www.npmjs.com/package/babel-plugin-css-modules-transform вот например

Мне проще плагин на вебпаке написать

мы так и делаем

Мне проще плагин на вебпаке написать

для серверсайд рендера юзать вебпак?

Почему нет?

target=node

Почему нет?

потому что это как-то совсем фу

Абрамов сказал?

потому что это как-то совсем фу

Ну религия короче, да

Или ещё какой-то opinion leader?

Ну религия короче, да

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

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

Тебе для ноды в любом случае гонять babel придётся

Ты это тупостью не считаешь?

Тебе для ноды в любом случае гонять babel придётся

по крайней мере это не превратится в огромный бандл

Ты это тупостью не считаешь?

со временем, от большинства плагинов бабеля можно спокойно отказаться

по крайней мере это не превратится в огромный бандл

Всегда можно настроить вебпак для исключения node_modules напрмиер

Но не поддерживать 2 конфигурации: для ssr и фронта

со временем, от большинства плагинов бабеля можно спокойно отказаться

orly? Когда flow там в ноду пропихнут?

https://www.npmjs.com/package/babel-plugin-css-modules-transform вот например

И от этого тоже откажемся?

orly? Когда flow там в ноду пропихнут?

БОЛЬШИНСТВО != ВСЕ

БОЛЬШИНСТВО != ВСЕ

То есть бабель в любом случае останется, так?

и

останестся 3 плагина, вместо 50 а учитывая что ES будет постоянно развиваться, то не 3 а может быть 5

и что? От шага сборки кодя для ноды никуда не денешься

и что? От шага сборки кодя для ноды никуда не денешься

не сборки, а транспайлинга

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

И мы приходим к вопросу - фу это или нет

Почему вебпак - более "фу" чем бабель?

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

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

Почему вебпак - более "фу" чем бабель?

изменение кода vs конкатенация

очень удобно читать require(238) на 5935 строке, наверное ))

=)

Ладно, тут соглашусь. Но не соглашусь с тем что flow + babel сильно лучше чем typescript + babel

Я вот как то typescript даже больше доверяю

очень удобно читать require(238) на 5935 строке, наверное ))

я слышал, придумали сорсмапы

Ладно, тут соглашусь. Но не соглашусь с тем что flow + babel сильно лучше чем typescript + babel

1 компилятор vs 2 компилятора

я слышал, придумали сорсмапы

слышал что они достаточно дерьмово работают в vim/cat?

1 компилятор vs 2 компилятора

flow + babel это те же 2 компилятора, сшитые воедино

чуть чуть проще в настройке

flow + babel это те же 2 компилятора, сшитые воедино

нет flow это анализатор можно юзать без бабеля (правда только на проверку)

Задачу выполняют они с typescript одинаковую

нет flow это анализатор можно юзать без бабеля (правда только на проверку)

tsc --noEmit на проверку)

tsc --noEmit на проверку)

+1

Задачу выполняют они с typescript одинаковую

ага есть два набора инструментов, которые выполняют одну и ту же задачу, давайте сравним: ts+babel: 2 компилятора, дольше в компиляции, больше конфигов, больше разномастного синтаксиса flow+babel: 1 компилятор, на один плагин больше, один конфиг, один синтаксис (в пределах бабеля)

Кстати а как там у flow с поддержкой ide?

Кстати а как там у flow с поддержкой ide?

vscode также как и ts

Кстати а как там у flow с поддержкой ide?

idea вроде старается

Сам flow даёт что-то в этом плане? Ну типа как typescript language service?

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

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

Угу, потому что фейсбук

vscode также как и ts

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

А кстати как там дела с репозиторием дефинишенов для flow?

Сам flow даёт что-то в этом плане? Ну типа как typescript language service?

Nuclide ?

Сам flow даёт что-то в этом плане? Ну типа как typescript language service?

Да, все примерно так же

А кстати как там дела с репозиторием дефинишенов для flow?

ну это уже совсем варварство ? сколько лет ts и сколько flow

Сам flow даёт что-то в этом плане? Ну типа как typescript language service?

flow ide недавно появился в CLI

также как сравнивать экосистему rust и anylang

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

в ts можно запретить юзать кастомный синтаксис?

Главная причина выбрать Flow - в нем лучше тайпчекинг и инференс

Главная причина выбрать Flow - в нем лучше тайпчекинг и инференс

Вот это уже более серьёзно.

Надеюсь что в ts завезут ручной variance

А также nominal type

в ts можно запретить юзать кастомный синтаксис?

Это какой например?

nominal - вряд ли

ERROR: S client not available

variance тоже вряд ли честно говоря

от него мало толку в ТС

Это какой например?

неймспейсы, энумы и прочее

неймспейсы, энумы и прочее

Нет нельзя, можно только декораторы отключить

Ну investigate это как бы ничего не значит

Нет нельзя, можно только декораторы отключить

ну вот и всё...

Но посмотрим

ну вот и всё...

Закрываем лавочку

а то

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

Ну кроме энумов

это как спор композиция vs наследование

Я кстати за композицию )

я тоже

но здесь в компании понимают так: если ts то значит херачим как можно больше ООП

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

тебе в clojurescript идти надо - там без типов и считай встроенная rambda

имхо, люди вон пишут без типов на жс столько лет и ничего, работает я думаю можно иногда any поставить, ничего страшного в этом нет тс нужен, но в меру, и если он в каких-то местах мешает пилить фичи для бизнеса, отнимает кучу времени в плане дрочки на типы и тд, то мб стоит просто поставить any где-то там и идти дальше, все хорошо в меру когда пилишь пакет/либу/фреймворк и потребители по сути это другие разработчики, тогда мб стоит пое***ся с типами, но когда пилишь какой-то визуальный инструмент для других людей, то им пофиг по сути что там внутри, а для себя всегда можно найти какие-то компромисы в плане типизации (где надо писать, а где нет) т.е. я вообще это не к тому, что надо ложить на все хер, я больше про то, что дофига перфекционизма это тоже плохо, особенно когда пилишь сугубо простые и прикладные вещи в clojurescript свое говно, в purescript – свое, везде свое говно, надо трахаться сорри, я все не читал, я вот не очень понимаю смысл в babel + ts? почему просто тс не оставить? вот эти плагины типа https://github.com/css-modules/css-modules-require-hook они ведь не очень нужны с вебпаком, все равно собираться придется и все равно даже если тупо для сср, то оч вероятно, что тулчейн нужен будет по-мощнее, чем просто бабель, почему бы сразу вебпаком все не делать (бтв для типизации цсс модулей есть tcm и плагин для вебпака)

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

Еее джава

ага есть два набора инструментов, которые выполняют одну и ту же задачу, давайте сравним: ts+babel: 2 компилятора, дольше в компиляции, больше конфигов, больше разномастного синтаксиса flow+babel: 1 компилятор, на один плагин больше, один конфиг, один синтаксис (в пределах бабеля)

Ващето у флоу отдельный конфиг

ага есть два набора инструментов, которые выполняют одну и ту же задачу, давайте сравним: ts+babel: 2 компилятора, дольше в компиляции, больше конфигов, больше разномастного синтаксиса flow+babel: 1 компилятор, на один плагин больше, один конфиг, один синтаксис (в пределах бабеля)

К тому же TS не нужен бабель.

Не все так считают

Я без бабеля живу

согласен

+1 к TS без babel :)

А зачем он там особо нужен?

Я обхожусь без

Если только под функции-генераторы

Они вроде не особо в TS поддерживаются пока

А зачем он там особо нужен?

чтобы не писать import * as React from ‘react’;

Если только под функции-генераторы

Вот с этого всё и начинается, ага

чтобы не писать import * as React from ‘react’;

Баловство ещё один транспайлер юзать только из-за этого :D