Типизация и вообще структурирование кода (пускай это ООП или еще что-то) делает язык более сложным с точки зрения продумывания структуры того что ты пишешь. Очевидно типизация делает код более поддерживаемым тка же как и ООП, и это более инженерный подход чем слабать что-то на коленке, залить на продакшен, потом свалить из компании в другую и там снова фанбоить.
А JS позиционировался всегда, как язык для всех, даже для сайта из одной странички 5кб, написанной за вечер.
Не всегда, последние года 4 это уже не так. Задачи которые сейчас решает JS уже далеко не те которые он решал 5-10 лет назад. Серверная часто теперь как правило stateless (да теперь бекенерам проще стало чем было ранее, а в JS гораздо сложнее), состояние держится на клиенте. JS кода стало очень много, и когда кода много важну роль занимает его поддержка и развитие и здесь типизацию сложно недооценить.
А нужны ли вообще крупные приложения в браузере?
Речь идет не только о бразуераз, JS заполонил все направления, есть ведь любители писать много серверной бизнес логики на Node.js без какой либо типизации.
Типизация это уже далкео не сахар а реально нужная вещь. Поддерживаемость кода имеет большое значение, часто большее чем очень оптимальный по размеру сгенерированный код на выходе и SCSS в этом плане выходит вперед перед голым CSS.
Ок, да второй вроде как позиционировался простым, но на деле там много всяких сущностей и итоговая структура приложения получается я бы не сказал что простая.
Лучше напишите что-то против моих слов чем тупо минусы ставить. Ведь типов не видно в будующих стандартах и разве это не говорит о приоритетах авторов стандартов? Я понимаю они хотят оставить JS «простым», но вместе с этим реальных подвижек в стандарте нет (стрелочные функции, деструкторы и прочая мишура это просто сахар который не решает базовые проблемы JS).
Выше перечислены простые вещи, которые делаются один раз и это много времени не занимают. Гораздо более сложный вопрос с переходом может возникнуть если команда не готова работать с типами и ООП вообще (например елси в команде фанбои функциональщины, или просто не инженеры которые не привыкли писать поддерживаемый код).
Рано или поздно, все полезные функции TS будет так или иначе перенесены в стандарт языка и TS повесит бутсы на гвоздь.
Очень мало вероятно. TS сделан инженерами для инженеров, а ES хипстерами. Если бы ES делали инженеры то типы бы уже там появились, но они просто добавляют синтаксического сахара, это говорит об их приоритетах.
Это полумера, TypeScript больше чем просто типы. В любом случае на переход тратятся усилия, так лучше потратить их разумно чем хвататься за сомнительные поделки.
Статическая типизация — это не wish, это необходимость для любого крупного проекта, который не должен быть заброшен через месяц после релиза и у которого стоят высокие требования к качеству.
Вот я тоже удивляюсь как люди этого не могут понять, просто молятся на свое ФП. Видимо не сталкивались с большимим проектами и с тем когда разработчики в команде разного уровня. ФП (а также миксины и прочее функциональное месиво) хорошо в блоге показать, на ютюбе роликов сделать, но не для разработки больших и серьезных проектов.
PS я больше не использую подход function.name очевидно в этом случае имена функций ужимать нельзя при минификации, использую кастомное статическое поле $name.
Я согласен что jQuery можно использовать когда человек понимает как оно работает и когда он может сделать то же самое без jQuery. Но часто бывает что jQuery просто используется, без понимания сути и последствий.
Я не пытаюсь даже спорить, мне лично понятны недостатки и преимущества обоих подходов. Эта чудесная композиция / миксины и ФП (все это делает из кода неконтролируемое месиво) в целом подходят только для простых проектов, можно сказать для проектов где работает один человек которому скучно писть поддерживаемый код (назовем его хипстер).
Код который обычно пишут на jQuery абсолютно не поддерживаемый и не развиваемый. Задача jQuery очень узкая. В первую очередь при разработке чего-то большого необходима структура и модульность. jQuery структуру не предоставляет, и большая часть любителей jQuery не способна самостоятельно задать гибкую структуру.
Попробуйте порефакторить эту «функциональную кашу», сразу разберетесь. Функциональщина делает из кода месиво, которое не может быть однозначно интерпретировано на этапе разработке. Происходит разработка скриптов.
К чему мне ваши ссылки на ресурсы для джуниоров? Я ваши миксины использовал более 10 лет назад, когда их так еще не называли. Так и не поняли чем эти миксины могут навредить большому проекту? Хипстерня любит функциональщину, это очевидно, но на практике такой подход не всегда оправдан.
Не всегда, последние года 4 это уже не так. Задачи которые сейчас решает JS уже далеко не те которые он решал 5-10 лет назад. Серверная часто теперь как правило stateless (да теперь бекенерам проще стало чем было ранее, а в JS гораздо сложнее), состояние держится на клиенте. JS кода стало очень много, и когда кода много важну роль занимает его поддержка и развитие и здесь типизацию сложно недооценить.
Речь идет не только о бразуераз, JS заполонил все направления, есть ведь любители писать много серверной бизнес логики на Node.js без какой либо типизации.
А в TS типизация не опциональна? Плюс теперь есть флаг «allowJs».
Что имеется ввиду под «выводить типы»?
Очень мало вероятно. TS сделан инженерами для инженеров, а ES хипстерами. Если бы ES делали инженеры то типы бы уже там появились, но они просто добавляют синтаксического сахара, это говорит об их приоритетах.
Вот я тоже удивляюсь как люди этого не могут понять, просто молятся на свое ФП. Видимо не сталкивались с большимим проектами и с тем когда разработчики в команде разного уровня. ФП (а также миксины и прочее функциональное месиво) хорошо в блоге показать, на ютюбе роликов сделать, но не для разработки больших и серьезных проектов.
Попробуйте порефакторить эту «функциональную кашу», сразу разберетесь. Функциональщина делает из кода месиво, которое не может быть однозначно интерпретировано на этапе разработке. Происходит разработка скриптов.