Чтобы оценить глупость этой статьи предлагаю небольшое ментальное упражнение: представьте, что у вас уже есть код на тайпскрипте и подумайте, что вам даст переход на яваскрипт. Вкратце, он даст:
Ухудшение DX: авторефакторинг будет периодически ломать код, автокомлит будет выдавать кучу мусора, линтеры смогут делать лишь тривиальные чисто локальные проверки.
Вам придётся писать тонны JSDoc-ов, и внимательно следить на ревью, чтобы они соответствовали коду.
Вы сможете нанимать менее квалифицированных разработчиков, которые не осилили типизацию.
Вам придётся заменить ts-компилятор который просто работает, на babel с плагинами и париться с его настройкой. Зато у вас появится возможность сделать свой уникальный диалект яваскрипта, работающий только с заданной комбинацией плагинов.
У вас появляется куча новых способов выстрелить себе в ногу. Человек, как известно, очень хорош в статическом анализе конструкций вида "соединим строку от пользователя со строкой из объекта и возьмём значение поля класса с этим именем". Множество XSS и SQL-Injection не позволяют в этом сомневаться.
Вам нужно учить разработчиков жить на минном поле. Приучать к "защитному программированию". Ведь в любой момент в качестве аргумента вам может прийти всё, что угодно. И вы не можете эту неопределённость локализовать в изолированной функции, сделав в ней рантайм проверку с тайпкастом.
Вы сможете вырезать все типы. Точнее не вырезать, а перенести в документацию. Плюс вам придётся написать кучу бойлерплейта по проверке аргументов. А к нему и в 2 раза больше тестов для разнообразных вдруг появившихся новых негативных сценариев.
Итого: -4 в пользу JS.
А, да, ещё от декораторов отказаться придётся пока что.
Сдается мне, что автор начал за здравие, а закончил за упокой. Зачем это сопоставление REST с CRUD? Причем здесь проблема N+1? Сервисы — это фасад, и должны им оставаться. Обслуживающий персонал. Ну надо клиенту получить много связанных данных — ну выстави ты ему агрегирующий ресурс, зачем повторять структуру домена или структуру таблиц в БД? С таким успехом сервисы на основе чего угодно можно сделать эдакой вещью в себе.
КО утверждает:
1) Простые вещи должны делаться просто. И их проще несколько раз переделывать целиком, чем обеспечить стабильность-совместимость-и-непротиворечивость-на-века-аминь.
2) Типовых задач — больше 80%. А значит, простые решения будут востребованы всегда. Любая «расширяемая» парадигма, должна уметь деградировать до «hello world», чтобы получить шанс попасть на этот праздник жизни.
3) И тем не менее, взгляд на то, как наилучшим образом решать типовые задачи, имеет каждый суслик в поле. Без этого прогресса не будет, хотя и неразберихи тоже полно.
4) Решение сложных задач — это всегда вызов. Иначе они не назывались бы сложными. Более того: сложная задача сегодняшнего дня может перейти в статус типовой завтра. При решении сложных задач приходится сталкиваться с границами возможностей всего: железа, софта, спецификаций. И иногда приходится изобретать своё, чтобы расширить границы возможного.
5) Автоматизация разработки и её человекоориентированность — это разные цели. Порой, диаметрально противоположные. Для машины удобнее xml, wsdl и прочие строгие вещи. Для человека — html, json (как html, только для ajax). И тут снобизм неуместен: интернет как явление мог бы не состояться, если бы не было простого html и браузеров, очень терпимых к ошибкам в нём. В простых задачах сначала идёт человекоориентированность. И только по мере усложнения и развития приоритет автоматизации усиливается.
6) Интероперабельность, совместимость, интеграция — это задача в третьем измерении, которая решается с учётом первых двух. Если вообще возникает. В огромном числе простых задач — вопросы интероперабельности отсутствуют как класс. Хоть на коне танцуй!
REST недостаточно строг, чтобы его можно было легко и безболезненно использовать для решения сложных задач. Но он позволяет стартануть прямо из Блокнота, после 5 минут видеоурока. В этом его главная фишка.
С другой стороны, запрос на строгость и спецификации есть. А значит будут и спецификации и их достаточно широкая поддержка. Чтобы ещё какое-то подмножество сложных задач стало типовыми.
Чтобы оценить глупость этой статьи предлагаю небольшое ментальное упражнение: представьте, что у вас уже есть код на тайпскрипте и подумайте, что вам даст переход на яваскрипт. Вкратце, он даст:
Итого: -4 в пользу JS.
А, да, ещё от декораторов отказаться придётся пока что.
1) Простые вещи должны делаться просто. И их проще несколько раз переделывать целиком, чем обеспечить стабильность-совместимость-и-непротиворечивость-на-века-аминь.
2) Типовых задач — больше 80%. А значит, простые решения будут востребованы всегда. Любая «расширяемая» парадигма, должна уметь деградировать до «hello world», чтобы получить шанс попасть на этот праздник жизни.
3) И тем не менее, взгляд на то, как наилучшим образом решать типовые задачи, имеет каждый суслик в поле. Без этого прогресса не будет, хотя и неразберихи тоже полно.
4) Решение сложных задач — это всегда вызов. Иначе они не назывались бы сложными. Более того: сложная задача сегодняшнего дня может перейти в статус типовой завтра. При решении сложных задач приходится сталкиваться с границами возможностей всего: железа, софта, спецификаций. И иногда приходится изобретать своё, чтобы расширить границы возможного.
5) Автоматизация разработки и её человекоориентированность — это разные цели. Порой, диаметрально противоположные. Для машины удобнее xml, wsdl и прочие строгие вещи. Для человека — html, json (как html, только для ajax). И тут снобизм неуместен: интернет как явление мог бы не состояться, если бы не было простого html и браузеров, очень терпимых к ошибкам в нём. В простых задачах сначала идёт человекоориентированность. И только по мере усложнения и развития приоритет автоматизации усиливается.
6) Интероперабельность, совместимость, интеграция — это задача в третьем измерении, которая решается с учётом первых двух. Если вообще возникает. В огромном числе простых задач — вопросы интероперабельности отсутствуют как класс. Хоть на коне танцуй!
REST недостаточно строг, чтобы его можно было легко и безболезненно использовать для решения сложных задач. Но он позволяет стартануть прямо из Блокнота, после 5 минут видеоурока. В этом его главная фишка.
С другой стороны, запрос на строгость и спецификации есть. А значит будут и спецификации и их достаточно широкая поддержка. Чтобы ещё какое-то подмножество сложных задач стало типовыми.