Зачем вам такая 1 колонка, если все остальное поедет напрочь?
Бутстрап, если подключать его с cdn, скорее всего уже закеширован пользователем, по этому подключать его не так страшно. Во-вторых, бутстрап из коробки дает нормально оформленные другие стандартные элементы, поля ввода, кнопки, ссылки, тот же ресет стандартных параметров, а то часто встречаешь, что везде хорошо, а в одном браузере из-за 1 пиксела все едет.
Куча готовых элементов. Для текущих реалий интернета, бутстрап не является чем то изряд вон выходящим.
Я чаще встечаю не сжатые png'шки размером в ~500к, я молчу конечно про автособщик типо гулпа, но хотя бы воспользоваться ресурсом tinypng уж могла бы перед деплоем большая часть лендингостроителей, да и сайтов в том числе )))))
Я в куре что это, я говорю что это не оправданно, по причине описанным выше.
Любая схема кеширования должна проектироваться с подключением головы, а не просто включатся по кнопке, потому что так "модно".
Для примера по вашей ссылки из вики:
То есть на виртуальных серверах где оперативки 1-2 гига, мемкэш во вред чем в пользу, так как кэш будет сбрасываться часто.
для этой системы кеширования нужно более чем 1 сервер иначе ваш кэш это мнимая пустышка.
Ну и конечно же там множество подводных камней. оно не оправдано никак на небольших проектах.
Hadoop - это даже далеко не база данных. Почитайте внимательно о технологии прежде чем предлагать :) Да и сам hadoop уже так сказать "устарел" в своём классе.
Никто не держит статику в оперативки сервера ( если это конечно не критично ), я вам больше скажу, никто не держит результат выполнения тяжелых запросов в оперативке сервера. Держать кэш в оперативке неоправданная роскошь, там можно хранить наример сессии пользователей, но никак не результат выборок с базы, так как разогреть такой кеш после перезапуска машины будет проблематично, да и не получится разогреть такой кеш на специальной машине с переносом на продакшен :))
Для большинства запросов к базе хватает правильно настроенных индексов и третьей нормальной формы реляционной БД. И на крайняк сохранения результата на SSD :))
Кэш для статики обычно хранится на стороне клиента (в браузере), просто вместе с картинкой надо послать заголовок, сколько она будет актуальна. Зачем вам статику хранить в оперативке сервера? Как часто у вас меняется файл библиотеки jQuery версии 1.11 например?
Для динамики, да, можно использовать хранение в оперативке и то это не всегда актуально.
Вам нужен хороший верстальщик на аутсорсе и тогда вы сможете
Почему нелепо?
Можно пойти дальше и сделать дыру в безопасности (если у вас веб сервер Apache), но зато этичную, надо всего то в .htaccess вставить строчку
AddType application/x-httpd-php .html
И вы сможете вставлять код php в файл с расширением .html, но то что это дыра я предупредил
Смотря, что вы хотите от этого получить.
Ну очень уж прельщает retailCRM для интернет магазина, правда дорого. Мой склад для учета еще ничего так, но больно печально там всё. А так, конечно есть и специализированные. Вам надо не от движка заходить, а от бизнес процессов.
Чтобы небыло лишних запросов к серверу
Тогда мне интересно, что по вашему самописы? Легаси код из учебников, написанный школьником что ли?
Я никак не принижаю вклад популярных движков в сообщество, я лишь говорю о том, что
А вы пошли непонятно в какую сторону.
