какие технологии использует сайт
HackWare.ru
Этичный хакинг и тестирование на проникновение, информационная безопасность
Как узнать на чём работает сайт
Чтобы примерно представлять, как много технологий может быть задействовано в работе одной единственной страницы веб-сайта, посмотрите на этот список.
Как работают веб-сайты
В самой основе стоят серверы, на которых установлена операционная система В этой операционной системе установлен веб-сервер, а к этому веб-серверу подключены различные расширения для работы разных скриптов (например, PHP, Python, PERL, Ruby). Также к веб-серверу подключены и другие расширения: для безопасности (HTTPS, например), для ускорения загрузки, кэширования данных и т. д.
На веб-сервере в качестве программной основы сайта может быть установлена та или иная система управления контентом (CMS), какой-то из популярных движков форума, вики, блога, галереи фотографий, онлайн магазин, и т. д.
У этой программной основы сайта могут быть свои собственные расширения: SEO плагины, редакторы текста, плагины кэширования и прочее.
Программная платформа сайта может быть написана с использованием фреймворков JavaScript, библиотек JavaScript, графический расширений JavaScript и прочего.
Уже к готовому сайту могут быть подключены разнообразные сторонние сервисы: аналитики, метрики, системы комментирования, CDN, капчи, платёжные системы, рекламные сети, криптомайнеры, шрифты, карты, видео проигрыватели.
В общем, много всего бывает, и определить сразу всё просто заглянув в исходный код не всегда возможно.
Именно для решения этой проблемы — мгновенного определения всех задействованных на сайте технологий и создана специальное расширение для веб-браузеров wappalyzer.
Wappalyzer — это расширение браузера, которое раскрывает технологии, используемые на веб-сайтах. Оно определяет системы управления контентом, платформы eCommerce, веб-серверы, фреймворки JavaScript инструменты аналитики и многое другое. Все технологии перечислены по уже приведённой ссылке.
Wappalyzer для Firefox вы можете установить по ссылке: https://addons.mozilla.org/ru/firefox/addon/wappalyzer/
После установки Wappalyzer среди иконок расширений появится новое. Просто зайдите на сайт, который вас интересует, и кликните на иконку Wappalyzer.
Пример вывода для HackWare.ru:
Пример вывода для SuIP.biz:
Обратите внимание на настройки плагина:
Вполне возможно, что вы захотите отключить некоторые из них:
webanalyze — это Wappalyzer для командной строки
Расширение для веб-браузера очень удобно для обычных пользователей, но такая реализация не позволяет проверить большое количество сайтов за короткое время (что если нужно проверить 1000 или более сайтов?), к тому же, некоторым просто привычнее работать в командной строке.
Именно для таких случаев был создан инструмент webanalyze, который является по своей сути является программой Wappalyzer, портируемой на язык программирования Go.
Как установить webanalyze
Начните с установки компилятора и инструментов Go по данной статье (выберите ручную установку).
Затем выполните команды:
Как пользоваться webanalyze
Чтобы собрать информацию о технологиях, применяемых сайтом https://hackware.ru запустите команду:
Чтобы узнать информацию о технологиях сайта https://suip.biz, а также информацию о технологиях с 5 ссылок, найденных на указанной странице (-crawl 5):
Если вам нужно проверить много сайтов, то сохраните их в файл в формате: один сайт на одну строку. При запуске укажите программе этот файл с помощью опции -hosts:
По умолчанию результаты выводятся в стандартный вывод в удобном для восприятия человеком формате, но с помощью опции -output можно указать формат csv (данные разделены запятыми, такой файл можно открыть программой для работы с таблицами), либо можно указать json для вывода в формате JSON. Например:
Но данная команда также выведет результат в стандартный вывод, чтобы перенаправить вывод в файл используйте символ >, например:
Другие опции программы webanalyze вы найдёте здесь: https://kali.tools/?p=4804
Решение проблем
Ошибка «error initializing:open apps.json: no such file or directory»
При запуске вы можете получить сообщение об ошибке:
Для своей работы программа webanalyze использует файл базы данных apps.json от программы Wappalyzer. Показываемая ошибка означает, что данные файл отсутствует. Для его скачивания выполните команду:
webanalyze выводит меньше данных, чем wappalyzer
В своей работе wappalyzer для определения технологий выполняет JavaScript код и запросы, благодаря которым собираются дополнительные сведения. Поскольку в webanalyze на данный момент это не реализовано, то он выводит меньше информации — только ту, которая не требует выполнения кода JavaScript на сайте.
Как узнать CMS сайта?
Задавайте, а мы ответим на него в блоге.
Чтобы узнать движок другого сайта, не нужны специальные навыки, это можно сделать в окне браузера. Разбираем основные способы, как определить CMS.
Какие движки можно определить
Существует четыре вида CMS:
Коробочные движки и CMS от конструкторов сайтов можно узнать вручную или используя автоматические сервисы. Код и архитектура у них повторяются от проекта к проекту. Со студийными и самописными сложнее — у них нет открытого известного кода, из-за чего узнать их не получится.
Учитывайте, что на разных разделах сайта могут стоять разные CMS. Например, amplifir.com работает на самописной CMS, а блог (amplifir.com/blog) — уже на WordPress. Поэтому проверяйте конкретную страницу, движок которой вы хотите узнать.
Ниже — основные способы, как определиь CMS сайта.
По исходному коду страницы
В HTML-коде сайта сохраняется информация о базе и библиотеках используемой CMS. Чтобы определить платформу через код, открываем в браузере правой кнопкой мыши пункт меню «Просмотр кода страницы». Система управления выдаёт себя внутри тега head, где указаны важные файлы админки.
По файлу robots.txt
Служебный файл robots.txt используется веб-мастерами для индексации сайта в поисковых системах. Он находится в открытом доступе и зачастую содержит информацию о CMS. Чтобы перейти к файлу, откройте в адресной строке браузера ссылку вида сайт/ robots.txt.
По информации в подвале сайта
В подвале может быть указана система управления контентом. Второй способ узнать систему — обратиться к разработчикам, если они оставили ссылку на себя в футере. Так, например, можно выяснить, использует ли студия коробочную или самописную CMS.
Через автоматические сервисы
Автоматически определить CMS можно с помощью онлайн-сервисов. Эти способы подходят для сайтов-конструкторов и коробочных систем. Большинство популярных сервисов угадывают систему управления правильно.
BuiltWith. Онлайн-сервис BuiltWith без регистрации анализирует любой домен и показывает его CMS. Нужно только ввести адрес сайта, а BuiltWith быстро выдаст данные о его движке.
Сервис даёт подробный анализ, в том числе определяет систему управления контентом
WhatCMS. WhatCMS — простейший онлайн-сервис для определения системы управления контентом. В строке поиска вводим название сайта и, вуаля, получаем результат анализа без дополнительных деталей.
iTrack. Сервис iTrack определяет более 80 известных движков. Для регулярной проверки можно установить расширение для браузера.
Через расширения браузера
Если анализировать CMS нужно часто, используйте расширения для браузера. Они выдают заключение о CMS, и иногда показывают другую полезную информацию: например, об установленных приложениях и плагинах на сайте.
Wappalyzer (Chrome, Safari, Firefox). Инструмент автоматически определяет технологии, с помощью которых создан сайт. Помимо CMS Wappalyzer находит системы аналитики, библиотеки, фреймворки и т.д.
iTrack (Chrome). Уже знакомый сервис доступен через расширение браузера. Можно онлайн узнать CMS текущего сайта или вставить ссылку в окно интерфейса.
RDS Bar (Chrome, Яндекс.Браузер, Opera, Firefox). Инструмент для веб-мастеров и seo-специалистов. Новички могут запутаться в многообразии результатов анализа.
Если определить CMS не получилось
Если ни один из инструментов не смог узнать CMS, скорее всего сайт сделан на самописном или студийном движке. Чтобы убедиться в этом, стоит уточнить платформу у разработчика, указанного в подвале. Или заглянуть в раздел «Контакты» и спросить у владельца напрямую.
Всего проверено сайтов: 32395 (уникальных: 24264). История проверок:
https://gambit-v.ru
Дата проверки: 03.11.21 22:36:09
https://r-rp.ru
Дата проверки: 03.11.21 22:35:16
https://www.apteka.ua
Еженедельник АПТЕКА — медикаменты, медпрепараты и цены на них. Новости медицины и фармации
Дата проверки: 03.11.21 21:10:07
https://edu.spbftu.ru
Система дистанционной поддержки образовательного процесса СПбГЛТУ: Вход на сайт
Дата проверки: 03.11.21 21:05:43
https://www.rgo.ru
Дата проверки: 03.11.21 18:03:32
https://edu.iqanat.kz
https://edu.iqanat.kz
Дата проверки: 03.11.21 17:45:12
https://arpanetus.com
https://arpanetus.com
Дата проверки: 03.11.21 16:39:15
https://www.userback.io
https://www.userback.io
Дата проверки: 03.11.21 15:26:52
https://profi.ru
Дата проверки: 03.11.21 14:15:30
https://market.yandex.ru
Дата проверки: 03.11.21 13:42:03
http://monetochka.ru
МонеТочка — супермаркет платежных систем! | monetochka.ru
Дата проверки: 03.11.21 13:25:44
https://migalauto.com
Грузоперевозки, доставка грузов в Европу, Россию, СНГ. Транспортная компания MigalAuto. — Международные грузоперевозки из Молдовы в Европу и Россию. Грузовой автосервисMigalauto
Дата проверки: 03.11.21 13:02:06
http://www.migalauto.com
Грузоперевозки, доставка грузов в Европу, Россию, СНГ. Транспортная компания MigalAuto. — Международные грузоперевозки из Молдовы в Европу и Россию. Грузовой автосервисMigalauto
Дата проверки: 03.11.21 13:01:52
https://my-shop.ru
Дата проверки: 03.11.21 12:50:50
Дата проверки: 03.11.21 12:46:08
https://nipyatnyshka.ru
НиПятнышка | Химчистка и Аквачистка в Ижевске, SPA для вашей одежды
Дата проверки: 03.11.21 11:52:18
https://gvozditut.ru
Всё для дома и ремонта от компании «У Михалыча»
Дата проверки: 03.11.21 08:22:03
https://koryosaram.ru
https://koryosaram.ru
Дата проверки: 03.11.21 06:47:26
Выбор технологий для большого и не очень большого веб-проекта
За годы работы я часто слышу вопросы о выборе технологий для того или иного веб-проекта. Кто-то спрашивает у нас, как у разработчиков, как правильно, а кто-то приходит и просит сделать на какой-то конкретной технологии. Проблема в том, что большинство выбирают технологии по субъективным причинам, и пока я не слышал достойного и понятного рассуждения, которое позволило бы выбрать технологию объективно, основываясь на фактах, а не желаниях. Даже немногие итишники могут правильно выбрать технологию, ведь для этого нужно: понимать специфику проекта, иметь многолетний опыт разработки на нескольких языках, знать, как устроены подобные проекты и т.д.
Но прежде, чем что-то выбирать, давайте посмотрим, какие технологии бывают, чем они отличаются и в каких случаях какую технологию выбрать.
Как чаще всего выбирают технологию сейчас:
В чем тут проблема:
Важные критерии при выборе технологий:
Какие бывают проекты
К технологиям мы еще вернемся, а пока давайте разберемся, какие бывают проекты. Часто тип проекта говорит сам за себя, и можно сразу сказать, что подойдет: либо уже готовое решение, либо хотя бы в какую сторону нужно двигаться.
По сложности проекты делятся:
Языки программирования
В технологиях я бы выделил 3 уровня абстракции:
Сегодня есть огромное количество разных языков программирования, на которых делают сайты. И, более того, на всех популярных языках есть примеры огромных сайтов. Если 10 лет назад, говоря о технологиях больших сайтов, все говорили преимущественно о Java, то сегодня это может быть почти любой язык, и утверждать, что сайты делаются на каком-то конкретном языке, — стереотип. Это связанно с развитием самих языков, за последнее десятилетие многие сильно продвинулись в развитии и получили широкие возможности. Конечно, каждый язык чем-то отличается, и выбирая мы опять же должны руководствоваться объективными критериями с оглядкой на задачи проекта.
На чистом языке, без использования фреимворков и коробочных решений, пишутся огромные проекты с повышенными требованиями по гибкости, нагрузкам и безопасности. Для таких огромных проектов часто бюджет не играет такого значения, как эффективность. Чем больше проект, тем больше будет требований по гибкости и нагрузкам, а значит, проще писать все с нуля, выделяя на это лучших специалистов, чем если брать какие-то готовые решения, которые непонятно кем писались и непонятно какие проблемы в них скрыты. К примеру, когда речь о небольшом проекте с посещаемостью в 10 тыс. человек в день, то нам будет дешевле сделать его на CMS, которая будет потреблять в 3 раза больше ресурсов сервера, поставить дополнительный сервер за 50$ / мес., и он будет работать. Когда же мы говорим о сайте с посещаемостью в 100 млн. пользователей в день, стоимость добавления серверов у нас будет просто космической, поэтому нам проще и дешевле вложить деньги в разработку решения на чистом языке, которое будет оптимальным именно для конкретного проекта.
Чем больше проект, тем больше стек технологий, который в нем используется. В огромных порталах может использоваться сразу несколько языков программирования. Опять же, мы приходим к объективным критериям выбора технологий. Часто один язык может хорошо решать одну задачу, а другой — другую. Такие проекты могут быть настолько огромными, что их части могут работать на разных серверах, с разными доменами (поддоменами) и разными технологиями. Не следует бояться винегрета технологий в большом проекте, хотя и допускать его нужно только, когда это действительно необходимо, а также помнить, что далеко не все технологии совместимы. Самый яркий пример использования разных технологий — Google. Он на столько большой, чтобы разные его части написаны на C/C++, Java, Python, JS и других языках. Более того, Google активно создает новые технологии, как, например, популярный нынче AngularJS.
Попробую дать краткую характеристику каждому из популярных языков:
Примеры больших сайтов:
Фреймворки и платформы
Это некая среда разработки для программистов, где есть готовая инфраструктура и ряд готовых функций со стандартными решениями типичных задач. Такой себе полуфабрикат, из которого можно сделать конфетку. На каждом языке есть много разных фреймворков. Есть как общие, которые создавались для разработки любых решений, так и специализированные, под узкие задачи. Например, Sylius — специализированный E-commerce фреймворк на основе Symfony. Также есть те, на которых делаются большие и сложные решения, а другие для этого не предназначены. Ниже я опишу популярные фреймворки для каждого из языков, на которых можно писать большие и сложные решения.
На фреймворках разрабатываются довольно большие и сложные сайты с уникальным функционалом. Это значительно быстрее и дешевле, чем на чистом языке, но при этом такое решение позволяет разрабатывать действительно сложные вещи и оптимизировать все это под нагрузки. Кроме того, это почти всегда более безопасно, чем любая коробочная CMS.
Популярные фреймворки и платформы:
.NET и Node.js — это целые самостоятельные платформы, которые базируются на определенных языках, но имеют очень широкие возможности.
Недавно мы проводили исследования по тем фреймворкам, на которых специализируемся. Смотрели в каких больших проектах они используются. В частности огромные сайты на Python / Django и огромные сайты на PHP / Symfony. Также мы писали, как мы разрабатывали социальную сеть на Symfony вместе с API (статья больше про API, самое широкое описание в рунете по этой теме). Такие же огромные сайты есть на каждом из перечисленных фреймворках.
CMS и CMF
Это готовое программное обеспечение, которое нужно только настроить, реже — дописать / переписать какую-то из частей. Таких решений очень много на любом языке, но исторически так сложилось, что в основном все популярные CMS сделаны на PHP. Тут дело в развитии языков, раньше простые сайты, для которых и создавались CMS, писались на PHP. Я еще застал те времена, когда CMS почти не было, были скрипты — отдельные готовые части разных сайтов. Позже эти скрипты собирали в коробочный продукт, который был призван решить потребности 90% простых сайтов. Так и получилось, что основные CMS сделаны на PHP. Сегодня CMS на других языках развиваются слабо, потому что уже есть сильные конкуренты на PHP, а для простого сайта язык не играет большой роли, поэтому все смотрят на возможности этих готовых продуктов.
CMF, если говорить простым языком, — это что-то среднее между CMS и фреймворком по возможностям. Обычно CMF используют для самых сложных сайтов из этой категории. Этот подход позволяет избавиться от лишних частей CMS, которые не нужны конкретному проекту.
CMS бывают разные по назначению: общие, для интернет-магазинов, для блогов и т.д. Разные по условиям использования: платные и бесплатные. Для каждой популярной CMS есть много разных платных и бесплатных модулей, которые легко подключать и использовать.
Маленькие сайты, которые в основном нужны для малого бизнеса, почти всегда используют CMS. Это позволяет очень сильно экономить время на разработку. Кроме того, для настройки таких решений не нужны дорогие программисты, обычно это могут делать новички в программировании, по крайней мере саму настройку, если уже нужно писать код, тут сложнее.
Именно в работе с CMS возникает больше всего непонимание среди конечных заказчиков таких решений. Любая CMS — это тонны готового программного кода, на все случае жизни. В коробочной поставке идут десятки и сотни модулей. Все это очень сильно ограничивает специалистов. Такие решения сильно «тормозят», они абсолютно не гибкие, их очень легко взломать, особенно бесплатные CMS. Еще часто взламывают CMS через модули сторонних разработчиков, в которых есть критические уязвимости, потому что мы никогда не знаем, какого уровня программист писал тот или иной модуль. То есть любая CMS НЕ рассчитана для большого и сложного сайта. Она не может выдержать большие нагрузки. Это решение небезопасно, чтобы не говорили разработчики конкретной CMS.
Я видел решения почти на всех популярных CMS, с многими за более, чем 10 лет работы, пришлось поработать лично. Часть из них популярна в рунете, а часть знают в основном на западе. На используемые в них языки CMS разбивать нет смысла, по причинам, описанным выше. Лучше сказать несколько слов про каждую популярную CMS:
Ранее, мы проводили исследования, на каких CMS сделаны самые посещаемые сайты рунета: часть 1 и часть 2, крупнейшие интернет-магазины и крупнейшие сайты банков. Эти исследования подтверждают описанные выводы в статье.
Шаблоны
В последние 5 лет очень активно развивают шаблонные решения. Это еще на одну ступеньку выше, чем CMS. Если CMS — это конструктор, и его нужно настраивать, то шаблоны — это уже готовые решения под типовые случаи. Например, в каждом городе есть свои рестораны, такси, клиники и т.д. Для всех этих типов малого бизнеса нужно примерно одно и тоже. Поэтому, можно просто выбрать готовый тематический шаблон, заменить в нем логотип, цвета и контент. При желании такие шаблоны можно дорабатывать по усмотрению владельца.
Преимущества таких решений в том, что они очень дешевые и их можно запускать моментально. Но при этом такие решения не учитывают особенностей бизнеса и конверсия будет не очень высокой.
Есть специальные каталоги шаблонов: TemplateMonster, ThemeForest и др. Часто встречаются онлайн-конструкторы, в том числе тематические: Wix, PageCloud и др.
Мобильные приложения
В мобильных приложениях в последнее время используется два подхода: нативная разработка и кроссплатформенные технологии. Нативная ведется на оригинальных языках программирования, в частности Swift (для iOS, ранее был Objective-C) и Java (для Android). Кроссплатформенных технологий сейчас довольно много, они есть на базе разных языков программирования, в частности: Apache Cordova, React Native и др. Некоторые лучше, некоторые хуже. В любом случае, сложные приложения всегда пишутся на нативных технологиях. С кроссплатформой часто возникают проблемы, вплоть до того, что некоторые функции просто нереализуемы на тех или иных кроссплатформенных технологиях, сильно грузится оперативная память устройства, быстро садится батарея и т.д.
В этих двух подходах люди тоже часто путаются, пытаясь использовать кроссплатформенные технологии на все случаи жизни. Оно и понятно, ведь кроссплатформа позволяет писать код один раз, который сразу работает и на iOS, и на Android, в то время, как на нативных технологиях это выходит минимум в два раза дороже. Однако мало кто знает о возможных дальнейших проблемах в разработке. Я бы рекомендовал очень тщательно выбирать технологии, и кроссплатформу брать только для простых приложений, иначе придется переписывать. Впрочем, кроссплатформенные технологии постепенно развиваются и становятся все лучше, а приложения, написанные на них, все сложнее.
Стек технологий в больших проектах
Выше я описал разные языки и фреймворки, которые используются в больших проектах, однако, если присмотреться к действительно большим проектам, там можно найти целый комплекс языков и технологий. Почти все большие сайты используют один основной язык и несколько дополнительных. Тоже самое с базами данных: для одних задач могут использоваться реляционные, а для других нереляционные базы. И все это органично сочетается в рамках одного проекта.
Выбор технологий зависит от предлагаемой архитектуры проекта. Именно архитектор продумывает основные блоки будущего сайта. Какой язык ляжет к основу, будет ли он нативным или фреймворк, какую систему кэширования выбрать, какие базы данных, как все это будет связано и т.д.
Для примера рассмотрим технологии Instagram (данные Insight IT):
Стоимость специалистов
Один из важнейших факторов выбора технологии является стоимость и доступность специалистов, потому что именно это — самая затратная часть в любом проекте. В рунете есть только одна пузомерка по зарплатам: https://jobs.dou.ua/salaries/ — я отфильтровал по Киеву, уровень Senior, опыт 3-5 лет. Сравним средние значения.
Теперь переведем цифры на человеческий язык. Java хоть и не новый язык, но специалисты на нем всегда были одними их самых дорогих. PHP всегда был самым дешевым, да и специалистов на рынке очень много. В сравнение я внес еще и Scala, как один из новейших и трендовых языков, по этой причине он дороже всех. Еще дорогой JS, это связанно с его бурным ростом в последние годы и растущей популярностью Node.js, а также AngularJS.
Таким образом: если мы хотим экономить, то лучше смотреть на PHP — специалисты дешевые, а комьюнити большое. А если хотим самое качественное, то смотрим на Scala, который называют будущем веб-разработки, но, правда, на нем найти специалистов почти невозможно, и наработок просто нет.
Еще важным параметром будет скорость разработки. Ведь важна не только зарплата программистов, но и скорость разработки. Если не учитывать уже существующие наработки, то одними из самых быстрых в разработке будут Python и Ruby, а самый медленный — Java. Кстати, по этой причине за последние 10 лет почти не вышло новых мегапроектов на Java, зато вышло много проектов на Python, о чем я расскажу ниже.
Тренды
Выбирая технологию, нам нужно смотреть вперед. Особенно, если речь о большом проекте. Все технологии очень быстро развиваются, выходят все новые и новые версии. Языки сильно меняются каждые 5-7 лет, фреймворки — каждые 2-3 года, а CMS — каждые 1-2 года. Важно выбрать не просто хорошую технологию сегодня, а предугадать тренды развития так, чтобы остаться на коне и через несколько лет. Иначе, в конечном счете, придется переписывать проект, что всегда очень проблематично.
Есть всевозможные исследования, которые нам могут подсказать некоторые статистические выкладки. Например, исследование TIOBE Index показывает интересную статистику:
По результатам разных исследований можно выделить явных лидеров по росту — это JS (версия ES6 и выше) и мультипарадигмальные языки, в частности Scala. Кстати, именно Scala считается преемником языка Java и во многом на него похож. Также не плохо себя показывает Python.
Антитренды держат ряд старых языков и PHP. Правда, недавно вышла 7я версия PHP, в которой исправлены многие серьезные недостатки. Так что, я думаю, мы скоро увидим новый виток развития PHP. Также многие большие проекты переписываются с Ruby на другие языки, тоже некий антитренд.
Для иллюстрации посмотрим, каких специалистов не хватает в США:
Именно это можно считать реальной картиной трендов, которые мы видим и у нас.
На чем делались большие проекты за последние 10 лет?
Стоимость поддержки
Безусловно, важный критерий выбора технологии — это стоимость поддержки, о которой мало кто задумывается в начале разработки. Обычно все мыслят категориями стоимости часа поддержки, что в корне неправильно. Нам важны несколько параметров: стоимость часа, количество часов, официальная поддержка технологии, доступность специалистов, правильный подход к разработке и некоторые другие.
Стоимость часа зависит от зарплаты специалисты, с этим мы уже разобрались. А вот количество часов зависит от самой технологии и качества написания кода. Если решение коробочное, то часов на него может уходить очень много. То есть, с одной стороны, мы можем сэкономить при разработке первой версии проекта, но после погрязнуть в его постоянной доработке. Хорошо, когда решение популярное, и есть официальная документация. Но часто выбирают малоизвестные коробочные решения без какой-либо документации — в таких решениям стоимость поддержки будет во много раз выше стоимости самой коробки. То же касается некачественной разработки: у нас почему-то полностью отсутствует культура проведения технических аудитов готовых решений или их частей. В среднем за 20-40 часов можно проверить почти любое решение и найти его основные минусы. Чем более качественный код, тем легче, а следовательно, и дешевле его поддерживать.
Также следует смотреть на версию языка, фреимворка, CMS. Нужно всегда использовать самую последнюю стабильную версию, чтобы она не устарела до выхода проекта в продакшн. При появлении новой версии нужно сразу рассматривать возможность перевода проекта на эту версию. Потому что, если пропустить несколько версий, потом будет проблемно сделать резкое обновление.
Так что выбрать?
Подведем итог. Для простых сайтов чаще всего отлично подходят коробочные решения и шаблоны. Сложные сайты делаются только на фреимворках или даже чистых языках программирования. Делать можно на очень разных языках, язык выбирается под проект. Простые мобильные приложения можно делать на кроссплатформенных технологиях, а сложные обычно делаются на родных технологиях. Ну и, выбирая платформу, всегда стоит руководствоваться объективными критериями, которые я описал в статье.
Ниже я сделал опрос по предпочтительному языку программирования для большого проекта. Подразумевается уровень проектов с посещаемостью в 100 млн. пользователей и больше. Если у вас есть опыт разработки больших проектов, хотя бы на несколько миллионов пользователей, прошу не просто проголосовать, но и обосновать свое мнение в комментариях, так как у каждого разные опыт и предпочтения. Разбавим некоторую долю субъективизма статьи мнениями других членов сообщества 🙂
P.S.. В нашей школе есть несколько интересных курсов по программированию. Чтобы записаться пишите на info@digitov.com
P.P.S. Чтобы получать наши новые статьи раньше других или просто не пропустить новые публикации — подписывайтесь на нас в Facebook, VK и Twitter.
Автор:
Никита Семенов, CEO, Компания «SECL Group»