Нет)
Хорошая тема, но по факту нам никто ничего не должен.
Я сам заикаюсь, потому расскажу одну историю.
Лет 5 назад, очень горел идеей свичнуться из фронтенда на бекенд. Нашел интересную вакансию на node.js джуна. Успешно выполнил ТЗ, потом бодро пообщался с тех лидом, а вот на собеседовании с HR меня ожидало полное фиаско — был тест на английском, ну и я знал конечно что сказать, но не смог.
Дальше уже мало кого интересует, почему. Не можешь общаться — не подходишь. Было неприятно конечно, но по факту это рынок. Смысл брать кандидата у которого проблемы с устной речью, если можно взять другого без этих проблем.
Если бы таких как мы было прям реально много, тогда да — работодатели как-то включались бы в этот вопрос, наверное.
Люблю разные «челленджевые» задания. Чем больше у меня становилось опыта разработки, тем меньше таких заданий соответственно становилось.
Одно из таких — сделать свою песочницу для фронтенда. Как stackblitz или codesandbox. Причем воспринимал я такую таску, чуть ли не на уровне невозможного.
В конце концов взялся за реализацию, но решил делать не просто песочницу, так как не хотелось чтобы проект ушел в «стол», а интерактивные курсы по фронтенду.
Здесь можно посмотреть сам сайт — frontendly.dev
Здесь подписаться на мой твиттер и следить за обновлениями — twitter.com/tagtag193
В будущем планирую основательно наполнить сайт контентом и сделать подписку. Посмотрим что из этого выйдет.
П.С. Так же есть идея, правда пока в зачаточном виде — сделать интерфейс чтобы другие люди могли делать свои курсы у меня на сайте. Текст, код, валидация решения пользователя и все такое.
Есть два сайдпроекта
pagehealth.me — идея состоит в том, чтобы поставить веб-страницу на слежение и собирать метрики Google Page Speed Insights. На основе этого следить за перфомансом на длинном отрезке времени. Сейчас проектом не занимаюсь, но зарегаться и поставить до 3 (включительно) страничек на слежение, можно любому бесплатно.
frontendly.dev — платформа для обучения людей фронтенду решая задачи максимально приближенные к реальной разработке. Сейчас этим проектом горю и большую часть свободного времени отправляю туда.
Написал браузерный бандлер, так что скоро появятся уроки по Реакту и прочим либам/фреймворкам.
Ни первый, ни второй денег не приносят.
Я когда-то сделал вот такой сервис — pagehealth.me .
Вводишь интересующий тебя урл и каждый день (либо через вебхук) получаешь данные по Lighthouse Metrics и Chrome User Experience Reports.
Потом на графиках легче понять из-за чего именно те или иные метрики начали проседать или наоборот.
Я или невнимательно читал или вы не написали. Так какой у вас сейчас MRR ?
В целом, мне было интересно и полезно почитать. Спасибо за статью.
Можешь не париться. Для программирования что фронтенда, что бекенда математика нужна на уровне арифметики начальных классов. Бывают конечно случаи, что какие-то алгоритмы нужны ( редко ), но опять же — во всем можно разобраться, это не так сложно как кажется.
У меня вводные, похожие как у тебя и ничего вкатился и работаю.
Хотел стать специалистом в какой-то сфере и зарабатывать хорошие деньги, но совершенно не представлял чем хочу заниматься.
Пробовал разные варианты, но нигде особо не получалось.
Потом как-то узнал от знакомого друга, что тот вкатился как QA. На тот момент я IT вообще не рассматривал, так как был твердо убежден, что без сильного математического бекграунда там делать вообще нечего.
В общем начал пробовать, зашло. Где-то с нуля до первой работы, ушло 2 года примерно, с небольшими перерывами. Совмещал
Платные курсы никакие не посещал, так как банально не было на них денег. Тогда и на еду даже не всегда хватало :) .
Очень помогли бесплатные курсы от ребят из Kottans, за что им очень благодарен.
В сухом остатке в 26 где-то начал, в 28 вкатился.
П.С. Думаю отчасти решает круг общения, если бы знал о возможностях, то раньше бы и попал.
Книги линейки Head First, отличный старт для людей которые вкатываются в IT с полного нуля. Сам когда-то занимался по одной из таких.
Раньше он так не тормозил кстати. Вообще фиг с ней с долго загрузкой. Проект действительно хороший. Но хотелось бы конечно, чтобы сверху был какой-то прогресс бар с загрузкой, а то иногда непонятно происходит ли вообще что-то, когда на ссылку нажал или нет.
Вангую, что-то вроде Server Sent Events используется. Но может и другие варианты какие-то конечно.
ТС, красавчик.
Я года 1.5 стартанул с сайд проектами и пока даже и близко не достиг таких результатов.
Вот завтра собираюсь публиковать на Product Hunt один из своих проектов, посмотрим что получится.
Мне кажется, вы могли бы начать с чего-то по типу такого www.amazon.com/...mized-ebook/dp/B07PSJKHKJ . Мне нравится эта книга и она как раз на том языке который вы хорошо знаете.
Например тот же Django, больше даст понятие о том как здесь и сейчас решать полезные бизнес задачи, но вряд ли даст фундаментальное понимание.
Классная статья. Видно что автор серьезно подошел к вопросу оптимизации, да и написании статьи тоже.
Особенно порадовали разные юмористические вкрапления, чтобы веселее было читать это все.
І поки браузер зайнятий перетравленням вашого коду, користувач самотньо сидить у туалеті й намагається оживити пальцями мертвий екран!
Теперь по-поводу того что знаю я на счет оптимизаций. Оптимизировал я правда не Вордпресс, а SPA на ангуляре. Но в целом, фронтенд есть фронтенд.
Возможно что-то повторю за автором, статья длинная, так что простите если что.
1). Заменяем все наши jpeg, png на webp, есть еще модный молодежный avif , но я пока с ним не работал еще. Проверять поддерживает браузер webp или нет, можно через хедеры реквеста, который браузер шлет на сервер чтобы получить страничку. Хедер называется — accept . В нем собственно представлены все форматы данных которые браузер поддерживает.
2). Отложенная загрузка js кода. Ну тут два варианта, если это какая-нибудь капча, то просто когда она нам нужна, берем динамический импорт
и загружаем код необходимый для капчи. Либо же если виджет не попадает в вьюпорт с которого начинается загрузка страницы то в комбинации с Intersection Observer и импортом делаем то же самое.
3). Заменить сжатие ресурсов с gzip на brotli — выгода не сильно большая, но как говориться — курочка по зёрнышку клюёт.
4). Time to first byte — довольно значительно влияет на общую картину загрузки. Баллов на 20 точно. Если у вас скажем SPA + SSR где чтобы сформировать шаблон (перед отдачей браузеру) надо отправить несколько тяжелых http запросов, то закономерно что ttfb будет страдать. Потому в таких кейсах, лучше кешировать эти шаблоны. Как после сборки заранее, так и на лету запихивая их в какой-нибудь редис или вообще в память, если вы в один поток запускаете свой node.js сервер.
По-поводу веб воркеров, есть вот такая интересная, пока еще экспериментальная библиотека . Суть её в том чтобы значительно уменьшить влияние на метрики Web Vitals всяких скриптов по типу facebook pixel или google tag manager.
Я уже наблюдал такую картину, когда выстраданная потом и кровью страничка с двумя 100 на десктопе и мобайле обвешивается различными скриптами аналитики и сразу метрики проседают))
Ну и напоследок немного по рекламируюсь. В связи с тем, что я тоже длительное время занимался и занимаюсь оптимизациями, всегда было интересно как меняются метрики on the long run как говорится, потому собственно я и создал SaaS — pagehealth.me который трекает метрики производительности.
На данный момент трекается:
— Chrome User Experience Reports (CrUX)
— Lighthouse Metrics
— Code Coverage (сколько из загруженного js/css реально применяется, а сколько грузится в холостую)
Трекать можно как каждый день, так и по вебхуку. Ну и конечно добавлять комменты к вебхукам, чтобы хотя бы примерно понимать релиз какой фичи мог затронуть просадку или повышение метрик.
Я туда зашел, но мне непонятно зачем там писать что ты работаешь в Розетке, а в статусе на доу — что в Вебике. Можешь как-то это объяснить?
Так что это за Webika такая? Ссылку в студию.
directed by robert b weide ©
Контентного сайта, где вы не отказались от SPA-фреймворка, потому что это было бы ошибкой, а так же просто выбрали инструменты правильно.
Мы же вроде бы об этом говорили.
Ідея Svelte у маленькому бандлі, а не у якомусь більш зручному синтаксисі. Тому це саме та ситуація де вибирають інструмент під задачу.