Rem зависит от настроек браузера. Если там размер шрифта выставлен не дефолтный в 16px, то размер в rem тоже будет другим, пропорционально шрифту, тогда как размер в пикселях можно изменить только зумом.
Очередная рекламная статья с высосаной из пальца проблемой. Ну да, есть у хуков пара ограничений — к слову говоря, конкретно их вызов на корневом уровне функций реальной проблемой становился лишь пару раз, — ну так, как говорится, не нравится — не используй.
Проблема с сравнением по ссылке тоже яйца выеденного не стоит: автор же сам разлагает config на url, skip и take, так в чём проблема их в массив зависимостей и засунуть? Вода сплошная для того, чтобы статья внушительнее выглядела.
Короче, маркетинговый буллшит. Переводчики, вы хоть что-нибудь более полезное отбирайте для перевода, это уже совсем треш ведь.
И что работать оно всё будет примерно с такой же скоростью, как и на JS.
… и даже медленнее, потому что WebAssembly пока что не умеет в прямую интеракцию с DOM, и там будут постоянные пробросы команд WA -> JS -> DOM и обратно.
Всё дело в обновлениях. Поддерживать приложение, основанное на CRA без eject очень легко — по сути, за весь билд отвечает команда CRA, а всё, что нужно девелоперу — просто обновиться.
Если же ты сделал eject, то проще держать все зависимости залоченными, потому что постоянно обновлять их (а зависимости, используемые CRA, выходят часто) — очень тяжело. Зато легко что-нибудь сломать в билде.
С другой стороны, держать зависимости без обновления — не очень хорошо, потому что за полгода набирается под три-четыре тысячи уязвимостей, которые желательно фиксить.
Вот поэтому и наблюдается тенденция, что девелоперы не любят делать eject, т.к. это создаёт кучу новой работы, а плюсов даёт, ну, сравнительно немного.
Как всегда, автор натягивает сову на глобус ради того, чтобы просто статью написать. По сути, единственная разумная причина — это первая, которая решается средствами, которые автор сам же и упоминает — customize-cra или craco (react-app-rewired вроде считается устаревшим со второй версии CRA).
Вторая причина — откровенно ниочём. Ну да, начинающий так будет думать. Но если начинающего ткнуть в настройку вебпака — он с криками убежит и больше никогда не вернётся. Так что надо будет — пойдёт и изучит, из чего CRA состоит и как его правильно настраивать. Рано или поздно это всегда придётся сделать, но я бы сказал, что лучше это делать после того, как ты поигрался со своим первым сайтом и решил углубиться.
А насчёт перегруженности возможностями вообще претензию не понял. Ладно бы эта перегруженность какое-то влияние на производительность/размер бандла/сложность настройки влияние оказывало, так нет же. На это окажут влияние, скорее, кривые руки при самостоятельной настройке вебпака.
А ещё можно нехило поджечь кресло, дебажа bin/start.js автора, куда он напихал просто неведомую хрень. Особенно уровень неведомого будет зашкаливать для начинающего, о котором автор, вроде бы, заботится. И эту хрень поддерживать он, в отличие от авторов CRA, конечно же, не будет, так что любые изменения и хотелки придётся вносить самостоятельно. За это автора, кстати, неплохо пропесочили в комментах исходной статьи.
Треш, короче. Конечно, разбираться в том, из чего CRA состоит — полезно и даже необходимо. Но отказываться от инструмента при этом — совершенно необязательно.
Почему бы им просто не брать арендную плату за возможность размещать свои приложения? По сути, эти сторы — не более чем хостинги. Вот пусть и работают по принципу хостинга или арендодателя — берут фиксированную арендную плату каждый определённый промежуток времени.
А то, я думаю, продавцы на рынке быстро бы возмутились, вздумай хозяин помещения рынка брать с них процент от прибыли...
Есть ли разница, какие именно мотивы сломают хребет монополии? В общем-то, экономика конкуренции так и работает: одни корыстные интересы встречаются с другими корыстными интересами, и на стыке радуется потребитель.
Нет таких, сейчас веб-компоненты не поддаются SSR. Есть некоторые наработки по гидратации в lit-html, есть @skatejs/ssr, но, насколько я знаю, это всё пока на ранних экспериментальных стадиях.
Сейчас всё упирается в императивность создания Shadow Root. Есть пропозал на его декларативность, но он пока не особо куда-то движется.
Хмм, в первый раз слышу такую точку зрения, если честно. И, пожалуй, с ней не соглашусь. Начиная с того, что у tsc невозможно выключить проверку типов при компиляции (ну, по крайней мере было невозможно на тот момент, когда я проверял в последний раз) и заканчивая тем, что tsc не поддерживает плагины, а значит огромные возможности по трансформации кода при компиляции оказываются отрезаны. Я бы сказал, что, скорее, пользоваться tsc — анахронизм с тех пор, как Babel ввёл поддержку Typescript.
P.S. Я не один так считаю, кстати. Самый популярный на данный момент стартер — create-react-app, — использует для трансформации Typescript именно Babel, а не tsc.
После компиляции ts в js, вы продолжаете работать с js. Что-то изменять, добавлять, подключать какие-то либы и тд. На этом этапе тайпскрипта уже нет, остался лишь js, который не дает гарантий.
Нет, я всё это делаю на этапе работы с TS. Все библиотеки, все изменения происходят лишь в тайпскрипт-коде. Затем управление отдаётся бандлеру — webpack или rollup, — который уже компилирует, модифицирует, минифицирует конечный вариант. В общем-то, всё то же самое, что делает, например, LLVM. Разве кто-то сейчас делает по-другому? Зачем усложнять кодовую базу, влезая руками в скомпилированный JS, когда у тебя сорцы на TS? Поэтому-то TS и сравнивают с Rust — оба этих языка являются в первую очередь статическими анализаторами, которые дают гарантии именно на этапе компиляции. Да, ввиду изначально корректной архитектуры Rust даёт больше гарантий, в то время как TS создавался поверх уже существующего JS, что накладывает свой отпечаток. Но это не значит, что TS ничего не привносит — ещё как. Он делает то, что в Rust является одним из краеугольных камней дизайна языка: делает неявное явным. Explicit лучше чем implicit.
Или, к примеру, когда вам нужно будет что-то дебажить — вы будете дебажить js (либо увеличивать размер бандла через доп инфу в соурс мапах). Всё это означает двойную работу.
Я как-то дебажил Rust через GDB, и скажу вам, source maps или JavaScript — это очень удобно в сравнении :D
А Babel весьма быстро работает, что с Jest, что в вебпаке. В принципе, логично, с учётом того, что всё, что он делает для TS — просто вырезает типы из AST. А проверку правильности типов можно и отдельно от компиляции делать.
Вы удивитесь, но Typescript тоже даёт определённые гарантии на этапе компиляции. Разница лишь в том, что компилируется он не в машинные коды или байткод, а в JavaScript.
Спасибо за статью, чрезвычайно полезно! Единственное, насчёт Subaru: всё-таки в оригинальном японском варианте ударение будет на второй слог. Точнее, там будет подъём тона на два последних слога, но для русского уха это звучит практически как ударение. Поэтому по-японски правильно будет суба́ру.
Rem зависит от настроек браузера. Если там размер шрифта выставлен не дефолтный в 16px, то размер в rem тоже будет другим, пропорционально шрифту, тогда как размер в пикселях можно изменить только зумом.
Очередная рекламная статья с высосаной из пальца проблемой. Ну да, есть у хуков пара ограничений — к слову говоря, конкретно их вызов на корневом уровне функций реальной проблемой становился лишь пару раз, — ну так, как говорится, не нравится — не используй.
Проблема с сравнением по ссылке тоже яйца выеденного не стоит: автор же сам разлагает config на
url,skipиtake, так в чём проблема их в массив зависимостей и засунуть? Вода сплошная для того, чтобы статья внушительнее выглядела.Короче, маркетинговый буллшит. Переводчики, вы хоть что-нибудь более полезное отбирайте для перевода, это уже совсем треш ведь.
Ну, IE6-то умер...
… и даже медленнее, потому что WebAssembly пока что не умеет в прямую интеракцию с DOM, и там будут постоянные пробросы команд WA -> JS -> DOM и обратно.
Тоже об этом подумал. Тот момент, когда автору ну очень хочется написать статью, а разбираться в матчасти лень.
Всё дело в обновлениях. Поддерживать приложение, основанное на CRA без eject очень легко — по сути, за весь билд отвечает команда CRA, а всё, что нужно девелоперу — просто обновиться.
Если же ты сделал eject, то проще держать все зависимости залоченными, потому что постоянно обновлять их (а зависимости, используемые CRA, выходят часто) — очень тяжело. Зато легко что-нибудь сломать в билде.
С другой стороны, держать зависимости без обновления — не очень хорошо, потому что за полгода набирается под три-четыре тысячи уязвимостей, которые желательно фиксить.
Вот поэтому и наблюдается тенденция, что девелоперы не любят делать eject, т.к. это создаёт кучу новой работы, а плюсов даёт, ну, сравнительно немного.
iOS-версия тоже релизнулась.
Как всегда, автор натягивает сову на глобус ради того, чтобы просто статью написать. По сути, единственная разумная причина — это первая, которая решается средствами, которые автор сам же и упоминает — customize-cra или craco (react-app-rewired вроде считается устаревшим со второй версии CRA).
Вторая причина — откровенно ниочём. Ну да, начинающий так будет думать. Но если начинающего ткнуть в настройку вебпака — он с криками убежит и больше никогда не вернётся. Так что надо будет — пойдёт и изучит, из чего CRA состоит и как его правильно настраивать. Рано или поздно это всегда придётся сделать, но я бы сказал, что лучше это делать после того, как ты поигрался со своим первым сайтом и решил углубиться.
А насчёт перегруженности возможностями вообще претензию не понял. Ладно бы эта перегруженность какое-то влияние на производительность/размер бандла/сложность настройки влияние оказывало, так нет же. На это окажут влияние, скорее, кривые руки при самостоятельной настройке вебпака.
А ещё можно нехило поджечь кресло, дебажа
bin/start.jsавтора, куда он напихал просто неведомую хрень. Особенно уровень неведомого будет зашкаливать для начинающего, о котором автор, вроде бы, заботится. И эту хрень поддерживать он, в отличие от авторов CRA, конечно же, не будет, так что любые изменения и хотелки придётся вносить самостоятельно. За это автора, кстати, неплохо пропесочили в комментах исходной статьи.Треш, короче. Конечно, разбираться в том, из чего CRA состоит — полезно и даже необходимо. Но отказываться от инструмента при этом — совершенно необязательно.
Лучше react-window, она почти в 10 раз меньше и во столько же быстрее. Написан автором react-virtualized как переосмысление виртуализации для Реакта.
А ещё есть такая штука как uni-virtualizer от Polymer, но она пока ещё в разработке, правда.
Почему бы им просто не брать арендную плату за возможность размещать свои приложения? По сути, эти сторы — не более чем хостинги. Вот пусть и работают по принципу хостинга или арендодателя — берут фиксированную арендную плату каждый определённый промежуток времени.
А то, я думаю, продавцы на рынке быстро бы возмутились, вздумай хозяин помещения рынка брать с них процент от прибыли...
Есть ли разница, какие именно мотивы сломают хребет монополии? В общем-то, экономика конкуренции так и работает: одни корыстные интересы встречаются с другими корыстными интересами, и на стыке радуется потребитель.
Нет таких, сейчас веб-компоненты не поддаются SSR. Есть некоторые наработки по гидратации в
lit-html, есть@skatejs/ssr, но, насколько я знаю, это всё пока на ранних экспериментальных стадиях.Сейчас всё упирается в императивность создания Shadow Root. Есть пропозал на его декларативность, но он пока не особо куда-то движется.
А есть возможность раскрыть все сокращения? Я минуты три пытался понять, что такое "Во-1" и "Во-2". Довольно сильно выбивает из потока чтения.
Хмм, в первый раз слышу такую точку зрения, если честно. И, пожалуй, с ней не соглашусь. Начиная с того, что у tsc невозможно выключить проверку типов при компиляции (ну, по крайней мере было невозможно на тот момент, когда я проверял в последний раз) и заканчивая тем, что tsc не поддерживает плагины, а значит огромные возможности по трансформации кода при компиляции оказываются отрезаны. Я бы сказал, что, скорее, пользоваться tsc — анахронизм с тех пор, как Babel ввёл поддержку Typescript.
P.S. Я не один так считаю, кстати. Самый популярный на данный момент стартер — create-react-app, — использует для трансформации Typescript именно Babel, а не tsc.
Нет, я всё это делаю на этапе работы с TS. Все библиотеки, все изменения происходят лишь в тайпскрипт-коде. Затем управление отдаётся бандлеру — webpack или rollup, — который уже компилирует, модифицирует, минифицирует конечный вариант. В общем-то, всё то же самое, что делает, например, LLVM. Разве кто-то сейчас делает по-другому? Зачем усложнять кодовую базу, влезая руками в скомпилированный JS, когда у тебя сорцы на TS? Поэтому-то TS и сравнивают с Rust — оба этих языка являются в первую очередь статическими анализаторами, которые дают гарантии именно на этапе компиляции. Да, ввиду изначально корректной архитектуры Rust даёт больше гарантий, в то время как TS создавался поверх уже существующего JS, что накладывает свой отпечаток. Но это не значит, что TS ничего не привносит — ещё как. Он делает то, что в Rust является одним из краеугольных камней дизайна языка: делает неявное явным. Explicit лучше чем implicit.
Я как-то дебажил Rust через GDB, и скажу вам, source maps или JavaScript — это очень удобно в сравнении :D
А Babel весьма быстро работает, что с Jest, что в вебпаке. В принципе, логично, с учётом того, что всё, что он делает для TS — просто вырезает типы из AST. А проверку правильности типов можно и отдельно от компиляции делать.
Вы удивитесь, но Typescript тоже даёт определённые гарантии на этапе компиляции. Разница лишь в том, что компилируется он не в машинные коды или байткод, а в JavaScript.
А что насчёт дебага? Допустим, если вот этот
fetchвx-initупал по какой-то причине, как его отыскать; поставить туда брейкпоинт?А эффективно ли обрабатывать перчатки антисептиком? Во имя уменьшения одноразовости, так сказать.
Спасибо за статью, чрезвычайно полезно! Единственное, насчёт Subaru: всё-таки в оригинальном японском варианте ударение будет на второй слог. Точнее, там будет подъём тона на два последних слога, но для русского уха это звучит практически как ударение. Поэтому по-японски правильно будет суба́ру.