Comments 117
Т.е. бэкенд ограничивается всего 4-мя динамическими языками. Мы точно в 2017?
Ну, видимо автор писал о том, в чём разбирается.
Значительно менее детально, чем Ruby, PHP и Python. Бэкграунд у автора видимо такой.
Точно, не увидел сразу. Но тоже очень странно: для java написали фреймворки (да и то, Grails и Play — не лучший выбор в 2017), для # и Go — нет. Как-то всё однобоко.
А что в Java мире предпочитают в 2017? Не использовать Java? :D Я думал, что Play в целом хорош.
Да есть всякие в шарпе NancyFx и прочая хипстерщина. Но зачем они нужны, если сейчас завезли ASP.NET Core, который покрывает все возможные нужды? Раньше ещё отдельно WebAPI был, но его в основной аспнет интегрировали.
Ну не обязательно описывать только фреймворки. Для других языков же описаны и пакетные менеджеры, и библиотеки для тестирования, и инструменты для разработки.
По картинке складывается ощущение, что php, python, js и ruby более популярны для бэка в 2017, чем java,# и Go, хотя это не так. Как минимум, потому что бэк очень многогранен. Для одних вещей лучше взять питон с джангой, для других — java со спрингом, для третьих — go и кучку мелких библиотек.
Ок, я не совсем точно выразился по поводу php, попытаюсь прояснить.
Во-первых, бОльшая часть пхп-сайтов — это какой-нибудь простенький форум/вики/порталы на различные тематики (кулинарные, развлекательные и т.д.), магазины всякой фигни. Это всё разворачивается на жумле/вордпрессе/битриксе и других CMS.
Не хочу никого обидеть, но это трудно назвать разработкой, хотя бы потому что там даже при желании банально некуда развиваться. Разработки как таковой почти нет, так как таким сайтам хватает возможностей этих CMS из коробки, и всё сводится к разворачиванию и настройке CMS, подключению темы и плагинов. Да, на такие вещи всегда много вакансий, но зачастую это всё либо одноразово (подключил, настроил — получил деньги), либо периодически (2-3 раза в месяц что-то подправил/обновил CMS/подключил плагин).
Во-вторых, даже если сайт на php — это мало что говорит о реальных технологиях, которые используются. Мой знакомый работает в компании, наружу у них выставлен магазин, написанный на php. Он интегрируется с 1С и с API. API написан на java, и имеет сложную бизнес-логику (часть API не используется магазином, но необходимо для иных аспектов работы компании). В штате один php-разработчик, один 1С-разработчик и 5 java-разрабов. Но в статистике использования языков учтётся только php, хотя по вакансиям ситуация будет совершенно иной.
- Когда человек хочет пройти по этому пути, ему не нужны ветки. Ему нужен workflow без ветвлений
- DevOps — не профессия и в делает из этой схемы яблоки/апельсины. DevOps полезен каждому разработчику, будь он какой-угодно-end
- Linux нужно ставить во главу угла, так как это очень важная матчасть. Даже если человек работает под Windows, знания Linux ему помогают, так как раскладывают все по полочкам
- Обидно, что под PHP дебаггеры существуют, а PDB еще не изобрели
- Ничего по IPC — как без этого?
- Проигнорированы MQ
- Не написано, что человек должен уметь логировать и читать конфиги из приложения
- Apache можно отнести в мир PHP. Сегодня он нужен только там, где используют .htaccess
Вывод: это какой-то график toolset, а не то, что написано в заголовке статьи. Причем toolset очень неполный, непоследовательный и непрозрачный. Даже разница между «Возможно» и «На выбор» меня заставила задуматься.
То есть нельзя на вопрос «как стать» в качестве ответа предосатвить toolset.
Когда человек хочет пройти по этому пути, ему не нужны ветки. Ему нужен workflow без ветвлений
Не всегда. Тут в самом начале выбор из трех пунктов)
DevOps — не профессия и в делает из этой схемы яблоки/апельсины. DevOps полезен каждому разработчику, будь он какой-угодно-end
Окей, назовем это SRE или DevOps Engeener. То, что профессию называет неправильно, не делает ее несуществующей. Разработчику знания о том, как работает jenkins и как его настраивать, например, не очень то и полезны.
Аналогично менеджемент кластеров, веб серверов и прочего — зачем оно ему? Мониторинг и прочее отправим туда же.
Linux нужно ставить во главу угла, так как это очень важная матчасть. Даже если человек работает под Windows, знания Linux ему помогают, так как раскладывают все по полочкам
А потом оказывается, что они пишут на ASP.Net под ISS. Как бы я не любил linux, но он не must-have.
Проигнорированы MQ
А еще timeseries database. Как часто вам приходится работать напрямую с MQ?
Не написано, что человек должен уметь логировать и читать конфиги из приложения
А еще не написано, что он должен уметь в паттерны, оценивать задачи, уметь в скрам и прочее. Как быть?
Аналогично менеджемент кластеров, веб серверов и прочего — зачем оно ему? Мониторинг и прочее отправим туда же.
DevOps уже на столько стало buzz-word, что все, что не разработчик, стало девопсом. То, что вы описали, не входит в рамки понимания DevOps. Это старое доброе системное администрирование.
DevOps занимается совершенно другими делами, связанными с выравниванием работы людей в команде по направлению Dev--> Ops и в обратную сторону. Это имплементация сервисов самообслуживания для разработчиков (автоматическая доставка логов из Ops в Dev, например), это разбиение сервисов на атомарные микросервисы для достижения предсказуемости времени ремонта (требование VisibleOps), это подбор и адаптация грамотной методологии, когда ситуация требует, например FDD, а команда работает в waterfall'е, это управление SQL-ченджсетами в рамках green/blue-deployment, когда надо заставить разработчиков рассчитывать, как раскидать их по спринтам, чтобы не столкнулись новая версия приложения со старой схемой БД… и еще много других вещей, которые точно не умещаются в распространенное понимание «гендиректор дженкинса» :-)
А еще timeseries database. Как часто вам приходится работать напрямую с MQ?
Это не вопрос частоты. Это вопрос того, сможет ли человек обратить внимание в эту сторону, когда задача будет требовать того или пойдет только доступными ему инструментами пользоваться, изобретая велосипед.
Но вообще да, это очень популярное решение.
А еще не написано, что он должен уметь в паттерны, оценивать задачи, уметь в скрам и прочее. Как быть?
Как вы можете такое сравнивать? Я прихожу в команду и вижу, что разработчики тратят примерно 70-80% времени на поиски багов только потому, что они попросту не умеют логировать. Вы понимаете, на сколько простое неумение простой вещи приносит ущерб? Как отсутствие скрама или правильного паттерна сможет достигнуть такой немыслимой цифры?
DevOps уже на столько стало buzz-word, что все, что не разработчик, стало девопсом. То, что вы описали, не входит в рамки понимания DevOps. Это старое доброе системное администрирование.
DevOps занимается совершенно другими делами, связанными с выравниванием работы людей в команде по направлению Dev--> Ops и в обратную сторону. Это имплементация сервисов самообслуживания для разработчиков (автоматическая доставка логов из Ops в Dev, например), это разбиение сервисов на атомарные микросервисы для достижения предсказуемости времени ремонта (требование VisibleOps), это подбор и адаптация грамотной методологии, когда ситуация требует, например FDD, а команда работает в waterfall'е, это управление SQL-ченджсетами в рамках green/blue-deployment, когда надо заставить разработчиков рассчитывать, как раскидать их по спринтам, чтобы не столкнулись новая версия приложения со старой схемой БД… и еще много других вещей, которые точно не умещаются в распространенное понимание «гендиректор дженкинса» :-)
Потому что так получилось, что админ, который сидит вместе с девами начинает заниматся этим магическим "DevOps". В моем представлении, это сильно отличается от той идеи, когда админы были отдельно, а девы отдельно. И именно вот тут админы превращаются в нечто под названием "DevOps", так как понимание предложение дает им возможность настроить любую часть того, что раньше было простым системным администрированием лучше.
Ну и не знаю, как у вас, в моем понимании как раз "гендиректор дженкинса" будет за все это отвечать, кто же еще? Он же деплоит.
Это не вопрос частоты. Это вопрос того, сможет ли человек обратить внимание в эту сторону, когда задача будет требовать того или пойдет только доступными ему инструментами пользоваться, изобретая велосипед.
Это очень популярное решение в довольно узком кругу задач. Не спорю, что есть множество вещей, которые так или иначе используют MQ, но работать напрямую с MQ приходится довольно не часто. Учитывая, что некоторые задачи, например, web push и прочее, можно вполне успешно делегировать на внешние сервисы.
Как вы можете такое сравнивать? Я прихожу в команду и вижу, что разработчики тратят примерно 70-80% времени на поиски багов только потому, что они попросту не умеют логировать. Вы понимаете, на сколько простое неумение простой вещи приносит ущерб? Как отсутствие скрама или правильного паттерна сможет достигнуть такой немыслимой цифры?
Все зависит от задачи и проекта. Отсутствие скрама, а значит и всякий дейли стендапов, например, приведет к тому, что разработчики вполне будут переделывать логику друг друга, что выльется даже не в 70-80% времени багфикса, а как бы не в 200-300% сверху.
Неправильное проектирование приведет к тому, что в тех местах, где дело решается простым паттерном, вырастут кручи и костыли, которые вы потом будете фиксить в 10-20 раз дольше, чем пилилась изначальная задача.
К тому же, говорить что правильное логгирование — простая задача, это очень сильно сгущать краски. Правильное логгирование должно включать в себя еще такую вещь как понимание того, что можно не логгировать, а это далеко не так просто, особенно, если разработчик не может себе целиком описать логику, над которой работает. А без этой сложной части, логи превратятся в кашу, где люди те же 70-80% времени будут искать нужную инфу.
Разумеется, можно свалить проблему парсинга и разбора логов на парня с лейбой DevOps, но он не всегда есть, и не всегда это удачная идея.
Ну и не знаю, как у вас, в моем понимании как раз «гендиректор дженкинса» будет за все это отвечать, кто же еще? Он же деплоит.
Вот мы и нашли основу вашего непонимания слова DevOps. В DevOps основа основ — полное покрытие всей дистанции ответственностью каждого участника.
И да, деплой Jenkins'ом — это какая-то жесть. Это какой-то очень примитивный продакшен, где и 100 серверов не наберется и все они одинаковые.
Все зависит от задачи и проекта. Отсутствие скрама, а значит и всякий дейли стендапов, например, приведет к тому, что разработчики вполне будут переделывать логику друг друга, что выльется даже не в 70-80% времени багфикса, а как бы не в 200-300% сверху.
Я не согласен, но если бы это было так, что скрам обязательно добавить в таблицу надо.
говорить что правильное логгирование — простая задача, это очень сильно сгущать краски.
Я не говорю про грамотное логирование. Новичку неоткуда ему научиться. Потом наберется в команде. Но я говорю про хотя бы малую долю — адекватное логирование. Они же все «логируют» принтами в STDOUT в своих демонах)))) А потом сидят и репу чешут, что там у них сломалось. В комбинации с неумением пользоваться дебаггером (а его и не существует под другие языки, кроме как PHP, согласно этой картинке) это дает прелестную картину :-D
Вот мы и нашли основу вашего непонимания слова DevOps. В DevOps основа основ — полное покрытие всей дистанции ответственностью каждого участника.
Это просто основа основ для грамотной работы большой компании, разве нет? Причем тут DevOps?
В средних и маленьких компаниях такое довольно часто не могут себе позволить, хотя бы потому, что часто люди совмещают несколько функций.
И да, деплой Jenkins'ом — это какая-то жесть. Это какой-то очень примитивный продакшен, где и 100 серверов не наберется и все они одинаковые.
Привет от людей, с одним или двумя серверов в проде :) А для больших серверов кто-то мешает использовать, например, kubernetes через jenkins? Я, конечно, не то что бы опытный, но каких-то потенциальный проблем, кроме того, что это таки будет автоматический деплой, не вижу. Если не сложно, подскажите, в чем еще может быть проблема?
Я не согласен, но если бы это было так, что скрам обязательно добавить в таблицу надо.
Как вы понимаете, это очень сильно зависит от проекта. Проекты разные, люди разные и у всего этого разные проблемы. Если бы кто-то написал бы workflow как действовать во всех случаях, ему бы тут же выдали бы нобелевку и прочее, но к сожалению, такого человека пока нет :)
Я не говорю про грамотное логирование. Новичку неоткуда ему научиться. Потом наберется в команде. Но я говорю про хотя бы малую долю — адекватное логирование. Они же все «логируют» принтами в STDOUT в своих демонах)))) А потом сидят и репу чешут, что там у них сломалось. В комбинации с неумением пользоваться дебаггером (а его и не существует под другие языки, кроме как PHP, согласно этой картинке) это дает прелестную картину :-D
Если они делают такую фигню, их нужно бить по рукам. А потом по рукам тех, кто пропустил такое после code review. Мне кажется, что если человеку один раз сказать, что нужно вместо print(text) использовать log.info/warning(text), то он так и будет делать. Или я слишком оптимистичен?
Привет от людей, с одним или двумя серверов в проде
DevOps начинается там, где возникает нужна регулировать отношения между Dev и Ops. То есть не там, где команда состоит из фуллстэк-разработчика и бухгалтера. Если в проде есть два сервера, то DevOps там нет по определнию самого термина.
Если они делают такую фигню, их нужно бить по рукам
Мы кажется как раз и говорим о том, что нужно пройти и изучить новичку. Не надо никого бить, это надо выучить.
__
По остальным вашим пунктам: мне кажется, вы потеряли, что доказываете.
DevOps начинается там, где возникает нужна регулировать отношения между Dev и Ops. То есть не там, где команда состоит из фуллстэк-разработчика и бухгалтера. Если в проде есть два сервера, то DevOps там нет по определнию самого термина.
Не уверен, что вам понимаю. Если у нас в команде 4 разработчика и один админ на 10%, который на 90% кодер на другом проекте, то DevOps там не нужен? А сервера у вас будет один или два.
Или же, если вы кодите прототип, у вас 5 кодеров и один полноценный админ, на котором висит все от окружения и ci, до аггрегации логов и анализа работы приложения. Тут тоже не будет DevOps?
Так же добавлю, что еще у вас может быть тесная интеграция с aws и в самом деле 1-2 сервера, а все остальное будет проходить через aws (базы данных и прочая фигня).
Мы кажется как раз и говорим о том, что нужно пройти и изучить новичку. Не надо никого бить, это надо выучить.
Это так просто не работает. У каждого фреймворка, проекта и компании обычно свой подход и свои методы. Например, куча проектов на python использует свои навороты над стандартным логгированием.
DevOps включает в себя автоматизацию, но DevOps != автоматизация.
я говорю про хотя бы малую долю — адекватное логирование.
Можно попросить расказать поподробнее как должно выглядеть адекватное логгирование?
Вот мы и нашли основу вашего непонимания слова DevOps. В DevOps основа основ — полное покрытие всей дистанции ответственностью каждого участника.
И да, деплой Jenkins'ом — это какая-то жесть. Это какой-то очень примитивный продакшен, где и 100 серверов не наберется и все они одинаковые.
jenkins разучился взаимодействовать с ansible/puppet, с k8s/nomad и подобными развлекухами? Где здесь узкое место по масштабированию процессов в гетерогенной среде?
Я уверен, что сможете. Но за год и при помощи 10 килострок кода в pipline. Только причем тут уже Jenkins, если это будут сложнейшие самописные скрипты в рамках Jenkins?
Jenkins сделан для CI, но для CD он вообще никак не подходит. И вещи, которые делаются в RunDeck/uDeploy он из коробки делать не может и его надо допиливать.
Что касается Ansible/Puppet — они тут вообще ни при чем. Они выходят на сцену после любого подходя, когда определен список хостов и список ролей.
Раз уж зашла речь про rundeck/udeploy, есть ли open source решения такого плана? Бесплатный rundeck на первый взгляд умеет существенно меньше чем jenkins pipeline.
Скорее всего, что нет. Эти инструменты не нужны в маленьких компаниях. А в больших предпочитают потратиться на платный продукт, потому что это выгоднее по деньгам, чем содержать профессионала по опен-сорсному продукту.
Что касается pipline в Jenkins — тут все по другому. С одной стороны нет ничего гибче, чем код. С другой стороны, эта штука не может работать размазанной по времени — пайплайн должен проходить за один проход. Не будет же он висеть в бесконечном цикле и разруливать разные задачи по разному.
И окружения в нем настроить если и можно, то это будет хардкод и усложнения. То есть код пайплайна вырастет до размеров uDeploy, только вот степень сложности обслуживания будет на порядок выше. А если начнете подстраивать версии артефактов пол разные окружения (я про Java) — там вообще умрете.
В общем и целом, Jenkins идеален для CI. Для CD он как-то не сильно приспособлен. Да и степень его надежности оставляет желать лучшего. Отвалившийся агент во время деплоймента в прод — это весело.
Но эта поделка никогда не станет крутым CD.
Только одна SVG библиотека. Не рассматривали вариант с RaphaelJS->SnapSVG?
Ещё бы увидеть расклад для full-stack JavaScript(front-end + node.js). Типа MeteorJS или SailJS?
В целом спасибо, буду давать ссылку на этот пост, всем кто меня спрашивал о пути развития.
п.с. еще её можно закрепить на главной странице totster.ru ибо вопросов по пути развития много.
а я php-шник и мне статья понравилась, добавил в избранное и буду кидать тем, кто задает вопросы вроде
- а как сделать свой сайт с нуля?
- а что надо учить в php?
- а почему у тебя в контроллере ларавела только try/catch и один вызов dispatchInteractor с какими-то %SomeName%::class ?
- а почему не стоит делать свой php шаблонизатор вроде twig и orm вроде Eloquent?
- а почему некоторые сайт называют реактивными?
P.S да, да, %habra-username% я знаю php вообще лучше не учить, и сам иногда сожалею что не начал в серьез заниматься python или java когда был студентом, а теперь думаю стоит начать разбираться в node.js
Буду очень благодарен за ответ т.к. сам знаком с обоими только в теории.
Ничем не лучше и не хуже. Разным задачам — разные решения.
Для питона, например, есть django, аналогов которому в ноде нет. Если мне нужно быстро сделать что-то типа новостного сайта с админкой и без сложного фронта — я возьму питон с джангой.
Если нужен сложный фронт + простенький API к нему — лучше взять ноду и какой-нибудь фронтовый SPA-фреймворк, так как можно всё написать на одном языке и примерно одинаковыми инструментами.
Если же бэкенд нужен посложнее и попроизводительнее — стоит взять что-то из более надёжных и быстрых вещей (java/c#).
Не могли бы вы объяснить, чем питон принципиально лучше, чем nodjs с какой-нибудь обвязкой (например typescript для стат. типизации)
Ммм… только не nodejs, а js. Вы ж языки сравниваете, а не интерпретатор и язык?
Хуже-лучше не очень то правильно поставленный вопрос. Но я скажу, в чем между ними принципиальная разница, которая облегчает выбор: асинхронность. Она сильно замедляет время дебага, но зато дает другие плюшки. Поэтому эти языки для очень разных задач.
Ну а ваши предложения?
Bootstrap — это набор стилизованных кнопочек. Он самый популярный, но есть и другие: Material Design Lite, Semantic UI, например. Всегда полезно знать альтернативы, а не замыкаться в одном решении. Кроме того в Bootstrap не самая лучшая конвенция именовать css-классы, "научиться" хорошему в Bootstrap не выйдет.
Другое дело — BEM. Это конвенция именования классов, изначально придуманная в Яндексе, а теперь подхвачена многими другими большими компаниями. Их подход хорошо масштабируется, позволяет вводить в проект новые стиили без риска сломать уже написанное.
А Flexbox — это такая новая функциональность в браузерах, позволяет внятно описывать раскладку элементов, которая раньше делалась через одно место.
А что скажете на тему Foundation?
И еще оффтопный вопрос. Я недавно подошел к нашему разработчику фронтэндовскому и попросил делать id= для каждого элемента, чтобы тестировщики могли в Selenium указать элемент без xpath (который может поменять и тесты полетят). И он ответил: id сегодня не используются уже и обосновал почему. Но не предложил ничего взамен.
Как эта проблема решается?
А Flexbox — это такая новая функциональность в браузерах, позволяет внятно описывать раскладку элементов, которая раньше делалась через одно место.
Осталось дождаться когда вымрут браузеры не поддерживающие grid'ы в современной редакции, тогда для многих кейсов станет совсем хорошо.
Про Flexbox очень хорошо рассказывают css-tricks.com.
А как иначе? Вот пример из Bootstrap:
<div class="form-group row">
<label for="inputEmail3" class="col-sm-2 col-form-label">Email</label>
<div class="col-sm-10">
<input type="email" class="form-control" id="inputEmail3" placeholder="Email">
</div>
</div>Для простого текстового поля нужно добавить кучу классов. Если потом добавить еще пару своих классов для переопределения стилей, то разметка становится совсем неподдерживаемой.
Другое дело, если переписать по BEM:
<div class="form-field">
<label for="inputEmail3" class="form-field__label">Email</label>
<div class="form-field__control">
<input type="email" class="form-field__input" id="inputEmail3" placeholder="Email">
</div>
</div>Классов стало меньше, зона отвественности у каждого из них понятнее. Если есть возможность, можно пойти дальше и использовать шаблонизатор, чтобы генерировать длинные имена классов с префиксами, или вообще подключить CSS-модули.
Бем изучить обязательно, а использовать нет, это самая распространенная проблема начинающих которая приводят к косякам, люди просто не знают как называть файлы, классы, названия переменных.
На замену уже потихоньку пришел и где-то доходит css модули (в связки с react) — решают те проблемы которые и бем.
flexbox конечно же нужно знать — но он элементарный — гораздо проще float, display-block, position: absolute и прочего.
А вот Bootstrap и вправду кажется не нужен — особенно чем дальше фронтендщик отошел от верстальщика
Больше похоже на список распространенных технологий/API/языков о которых необходимо иметь представление.
Учить в таком порядке — убить программиста)
И структурировано странно. Я бы, например, для фронтенда запретил вообще изучать JQuery, как самый большой источник говнокода. А вот D3, который это все делает на много лучше я бы поставил в основы. Уже только это невероятно бы повысило качество и реюзабельность. Весь список с Ангуларами, Реактами, Эмберами и пр. заменил бы на малюсенький riot.js ну т.д.
В общем в 2017-м ждем новых чудо кодеров, тащащих за собой огромные библиотеки из которых они пользуются 5%, при том что даже эти 5: можно реализовать правильно, читабельно и красиво)
Хотя, если встраиваться в команды, наверно лучше жить в этом стеке технологий, курить JQuery с Angular. Здравствуй тормозной и глючный веб)
Очевидно, что для того, что бы работать web-разработчком, учить d3 и не учить jquery очень странно :)
По этому и программисты очень разные и качество кода разное и скорость реализации одних и тех же задач разная и проекты разные и заработки.
Не всегда то, что в тренде и есть самое лучшее.
Конечно надо знать что такое jQuery, чтобы как минимум можно было временно прицепить к проекту чужой говнокод и чтобы потом хотяб смочь сделать рефакторинг с целью вырезать эту и прочую хрень)
Посмотрите примеры как D3 позволяет вертеть DOM или SVG и это при коротком и лаконичном коде. Посмотрите, что и каким количеством и качеством кода делаетя с графикой и представьте что и как можно делать с интерфейсом, если понимать идеологию D3.
А JQuery это — тонны мусора в коде, особенно с ростом проекта.
D3 отображает и обновляет слой данных и отделяет данные от DOM,
а JQuery мешает все в кучу — это как мазать краской холст каждый раз поверх. DOM надо создавать, а не патчить. Data Driven Documents это подход, концепция, а JQuery — не более, чем обертка для обычных ванильных яваскрит функций.
А используют эти библиотеки по сути для одного и того же.
Я когда ищу реализации чего-то или алгоритмы и вижу JQuery в зависимостях, то сразу в помойку этот скрипт и смотрю следующий т.к. в 99% случаях это означает что будет 5000 строк мусора на то, что можно было сделать за 300-500 строк порядка.
Я своим запрещаю эту хрень)) Но это личное дело каждого.
Графика просто наглядно показывает что и каким количеством кода может D3.
Данные не обязательно визуализировать графикой, можно и таблицами, формами, кнопками и окнами. С этим D3 справляется точно также.
Порог входа, конечно в нее выше чем в jQuery.
Даже концепцию enter/update/exit новички не сразу вкурить могут.
у них у каждого своя ниша.
Когда-нибудь веб-разработка обвалится из-за собственной перегруженности
воистину, кстати как бы я не любил php — имхо он не умер, а реинкарнировался в 7 версии и теперь сново набирает популярность лишь потому что в js вот именно прыг-скок тяни-толкай с фреймворками. Утрированно — ты блин хендбук по 1 не успел прочитать и осознать, а он уже устарел и ваще он даже не запустится ибо нода обновилась :)
А у PHP разве не такая же куча популярных фреймворков: Yii, Laravel, Symfony, Zend, ...?
Тут разве что Python рассматривать, вот там действительно при всем разнообразии, есть два фреймворка «по-умолчанию»: Flask для простых задач и Django для всего остального.
У них схожие идеологии и довольно редкие релизы версий раз в 3-5 лет. А еще зная Symfony вы за день начнете писать на Yii. В JS такое не прокатит.
На пыхе фреймворк береться из задачи. Если у тебя лендинг тогда в топку фреймворк, можно обойтись небольшим скриптом.
нужен небольшой сайт на shared хостинге тогда — Yii, хотя на 80% таких вариантов хватит и такого зла как cms
огромный корпоративный портал с адской бизнес логикой тогда берем Symfony
огромный корпоративный портал с адской бизнес логикой и задолбало строить абстрактную фабрику для абстрактной фабрики абстрактного класса для объекта с +100500 интерфейсами и дедлайн был вчера и вообще ты только научился писать инлайном — тогда бери laravel
если ты супер-про который знает что ему нужно и у тебя есть тз по вещи которую тебя даже полным именем называть влом — тогда берешь Zend/CodeIgniter или выбрасываем laravel оставляя только Illuminate из него, добавляем еще пару библиотек и из этой солянки строим уже что-то такое что кровь стынет в жилах.
нужна очень хорошая производительность берем phalcon
Плюс фреймворки используют Psr и другие общие стандарты, что позволяет невозбранно в одном проекте использовать части от разных фреймворков.
If you think that these can be improved in anyway, please do suggest.
У веб разработки есть база: html + css + js + php, все остальное, включая другие языки и фреймворки — это частные случаи тонкой настройки и вкусовщина рабочего процесса, единицы проектов реально требуют той или иной технологии.
Иметь возможность поднять любой проект самому в полном цикле — приносит намного больше профита, как я говорю своим юниорам — мы не ракеты запускаем, чтобы ныть о сложности.
Backend в веб разработке — это тоже очень специфическая вещь, все время уходит на стилизацию интерфейсов, в командах 1 back end на 3-4 front end разработчика — для бизнеса удобно ), для разработчика — искуственное ограничение.
Статья — прекрасный повод проявить технологическое высокомерие специалисту любого профиля)
А если серьёзно — на глубины не претендуя, статья обладает некоторым обзорным эффектом и ценностью как у составленной базы данных: вроде бы все элементы в отдельности — тривиальны, но по совокупности обладают некоторой неаддитивной пользой.
Вы описываете ситуацию, когда back end натягивает верстку на php движок и не должен отвелкать Front End?
Я за Full stack, но учитывая, что кадров на рынке нет, приходится делить обязаности и для Junior создавтаь чуть ли е автоматику.
вэб бэкенд разработчик должен знать HTML, CSS, JS на ДОСТОЙНОМ уровнеЕсли он фронт не пишет, то зачем это необходимо? (кроме общей компетенции и всего такого)
К сожалению, за 10 лет ни одного заказчика не нашлось, кто бы оценил, хоть что-то. Ты делаешь, делаешь у тебя внутри супер всё хорошо и красиво. А он открывает сайт какой-то на wp без всего и говорит во видишь как здорово!
И ты думаешь, нужно было сделать так же. Взять денег, сказать, что работа сложная, делать буду 2 месяца. Сделать всё за 20 минут и отдыхать, потом сдать.
Я уже пришел к этому, взял WP за основу и перекроил index.php под кеш, чтобы отрубать компиляцию WP и делаю на нем сайты, нечего выпендриваться )
Потом мне понравился EmberJS, но я вернулся на Angular 2/4 потому что рынок нанмного больше. Конечному клиенту всеравно — а посредникам «профессионалам» подавай Angular.
В итоге выбор сводится к тому, есть ли у вас выход на прямого закачика, чтобы самостоятельно выбирать фреймворк или «самый популярный фреймворк».
Бизнес зачастую просто не думает про поддержку получившейся на jquery лапши через 5-10 лет. А посредники могут вполне понимать, что это им поддерживать и через 5 лет.
А к чему jQuery тогда? Есть нативный DOM, так же еще быстрее, а код организовать вы уже умеете. Наверно у вас уже есть самописные хранилища state приложения, самописные роутеры, обертки над сокетами, обертку над ajax тоже можно самому написать. Выносить обновление dom под капот тоже не стоит (как в реакт, например), можно же просто подписаться на что-нибудь и в ручную апдейтить dom (не забыть отписаться потом, и не забыть проверить вообще в dom ли у нас нужные элементы).
Это была ирония, если что.
Фронт-энд быстро эволюционирует, новые фреймворки это не новые технологии, это новые виды (возможно только в мире фронта) абстракций, лучшие выживают (react, angular), остальные умирают (где там backbone и knockout сейчас).
Мой интерес, прочитав статью, живенько двинул по ссылке на сайт "Нетологии", но разбился об стену дичайших тормозов. :)
Статья чтобы испугать новичков и они пошли к вам, а не сами учились. Чтобы начать работать достаточно знать на среднем уровне css+html и на низком js, и уже можно работать на фрилансе или джуном в мелкой конторе, потом как пойдут заказы уже можно учить, то что продиктует рынок.
Хотелось бы располагать такими статьями и в ПО, и по играм, и по робототехнике). Сильно может помочь.
Как стать веб-разработчиком в 2017 году — план действий