Где можно посмотреть пример готового сайта на Express.js?

copal: мне откровенно надоело с вами спорить.

stephenwalther.com/archive/2008/08/24/the-evolutio... вот читайте, конкретно то о чем вы говорите это MVC, JSP years. То есть это уже не каноническая реализация MVC.

Так же почитайте Мартина Фаулера о недостатках MVC которые были исправлены другими подходами:
martinfowler.com/eaaDev/uiArchs.html

отдельное внимание уделите словам UI architecture. Если интересно продолжить дискуссию - в личку. Тут я буду игнорировать уже, ибо мы уже достали окружающих)

Где можно посмотреть пример готового сайта на Express.js?

copal: все, закрываем дискуссию. Тут товарисчу HoHsi уже натификациями все заспамили, раз он жалуется на спам.

БЭМ. Не понятие основных понятий - блок, элемент, модификатор?

kid-programmer: блоки не зависят от других блоков, так что скорее элементы..., но да... грубо говоря блоки пожалуй. То есть я все же стараюсь делать блоками только то, что дублируется.

Посмотрите на cssmodules, это намного более удобная концепция, но... если BEM не требует ничего что бы работать (просто будет геморно), то cssmodules завязано на сборке.

Где можно посмотреть пример готового сайта на Express.js?

copal:

И именно с него, чтобы проследить по времени, как люди ошибаясь меняли его

Если мы посмотрим на схему самого первого MVC то мы можем заметить, что сейчас повсеместно используется HMVC а не MVC.

ведь модель на сервере

сервер отдельно, клиент отдельно. Сервер не модель, модель это что-то маленькое, простая структура. Повторюсь, вы точно читали первоисточник?

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

Ну вот Вы, насколько мне не изменяет память, не видите смысл в grid при верстке.

Я не "не вижу смысла в grid при верстке", вы вырвали фразу из контекста. Я отвечал на вопрос "зачем нужны отдельные элементы? Можно же просто сделать универсальные элементы которые будут заточены под сетку". И ответ мой был к тому что не всегда сетка помогает. Я использую сетку, это довольно удобная штука, но это не панацея.

вынужден писать в вэб (для других) именно так, как это принято в вэб.

в web толстый контроллер считается плохой практикой, если что. То что вы делаете толстые контроллеры - это ваша личная проблема а не индустрии. У меня вот контроллеры обладают ограниченной ответственностью. Если мы берем сервер - то это перевод запроса из HTTP формата в формат приложение, скармливание этого дела сервису и формирование ответа из DTO пришедшего к нам из сервиса. В упрощенном случае это три строчки - десериализовать реквест, отправить в сервис, сериализовать респонс. Если мы говорим о клиенте - то задача контроллера - среагировать на действие пользователя и попросить модель/сервис что-то сделать с данными. И все. Контроллер на клиенте у меня ничегошеньки не знает о view и он весьма тонкий, вся логика вынесена в сервисы (angular).

они должны быть в виде дерева

Что именно в виде дерева? MVC 79-ого года подразумевает что у вас есть модель как структура данных, объект смолтоковский, возможно это какое-то дерево объектов. Контроллер - всегда один объект, представление - так же один объект, который может оперировать другими, но он один.

То что вы описываете - это HMVC а не MVC 79-ого года.

модель находится на сервере.

повторюсь но все же... сервер это не модель. А если и так то это только подтверждает что на самом сервере нет MVC, так как... ну это же модель....

Вы сами не путаетесь в мыслях часом?

БЭМ. Не понятие основных понятий - блок, элемент, модификатор?

Думай Головой: ну как бы так оно и есть, только классы должны присутствовать в селекторах.

kid-programmer: именно так, все разбивается на блоки, внутри блоков другие блоки... в плодь до отдельных атомарных блоков, таких как параграфы, кнопки и т.д.

Повторюсь, это все хорошо работает при большом количестве проектов трубеющих примерно одинаковый UI и оформление, когда на сотню проектов можно реюзать блоки. Для маленьких проектов это не особо имеет смысла.

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

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

БЭМ. Не понятие основных понятий - блок, элемент, модификатор?

kid-programmer: соль в том что все дублирующееся - это явно блок.

БЭМ. Не понятие основных понятий - блок, элемент, модификатор?

kid-programmer: codepen.io/anon/pen/MavEBw и нет проблем.

Библиотека для оптимизации изображений?

Иван Волков: почитайте про то, как работают штуки аля jpegoptim. Речь идет о lossless сжатии, GD это не умеет.

БЭМ. Не понятие основных понятий - блок, элемент, модификатор?

Думай Головой: ммм... а можете оформить пример на codepen?

Что такое stack и heap в языке программирования?

recursi0n: то есть реализация не важна, важно как именно хранятся данные.

Что такое stack и heap в языке программирования?

recursi0n: это структура данных. Она есть в програмном виде (те структурки которые вы можете достать из стандартной библиотеки), есть в програмном виде на системном уровне (менеджер памяти операционной системы содержит heap), есть в железном варианте (процессоры частенько иеют стэковый регистр или что-то в этом духе, есть так же реализация чисто стэковой машины, например по этому принципу реализована Java Virtual Machine)

БЭМ. Не понятие основных понятий - блок, элемент, модификатор?

БЭМ норм, просто работает это хорошо только в больших масштабах. На маленьких да, избыточно.

БЭМ. Не понятие основных понятий - блок, элемент, модификатор?

kid-programmer: потому что далеко не всегда объекты должны располагаться по сетке, все обычно много сложнее.

БЭМ. Не понятие основных понятий - блок, элемент, модификатор?

kid-programmer: ну потому что это все объекты, а не "классы". Классы это вообще рак ООП, но удобно.

Есть объект "блок" задача которого - инкапсулировать какой-то UI компонент. Например блог пост, лэйблочка с временем добавления, тело поста, аватарка пользователя и т.д. Все это блоки. Элементы это объекты, принадлежащие блоку, занимающиеся "расстановкой" блоков внутри друг дружки. Модификаторы - объекты расширяющие стили. И для них так же справедливо ограничения по тому какие стили в них могут быть, а именно... модификатор для элемента должен только менять расположение дочерних блоков. А модификатор для блока в идеале не должен влиять на позиционирование, менять только оформление.

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

Посмотрите на cssmodules, это пожалуй самое актуальное на данный момент, во всяком случае идея мне нравится, но пока сырова-то.

Библиотека для оптимизации изображений?

Иван Волков: GD не умеет качественно жать картинки, не умеет удалять метаданные да и можно конечно хотя бы метаданные обрезать да выжрет много памяти и медленно.

Где можно посмотреть пример готового сайта на Express.js?

HoHsi: да никак, мы просто общаемся на тему MVC-фреймворков. В кратце, товарисч copal очень любит MVC а я считаю название MVC-фреймворк маркетинговым булшитом.

Насколько код ООП и что бы вы посоветовали по его улучшению?

DevMan : mysqli излишне низкоуровневая штука, и она нужна только когда тебе не хватает PDO (когда тебе нужны плюшки mysqlnd вроде асинхронных запросов). Согласись, это не случай автора.

Насколько код ООП и что бы вы посоветовали по его улучшению?

dk-web: не не, это другое. Хабр тем и крут что комментарии обычно много ценнее статьи.

Насколько код ООП и что бы вы посоветовали по его улучшению?

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

Насколько код ООП и что бы вы посоветовали по его улучшению?

dk-web: да, извините. Я наискосок читаю, некоторые слова выпускаю извиду...