#думки_вголос
Де межа між фреймворком та бібліотекою?
Суперечка про те, чи є той же React фреймворком чи простою бібліотекою, точиться уже давно і з перемінним успіхом. Вона не така затята, як таби проти пробілів, але усе ж.
І цікавим аспектом є те, що в сучасній веброзробці поняття UI-бібліотеки стає дедалі розмитішим. Навіть в часи перших версій React не можна було б назвати чистою бібліотекою. Але й до фреймворка він не дотягував. Не дотягує він і досі, але різниця усе меншає.
Наприклад, той самий Inversion of Control. Якщо коротко, то це принцип, коли контроль за виконанням нашого коду передається зовнішній системі. І в React цей принцип певною мірою закладено ще з найперших версій.
Ми пишемо логіку рендеру та композиції. Однак ми не контролюємо життєвий цикл компонентів, не маємо влади над побудовою Virtual DOM, не впливаємо на те, як і коли саме викликаються хуки. Усе це виконується згідно внутрішньої логіки React і контрлюється саме ним.
Чи робить це React фреймворком? Тверде ні. Фреймворк це набагато складніше поняття, і його головний аспект — диктатура. Він диктує структуру та підходи. Він задає жорсткі рамки. І, що головне, фреймворк надає інструменти для забезпечення усіх цих обмежень.
Тому Angular — фреймворк. Попри те, що він дозволяє користуватися різними бібліотеками для розширення функціоналу, його ядро є незмінним. Роутинг, модульність, компоненти, модель роботи з даними — задано на рівні системи і є самодостатнім набором, аби будувати повноцінні застосунки.
React же з коробки вміє лише генерувати HTML і пропихувати пропси. Це якщо розглядати його в першому наближенні. Звичайно, якщо підійти до задачі нетривіально, то можна взагалі без зовнішніх залежностей створити робочий застосунок, і навіть із роутингом. Але, повірте, не варто, я свого часу розплутував такий код, переводячи його на роутер, і здається мені, що автор його не міг спати через гикавку кілька місяців то точно.
Але якщо підібрати певний набір інструментів для того ж роутингу, роботи з даними чи ще якимись задачами, то така збірка може цілком собі поводитись як фреймворк. Але це не робить сам React фреймворком. Радше центральною частиною системи.
Але не реактом єдиним. Візьмемо, до прикладу, Vue. Це бібліотека чи фреймворк? Ви можете почути обидві відповіді. І, що цікаво, обидві будуть вірні. Адже самі автори визначають Vue як прогресивний JavaScript-фреймворк, де прогресивність означає не те, що він стоїть на чолі прогресу, а те, що його функціонал може варіюватися в залежності від ваших потреб.
Тобто Vue може працювати як проста UI-бібліотека, якщо це покриває ваші запити, а може бути потужним фреймворком з усім необхідним вбудованим функціоналом. І така поведінка залишає питання що є UI-бібліотекою, а що фреймворком, ще відкритішим.
Особисто я би радив не заглиблюватися в такі філологічно-архітектурні дискусії, а натомість навчитися розглядати будь-який проєкт як систему, а не імплементацію.
На мою думку, важливо розуміти, що таке система, що таке її компоненти, і бачити їхні звʼязки без привʼязки до конкретних інструментів. Це означає, що застосунки на Angular та React мають виглядати для вас ідентично, якщо вони імплементують ідентичну систему. Тут стає трохи заплутано, розумію.
Ми маємо вміти розділяти наш код на абстракції. Бачити не react-компонент чи angular-компонент, а шар представлення. Бачити не redux-store чи ngrx-store, а шар даних. І так далі. Розуміти що таке MVC чи MVVM. І головне — бачити схоже в різних імплементаціях.
Тоді у вас не виникатиме питань "React це бібліотека чи фреймворк?", бо для вас це стане не важливим. Ви бачитимете систему в цілому. І знатимете, як її імплементувати за допомогою наявних інструментів.
(цей допис — субʼєктивний настільки, наскільки це може в принципі бути)
@babichdev
***
З вас вподобайка з коментарем. І ще б пару гривень на збір на детектори дронів для 115 бригади на Покровський напрямок.
Дякую, і гарного вам усім початку тижня!
Де межа між фреймворком та бібліотекою?
Суперечка про те, чи є той же React фреймворком чи простою бібліотекою, точиться уже давно і з перемінним успіхом. Вона не така затята, як таби проти пробілів, але усе ж.
І цікавим аспектом є те, що в сучасній веброзробці поняття UI-бібліотеки стає дедалі розмитішим. Навіть в часи перших версій React не можна було б назвати чистою бібліотекою. Але й до фреймворка він не дотягував. Не дотягує він і досі, але різниця усе меншає.
Наприклад, той самий Inversion of Control. Якщо коротко, то це принцип, коли контроль за виконанням нашого коду передається зовнішній системі. І в React цей принцип певною мірою закладено ще з найперших версій.
Ми пишемо логіку рендеру та композиції. Однак ми не контролюємо життєвий цикл компонентів, не маємо влади над побудовою Virtual DOM, не впливаємо на те, як і коли саме викликаються хуки. Усе це виконується згідно внутрішньої логіки React і контрлюється саме ним.
Чи робить це React фреймворком? Тверде ні. Фреймворк це набагато складніше поняття, і його головний аспект — диктатура. Він диктує структуру та підходи. Він задає жорсткі рамки. І, що головне, фреймворк надає інструменти для забезпечення усіх цих обмежень.
Тому Angular — фреймворк. Попри те, що він дозволяє користуватися різними бібліотеками для розширення функціоналу, його ядро є незмінним. Роутинг, модульність, компоненти, модель роботи з даними — задано на рівні системи і є самодостатнім набором, аби будувати повноцінні застосунки.
React же з коробки вміє лише генерувати HTML і пропихувати пропси. Це якщо розглядати його в першому наближенні. Звичайно, якщо підійти до задачі нетривіально, то можна взагалі без зовнішніх залежностей створити робочий застосунок, і навіть із роутингом. Але, повірте, не варто, я свого часу розплутував такий код, переводячи його на роутер, і здається мені, що автор його не міг спати через гикавку кілька місяців то точно.
Але якщо підібрати певний набір інструментів для того ж роутингу, роботи з даними чи ще якимись задачами, то така збірка може цілком собі поводитись як фреймворк. Але це не робить сам React фреймворком. Радше центральною частиною системи.
Але не реактом єдиним. Візьмемо, до прикладу, Vue. Це бібліотека чи фреймворк? Ви можете почути обидві відповіді. І, що цікаво, обидві будуть вірні. Адже самі автори визначають Vue як прогресивний JavaScript-фреймворк, де прогресивність означає не те, що він стоїть на чолі прогресу, а те, що його функціонал може варіюватися в залежності від ваших потреб.
Тобто Vue може працювати як проста UI-бібліотека, якщо це покриває ваші запити, а може бути потужним фреймворком з усім необхідним вбудованим функціоналом. І така поведінка залишає питання що є UI-бібліотекою, а що фреймворком, ще відкритішим.
Особисто я би радив не заглиблюватися в такі філологічно-архітектурні дискусії, а натомість навчитися розглядати будь-який проєкт як систему, а не імплементацію.
На мою думку, важливо розуміти, що таке система, що таке її компоненти, і бачити їхні звʼязки без привʼязки до конкретних інструментів. Це означає, що застосунки на Angular та React мають виглядати для вас ідентично, якщо вони імплементують ідентичну систему. Тут стає трохи заплутано, розумію.
Ми маємо вміти розділяти наш код на абстракції. Бачити не react-компонент чи angular-компонент, а шар представлення. Бачити не redux-store чи ngrx-store, а шар даних. І так далі. Розуміти що таке MVC чи MVVM. І головне — бачити схоже в різних імплементаціях.
Тоді у вас не виникатиме питань "React це бібліотека чи фреймворк?", бо для вас це стане не важливим. Ви бачитимете систему в цілому. І знатимете, як її імплементувати за допомогою наявних інструментів.
(цей допис — субʼєктивний настільки, наскільки це може в принципі бути)
@babichdev
***
З вас вподобайка з коментарем. І ще б пару гривень на збір на детектори дронів для 115 бригади на Покровський напрямок.
Дякую, і гарного вам усім початку тижня!
❤56👍14🔥4👏1
Дружнє нагадування про збір на детектори дронів для 115 бригади на Покровський напрямок.
Наразі зібрано 36 886 гривень з 51 000.
Лишається зібрати 14 114 гривень.
Дякую за кожну гривню!
🔗Посилання на банку
https://send.monobank.ua/jar/AeXQ6YRf2X
💳Номер картки банки
5375411202918178
Наразі зібрано 36 886 гривень з 51 000.
Лишається зібрати 14 114 гривень.
Дякую за кожну гривню!
🔗Посилання на банку
https://send.monobank.ua/jar/AeXQ6YRf2X
💳Номер картки банки
5375411202918178
❤7
Дивовижний світ веброзробки
Дружнє нагадування про збір на детектори дронів для 115 бригади на Покровський напрямок. Наразі зібрано 36 886 гривень з 51 000. Лишається зібрати 14 114 гривень. Дякую за кожну гривню! 🔗Посилання на банку https://send.monobank.ua/jar/AeXQ6YRf2X 💳Номер…
Товариство, цей збір закрито! Незабаром почнеться наступний.
🔥12❤3👏2
#анонс
Товариство, я цього вікенду в Києві. І разом з appflame буду робити для вас цікаву забаву, ідея якої крутилася у мене в голові вже дуууууже давно.
Це буде формат "Одне питання — три відповіді". Ми зберемо мідла, синьйора та тимліда, що відповідатимуть на одні й ті самі питання від мене, а я розбиратиму їхні відповіді прямо на місці.
Ми побачимо, чим саме мають відрізнятися ці відповіді, що є достатнім для мідла, а що недостатнім для тимліда, а заодно я спробую довести, насамперед собі, що можна провести співбесіду як джуну, так і тимліду за одним планом. Побачимо, чи вийде.
А, і ще дізнаєтесь, чому для мене не існує неправильних відповідей.
📆 Коли: 14 листопада, 18:00-21:00
✅ Де: офлайн в Києві (місце проведення повідомимо після реєстрації)
Кількість місць обмежена!
Участь — за донат від 500 грн на Veteran Hub.
Кошти будуть спрямовані на індивідуальні психологічні консультації для військових, ветеранів та ветеранок, а також їхніх родин.
📚 РЕЄСТРАЦІЯ: https://bit.ly/47RG7Dc
@babichdev
Товариство, я цього вікенду в Києві. І разом з appflame буду робити для вас цікаву забаву, ідея якої крутилася у мене в голові вже дуууууже давно.
Це буде формат "Одне питання — три відповіді". Ми зберемо мідла, синьйора та тимліда, що відповідатимуть на одні й ті самі питання від мене, а я розбиратиму їхні відповіді прямо на місці.
Ми побачимо, чим саме мають відрізнятися ці відповіді, що є достатнім для мідла, а що недостатнім для тимліда, а заодно я спробую довести, насамперед собі, що можна провести співбесіду як джуну, так і тимліду за одним планом. Побачимо, чи вийде.
А, і ще дізнаєтесь, чому для мене не існує неправильних відповідей.
Кількість місць обмежена!
Участь — за донат від 500 грн на Veteran Hub.
Кошти будуть спрямовані на індивідуальні психологічні консультації для військових, ветеранів та ветеранок, а також їхніх родин.
@babichdev
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥19❤7👍2
#css_in_action
Усі ми чудово знайомі з media queries — способом змінювати певні стилі в залежності від ширини вʼюпорту. Ще з 2001 року ми мали можливість визначати стилі для різних типів медіа, правда, без звичної на сьогодні гнучкості: просто screen чи print.
Але вже з 2002 року розпочалася робота над Media Queries Level 3, і підтримка так званих брейкпоінтів зʼявилася спочатку в Opera 7 2003 року, а трошки згодом її підхопили Safari 3, Firefox 3 та Chrome 1.
Проривом у використанні цього підходу можна вважати статтю Ітана Маркотта Responsive Web Design, що вийшла 2010 року та закріпила термін responsive design як один з головних підходів до побудови інтерфейсів.
Але очевидно, що цей підхід з часом усе більше й більше обмежував розробників. Що, якщо ми маємо одну ширину екрану, але той самий віджет на одних сторінках може займати ширину однієї колонки, а на інших — дві чи три?
Частково, звичайно, це можна вирішити використанням такого собі fluid layout — з використанням тих же flex, коли елементи можна розташувати в адаптивний потік, який сам розташовує їх в залежності ширини.
Але така флюїдність також має певні обмеження, і одна з них — відсутність точного контролю зі сторони розробника.
Ідея container query зародилася ще 2009 року, але тривалий час перебувала лише ідеєю, не в останню чергу через технічні обмеження того часу. Адже це вимагало б постійної перевірки стану контейнерів та їхніх нащадків, що могло також призводити до нескінченних циклів. Тому роботу відклали майже на десятиліття, і лише 2018 року почалися перші цікаві досліди Google з ідеєю "Element Queries".
Це призвело до компромісної ідеї: до специфікації вводиться поняття CSS Containment, яке дозволяє обмежити вплив елемента на layout і тим самим зробити container queries можливими. І вже 2021 року в Chrome Canary зʼявляється перша підтримка
Подальше прийняття відбулося фактично в два етапи: спочатку у червні 2022 року Chrome та Edge 105 впроваджують повну підтримку фічі (з очевидних причин ми якось пропустили цю новину), а згодом до них приєднуються Safari 16 та Firefox 110.
Якщо коротко, то за допомогою container query ми можемо визначати стилі для нащадків контейнера в залежності від його розмірів. Що цікаво, не лише від ширини, а й від висоти. Синтаксис простий, мінімально ми задаємо контейнеру його тип:
А в запиті реагуємо на задані умови:
Ба більше, ми можемо іменувати контейнери, і в такий спосіб точніше визначати стилі, наприклад, коли ми працюємо з елементом, який може бути вкладеним в два чи більше контейнерів.
Такий підхід дозволяє робити дійсно ізольовані UI-компоненти, і не переживати через те, що макет десь зламається, адже ми обмежуємось контекстом саме контейнеру, а не усієї сторінки загалом. В такий спосіб забезпечується більша гнучкість UI та збільшується кількість сценаріїв використання компоненту, які ми можемо дійсно передбачити.
Що почитати:
📖 MDN: @container
📖 MDN: container-type
📖 MDN: container-name
Що почитати душнілам:
📖 CSS Containment Module Level 3 (W3C Draft)
@babichdev
Усі ми чудово знайомі з media queries — способом змінювати певні стилі в залежності від ширини вʼюпорту. Ще з 2001 року ми мали можливість визначати стилі для різних типів медіа, правда, без звичної на сьогодні гнучкості: просто screen чи print.
Але вже з 2002 року розпочалася робота над Media Queries Level 3, і підтримка так званих брейкпоінтів зʼявилася спочатку в Opera 7 2003 року, а трошки згодом її підхопили Safari 3, Firefox 3 та Chrome 1.
Проривом у використанні цього підходу можна вважати статтю Ітана Маркотта Responsive Web Design, що вийшла 2010 року та закріпила термін responsive design як один з головних підходів до побудови інтерфейсів.
Але очевидно, що цей підхід з часом усе більше й більше обмежував розробників. Що, якщо ми маємо одну ширину екрану, але той самий віджет на одних сторінках може займати ширину однієї колонки, а на інших — дві чи три?
Частково, звичайно, це можна вирішити використанням такого собі fluid layout — з використанням тих же flex, коли елементи можна розташувати в адаптивний потік, який сам розташовує їх в залежності ширини.
Але така флюїдність також має певні обмеження, і одна з них — відсутність точного контролю зі сторони розробника.
Ідея container query зародилася ще 2009 року, але тривалий час перебувала лише ідеєю, не в останню чергу через технічні обмеження того часу. Адже це вимагало б постійної перевірки стану контейнерів та їхніх нащадків, що могло також призводити до нескінченних циклів. Тому роботу відклали майже на десятиліття, і лише 2018 року почалися перші цікаві досліди Google з ідеєю "Element Queries".
Це призвело до компромісної ідеї: до специфікації вводиться поняття CSS Containment, яке дозволяє обмежити вплив елемента на layout і тим самим зробити container queries можливими. І вже 2021 року в Chrome Canary зʼявляється перша підтримка
@container.Подальше прийняття відбулося фактично в два етапи: спочатку у червні 2022 року Chrome та Edge 105 впроваджують повну підтримку фічі (з очевидних причин ми якось пропустили цю новину), а згодом до них приєднуються Safari 16 та Firefox 110.
Якщо коротко, то за допомогою container query ми можемо визначати стилі для нащадків контейнера в залежності від його розмірів. Що цікаво, не лише від ширини, а й від висоти. Синтаксис простий, мінімально ми задаємо контейнеру його тип:
.card {
container-type: inline-size;
}А в запиті реагуємо на задані умови:
@container (min-width: 400px) {
.card-content { display: grid; }
}Ба більше, ми можемо іменувати контейнери, і в такий спосіб точніше визначати стилі, наприклад, коли ми працюємо з елементом, який може бути вкладеним в два чи більше контейнерів.
Такий підхід дозволяє робити дійсно ізольовані UI-компоненти, і не переживати через те, що макет десь зламається, адже ми обмежуємось контекстом саме контейнеру, а не усієї сторінки загалом. В такий спосіб забезпечується більша гнучкість UI та збільшується кількість сценаріїв використання компоненту, які ми можемо дійсно передбачити.
Що почитати:
📖 MDN: @container
📖 MDN: container-type
📖 MDN: container-name
Що почитати душнілам:
📖 CSS Containment Module Level 3 (W3C Draft)
@babichdev
🔥31❤19👍4👏1
#мислення_розробника
Як навчитись не боятись робити помилки?
Під час панельної дискусії про факапи на MateConf нам із Віктором Турським та Іллєю Климовим ставили багато цікавих питань, але, на жаль, не на всі вдалося відповісти. Але на деякі спробую дати свої максимально упереджені відповіді тут.
Отже, як навчитись не боятись робити помилки? Зазвичай ми боїмося помилитись через банальний страх покарання. І це, друзі мої, найгірша ситуація, в якій можна опинитися. Тут моя порада буде простою — в дупу таку компанію.
А тепер до суті. Щоб перестати боятися помилок, треба навчитись розуміти ціну помилки. Я маю на увазі не розмір штрафу, а радше обсяг виправлень, які доведеться робити, аби нівелювати нанесену шкоду.
Це не означає, що як така ціна помилки невелика, то на неї можна забивати. Розуміння того, що будь-яку ціну помилки доведеться так чи інакше платити, має бути. Саме на цьому будується відповідальність.
Усвідомлення ціни помилки має впливати на те, до яких сценаріїв ми маємо бути готові, на який масштаб damage control нам треба очікувати. Якщо усвідомлювати це, то замість страху перед помилками у нас буде небажання їх припускатись. А це різні речі, погодьтесь.
Ми маємо бути готовими до помилок. Це виявляється у створенні якихось правил, дотримання яких дозволить їх просто не припускатися. Звичайно, до всього готовим не будеш, і тому варто мати ще й «аварійні протоколи».
При цьому варто розуміти, що навіть за наявности усього цього, ви не вбережетесь від факапу на сто відсотків. Присутність розуміння, що робити в разі халепи, додає спокою і не дасть метушитися й панікувати, коли халепа таки станеться.
Помилок не треба боятися. До них треба готуватися, досліджувати шляхи, як їх не припускатися, мати план дій на випадок їх виникнення.
От десь тут пасувало би поставити допису вогника чи серденько
Але давайте так: не варто перетворювати це на тривожний розлад. Не треба на кожен чих і косяк мати тритомні інструкції. Достатньо випрацювати кілька універсальних сценаріїв, що покривають більшість випадків. Ще раз наголошу — до всього готовим не будеш.
Тут ліпше виховати в собі підхід «намагаюсь не допустити, якщо трапилось — роблю все в моїх силах, аби нівелювати».
Ну а щодо того «як навчитися»… Запамʼятайте — щоб навчитися щось робити правильно, треба спочатку зрозуміти, як робити неправильно. Тому будьте відкритими до помилок у вашій практиці, не бійтеся їх. Головне — робіть аналіз та висновки за результатами. Не забороняйте собі шукати поради й допомоги.
Аби навчитися тонкої різьби по дереву, вам доведеться не раз порізати пальці. Але лише так ви навчитеся тримати різець так, щоб, замість шкодити собі, створювати красу.
Але, звичайно, це усе можливо лише за умови, що ваше оточення, зокрема компанія, забезпечує відповідну атмосферу. За умов постійного страху покарання ви ніколи не навчитеся брати на себе відповідальність, натомість станете незрівнянними майстрами ухиляння від неї та перекладання провини на інших. Навичка сама по собі в певних обставинах непогана, але як професійна якість — шкідлива понад міру.
Тож, якщо коротко — не бійтесь, а готуйтесь. Не уникайте відповідальности, а беріть її на себе самі. Памʼятайте, будь-який факап — чудова точка росту, якщо правильно нею скористатись.
Всім гарного початку тижня!
@babichdev
P.S. Долучайтеся до чату спільноти: @babichdevchat
Як навчитись не боятись робити помилки?
Під час панельної дискусії про факапи на MateConf нам із Віктором Турським та Іллєю Климовим ставили багато цікавих питань, але, на жаль, не на всі вдалося відповісти. Але на деякі спробую дати свої максимально упереджені відповіді тут.
Отже, як навчитись не боятись робити помилки? Зазвичай ми боїмося помилитись через банальний страх покарання. І це, друзі мої, найгірша ситуація, в якій можна опинитися. Тут моя порада буде простою — в дупу таку компанію.
А тепер до суті. Щоб перестати боятися помилок, треба навчитись розуміти ціну помилки. Я маю на увазі не розмір штрафу, а радше обсяг виправлень, які доведеться робити, аби нівелювати нанесену шкоду.
Це не означає, що як така ціна помилки невелика, то на неї можна забивати. Розуміння того, що будь-яку ціну помилки доведеться так чи інакше платити, має бути. Саме на цьому будується відповідальність.
Усвідомлення ціни помилки має впливати на те, до яких сценаріїв ми маємо бути готові, на який масштаб damage control нам треба очікувати. Якщо усвідомлювати це, то замість страху перед помилками у нас буде небажання їх припускатись. А це різні речі, погодьтесь.
Ми маємо бути готовими до помилок. Це виявляється у створенні якихось правил, дотримання яких дозволить їх просто не припускатися. Звичайно, до всього готовим не будеш, і тому варто мати ще й «аварійні протоколи».
При цьому варто розуміти, що навіть за наявности усього цього, ви не вбережетесь від факапу на сто відсотків. Присутність розуміння, що робити в разі халепи, додає спокою і не дасть метушитися й панікувати, коли халепа таки станеться.
Помилок не треба боятися. До них треба готуватися, досліджувати шляхи, як їх не припускатися, мати план дій на випадок їх виникнення.
Але давайте так: не варто перетворювати це на тривожний розлад. Не треба на кожен чих і косяк мати тритомні інструкції. Достатньо випрацювати кілька універсальних сценаріїв, що покривають більшість випадків. Ще раз наголошу — до всього готовим не будеш.
Тут ліпше виховати в собі підхід «намагаюсь не допустити, якщо трапилось — роблю все в моїх силах, аби нівелювати».
Ну а щодо того «як навчитися»… Запамʼятайте — щоб навчитися щось робити правильно, треба спочатку зрозуміти, як робити неправильно. Тому будьте відкритими до помилок у вашій практиці, не бійтеся їх. Головне — робіть аналіз та висновки за результатами. Не забороняйте собі шукати поради й допомоги.
Аби навчитися тонкої різьби по дереву, вам доведеться не раз порізати пальці. Але лише так ви навчитеся тримати різець так, щоб, замість шкодити собі, створювати красу.
Але, звичайно, це усе можливо лише за умови, що ваше оточення, зокрема компанія, забезпечує відповідну атмосферу. За умов постійного страху покарання ви ніколи не навчитеся брати на себе відповідальність, натомість станете незрівнянними майстрами ухиляння від неї та перекладання провини на інших. Навичка сама по собі в певних обставинах непогана, але як професійна якість — шкідлива понад міру.
Тож, якщо коротко — не бійтесь, а готуйтесь. Не уникайте відповідальности, а беріть її на себе самі. Памʼятайте, будь-який факап — чудова точка росту, якщо правильно нею скористатись.
Всім гарного початку тижня!
@babichdev
P.S. Долучайтеся до чату спільноти: @babichdevchat
❤53🔥26👍3
#коштозбір
Доброго ранку, товариство. У повному розпалі збір на DJI Mini 4 Pro для 115-ї бригади, на Покровський напрямок.
Це той самий екіпаж бензовозів, для яких ми збирали на "Чуйки", себто детектори дронів. Чуйки вже в черзі на виготовлення, тож щойно підрозділ їх отримає, буде фотозвіт.
А дрон їм треба в якості "очей". Нагадую, що ці бензовози виконують надзвичайно важливе завдання — дозаправку важкої техніки на ЛБЗ.
Так от. За результатами збору я розіграю Lego Dune серед усіх донатів, кратних 100 гривням.
Дякую за кожен ваш внесок!
🎯 Ціль: 48 000 ₴
Зібрано 5 463 ₴
🔗Посилання на банку
https://send.monobank.ua/jar/9xqCBnLwJF
💳Номер картки банки
4874100021563021
Доброго ранку, товариство. У повному розпалі збір на DJI Mini 4 Pro для 115-ї бригади, на Покровський напрямок.
Це той самий екіпаж бензовозів, для яких ми збирали на "Чуйки", себто детектори дронів. Чуйки вже в черзі на виготовлення, тож щойно підрозділ їх отримає, буде фотозвіт.
А дрон їм треба в якості "очей". Нагадую, що ці бензовози виконують надзвичайно важливе завдання — дозаправку важкої техніки на ЛБЗ.
Так от. За результатами збору я розіграю Lego Dune серед усіх донатів, кратних 100 гривням.
Дякую за кожен ваш внесок!
🎯 Ціль: 48 000 ₴
Зібрано 5 463 ₴
🔗Посилання на банку
https://send.monobank.ua/jar/9xqCBnLwJF
💳Номер картки банки
4874100021563021
❤17
Дивовижний світ веброзробки
#коштозбір Доброго ранку, товариство. У повному розпалі збір на DJI Mini 4 Pro для 115-ї бригади, на Покровський напрямок. Це той самий екіпаж бензовозів, для яких ми збирали на "Чуйки", себто детектори дронів. Чуйки вже в черзі на виготовлення, тож щойно…
Ранок обіцяє бути вибуховим, тому пропоную закинути пару гривень на збір.
Товариство, маю надію, що з усіма вами все гаразд. Росія — кончена країна кончених людей, і не втомлюється про це нагадувати. Тому повинна зникнути назавжди. А відключення ми якось та й переживем.
Я планував цей анонс зробити ще вчора, але шось якось за переглядом першого сезону Дивних Див забув. Тому роблю його зараз. До речі, це не останній анонс не сьогодні.
Шо? ШІ? Знову?!
Так, навіть перший Ламповий Мітап у Львові не обійдеться без розмов про штучний інтелект. 21 листопада, цієї пʼятниці, ІТ-спільнота ЛАМПА проведе свій перший серйозний мітап, на якому будуть наступні теми:
Комплекс самозванця — тепер з присмаком AI
Петро Карнаух поділиться своїми внутрішніми рефлексіями на тему впливу штучного інтелекту на нашу самооцінку, як фахівців. Разом із нами він спробує розібратись чи знадобиться нам AI психолог, аби поколупатись у нашому AI дитинстві.
Чи дійсно ЛЛМ трансформують тестування та автоматизацію?
Роман Марінський розповість історії страждань та болей від бездумних АІ трансформацій та практичних повчальних історій де саме всунути ШІ.
Запхайте свій AI собі в співбесіду!
Ну а я не вигадав нічого кращого, ніж знову говорити про технічні співбесіди. Буде намагатися зрозуміти, чому одні компанії категорично забороняють ШІ на інтервʼю, а інші навпаки — будують свої співбесіди навколо нього.
🚨 РЕЄСТРАЦІЯ
Буду раді бачити вас цієї пʼятниці, 21 листопада, у офісі компанії Sigma Software, за адресою вул. Наукова 7Д, о 19 годині! Можна приходити трошечки раніше, було б прикольно хоча б раз почати мітап вчасно.
Вартість квитка — 400 грн. Уся кошти з події будуть скеровані на потреби ЗСУ.
Я планував цей анонс зробити ще вчора, але шось якось за переглядом першого сезону Дивних Див забув. Тому роблю його зараз. До речі, це не останній анонс не сьогодні.
Шо? ШІ? Знову?!
Так, навіть перший Ламповий Мітап у Львові не обійдеться без розмов про штучний інтелект. 21 листопада, цієї пʼятниці, ІТ-спільнота ЛАМПА проведе свій перший серйозний мітап, на якому будуть наступні теми:
Комплекс самозванця — тепер з присмаком AI
Петро Карнаух поділиться своїми внутрішніми рефлексіями на тему впливу штучного інтелекту на нашу самооцінку, як фахівців. Разом із нами він спробує розібратись чи знадобиться нам AI психолог, аби поколупатись у нашому AI дитинстві.
Чи дійсно ЛЛМ трансформують тестування та автоматизацію?
Роман Марінський розповість історії страждань та болей від бездумних АІ трансформацій та практичних повчальних історій де саме всунути ШІ.
Запхайте свій AI собі в співбесіду!
Ну а я не вигадав нічого кращого, ніж знову говорити про технічні співбесіди. Буде намагатися зрозуміти, чому одні компанії категорично забороняють ШІ на інтервʼю, а інші навпаки — будують свої співбесіди навколо нього.
Буду раді бачити вас цієї пʼятниці, 21 листопада, у офісі компанії Sigma Software, за адресою вул. Наукова 7Д, о 19 годині! Можна приходити трошечки раніше, було б прикольно хоча б раз почати мітап вчасно.
Вартість квитка — 400 грн. Уся кошти з події будуть скеровані на потреби ЗСУ.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤15🔥9
Товариство, доброго ранку! Знаю, що цього тижня не сильно балував вас новими корисними текстами, ну так ви мене й вподобайками теж не сильно балуєте.
Тако, маю для вас нині дві речі.
Перша: ви ще маєте нагоду придбати квиточок на перший Ламповий Мітап, на якому достойні козаки Петро Карнаух, Роман Марінський і ваш скромний Бабіч поділяться різними думками, корисними й не дуже. Я особисто буду імпровізувати на тему місця ШІ на технічних співбесідах. Тож обовʼязково приходьте, хто має нагоду!
Квитки на мітап тут, і їх лишилось не те, щоб багато. Не зволікайте.
І друге. Якщо складуться всі зорі, то сьогодні, спеціально для тих, хто не зможе потрапити на мітап, відбудеться премʼєра співбесіди, яку я записав ще 1 листопада. Можна навіть сказати, що навколо цього випуску відбувалась містична чортівня, але насправді виною усьому мої криві руки. Тому процес монтажу і доведення до нормального стану дещо затягнувся.
Але, я вважаю, вийшло цікаво, корисно й пізнавально. Тож, щойно я викладу відео й запланую премʼєру, я зроблю допис нагадайку, аби ви не пропустили.
Щоразу я собі обіцяю, що от цей тиждень вже точно був найнасиченішим, і наступного буде якось легше, нарешті дороблю те, те і те. І щоразу наступний тиждень підкидає як не якусь сраку, то неймовірну можливість. Так і нині — мене запросили відвідати такий івент, від самої думки про який у мене певно дрижали б колінка ще пів року тому. А зараз я просто в екстреному режимі роблю персональний лендинг і візитівки )
Та й таке ) До речі, як у вас справи? Шось ми давно не теревенили просто так.
Тако, маю для вас нині дві речі.
Перша: ви ще маєте нагоду придбати квиточок на перший Ламповий Мітап, на якому достойні козаки Петро Карнаух, Роман Марінський і ваш скромний Бабіч поділяться різними думками, корисними й не дуже. Я особисто буду імпровізувати на тему місця ШІ на технічних співбесідах. Тож обовʼязково приходьте, хто має нагоду!
Квитки на мітап тут, і їх лишилось не те, щоб багато. Не зволікайте.
І друге. Якщо складуться всі зорі, то сьогодні, спеціально для тих, хто не зможе потрапити на мітап, відбудеться премʼєра співбесіди, яку я записав ще 1 листопада. Можна навіть сказати, що навколо цього випуску відбувалась містична чортівня, але насправді виною усьому мої криві руки. Тому процес монтажу і доведення до нормального стану дещо затягнувся.
Але, я вважаю, вийшло цікаво, корисно й пізнавально. Тож, щойно я викладу відео й запланую премʼєру, я зроблю допис нагадайку, аби ви не пропустили.
Щоразу я собі обіцяю, що от цей тиждень вже точно був найнасиченішим, і наступного буде якось легше, нарешті дороблю те, те і те. І щоразу наступний тиждень підкидає як не якусь сраку, то неймовірну можливість. Так і нині — мене запросили відвідати такий івент, від самої думки про який у мене певно дрижали б колінка ще пів року тому. А зараз я просто в екстреному режимі роблю персональний лендинг і візитівки )
Та й таке ) До речі, як у вас справи? Шось ми давно не теревенили просто так.
❤31
#анонс
Так, товариство, премʼєра нового випуску співбесід таки відбудеться сьогодні о 19:00!
Моєю гостею цього разу була Стася Тілікіна, фронтенд-інженерка з понад трьома роками досвіду у веброзробці. Вона має досвід викладання й менторства на ІТ-курсах, а нині виконує роль тімліда — керує командою, планує розвиток проєкту та допомагає інженерам зростати.
Співбесіду я ж будував навколо однієї уявної фічі в уявному проєкті, але поговорили ми зі Стасею про різні неуявні аспекти розробки, тож запрошую вас до перегляду цього випуску сьогодні ввечері!
https://youtu.be/IKqcJSYE0_Q
P.S. До речі, під час запису цього випуску ми зібрали 4401.50 грн на потреби ЗСУ
P.P.S. Якщо якісь косяки монтажу лишились, то вже звиняйте, я перемонтовувать не буду, в мене й так всі нерви на це пішли )
Так, товариство, премʼєра нового випуску співбесід таки відбудеться сьогодні о 19:00!
Моєю гостею цього разу була Стася Тілікіна, фронтенд-інженерка з понад трьома роками досвіду у веброзробці. Вона має досвід викладання й менторства на ІТ-курсах, а нині виконує роль тімліда — керує командою, планує розвиток проєкту та допомагає інженерам зростати.
Співбесіду я ж будував навколо однієї уявної фічі в уявному проєкті, але поговорили ми зі Стасею про різні неуявні аспекти розробки, тож запрошую вас до перегляду цього випуску сьогодні ввечері!
https://youtu.be/IKqcJSYE0_Q
P.S. До речі, під час запису цього випуску ми зібрали 4401.50 грн на потреби ЗСУ
P.P.S. Якщо якісь косяки монтажу лишились, то вже звиняйте, я перемонтовувать не буду, в мене й так всі нерви на це пішли )
YouTube
Співбесіда Frontend Engineer: Стася Тілікіна
Учасниця цього випуску — Стася Тілікіна, фронтенд-інженерка з понад трьома роками досвіду у веброзробці. Має досвід викладання й менторства на ІТ-курсах, а нині виконує роль тімліда — керує командою, планує розвиток проєкту та допомагає інженерам зростати.…
🔥28❤8
Відлік розпочався!
https://youtu.be/IKqcJSYE0_Q
https://youtu.be/IKqcJSYE0_Q
YouTube
Співбесіда Frontend Engineer: Стася Тілікіна
Учасниця цього випуску — Стася Тілікіна, фронтенд-інженерка з понад трьома роками досвіду у веброзробці. Має досвід викладання й менторства на ІТ-курсах, а нині виконує роль тімліда — керує командою, планує розвиток проєкту та допомагає інженерам зростати.…
🔥20❤1👍1
#мислення_розробника
Пастка кращих практик.
Хочеш бути кращим інженером? Використовуй KISS! DRY! YAGNI! та інші, не менш цікаві, абревіатури. І водночас, коли багато хто переконливо пояснюють нам чому нам обовʼязково потрібно дотримуватись усіх цих практик, дуже мало голосів намагаються розібратися, коли їх дотримуватись не треба.
Не так давно, розмірковуючи про Good Enough Code, я зауважив, що на 100% відсотків дотримуватися усіх "кращих практик" просто фізично неможливо. З однієї простої причини — вони порушують одне одного. В цей аспект заглиблюватись не буду, я сьогодні про інше.
Тут днями в нашому чаті почалася розмова про ту саму "перевикористовуваність" компонентів, яку багато розробників перевели хто в статус державної релігії, а хто й карґо-культу.
Основна ідея реюзабельности проста як двері — ваш компонент не повинен бути заточеним під один-єдиний юзкейс, і його можна використати в іншому сценарії. Звучить круто, так? Менше коду, взяв готове, і вперед.
Однак це відкриває провалля до пекла. І починається воно з того, що розробники не бачать межу між компонентами, які можна перевикористати, і тими, які в принципі за своєю суттю є одноразовими. І тоді починається цікаве. Ось такий базовий компонент починає всотувати в себе одноразові кейси, потроху роздуваючись до непристойних розмірів та обростаючи додатковими прапорцями й налаштуваннями.
Далеко ходити не треба. Кожен з нас бодай раз, але таки створював компонент кнопки. Спочатку це маленький милий пухнастий компонентик, який ховає під собою тільки стилі. Проте потім у нього починають відростати додаткові стани і пропси до них: іконка зліва, іконка справа, стан завантаження, варіанти стилю, розміри і тому подібне.
І ось на нас вже сумно дивиться з потойбічної Безодні щось хтонічне, поряд із чим навіть Ктулху поводиться чемно.
Чи можна було цього уникнути? Абсолютно. В першу чергу, величезна кількість "станів" в кінці кінців зводиться до того, що під капотом на кнопку вішається якийсь клас. То чому ж не дати розробнику самому цей клас навісити?
Чи ті самі іконки? Просто кладіть іконку в кнопку явно на потрібне місце. CSS давно вміє застосовувати стилі на основі позиції та присутності чи відсутності певних елементів.
Похідні стилі? CSS змінні та calc до ваших послуг.
І так далі, і тому подібне. Ми настільки звикли робити ось ці універсальні комбайни, що тулимо їх там, де рішення може бути настільки простим, наскільки лише можна. І виходить, що та сама кнопка, задача якої або натискатися, або не натискатися, розростається в складний заплутаний клубок пропсів.
Не все має бути перевикористовуваним. Не все має бути універсальним. Ба більше, не все має бути ідеальним.
Коли у вас виникає спокуса додати до компонента ще одне налаштування, що один пропс, покрити ще один кейс, ставте собі просте запитання: "Що я цим вирішую?".
Чи не краще замість чергового isLoading в базовій кнопці створити
А раджу я не конкретний рецепт, а ідею, думку, варту того, аби над нею подумати: замість монструозних універсальних систем мати шар базових, тупих як пересічний росіянин, компонент, і шар більш спеціалізованих, успадкованих від базових, компонент, які покривають специфічніші задачі (я прямо відчуваю хвилю гніву, що котиться до мене з табору реактщиків).
І мова не лише про UI. Спробуйте цю ідею. Іноді найкращі речі — найпростіші речі. А принципу наслідування й розширення рочків вже побільше ніж мені, певно.
@babichdev
З вас вподобайка, репост і раптова підписка. Гарного початку тижня, і не городіть хєрні в коді!
Пастка кращих практик.
Хочеш бути кращим інженером? Використовуй KISS! DRY! YAGNI! та інші, не менш цікаві, абревіатури. І водночас, коли багато хто переконливо пояснюють нам чому нам обовʼязково потрібно дотримуватись усіх цих практик, дуже мало голосів намагаються розібратися, коли їх дотримуватись не треба.
Не так давно, розмірковуючи про Good Enough Code, я зауважив, що на 100% відсотків дотримуватися усіх "кращих практик" просто фізично неможливо. З однієї простої причини — вони порушують одне одного. В цей аспект заглиблюватись не буду, я сьогодні про інше.
Тут днями в нашому чаті почалася розмова про ту саму "перевикористовуваність" компонентів, яку багато розробників перевели хто в статус державної релігії, а хто й карґо-культу.
Основна ідея реюзабельности проста як двері — ваш компонент не повинен бути заточеним під один-єдиний юзкейс, і його можна використати в іншому сценарії. Звучить круто, так? Менше коду, взяв готове, і вперед.
Однак це відкриває провалля до пекла. І починається воно з того, що розробники не бачать межу між компонентами, які можна перевикористати, і тими, які в принципі за своєю суттю є одноразовими. І тоді починається цікаве. Ось такий базовий компонент починає всотувати в себе одноразові кейси, потроху роздуваючись до непристойних розмірів та обростаючи додатковими прапорцями й налаштуваннями.
Далеко ходити не треба. Кожен з нас бодай раз, але таки створював компонент кнопки. Спочатку це маленький милий пухнастий компонентик, який ховає під собою тільки стилі. Проте потім у нього починають відростати додаткові стани і пропси до них: іконка зліва, іконка справа, стан завантаження, варіанти стилю, розміри і тому подібне.
І ось на нас вже сумно дивиться з потойбічної Безодні щось хтонічне, поряд із чим навіть Ктулху поводиться чемно.
Чи можна було цього уникнути? Абсолютно. В першу чергу, величезна кількість "станів" в кінці кінців зводиться до того, що під капотом на кнопку вішається якийсь клас. То чому ж не дати розробнику самому цей клас навісити?
Чи ті самі іконки? Просто кладіть іконку в кнопку явно на потрібне місце. CSS давно вміє застосовувати стилі на основі позиції та присутності чи відсутності певних елементів.
Похідні стилі? CSS змінні та calc до ваших послуг.
І так далі, і тому подібне. Ми настільки звикли робити ось ці універсальні комбайни, що тулимо їх там, де рішення може бути настільки простим, наскільки лише можна. І виходить, що та сама кнопка, задача якої або натискатися, або не натискатися, розростається в складний заплутаний клубок пропсів.
Не все має бути перевикористовуваним. Не все має бути універсальним. Ба більше, не все має бути ідеальним.
Коли у вас виникає спокуса додати до компонента ще одне налаштування, що один пропс, покрити ще один кейс, ставте собі просте запитання: "Що я цим вирішую?".
Чи не краще замість чергового isLoading в базовій кнопці створити
AsyncButton з тим же pending станом? Більшість з вас, звичайно, зараз обурено вдихнули — це що таке я раджу? А раджу я не конкретний рецепт, а ідею, думку, варту того, аби над нею подумати: замість монструозних універсальних систем мати шар базових, тупих як пересічний росіянин, компонент, і шар більш спеціалізованих, успадкованих від базових, компонент, які покривають специфічніші задачі (я прямо відчуваю хвилю гніву, що котиться до мене з табору реактщиків).
І мова не лише про UI. Спробуйте цю ідею. Іноді найкращі речі — найпростіші речі. А принципу наслідування й розширення рочків вже побільше ніж мені, певно.
@babichdev
З вас вподобайка, репост і раптова підписка. Гарного початку тижня, і не городіть хєрні в коді!
❤70👍18🔥15👏4🤔1
Товариство, нам з вами лишилося дотиснути зовсім трошки у зборі на DJI Mini 4 Pro для 115-ї бригади, на Покровський напрямок.
Наразі ми зібрали 35 275 гривень на банку з Lego, і ще 6 800 в основній банці, тобто разом маємо 42 075 з необхідних 48 000 грн.
Нагадую, що кожні 100 гривень вашого донату — це "квиточок" у розіграші Lego Dune: Atreides Royal Ornithopter.
🔗Посилання на банку
https://send.monobank.ua/jar/9xqCBnLwJF
💳Номер картки банки
4874100021563021
Наразі ми зібрали 35 275 гривень на банку з Lego, і ще 6 800 в основній банці, тобто разом маємо 42 075 з необхідних 48 000 грн.
Нагадую, що кожні 100 гривень вашого донату — це "квиточок" у розіграші Lego Dune: Atreides Royal Ornithopter.
🔗Посилання на банку
https://send.monobank.ua/jar/9xqCBnLwJF
💳Номер картки банки
4874100021563021
❤9🔥1
Товариство, доброго ранку!
У мене цей тиждень трохи зайнятий, справи, поїздки, тому не сильно й пишу.
Шо хочу повідомити — збір на DJI Mini 4 Pro для 115-ї бригади ЗАВЕРШЕНО, дрон оплаченою. З тижня розберусь з усим, відзвітую детальніше.
Банку не закрив поки, тож як хто ще хоче випробувати долю і спробувати виграти Lego Atreides Royal Ornithopter — можете закинути від 100 гривень. Усе, що дозбираєм, піде на наступний збір. Банку закрию в понеділок.
Дякую усім, хто долучився, ви допомагаєте робити великі справи!
Всім цьом у лобіка і до зустрічі в понеділок!
У мене цей тиждень трохи зайнятий, справи, поїздки, тому не сильно й пишу.
Шо хочу повідомити — збір на DJI Mini 4 Pro для 115-ї бригади ЗАВЕРШЕНО, дрон оплаченою. З тижня розберусь з усим, відзвітую детальніше.
Банку не закрив поки, тож як хто ще хоче випробувати долю і спробувати виграти Lego Atreides Royal Ornithopter — можете закинути від 100 гривень. Усе, що дозбираєм, піде на наступний збір. Банку закрию в понеділок.
Дякую усім, хто долучився, ви допомагаєте робити великі справи!
Всім цьом у лобіка і до зустрічі в понеділок!
🔥8
А їду я, якшо шо, до Чернівців.
Буду на події FE Hills розказувати куди запхати ШІ на співбесіді.
Тож, якщо ви цими днями в Чернівцях і досі на взяли квиток — ну та я й не знаю, шо на це сказати.
Беріть квиточок і до зустрічі завтра!
https://www.it-cluster.cv.ua/fe-hills
Буду на події FE Hills розказувати куди запхати ШІ на співбесіді.
Тож, якщо ви цими днями в Чернівцях і досі на взяли квиток — ну та я й не знаю, шо на це сказати.
Беріть квиточок і до зустрічі завтра!
https://www.it-cluster.cv.ua/fe-hills
www.it-cluster.cv.ua
FE Hills
29 листопада 2025 року топові експерти поділяться найкращими практиками використання AI, сучасних інструментів та автоматизації у Frontend-розробці.
❤17😁1
#css_in_action
Бравзер читає CSS-селектори справа наліво.
Це загальновідомий факт, який, однак, потребує певного пояснення. По-перше, треба розуміти, коли це стається, а по-друге — чи завжди так.
Цей процес відбувається між етапом коли побудовані DOM та CSSOM та етапом render-tree. Це так званий style computation — крок, під час якого бравзер визначає, які стилі до якого елемента застосовуються. І саме тоді йому потрібно знайти відповідність між селектором та елементос в DOM.
Чому ж справа наліво? Усе просто — це зменшує кількість кандидатів для перевірки. Якби бравзер йшов селектором зліва направо, тобто зверху вниз DOM-деревом, йому б довелось перевіряти все дерево повністю. Натомість він відразу відсікає невідповідні кінцеві "листки" дерева, і прямує вгору від цільового елементу, який визначається найправішим простим селектором.
Погляньмо на приклад:
Тут бравзер відразу шукатиме усі
Якби ми йшли зліва направо, то бравзер мусив би перебирати усі
Цей механізм, до речі, був закладений в CSS ще від самого початку появи технології.
А на цьому місці прийшов час поставити вподобайку та поширити допис. Хіба нє?
Взагалі, метчинг запускається доволі часто, коли постає потреба перезапустити style-calculation, наприклад, коли змінюються CSS-правила. Наприклад, на додачу до вище згаданого, коли ми змінюємо атрибути елементу з попереднім селектором (в цьому прикладі
Але перерахунок відбувається точково, лише для потенційно зачеплених вузлів, а не по усьому дереву.
Важливо памʼятати, що DOM API не використовує саме цей рушій, але окремі операції можуть виглядати схоже. Наприклад,
Той же
Загалом цей підхід спрямований не на якесь там "прискорення селекторів", а для забезпечення контрольованості інвалідації стилів. Завдяки такому напрямку браузер не перевіряє весь DOM, а працює локально — що й дозволяє CSS залишатися ефективним навіть на велетенських деревах.
Однак це не означає, що тепер можна видихнути і писати селектори на 15 складових. Треба памʼятати, що бравзеру однак доводиться виконувати титанічний обсяг роботи, особливо в умовах високодинамічних інтерфейсів. І якщо ми йому в цьому допоможемо, пишучи максимально прості селектори, він на нас точно не образиться.
Що почитати:
📖 The truth about CSS selector performance
@babichdev
Бравзер читає CSS-селектори справа наліво.
Це загальновідомий факт, який, однак, потребує певного пояснення. По-перше, треба розуміти, коли це стається, а по-друге — чи завжди так.
Цей процес відбувається між етапом коли побудовані DOM та CSSOM та етапом render-tree. Це так званий style computation — крок, під час якого бравзер визначає, які стилі до якого елемента застосовуються. І саме тоді йому потрібно знайти відповідність між селектором та елементос в DOM.
Чому ж справа наліво? Усе просто — це зменшує кількість кандидатів для перевірки. Якби бравзер йшов селектором зліва направо, тобто зверху вниз DOM-деревом, йому б довелось перевіряти все дерево повністю. Натомість він відразу відсікає невідповідні кінцеві "листки" дерева, і прямує вгору від цільового елементу, який визначається найправішим простим селектором.
Погляньмо на приклад:
.card p ~ a.button
Тут бравзер відразу шукатиме усі
a.button, потім пройдеться його попередніми сусідами, які є p, і для кожного з них знайде безпосереднього батька з класом .card. Що примітно, бравзер навіть не "шукатиме" ці елементи, бо побудує індекс за тегами й класами ще на етапі побудови DOM-дерева. Тому розпочне пошук відразу з потрібних вузлів. Якби ми йшли зліва направо, то бравзер мусив би перебирати усі
.card, незалежно від того, чи містять вони p, потім — усі p в таких .card, незалежно від того, чи є у них сусідні a.button.Цей механізм, до речі, був закладений в CSS ще від самого початку появи технології.
Взагалі, метчинг запускається доволі часто, коли постає потреба перезапустити style-calculation, наприклад, коли змінюються CSS-правила. Наприклад, на додачу до вище згаданого, коли ми змінюємо атрибути елементу з попереднім селектором (в цьому прикладі
p або .card). Чи коли змінюється структура DOM: переміщення, додавання, видалення вузлів, а також коли є динамічні псевдокласи.Але перерахунок відбувається точково, лише для потенційно зачеплених вузлів, а не по усьому дереву.
Важливо памʼятати, що DOM API не використовує саме цей рушій, але окремі операції можуть виглядати схоже. Наприклад,
closest() ззовні може нагадувати рух селектором справа наліво, бо йде вгору по дереву. Проте під капотом він просто розбиває комплексний селектор на частини й викликає matches() на кожному предку. matches() же працює через Selector API, а не через CSS matching, тому алгоритм там зовсім інший.Той же
querySelector прямує вниз деревом, а селектор перебирає зліва направо. І операції з DOM використовують Selector API, а не іпмлементацію CSS-рушія, тож і алгоритми, і оптимізації, і підходи загалом можуть суттєво відрізнятись.Загалом цей підхід спрямований не на якесь там "прискорення селекторів", а для забезпечення контрольованості інвалідації стилів. Завдяки такому напрямку браузер не перевіряє весь DOM, а працює локально — що й дозволяє CSS залишатися ефективним навіть на велетенських деревах.
Однак це не означає, що тепер можна видихнути і писати селектори на 15 складових. Треба памʼятати, що бравзеру однак доводиться виконувати титанічний обсяг роботи, особливо в умовах високодинамічних інтерфейсів. І якщо ми йому в цьому допоможемо, пишучи максимально прості селектори, він на нас точно не образиться.
Що почитати:
📖 The truth about CSS selector performance
@babichdev
❤61👍18🔥8
#партнерський_допис
Товариство, якби хто з вас мав бажання створити власну ІТ-компанію, то маєте чудову нагоду дізнатися, як саме це можна зробити.
Growth Factory проводитиме воркшоп "Як почати працювати напряму із замовниками і стартувати власний IT-бізнес", на якому Олег Мелешко, засновник Incode Group (≈200 людей) та фулстек-розробник, покаже, як виглядає шлях від першого проєкту до власної команди з 10 людей і компанії.
На цьому воркшопі ви дізнаєтеся:
— З чого реально починається сервісна IT-компанія і що робити в перший місяць;
— Як знайти свій перший проєкт, якщо вас ніхто не знає;
— Як діяти, щоб вирости до 5–10 людей у команді;
— Перші рішення та фреймворки, які запускають бізнес;
— Як має виглядати процес роботи;
А ще разом створите просту CRM для управління проєктами, якою можна буде користуватися хоч просто вже.
Участь у воркшопі безкоштовна. Реєструйтесь та почніть робити перші кроки до власного IT-бізнесу: https://bit.ly/4pBgxd0
P.S. 100% коштів за розміщення допису спрямовано на потреби ЗСУ.
Товариство, якби хто з вас мав бажання створити власну ІТ-компанію, то маєте чудову нагоду дізнатися, як саме це можна зробити.
Growth Factory проводитиме воркшоп "Як почати працювати напряму із замовниками і стартувати власний IT-бізнес", на якому Олег Мелешко, засновник Incode Group (≈200 людей) та фулстек-розробник, покаже, як виглядає шлях від першого проєкту до власної команди з 10 людей і компанії.
На цьому воркшопі ви дізнаєтеся:
— З чого реально починається сервісна IT-компанія і що робити в перший місяць;
— Як знайти свій перший проєкт, якщо вас ніхто не знає;
— Як діяти, щоб вирости до 5–10 людей у команді;
— Перші рішення та фреймворки, які запускають бізнес;
— Як має виглядати процес роботи;
А ще разом створите просту CRM для управління проєктами, якою можна буде користуватися хоч просто вже.
Участь у воркшопі безкоштовна. Реєструйтесь та почніть робити перші кроки до власного IT-бізнесу: https://bit.ly/4pBgxd0
P.S. 100% коштів за розміщення допису спрямовано на потреби ЗСУ.
👍6🔥6❤3
#думки_вголос
Часто, коли мова йде про сучасний стан на ринку, звучить думка про джунів та їхню нелегку долю. І, хоч я й згоден із тим, що ситуація далека від бажаного стану речей, маю одне зауваження. Річ у тім, що відчутна частка як роботодавців, так і кандидатів, чомусь досі керуються поняттям джуна, яке вже дуже застаріло.
Через це компанії відмовляються від найму джунів, а кандидати свідомо лишаються в цих застарілих рамках, що призводить до очевидного — і ті і ті не хочуть змінюватися, і як наслідок, одні лишаються без інженерів, а інші без роботи.
Індустрія змінюється, до того ж стрімко, як ніколи до того. Той рівень знань та навичок, яких раніше цілком вистачало, аби вважатися джуном, а подекуди й мідлом, нині переходять до категорії "вимог за замовчуванням", тобто очікуються від людини, яка лише думає потикати носа в ІТ.
В першу чергу треба змінити наше сприйняття цих вимог. Те, що досі продається більшістю курсів (і я кажу не лише про школи, а й про безкоштовні онлайн продукти), вже не є розкішним максимумом, а ледь-ледь дошкрябує до необхідного мінімуму.
Суто технічні навички й знання поступово відходять на задній план, особливо, якщо вони не підкріплені іншими навичками, зокрема тим самим продуктовим мисленням, вмінням вирішення задач бізнесу та інших речей, які ми досі вважаємо маркетинговою маячнею.
Ще одна суттєва проблема сьогодення — гайп. Індустрія знаходиться в перехідному періоді, через який проходили безліч інших галузей, коли змінювалися технології, на яких ґрунтувалися ці галузі. Очевидно, що з появою інструменту, який робить те, що до того робило десять людей, першою думкою буде звільнити тих десять людей. Але, як показує історія, з часом зʼявляються нові робочі місця, галузь переживає новий бум. Але в іншому вигляді, з іншим фокусом, іншими критеріями.
Згадайте книжкову справу. З появою друкарського пресу зник цілий прошарок професій. Але чи зникла індустрія? Чи стало там працювати менше людей? Просто подивіться на галузь сьогодні. Вона настільки далека від того, чим була сотні років тому, як космічні кораблі від брички.
Що бізнесу, що фахівцям потрібно змінюватися. Змінювати своє бачення того, хто є джуном, мідлом, синьйором. Сьогодні ця лінія розмивається настільки, що й дійсно людина з неглибокими технічними знаннями, але хорошими софт навичками та клепкою в голові, може робити більше, аніж бородань, який чудово пише код, але при цьому лише пише код.
Це не катастрофа, це кінець світу. Просто ми в такий час, що дійсно треба бігти щодуху, аби просто тримати екпрес прогресу просто в полі зору.
І так, як би не було прикро, наздоженуть його далеко не усі. Це теж треба враховувати. Багато з нас, навіть ті, хто в індустрії вже давно, просто не витримають темпу.
Тому треба вчитися не лише писати код, а, насамперед, створювати продукт, результат. А код тепер — не основна цінність, а лише засіб вираження рішення проблеми.
Як саме цього досягнути — я, на жаль, універсального рецепту не маю. Це покладається на вас самих. Шукайте способи, досліджуйте, експериментуйте, усвідомте свою цінність і потреби ринку. Можливо, ваша цінність в тому, чого ринок ще не чекає, хто зна.
Головне не сидіть камінцем на тому, чого ринок вже не чекає.
Якось так.
@babichdev
Ринок може вже й не чекає чогось, а от я на ваші вподобайки чекаю.
Часто, коли мова йде про сучасний стан на ринку, звучить думка про джунів та їхню нелегку долю. І, хоч я й згоден із тим, що ситуація далека від бажаного стану речей, маю одне зауваження. Річ у тім, що відчутна частка як роботодавців, так і кандидатів, чомусь досі керуються поняттям джуна, яке вже дуже застаріло.
Через це компанії відмовляються від найму джунів, а кандидати свідомо лишаються в цих застарілих рамках, що призводить до очевидного — і ті і ті не хочуть змінюватися, і як наслідок, одні лишаються без інженерів, а інші без роботи.
Індустрія змінюється, до того ж стрімко, як ніколи до того. Той рівень знань та навичок, яких раніше цілком вистачало, аби вважатися джуном, а подекуди й мідлом, нині переходять до категорії "вимог за замовчуванням", тобто очікуються від людини, яка лише думає потикати носа в ІТ.
В першу чергу треба змінити наше сприйняття цих вимог. Те, що досі продається більшістю курсів (і я кажу не лише про школи, а й про безкоштовні онлайн продукти), вже не є розкішним максимумом, а ледь-ледь дошкрябує до необхідного мінімуму.
Суто технічні навички й знання поступово відходять на задній план, особливо, якщо вони не підкріплені іншими навичками, зокрема тим самим продуктовим мисленням, вмінням вирішення задач бізнесу та інших речей, які ми досі вважаємо маркетинговою маячнею.
Ще одна суттєва проблема сьогодення — гайп. Індустрія знаходиться в перехідному періоді, через який проходили безліч інших галузей, коли змінювалися технології, на яких ґрунтувалися ці галузі. Очевидно, що з появою інструменту, який робить те, що до того робило десять людей, першою думкою буде звільнити тих десять людей. Але, як показує історія, з часом зʼявляються нові робочі місця, галузь переживає новий бум. Але в іншому вигляді, з іншим фокусом, іншими критеріями.
Згадайте книжкову справу. З появою друкарського пресу зник цілий прошарок професій. Але чи зникла індустрія? Чи стало там працювати менше людей? Просто подивіться на галузь сьогодні. Вона настільки далека від того, чим була сотні років тому, як космічні кораблі від брички.
Що бізнесу, що фахівцям потрібно змінюватися. Змінювати своє бачення того, хто є джуном, мідлом, синьйором. Сьогодні ця лінія розмивається настільки, що й дійсно людина з неглибокими технічними знаннями, але хорошими софт навичками та клепкою в голові, може робити більше, аніж бородань, який чудово пише код, але при цьому лише пише код.
Це не катастрофа, це кінець світу. Просто ми в такий час, що дійсно треба бігти щодуху, аби просто тримати екпрес прогресу просто в полі зору.
І так, як би не було прикро, наздоженуть його далеко не усі. Це теж треба враховувати. Багато з нас, навіть ті, хто в індустрії вже давно, просто не витримають темпу.
Тому треба вчитися не лише писати код, а, насамперед, створювати продукт, результат. А код тепер — не основна цінність, а лише засіб вираження рішення проблеми.
Як саме цього досягнути — я, на жаль, універсального рецепту не маю. Це покладається на вас самих. Шукайте способи, досліджуйте, експериментуйте, усвідомте свою цінність і потреби ринку. Можливо, ваша цінність в тому, чого ринок ще не чекає, хто зна.
Головне не сидіть камінцем на тому, чого ринок вже не чекає.
Якось так.
@babichdev
Ринок може вже й не чекає чогось, а от я на ваші вподобайки чекаю.
❤86🔥9👍6🤔3
Так, товариство, дрон, на який ми збирали, а саме DJI Mini 4 Pro для 115-ї бригади, вже дістався адресатів та почав виконувати свої завдання.
Остаточна вартість дрона склала 48 154 гривні.
Дякую усім, хто долучився до збору бодай гривнею!
P.S. Розіграш в банці я вже провів, напишу про переможця, щойно ця людина мені відкриє контакти та я з нею звʼяжусь. Нагадую, що розігрував я ось таке Lego. Дуже сподіваюсь, що його таки заберуть, і не доведеться його розігрувати ще раз. І ще раз. І ще.
Остаточна вартість дрона склала 48 154 гривні.
Дякую усім, хто долучився до збору бодай гривнею!
P.S. Розіграш в банці я вже провів, напишу про переможця, щойно ця людина мені відкриє контакти та я з нею звʼяжусь. Нагадую, що розігрував я ось таке Lego. Дуже сподіваюсь, що його таки заберуть, і не доведеться його розігрувати ще раз. І ще раз. І ще.
❤13🔥5