Честно говоря мне непонятна ниша промежуточного приложения в данном случае.
Что можно показать до загрузки самого приложения? Ну, лоадер можно показать, пару текстовых баннеров, чтоб пользователю не было скучно. Форму обратной связи может быть, на случай если не загрузилось? Да и всё. Это не настолько сложный функционал чтоб тянуть какой бы то ни было фреймворк или библиотеку, уместится в index.html. Всё что сложнее, это уже с роутером, а роутер - это уже дублирование логики с той, что в основном приложении (особенно при использовании разных фреймворков).
То есть, это может быть оправдано при использовании Vue в основном приложении, но вы пишете про React.
Не поймите неправильно, мне абсолютно близка и понятна идея прогрессивного рендеринга, как на картинке из первой статьи, но в случае реакта это скорее достигается lazy-компонентами и загрузкой чанками. А вот зачем рендерить лоадер с помощью petite-vue, до загрузки первого чанка реакта - мне непонятно.
В целом, если объективно, ваш опыт вообще никак не отличается от любой другой ОС. Любой пользователь привыкший к чему-то будет испытывать массу неудобств, пока не сможет настроить похожее поведение на новой ОС. Но это не отменяет того, что для неискушенного пользователя MacOS предоставляет довольно неплохой пресет.
Мой опыт переключения по CapsLock - это раскладка Мефодица (https://github.com/epsimatic/mefodica-birmana) с некоторыми твиками раскладки через Ukelele (http://scripts.sil.org/ukelele). Суть мефодицы в том, что используется два языка в одной раскладке, но находятся в разных регистрах, и CapsLock просто переключает регистр.
Ну скажем, с гридами в области решения hero секции подход интересный. Но вот `display: contents` - это и правда неочевидная фича и костыль. Зато стильно-модно-молодёжно.
Достаточно убрать `__content` вообще и использовать `order` as-is.
Вы излишне драматизируете. Звучит как "давайте гулять по всем полям, но знакомый моего знакомого рассказывал, что на одном из них может быть зарыта неразорвавшаяся бомба со времён войны, но это не точно. А ещё её можно вовремя заметить, позвать сапёров и они обезвредят."
заявлять о доказанной безопасности, якобы потому что вколено миллиарды доз
Речь только про статистику, что статистически собрано сильно больше данных, чем с тех 1000 человек в описываемой в статье компании. Даже если там всё было с нарушениями, постфактум это уже ничего не значит.
А где я говорил про pnpm? Мой комментарий только относительно переиспользования кода, переиспользования хелперов, без которых код часто ломается (i.e. isObject/isArray) и использование одиночных пакетов vs lodash.
вместо того, чтобы написать 3 строчки кода, люди непонятно зачем тянут в проект зависимость
Тут есть нюанс. Ну мы с вами напишем корректный isObject в три строчки сходу, и всё будет ок. Но я предпочту чтоб джуны в моей команде использовали lodash вместо того, чтоб писать свои сравнения, которые потом что-то сломают.
Да, это решается code-review (но зачем?). Да, можно открыть исходники lodash и скопировать имплементацию. Но чем это отличается от запекания текущей версии lodash в package-lock и использовании его как пакета?
Защита от удаления пакета? Теоретически возможно, но маловероятно.
Защита от того, что используемый код изменится в будущих минорных версиях? Используйте точные версии в package.json и package-lock.
Защита что кто-то сломает npm репозиторий и поменяет текущие версии в нём? Всё может быть, но это уже паранойя.
Строго говоря в результирующий бандл войдёт только index.js. Но вообще да, для этого есть тот же lodash который при сборке тем же вебпаком может не включать в бандл тот код, функции которого не были использованы (я полагаю, именно для этого созданы такие пакеты-одиночки).
Хотя если во всём проекте из того же lodash вы используете только isObject, то есть ли в этом смысл? Не всё так просто и однозначно, об этом должен думать человек добавляющий пакеты в проект.
Погодите, но регулярные выражения были созданы чтоб простыню кода по парсингу скомкать в компактную строку. Её нет никакого смысла раскрывать обратно, вместо этого вы могли бы взять аналогичную простыню кода и попробовать её упростить до, например, упомянутого выше, https://github.com/sprache/Sprache.
4 - ответ для "сколько еще, минимум, таких элементов надо докупить". Я вот сразу подумал про бесконечное, потому что "более длинную" прочитал как "максимально длинную".
Но да, как уже указали, пропущено ещё одно слово - "кольцевую".
А вы видимо не совсем понимаете, что дело не в сторипоинтах? Дело в отношении автора к читателям вида "я вот заморочился, сделал кое-какой перевод, читайте молча, внимайте и скажите спасибо что я вообще заморочился".
Если бы автор написал "да, я знаю, перевод дерьмо, пользовался гуглтранслейтом, спасибо за правки, сейчас всё поправлю" и "да, я подумал, что мой вариант перевода лучше, но я вижу что большинство так не думает, оставлю сторипоинтами" - ничего бы и не было.
Особенно это выглядит забавно с, цитирую из статьи
стендапов и уточнений бэклога, до ретроспектив — ритуалах «самосовершенствования», основанных на спринтах.
А вот "сторипоинты" не угодили.
Сторипоинт - это устоявшийся термин, нравится вам это или нет. Навязывать свой термин с такой подачей как у автора, сопровождая это кичиньем знания английского и родного русского (с переводом через гугл-транслейт, ага) - ну, эм… глупо просто.
не могу не отметить некоторую иронию в том, что когда в дискуссии
Ну, дискуссия - это когда высказывают разные точки зрения. Когда все соглашаются с одной точкой - это уже не дискуссия ;)
Касательно основного вопроса - большинство (ну прям почти все из тех, с кем я общаюсь) из тех, кто переехал сталкиваются с основной проблемой - сложность ассимиляции. И даже после нескольких лет за границей всё ещё страдают от того, как там всё по другому, но уже не могут ни себе ни другим признаться что сделали неправильный выбор мигрировав, в основном рассказывая на публику как там всё хорошо.
Конечно, можно молча перестрадать, чтоб детям было хорошо, но всегда ли надо жертвовать собой ради этого?
Если бы поменять страну было так же просто как пиццерию - тогда возможно что-то бы и изменилось само по себе путём конкуренции между государствами "за потребителя". А так - каждое отдельное государство монополист, и других средств что-то поменять кроме как изнутри чаще всего нет.
Честно говоря мне непонятна ниша промежуточного приложения в данном случае.
Что можно показать до загрузки самого приложения? Ну, лоадер можно показать, пару текстовых баннеров, чтоб пользователю не было скучно. Форму обратной связи может быть, на случай если не загрузилось? Да и всё. Это не настолько сложный функционал чтоб тянуть какой бы то ни было фреймворк или библиотеку, уместится в index.html. Всё что сложнее, это уже с роутером, а роутер - это уже дублирование логики с той, что в основном приложении (особенно при использовании разных фреймворков).
То есть, это может быть оправдано при использовании Vue в основном приложении, но вы пишете про React.
Не поймите неправильно, мне абсолютно близка и понятна идея прогрессивного рендеринга, как на картинке из первой статьи, но в случае реакта это скорее достигается lazy-компонентами и загрузкой чанками. А вот зачем рендерить лоадер с помощью petite-vue, до загрузки первого чанка реакта - мне непонятно.
Это на фуллстека или для фронта? Если для фронта, то это прям как-то странно.
В целом, если объективно, ваш опыт вообще никак не отличается от любой другой ОС. Любой пользователь привыкший к чему-то будет испытывать массу неудобств, пока не сможет настроить похожее поведение на новой ОС. Но это не отменяет того, что для неискушенного пользователя MacOS предоставляет довольно неплохой пресет.
Мой опыт переключения по CapsLock - это раскладка Мефодица (https://github.com/epsimatic/mefodica-birmana) с некоторыми твиками раскладки через Ukelele (http://scripts.sil.org/ukelele). Суть мефодицы в том, что используется два языка в одной раскладке, но находятся в разных регистрах, и CapsLock просто переключает регистр.
Аргументируйте. Что значит непригоден? Непригоден - это невозможно, не поддерживает.
В статье речь именно про переключение между окнами приложения. Ваш кейс интересный, но довольно узкий и не описан в статье.
Ну скажем, с гридами в области решения hero секции подход интересный. Но вот `display: contents` - это и правда неочевидная фича и костыль. Зато стильно-модно-молодёжно.
Достаточно убрать `__content` вообще и использовать `order` as-is.
Вы излишне драматизируете. Звучит как "давайте гулять по всем полям, но знакомый моего знакомого рассказывал, что на одном из них может быть зарыта неразорвавшаяся бомба со времён войны, но это не точно. А ещё её можно вовремя заметить, позвать сапёров и они обезвредят."
Да, и для этого стоит использовать точные версии (без `^`) и package-lock, так как malware попадёт только в новые версии, но не в существующие.
Речь только про статистику, что статистически собрано сильно больше данных, чем с тех 1000 человек в описываемой в статье компании. Даже если там всё было с нарушениями, постфактум это уже ничего не значит.
А где я говорил про pnpm? Мой комментарий только относительно переиспользования кода, переиспользования хелперов, без которых код часто ломается (i.e. isObject/isArray) и использование одиночных пакетов vs lodash.
Тут есть нюанс. Ну мы с вами напишем корректный isObject в три строчки сходу, и всё будет ок. Но я предпочту чтоб джуны в моей команде использовали lodash вместо того, чтоб писать свои сравнения, которые потом что-то сломают.
Да, это решается code-review (но зачем?). Да, можно открыть исходники lodash и скопировать имплементацию. Но чем это отличается от запекания текущей версии lodash в package-lock и использовании его как пакета?
Защита от удаления пакета? Теоретически возможно, но маловероятно.
Защита от того, что используемый код изменится в будущих минорных версиях? Используйте точные версии в package.json и package-lock.
Защита что кто-то сломает npm репозиторий и поменяет текущие версии в нём? Всё может быть, но это уже паранойя.
Строго говоря в результирующий бандл войдёт только index.js. Но вообще да, для этого есть тот же lodash который при сборке тем же вебпаком может не включать в бандл тот код, функции которого не были использованы (я полагаю, именно для этого созданы такие пакеты-одиночки).
Хотя если во всём проекте из того же lodash вы используете только isObject, то есть ли в этом смысл? Не всё так просто и однозначно, об этом должен думать человек добавляющий пакеты в проект.
Погодите, но регулярные выражения были созданы чтоб простыню кода по парсингу скомкать в компактную строку. Её нет никакого смысла раскрывать обратно, вместо этого вы могли бы взять аналогичную простыню кода и попробовать её упростить до, например, упомянутого выше, https://github.com/sprache/Sprache.
Буквально это может значить, что это не маловероятный объект, но раньше у нас не было возможности их наблюдать (а они были и будут).
Левшам насрать, извините, на все эти правила, у них банальные ножницы не работают
Почему тогда не 8?
4 - ответ для "сколько еще, минимум, таких элементов надо докупить". Я вот сразу подумал про бесконечное, потому что "более длинную" прочитал как "максимально длинную".
Но да, как уже указали, пропущено ещё одно слово - "кольцевую".
А вы видимо не совсем понимаете, что дело не в сторипоинтах? Дело в отношении автора к читателям вида "я вот заморочился, сделал кое-какой перевод, читайте молча, внимайте и скажите спасибо что я вообще заморочился".
Если бы автор написал "да, я знаю, перевод дерьмо, пользовался гуглтранслейтом, спасибо за правки, сейчас всё поправлю" и "да, я подумал, что мой вариант перевода лучше, но я вижу что большинство так не думает, оставлю сторипоинтами" - ничего бы и не было.
Особенно это выглядит забавно с, цитирую из статьи
А вот "сторипоинты" не угодили.
Сторипоинт - это устоявшийся термин, нравится вам это или нет. Навязывать свой термин с такой подачей как у автора, сопровождая это кичиньем знания английского и родного русского (с переводом через гугл-транслейт, ага) - ну, эм… глупо просто.
С одной стороны да, с другой - на этот случай предсмотрен единоразовый резет кармы.
В том, что сторипоинты не дни? У вас они могли быть днями. У других это абстрактное понятие сложности, которое с днями не коррелирует.
Ну, дискуссия - это когда высказывают разные точки зрения. Когда все соглашаются с одной точкой - это уже не дискуссия ;)
Касательно основного вопроса - большинство (ну прям почти все из тех, с кем я общаюсь) из тех, кто переехал сталкиваются с основной проблемой - сложность ассимиляции. И даже после нескольких лет за границей всё ещё страдают от того, как там всё по другому, но уже не могут ни себе ни другим признаться что сделали неправильный выбор мигрировав, в основном рассказывая на публику как там всё хорошо.
Конечно, можно молча перестрадать, чтоб детям было хорошо, но всегда ли надо жертвовать собой ради этого?
Хорошо там где нас нет.
Если бы поменять страну было так же просто как пиццерию - тогда возможно что-то бы и изменилось само по себе путём конкуренции между государствами "за потребителя". А так - каждое отдельное государство монополист, и других средств что-то поменять кроме как изнутри чаще всего нет.