Отличные видео, после них всегда мысль: хорошо что не повелся на обещания разрабов очередного модного фреймворка. Самые бессмысленные и расхайпленные вещи по моему это effector и fsd. Кто-то явно тешит свое ЧСВ такими вторичными выдумками. Спасибо, что сэкономили время этими видео, было интересно.
Хочу добавить, что самое кринжовое видео было с разбором $mol из-за самой подачи, тут бы немного подготовиться, набор тематических шуток составить, а то эти задержки на вхождение образ мага ну чересчур долгие)
Большой пыт написания крупных проектов на Typescript и Javascript + JSDoc, есть что сказать. Ксли кратко: они равны по возможностям, отличается лишь синтаксис. Как async/await и then/catch. А на "чистом" Javascript без JSDoc писать что-то сложное не советую, одного лишь автовывода типов мало. Откуда автовывод в Javascript? Подкидываем в проект jsconfig.json вместо tsconfig.json, не забываем включить побольше строгих правил. Все, ваш Javascript-код проверяется точно так же, как Typescript-код. Далее вместо двоеточий используем документационные комментарии с тегами, самые популярные будут @type, @typedef и @template. Полно и других классных тегов, например, чтобы делать поля приватными, перегружать функции. Читайте про JSDoc, многое пригодится и для тайпскриптунов, пишущих библиотеки. А еще вы можете делать compile-time проверки через запуск tsc с флагами, можете использовать все это дело в watch-режиме или в pre-commit git-хуке. Ну и конечно для библиотек будет полезно, если вы сгенерируете d.ts файлы через тот же tsc при публикации.
Удачи поддерживать код, который писался человеком без mobx скилов. Когда в простейшем компоненте я вижу адовую смесь эфектора с реактом мне хочется вышвырнуть из компании этот лапшекодолюбивый балласт в вместе с HR котрый его принимал. Зато он всегда сумеет вам объяснить, почему поддержка стоит такого нереального бабла и ответственно впарить команде сырейшую либу с тысячами звездочек на гитхабе. Реально уже задрало.
Только в примерах, так то я активно работаю с JSDoc и/или Typescript.
никакого Prettier с форматированием с отступами
Извините, форматирование есть в исходнике статьи, просто пока не разобрался почему отображается она без них. К Prettier и Eslint я давно привык, и не представляю как без них можно работать.
Я для многих проектов использую сторы на классах, не понимаю что в них является ненужным и вредным
Я считаю, что Javascript-классы вредны именно из-за бессмысленности их существования, не давая ничего хорошего взамен, они позволяют писать код в еще одном стиле, что приводит к необходимости небольшого ментального переключения во время чтения чужого кода на классах, а так же при его правках. Я бы мог попросить примеры, где Javascript-классы обладают большей читабельностью, нежели простые объекты и функции, но, полагаю, это все будет вкусовщина.
Я целый год писал на иммутабельном redux и вообще не понимаю в чем прикол. Что дает иммутабельность в реальном frontend проекте?
Мне нравится, что иммутабельность дает гарантии безопасной работы с объектами, разумеется, при использовании немутирующих эти объекты функций. То есть при любой вложенности объектов я могу не опасаться того, что в другом участке кода будет вызвана их мутация, что приведет к тяжело отслеживаемому поведению. При этом я совершенно не против использования мутаций при заполнении свежих объектов в пределах одной небольшой функции, если так код читается чище и работает быстрее.
Тоже бы посмотрел, но пока еще вроде сыро, на Windows только рантайм, куча других проблем. @nin-jin Сделаете нам разбор, как Bun будет готов?
Отличные видео, после них всегда мысль: хорошо что не повелся на обещания разрабов очередного модного фреймворка. Самые бессмысленные и расхайпленные вещи по моему это effector и fsd. Кто-то явно тешит свое ЧСВ такими вторичными выдумками. Спасибо, что сэкономили время этими видео, было интересно.
Хочу добавить, что самое кринжовое видео было с разбором $mol из-за самой подачи, тут бы немного подготовиться, набор тематических шуток составить, а то эти задержки на вхождение образ мага ну чересчур долгие)
Согласен, но это чтобы не унижать Rust и Go, на которых автору нравится писать) Если кто не в курсе: https://www.techempower.com/benchmarks/#section=data-r21&test=composite
Вам пишут о странах, а вы жалуетесь на свой поселок, не слишком мелко?
Большой пыт написания крупных проектов на Typescript и Javascript + JSDoc, есть что сказать. Ксли кратко: они равны по возможностям, отличается лишь синтаксис. Как async/await и then/catch. А на "чистом" Javascript без JSDoc писать что-то сложное не советую, одного лишь автовывода типов мало. Откуда автовывод в Javascript? Подкидываем в проект jsconfig.json вместо tsconfig.json, не забываем включить побольше строгих правил. Все, ваш Javascript-код проверяется точно так же, как Typescript-код. Далее вместо двоеточий используем документационные комментарии с тегами, самые популярные будут @type, @typedef и @template. Полно и других классных тегов, например, чтобы делать поля приватными, перегружать функции. Читайте про JSDoc, многое пригодится и для тайпскриптунов, пишущих библиотеки. А еще вы можете делать compile-time проверки через запуск tsc с флагами, можете использовать все это дело в watch-режиме или в pre-commit git-хуке. Ну и конечно для библиотек будет полезно, если вы сгенерируете d.ts файлы через тот же tsc при публикации.
Есть ли преимущества для React-разработчиков перед Visual Studio Code? Если есть, то какие самые сильные?
Только в примерах, так то я активно работаю с JSDoc и/или Typescript.
Извините, форматирование есть в исходнике статьи, просто пока не разобрался почему отображается она без них. К Prettier и Eslint я давно привык, и не представляю как без них можно работать.
Я считаю, что Javascript-классы вредны именно из-за бессмысленности их существования, не давая ничего хорошего взамен, они позволяют писать код в еще одном стиле, что приводит к необходимости небольшого ментального переключения во время чтения чужого кода на классах, а так же при его правках. Я бы мог попросить примеры, где Javascript-классы обладают большей читабельностью, нежели простые объекты и функции, но, полагаю, это все будет вкусовщина.
Мне нравится, что иммутабельность дает гарантии безопасной работы с объектами, разумеется, при использовании немутирующих эти объекты функций. То есть при любой вложенности объектов я могу не опасаться того, что в другом участке кода будет вызвана их мутация, что приведет к тяжело отслеживаемому поведению. При этом я совершенно не против использования мутаций при заполнении свежих объектов в пределах одной небольшой функции, если так код читается чище и работает быстрее.