Понимаю, что у вас другой опыт. Но я нигде не видел, чтобы кто-то использовал process.nextTick() напрямую. Тоже самое про requestAnimationFrame. Вполне возможно, что как раз тот самый формошлёп, о котором вы говорите.
По моему опыту - никто даже на бэкенде в такие низкоуровневые дебри не лезет. Большинство использует сторонние пакеты, которые это все инкапсулируют. Спорить не буду что есть какие-то конторы где нужен низкоуровневый код, только вот думаю их сильно меньше, чем любителей задавать такие вопросы на собеседованиях.
Я замечаю, что в большинстве статей показывается позиция EM как некое продолжение позиции Tech Lead. Это еще более странно, видя рекомендацию на книгу The Manager's Path. EM это другая ветка от Engineer. Tech Lead - это вообще временная роль, а не ступенька на картерной лестнице.
Исходя из прогрессии в начале статьи - инженерные задачи выше Senior Engineer в организациях решает никто, ведь все инженеры должны непременно стать менеджерами (или уйти). А задача менеджеров - подбирать методологию и тикеты приоритизировать.
Я думаю, было бы полезнее разделять путь инженера и путь менеджера, ибо задачи у них разные, особенно на уровне выше Senior.
Все ждал, когда же кто-то вспомнит как минимум про ErgoDox EZ. Тут и сплит, и слои, и полностью переназначаемые клавиши (есть даже комбинации и макросы). Цена только кусается.
После установки пары коронок и имплантов приходится пользоваться чуть ли не всем арсеналом из списка, чтобы поддерживать хотя бы нормальное состояние десен — а все из-за того что в местах имплантов образуются десенные карманы, где обожают скапливаться бактерии.
Про ирригатор соглашусь — вещь жутко полезная. Странно даже, почему далеко не все стоматологи его рекомендуют.
Есть хорошая платформа для изучения и понимания основ математики (и не только) — https://brilliant.org/. Но, увы, только на английском. Объяснения визуализированы, идут сразу с задачами на закрепление понимания.
Интересно, собираются ли они такую же политику устраивать в недавно купленном Keybase? Ну а вообще — тренд на "приватность как премиум услуга" сильно печалит.
У нас, помню тоже была похожая ситуация в React-приложении. IntersectionObserver использовать не стали — ибо была нужна поддержка IE11. Наш выбор пал на react-waypoint. Сработал на ура, если отбросить кое-какие ограничения по стилям родителя и сузить использование до ленивого рендеринга (+ ленивой загрузки) react-компонентов.
Для более гранулированного контроля, конечно, вряд ли подойдёт.
Сам использую Yubikey с forcesig. Довольно удобно (кроме необходимости вводить пин для каждой операции) и надёжно. Но для более быстрого сетапа можно попробовать Krypton.
Хороший набор, но вот Enzyme я бы не включал, а заменил бы на react-testing-library. Поддержка Enzyme для React 16 так себе, да и в целом они сильно тормозят с новыми фичами.
Список изменений впечатляет, жаль только, что с ExtractTextPlugin они не сильно спешат. Для веба это просто маст хэв, а текущая стабильная версия с новым webpack работать не может — API для плагинов сменили кардинально.
Фича с указанием sideEffects выглядит весьма многообещающе. Очень надеюсь, что она наконец починит Tree shaking.
Не гребите всех под одну гребёнку. Фармошлёпов хватает во всех языках. Сам факт появления NodeJS (как и других библиотек/движков/языков) недвузначно намекает, что не всем нравится java/C# на бэкенде. Называть людей фармошлёпами только потому что они решили попробовать что-то новое, ИМХО, несправедливо.
И опять же — никто не забирает хлеб у Java/C# — в них тоже денег вливают неплохо. За ними тоже не кто-попало стоит. У всех свои ниши и NodeJS — не серебряная пуля, как, впрочем, и Java/C#.
Полностью согласен. Очень многие вещи усваиваются с полпинка. Как вы сказали — это уже не та жесть, которую писали 10 лет назад.
ES6 для меня был как глоток свежего воздуха. Последующие стандарты только улучшают ситуацию.
Я думаю, что люди из других языков и парадигм нужны в JS сообществе. Способность посмотреть на вещи под другим углом может привнести (и зачастую, привносит) хорошие идеи.
Согласен со многими фактами, приведенными в статье, но позвольте несколько замечаний и вопросов (я JS разработчик).
1. const — слышу о нём почти отовсюду. Но вот незадача — почему все думают что он должен работать точно так же как в С/С++/<вставьте любимый язык>. Я не спорю, реализация у него не лучшая, но это специфичная для языка конструкция, коротая имеет довольно простую функцию.
2. this — подобно const, крайне непонятая многими особенность языка. И опять же — использовать её необязательно.
3. Отсутствие нормальных классов/ООП. Недостаток только для людей, которые привыкли к ООП. Но соглашусь, те попытки создать ООП в JS, которые были — очень далеки от привычных многим концепций в Java/C/C++/C#/<добавьте свой язык>.
4. «Многомиллионные инвестиции кровавых денег от больших корпораций». Вы так говорите, как будто это что-то плохое. Ни один язык не станет популярным на голом энтузиазме его последователей. Нужны деньги, нужна реклама, нужна раскрутка. Как, по-вашему, работодатели узнают о языке/библиотеке/фреймворке, если он на слуху только в технических кругах?
В общем и целом, я к тому, что у всех языков есть недостатки и достоинства. У всех есть свои ниши и свои задачи. Языки — всего лишь инструменты.
С тем же NodeJS, многие его хаят за то, что он посягает на святая-святых — backend. Но я думаю, что если JS не подходит для backend и он настолько плох — разработчики будут жаловаться. Жалобы поднимут дискуссии, появятся решения, новые версии, патчи и исправления. И если этого будет недостаточно, то люди перестанут этим языком пользоваться. И он уйдёт из этой ниши. На его место прийдет другой и попытается привлечь к себе внимание, чтобы начать дискуссию. Потому как дискуссия и обсуждение — главные способы сделать язык лучше.
Java тоже не сразу стала удобной. Её тоже не все готовят правильно, есть жуткий код, есть хороший.
С радостью выслушаю мнения насчет JS и его представления на уровне backend.
1. Наполнить пятилитровый кувшин водой
2. Из пятилитрового кувшина наполнить трёхлитровый кувшин (в пятилитровом останется 2 литра воды)
3. Вылить всю воду из трёхлитрового кувшина и перелить 2 литра воды из пятилитрового кувшина.
4. Наполнить пятилитровый кувшин водой
5. Наполнить заполненый на 2 литра трёхлитровый кувшин водой из полного пятилитрового кувшина (потребуется 1 литр воды)
В итоге, в пятилитровом кувшине останется 4 литра воды.
Я так понимаю, они внедрили Apple Passkeys в своём логине. У нас такое уже давно работает, единственная проблема - не было шаринга между устройствами.
Если не секрет, что за проект и для чего используете эти API?
Понимаю, что у вас другой опыт. Но я нигде не видел, чтобы кто-то использовал
process.nextTick()напрямую. Тоже самое проrequestAnimationFrame. Вполне возможно, что как раз тот самый формошлёп, о котором вы говорите.По моему опыту - никто даже на бэкенде в такие низкоуровневые дебри не лезет. Большинство использует сторонние пакеты, которые это все инкапсулируют. Спорить не буду что есть какие-то конторы где нужен низкоуровневый код, только вот думаю их сильно меньше, чем любителей задавать такие вопросы на собеседованиях.
Я бы с радостью почитал про ветку IC! Я думаю что эта тема очень слабо освещена.
Я замечаю, что в большинстве статей показывается позиция EM как некое продолжение позиции Tech Lead. Это еще более странно, видя рекомендацию на книгу The Manager's Path. EM это другая ветка от Engineer. Tech Lead - это вообще временная роль, а не ступенька на картерной лестнице.
Исходя из прогрессии в начале статьи - инженерные задачи выше Senior Engineer в организациях решает никто, ведь все инженеры должны непременно стать менеджерами (или уйти). А задача менеджеров - подбирать методологию и тикеты приоритизировать.
Я думаю, было бы полезнее разделять путь инженера и путь менеджера, ибо задачи у них разные, особенно на уровне выше Senior.
Все ждал, когда же кто-то вспомнит как минимум про ErgoDox EZ. Тут и сплит, и слои, и полностью переназначаемые клавиши (есть даже комбинации и макросы). Цена только кусается.
После установки пары коронок и имплантов приходится пользоваться чуть ли не всем арсеналом из списка, чтобы поддерживать хотя бы нормальное состояние десен — а все из-за того что в местах имплантов образуются десенные карманы, где обожают скапливаться бактерии.
Про ирригатор соглашусь — вещь жутко полезная. Странно даже, почему далеко не все стоматологи его рекомендуют.
Есть хорошая платформа для изучения и понимания основ математики (и не только) — https://brilliant.org/. Но, увы, только на английском. Объяснения визуализированы, идут сразу с задачами на закрепление понимания.
Сарказм скорее к тому, что это хоть и технически возможно (вы на своём примере показали), но для многих компаний экономически невыгодно.
Интересно, собираются ли они такую же политику устраивать в недавно купленном Keybase? Ну а вообще — тренд на "приватность как премиум услуга" сильно печалит.
У нас, помню тоже была похожая ситуация в React-приложении. IntersectionObserver использовать не стали — ибо была нужна поддержка IE11. Наш выбор пал на react-waypoint. Сработал на ура, если отбросить кое-какие ограничения по стилям родителя и сузить использование до ленивого рендеринга (+ ленивой загрузки) react-компонентов.
Для более гранулированного контроля, конечно, вряд ли подойдёт.
Сам использую Yubikey с forcesig. Довольно удобно (кроме необходимости вводить пин для каждой операции) и надёжно. Но для более быстрого сетапа можно попробовать Krypton.
Хороший набор, но вот Enzyme я бы не включал, а заменил бы на react-testing-library. Поддержка Enzyme для React 16 так себе, да и в целом они сильно тормозят с новыми фичами.
Читать Reddit из терминала — самое важно в веб-разработке.
Список изменений впечатляет, жаль только, что с ExtractTextPlugin они не сильно спешат. Для веба это просто маст хэв, а текущая стабильная версия с новым webpack работать не может — API для плагинов сменили кардинально.
Фича с указанием sideEffects выглядит весьма многообещающе. Очень надеюсь, что она наконец починит Tree shaking.
Не гребите всех под одну гребёнку. Фармошлёпов хватает во всех языках. Сам факт появления NodeJS (как и других библиотек/движков/языков) недвузначно намекает, что не всем нравится java/C# на бэкенде. Называть людей фармошлёпами только потому что они решили попробовать что-то новое, ИМХО, несправедливо.
И опять же — никто не забирает хлеб у Java/C# — в них тоже денег вливают неплохо. За ними тоже не кто-попало стоит. У всех свои ниши и NodeJS — не серебряная пуля, как, впрочем, и Java/C#.
Полностью согласен. Очень многие вещи усваиваются с полпинка. Как вы сказали — это уже не та жесть, которую писали 10 лет назад.
ES6 для меня был как глоток свежего воздуха. Последующие стандарты только улучшают ситуацию.
Я думаю, что люди из других языков и парадигм нужны в JS сообществе. Способность посмотреть на вещи под другим углом может привнести (и зачастую, привносит) хорошие идеи.
1. const — слышу о нём почти отовсюду. Но вот незадача — почему все думают что он должен работать точно так же как в С/С++/<вставьте любимый язык>. Я не спорю, реализация у него не лучшая, но это специфичная для языка конструкция, коротая имеет довольно простую функцию.
2. this — подобно const, крайне непонятая многими особенность языка. И опять же — использовать её необязательно.
3. Отсутствие нормальных классов/ООП. Недостаток только для людей, которые привыкли к ООП. Но соглашусь, те попытки создать ООП в JS, которые были — очень далеки от привычных многим концепций в Java/C/C++/C#/<добавьте свой язык>.
4. «Многомиллионные инвестиции кровавых денег от больших корпораций». Вы так говорите, как будто это что-то плохое. Ни один язык не станет популярным на голом энтузиазме его последователей. Нужны деньги, нужна реклама, нужна раскрутка. Как, по-вашему, работодатели узнают о языке/библиотеке/фреймворке, если он на слуху только в технических кругах?
В общем и целом, я к тому, что у всех языков есть недостатки и достоинства. У всех есть свои ниши и свои задачи. Языки — всего лишь инструменты.
С тем же NodeJS, многие его хаят за то, что он посягает на святая-святых — backend. Но я думаю, что если JS не подходит для backend и он настолько плох — разработчики будут жаловаться. Жалобы поднимут дискуссии, появятся решения, новые версии, патчи и исправления. И если этого будет недостаточно, то люди перестанут этим языком пользоваться. И он уйдёт из этой ниши. На его место прийдет другой и попытается привлечь к себе внимание, чтобы начать дискуссию. Потому как дискуссия и обсуждение — главные способы сделать язык лучше.
Java тоже не сразу стала удобной. Её тоже не все готовят правильно, есть жуткий код, есть хороший.
С радостью выслушаю мнения насчет JS и его представления на уровне backend.
1. Наполнить пятилитровый кувшин водой
2. Из пятилитрового кувшина наполнить трёхлитровый кувшин (в пятилитровом останется 2 литра воды)
3. Вылить всю воду из трёхлитрового кувшина и перелить 2 литра воды из пятилитрового кувшина.
4. Наполнить пятилитровый кувшин водой
5. Наполнить заполненый на 2 литра трёхлитровый кувшин водой из полного пятилитрового кувшина (потребуется 1 литр воды)
В итоге, в пятилитровом кувшине останется 4 литра воды.