Фронтендеры — герои. Yehuda Katz объясняет почему

Original author: Yehuda Katz
  • Translation

Идея что фронтенд это "для джунов", расстраивает меня тем, что никто не скажет так про другие специализации.

Кто-то может сказать, что неплохо, если б автор компилятора был более "фуллстековым".

Но они не скажут, что "писать компиляторы это для джунов".

Это перевод треда Yehuda Katz из твиттера. Под фронтендом здесь подразумеваются именно браузерные приложения на JS (и, отчасти, вся JS-экосистема).

По сути, когда люди говорят «фронт для джунов», они делают несколько больших ошибок. Вот две из них:

  1. Они недооценивают сложность работы.

  2. Они переносят мемы про тулинг фронта на самих фронтендеров.

Фронтенд - это сложно в самой своей сути

Во-первых, это непростая техническая работа. Она включает асинхронный обмен данными с сервером в ситуации, которая часто связана с неожиданными ошибками в реальной жизни, когда при этом надо сохранить интерактивность интерфейса.

На самом базовом уровне это просто трудно. Эквивалент «пользователь закрыл свой ноутбук» - это «что, если случайные 5% моих SQL-запросов в Rails фейлятся».

Начинающие фронтендеры не думают об этом, но более опытные - точно учитывают такие кейсы.

Хотя бэкэнд в основном не имеет состояния (и это нам очень нравится), на фронте пользователь может запустить какие-то асинхронные запросы, а затем продолжить использовать приложение произвольным образом.

На бэкэнде вы получаете в значительной степени согласованное представление о мире, с которым можете работать (через ACID транзакции), на клиенте вы постепенно увеличиваете локальный кеш данных, который не имеет гарантий внутренней консистентности.

Опять же, если вы думаете, что «на самом деле никто не работает над этим, лол», вы сильно ошибаетесь.

Опытные фронтендеры МНОГО думают о том, как структурировать свои приложения так, чтобы минимизировать эти проблемы, да ещё и так, чтобы начинающие смогли всё это понять.

Фронтенд сложен ещё и с другой стороны: это место, где покрышки касаются дороги при работе с пользователем.

Требования пользователей накладывают больше ограничений на то, что вашему коду могут простить.

Интерфейс - это то, о чем думают руководители вашей компании, когда придумывают новые идеи для приложения.

И очень часто у них есть особое мнение о том, как должен выглядеть этот интерфейс и как он должен работать.

Мелкие ошибки в коде интерфейса заметны не только руководителям и менеджерам компании, но и пользователям.

Косяк в интерфейсе может быть вызван ошибкой стиля, из-за которой один блок перекрывает другой на каком-то экране случайного размера, который никто не тестировал.

На бэкэнде нет ничего похожего.

Вкратце: на фронтендеров возлагается задача реализовать ту часть приложения, о которой ваши пользователи и руководители могут составить своё мнение и, исходя из него, находить какие-то ошибки.

Фронтендеры должны реализовывать идеи (и адаптироваться к мнению руководителей и пользователей) во враждебной среде (глючный браузер привет Safari, блокировщики рекламы, расширения для перевода и т.д.), в которой пользователь может создать странное состояние приложения в любое время, просто перейдя в комнату с плохим Wi-Fi.

И это важно: опытные фронтендеры постоянно работают над этими сложными проблемами и стараются сделать их решения понятными для менее опытных разработчиков.

Некоторые эти проблемы решаются фреймворками, но многие из них трудно решить целиком и полностью.

И, наконец, так как на самом деле фронтенд - это вход в программирование для неопытных разработчиков, опытные фронтендеры работают над тем, чтобы их решения этих проблем были достаточно общими, чтобы кто-то прямо в учебке мог использовать их продуктивно и правильно.

Я видел это во многих, многих компаниях, включая Tilde. Опытные фронтендеры наставляют и направляют новых разработчиков.

Это все очень сложно и запросто может превратиться в отдельную специальность и карьеру. Бессмысленно выделять один только фронтенд и назвать все перечисленное чем-то только для джунов.

Но, я согласен с тем, что каждая техническая роль выиграет от большей "фуллстечности".

Лично я работаю над ядром Ember, бэкэнд-кодом Rails и бэкэнд-кодом Rust, когда работаю над Skylight.

Я считаю, что это хорошо.

Но никто никогда не скажет: «Специализация на Rust-бэкэнде у нас имеет смысл только для джунов». По сути, сказать так про фронт - значит сильно недооценить сложность задач, которые стоят перед фронтендерами.

Итак, это была первая часть.

Мемы про node_modules

Вторая часть - это (откровенно комичное) высмеивание инструментов фронта.

Скажу как человек, который в свое время создал много тулингов (bundler, cargo, инспектор Ember): тулинг фронта часто на голову лучше, чем тулинги, которые кто-то может самодовольно превозносить.

Не только JavaScript может получать пользу от транспайлеров. Разве плохо было бы, если б большинство фич C++ 20 работали с более старыми (и все еще широко использующимися) версиями компиляторов через транспиляцию?

Сделать подобное непросто, но в экосистеме JS вы можете использовать совершенно новые фичи (включая экспериментальные), даже если вы ориентируетесь на гораздо более старые браузеры.

И дело не только в том, что вы можете транспилировать код: инструменты вроде eslint, IDE language servers, syntax highlighters и TypeScript обычно поддерживают большую часть самой последней версии ECMAScript задолго до того, как она будет завершена.

Кстати, о TypeScript. TypeScript - лучшая в своем классе система постепенной типизации для динамического языка. Ничто другое (может, за исключением Racket) даже близко к подобному уровню не подбирается, особенно если учесть интеграцию в экосистему и проработанность тулинга.

И всё это довольно легко работает с популярным расширением JS (JSX), которое даже не входит в спецификацию ECMAScript.

Таким образом, вы можете написать свой код в TSX с помощью ES2020, получить отточенный линтинг и тулинг, а затем скомпилировать его за кулисами для старых браузеров.

И для этого не надо ручками указывать набор фич, которые нужны от браузера.

Стандартный способ указать, какие фичи необходимо транслировать - это browserslist, который позволяет вам сказать «последняя версия Chrome» или «браузеры с долей рынка в 1%».

Таким образом, вы просто используете ES2020 и TypeScript, указываете браузеры, которые вам нужно поддерживать (используя гибкое описание, основанное на данных, поддерживаемых caniuse.com), и легко получаете сборку, которая работает в поддерживаемых браузерах.

Если надо поддерживать Node - всё то же самое.

Вдобавок ко всему, девтулзы в браузере намного, намного лучше, чем любые отладчики, доступные для большинства языков - если, конечно, учесть, насколько легко их настроить и насколько они доступны для людей с любым опытом.

Насмехайтесь над npm сколько угодно, но отличия npm от Bundler сильно повлияли на мой дизайн Cargo, а экосистема Rust стала лучше из-за отсутствия ограничения «только одна копия вашей зависимости, даже если она используется только внутри пакета».

Конечно, npm мог бы быть лучше, но было впечатляюще (и вдохновляюще) наблюдать за медленным и неуклонным улучшением npm на протяжении многих лет (приличное разрешение зависимостей, файлы блокировки, йуху!).

Workspaces из Yarn перенимаются в npm и pnpm, что ставит фронт в высшую лигу языков с хорошей поддержкой монорепозиториев (поддержка не идеальна, но точно в высшей лиге).

Вдобавок ко всему, бандлеры JS должны (просто для выживания) поддерживать разделение кода и удаление мертвого кода, при этом понятное для неопытных разрабов.

Они также должны иметь возможность поддерживать динамическую загрузку частей приложения так, чтобы это было совместимо с оригинальной семантикой модулей, которую имел в виду программист.
Да, DLL не новы. Нет, они не работают запросто со всем вышеперечисленным, во всяком случае без познаний уровня волшебника.

И ни одно из этих ограничений не является случайным или «чрезмерно усложняющим проблему».

Фронтенд-разработка - сложная проблема по самой своей сути. Это расплата за то, что мы можем писать приложения, которые работают в любой операционной системе, на более старых машинах (и ОС), различных разрешениях (от маленьких телефонов до сверхшироких дисплеев), технологиях доступности и версиях всех этих вещей, которых даже не существует на момент написания кода (при этом ещё и продолжая постоянно работать вне зависимости от обновлений пользовательских устройств).

В заключение

Я полностью согласен с тем, что люди должны стараться стать более универсальными в разработке и что чрезмерное внимание к одной специализации может скрыть от инженера какие-то важные детали в соседних областях.

Но это не делает фронтенд специализацией, подходящей только для «джунов».

По моему опыту, легче полностью погрузиться во фронтенд, нежели во что-то вроде Rails, и при этом всё ещё приносить огромную пользу по мере развития.

Это, кстати, вызвано (отчасти) тем фактом, что фронт достаточно прост для начинающих разработчиков.

Из-за этого опытные фронтендеры значимую часть времени обучают новых разработчиков.

Также поэтому опытные фронтендеры отвечают за создание абстракций, которые решают все вышеперечисленные проблемы способом, доступным для огромного круга разработчиков.

Если вы фронтенд-разработчик, не позволяйте никому высмеивать то, что вы делаете, и не позволяйте никому относиться к фронту как к чему-то «более легкому» или менее подходящему для специализации, нежели более традиционный бэк.

Думайте о себе как о герое, который несет прямую ответственность перед пользователем и руководителями, отвечает за то, чтобы ваше приложение работало в чрезвычайно враждебной и неизвестной среде (сравнивая с «запустить Go в докере»).

Вы также несете ответственность за создание абстракций, которые может использовать весь спектр разработчиков в вашей компании, потому что начинающим нужна ваша помощь.

И мы все здесь, чтобы оформлять друг для друга полезные частички функциональности и даже целые фреймворки, которые позволяют не переизобретать велосипеды для очередного хелловорлда.

Мои друзья-фронтендеры: мне нравится быть с вами в одном сообществе.

Продолжим же доказывать, что ненавистники ошибаются, продолжим создавать классные вещи для пользователей самых разных девайсов. Продолжим удивлять людей тем, чего мы можем достичь вместе.

Мы круты! Мы зажигаем!

Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 71

    +3
    Разве плохо было бы, если б большинство фич C++ 20 работали с более старыми (и все еще широко использующимися) версиями компиляторов...

    -Да, никому не упали лишние UB

      +22

      В формате мема:


      Все: Ржут над npm с его node_modules и говорят что python куда лучше для новичков


      Python3: Я буду ставить зависимости всех проектов прямо в систему. Ну, если только если ты не обманешь её, сделав одним из нескольких способов венв и не пообещаешь на словах, что не забудешь включать венв когда будешь ставить зависимости. Которые, кстати, будут просто в текстовом файле, а если там нужны системные библиотеки — то пошел ты нафиг, вот что.

        +1
        Все давно в pyproject.toml (https://python-poetry.org/)
        +2
        Никогда не думал, что фронт для джунов. До этой статьи.
          +3

          А как она изменила это мнение?

            +2
            Когда в чем то начинают активно разубеждать, невольно находишь аргументы в пользу противоположного мнения.
              0

              И какие аргументы Вы нашли?

                +1
                Довольно низкий порог входа. Весьма большое, как мне кажется, количество задач покрывается знаниями, которые можно получить за 2-3 месяца с нуля. По крайней мере этого хватит на пропитание. Не знаю так ли это в беке.
                  0

                  Что значит "низкий порог входа"? Создать index.html в 2к21 уже недостаточно, если что :)

                    –4
                    Ты очень нудный, потому что просишь объяснять все мотивы субъективного мнения.
                      0

                      99.9999% всех разговоров в интернете строятся вокруг объективных суждений (данная цифра тоже субъективно взята с потолка), не понимаю, в чем проблема ¯_(ツ)_/¯

                        0

                        субъективных конечно же facepalm.jpg

                    +2
                    Довольно низкий порог входа. Весьма большое, как мне кажется, количество задач покрывается знаниями, которые можно получить за 2-3 месяца с нуля.

                    Низкий порог входа только для тех, кто копипастит примеры jQuery со Stack Overflow.

                    Я пару лет активно занимался кастомным фронтедом HTML/CSS/Vanilla JS (никакого jQuery или Бутстрапа). А потом за 2-3 месяца освоил бекенд (настройка сервера и NodeJS). До этого я боялся бекенда. Думал, что им занимаются только хардкорные программисты. Но я очень удивился, когда осознал, что те логические задачи которые мне приходится решать на фронденте на порядок сложнее тех, с которыми я сталкиваюсь на бекенде. Это в разрезе одного среднестатистического сайта на котором я делаю и фронт, и бек.

                    Тут автор правильно заметил: фронтендер имеет дело с асинхронным кодом и «многослойным» приложением в котором вам параллельно нужно решать разные задачи (дирижировать этим всем). А на бекенде, грубо говоря: точка входа и точка выхода. И вся работа бекендера между этими точками «по прямой». Это я про обработку запроса.

                    Это моё субъективное впечатление на основе описанного выше опыта.
                      0
                      По большинству задач соглашусь с вами. Сам программирую и фронтенд и бекенд. На бекенде становится сложнее, когда приходится решать нетиповые задачи, правильнее сказать задачи, которые требуют больше ресурсов, чем может дать железо сервера, сетевые ограничения. Тут и начинаются танцы с бубном). На фронте проще упереться в ограничения.
                +1

                Статья показалась очень наивной:


                1. Фронтэндеры подменяются мифическими "опытными фронтэндерами"
                2. "Сложность" частично подменяется "важностью"
                3. Много воды типа "сложные проблемы такие сложные", "МНОГО думают над этими проблемами", "ПОСТОЯННО работают над этими проблемами"

                Показалось что кучка джунов напостила комменты в твиттер — и вот статья.

                  0

                  вы же в курсе, кто такой Yehuda Katz?

                    0

                    Какая разница? Я про содержание статьи, а не про количество женщин, которые хотят от него детей.

              +14

              Люди:
              "С фронтом справится любая обезьяна, там делов-то что джейсон перекладывать и формочки клепать"


              Эти же люди:
              "Эй, почему у меня сайт тормозит? Почему он грузит мегабайты жс-кода? Почему так медленно? Где доступ с клавиатуры? Почему в сафари всё поехало? Какие дятлы вообще так делают?!"

                +5

                Дятлы? Герои!

                –6
                Человек, который хвалит тулинг JS либо никогда не работал ни с чем другим, либо никогда не работал с проектами больше одностраничника. Когда у тебя тайпчек после простого изменения делается по 2-3 минуты, или вообще tsc отваливается — разработка превращается в ад. Сборка проекта, который пишется меньше года по 15 мин — да запросто. Тайпинг в тайпскрипте лучший — ну программисты Dart с вами не согласны.
                Редко соглашаюсь с этим автором, но вот тут он прав — Объясните, почему мой рокет-саенс бэкенд билдится пару секунд, а четыре формы на фронте — полгода
                А по-поводу отношения как к джунам — не знаю как так получается, но у меня сложилось впечатление, что фронтендеры гораздо чаще изучают и знают именно технологии, а не само программирование. Вы когда-нибудь видели чтобы в мире C# делили людей на EntityFramework-разработчик или Dapper-разработчик? А Senior React Developer — это в порядке вещей.
                  +8

                  Яхуда Кац явно работа с проектами вне фронтенда. И большие проекты явно делал.

                    0
                    > Сборка проекта, который пишется меньше года по 15 мин — да запросто.
                    А на C можно membomb написать, которая вообще не соберется.
                    strict: true надо включать и типы чаще прописывать, тогда тайпскрипт компилирует довольно быстро. Ну и реакты с англурярами собирать отдельно, чтобы по 10МБ на диск не читать/писать
                      +2
                      ну программисты Dart с вами не согласны.

                      А можно пример?


                      Когда у тебя тайпчек после простого изменения делается по 2-3 минуты

                      Это проблема. Но стоит отметить, что эта проблема присутствует, наверное, во всех языках с продвинутой системой типов. И ею она и обусловлена. Т.е. тормозами вы платите за комфорт. Если вас устраивает система типов в C#, то вы можете писать на TS так, чтобы он копилировал быстро.

                        0
                        Деление есть, но его мало. Для примера есть SharePoint. Знания только c# будет мало, надо понимать особенности экосистемы SP. Если покопать, то причина кроется в маркетинге и попытке удешевить оплату труда разработчика, уменьшая порог вхождения. То бкенда тоже доберется). В целом кодить на фронте сложнее чем на бекенде. Большинство фронтовых заказов в области сайтиков, с которыми справляются и недопрограммситы)
                          +1

                          Настройте babel для транспиляции и линтер для tsc.
                          А tsc --noEmit используйте периодически для проверки.
                          Итого, компиляция через бейбл 1,7сек, через tsc 47. Как-то так.)

                            0
                            у меня сложилось впечатление, что фронтендеры гораздо чаще изучают и знают именно технологии, а не само программирование

                            Это ложное впечатление. Прочитайте мой комментарий выше: habr.com/ru/post/535724/#comment_22530464
                              +1

                              На самом деле обе стороны правы. Или обе ошибаются, как посмотреть. По долгу службы имею отношение к собеседованиям сотен кандидатов самых разных профилей и стеков, и могу своими глазами наблюдать, что сейчас что фронты, что беки — одинаково плохо знают и не умеют в программирование.

                            +1
                            Вы когда-нибудь видели чтобы в мире C# делили людей на EntityFramework-разработчик или Dapper-разработчик? А Senior React Developer — это в порядке вещей.

                            "Senior Oracle Developer", это тоже человек, который просто знает именно технологию, а не само программирование? (вакансия как доказательство существования профессии, а не реклама).
                            В целом, все описанные Вами проблемы решаются очень просто, у нас проект, которому больше 7 лет, с кучей файлов, ts'ом, scss'ом, vue, и прочая и прочая, собирается за 30 секунд 3-им webpack'ом:) (можно и быстрее, но неактуально, пока что)
                            0

                            У меня есть гипотеза, почему «фронтенд для джунов».


                            1. Никто не хочет тратить время на нагромождение костылей по имени HTML+CSS и часто отдают это джунам.
                            2. Делать типовые формы и таблицы действительно несложно.

                            Верстка, формы и таблицы это, наверное, 80% всего фронтенда и с этим справляются джуны. То же самое можно сказать и про бек, где 80% это принять запрос, запустить SQL, вернуть результат.


                            Сложный фронтенд это же модель в памяти, обновляемая и читаемая из разных потоков, без транзакций, в среде, где приложение может быть закрыто или остановлено в любой момент. Это сложно как ни крути.

                              0
                              То же самое можно сказать и про бек, где 80% это принять запрос, запустить SQL, вернуть результат.

                              Кто то еще этим занимается в 21 веке? Я уже лет 10 ввод/вывод данных не писал, есть куча спецификаций которые это делают автоматом для CRUD.
                                +3

                                На одной из работ нужно было делать много разных таблиц.


                                На первый взгляд действительно просто. Но потом возникают такие вещи как:


                                • динамические данные
                                • фельтиперсовые ячейки а-ля прогресс-бары, чарты, красотульки, свистелки и пукалки
                                • фильтрация, из хэдеров или из-вне.
                                • пагинация, причем обязательно сподвывертом и красивыми кнопочками
                                • сортировка, причем когда у вас фельтиперсовые ячейки в виде графиков, прогрессбаров и тд
                                • изменение данные прямо из таблички
                                • объединение ячеек и колонок
                                • drag-and-drop
                                • i18n
                                • ....

                                Вот и прыгаешь по всем этим DataTables, ag-Grids и мериадам реактовых велосипедов. А потом еще и сам свой велосипед начинаешь городить ибо ничего из готового под фантазию твоих продуктов не подходит.

                                  0
                                  Конечно же я не о таких таблицах говорил.
                                    –6

                                    Что только это фронтендеры ни придумают, лишь бы $mol не использовать..

                                  0
                                  Удивлен, почему «пользователь закрыл ноутбук» преподносится как внезапное, неочевидное и уникальное для фронта поведение. Аналоги его присутствуют для любых (во всяком случае, во всех, мне известных) областей. Виртуальная машина встала на suspend и вернулась через 10 минут. Антивирус заблокировал временно или перманентно один или несколько ресурсов, используемых десктопным приложением. В среде обновилась библиотека и теперь она вызывает ряд недокументированных эффектов в старых функциях. Пропало питание, в конце концов. Продолжать можно бесконечно… В большинстве случаев приложение должно разрабатываться с учётом того, что кругом враги и на входе и выходе могут произойти непредвиденные ситуации. И да, «X для Y» без уточнения условий не вызывает ничего, кроме снисходительного недоумения. Разве только кроме иронического применения)
                                    +4

                                    На беке если пропало соединение с базой, то просто вернули ошибку и все. На фронте же нужно переходить в состояние «восстанавливаю соединение», завершать начатые операции каким-то образом, бывает закрывать диалоговые окна, может быть чистить что-то в памяти и так далее. Понятно, что на беке такое тоже может быть, например кеш очистить. Но на беке это бывает нужно, а на фронте такое нужно всегда.

                                      +2
                                      Вселенная не ограничивается backend как прослойкой между фронтом и базой. Вполне регулярное явление, когда после получения информации о недоступности необходимого ресурса нужно диагностировать, что отвалилось ещё, продолжать ли работу службы после этого, составить отчёт о неполадке и выбрать доступный способ его сохранения (может быть недоступен диск, но доступен сетевой логгер, к примеру). Я уж не говорю о толстых клиентах, драйверах и прочем, что почему-то в последнее время во внимание не принимается. Разработка это не только web.
                                      +3

                                      Отличие в том, что в бекенд обычно stateless и подобные приколы решаются рестартом сервиса. Сложные распределенные системы где нужно хранить состояние встречаются нечасто.


                                      А вот требование, чтобы страничка нормально работала когда ноутбук выходит из спящего режима – это норма для даже самого простого онлайн-магазина.

                                        0
                                        Вы всё, что не web-фронт, почему-то обобщаете в stateless-бэк (плюс редкие не-stateless). Модуль расширения для Postgres, к примеру, к разработке не относится? Или там не требуется отрабатывать нештатные ситуации? Или перезапускать сервер с тяжелыми базами — это не критично? Не вполне понял Вашу мысль.
                                          0

                                          Понятно, что есть другие системы. Просто обычно сравнивают фронт и бек одного проекта, как сопоставимые задачи

                                      –3
                                      Кстати, о TypeScript. TypeScript — лучшая в своем классе система постепенной типизации для динамического языка.

                                      Не знаю как Вы, но лично я бы предпочел, чтобы TypeScript имел обязательную статическую типизацию. Думаю, если сильно постараться можно даже отказаться от типа any. Но больше всего в ts мне не нравятся дженерики. Окей, они есть, но почему нужно делать какие-то костыли?
                                      спойлер
                                      ёлы-палы, я только сейчас увидел как давно этот вопрос был задан, мда…
                                        0
                                        Окей, они есть, но почему нужно делать какие-то костыли?

                                        Принимая во внимание, что в TS это просто типы поверх JS, получается, что автор вопроса хочет странного. Он хочет получить тип, который есть только на стадии компиляции, и использовать его в runtime. Для этого надо класс передавать явным образом в виде, скажем, аргумента. Ну или замыкания. Т.е. generic-и в TS тут совсем не причём, т.к. они — просто типы. Они абстрактная нематериальная сущность, к ним нельзя обратиться в runtime, т.к. их просто не существует в runtime. Весь TS это просто абстракция.


                                        TypeScript имел обязательную статическую типизацию. Думаю, если сильно постараться можно даже отказаться от типа any

                                        TS это wrapper над JS, и практически все проблемы TS вытекают именно из этого. Например отсутствие удобных перегрузок, отсутствие доступа к типам в runtime, unsoundness и пр..


                                        Я бы тоже предпочёл, чтобы в browser-ах появился новый язык, с выразительностью и системой типов не ниже TS/Flow, но sound (напр. Scala 3). Это же позволит сделать его весьма быстрым. Однако этого, я полагаю, не случится в ближайшее десятилетие.

                                          –2
                                          В браузерах есть webassembly.

                                          И, я надеюсь, с какого-то момента из webassembly будет доступ к DOM без JS interop и мы забудем про JS как про страшный сон.
                                            +1
                                            Боюсь webassembly породит еще больше проблем, они просто будут другими), но решит текущие)
                                              +1

                                              Доступ в DOM из WASM не поможет. Потому что внезапно выскочат все те же грабли что и в JS


                                              • Массивы, которые совсем не массивы, а NodeList со своим поведением
                                              • document.all который имеет тип undefined, но со значением

                                              Можно, конечно, сказать "а давайте выкинем это легаси и сделаем новый нормальный API", но это совсем другого порядка задача и как заметил faiwer, в ближайшем десятилетии это вряд ли случится

                                                0
                                                В чем проблема сделать новое браузерное API, если обратная совместимость нас не тянет? Это как раз тот случай, когда можно и нужно. Легаси продолжит использовать интероп, ибо и сам JS сразу никуда не планирует исчезать из браузеров.
                                            0
                                            Т.е. generic-и в TS тут совсем не причём, т.к. они — просто типы. Они абстрактная нематериальная сущность, к ним нельзя обратиться в runtime, т.к. их просто не существует в runtime.

                                            Так ведь можно сделать так, чтобы они были доступны: записывать референсы на конструктор в приватных статических полях класса, доставать их оттуда. Проблема только в том, что это не будет работать с выдуманными типами «string», «number». Но даже это можно обойти, если во время транспиляции подставлять соответственно «String» и «Number». Это всё только должен разруливать tsc, а не программист.

                                            В NestJS подобный бойлерплейт заменили аннотациями, менее удобно, но сойдет.
                                              +1
                                              Так ведь можно сделать так, чтобы они были доступны: записывать референсы на конструктор в приватных статических полях класса, доставать их оттуда

                                              Записать в references вы можете только class-ы, т.к. interface-ов и type-ов просто не существует в runtime. Записывать же туда только классы — очень спорное решение.


                                              Но даже это можно обойти, если во время транспиляции подставлять соответственно «String» и «Number»

                                              Очень слабое решение. Это позволит покрыть условно 0.1% возможностей типов в TS. Зачем оно такое нужно на уровне языка? Я уже использовал это решение как раз с NestJS. Ощущение того что это эпичный костыль не покидало и не покидает меня по сей день. Там такое количество "но"…

                                                0
                                                очень спорное решение

                                                Ну дык из enum'ов сделали же порнографию, что с дженериками такое провернуть не могут?

                                                Ладно, я понял Вашу позицию. Можете привести примеры возможностей типов в TS только? Пока не сообразил, что имеете в виду.
                                                  +1
                                                  Ладно, я понял Вашу позицию. Можете привести примеры возможностей типов в TS только? Пока не сообразил, что имеете в виду.

                                                  Ну например:


                                                  • Сигнатуры у методов
                                                  • Алгебра типов (особенно |)
                                                  • higher order rank polymorphism
                                                  • Рекурсивные типы
                                                  • Литералы
                                                  • Перегрузка
                                                    –4
                                                    Ну например:

                                                    Сигнатуры у методов
                                                    Алгебра типов (особенно |)
                                                    higher order rank polymorphism
                                                    Рекурсивные типы
                                                    Литералы
                                                    Перегрузка

                                                    все ясно автор кроме ванильного жс ниче не курил


                                                    господа кстати слышали про дено
                                                    а нет тайпскрипт же статический в 2к21 а ну ладно

                                                      0

                                                      Если честно я вообще не понял, что вы этим хотели сказать. Зачем вы процитировали моё сообщение. И причём тут автор (я не автор). Так же как непонятно причём тут Deno.

                                                        –2
                                                        ну с пониманием я тебе уже ничем не помогу, хоть фактуру разжую
                                                        ты написал сообщение я на него ответил (лол ваще в шоке как это можно не понять)
                                                        автор при том что у каждого высказывания есть свой автор, так вот о нем я высказался в своем ответе (причем тут автор? я не автор (что? (а ну ладно)))
                                                        дено тут при том что тут люди обсуждают то что тс статический, что мб было бы актуально года так полтора назад
                                                          +1
                                                          дено тут при том что тут люди обсуждают то что тс статический, что мб было бы актуально года так полтора назад

                                                          Вы уверены, что вы понимаете, что такое Deno? :) Это просто аналог nodeJS от его же автора. Да в нём используется TS по-умолчанию. Но, come on, runtime там всё тот же V8. Соответственно там нет никаких типов в runtime. Deno никак не меняет сущность TS. Просто транспилятор встроен в сам Deno. Поэтому он мало кому интересен. Кроме "революционной" идеи про url-import-ы он ничем не примечателен.


                                                          лол ваще в шоке как это можно не понять

                                                          Ну то что у вас трудности с формулировками я вижу :) JS не является моим первым языком. И единственным тоже не является. И нет, я писал на языках со статической системой типов. Я "курил" куда больше, чем ванильный JS. Подозреваю, что в цитате, на которую вы мне ответили, вы непонимаете значения половины пунктов :)

                                                            –4
                                                            мде печально тебе

                                                            продолжай думать что deno = nodejs и у тс нет рантайма. тут тебе уже бог только поможет

                                                            ХАХАХАХАХ ты продолжаешь думать что я говорил о тебе ЛМААААААААААО (кринж)

                                                            и да вынесу твой выс*р о том что я не знаю и половины якобы перечисленных «фишечек» тс
                                                            — Сигнатуры у методов — ЛЮБОЙ ооп язык
                                                            — алгебра типов — тут согласен такого нигде больше нету (блин просто не знаю что это такое и что такое юнион тип блин пощади)
                                                            — higher order rank polymorphism — ну тут вообще цирковое представление github.com/microsoft/TypeScript/issues/1213
                                                            просто в голос, мало того, что названо не так (higher order вместо kinded), так еще тс его не поддерживает. ты наверное думал что знаешь (intellec), но наверное тебе бы следовало заглянуть на вики за примером с хаскела (нет ты все знаешь не надо нееет)
                                                            — Рекурсивные типы — какие, если такие как в тс, тот тут ему аналогов нету из-за уже названной алгебры типов в которой это можно обильно применять, а если в объедках, то в вообще любом ооп япе (мб только не в с++, т.к. там это undefined behavior, но и там можно просто сначала объявить голый тип и дальше от этого писать)
                                                            — литералы — помянем автора
                                                            — перегрузка — аналогично

                                                            ставлю свечки за упокой в общем

                                                              +1
                                                              был неправ, действительно у дено нет тс рантайма
                                                                +1
                                                                Сигнатуры у методов — ЛЮБОЙ ооп язык

                                                                Почему именно ООП? Любой язык со статическими типами вообще. Как без них то? Писалось в контексте того что TS не может предоставить в runtime такие вещи


                                                                алгебра типов — тут согласен такого нигде больше нету

                                                                С чего это вдруг? Wiki пишет про несколько десятков языков, среди которых Scala и Haskell


                                                                higher order rank polymorphism — ну тут вообще цирковое представление

                                                                Насколько я могу судить в TS вообще нет Kind-ов. Отсюда и нет их полиморфизма. Issue по твоей ссылке я читал. Их там много. Каждый любитель FP заводит по одной, чтобы завести свои монады ;) На хабре есть даже неплохая статья про то как это можно обойти, если очень надо.


                                                                Но я не про -Kinded polymorphism, я про:


                                                                type A<T1> = <T2>(t1: T1, t2: T2) => <T3>(t3: T3) => [T1, T2, T3]

                                                                По сути про polymorphism за счёт generic-ов в рамках higher-order-functions. Но ок, раз ты смог нагуглить про Kind-ы поставим галочку ;)


                                                                — литералы — помянем автора

                                                                Literal Types


                                                                — перегрузка — аналогично

                                                                Overloaded Functions. Впрочем уверен что если ты слышал про ООП, то про них ты знаешь.


                                                                тут тебе уже бог только поможет
                                                                ставлю свечки за упокой в общем
                                                                помянем автора
                                                                с пониманием я тебе уже ничем не помогу, хоть фактуру разжую
                                                                ниче не курил

                                                                Хорошо, что к вам "на район" завезли интернет ;) TS всяко лучше, чем 228

                                            0
                                            Герои хреновы. Раньше firefox за неделю-две использования сжирал 2-3 гигабайта и падал. Сейчас же при запуске и открытии нескольких сайтов он отжирает эти самые 2-3 гигабайта. И это не только потому что он такой кривой, а потому что сайты стали немерено сложными. На ноутбуке с 16 гигабайтами RAM уже невозможно работать.
                                              0
                                              Странно, на своей десктопной «лисе» за несколько лет такого никогда не замечал.
                                              Браузер всегда укладывается в 1 Гб RAM.

                                              А вот с тем, что через несколько дней использования hibernate браузер начинает глючить, согласен полностью.
                                                0
                                                Никакой гибернации, комп работает месяцами без перезагрузок. Укладывается в гигабайт? Очень смешно. Он по настроению может запросто выжрать всю память, а ее установлено 64 гигабайта. Не всё, конечно, выделено для наглой рыжей морды, но жрёт он всё до чего может дотянуться. Иногда с какими-то версиями лучше, иногда совсем плохо. Очень сильно течет от просмотров видео.
                                                Впрочем, chrome не лучше.
                                                  +2
                                                  Очень сильно течет от просмотров видео.

                                                  Самое время задуматься о том, что у вас с кодеками понаверчено, если у вас от просмотра видео память течет.
                                                  Ну а если вы просто оставляете 50 вкладок с открытым HD видео — то и не обижайтесь, что только на буферы несколько гигабайт уйдет.

                                                    –1
                                                    Причем тут кодеки? Firefox все воспроизводит своими встроенными. 50 вкладок с видео я не оставляю. Вкладки открываются и закрываются, а общая занимаемая память растет со временем. В целом да, 50-100 вкладок открыто, но раньше на это хватало 2-3 гигабайт памяти, сейчас уходит в 10 раз больше. А всё из-за героев фронтендеров, которые увешивают все тоннами джаваскрипта, мегабайтными плохо сжатыми картинками, простынями css.
                                                      0
                                                      но раньше на это хватало 2-3 гигабайт памяти, сейчас уходит в 10 раз больше

                                                      В целях общего развития (моего), а в каком году было это "раньше"?

                                                        0
                                                        Это было во времена когда еще не было официальных 64-битных сборок firefox под windows. Соответственно, до firefox 43. Он вышел в конце 2015 года, 5 лет назад.
                                                          0

                                                          Интересно получается. В то время уже были SPA, и Angular и React уже набрали популярность, даже редизайн Хабра уже случился. По идее, с тех пор должно становиться только лучше, потому что весь этот молодой и не окрепший стек вышел на плато продуктивности, без новых JS-фреймворков каждую неделю

                                                            0
                                                            С тех времен веб для десктопов лучше не стал. Есть крен в сторону мобилок. Сейчас большинство сайтов можно без проблем смотреть с телефона. Но цена этого — деградация десктопной версии, которая превращается в мобильную. А это меню-гамбургер, хотя на десктопе не проблема сделать нормальное меню, огромные отступы между элементами, очень низкая плотность информации на экране. Скорость работы сайтов не выросла, а хорошо если не упала. В 2006-м году gmail через телефонный модем работал нисколько не медленнее нынешнего gmail через 100-мегабитное соединение. Оптимизации никакой ни у кого нет. Пару лет назад я пытался купить билеты на сайте s7 из Таиланда и мне это не удалось. Там с 5-7 шагов по покупке и они не догружались. Пришлось качать мобильное приложение. Дома смотрел, идут запросы каждую секунду с телеметрией. Герои, да.
                                              +2
                                              Компилятор может написать почти нуб, сама идея с деревьями виртуальных объектов проста, вопрос — какого качества будет этот компилятор.
                                              Дело в том, что компиляторов нужно не много и требования к качеству высоки
                                              Вебcайтов же напротив нужно очень много и требования к качеству — самые разные, отсюда — множество нубов во фронтенде и еще больше — в простой верстке и создании сайтов «из коробки».
                                                +4
                                                frontendlivesmatter
                                                  +3
                                                  «что, если случайные 5% моих SQL-запросов в Rails фейлятся». Начинающие фронтендеры не думают об этом, но более опытные — точно учитывают такие кейсы.

                                                  Постоянно сталкиваюсь с тем, что об этом забывают дизайнеры. Ну никак не могут усвоить и принять для себя классическую асинхронную триаду "waiting/success/failure". На картинках всегда только "success", остальных состояний нет, приходится пинать.

                                                    0

                                                    А ещё плейсхолдеры для пустых коллекций, да-да.

                                                  Only users with full accounts can post comments. Log in, please.