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

що там складного? Singleton vs Scoped vs Transient?

заходять а бар Фейковий ФОП, Копач бурштину, Євробляхер і Ухилянт...

Зрадо..кий пост. Ніхто не заважає інкорпоруватись в іноземній юриздикції. В США можна відкрити LLC / LP / INC для іноземців, і мати доступ до всіх благ і платити близько 25%.

Гарна стаття, дякую. Новий рівень з кодом.

«Українські діячі і філософи краще висловились з цього питання» Михайло Басюк

тому що ця думка від інфоцигана, який не має жодної власної позициї і міняє свою позицію в залежності від того хто сьогодні платить.

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

Так вони ж аппелюють до принципу відсутності дискримінації за статтю при прийомі на роботу?
Це просто двулічіє і ліцемірство, боротися за це і ігнорувати очевидні дискримінації за статтю просто тому що це не твоя стать

Валідний аргумент, і все ж таки я про інше. Чи вважаєте Ви що часто буває вигідно об‘єднатися невеликою групою і захистити права конкретно вашої групи, навіть якщо це гра з нульовою суммою? Чи всі такі об‘єднання є аморальними за своєю суттю, і чи завжди статус-кво більш морально виправданий просто по факту того що він історично склався. Приклад, студенти хочуть більшу стипендію, пенсіонери більшу пенсію, україномовні — державну українську, ну і т.д

Це ви серйозно? А хто він такий?

Яке це має значення якщо думка правильна?

Так принцип простий — при прийомі на роботу не повинно бути дискримінації за статевою ознакою, віком, сексуальною орієнтацією, коліру шкіри і т.д. Це навіть записано в українському законодавстві.
Не прийом на роботу через те що кандидат жінка, чи через те що кандидат чоловік — це рівнозначно неправильно і повинно засуджуватися.

Принцип простий, але перехід

А чому борці за гендерну нерівність і дискримінацію при прийомі на роботу за статтю мовчать

невірний. Борці можуть пред’явити по одному конкретному питанню, і вирішувати по одному питанню за раз.

По Арестовичу політик потрібен щоб мати політичну позицію по конкретному питанню. Захистити жінок від дискримінації це позиція, захистити всіх від всіх і зважити всі за і проти це не позиція яка на щось впливає.

В чому різниця між професійним фронтет розробником з багаторічним досвідом і позером, який подивився кілька відяшок в ютуб?

Для новачків / менеджерів / бекенд розробників підсумок:
Не намагайтесь реюзати html і css, а якщо і намагаєтесь маєте розуміти базові обмеження чого це дуже складно.

Якщо хочете зберегти час і мати нормальний дизайн методологія така:
1) Використовуєте тулу яка не модифікує каскадом дочірні елементи. Фотошоп або фігма, або щось подібне і малюєте там як все має бути
2) Імлементите в css. Важливо писати css від parent до child. Спочатку html, body, container і т.д. Намагайтесь не модифікувати parent елементи, якщо не хочете перевіряти все по кругу. В ООП аналогом є зміни в parent класу.
3) уникайте використання разом css компонентів які не тестувались разом, наприклад від різних вендорів. Уникайте намагання реюзати css код — засунути те що зробили в компоненту і потім десь переюзати — не вийде. Якщо хтось намагається змусити вас реюзати його «компоненти», розповідає про беми, що це реально — ідіть до менеджера і покажіть цей коментар. Менеджеру: не потрібно так робити. Перевикористання коду на UI тільки через шаблони дизайнера і через протестовані компоненти 3-rd party вендорів. Ніколи через компоненти всередині команди яка робить конкретну імплементацію.

Перший результат в гуглі:

BEM — is a methodology that helps you to create reusable components and code sharing in front‑end development

Питання, чого немає чоловічого «білка», «видра», «жаба», але є «лев», «тигр», «яструб»

Коли всі ці конвеншони створювались, то в розробників була проблема, яку ці конвеншони й вирішували.

Не зовсім так, мати конвеншени в css це приємний бонус. Але давайте пройдемось як приймаються рішення в IT.
1) Є реальна практична проблема
2) Багато практиків і теоретиків бачать проблему і її обговорюють, і діляться своїм баченням для рішення.
3) Хороші рішення знаходять гарні відгуки, це оформлюється в якусь обгортку і презентується ширшій удиторії на конференціях і форумах
4) Далі може іти хайп, експерти продають це рішення як проривне, що допоможе їх бізнесу, і далі бізнес створює пропозицію — шукають розробників які знайомі з новою мегатехнологіїєю, або методологією.
5) Далі купа людей іде на доу і клеймить що є така технологія і я в ній експерт, ось тут і тут вона корисна.

Нічого такого коли технологія дійсно проривна, наприклад OOP, FP, CSS3, Android, Figma, jQuery, JS, Java, C#, C++, Bootstrap;

Проблеми починаються коли підключається бізнес який аналізує цей флов і починає просувати свої технології починаючи з 4) і 5) без ключового — 1) відсутність реальної практичної проблеми, або 2) відсутності розуміння першопричини і зрорової дискусії з пошуку оптимального рішення, або хоча б рішення яке не робить прямо протилежне для вирішення заявленої проблеми.

Приклади таких BS технологій: BEM, Webpack, Docker, Microservices, CQRS;

Тобто для прикладу BEM який просувався яндексом рекламувався як технології ізоляції для всіх включаючи менеджерів і розробників з backend background які не розуміють що таке css.

А те що ви пишете про прийняття елементом стилей від батьківського елемента, то це те саме, що функція всередині функції має доступ до змінних батьківської функції. Ви ж не намагаєтесь такі змінні ізолювати, правильно?

В сценарії з двома «компонентами» найближча аналогія це множинне наслідування — від двох батьків, яке не підтримується більшістю мов. Селектор з правилом ближче до OOP класу ніж до проперті

Типовий bait and switch, нічого нового. Ми вже визначились що таке ізоляція і як мають працювати компоненти в нормальному розумінні.

Це правда, але продаються вони як технологія ізоляції з якою можна побудувати компоненти.

Ок, можеш нагадати як працює top і left? І це один з прикладів

ну тобто реальних окремих технологій для ізоляцій стилів не існує, за визначенням ізоляції. той костиль що робить web components \ CSS Modules це просто жесть, і не допомагає в дуже простих випадках, як-от в прикладі коли line-height потрібно поміняти на parent елементі.
Цікаво що далеко не всі команди роблять висновки з базових знань про css, і організовують процеси розробки UI на основі уявних технологій «ізоляції», «компонентів», і витрачають купу сил на регресії, по вуха в UI-багах з пропущеними дедлайнами, і купою обмежень і виправдань.
А без жодних ізоляцій заімплементити figma/ps -шаблончик не дозволяє релігія.

Згоден з 1) з 2) не зовсім, так як в css є документовані правила за якими визначається фінальний результат. Тобто для css engine ніяких конфліктів не буває, вони бувають тільки в голові розробника якому лінь запам‘ятовувати ці правила, і якщо очікування розробника не співпадають з тим як конкретно розраховується стиль, то це більше проблема самого розробника. Можете дати приклад як зможе наприклад sass namespace ізолювати стиль який приходить з каскаду. Ось я напишу в якійсь депенденсі body line-height : 1.3em; font-family: serif; Як ви думаєте багато компонентів написані в цими компонентами залишаться ізольованими

Ваш покірний слуга ділиться своїм скромним досвідом. В моєму випадку дуже допомагав фігма шаблон, або фотошоп. Якщо є точні розміри що і як має бути, особливо в різних розмірах а ще з анімацією, який консистентний це допомагає набагато більше ніж намагання приводити в порядок css. А відсутність цього сповільнює і створює пррблем набагато більше ніж складний css, без відсутності конвенцій, написаний різними вендорами і т. д.