Тимофей

Изучай

Непонятно, если вы намастрячились использовать Laravel (что, скорее всего, лучший выбор в мире PHP), зачем вы что-то ещё выбираете?

> А как происходит дело в NodeJS ?
Прими за исходную: работаешь со строкой, которую записываешь в body ответа. Не больше и не меньше. Да, можно сделать эту строку в виде "< html >< body >" + myContentVarHere + "< /body >< /html >", но зачем? Есть популярные шаблонизаторы: Jade, EJS, JQtemplates используй их.

@Fesor
> В целом PHP плохой шаблонизатор.
Не согласен. PHP - stateless язык, который вполне себе ок шаблонизатор. Если верить википедии: PHP: Hypertext Preprocessor. Да, есть twig, да есть smarty, но эти шаблонизаторы только пародируют PHP. Результат их работы - это тот же PHP код, только кэшированный.

> Пока у людей пишущих на php появляются такие мысли, над php будут продолжать смеяться.
Над нами php-dev смеются потому что:
1. Динамическая типизация. 5 + "5abc" + "abc5" по хорошему должно давать исключение в стиле "парень меняй драг диллера, это какое-то УГ!".
2. Не консистентное API. С тем же if (!strpos(...)) наверняка хлебнули горя.
3. Наличие миллиона стандартов. Да, есть PSR, расскажите о нем автору, знающему кохану.
4. Что на счет scalar type hinting? Всего 20 лет прошло как в 7-ке это таки решили внедрить, и то с ограничениями на вывод.
5. Что на счет демонов? Да, я знаю, можно, да я знаю как, но №;%: есть языки для этого приспособленные и php в их число не входит, это stateless язык!

Я отошел от темы шаблонизаторов.
Чем принципиально {{someVar}} лучше <?= $someVar; ?>, учитывая, что шаблон в любом случае приведется к нейтивному коду + за кэшируется?

Я использовал Sails. И я перешел от него обратно к Express (и же Koa сюда же). Почему? Он слишком много работы берет на себя.

Что мне делать, если я хочу использовать LiveScript \ JS ES6 (Babel) в качестве языка?
Что мне делать, если я не использую не Grunt, а Webpack?

В общем, он слишком монолитный. И слишком медленно развивается... По началу было прикольно и весело, но потом разонравился.

Что за шутки? Откуда цифра в 300 RPS?
К РНР там гири привязывали, что ли?
Какова доля РНР? Где тесты, показывающие, что бутылочное горлышко - РНР фреймворк, а не, скажем, база?

Мне кажется наиболее рациональное решение - выбрать все данные из Вашей таблицы за нужный период, и за 1 проход цикла в любом ЯП составить требуемую табличку.

Вёрстка, это всегда проблема. Потому что html и css это одна большая проблема сама по себе.
Всё что вы перечислили это мейнстримовый абстрактный кич. Я бы вообще не стал рассматривать это в отдельности, как что-то реально существующее. Всё что вам нудно это усвоить основные базовые понятия: строчный и блочный элемент, поток, позиционирование, z-index. А дальше уже делаете дизайн какой захотите с паралаксами, сетками и тд.
По поводу ресурсов где рассматриваются проблемы вёрстки. Скажите, зачем вам чужие проблемы? Их на самом деле столько, что пером не описать.
Просто верстайте. И когда натолкнётесь на проблему, либо изначально задумаете какую-нибудь конструкцию, которую не знаете как сверстать, то там уже можно будет и погуглить, почитать или задать конкретный вопрос.
Всё дело в том, что сама по себе технология html и css, да и js, не идеальна. Причём далеко не идеальна. Скажем если мы возьмём идеальность за 100%, то нынешняя ситуация будет где-то процентов на 15-20, ну максимум 30.

Наиболее подходящий вариант нельзя посоветовать не зная ваших объемов данных и того как вы планируете это использовать.

Если время поиска не критично, типов данных мало, нужно простое и переносимое решение, то я бы посоветовал вариант 1 с сериализацией различных типов в строку.

Вариант с постгревыми json/jsonb добавляет гибкости/производительности, но в json простые типы это число, строка и булев. Даты и прочих типов там нету. Для jsonb поддерживаются индексы. Это решение означает жесткую привязку к PG.

Есть еще вариант похожий на 1, но с заданием разнотипных колонок и хранением в каждом свойстве его типа. Запросы будут выглядет как-то так

SELECT * FROM profile_field_values
WHERE 
  (property_field="дата рождения"
  and value_type="date" and value_date > ?)
and
  (property_field="размер ноги"
  and value_type="integer" and value_integer < ?)

По скорости вы выиграете, но получите сложности с реализацией и интеграцией всего этого в рельсы.

Еще есть вариация на тему решения N3 - внешний сервис для поиска: Sphinx, Solr, etc...

1-ый вариант = Продаешь 10 битриксов в месяц
2ой вариант = 0,5 сайтов на фреймворке в месяц

https://github.com/janl/mustache.js

Без JS никак. Либо повесить hover на wrap:

#wrap:hover + .b {
  display: block;
}

Во-первых, я полностью согласна с @andead. Спасибо за отличный ответ, man!

Позволю себе небольшие дополнения как битрикс-разработчик.

1) Почему считается, что друпал сложно темизировать?

Наговнокодить прямо в шаблоне большого ума не надо.

Правильно темизировать и битрикс нелегко. Другой разговор, что оставить в шаблоне друпала $_SESSION в 100 раз хуже, чем оставить тоже самое в шаблоне битрикса. Процесс темизации и той, и другой CMS должен контролировать понимающий систему программист.

2) Действительно ли друпал очень медленный? Медленней ли он того же битрикса?

В битриксе каждый «блок» (часть страницы) можно независимо закешировать на основе идентификаторов групп пользователя, значений фильтра каталога и чего угодно. Обёртка $this->StartResultCache() как отче наш в любом коде и в стандартных компонентах из коробки. В итоге страница быстро собирается из кешей для людей с сессией, авторизацией и т.д. В друпале нужно стремиться к этому же, но для этого приходится писать свои кеш-плагины к Panels, шаманить с Expire и даже ESI и понимать всякие тонкости работы друпал-кеширования (drupalace.ru/tags/cache).
В битриксе всякие панели производительности и мониторы качества из коробки. В друпале это "энтерпрайз"-услуга :)

3) Этот вопрос к тем, кто имел дело с интернет-магазинами на друпале: стоит ли вообще делать на нем интернет-магазины? Мое мнение таково, что удобнее на битриксе

Для России того же мнения придерживаюсь. Видимо, потому что умею запускать магазины на битриксе и не умею на друпале.

5) Есть люди, которые сравнивают инфоблоки битрикса с нодами друпала. Как по мне - ноды в кипе с таксономией в пух и прах разбивают инфоблоки. У кого другое мнение и почему?

Инфоблоки гораздо мощнее просто нод из коробки. Опыт работы с тем и другим >2 лет. Сравнивать можно сущности в друпале и инфоблоки в битриксе. Вот здесь уже друпал (вместе с Entity API, конечно) смотрится гораздо серьёзней и гибче. Битрикс выглядит глупо, когда нужно что-то странное, друпал же позволяет воротить что угодно.

Если вы имели дело с формами на сайте, подскажите, как лучше их реализовать, чтобы получился некий аналог форм в битриксе - с почтовыми шаблонами, настройкой вопросов и т.д. и т.п. Здесь у меня возникали проблемы именно с темизацией, то есть хотелось бы просто вывести, например, блок с формой, на которую есть готовая верстка и стандартная разметка друпала по этой причине не устраивает.

Webform/Entityforms гораздо проще битрикса в плане собственно форм, просто надо привыкнуть. А вот email-подсистема в друпале послабее. В друпале если что-то делают, то только со вселенским размахом :) Как пример, Message Stack :)

Действительно ли вам показался друпал сложным в освоении (как программистам, разумеется) в сравнении с другими системами?

Спустя 2 года я нахожу что-то новое и очень крутое в друпале или благодаря друпалу. Не могу ответить на этот вопрос, т.к. продолжаю учиться :)

Как вы темизировали хлебные крошки и постраничную навигацию?

Пользуясь случаем, пропиарю модуль Path Breadcrumbs, ко-мейнтейнером которого гордо являюсь. В нём переопределяется theme_breadcrumb() для добавления поддержки Rich Snippets: drupalcode.org/project/path_breadcrumbs.git/blob/c...
С помощью того же hook_theme_registry_alter() вы можете заставить крошки темизироваться через файл, а не функцию.

Друпал люблю больше из-за качества кода и сообщества.

1) Почему считается, что друпал сложно темизировать?

Друпал сложно правильно темизировать. Достаточно тяжело понять всю систему из theme функций/файлов, preprocess/process функций, theme sugestions, render массивов, различных pre_build/after_build/post_build калбаков, theme врапперов, кэширования и т.п. Наговнокодить прямо в шаблоне большого ума не надо.

2) Действительно ли друпал очень медленный?

Друпал, как и любая другая CMS, медленнее узкоспециализированных систем в виду своей избыточности. Голый друпал 7 на средней машине генерит странички за ~100 ms. Решайте сами, это очень медленно или нет.

3) Этот вопрос к тем, кто имел дело с интернет-магазинами на друпале: стоит ли вообще делать на нем интернет-магазины?

Если нет хорошего скила или денег на соответствующего разработчика, то не стоит.

4) Если вы имели дело с формами на сайте, подскажите, как лучше их реализовать, чтобы получился некий аналог форм в битриксе

Популярно — Webform. Правильно — Entityforms.

6) Действительно ли вам показался друпал сложным в освоении (как программистам, разумеется) в сравнении с другими системами?

Нет. Какой-нибудь Symfony 2 на порядок сложнее будет.

7) Как вы темизировали хлебные крошки и постраничную навигацию? На мой взгляд, разработчики друпала были сильно не правы, не реализовав их через файлы шаблонов.

Они реализованы theme функциями theme_breadcrumb и theme_pager. Функции мало чем отличаются от шаблонов — их так же можно переопределять, процессить и использовать через theme('...').