Тут тонкость в том, что если неугодной стала одна статья, то по HTTP можно заблокировать один отдельный URL, а по HTTPS URL передается в зашифрованном виде. Поэтому блокировать будут ресурс целиком, как с GitHub было.
Если Хабр останется совсем без политики, то, думаю, на него HTTPS повесить можно будет без ущерба для ресурса в целом.
Видно, что обновление нацеленно на тех, кто по скайпу в основном звонится и передает файлы. А вот для тех, у кого 10-15 чатов по 60-300 человек в каждом, нововведения не из приятных.
Тут такое дело. Приходит выросший ребенок, которого никогда особо не заставляли делать то, что ему не хочется, на работу. И начинается:
— У, у вас фреймворк не модный используется, на этом не хочу писать!
— Эээ, мне эта задача неинтересна.
— Ну, требования странные какие-то, мне не хочется в них разбираться.
И так далее. Я считаю, что работа должна быть интересной, но даже на самой лучшей работе порой приходится заниматься какими-то нудными и не самыми приятными задачами.
Ребенка надо учить хорошему слову «Надо». Но и совсем загонять не стоит. В конце концов, работу тоже можно поменять, если она совсем не нравится. Проголосовал за второй вариант.
Тоже, на мой взгляд, антипаттерн. Сразу сообщать данные своей карты какой-то левой системе? Кроме того, если деньги не сразу снимаются, и есть, например, триальный период, то лучше позволить пользователю заплатить тогда, когда это будет нужно. И если ему это будет нужно.
Конечно, антипаттерн. Мы столько копий наломали с руководством, чтобы от него избавиться!
Там вообще много таких скользких мест было, которые зародились на раннем этапе, когда введение одного такого антипаттерна позволяло платить зарплату еще одному члену команды. Потом, когда сервис стал крупнее, все это было уже не нужно, но уговорить людей получать на, скажем, сто тысяч долларов в месяц бывает тяжело.
Сейчас, насколько знаю — меня в той команде уже нет — остался только один косяк: на сайте указан номер службы техподдержки, работающей 24/7, но за номером робот, который регистрирует звонок. Поддержка потом переходит в режим общения по email и звонит клиенту только если он грозит чарджбеком.
За такое вообще убивать хочется. Особенно, когда некоторые извращенцы яваскриптом Ctrl+c/Ctrl+v в этих полях блокируют.
Мы ведь тоже так делали 2 года: пупблика на сайте была непродвинутая и ошибки в почте были часто. Причем мы сразу просили данные карты, и потом снимали с людей денег. И получалось: есть аккаунт, с которого идут деньги, но которому не удается отправить подтверждение. Часто люди платили месяцами и пользовались. Но иногда человек получал очередной платеж, видел его в банке, но не узнавал и заказывал chargeback.
Одно время это был основной источник чарджбеков, и мы пробовали разные варианты. Нужно было и денег не потерять, и на счетчик в платежной системе не вставать. Вариант «следить за тем, что пользователь имеет неподтвержденный мейл и отменять ему подписку» сильно бил по карману. Вариант «вводить почту дважды» снижал конверсию, но в результате по деньгам мы теряли меньше.
Потом через два года попробовали другой вариант: проверять популярные почтовые домены и сравнивать юзернейм в адресе почты и в нашей системе и подсказывать, если есть подозрения. Оказался лучшим со всех сторон.
Кстати, требовать вводить пароль два раза при регистрации и смене пароля — это пережиток прошлого. Если человек опечатается — а такое случается редко-редко — всегда можно воспользоваться восстановлением пароля еще раз.
Из то же оперы следующие сценариями, которые долгое время считались единственно правильными и возможными:
1. Иметь длинную форму регистрации.
2. Требовать вбить пароль при регистрации 2 раза.
3. Иметь длинную форму регистрации и сбрасывать поля ввода пароля и подтверждения, если валидация других полей не прошла.
4. Требовать вбить 2 раза адрес электронной почты.
5. Не давать пользоваться сервисом, пока в письме на ссылку не нажмешь.
И т.д, Сегодня большинство пунктов — дикость. Желательно иметь вообще 2 поля при регистрации и логине — почта и пароль. Плюс социальные кнопки по желанию.
Все больше проектов перенимают такую систему релизов, привязанных к календарю. Не знаю, кто первым это начал, но посмотрите на список:
Ubuntu — релиз каждые полгода, есть LTS-версии
Chrome — релиз каждые 6 недель, есть несколько каналов обновления
Firefox — релиз каждые 6 недель, есть LTS-версии и несколько каналов обновления
Haskell Platform — релиз каждый год, опциональные релизы в течение года
Ember.JS — релиз каждые 6 недель, несколько каналов обновления
Есть планы по переходу на такой режим стандарта ECMAScript: релиз каждый год, WHAT WG тоже перешло на регулярный перевыпуск стандарта HTML5 (но там как таковых версий нет). В Node.js разработчики говорили о планах перейти на регулярные релизы после выпуска 1.0. В Django официально такой политики регулярных релизов нет, но по факту разработчики следуют четкому расписанию.
В общем, примеров масса и со временем их становится больше.
Ага, идея была «внимание привлечь». Мол, «с первых секунд пользователь услышит интересную ему информацию и сразу пидет к нам».
Еще одно время — где-то в 2005-2008 годах были популярны разъезжающиеся баннеры. Случайно проведешь по нему, а он растягивается почти на всю видимую часть страницы. Часто при этом включалась бешеная анимация и звук. Тоже воспаленная мысль маркетологов двигалась в направлении «пользователь навел мышь на баннер, значит ему интересно наше предложение — нужно его убедить, пока внимание не переключилось на что-то другое». То, что баннер часто лепили между, скажем, навигацией по сайту и статьей, никого не волновало.
Еще какое-то время были популярны рекламные псевдо-ссылки. По всему тексту слова и фразу подчеркивались, но вместо перехода на другую страницу этого или другого сайта при наведении показывался баннер. Помню, одно время эти псевдо-ссылки так раздражали всех, что поднялась шумиха насчет их запрета или регулирования. Одна такая служба, помню, первой добровольно решила, что будет выделять свои рекламные ссылки двумя подчеркиваниями, а не одним, чтоб пользователей не путать. Но все равно они раздражали жутко. Попропадали они после того, как Google стал страницы с такой рекламой в выдаче понижать.
Ну и AirPush на мобильниках — тоже пример того, как рекламу не надо делать.
Насколько мне известно, основная причина запрета смартфонов — это не то, что ученики подсмотрят что-то и спишут. Цель запрета — сократить уровень преступности в школах. Основной источник проблем в школах — по крайней мере, в наших странах — воровство и притеснение одних учеников другими (bulling). Проблемы возникают у тех учеников, кто чем-то отличается в глазах сверстников. В основном это:
— шмотки: у Ленки кожаные штаны крутые, все девочки завидуют, все мальчики «фантазируют». Могут и порезать штаны, и самой Лене может достаться. Или наоборот — Лена станет крутой и популярной, и доставаться будет тем, кто к Лене в свиту не попал.
— косметика: новая Машина помада может послужить отличным инструментом для макияжа в стиле «Джокер», правда?
— мобильники
Поэтому в школах часто вводят форму — чтобы все выглядели одинаково, — запрещают косметику, а телефоны часто сдают на хранение охране, классному руководителю или дежурным (как одежду в гардероб). Надо позвонить — пошел на пункт сдачи, попросил свой телефон, поговорил, сдал. Звонят тебе? — тебя вызовут на этот пункт.
Такие правила действуют во многих школах по всему миру — в Японии, США, России, Франции и т.д. Не везде это правило закреплено законом, чаще школа сама решает, как ей решать подобные проблемы.
Возможно, сегодня смартфон перестал быть ярким дифференцирующим фактором — теперь он есть не у единиц, а почти у каждого в классе, — и запрет решили снять.
Вообще, я считаю, что пусть лучше разрешают все. В условиях, когда есть форма, нет мобильников и косметики — как, например, в советских школах, — выделяться начинают те, у кого успеваемость лучше и те, кто очки носит. А я против того, чтоб обижали ботаников :)
Да, именно вариант «split brain» — от примерно сотни машин с одинаковой конфигурацией отвалились 8. Проблему обнаружили, когда начал кидать ошибки сторонний сервис, куда и основная часть, и отщепенцы одновременно писали противоречивые метрики. Все дело продлилось минут 40.
Но если честно, кто его знает, как там у Амазона сетка организована. Может, тоже иерархия свитчей какая-то, невидимая с точки зрения виртуалок.
Было явно понятно, что какой-то из ряда вон выходящий случай, и мы так и не смогли решить, как данные объединить. Решили просто похерить все, что те 8 серверов насоздавали.
Я еще думаю, что раз все эти ребята — и Google, и Facebook, и Bashoo, и другие вендоры — так упирают на этот случай, значит, действительно актуальная для них проблема. Вопрос в том, актуальна ли она для «простых смертных». Мы тогда забивали, но было неприятно потом баланс сводить и рефандить недовольных клиентов.
Но вот совет «используй CDN для jQuery» на практике не особенно полезный. Steve Souders — гуру фронтенд-производительности, автор книг High Performance Web Sites и Even Faster Web Sites, руководитель групп разработки Y!Slow и PageSpeed в Yahoo и Google соответственно — проводил исследования данных HTTPArchive как раз на эту тему.
И оказалось, что хотя в целом jQuery из Google CDN загружеют 18% из топ 300 тысяч сайтов интернета, — что, в общем-то, очень даже круто — когда дело доходит до конкретной версии, то наблюдается одромный разброс значений и по сравнению с 2011 годом фрагментация только растет:
Table 1. Top Versions of jQuery from GHL Mar 1 2013
jQuery version percentage of sites
1.4.2 (http) 1.7%
1.7.2 (http) 1.6%
1.7.1 (http) 1.6%
1.3.2 (http) 1.2%
1.7.2 (https) 1.1%
1.8.3 (http) 1.0%
1.7.1 (https) 0.8%
1.8.2 (http) 0.7%
1.6.1 (http) 0.6%
Так что вероятность того, что именно ваша версия jQuery уже есть в кеше браузера, ничтожно мала. Гораздо более выгодно собирать ваш JS, ваши стили и картинки и отдавать их от какого-то CDN. Тогда если пользователь ходит на ваш сайт часто, вы получите горадо больший прирост по скорости. А если редко, то что с Google CDN, что без него, ему придется загружать ваш сайт целиком с нуля (тут особую роль играют оистрически малые размеры кеша браузеров). Услуги CDN сегодня очень дешевы и легко подключаются.
Ребята уже упоминали про связь между датацентрами. Но у меня подобная ситуация возникала в AWS внутри одной availabilty zone. Конечно, никто не знает, какая именно там топология сети, но факт есть факт.
Разделение сети — крайне редкое явление в наше время. Гилберт и Личн прямо заявляют, что системы, работающие в локальной сети, можно считать не подверженными разделению.
Как писали Стругацкие, «Вы мне это прекратите!».
«Крайне редкое» — понятие очень растяжимое. 61 раз за 700 дней — это по вашему «крайне редкое»? А ведь такую статистику по одному проекту собрали в Google. Имхо, если случай возникает чаще двух раз в неделю, то распределенная программная система должна проектироваться с учетом такого случая.
Если бы для каждого «факта» в вашей статье были какие-то свидетельства, его подтверждающие, то доверие вашей статье было бы куда больше. А так — вброс вбросом.
Я долго «не верил» в CAP-теорему, считая ее модным приемом технического маркетинга. А потом почитал доказательство и ряд других работ, которые пытались его опровергнуть или подвергнуть сомнению, а также работ, которые, наоборот, подтверждали правильность доказательства. Я склонен доверять научному методу познания окружающего мира, даже если из-за этого мне приходится перестать верить в некоторые чудеса.
Сейчас в моде минимализм, поэтому часто гораздо проще уговорить человека взять маленькую библиотечку, даже если потом он накачает ворох других библиотек и модулей, чтобы решать сопутствующие задачи, чем убедить его в том, что будет лучше взять готовый комбайн.
В мире Руби это случается сплошь и рядом: люди думают «я сделаю проект гораздо проще, если возьму вместо Рельс Синатру», а потом их gemfile начинает расти, и расти, и расти, — пока суммарно приложение не сравняется по объему зависимостей с аналогичным на Ruby on Rails.
В мире Питона та же история: люди часто скачут между Django и Flask (или аналогами). Так же модно взяться за Node или Go, а потом наплодить микросервисов, каждый из которых концептуально прост, а вот все вместе — каша.
Бывают, конечно, и удачные примеры минимализма в мире разработки, но не так часто, как это может показаться.
С таким отношением в нашей профессии нельзя. Если заглянуть под капот таких продуктов как Apache Hadoop, Hibernate, исходники Java, V8, .NET, ядра Linux или Windows, то там все также печально (в разной степени печальности).
Что поделать? Жизнь — тлен.
Нужно учиться пользоваться абстракциями там, где это возможно, и одновременно с этим не бояться нырять с головой в проблему, если абстракция для вашего случая оказалась решетом.
Rails хорош, если с одной стороны, вам недостаточно возможностей CMS, но с другой — у вас нет задачи заниматься real-time вебом и нет заоблачных требований по производительности. Если вы делаете HTTP API или традиционный сайт с элементами интерактива, то Рельсам в этой нише равных нет. Во-первых, сам фреймворк из коробки кучу всего умеет. А во-вторых, для него есть огромное множество библиотек для расширения базового функционала. Часто проекты достигают стадии «готово на 80%» уже в первые дни только за счет того, что инжинеры быстро находят и подключают готовые библиотеки и.
И пусть оно внутри страшное. Оно работает и часто у него отлично спроектированный публичный API, и значит, каким бы плохим не был код самого фреймворка или плагинов, это никак не портит вашего кода. А ваш код — это как раз то, что волнует вас больше всего.
А есть ли смысл сюда писать примеры? Пост популярный, наверняка после 300-400 комментариев попадет на страницы Гугла и Яндекса. А значит, большинство кандидатов на запрос в поисковике будут сюда попадать, вопросы и ответы читать. Соответственно, вопросы перестанут быть актуальными.
В мире Java лет 10 назад было модно спрашивать, чем ArrayList отличается от LinkedList или чем абстрактный класс отличается от интерфейса. Ценность[1] ответа на оба вопроса была минимальной уже тогда, а сегодня тем более.
С этими вопросами на JavaScript-интервью произойдет то же самое. Вопрос про new Date() вообще ничего не показывает. Гораздо интереснее спросить про время высокого разрешения, потому что если человек знает про window.performance.now(), то может и про другие аспекты Performance API ему что-то известно.
[1] Для меня цель интервью — понять, насколько эффективным будет тот или иной инженер в работе, насколько успешно он будет решать задачи и насколько медленно при этом будет расти технический долг на проекте. Как оказалось, корреляция между тем, отвечает ли человек на такие вопросы, и его эффективностью практически не прослеживается.
Если Хабр останется совсем без политики, то, думаю, на него HTTPS повесить можно будет без ущерба для ресурса в целом.
— У, у вас фреймворк не модный используется, на этом не хочу писать!
— Эээ, мне эта задача неинтересна.
— Ну, требования странные какие-то, мне не хочется в них разбираться.
И так далее. Я считаю, что работа должна быть интересной, но даже на самой лучшей работе порой приходится заниматься какими-то нудными и не самыми приятными задачами.
Ребенка надо учить хорошему слову «Надо». Но и совсем загонять не стоит. В конце концов, работу тоже можно поменять, если она совсем не нравится. Проголосовал за второй вариант.
Конечно, антипаттерн. Мы столько копий наломали с руководством, чтобы от него избавиться!
Там вообще много таких скользких мест было, которые зародились на раннем этапе, когда введение одного такого антипаттерна позволяло платить зарплату еще одному члену команды. Потом, когда сервис стал крупнее, все это было уже не нужно, но уговорить людей получать на, скажем, сто тысяч долларов в месяц бывает тяжело.
Сейчас, насколько знаю — меня в той команде уже нет — остался только один косяк: на сайте указан номер службы техподдержки, работающей 24/7, но за номером робот, который регистрирует звонок. Поддержка потом переходит в режим общения по email и звонит клиенту только если он грозит чарджбеком.
Мы ведь тоже так делали 2 года: пупблика на сайте была непродвинутая и ошибки в почте были часто. Причем мы сразу просили данные карты, и потом снимали с людей денег. И получалось: есть аккаунт, с которого идут деньги, но которому не удается отправить подтверждение. Часто люди платили месяцами и пользовались. Но иногда человек получал очередной платеж, видел его в банке, но не узнавал и заказывал chargeback.
Одно время это был основной источник чарджбеков, и мы пробовали разные варианты. Нужно было и денег не потерять, и на счетчик в платежной системе не вставать. Вариант «следить за тем, что пользователь имеет неподтвержденный мейл и отменять ему подписку» сильно бил по карману. Вариант «вводить почту дважды» снижал конверсию, но в результате по деньгам мы теряли меньше.
Потом через два года попробовали другой вариант: проверять популярные почтовые домены и сравнивать юзернейм в адресе почты и в нашей системе и подсказывать, если есть подозрения. Оказался лучшим со всех сторон.
Из то же оперы следующие сценариями, которые долгое время считались единственно правильными и возможными:
1. Иметь длинную форму регистрации.
2. Требовать вбить пароль при регистрации 2 раза.
3. Иметь длинную форму регистрации и сбрасывать поля ввода пароля и подтверждения, если валидация других полей не прошла.
4. Требовать вбить 2 раза адрес электронной почты.
5. Не давать пользоваться сервисом, пока в письме на ссылку не нажмешь.
И т.д, Сегодня большинство пунктов — дикость. Желательно иметь вообще 2 поля при регистрации и логине — почта и пароль. Плюс социальные кнопки по желанию.
Ubuntu — релиз каждые полгода, есть LTS-версии
Chrome — релиз каждые 6 недель, есть несколько каналов обновления
Firefox — релиз каждые 6 недель, есть LTS-версии и несколько каналов обновления
Haskell Platform — релиз каждый год, опциональные релизы в течение года
Ember.JS — релиз каждые 6 недель, несколько каналов обновления
Есть планы по переходу на такой режим стандарта ECMAScript: релиз каждый год, WHAT WG тоже перешло на регулярный перевыпуск стандарта HTML5 (но там как таковых версий нет). В Node.js разработчики говорили о планах перейти на регулярные релизы после выпуска 1.0. В Django официально такой политики регулярных релизов нет, но по факту разработчики следуют четкому расписанию.
В общем, примеров масса и со временем их становится больше.
Еще одно время — где-то в 2005-2008 годах были популярны разъезжающиеся баннеры. Случайно проведешь по нему, а он растягивается почти на всю видимую часть страницы. Часто при этом включалась бешеная анимация и звук. Тоже воспаленная мысль маркетологов двигалась в направлении «пользователь навел мышь на баннер, значит ему интересно наше предложение — нужно его убедить, пока внимание не переключилось на что-то другое». То, что баннер часто лепили между, скажем, навигацией по сайту и статьей, никого не волновало.
Еще какое-то время были популярны рекламные псевдо-ссылки. По всему тексту слова и фразу подчеркивались, но вместо перехода на другую страницу этого или другого сайта при наведении показывался баннер. Помню, одно время эти псевдо-ссылки так раздражали всех, что поднялась шумиха насчет их запрета или регулирования. Одна такая служба, помню, первой добровольно решила, что будет выделять свои рекламные ссылки двумя подчеркиваниями, а не одним, чтоб пользователей не путать. Но все равно они раздражали жутко. Попропадали они после того, как Google стал страницы с такой рекламой в выдаче понижать.
Ну и AirPush на мобильниках — тоже пример того, как рекламу не надо делать.
— шмотки: у Ленки кожаные штаны крутые, все девочки завидуют, все мальчики «фантазируют». Могут и порезать штаны, и самой Лене может достаться. Или наоборот — Лена станет крутой и популярной, и доставаться будет тем, кто к Лене в свиту не попал.
— косметика: новая Машина помада может послужить отличным инструментом для макияжа в стиле «Джокер», правда?
— мобильники
Поэтому в школах часто вводят форму — чтобы все выглядели одинаково, — запрещают косметику, а телефоны часто сдают на хранение охране, классному руководителю или дежурным (как одежду в гардероб). Надо позвонить — пошел на пункт сдачи, попросил свой телефон, поговорил, сдал. Звонят тебе? — тебя вызовут на этот пункт.
Такие правила действуют во многих школах по всему миру — в Японии, США, России, Франции и т.д. Не везде это правило закреплено законом, чаще школа сама решает, как ей решать подобные проблемы.
Возможно, сегодня смартфон перестал быть ярким дифференцирующим фактором — теперь он есть не у единиц, а почти у каждого в классе, — и запрет решили снять.
Вообще, я считаю, что пусть лучше разрешают все. В условиях, когда есть форма, нет мобильников и косметики — как, например, в советских школах, — выделяться начинают те, у кого успеваемость лучше и те, кто очки носит. А я против того, чтоб обижали ботаников :)
Но если честно, кто его знает, как там у Амазона сетка организована. Может, тоже иерархия свитчей какая-то, невидимая с точки зрения виртуалок.
Было явно понятно, что какой-то из ряда вон выходящий случай, и мы так и не смогли решить, как данные объединить. Решили просто похерить все, что те 8 серверов насоздавали.
Я еще думаю, что раз все эти ребята — и Google, и Facebook, и Bashoo, и другие вендоры — так упирают на этот случай, значит, действительно актуальная для них проблема. Вопрос в том, актуальна ли она для «простых смертных». Мы тогда забивали, но было неприятно потом баланс сводить и рефандить недовольных клиентов.
— index.html — с моего сервера
— styles.css, vendor.js, app.js — с CDN
можно было бы jquery из vendor.js вытянуть и с CDN гугла грузить, но зачем лишний запрос делать?
И оказалось, что хотя в целом jQuery из Google CDN загружеют 18% из топ 300 тысяч сайтов интернета, — что, в общем-то, очень даже круто — когда дело доходит до конкретной версии, то наблюдается одромный разброс значений и по сравнению с 2011 годом фрагментация только растет:
Так что вероятность того, что именно ваша версия jQuery уже есть в кеше браузера, ничтожно мала. Гораздо более выгодно собирать ваш JS, ваши стили и картинки и отдавать их от какого-то CDN. Тогда если пользователь ходит на ваш сайт часто, вы получите горадо больший прирост по скорости. А если редко, то что с Google CDN, что без него, ему придется загружать ваш сайт целиком с нуля (тут особую роль играют оистрически малые размеры кеша браузеров). Услуги CDN сегодня очень дешевы и легко подключаются.
Как писали Стругацкие, «Вы мне это прекратите!».
«Крайне редкое» — понятие очень растяжимое. 61 раз за 700 дней — это по вашему «крайне редкое»? А ведь такую статистику по одному проекту собрали в Google. Имхо, если случай возникает чаще двух раз в неделю, то распределенная программная система должна проектироваться с учетом такого случая.
Вот тут выжимка из целой коллекции исследований на тему: An informal survey of real-world communications failures
Если бы для каждого «факта» в вашей статье были какие-то свидетельства, его подтверждающие, то доверие вашей статье было бы куда больше. А так — вброс вбросом.
Я долго «не верил» в CAP-теорему, считая ее модным приемом технического маркетинга. А потом почитал доказательство и ряд других работ, которые пытались его опровергнуть или подвергнуть сомнению, а также работ, которые, наоборот, подтверждали правильность доказательства. Я склонен доверять научному методу познания окружающего мира, даже если из-за этого мне приходится перестать верить в некоторые чудеса.
В мире Руби это случается сплошь и рядом: люди думают «я сделаю проект гораздо проще, если возьму вместо Рельс Синатру», а потом их gemfile начинает расти, и расти, и расти, — пока суммарно приложение не сравняется по объему зависимостей с аналогичным на Ruby on Rails.
В мире Питона та же история: люди часто скачут между Django и Flask (или аналогами). Так же модно взяться за Node или Go, а потом наплодить микросервисов, каждый из которых концептуально прост, а вот все вместе — каша.
Бывают, конечно, и удачные примеры минимализма в мире разработки, но не так часто, как это может показаться.
Что поделать? Жизнь — тлен.
Нужно учиться пользоваться абстракциями там, где это возможно, и одновременно с этим не бояться нырять с головой в проблему, если абстракция для вашего случая оказалась решетом.
Rails хорош, если с одной стороны, вам недостаточно возможностей CMS, но с другой — у вас нет задачи заниматься real-time вебом и нет заоблачных требований по производительности. Если вы делаете HTTP API или традиционный сайт с элементами интерактива, то Рельсам в этой нише равных нет. Во-первых, сам фреймворк из коробки кучу всего умеет. А во-вторых, для него есть огромное множество библиотек для расширения базового функционала. Часто проекты достигают стадии «готово на 80%» уже в первые дни только за счет того, что инжинеры быстро находят и подключают готовые библиотеки и.
И пусть оно внутри страшное. Оно работает и часто у него отлично спроектированный публичный API, и значит, каким бы плохим не был код самого фреймворка или плагинов, это никак не портит вашего кода. А ваш код — это как раз то, что волнует вас больше всего.
В мире Java лет 10 назад было модно спрашивать, чем
ArrayListотличается отLinkedListили чем абстрактный класс отличается от интерфейса. Ценность[1] ответа на оба вопроса была минимальной уже тогда, а сегодня тем более.С этими вопросами на JavaScript-интервью произойдет то же самое. Вопрос про
new Date()вообще ничего не показывает. Гораздо интереснее спросить про время высокого разрешения, потому что если человек знает проwindow.performance.now(), то может и про другие аспекты Performance API ему что-то известно.[1] Для меня цель интервью — понять, насколько эффективным будет тот или иной инженер в работе, насколько успешно он будет решать задачи и насколько медленно при этом будет расти технический долг на проекте. Как оказалось, корреляция между тем, отвечает ли человек на такие вопросы, и его эффективностью практически не прослеживается.