Здравствуйте, уважаемые подписчики и гости канала!
Если вкратце, то всё тривиально: количество кода и простота доки для получения первых результатов - вот что отличает jQuery от всяких React-ов и от Angular 2+.
Стоит заметить, что я знаю про umd и прочие прелести, всё это более-менее приближает к быстро-использованию технологий, да и браузеры за 10 лет шагнули сильно вперед и кросс-браузерность уже не такая проблема, как была раньше. Но все же, это не совсем то, как именно реально используется react, vue и angular. Так же надо webpack, хотя нет, сейчас вроде уже rollup. Это тоже не добавляет удобства для простых проектов. Мне понятно зачем это всё и я не против новых технологий и статья не про то, что jQuery супер крут и его хватает для всего.зображение с сайта jquery.com
Кстати, важно! Обязательно ознакомьтесь с youmightnotneedjquery.com чтобы больше узнать в каких случаях вам не нужна эта библиотека.
Так вот, суть-то даже не в самом jQuery, а в том, что не все работают над проектами уровня Фейсбука или Гугла, а значит внедрение полноценного современного фронтенда в ряде случаев будет избыточным по времени, стоимости программирования, тестирования и стоимости поддержки.
Грубо говоря, если у вас просто форма входа, где надо сделать пару ajax запросов и по условию показать или скрыть пару полей, то задумайтесь, хотите ли вы вообще запариться со сборкой фронтенда сейчас? А это же сейчас целый ритуал, начинающийся с package.json. Или может лучше поделать другую реальную работу, а на форме логина на первое время быстро на jQuery (или Vanila JS 😎) в 50 строк кода это решить задачу.
Просто сравните сколько кода надо на все это. Как говорится "базара нет", если деньги не ваши, а инвесторские, хотя лично я не приветствую пустое прожигание денег. Как-то всегда как к своим относился и до сих пор так же отношусь. И все же, зачем их трать на что-то что можно сделать отдельно, быстро и без время для проекта? Может быть пример с формой входа не самый лучший, но суть ясна, думаю — реально ли нужно брать ту или иную сложную любу или для проекта сейчас лучше будет, чтобы он заработал в таком виде и с такими технологиями, чтобы смог начать нормально обслуживать клиентов? Не стоит идти на сделку с совестью и писать заведомо ужасный код, но у вас в голове должен быть выбор, взвешенные "за" и "против". Вам и команде на месте и решать, конечно - не мне же ваш проект поддерживать и в дедлайны успевать)
Собственно, то же самое с любыми другими фреймворками на других языках. Например, скорее всего для начала можно просто на питоне накидать хоть какое-то json api. А потом, когда вам стало неудобно, ресурсозатратно или вы хотите больше контроля над типами вы переходите на gRPC. Смекаете? 😊 Это всё не касается, наверное, очень серьезных банковских разработок, я скорее про более динамичные случаи, хотя против банков ничего и имею и не имел никогда - там все круто, я уверен.
Часто бывает так, что люди стремятся постоянно выбирать подходы больших именитых компаний типа Google. Моё мнение — не стоит программировать всегда только так, будто вы в Гугле работаете. Там и денег больше и программистов, налаженные процессы, учёт ошибок, стоимости разработки и т.д. Вот, например, я уверен, что Bazel от Google - отличный инструмент для сборки. Знаю, что многие компании выбрали его для себя. И вместе с тем, внедряя его, например, для java, вы должны понимать для чего именно вы это делаете - у вас должны быть веские аргументы, потому, что вся команда должна научиться с ним работать, знать нюансы. И это при этом Maven и Gradle же никто не отменял, это тоже надо знать. Т.е. если вы захотите просто попробовать новую технологию или плагинчик, то должны четко отдавать себе отчет, что потратите не только свое время, но и время других.
Противоположностью это подходу является подход некоторых команд, которые пишут максимально сложный и «прогрессивный» код на scala и используют какую-нибудь модную nosql бд — нагрузки же будут ой-ой-ой. И при этом ноль клиентов и нагрузок тоже что-то нет... И вот, деньги у стартапа заканчиваются и вы ищите другую работу. Опыт появился, несомненно, но тот ли? Тут, конечно, каждый сам для себя решает, а я думаю, что для почти любого обычного проекта нужны такие технологии:
1. Обязательные: postgresql/mysql + python/php/nodejs/java + что-нить на фронтенд в зависимости от сложности например jquery/nextjs
2. Далее скорее всего скоро нужен будет redis/memcache для кеширования
3. Потом для упрощения роста: контейнеризация хоть в каком-нибудь виде (docker-compose, kubernates) и желательно сразу в мульти-инстансе + рекомендую рассмотреть s3-совместимое хранилище.
При этом два последних пункта не обязательны, но это моё ИМХО по желательности, так как код сразу станет гораздо более расширяемым и не надо будет тратить дни на переписывание под контейнеры и мульти-инстансы — это не всегда просто. При этом, если вы знаете эти технологии или можете подготовить их для команды — это лучше сразу сделать, так как займет 1-2 дня в начале проекта. Когда вы работаете в мульти-инстансной среде (приложение запущено одновременно в нескольких копиях и обрабатывает одних и тех же клиентов) вы не можете писать некоторые хаки и это хорошо. 😊 А если вы еще не работали так — попробуйте дома на pet-проекте - уберите сессии юзеров в redis, запустите http сервер в minikube c микро-балансировщиком на nginx и представьте или сделайте как-то, что ваши pod-ы на разных машинах работают и сразу поймете, что локальный кеш не всегда крут, что «под себя» файлы писать не получается ну и так далее.
Ну вот и все, как говорила моя учительница по истории - "начали с булочек, а закончили мировым положением". Суть про jQuery вы уловили, надеюсь, так же как и то, что статья не только про jQuery. 😂 Вы же не арендуете фуру, чтобы шкаф перевезти, так же и к технологиям относиться надо. Всему свое место и время.
А на этом всё, спасибо за внимание!
Подписывайтесь на канал, ставьте лайки, оставляйте комментарии - это помогает продвижению в Дзене.
Кроме этого:
Подписывайтесь в Telegram: https://t.me/lets_goto_it
#jquery #react #angular #начинающий программист #уйти в программирование #с чего начать карьеру программиста