Comments 78
Если бы Facebook сейчас выбирал технологию для себя, я сомневаюсь, что он взял бы за основу PHP.
Хотелось бы ссылку, где об этом пишет (говорит) кто-то из топ менеджеров FB, а не Ваши сомнения.
ps
Вдруг ссылка имеется, я хоть почитаю.
Сайт белого дома на Wordpress, а какая у этого сайта посещаемость? Известность брэнда не означает высокой посещаемости его сайта. У меня друг — супер-профи вордпресса с зп 10к+ баксов месяц и для них супер-достижением является 2млн уников в месяц. Это меньше 70к посетителей в сутки.
Почему вы считаете фреймворк рамками и ограничениями? Вот это только я понять не могу, если честно. К примеру, если мы будем смотреть на Laravel — то на его основе можно написать абсолютно любое приложение, какие ограничения могут подразумеваться в этом случае? То что мы классы используем вместо простых функций чтоли?) Впрочем, даже на основе функций код можно вполне писать прямо внутри Laravel, я даже пост об этом писал недавно на хабре, который правда заминусовали. Или есть что-то более серьёзное из доводов?
Просто честно, мне кажется довольно странным только этот довод из всей вашей статьи. Если смотреть на Laravel, то это прекрасная основа для написания любого мыслимого проекта. Вся конструкция Laravel выглядит как очень гибкий набор мягко связанных друг с другом компонентов, использующих, к тому же, в большинстве ситуаций контракты для взаимодействия между друг другом. Всё это позволяет заменить, при желании, практически любую подсистему вашего проекта.
К примеру, вы захотели реализовать свою проприетарную систему кеширования. Нет проблем: напишите класс для связи с вашей системой, удовлетворяющий контракту кеш-подсистемы laravel — и используйте его. Об этом и глава отдельная в официальной документации имеется. И так со всеми подсистемами. Вы можете заменить практически всё что угодно.
Мы сейчас работаем над проектом, в котором мы решили использовать шаблонизатор pug. Ничего особенно сложного. Gulp компилирует шаблоны в php файлы, понятные laravel.
Мы захотели разбить весь наш проект на отдельные модули, и хранить контент каждого модуля в отдельной папке. Снова никаких ограничений фреймворк нам не доставил, благо в нём есть такие прекрасные штуки как сервис провайдеры и возможность указать место хранения других шаблонов.
В общем, если честно, то ваше мнение в этом плане, на мой взгляд, довольно субьективное, и оно не отражает реальную ситуацию с фреймворками на нынешний пред-2017-й год. Фреймворки стали более гибкими сегодня. Раньше было примерно так, как вы пишете, это я согласен.
Плюс, конечно, есть ещё такая тонкость, что мой личный опыт довольно узкий. Такой уж я человек: я больше стараюсь углубиться в изучение какой-то конкретной области, чем бегать туда-сюда между различными технологиями. В силу этого, я больше знаю PHP, Кохану и Laravel, и очень мало знаю об остальных фреймворках этого мира. Вполне возможно, что то, что вы говорите, является истиной по отношению к другим фреймворкам. Но и Кохана, кстати, в своё время предоставляла возможность довольно легко расширять и переписывать всю основную логику фреймворка без всякого затрагивания основной системной папки благодаря идее прозрачного расширения классов. Чем я также неоднократно с большим удовольствием пользовался во времена расцвета этого фреймворка)
Автор, напишите честно — потому что у вас нет опыта работы с большими проектами, даже рядом не проходили.
Ваше заявление про Go выглядет особенно странно в контексте «Выбор технологий для большого и не очень большого веб-проекта»,
где как раз у Go одни из ведущих позиций
;)
С компетентностью автора все понятно —
в качестве перспективных систем под большой проект он рассматривает CMS.
CMS, Карл!!!
Под большой проект!!!
При этом микросервисы, которые являются нормой для больших проектов — даже не упомянуты.
Видимо, 11-летний опыт автора — это в основном хоумпеджи небольших фирмочек.
А большим он называет проект больше, чем 6 человеко-месяцев.
Если хочешь критиковать, сначала прочитай, а потом пиши комментарии и обоснование к нему.
Впрочем, твой заминусованный рейтинг на Хабре отлично иллюстрируют твой профессиональный уровень. Сообщество его уже оценило)
2. Статья называется «Выбор технологий для большого и не очень большого веб-проекта». Где тут, блин, микросервисы?
;)
2. Подчеркну еще раз для непонятливых — статья называется «Выбор технологий для большого и не очень большого веб-проекта». Где тут, блин, микросервисы?
Друг мой, найди хоть одну фразу в статье, где я рекомендовал CMS для большого проекта? Ты не читал статью, просто пролистал, увидел слово CMS и сделал какие-то выводы. CMS я рекомендовал для МАЛЕНЬКИХ проектов
Статья называется «Выбор технологий для большого и не очень большого веб-проекта»
Маленький != большой
Маленький != не очень большой
Маленький != средний
Маленький — вообще не соответствует названию
Тем не менее вы про CMS разжевали подробно.
Видимо это единственное, в чем вы разбираетесь.
Тем не менее вы про CMS разжевали подробно.Тем не менее многие большие проекты на CMS :)
Ну и, если не CMS, то что по-Вашему?
Какие большие на CMS? Ну так Вы же писали статью… :)
https://trends.builtwith.com/shop/
Из топ-10000 магазинов — 10% использует WordPress, а есть и другие. :)
Довольно новый и небольшое сообщество. Не стал его рассматривать. Но со временем все может быть.
Go ровесник node.js, оба появились в 2009
У обоих развитое комьюнити
Так что странно упомянуть один и упустить другой
Писать всё на JS — банально дороже по затратам, как по мне. Да, круто, модно, молодёжно. Но писать на JS на стороне сервера — это, блин, не на жиквери лапшу лепить) Порог вхождения выше же. Плюс, до сих пор нет какого-то реально сильного фреймворка на ноде с кучей компонентов от сообщества, которые бы ты просто подключал и использовал в своей работе. Что имеется на других языках зачастую.
Если же я не прав — ткните меня в нос подобным фреймворком) Из того что я знаю — только Sails шуть шуть подходит под мои запросы. Да и то я так и не закрепился на нём, хотя было желание написать что-то.
Скорее нет (пока) вменяемого ORM (sails-овый народ тоже ругает, сам не пробовал), а так и express-а хватает для подавляющего большинства. Буржуи активно loopback используют. Для ноды фрейворк не нужен, это надо понять, принять и научится с этим жить. npm — чем не фреймворк? )
2) php-программистов чисто статистически больше всего
3) php7 весьма неплох
3) php7 весьма неплох
А php 5.* был ужасен и никто и никогда не выбирал его для больших веб-проектов (сарказм).
ps
Часто пишут, что FB для серверной части не использует php, скорее используется С++ и hiphop. Это очень важно отмечать, так как проектов размера мордокнижки очень мало и клиент с горящим взглядом, который делает очередной заказ на супер мега сложную информационную систему, которая круче авито и ОК вместе взятых, вряд ли, при Вашей жизни, достигнет посещаемости при которых php будет тормозить развитие его сайта. Это с учётом, что мы говорим о веб-проекте.
Кстати, ВК при Дурове использовал pure C на сервере. Отмечу, большие и сложные проекты реально сложны именно в серверной части (back end).
Как вывод большой проект надо писать на С, да?
Есть! :)
Мы сделали жалких фреймворщиков. :)
Пока что из результатов опроса можно сделать вывод, что эту статью прочитало больше всего людей, которые кроме PHP ничего другого не знают.
«В технологиях я бы выделил 3 уровня абстракции:
Чистый язык — это материал, из которого можно сделать все, что угодно. На чистом языке сделаны все крупнейшие сайты мира с посещаемостью в сотни миллионов и миллиардов пользователей
Фреимворк — это некая среда разработки для программиста с готовыми правилами и инструментами. Фреимворк, с одной стороны, помогает и ускоряет разработку, а с другой, накладывает определенные ограничения. На фреимворках делаются проекты средней сложности с посещаемостью в миллионы.»
:)
Большое спасибо за обзор. Внимательно ещё не успел прочитать, но из бегло просмотренного явно видно, что вы в теме, так как большинство ваших умозаключений коррелируют с моим опытом и мыслями на эту тему.
Если у вас есть опыт разработки больших проектов, хотя бы на несколько миллионов пользователей, прошу не просто проголосовать, но и обосновать свое мнение в комментариях, так как у каждого разные опыт и предпочтения
У меня нет опыта разработки проекта с такой большой посещаемостью, но всё равно хочется рассказать о своём опыте :) Самый популярный проект, разработку которого я вёл первые пару лет его жизни (сейчас я уже в другом проекте), имеет в данный момент посещаемость в 300 тысяч человек в месяц, и кол-во просмотров в пол миллиона. Работает он на Kohana фреймворке. Когда мы его начинали писать — Кохана тогда была популярна, а Laravel только набирал популярность :) Это большой медицинский портал с кучей всяких функций для пациентов и врачей, вроде записей на приём, отзывов, медицинских статей, каталога организаций, и так далее. Плюс, он ещё и мультиязычный и развивается сразу для России, Индии, США и может уже и для ещё каких-то стран в дополнение к этим.
В целом, Кохана и здравый котелок решили все возникшие проблемы. Разработку мы вели втроём — если говорить о программистах. Был я, и плюс была пара ребят, которые более-менее умели писать на фреймворках и на джс. На стороне фронтенда сначала мы всё писали на Backbone, так как он тогда был более-менее популярен. А впоследствии я многое переписал на Riot.js, когда узнал про него, так как он всё-таки намного более удобен для сложной JS логики.
Сегодня я всё также продолжаю использовать PHP для бэкенда, и меня всё вполне устраивает. Я снова веду разработку большого мультиязычного проекта, уже с другими людьми, в качестве технологий мы выбрали Laravel 5.1 LTS, Riot.js для сложных JS компонентов, шаблоны на Jade, которые компилируются gulp'ом в .blade.php. И SystemJS в связке с JSPM, которые отвечают за асинхронную подгрузку JS компонентов.
Честно, для веб-проектов, всё-таки, PHP — хорошая штука. В том числе об этом говорят ребята из Slack, к примеру. Я никаким образом не хочу унизить любые другие инструменты для разработки — вполне уверен, что и у них есть сильные стороны. Просто пишу о своём опыте.
Популярные фреймворки и платформы:
Кажется, если у Java стоит Spring, то для C# должен быть ASP.NET MVC/Core.
Популярные фреймворки и платформы:
JS: Node.js, AngularJS
Node.js фреймворк?
Других фреймворков, кроме AngularJS типа нет?
Кроме того, имеет смысл уточнить, что подразумевается под «большим проектом»:
— «большой в длину» — относительно немного относительно узких, но длинных таблиц (например соцсеть, сайт отзывов или объявлений)
— «большой в ширину» — много широких, но относительно коротких таблиц (например система ERP предприятия)
В первом случае логики обычно немного, но она должна быть очень быстрой и/или масштабируемой.
Во втором случае случае логики много и она сложная, но количество обрабатываемых сущностей не так велико.
Эти особенности тоже влияют на выбор стека. И поэтому, например, в корпорациях бизнес-процессы автоматизируют на Java, а в соцсетях используют PHP.
Будет написано ровно то, что нужно.
А не куча абстракций на все случаи жизни.
>в корпорациях бизнес-процессы автоматизируют на Java
Это просто глубое предубеждение, что это нужно делать на яве. :)
PHP: Facebook, Вконтакте, КиноПоиск
А где же любимая бадушечка? Мне за них обидно.
Т.е. гворить о том, что CMS подходит для X посещаемости, а фреймворк для Y не совсем корректно.
Что касается «трендов», то думаю, что в большей степени это хипстерство, особенно относительно JS для бэкэнда — в более-менее сложном проекте без какой-никакой типизации, стандартов и т.д. не обойтись, а по опыту, в среде JS-программистов c typescript или flow знакомы единицы. Многие проекты на JS, которые популярны и сейчас на слуху, лучше не отрывать с целью проникнуться чистотой и логикой кода.
«А если нет разницы зачем платить больше?»
Даже сам факт того, что большая часть не знает ничего кроме одного языка говорит о том, что они нашли в нем что искали и смысла искать дальше не было. Все открытия в том числе и новых языков идут от недостатков старых. Никто не будет искать новую технологию пока считает что старая его полностью удовлетворяет.
Но, как я понял, Вы измеряете сложность проекта в количестве будущих пользователей. Я предлагаю добавить вторую ось — функциональная сложность. Ведь может быть проект с огромной посещаемостью и относительно простым функционалом (например, сайт смешных коротких цитат) и проект с малой посещаемостью, но ужасающе сложным функционалом (например, внутренние корпоративные веб-системы — мы создаем узкоспециализированную срм как saas-решение). Можно выделить четыре квадранта, в каждом будут свои языковые лидеры: например, сложный функционал и малая посещаемость (как пример, enterprise-сегмент) — хорошо подходят Java и C#, простой функционал и большая посещаемость — Ruby (условно).
Шаг 1 (критический). В зависимости от предполагаемой популярности проекта и функционала делаем выбор в пользу CMS, фреймворка или чистого языка.
Шаг 2 (не слишком критический, потому что Вы сами говорили о том, что большие проекты можно встретить на самых разных языках): в зависимости от остальных 15 критериев выбираем конкретный язык.
Самое важное выбрать: CMS или писать всё самим, а какая CMS и на каком конкретно языке писать — вопрос важный, но второго плана. Нет? В случае CMS мы тратим десятки тысяч рублей, при самостоятельной реализации с фреймворком — сотни тысяч, без фреймворка — ещё большие сотни тысяч :)
Странно, что в качестве метрики выбрали именно посещаемость. Имхо, самый важный критерий — сложность, а на втором месте — эффективность. Просто потому, что медленно работающий сайт можно быстро "починить" вливанием денег в железо, в то время как проект, провалившийся из-за недостаточного качества фреймворка/языка/программистов, починке не подлежит.
С другой стороны, очень мало сложных, посещаемых, эффективных проектов начинались именно такими. Как правило, все начинается со стартапов, где требуется сделать что-то работающее за минимальные деньги, а уже потом как-то чинить и переписывать. Если выстрелит.
Поэтому в интернете всегда будет много мнений, на чем надо писать сайт.
Scala похожа на Java? Да и с чего бы этому языку быть будущему веб разработки?
Поподробней пожалуйста про архитектуру. Очень уж хочется сравнение архитектуру популярных CMS :-)
Пожалуйста с конкретикой, ядро построено так — это имеет следующие преимущества и недостатки, а так получается вы скатываетесь до холивара, типа Windows отстой из-за того, что мой знакомый мне сказал, что это так, он не может ошибаться потому, что использует Mac в повседневной работе.
Всегда любопытно почитать мнение "экспертов".
Никакая это не проблема.
Так как уж совсем экзотикой разработчики не владеют.
И если соглашаются на ней делать — то это уже их ответственность.
Соглашаются, делают говнокод, переписывают его через год нормально. Каждый второй запрос у нас — переписать старое полурабочее решение нормально.
Неверно интерпретируете причину.
Вы переписываете за студентами или многолетние запущенные разработки.
Кто-то спрашивает у нас, как у разработчиков, как правильно, а кто-то приходит и просит сделать на какой-то конкретной технологии
Не из за этого 90% проблем.
Выбор технологий для большого и не очень большого веб-проекта