же писал почему использую такую терминологию.
Если не сложно, повторите пожалуйста или отправьте меня туда, где это можно узнать. Очень интересно! Спасибо!
Прости меня за любопытство, но где Вы увидели прямую связь между «тоннами кода» и MVC паттерном? Вы думаете, что будь клиент написан без применения MVC, размер исходных файлов бы сократился?
Так а MVC-то тут причем? Я могу использовать MVC на клиенте, получая куски html с сервера и «проиграю в интерактивности». А могу, не используя паттерн MVC, создавать html на клиенте, «проигрывая в SEO».
А еще я могу (только тссс! никому не говорите!) использовать MVC безе всяких фреймворков — как на сервере, так и на клиенте.
Я соглашусь с nvbn, складывается впечатление, что Вы не видите разницы между фреймворками и паттерном MVC. Тем более, что упомянутый Вами Knockout.js использует MVVM паттерн, а не MVC.
И между делом
Четвертый миф — это то, что Full-Stack фреймворки еще сыроваты, не стабильны, испытвают проблемы произодительности при синхронизации данных. На данный момент есть несколько проектов в продакшене, находящихся под нагрузкой.
Тут бы ссылочки добавить или хотя бы перечислить, а то не очень убедительно.
забавно. на картинке у вас написано одно, а вы говорите совершенно другое))) в методичке у вас — «поддержка инвалидов», «вывод на печать». «подписка» итд а пишите о незакрытых тегах… вы батенька, сами запутались))) я рекомендую Вам еще раз как следует изучить методичку, которую Вы выложили, а потом уже спорить со всеми (судя по комментам))).
и опять же. если Вы действительно занимались разработкой, то прекрасно понимаете, что в этом процессе есть куча мелочей, все из которых иногда нет времени предусмотреть. иногда — необходимости. предвижу Ваше возражение и сразу отвечу — «незакрытые теги это не мелочь, а досадная ошибка которую необходимо избегать». а вот вывод на печать это мелочь, в большинстве своем ненужная))
надеюсь, я Вас не обидел. но на будущее внимательно изучайте материал, под которым подписываетесь, а то смешно получается, очень смешно)))
Вы упорно игнорируете мой вопрос)) воля Ваша.
Если Вы были в роли программиста то должны понимать, что каждый пункт несете за собой дополнительные затраты времени, а как следствие — дополнительные затраты средств. И далеко не все параметры (если угодно — группы параметров))) являются необходимыми и обязательными для каждого проекта. Впрочем, об этом я уже писал комментом ниже. Дальнейшая дискуссия — переливание из пустого в порожнее)))
хм… чтобы ответить на ваш вопрос позвольте сначала поинтересоваться что в вашем понимании «качественный». а что «не качественный» сайт? и сразу вопрос — вы занимались когда-нибудь заказом или разработкой сайта?
Идея сама по себе очень хорошая. Но я бы не стал рассматривать эту схему как жесткую доктрину. Скорее это эталон, на который необходимо равняться разработчикам. Говорить что «все пункты обязательны к выполнению» это неразумно, потому что есть ряд ограничивающих факторов. Например целесообразность (например вывод на печать игрового сайта нецелесообразно), ограниченность в бюджете как уже говорилось, ограниченность во времени (если соблюдать абсолютно ВСЕ пункты, то процесс разработки проекта может изрядно затянуться и соответственно увеличиться его бюджет).
Заказчикам эта схема вряд ли поможет. Хорошо если они понимают само значение слово «валидность» (что кстати им абсолютно не нужно). Проблема может крыться даже в таком пункте как дизайн. В подавляющем большинстве случаев, качество дизайна определяется как понравилось\не понравилось, критерии типа «современность», «соответствие стилю» уходят на десятый план. Для заказчиков я бы посоветовал выпустить гораздо более упрощенную версию, но в которой они бы могли разобраться не имея ни малейшего представления о веб-технологиях или хотя бы полиграфии.
же писал почему использую такую терминологию.
Если не сложно, повторите пожалуйста или отправьте меня туда, где это можно узнать. Очень интересно! Спасибо!
А еще я могу (только тссс! никому не говорите!) использовать MVC безе всяких фреймворков — как на сервере, так и на клиенте.
Я соглашусь с nvbn, складывается впечатление, что Вы не видите разницы между фреймворками и паттерном MVC. Тем более, что упомянутый Вами Knockout.js использует MVVM паттерн, а не MVC.
И между делом
Четвертый миф — это то, что Full-Stack фреймворки еще сыроваты, не стабильны, испытвают проблемы произодительности при синхронизации данных. На данный момент есть несколько проектов в продакшене, находящихся под нагрузкой.
Тут бы ссылочки добавить или хотя бы перечислить, а то не очень убедительно.
и опять же. если Вы действительно занимались разработкой, то прекрасно понимаете, что в этом процессе есть куча мелочей, все из которых иногда нет времени предусмотреть. иногда — необходимости. предвижу Ваше возражение и сразу отвечу — «незакрытые теги это не мелочь, а досадная ошибка которую необходимо избегать». а вот вывод на печать это мелочь, в большинстве своем ненужная))
надеюсь, я Вас не обидел. но на будущее внимательно изучайте материал, под которым подписываетесь, а то смешно получается, очень смешно)))
Если Вы были в роли программиста то должны понимать, что каждый пункт несете за собой дополнительные затраты времени, а как следствие — дополнительные затраты средств. И далеко не все параметры (если угодно — группы параметров))) являются необходимыми и обязательными для каждого проекта. Впрочем, об этом я уже писал комментом ниже. Дальнейшая дискуссия — переливание из пустого в порожнее)))
Заказчикам эта схема вряд ли поможет. Хорошо если они понимают само значение слово «валидность» (что кстати им абсолютно не нужно). Проблема может крыться даже в таком пункте как дизайн. В подавляющем большинстве случаев, качество дизайна определяется как понравилось\не понравилось, критерии типа «современность», «соответствие стилю» уходят на десятый план. Для заказчиков я бы посоветовал выпустить гораздо более упрощенную версию, но в которой они бы могли разобраться не имея ни малейшего представления о веб-технологиях или хотя бы полиграфии.