Согласен, что многие из этих вопрос борщ и вероятность того, что вы когда-то реально с ними столкнетесь в бою мала, но их спрашивают и нужно быть готовым, что и этот борщ вас могут спросить. А так да, отвечать на вопросы и решать алгосы, которые никогда в жизни не пригодятся - отстой.
Если создать строку через конструктор, new String(''), то она явно будет обьектом, кринжовый вопрос. А вообще в JS есть такая история как boxing/unboxing и все примитивы оборачиваются в объекты, для того чтобы мы могли использовать у них методы, например такие как toLowerCase() и тд. Так что вопрос может быть в каком-то смысле был на знание этого, просто странно сформулирован. Вот тут можно почитать - тык.
Насколько я знаю, JS хранит массив в памяти как объект с числовыми ключами, ну и тогда ответ на второй вопрос следует из первого - нет, зависимости нет, так как это объект, а в объекте можно хранить все.
Да, тут немного сложно, я применял ее для кэширования картинок, которые появляются во viewport, чтобы пользователь при повторном заходе сразу видела красивую картинку и для кастомной fallback страницы при отсутствии сети. Еще насколько я знаю, можно делать некое проксирование запросов, что тоже бывает полезно.
Big O — нотация, которая позволяет определить верхнюю границу скорости работы алгоритма. Она описывает отношение входных данных ко времени, за которое алгоритм сможет их обработать.
Это тоже не совсем верно, Big O - асимптотическая сложность, которая описывает верхнюю границу сложности алгоритма при увеличении размера входных данных, или как рост размера входных данных влияет на количество шагов. Но никак не отношение данных ко времени.
Раз уж вы приводите пример и устойчивых и неустойчивых сортировок, то было бы здорово привести пример устойчивой сортировки за O(n * log(n)), потому что про них тоже довольно часто спрашивают, например Merge Sort хорошо бы подошел - https://ru.wikipedia.org/wiki/Сортировка_слиянием.
Еще думаю у Quick Sort было бы полезно показать худший случай, где сортировка за O(n ** 2), раз вы его упоминаете.
Оно срабатывает не только для запросов из JavaScript, оно срабатывает для всех запросов страниц/статических файлов/скриптов и тд.
Да, можно повесить обработчик и добавить что-то в headers каждого запроса, но есть ограничения. Если интересно, можно почитать тут подробнее, грамотный ответ на ваш вопрос - https://qna.habr.com/q/553673
Согласен, что Service Workers стоят внимания, но мне показалось запихать в одну статью Shared/Dedicated/Service Workers будет слишком, в плане, материала по Service Workers точно наберется на еще одну статью, со всей его специфичностью.
Да и про Service Worker почти все знают, так как он на слуху, а вот с Shared/Dedicated Workers как по мне люди не очень знакомы.
Dedicated Workers - 97%, все поддерживает, кроме Opera Mini(Даже IE в последних версиях карл) Shared Workers - 53%, тут хуже, с десктопными браузерами все нормально, до мобильных еще не добралась технология https://caniuse.com/?search=web workers
Dedicated можно спокойно юзать, Shared в целом тоже можно использовать только на Desktop, особенно если основной пользователь это пользователь именно с Desktop'a
Думаю, что вложенность все-таки не настолько большая, чтобы она могла разрушать инкапсуляцию, если так, то скорее всего у вас уже какой-то overengineering и компоненты в 3 строки) ИМХО
Drilling CSS переменных вниз звучит очень страшно и уж точно ломает масштабируемость)) ИМХО
А по-поводу, @ container, очевидно, что они скоро будут активно использоваться, но думаю, что tailwind их внедрит как только у них появится обширная поддержка(сейчас это 86%, что не так много), а если уж прямо сейчас хочется, то по первой ссылке в гугле с 600 звездами на github есть либа - https://github.com/tailwindlabs/tailwindcss-container-queries
А в чем тогда преимущество tailwind если вы все равно длинные стили выносите в отдельный от вашего компонента объект с @apply?
Преимущество проявляется когда вы пишете максимально атомарные компоненты, с небольшим количеством стилей, а также когда вы пишете адаптив для 4 устройств например(вы вместо того, чтобы писать огромную вложенность из @ media, просто пишете sm: xl: lg:, etc...), также темизация элементарна. Если все ваши компоненты огромные и у каждого элемента по 20-30 стилей, пожалуй, tailwind не очень.
И забыли еще один большой минус tailwind - у него свое понятие размеров и цветов, надо запоминать что означают все эти bg-red-400 и mr-10. Если бы 10 означало 10px, это бы еще понятно, но 10 - это что-то относительно rem. Очень странная логика у tailwind.
Мало кто пользуется именно этими значениями, обычно они переопределяются кастомным конфигом и делаются понятными в вашей команде, вместо bg-red-400 -> bg-red-base например, mr-10 -> mr-40 можно превратить, если вам так будет удобнее, да и к тому что одна единица 4px довольно быстро привыкаешь
Думаю, вы немного не поняли, в каком контексте я показал этот пример, тут суть была не в том, что написано в этих стилях, в этом примере это играет второстепенную роль, первостепенно я хотел показать, что можно избежать спагетти кода в HTML(огромной награмажденности классов), на который многие ошибочно указывают при споре насчет того, насколько Tailwind захламляет разметку. Если уж говорить про сам код, то это просто какое-то мессиво из непонятных переменных, приправленное не всегда логичной организацией и уместными свойствами и в целом какой-то правильно организацией кода в примере не пахнет.
Думаю это не проблема конкретно Tailwind, я бы больше сказал, что это проблема всего IT, курсы аля "Как стать middle разработчиком за 3 месяца", гораздо больше влияют на то, что люди меньше изучают базу и сразу лезут во фреймворки(потому что на курсе сказали, что знание всего остального не обязательно и можно загуглить)/другие инструменты, которые являются надстройкой над чем-то базовым + изобилие готовых решений, которыми все пользуются тоже этому способствует. Однако я не считаю, что Tailwind таковым является, мне кажется, что Tailwind больше про альтернативный подход, а не про готовые решения, он явно никак не влияет на понимание общего flow разработки/работы с дизайнером и тд
Согласен, что там можно было сделать на порядок больше абстракций и сделать код еще чище и элегантнее, но тут скорее преследовалась цель показать разницу между количество кода с использованием Tailwind и CSS в целом. При наличии макета и цели сделать идеально, можно было сделать красиво. Да и главная цель была продемонстрировать @ apply в действии и что с помощью него можно делать красиво
Тут я не согласен, потому что Tailwind почти не предоставляет готовых решений, за исключением пары анимаций, он просто дает нам классы нотации эквивалентных CSS, которые мы можем использовать (flex -> display: flex, justify-between -> justify-content: space-between). Возможно это утверждение справедливо в отношении условного Bootstrap, где есть классы, являющиеся готовыми решениями. Tailwind скорее не про это. Как я и написал раньше для того чтобы писать на Tailwind нужно также понимать все эти CSS свойства, потому что ты используешь те же CSS свойства просто в другой нотации. А у меня наоборот опыт такой, что люди которые пишут на Tailwind попробовали уже кучу разных инструментов для стилизации от БЭМ до CSS Modules, CSS in JS, etc... и выбрали именно Tailwind, потому что он им удобен.
Да, как я и написал в статье, код специфичен(мягко говоря), просто очень часто видел подобные скрины в подтверждение того, что tailwind ужасно засоряет разметку и из-за этого не может нормально масштабироваться на крупных проектах
Там ссылка на refactoring.guru, он почему-то не работает без впнки, попробуй с впн зайти
Согласен, что многие из этих вопрос борщ и вероятность того, что вы когда-то реально с ними столкнетесь в бою мала, но их спрашивают и нужно быть готовым, что и этот борщ вас могут спросить. А так да, отвечать на вопросы и решать алгосы, которые никогда в жизни не пригодятся - отстой.
Да, вы правы, за это отвечает движок
Так никто не делает, потому что это не рекомендуется делать стандартами, эти конструкторы, вроде как, для внутреннего использования.
Если создать строку через конструктор, new String(''), то она явно будет обьектом, кринжовый вопрос.
А вообще в JS есть такая история как boxing/unboxing и все примитивы оборачиваются в объекты, для того чтобы мы могли использовать у них методы, например такие как toLowerCase() и тд. Так что вопрос может быть в каком-то смысле был на знание этого, просто странно сформулирован. Вот тут можно почитать - тык.
Насколько я знаю, JS хранит массив в памяти как объект с числовыми ключами, ну и тогда ответ на второй вопрос следует из первого - нет, зависимости нет, так как это объект, а в объекте можно хранить все.
Да, тут немного сложно, я применял ее для кэширования картинок, которые появляются во viewport, чтобы пользователь при повторном заходе сразу видела красивую картинку и для кастомной fallback страницы при отсутствии сети. Еще насколько я знаю, можно делать некое проксирование запросов, что тоже бывает полезно.
Это тоже не совсем верно, Big O - асимптотическая сложность, которая описывает верхнюю границу сложности алгоритма при увеличении размера входных данных, или как рост размера входных данных влияет на количество шагов. Но никак не отношение данных ко времени.
Раз уж вы приводите пример и устойчивых и неустойчивых сортировок, то было бы здорово привести пример устойчивой сортировки за O(n * log(n)), потому что про них тоже довольно часто спрашивают, например Merge Sort хорошо бы подошел - https://ru.wikipedia.org/wiki/Сортировка_слиянием.
Еще думаю у Quick Sort было бы полезно показать худший случай, где сортировка за O(n ** 2), раз вы его упоминаете.
Оно срабатывает не только для запросов из JavaScript, оно срабатывает для всех запросов страниц/статических файлов/скриптов и тд.
Да, можно повесить обработчик и добавить что-то в headers каждого запроса, но есть ограничения. Если интересно, можно почитать тут подробнее, грамотный ответ на ваш вопрос - https://qna.habr.com/q/553673
Согласен, что Service Workers стоят внимания, но мне показалось запихать в одну статью Shared/Dedicated/Service Workers будет слишком, в плане, материала по Service Workers точно наберется на еще одну статью, со всей его специфичностью.
Да и про Service Worker почти все знают, так как он на слуху, а вот с Shared/Dedicated Workers как по мне люди не очень знакомы.
Dedicated Workers - 97%, все поддерживает, кроме Opera Mini(Даже IE в последних версиях карл)
Shared Workers - 53%, тут хуже, с десктопными браузерами все нормально, до мобильных еще не добралась технология
https://caniuse.com/?search=web workers
Dedicated можно спокойно юзать, Shared в целом тоже можно использовать только на Desktop, особенно если основной пользователь это пользователь именно с Desktop'a
Идеальный ответ!
Думаю, что вложенность все-таки не настолько большая, чтобы она могла разрушать инкапсуляцию, если так, то скорее всего у вас уже какой-то overengineering и компоненты в 3 строки) ИМХО
Drilling CSS переменных вниз звучит очень страшно и уж точно ломает масштабируемость)) ИМХО
А по-поводу, @ container, очевидно, что они скоро будут активно использоваться, но думаю, что tailwind их внедрит как только у них появится обширная поддержка(сейчас это 86%, что не так много), а если уж прямо сейчас хочется, то по первой ссылке в гугле с 600 звездами на github есть либа - https://github.com/tailwindlabs/tailwindcss-container-queries
Преимущество проявляется когда вы пишете максимально атомарные компоненты, с небольшим количеством стилей, а также когда вы пишете адаптив для 4 устройств например(вы вместо того, чтобы писать огромную вложенность из @ media, просто пишете sm: xl: lg:, etc...), также темизация элементарна. Если все ваши компоненты огромные и у каждого элемента по 20-30 стилей, пожалуй, tailwind не очень.
Мало кто пользуется именно этими значениями, обычно они переопределяются кастомным конфигом и делаются понятными в вашей команде, вместо bg-red-400 -> bg-red-base например, mr-10 -> mr-40 можно превратить, если вам так будет удобнее, да и к тому что одна единица 4px довольно быстро привыкаешь
Думаю, вы немного не поняли, в каком контексте я показал этот пример, тут суть была не в том, что написано в этих стилях, в этом примере это играет второстепенную роль, первостепенно я хотел показать, что можно избежать спагетти кода в HTML(огромной награмажденности классов), на который многие ошибочно указывают при споре насчет того, насколько Tailwind захламляет разметку.
Если уж говорить про сам код, то это просто какое-то мессиво из непонятных переменных, приправленное не всегда логичной организацией и уместными свойствами и в целом какой-то правильно организацией кода в примере не пахнет.
Думаю это не проблема конкретно Tailwind, я бы больше сказал, что это проблема всего IT, курсы аля "Как стать middle разработчиком за 3 месяца", гораздо больше влияют на то, что люди меньше изучают базу и сразу лезут во фреймворки(потому что на курсе сказали, что знание всего остального не обязательно и можно загуглить)/другие инструменты, которые являются надстройкой над чем-то базовым + изобилие готовых решений, которыми все пользуются тоже этому способствует.
Однако я не считаю, что Tailwind таковым является, мне кажется, что Tailwind больше про альтернативный подход, а не про готовые решения, он явно никак не влияет на понимание общего flow разработки/работы с дизайнером и тд
Согласен, что там можно было сделать на порядок больше абстракций и сделать код еще чище и элегантнее, но тут скорее преследовалась цель показать разницу между количество кода с использованием Tailwind и CSS в целом. При наличии макета и цели сделать идеально, можно было сделать красиво. Да и главная цель была продемонстрировать @ apply в действии и что с помощью него можно делать красиво
Тут я не согласен, потому что Tailwind почти не предоставляет готовых решений, за исключением пары анимаций, он просто дает нам классы нотации эквивалентных CSS, которые мы можем использовать
(flex -> display: flex, justify-between -> justify-content: space-between). Возможно это утверждение справедливо в отношении условного Bootstrap, где есть классы, являющиеся готовыми решениями. Tailwind скорее не про это.
Как я и написал раньше для того чтобы писать на Tailwind нужно также понимать все эти CSS свойства, потому что ты используешь те же CSS свойства просто в другой нотации.
А у меня наоборот опыт такой, что люди которые пишут на Tailwind попробовали уже кучу разных инструментов для стилизации от БЭМ до CSS Modules, CSS in JS, etc... и выбрали именно Tailwind, потому что он им удобен.
Посмотрим что будет на дистанции, возможно и так)
А мне наоборот показалось, что эта директива очень удобна и отлично работает, все-таки все зависит от задач и потребностей.
Директива с помощью которой можно писать те же tailwind классы, но в css файле, в некоторых моментах оказалась очень к месту.
Да, как я и написал в статье, код специфичен(мягко говоря), просто очень часто видел подобные скрины в подтверждение того, что tailwind ужасно засоряет разметку и из-за этого не может нормально масштабироваться на крупных проектах
Скрин был взят с просторов интернета)