Комментарии 32
История, совершенно определённо, уже несколько раз показывала нам, что происходит с веб-технологиями, которые не основаны на веб-стандартах. А именно — такие технологии просто в определённый момент исчезают. Отличный пример этого — Microsoft Silverlight.
Главная проблема заключается в том, что ... попросту не используют комментарии, основанные на JSDoc, что позволяло бы IDE выдавать предупреждения в процессе написания кода.
Ну вот, я не один такой, кто считает, что ES6 + JSDoc ничуть не хуже TS, а в чём-то даже и лучше (например, не завязаны на одну корпорацию, пусть даже и очень большую).
С удовольствием перейду на TS как только он начнёт работать в Chrome и Safari напрямую, без транспиляции. Можно без FireFox'а. Нет, даже ещё раньше - как только разрабы движков Blink и WebKit заявят о своих намерениях реализовать нативную поддержку TS. Вот прямо на следующий день и начну кодить на TS, обещаю!
Это к вопросу о том, какие web-технологии считать web-стандартами (которые, кстати, тоже не самые глупые люди утверждают).
Как я понимаю, сейчас вы используете только ту функциональность js и css, которая поддерживается всеми этими браузерами и не используете Бабель для транспиляции?
именно так.
Можно поинтересоваться чем это обусловлено? (не сарказм)
Полагаю что ответ кроется в том что вы просто на клиенте js используете что бы производить простые манипуляции с DOM?
Т.к. в случае работы над большими приложениями обойтись без более серьезных инструментов (вроде vue, react и т.д.) просто не получится (а с ними в ваш проект приходит и использование babel).
А к вопросу по typescript - он ведь приносит не только синтаксический сахар (который сейчас конечно и в es6 завезли), но и хоть какую-то типизацию.
Когда в вашем приложении очень много структур различных типов данных - вам нужно их как-то описывать (typescript как раз с этим очень неплохо выручает).
Если же все ваши задачи на клиенте сводятся к тому что бы императивным способом обновить часть DOM на странице, то разумеется тянуть в приложеие все описанное выше будет overhead.
Но не стоит же в таком случае говорить что "что ES6 + JSDoc ничуть не хуже TS" т.к. TS дает все же больше чем Вам от него требуется и он просто конкретно Вам не нужен, для решения конкретно Ваших задач.
По этому не стоит приводить личный в виде объективной оценки. Для разных задач - требуются разные инструменты.
Можно поинтересоваться чем это обусловлено? (не сарказм)
Я просто считаю транспиляцию лишней.
Т.к. в случае работы над большими приложениями обойтись без более серьезных инструментов (вроде vue, react и т.д.) просто не получится (а с ними в ваш проект приходит и использование babel).
Нет, можно с vue работать и без babel'я. Вот TODO-демо, в котором используется Vue 3 & Quasar UI и не используется транспиляция. Зайдите во вкладку Sources панели Dev Tools в Chrome и сами увидите.
Когда в вашем приложении очень много структур различных типов данных - вам нужно их как-то описывать
JSDoc
Для разных задач - требуются разные инструменты.
Абсолютно верно
По этому не стоит приводить личный в виде объективной оценки.
Объективности не существует, это всего лишь сумма субъективностей. Я полагаюсь на свой личный опыт, потому что я стараюсь по максимуму не лгать самому себе. Буду только рад, если все в мире будут поступать так же. И это... я нигде в этой публикации не говорил, что мой личный опыт - это объективно (сделайте поиск по ключу "объектив"). Я действительно высказываю свою личную точку зрения, а считать её субъективной или объективной - это уже ваш выбор. В любом случае, спасибо за этот совет - я постараюсь и далее не делать того, чего не делал ранее.
Я думаю TS никогда нативно не будет работать в браузере, потому что type check занимает много времени и не нужно вне разработки.
В статье сильно преувеличено число "отрицателей тайпскрипта", и делается неуместное сравнение с сильверлайтом, который изначально был какой-то посторонней нашлепкой на браузер. TS, во первых, максимально возможно совместимый с JS (сравните с КофеСкриптом, который из-за дурацкого синтаксиса закономерно оказался на помойке), во вторых, компилится в сборке и ничего не требует в рантайме.
Полагаю, говорить о "победе Тайпскрипта" следует как о свершившемся факте.
Тайпскрипт не нужен!
"Победа" кого над чем? Если ТС над ЖС то по статистике жс кода без ТС за год написано в шесть раз больше.
"По ела" если и есть то в фантазиях конечных ООПщиков так и не понявших что они уже не в розовом вакууме джавы а в реале веба
Код, который пишется на js - это в основном сопровождение старых проектов, которые (пока) не протипизированы. Новое почти всегда на Машинописи.
А каким образом это обсуждение связано с ООП? И чем "розовый вакуум джавы" отличается от "реала веба"?
Множество стандартных библиотек тоже не типизировано. Что с этим делать? Ждать лет 10 ещё, когда можно будет перестать использовать any?
Сейчас довольно сложно найти более-менее известную библиотеку без встроенной типизации, к которой не было бы пакета "@types/nnn"
Множество стандартных библиотек тоже не типизировано
Если брать не количественно, а по популярности\частотности их использования, то почти всё типизировано. Это как сказать что большая часть интернета до сих пор на HTTP, что отчасти правда, если считать число сайтов. Но если учесть долю на рынке, то всё наоборот (посмотрите среди открытых вкладок сколько из них не HTTPS). Такая же ситуация и с типами.
Проблема типов "стандартных" библиотек не в том, что типов нет, а в том что часто они посредственного качества. Скажем не все методы описаны, не все объекты полны, местами стоят any и т.д..
можно будет перестать использовать any
Его и сейчас нет необходимости использовать. В тех редких случаях когда типов нет вообще, они пишутся руками в d.ts файлах в кратчайшие сроки, т.к. не требуется покрывать всю библиотеку. Достаточно только того API что вы используете в своём проекте.
Это до тех пор пока вы не используете преобразование типов, когда один тип выводится из другого.
Очень удобно, когда у нас есть некая структура и мы строим от нее производные, например для валидаций:
const user = { name: 'testName', age: 25 };
const validations: { [key in keyof typeof user]: (v: any) => boolean } = {
name: () => true, //OK
age: () => true, //OK
birthday: () => true // Not OK birthday not exists in the given type
}В результате, когда у вас меняется модель данных, тайпскрипт сам подсказывает вам в каком месте надо обновить схему валидации. Очень удобно.
Нет не подсказывает , а ещё хуже что подсказывает но далеко не всегда, посмотри Климова!
И вот когда он не подсказывает, де-факто тупо не выполняет рефакторинг там, где обещает, случается полный звиздец от исчезновения куска дом до разрушения БД.
Но тайпскриптщики в каментах знаете что говорят? Правильно, "тестить надо!" И "глаза разуть"
Тогда нахрена мне ваш тайпскрипт, чтобы "разувать глаза" на ещё один язык ?
Вам говорят что нафиг бы ваши "типы" вообще, и приводить нечего будет!
А вы в ответ: так ведь же приведение типов !?
Простите, что? Я привел конкретный кусок кода. Он:
Подсказывает
Всегда
Если у вас есть пример на котором этот код сломается - несите в студию, будем смотреть.
Да, TS не идеален. И не панацея. Иногда он не может вывести типы самостоятельно и тогда мы получаем неявное any, которое и может привести к ошибкам с рефакторингом. Иногда сами разработчики сами пишут any, а потом удивляются что "что-то пошло не так". Бывает что написать сложный тип может быть не просто, это занимает время и в итоге вылазит боком, т.к. тип слишком сложный. Поверьте за почти 5 лет работы с тайпскриптом, ответами на стековерфлоу я все это знаю и прочувстовал своими пальцами.
И тем не менее я все равно за тайпскрипт по очень простой причине - когда я возвращаюсь к своему проекту через несколько месяцев, он:
Намного проще читается
Позволяет включиться быстрее
Да еще и ловит часть ошибок при написании и! ловит будущие ошибки, например с обработкой enum или литеральных типов.
Вы же в курсе, что статический анализ из TypeScript поддерживает JsDoc аннотации? В VS Code, к примеру, даже устанавливать ничего не нужно, достаточно добавить // @ts-check в файл. И у вас все будет: вывод типов, сигнатуры функций, дженерики... Для совместной работы можно поставить хук с проверкой на коммиты и на сборку. И при этом, ваш код будет нормально работать в браузерах без сорсмапов и ваши модули можно будет свободно использовать в JS и TS проектах. А проблемы в TS возникают вовсе не из-за any, а чаще из-за того, что он до сих пор не умеет нормально компилить в ESM, выводить типы для сгенерированных классов и много чего еще.
до разрушения БД
Если у Вас БД ломается от изменения ts, то у Вас проблемы с архитектурой
посмотри Климова
Не стоит. Он в своей нелюбви к Typescript давно уже перестал быть объективным. Его категоричность давно перешла грань здравого смысла. Особенно когда в одном видео он топит за то что типы не нужны, пишите на JS + тесты, а в другом давайте писать на sound re-script, ибо "всё или ничего". Либо язык без типов, либо сразу sound. Климов — просто TS хейтер. TS есть за что ругать, но Климов воюет не туда.
Лично я с ним только в одном согласен — писать на TS хорошо могут немногие. Язык богат на возможности, но задействовать их с пользой бывает весьма нетривиально. Уровень входа в язык высокий.
JSDoc вам не даст даже трети того, что умеет TypeScript.
Давно используем подобную схему (main window + worker + OffscreenCanvas), в нашем случае это почти что необходимость, т.к. много работы с графикой и обработки данных на клиенте. Для облегчения работы с воркером написали обертку, которая позволяет вызывать апи домена как обычный метод. Обертка заворачивает аргументы и путь к функции в json и отправляет в воркер, получает ответ и возвращает promise. Заодно сериализует параллельные запросы к воркеру в последовательные, так что внутри домена в 1 момент только один экшен выполняется. Довольно удобно вышло. Есть на гитхабе, но почти без комментариев и документации, руки еще не добрались(
По поводу статьи есть несколько замечаний: OffscreenCanvas хорошо работает в FireFox (с включенным флагом, как говорит MDN, но я не уверен что это актуально) и никак не работает в Safari, в нем приходится рендерить в обычном canvas/svg, что получается значительно дольше, да и отзывчивость страдает. SharedWorker не работает с OffscreenCanvas, но его можно прокидывать через window.opener в обычный воркер.
Засовывать UI библиотеку в воркер кажется бессмысленным, там существует ощутимая задержка, которая убьет отзывчивость приложения, лучше делать тупые компоненты, отображающие стейт из воркера и обрабатывающие действия пользователя с маленьким локальным стейтом.
Каким бы быстрым не был ваш Virtual DOM, вы не можете обойтись без этапа синхронизации его с реальным DOM, и тут все преимущества теряются а недостатки остаются. Вы, конечно, можете выиграть на обработке синтаксиса шаблона, но все равно не сделаете кастомный парсинг на js быстрее старого доброго innerHTML. Ну и кастомный синтаксис, если он у вас есть - это ваш "выстрел в ногу", без него легко можно обойтись используя стандартный DOM API внутри DocumentFragment на этапе создания экземпляра компонента. Помимо этого, вынос кода в воркер делает ваше решение глубоко асинхронным, со всеми вытекающими. В общем, в рассуждениях автора, имеются довольно слабые места, хотя настрой, в целом, верный.
А вот другие его ядра в это время, вполне возможно, будут совершенно ничем не заняты.
Мне кажется, в 90% случаев в фоне будет запущено ещё мноого всего. Ситуация, когда пользователь заходит на ваш сайтик, не имея ни других открытых вкладок, ни других работающих в фоне приложений - редка.
Очень детальная и толковая статься, спасибо!
Что вы подразумеваете под "парсингJSX шаблонов на клиенте"?
Ожидал от статьи какой-то конкретики. Ведь все итак знают, что можно вынести часть логики в worker-ы, но потом встаёт проблема коммуникации между основным thread-ом и worker-ом. И вот тут дилемма — а как организовать это всё так, чтобы потери на обмен не превышали выгоды от выноса логики в worker-ы. Вот это было бы интересно почитать. А в статье имеем много-много воды и красивых диаграмм. Ух.
Лучшие стратегии разработки фронтенда в 2022 году