Только зарегистрированные пользователи могут участвовать в опросе. Почему вы считаете фреймворк рамками и ограничениями? Вот это только я понять не могу, если честно. К примеру, если мы будем смотреть на Laravel — то на его основе можно написать абсолютно любое приложение, какие ограничения могут подразумеваться в этом случае? То что мы классы используем вместо простых функций чтоли? Впрочем, даже на основе функций код можно вполне писать прямо внутри Laravel, я даже пост об этом писал недавно на хабре, который правда заминусовали. Или есть что-то более серьёзное из доводов? Просто честно, мне кажется довольно странным только этот довод из всей вашей статьи. Если смотреть на Laravel, то это прекрасная основа для написания любого мыслимого проекта. Вся конструкция Laravel выглядит как очень гибкий набор мягко связанных друг с другом компонентов, использующих, к тому же, в большинстве ситуаций контракты для взаимодействия между друг другом. Всё это позволяет заменить, при желании, практически любую подсистему вашего проекта. К примеру, вы захотели реализовать свою проприетарную систему кеширования. Об этом и глава отдельная в официальной документации имеется. И так со всеми подсистемами. Вы можете заменить практически всё что угодно. Мы сейчас работаем над проектом, в котором мы решили использовать шаблонизатор pug. Gulp компилирует шаблоны в php файлы, понятные laravel. Мы захотели разбить весь наш проект на отдельные модули, и хранить контент каждого модуля в отдельной папке. Снова никаких ограничений фреймворк нам не доставил, благо в нём есть такие прекрасные штуки как сервис провайдеры и возможность указать место хранения других шаблонов. В общем, если честно, то ваше мнение в этом плане, на мой взгляд, довольно субьективное, и оно не отражает реальную ситуацию с фреймворками на нынешний предй год. Фреймворки стали более гибкими сегодня. Раньше было примерно так, как вы пишете, это я согласен. Плюс, конечно, есть ещё такая тонкость, что мой личный опыт довольно узкий. Такой уж я человек: В силу этого, я больше знаю PHP, Кохану и Laravel, и очень мало знаю об остальных фреймворках этого мира. Вполне возможно, что то, что вы говорите, является истиной по отношению к другим фреймворкам. Но и Кохана, кстати, в своё время предоставляла возможность довольно легко расширять и переписывать всю основную логику фреймворка без всякого затрагивания основной системной папки благодаря идее прозрачного расширения классов. Чем я также неоднократно с большим удовольствием пользовался во времена расцвета этого фреймворка. Писать всё на JS — банально дороже по затратам, как по мне. Да, круто, модно, молодёжно. Но писать на JS на стороне сервера — это, блин, не на жиквери лапшу лепить Порог вхождения выше же. Плюс, до сих пор нет какого-то реально сильного фреймворка на ноде с кучей компонентов от сообщества, которые бы ты просто подключал и использовал в своей работе. Что имеется на других языках зачастую. Если же я не прав — ткните меня в нос подобным фреймворком Из того что я знаю — только Sails шуть шуть подходит под мои запросы. Да и то я так и не закрепился на нём, хотя было желание написать что-то. Большое спасибо за обзор. Внимательно ещё не успел прочитать, но из бегло просмотренного явно видно, что вы в теме, так как большинство ваших умозаключений коррелируют с моим опытом и мыслями на эту тему. У меня нет опыта разработки проекта с такой большой посещаемостью, но всё равно хочется рассказать о своём опыте: Самый популярный проект, разработку которого я вёл первые пару лет его жизни сейчас я уже в другом проекте , имеет в данный момент посещаемость в тысяч человек в месяц, и кол-во просмотров в пол миллиона. Работает он на Kohana фреймворке. Когда мы его начинали писать — Кохана тогда была популярна, а Laravel только набирал популярность: Это большой медицинский портал с кучей всяких функций для пациентов и врачей, вроде записей на приём, отзывов, медицинских статей, каталога организаций, и так далее. Плюс, он ещё и мультиязычный и развивается сразу для России, Индии, США и может уже и для ещё каких-то стран в дополнение к этим. В целом, Кохана и здравый котелок решили все возникшие проблемы. Разработку мы вели втроём — если говорить о программистах. Был я, и плюс была пара ребят, которые более-менее умели писать на фреймворках и на джс. На стороне фронтенда сначала мы всё писали на Backbone, так как он тогда был более-менее популярен. А впоследствии я многое переписал на Riot. Сегодня я всё также продолжаю использовать PHP для бэкенда, и меня всё вполне устраивает. Я снова веду разработку большого мультиязычного проекта, уже с другими людьми, в качестве технологий мы выбрали Laravel 5. И SystemJS в связке с JSPM, которые отвечают за асинхронную подгрузку JS компонентов. Честно, для веб-проектов, всё-таки, PHP — хорошая штука. В том числе об этом говорят ребята из Slack , к примеру. Я никаким образом не хочу унизить любые другие инструменты для разработки — вполне уверен, что и у них есть сильные стороны. Просто пишу о своём опыте. Странно, что в качестве метрики выбрали именно посещаемость. Имхо, самый важный критерий — сложность, а на втором месте — эффективность. С другой стороны, очень мало сложных, посещаемых, эффективных проектов начинались именно такими. Как правило, все начинается со стартапов, где требуется сделать что-то работающее за минимальные деньги, а уже потом как-то чинить и переписывать. Поподробней пожалуйста про архитектуру. Очень уж хочется сравнение архитектуру популярных CMS: Пожалуйста с конкретикой, ядро построено так — это имеет следующие преимущества и недостатки, а так получается вы скатываетесь до холивара, типа Windows отстой из-за того, что мой знакомый мне сказал, что это так, он не может ошибаться потому, что использует Mac в повседневной работе. Только полноправные пользователи могут оставлять комментарии. TM Feed Хабрахабр Geektimes Тостер Мой круг Фрилансим. Хабрахабр Публикации Пользователи Хабы Компании Песочница. SECL Group 45,93 Делаем стартапы успешными! За годы работы я часто слышу вопросы о выборе технологий для того или иного веб-проекта. Кто-то спрашивает у нас, как у разработчиков, как правильно, а кто-то приходит и просит сделать на какой-то конкретной технологии. Проблема в том, что большинство выбирают технологии по субъективным причинам, и пока я не слышал достойного и понятного рассуждения, которое позволило бы выбрать технологию объективно, основываясь на фактах, а не желаниях. Даже немногие итишники могут правильно выбрать технологию, ведь для этого нужно: Но прежде, чем что-то выбирать, давайте посмотрим, какие технологии бывают, чем они отличаются и в каких случаях какую технологию выбрать. Как чаще всего выбирают технологию сейчас: Она мне нравится Знакомый посоветовал Прочитал в Интернете На этой технологии сделан аналогичный сайт В чем тут проблема: А что, если по требованиям она не подходит? Или на ней работают очень дорогие и редкие специалисты? Или она вообще умирает? И даже если он программист с опытом, он не может знать всех решений на всех популярных языках. Ведь никто не спрашивает, по каким критериям выбирал этот знакомый. Если этот знакомый не CTO Google, я бы так просто не доверял такой рекомендации. Но опять же, чтобы разобраться во всех решениях человеку, пусть даже с крепкими знаниями в разработке, нужно время. А без знаний в разработке все прочитанные технические обзоры ничего не стоят. Если бы Facebook сейчас выбирал технологию для себя, я сомневаюсь, что он взял бы за основу PHP. А еще может быть, что технология уже устарела, её продавили на основе прошлых 3-х пунктов, выбрали какую-то разрекламированную технологию, а не действительно эффективную и т. Вы вряд ли можете знать реальные причины выбор технологий в других проектах. Оптимальные технологии используются крайне редко в аналогичных проектах. Таким образом, ни один из вышеперечисленных методов выбора технологий разработки не отвечает критериям объективности. Поэтому стоит сначала определить эти критерии, а уже потом подбирать по ним техническую платформу. Ниже я попытаюсь выделить действительно важные для проекта критерии, на которым мы и будем основываться. Важные критерии при выборе технологий: Размер и тип проекта Сложность проекта Скорость разработки Стоимость специалистов Доступность специалистов Доступные инструменты разработки Наличие готовых решений Гибкость решения Наличие широкого сообщества Отказоустойчивость решения Тренд его развития Наличие подробной документации Стоимость поддержки Требования к нагрузкам Требования к безопасности Кроссплатформенность Возможности интеграции с другими решениями Выбирая технологию по таким критериям, мы сможем добиться объективного выбора и тем самым сэкономить себе время и деньги. Какие бывают проекты К технологиям мы еще вернемся, а пока давайте разберемся, какие бывают проекты. Часто тип проекта говорит сам за себя, и можно сразу сказать, что подойдет: По сложности проекты делятся: Простые визитки, лендинги, простые интернет-магазины, простые приложения — такие решения обычно делаются на тематических коробочных решениях, CMS или шаблонах. Средние сложные интернет-магазины и маркетплейсы, порталы национального масштаба, разнообразные сервисы, продвинутые приложения — такие решения обычно делаются на фреимворках. Сложные огромные порталы, социальные сети, инновационные и нетиповые решения — ядро таких проектов обычно разрабатывается на чистом нативном языке программирования. Для большинства популярных тематических решений уже давно есть коробочные продукты, и, если мы не пытаемся сделать какого-то монстра, то правильнее будет выбрать именно их. Решений очень много, все в одной статье описать невозможно. Языки программирования В технологиях я бы выделил 3 уровня абстракции: Чистый язык — это материал, из которого можно сделать все, что угодно. Ограничивают нас только возможности языка. На чистом языке сделаны все крупнейшие сайты мира с посещаемостью в сотни миллионов и миллиардов пользователей, такие как: Instagram, YouTube, Pinterest, Tumblr, Dropbox, Twitter, Facebook, Amazon, Digg, LinkedIn и другие. Более того, крупнейшие проекты в мире даже создают новые технологии для себя, так как уже существующие их не устраивают. Фреимворк — это некая среда разработки для программиста с готовыми правилами и инструментами. Фреимворк, с одной стороны, помогает и ускоряет разработку, а с другой, накладывает определенные ограничения. На фреимворках делаются проекты средней сложности с посещаемостью в миллионы. CMS — это уже готовое решение, конструктор, в котором мы по частям собираем нужный проект. Его скорее не программируют, а настраивают. Ограничений тут огромное количество, выйти за границы коробки сложно и неэффективно. На CMS делаются простые сайты с посещаемостью до миллиона пользователей в месяц. Чаще всего один уровень абстракции базируется на другом. То есть на чистом языке делают фреимворки, а на фреимворках делают CMS. Для каждого популярного языка есть много разных фреимворков и CMS, но об этом позже. Сегодня есть огромное количество разных языков программирования, на которых делают сайты. И, более того, на всех популярных языках есть примеры огромных сайтов. Если 10 лет назад, говоря о технологиях больших сайтов, все говорили преимущественно о Java, то сегодня это может быть почти любой язык, и утверждать, что сайты делаются на каком-то конкретном языке, — стереотип. Это связанно с развитием самих языков, за последнее десятилетие многие сильно продвинулись в развитии и получили широкие возможности. Конечно, каждый язык чем-то отличается, и выбирая мы опять же должны руководствоваться объективными критериями с оглядкой на задачи проекта. На чистом языке, без использования фреимворков и коробочных решений, пишутся огромные проекты с повышенными требованиями по гибкости, нагрузкам и безопасности. Для таких огромных проектов часто бюджет не играет такого значения, как эффективность. Чем больше проект, тем больше будет требований по гибкости и нагрузкам, а значит, проще писать все с нуля, выделяя на это лучших специалистов, чем если брать какие-то готовые решения, которые непонятно кем писались и непонятно какие проблемы в них скрыты. К примеру, когда речь о небольшом проекте с посещаемостью в 10 тыс. Когда же мы говорим о сайте с посещаемостью в млн. Чем больше проект, тем больше стек технологий, который в нем используется. В огромных порталах может использоваться сразу несколько языков программирования. Опять же, мы приходим к объективным критериям выбора технологий. Часто один язык может хорошо решать одну задачу, а другой — другую. Такие проекты могут быть настолько огромными, что их части могут работать на разных серверах, с разными доменами поддоменами и разными технологиями. Не следует бояться винегрета технологий в большом проекте, хотя и допускать его нужно только, когда это действительно необходимо, а также помнить, что далеко не все технологии совместимы. Самый яркий пример использования разных технологий — Google. Более того, Google активно создает новые технологии, как, например, популярный нынче AngularJS. Попробую дать краткую характеристику каждому из популярных языков: PHP — его используют в основном для простых и средних проектов. Очень много коробочных решений. Антитренд последних лет, хотя с выходом последней версии языка под номером 7, он получил действительно мощные возможности. Python — современный язык, разработка на нем быстрая и качественная. Используют его для средних и больших проектов. Программистов найти проблематично, и стоят они не дешево. Ruby — современный язык, разработка на нем также быстрая. Его используют в основном для разработки простых и средних проектов, часто разрабатывают стартапы. Программистов также мало, и они дорогие. Java — разработка на нем очень долгая и дорогая. Его используют в основном для больших проектов со специфическими требованиями. C — аналог Java, также используют для больших проектов, часть в сфере FinTech. JS — очень быстро развивается, тренд последних лет. Огромное количество наработок, и можно писать все, что угодно, даже игры. Его используют для средних и больших проектов, но действительно мощные возможности этот язык получил недавно, потому примеров больших проектов пока мало, специалисты самые дорогие, и найти их сложнее всего. Я описал самые популярные языки, которые сегодня используются под веб. Есть много новых языков, которые очень быстро растут, в частности Scala и некоторые другие. Но пока они довольно молодые и сырые. Я бы не рекомендовал бежать за модой и писать на них, пока они не разовьются во что-то большее. Facebook, Вконтакте, КиноПоиск Python: Instagram, Pinterest, Reddit Ruby: Ebay, Amazon, Alibaba C: Guru, Stack Overflow, Bank of America JS: LinkedIn, Walmart, PayPal Эти примеры отлично показывают, что большие сайты могут быть на разных языках, и это нормально. Опять же, приходим к тому, что выбирать технологию нужно под требования, руководствуясь объективными причинами. Фреймворки и платформы Это некая среда разработки для программистов, где есть готовая инфраструктура и ряд готовых функций со стандартными решениями типичных задач. Такой себе полуфабрикат, из которого можно сделать конфетку. На каждом языке есть много разных фреймворков. Есть как общие, которые создавались для разработки любых решений, так и специализированные, под узкие задачи. Например, Sylius — специализированный E-commerce фреймворк на основе Symfony. Также есть те, на которых делаются большие и сложные решения, а другие для этого не предназначены. Ниже я опишу популярные фреймворки для каждого из языков, на которых можно писать большие и сложные решения. На фреймворках разрабатываются довольно большие и сложные сайты с уникальным функционалом. Это значительно быстрее и дешевле, чем на чистом языке, но при этом такое решение позволяет разрабатывать действительно сложные вещи и оптимизировать все это под нагрузки. Кроме того, это почти всегда более безопасно, чем любая коробочная CMS. Популярные фреймворки и платформы: Ruby On Rails Java: Меньше на других языках, а на некоторых действительно качественных фреймворков вообще всего один, как у языка Ruby. У Java очень много разных фреймворков для разных целей, и не только для сайтов. Все эти фреймворки ежегодно развиваются, выходят все новые и новые версии, одни фреймворки обгоняют другие. Например, Laravel только в последние несколько лет вышел на первое место по популярности, хотя самые сложные сайты до сих пор делаются на Symfony. Недавно мы проводили исследования по тем фреймворкам, на которых специализируемся. Смотрели в каких больших проектах они используются. Также мы писали, как мы разрабатывали социальную сеть на Symfony вместе с API статья больше про API, самое широкое описание в рунете по этой теме. Такие же огромные сайты есть на каждом из перечисленных фреймворках. Таких решений очень много на любом языке, но исторически так сложилось, что в основном все популярные CMS сделаны на PHP. Тут дело в развитии языков, раньше простые сайты, для которых и создавались CMS, писались на PHP. Я еще застал те времена, когда CMS почти не было, были скрипты — отдельные готовые части разных сайтов. Так и получилось, что основные CMS сделаны на PHP. Сегодня CMS на других языках развиваются слабо, потому что уже есть сильные конкуренты на PHP, а для простого сайта язык не играет большой роли, поэтому все смотрят на возможности этих готовых продуктов. CMF, если говорить простым языком, — это что-то среднее между CMS и фреймворком по возможностям. Обычно CMF используют для самых сложных сайтов из этой категории. Этот подход позволяет избавиться от лишних частей CMS, которые не нужны конкретному проекту. CMS бывают разные по назначению: Разные по условиям использования: Для каждой популярной CMS есть много разных платных и бесплатных модулей, которые легко подключать и использовать. Маленькие сайты, которые в основном нужны для малого бизнеса, почти всегда используют CMS. Это позволяет очень сильно экономить время на разработку. Кроме того, для настройки таких решений не нужны дорогие программисты, обычно это могут делать новички в программировании, по крайней мере саму настройку, если уже нужно писать код, тут сложнее. Именно в работе с CMS возникает больше всего непонимание среди конечных заказчиков таких решений. Любая CMS — это тонны готового программного кода, на все случае жизни. В коробочной поставке идут десятки и сотни модулей. Все это очень сильно ограничивает специалистов. Еще часто взламывают CMS через модули сторонних разработчиков, в которых есть критические уязвимости, потому что мы никогда не знаем, какого уровня программист писал тот или иной модуль. То есть любая CMS НЕ рассчитана для большого и сложного сайта. Она не может выдержать большие нагрузки. Это решение небезопасно, чтобы не говорили разработчики конкретной CMS. Я видел решения почти на всех популярных CMS, с многими за более, чем 10 лет работы, пришлось поработать лично. Часть из них популярна в рунете, а часть знают в основном на западе. На используемые в них языки CMS разбивать нет смысла, по причинам, описанным выше. Лучше сказать несколько слов про каждую популярную CMS: WordPress — некогда блоговый движек, сейчас на ней делаются почти любые сайты, включая магазины. Одна из самых популярных CMS в мире, есть примеры довольно посещаемых сайтов. На ней часто делают информационные сайты, в том числе разные СМИ. Качеством особо не отличается, на ней делают очень маленькие сайты, и обычно дешевле всех других вариантов, так как именно с этой CMS начинают учиться многие начинающие программисты. Drupal — это уже CMF для общего назначения, с недавнего времени поставляется со встроенных фреймворком Symfony. Довольно мощная, на ней есть известные сайты, например, официальный сайт Белого Дома. Magento — самая популярная система управления для интернет-магазинов в мире. Довольно мощная и сложная. В рунете используется редко, в основном на западе. PrestaShop — одна из самых популярных CMS для магазинов в мире. Тоже довольно мощная, используют в основном на западе. OpenCart — еще одна популярная система для интернет-магазинов, но её, наоборот, больше используют в рунете, чем на западе. В основном для маленьких и несложных магазинов. На ней часто пытаются делать большие и сложные сайты, а после определенного порога в посещаемости переписывают их на других технологиях. Многие считают, что только эта CMS может интегрироваться с 1С, что не является правдой, поскольку все перечисленные CMS из этого списка могут интегрироваться с 1С, для этого у всех CMS есть специальные модули. Со всеми перечисленными CMS я работал. В основном со стороны разработчика. Точно НЕ рекомендую — Joomla, с остальными можно работать. Для магазинов лучше выбирать специализированные, а не общие CMS. Кроме 1С-Битрикс в рунете есть еще аналогичные коммерческие CMS, они во многом схожи. У каждой из систем есть свои особенности, но все они не предназначены для больших и сложных проектов, главное это не забывать. Ранее, мы проводили исследования, на каких CMS сделаны самые посещаемые сайты рунета: Эти исследования подтверждают описанные выводы в статье. Шаблоны В последние 5 лет очень активно развивают шаблонные решения. Это еще на одну ступеньку выше, чем CMS. Если CMS — это конструктор, и его нужно настраивать, то шаблоны — это уже готовые решения под типовые случаи. Например, в каждом городе есть свои рестораны, такси, клиники и т. Для всех этих типов малого бизнеса нужно примерно одно и тоже. Поэтому, можно просто выбрать готовый тематический шаблон, заменить в нем логотип, цвета и контент. При желании такие шаблоны можно дорабатывать по усмотрению владельца. Преимущества таких решений в том, что они очень дешевые и их можно запускать моментально. Но при этом такие решения не учитывают особенностей бизнеса и конверсия будет не очень высокой. Есть специальные каталоги шаблонов: TemplateMonster , ThemeForest и др. Часто встречаются онлайн-конструкторы, в том числе тематические: Wix , PageCloud и др. Мобильные приложения В мобильных приложениях в последнее время используется два подхода: Нативная ведется на оригинальных языках программирования, в частности Swift для iOS, ранее был Objective-C и Java для Android. Кроссплатформенных технологий сейчас довольно много, они есть на базе разных языков программирования, в частности: Apache Cordova, React Native и др. Некоторые лучше, некоторые хуже. В любом случае, сложные приложения всегда пишутся на нативных технологиях. С кроссплатформой часто возникают проблемы, вплоть до того, что некоторые функции просто нереализуемы на тех или иных кроссплатформенных технологиях, сильно грузится оперативная память устройства, быстро садится батарея и т. В этих двух подходах люди тоже часто путаются, пытаясь использовать кроссплатформенные технологии на все случаи жизни. Оно и понятно, ведь кроссплатформа позволяет писать код один раз, который сразу работает и на iOS, и на Android, в то время, как на нативных технологиях это выходит минимум в два раза дороже. Однако мало кто знает о возможных дальнейших проблемах в разработке. Я бы рекомендовал очень тщательно выбирать технологии, и кроссплатформу брать только для простых приложений, иначе придется переписывать. Впрочем, кроссплатформенные технологии постепенно развиваются и становятся все лучше, а приложения, написанные на них, все сложнее. Стек технологий в больших проектах Выше я описал разные языки и фреймворки, которые используются в больших проектах, однако, если присмотреться к действительно большим проектам, там можно найти целый комплекс языков и технологий. Почти все большие сайты используют один основной язык и несколько дополнительных. Тоже самое с базами данных: И все это органично сочетается в рамках одного проекта. Выбор технологий зависит от предлагаемой архитектуры проекта. Именно архитектор продумывает основные блоки будущего сайта. Какой язык ляжет к основу, будет ли он нативным или фреймворк, какую систему кэширования выбрать, какие базы данных, как все это будет связано и т. Для примера рассмотрим технологии Instagram данные Insight IT: Сам Instagram не самый большой и сложный сервис в мире. Стоимость специалистов Один из важнейших факторов выбора технологии является стоимость и доступность специалистов, потому что именно это — самая затратная часть в любом проекте. В рунете есть только одна пузомерка по зарплатам: Теперь переведем цифры на человеческий язык. Java хоть и не новый язык, но специалисты на нем всегда были одними их самых дорогих. PHP всегда был самым дешевым, да и специалистов на рынке очень много. В сравнение я внес еще и Scala, как один из новейших и трендовых языков, по этой причине он дороже всех. Еще дорогой JS, это связанно с его бурным ростом в последние годы и растущей популярностью Node. А если хотим самое качественное, то смотрим на Scala, который называют будущем веб-разработки, но, правда, на нем найти специалистов почти невозможно, и наработок просто нет. Еще важным параметром будет скорость разработки. Ведь важна не только зарплата программистов, но и скорость разработки. Если не учитывать уже существующие наработки, то одними из самых быстрых в разработке будут Python и Ruby, а самый медленный — Java. Кстати, по этой причине за последние 10 лет почти не вышло новых мегапроектов на Java, зато вышло много проектов на Python, о чем я расскажу ниже. Тренды Выбирая технологию, нам нужно смотреть вперед. Особенно, если речь о большом проекте. Все технологии очень быстро развиваются, выходят все новые и новые версии. Языки сильно меняются каждые лет, фреймворки — каждые года, а CMS — каждые года. Важно выбрать не просто хорошую технологию сегодня, а предугадать тренды развития так, чтобы остаться на коне и через несколько лет. Иначе, в конечном счете, придется переписывать проект, что всегда очень проблематично. Есть всевозможные исследования, которые нам могут подсказать некоторые статистические выкладки. Например, исследование TIOBE Index показывает интересную статистику: По результатам разных исследований можно выделить явных лидеров по росту — это JS версия ES6 и выше и мультипарадигмальные языки, в частности Scala. Кстати, именно Scala считается преемником языка Java и во многом на него похож. Также не плохо себя показывает Python. Антитренды держат ряд старых языков и PHP. Правда, недавно вышла 7я версия PHP, в которой исправлены многие серьезные недостатки. Так что, я думаю, мы скоро увидим новый виток развития PHP. Также многие большие проекты переписываются с Ruby на другие языки, тоже некий антитренд. Для иллюстрации посмотрим, каких специалистов не хватает в США: Именно это можно считать реальной картиной трендов, которые мы видим и у нас. На чем делались большие проекты за последние 10 лет? Python и JS очень хорошо себя показывают. Стоимость поддержки Безусловно, важный критерий выбора технологии — это стоимость поддержки, о которой мало кто задумывается в начале разработки. Обычно все мыслят категориями стоимости часа поддержки, что в корне неправильно. Нам важны несколько параметров: Стоимость часа зависит от зарплаты специалисты, с этим мы уже разобрались. А вот количество часов зависит от самой технологии и качества написания кода. Если решение коробочное, то часов на него может уходить очень много. То есть, с одной стороны, мы можем сэкономить при разработке первой версии проекта, но после погрязнуть в его постоянной доработке. Хорошо, когда решение популярное, и есть официальная документация. Но часто выбирают малоизвестные коробочные решения без какой-либо документации — в таких решениям стоимость поддержки будет во много раз выше стоимости самой коробки. То же касается некачественной разработки: В среднем за часов можно проверить почти любое решение и найти его основные минусы. Чем более качественный код, тем легче, а следовательно, и дешевле его поддерживать. Также следует смотреть на версию языка, фреимворка, CMS. Нужно всегда использовать самую последнюю стабильную версию, чтобы она не устарела до выхода проекта в продакшн. При появлении новой версии нужно сразу рассматривать возможность перевода проекта на эту версию. Потому что, если пропустить несколько версий, потом будет проблемно сделать резкое обновление. Для простых сайтов чаще всего отлично подходят коробочные решения и шаблоны. Сложные сайты делаются только на фреимворках или даже чистых языках программирования. Делать можно на очень разных языках, язык выбирается под проект. Простые мобильные приложения можно делать на кроссплатформенных технологиях, а сложные обычно делаются на родных технологиях. Ну и, выбирая платформу, всегда стоит руководствоваться объективными критериями, которые я описал в статье. Ниже я сделал опрос по предпочтительному языку программирования для большого проекта. Подразумевается уровень проектов с посещаемостью в млн. Если у вас есть опыт разработки больших проектов, хотя бы на несколько миллионов пользователей, прошу не просто проголосовать, но и обосновать свое мнение в комментариях, так как у каждого разные опыт и предпочтения. Разбавим некоторую долю субъективизма статьи мнениями других членов сообщества: В нашей школе есть несколько интересных курсов по программированию. Чтобы записаться пишите на info digitov. Чтобы получать наши новые статьи раньше других или просто не пропустить новые публикации — подписывайтесь на нас в Facebook , VK и Twitter. Предпочтительный язык для большого проекта. Программирование , технологии , PHP , Python , Java , Ruby , JS , C , Scala , WordPress , 1C-Bitrix , Magento , OpenCart , Drupal , PrestaShop. Добавить в закладки SECL Group рейтинг 45, Метки лучше разделять запятой. Хотелось бы ссылку, где об этом пишет говорит кто-то из топ менеджеров FB, а не Ваши сомнения. Во времена старта Фейсбука такого выбора, как сейчас прръосто не было, с этим, я думаю, не поспоришь. Но если смотреть крупнейшие сайты мира, то на PHP сайты далеко не самые большие. Я специально искал большие сайты на PHP, более млн. Кроме этого, сам PHP в Фейсбуке не стандартный и они не раз заявляли про проблемы с ним. С другой стороны, сейчас вышел PHP7, который очень даже ничего. Возможно, скоро ситуация изменится. А ОК на java и некоторые сотрудники компании, иногда пишут о проблемах в java. И как они их решают. Wordpress который хостинг блогов , сайт белого дома, как упоминалось в статье. Очень уж странным выглядит призыв писать большие проекты на чистом языке без фреймворков. Я не призывал Я писал, что так часто делают ; Дыры есть везде, в фреймворках тоже. Любой фреймворк — это рамки и ограничения, а любому огромному ресурсу они не нужны. Сейчас еще добавлю в статью ссылки на наших исследования по фреймворкам, которые показывают примеры больших проектов на нескольких популярных фреймах…. Довольно новый и небольшое сообщество. Не стал его рассматривать. Но со временем все может быть. Думаю, что у него должно быть большое будущее. Компилируемый, со статической типизацией и относительно простой. Автор, напишите честно — потому что у вас нет опыта работы с большими проектами, даже рядом не проходили. При этом микросервисы, которые являются нормой для больших проектов — даже не упомянуты. Видимо, летний опыт автора — это в основном хоумпеджи небольших фирмочек. А большим он называет проект больше, чем 6 человеко-месяцев. Друг мой, найди хоть одну фразу в статье, где я рекомендовал CMS для большого проекта? Ты не читал статью, просто пролистал, увидел слово CMS и сделал какие-то выводы. CMS я рекомендовал для МАЛЕНЬКИХ проектов. Если хочешь критиковать, сначала прочитай, а потом пиши комментарии и обоснование к нему. Впрочем, твой заминусованный рейтинг на Хабре отлично иллюстрируют твой профессиональный уровень. Сообщество его уже оценило. Мой заминусованный рейтинг — это то, что не любят правду-матку 2. Где тут, блин, микросервисы? Я всего лишь пару раз похвалил Windows ; 2. Видимо это единственное , в чем вы разбираетесь. Но не очень большого может включать и маленький. Тем не менее вы про CMS разжевали подробно. Тем не менее многие большие проекты на CMS: Ну и, если не CMS, то что по-Вашему? Я бы сначала хотел, чтобы предыдущий оратор ответил что, если не CMS. Какие большие на CMS? Ну так Вы же писали статью…: Это статистика сеошного плагина к браузеру, а не статистическое исследование. Магазине НЕ большие сайты, их посещают только тогда, когда хотят что-то купить, то есть — очень редко. В статья я описывал, на чем делают большие сайты. Ну так открой статистику не магазинов. Розетка из Украины — да, маленький сайт. Ну так ты ж упоминал CMS… К чему весь сыр бор? Зря Вы так судите по рейтингу, на который влияет быдло. Поддержу Go, для крупных проектов идеально подходит. Не зря Mail и Яндекс его активно внедряют. Много плюсов, а главное простой. Несмотря на мое положительное отношение к последним версиям PHP, мне кажется весьма странной его лидирующая позиция в опросе. Либо хайп вокруг PHP на самом деле далек от действительности, либо это своего рода шутка. Согласен, меня тоже удивляют результаты опроса Я будем л лидерах будет Java. Еще JS почему-то отстает, тоже странно. Буржуи активно loopback используют. Для ноды фрейворк не нужен, это надо понять, принять и научится с этим жить. JS самый молодой, по крайней мере в том виде, в котором он описан тут, для бэк энда. Пройдет несколько лет и все появится. А пока, да, есть серьезные проблемы в его использовании. Это очень важно отмечать, так как проектов размера мордокнижки очень мало и клиент с горящим взглядом, который делает очередной заказ на супер мега сложную информационную систему, которая круче авито и ОК вместе взятых, вряд ли, при Вашей жизни, достигнет посещаемости при которых php будет тормозить развитие его сайта. Это с учётом, что мы говорим о веб-проекте. Кстати, ВК при Дурове использовал pure C на сервере. Отмечу, большие и сложные проекты реально сложны именно в серверной части back end. Как вывод большой проект надо писать на С, да? Чистый язык на первом месте! Мы сделали жалких фреймворщиков. Пока что из результатов опроса можно сделать вывод, что эту статью прочитало больше всего людей, которые кроме PHP ничего другого не знают. Я имею в виду: На чистом языке сделаны все крупнейшие сайты мира с посещаемостью в сотни миллионов и миллиардов пользователей Фреимворк — это некая среда разработки для программиста с готовыми правилами и инструментами. Более того, приведенный Вам абзац автора — мягко говоря, вранье. Практически все крупнейшие сайты в том или ином виде используют фреймворки. Главно, что это написано в статье. Если у вас есть опыт разработки больших проектов, хотя бы на несколько миллионов пользователей, прошу не просто проголосовать, но и обосновать свое мнение в комментариях, так как у каждого разные опыт и предпочтения У меня нет опыта разработки проекта с такой большой посещаемостью, но всё равно хочется рассказать о своём опыте: Кажется, если у Java стоит Spring, то для C должен быть ASP. В том что большинство проголосовало за PHP нет ничего удивительного. Любой большой проект начинается с маленького. Если речь идет о вебе, то маленькие проекты дешевле всего запускать на PHP, поскольку на этом языке написаны многие CMS и существует куча неплохих фреймворков. Других фреймворков, кроме AngularJS типа нет? Не совсем, это платформа. Я об этом писал. Кроме AngularJS есть, конечно. В статье не все возможные фреймворки приведены. Во втором случае случае логики много и она сложная, но количество обрабатываемых сущностей не так велико. Эти особенности тоже влияют на выбор стека. И поэтому, например, в корпорациях бизнес-процессы автоматизируют на Java, а в соцсетях используют PHP. Будет написано ровно то, что нужно. А не куча абстракций на все случаи жизни. Facebook, Вконтакте, КиноПоиск А где же любимая бадушечка? Мне за них обидно. Точно, еще и они. Но я не знаю их посещаемость, поэтому в статью и не пришло в голову включить…. Много где встречал критику в адрес Joomla!.. А что именно в ней плохого? Ну само ядро нормально оттестировано. Но вот с модулями беда, архитектура тоже хреновая, в общем все программисты, которые с ней работали, обычно на неё плюются. Отвратительно кастомизируется и дырявое как ведро. Плагины зачастую пишут новички. С точки зрения разработчика работа с ней крайне неудобная. Но она такая потому что удовлетворяет запросы определенного рынка и делает это хорошо. Не можем кастомизировать — кривые руки Плагины зачастую пишут новички Так это плюс, что новички могут написать плагин. Значит система легка в освоении. С точки зрения разработчика работа с ней крайне неудобная По сути вы сами себе противоречите, так как новички пишут плагины. Общественное мнение и предрассудки, основанные на шаблонах с TemplateMonster, Virtuemart и прочем варезе. Разные сайты с одинаковой посещаемостью могут создавать совершенно разную нагрузку на сервер, в зависимости от задач, которые сайт решает. Где-то нужны довольно ресурсоемкие вычисления, а где-то только выдача простых страниц из кеша. И каждый раз стоит просчитывать, что тебе будет выгоднее — писать быстрый и оптимизированный под задачи код, либо вкладывать бОльшие деньги в инфраструктуру при росте нагрузки. Многие проекты на JS, которые популярны и сейчас на слуху, лучше не отрывать с целью проникнуться чистотой и логикой кода. Все открытия в том числе и новых языков идут от недостатков старых. Никто не будет искать новую технологию пока считает что старая его полностью удовлетворяет. А может они банально неосиляторы? Не все стремятся к звездам, это нормально для любого общества и рода деятельности. Технологий в наше время слишком много, чтобы их изучать без причины. Изучение чего то просто для саморазвития не является причиной, так как относится ко всем технологиям без исключения. Как минимум нужно ощущение что это вам пригодится в дальнейшей деятельности. У каждого есть ворох нерешенных вопросов чтобы тратить свое время на что то бесцельное. Осознание необходимости это причина — поиск решение и изучение чего то в целях этого поиска — следствие этой причины. Согласен с вами, что слепо следовать хипстерской моде — глупо. Но объективные причины имеются, конечно же. И все таки истинную популярность и массовый исход иным технологиям даст что-то действительно революционное. Только технология решающая большую задачу достойна внимания, а не язык в котором отличае от старого только в синтаксисе объектов и косметическом изменении синтаксиса. К мелочам php достаточно быстро привыкаешь, после чего многие из них кажутся вполне логичными и объяснимыми. А отсутствие прорывов в других языках окончательно сводит на нет желание менять шило на мыло. Классно структурировано и разложено по полочкам. Но, как я понял, Вы измеряете сложность проекта в количестве будущих пользователей. Я предлагаю добавить вторую ось — функциональная сложность. Ведь может быть проект с огромной посещаемостью и относительно простым функционалом например, сайт смешных коротких цитат и проект с малой посещаемостью, но ужасающе сложным функционалом например, внутренние корпоративные веб-системы — мы создаем узкоспециализированную срм как saas-решение. Можно выделить четыре квадранта, в каждом будут свои языковые лидеры: В целом согласен, посещаемость не единственный критерий. Я выделил 17 критериев в начале статьи, которые важно учитывать при выборе технологии. Но я полагаю, не все критерии имеют равный вес. Потому что процесс выбора можно свести к двум шагам — возможно, я ошибаюсь, но это неявно сквозит в середине Вашей статьи и я с этим согласен. В зависимости от предполагаемой популярности проекта и функционала делаем выбор в пользу CMS, фреймворка или чистого языка. Шаг 2 не слишком критический, потому что Вы сами говорили о том, что большие проекты можно встретить на самых разных языках: CMS или писать всё самим, а какая CMS и на каком конкретно языке писать — вопрос важный, но второго плана. В случае CMS мы тратим десятки тысяч рублей, при самостоятельной реализации с фреймворком — сотни тысяч, без фреймворка — ещё большие сотни тысяч: Если грубо, то да, примерно так оно и выглядит Но это теория, на практике всегда вопросов…. Поэтому в интернете всегда будет много мнений, на чем надо писать сайт. Обычно посещаемые сайты со временем обрастают функционалом. Так что это связанные вещи. А с чего бы это разработка на Java обязательно долгая? Scala похожа на Java? Да и с чего бы этому языку быть будущему веб разработки? В среднем больше, чем на других язык. Особенно, если сравнить с питоном или руби. Если не согласны, что питон быстрее джавы — обоснуйте. Но я пока не видел ни одного разработчика, который бы такое мог не то, что обосновать, но и даже сказать. А что именно, по вашему, в питоне такого, что делает разработку на нем бвстрее? О e-commerce вспомнили, но ни слова про Salesforce Commerce Cloud Demandware и Oracle Commerce, которые выбирают для очень больших проектов, а не Magento и прочее на западе. Да, еще есть Hybris, IBM Websphere и другие. В статье я не описывал решения для энтерпрайза. Я описывала только популярные CMS, типа Магенты. Коробок очень много и все их описать довольно проблематично. Всегда любопытно почитать мнение "экспертов". Так как уж совсем экзотикой разработчики не владеют. И если соглашаются на ней делать — то это уже их ответственность. Соглашаются, делают говнокод, переписывают его через год нормально. Каждый второй запрос у нас — переписать старое полурабочее решение нормально. Вы переписываете за студентами или многолетние запущенные разработки. Дата основания 22 ноября Локация Москва Россия Сайт seclgroup. Сутки Неделя Месяц Уязвимость ВКонтакте: Интересные публикации Хабрахабр Geektimes. Отзыв сертификатов не работает. Секрет дешёвых светодиодных ламп GT. Быстрое удаление пробелов из строк на процессорах ARM. Первый в мире мобильный телефон без аккумуляторов работает по образцу советского шпионского жучка х годов GT. Tesla построит в Южной Австралии крупнейшую в мире аккумуляторную систему всего за дней GT. Дайджест интересных материалов для мобильного разработчика 03 июля — 09 июля. Разделы Публикации Хабы Компании Пользователи Песочница. Информация О сайте Правила Помощь Соглашение Конфиденциальность. Услуги Реклама Тарифы Контент Семинары.
Семьяс ребенкомна руках
На каком языке лучше делать сайт?
Потение ночью причины у женщин
На каких языках программирования пишут в Яндексе
Книжка малышка руками детей
Как создаются web-сайты
Сонник миллера чай
На каком языке пишутся сложные сайты?
Людям не интересно со мной общаться
На каком языке пишутся сложные сайты?
Характеристика преступления совершенного по легкомыслию
На каких языках программирования пишут в Яндексе
Кинотеатр дея расписание
Как создаются web-сайты
Таблица виды компенсационных выплат
На каких языках программирования пишут в Яндексе
Как приготовить воздушные сырники из творога
На каком языке пишутся сложные сайты?
Пуэ правила 2017 ввод в дом