Комментарии 35
История, совершенно определённо, уже несколько раз показывала нам, что происходит с веб-технологиями, которые не основаны на веб-стандартах. А именно — такие технологии просто в определённый момент исчезают. Отличный пример этого — 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 что вы используете в своём проекте.
очень спорный факт, из последних 5 проектов 3 было на TS, точнее будет сказать 2.5... но то что TS прочно завоевал свою нишу это факт и то что он не вытеснит JS это тоже на 99% факт... ниша TS это работа с IDE и контроль кодовой базы, в JS огромная проблема с анализаторами кода, а TS + IDE позволяет получить тебе удобоваримое описание функции например... но на этом все, и все это можно получить на JS к. безе, просто подсолив ее TS, если хочешь поспорить попробуй писать код в блокноте например без помощи IDE, да ты возненавидишь TS, TS не дает типизацию он дает аннотацию типов а это 2 большие разницы, весь твой код превратится из кареты в тыкву в полночь... что там еще полезного интерфейсы-да (критично-нет), приватные поля в JS появляются уже, дженерики-сомнительно (посмотреть во что они иногда разворачиваются это пи..ец, не могу подобрать другого слова), к тому же сколько лет нам уже обещают генерировать более оптимальный JS, а воз и ныне там, да наверно это лучше чем код джуна но это хуже чем код мидла с хорошей базой, про ошибки TS закрывает от силы 20%, просто не все ошибки у нас связаны с нашими кривыми руками и невнимательностью, к тому же с TS у нас появился еще 1 тип ошибок после транспиляции в JS, когда что то понять можно только копаясь в уже сгенерированном коде а если учесть что он все еще не оптимален то это занятие так себе, хочешь сказать что это редкость, от части соглашусь во первых по тому что JS всеядный и о половине из них ты так и не узнаешь а во вторых все таки от части детских ошибок TS избавился раз и навсегда, но меньше месяца назад я матом разговаривал неделю когда разбирался с одной из таких, основная проблема TS это то, что качественный код TS != качественный код JS
Нет не подсказывает , а ещё хуже что подсказывает но далеко не всегда, посмотри Климова!
И вот когда он не подсказывает, де-факто тупо не выполняет рефакторинг там, где обещает, случается полный звиздец от исчезновения куска дом до разрушения БД.
Но тайпскриптщики в каментах знаете что говорят? Правильно, "тестить надо!" И "глаза разуть"
Тогда нахрена мне ваш тайпскрипт, чтобы "разувать глаза" на ещё один язык ?
Вам говорят что нафиг бы ваши "типы" вообще, и приводить нечего будет!
А вы в ответ: так ведь же приведение типов !?
Вы же в курсе, что статический анализ из 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-ы. Вот это было бы интересно почитать. А в статье имеем много-много воды и красивых диаграмм. Ух.
Может стоит порекомендовать Svelte?
Автор пишет:
"Главными камнями преткновения в Angular и React являются шаблоны, основанные на XML или JSX. Их надо транспилировать, превращая в нечто такое, с чем мы можем работать."
"Парсинг шаблонов — это настолько вычислительно сложная операция, что в наши дни снова стал популярным серверный рендеринг (server side rendering, SSR)."
Клиенты не занимаются транспиляцией шаблонов JSX Реакта и популярность SSR не связана с парсингом шаблонов.
Лучшие стратегии разработки фронтенда в 2022 году