Комментарии

Интересно а почему дизайнеры вообще стали использовать прототипы? Раньше делали ведь просто дизайн и дальше разработку, UI/UX и прототипирование появилось сравнительно недавно если я не ошибаюсь

Для начала определимся с терминологией. В английском языке есть слова wireframe и prototype. В русском языке — сетка, прототип и живой прототип. Из-за трудностей с переводом, все время возникает путаница. Wireframe переводится как сетка. Но то, что мы называем сеткой — это grid. А то, что по-английски называется wireframe, мы называем прототипом. То, что у них prototype, мы называем «живой прототип» (который можно покликать).

От лица всей нашей компании хочу поблагодарить персонал ДСТ принимавший участие в работе над нашим новым маркетплейсом. У нас было свое представление будущего сайта и благодаря нормальному и плодотворному рабочему процессу со специалистами ДСТ получилось его создать. Мы реализовали то что хотели с вашей помощью! Спасибо за проделанную работу!

Edge на chromium поддерживает, а старый edge нет

Вот замечательная таблица со всеми (основными) видами типов веб-приложений

Мы обратились за ремонтом сайта в DST Global. Первое что приятно удивило это — удобное взаимодействие. Все пожелания по визуализации сайта были выполнены, в процессе обсуждались полезные рекомендации и оптимальные решения по структуре. Окончательный вариант выполнен в соответствии с техническим заданием. Спасибо

Спасибо специалистам DST, за то что ответственно подходят к работе и решению поставленных задач. За время совместной работы над нашей цифровой платформой, сотрудники компании показали себя высокими профессионалами, которые следят за качеством выполняемой работы и учитывают пожелания Заказчика. Выполнили работу все работы в установленные сроки.

Очень интересный комментарий! И хотелось бы увидеть не просто коммент, а целую статью по данной теме, поскольку (как мне кажется) вы в ней очень хорошо разбираетесь, и в последнее время она становится все более актуальной.

Несколько слов поводу SPA и их «недостатках» (буду высказываться в контексте Vue.js)

1) Для SEO в мире SPA существует SSR (Server side rendering) — Nuxt.js.
Если кратко, то когда пользователь впервые обращается к сайту, то на стороне сервера делаются все необходимые запросы к API для получения данных + «раскрывается» вся html, выполняется еще куча различных действий и в итоге на клиент улетает уже развернутая html, со всеми необходимыми данными, а дальше web-приложение начинает работать как обычное SPA.

2) Производительность при первой инициализации сайта на стороне клиента (без использования SSR) действительно будет уступать многостраничным (MPA) приложением, но когда дела доходит до роутинга (переходам по страницам) выбору фильтров, оформления покупки и т.д. (AJAX), то SPA в десятки раз выигрывает по производительности у MPA приложений, т.к. время на отрисовку при каждом действии всей страницы (как в MPA) требуется гораздо больше, нежели чем SPA приложению (т.к. перерисовывается только то, что изменилось и не более того). Стоит помнить, что самая дорогая операция в вебе — это рендер / отрисовка

А если же использовать SPA + SSR, то MPA приложения проигрывают по производительности практически во всех аспектах.

Так же, с помощью SSR мы можем реализовывать следующую технику: загружать только те части js / css, которые необходимы для работы конкретного компонента, т.е. представьте, что у нас есть страница каталога с закрытой картой и с закрытыми фильтрами. Когда мы загружаем эту страницу, то у нас не подгружаются компоненты, связанные с картой и фильтрами (т.к. она закрыты) => размер страницы будет крайне мал, а когда человек включает карту или (и) фильтры, то у нас динамически со стороны сервера подгружаются эти самые компоненты (Code Splitting), крч мы подгружаем компоненты только тогда, когда в них есть необходимость.
И дополню, что Code Splitting работает не только для отдельных компонентов, но и для целых страниц, что очень сильно облегчает размер бандла => скорость отдачи web-приложения на сторону клиента.

3) Утечка памяти: если над SPA приложением работает (ют) квалифицированные разработчики, то я на 99.8% уверен в том, что подобной проблемы не возникнет, т.к. методы / тулзы для профилирования (анализа работы приложения) уже давным-давно вышли на новый уровень и сейчас не эпоха ie6, где люди дебажили (искали баги / ошибки) с помощью alert's. И непонятно, почему этот пункт отнесся именно к SPA, ведь в любом приложении, где есть хоть какая-то логика, может возникнуть подобная ситуация, ни?

4) Поддержка js — я хз, но мы сейчас не в 2001 году, и я никогда (на основе личного опыта) не видел подобных людей, у которых был бы отключен js (исключение — это Opera Mini или всякие proxy browser, доля которых 0.0001% (наобум)), да даже в том же Tor Browser уже по умолчанию включен js (просто знаю).
В дополнении к этому, могу сказать, что для этого в мире SPA, и не только — существует специальная техника, которая называется Graceful Degradation (можно так же посмотреть в сторону Progressive Enhancement, как делает VK и многие другие популярные платформы).

5) Про PWA / TWA даже писать не буду, т.к. для этого нужно писать отдельную статью о том, что в этой статье не так.

Для frontend developer'ов: я постарался выражаться не с точки зрения программиста, а с точки зрения «обывателя», чтобы всем было понятно, о чем я говорю, поэтому примите и простите.

Я смотрю требования в DST высокие даже к джунам, это грустно, я не дотягиваю даже до этого уровня, еще учится и учится

Всегда доводи начатое дело до конца.
Но в начале подумай: стоит ли оно того?
Необходимо ли это?
Чтобы потом без вариантов. Раз решив — иди до конца, иди, и останавливайся на передышку как можно меньше. Чем больше отдыхаешь — тем меньше хочется работать. И чем больше работаешь — тем меньше хочется отдыхать.
Всегда доводи начатое дело до конца.
Иначе мало того, что ерунда в итоге получится, так ещё и себя уважать перестанешь. Какое бы оправдание себе не придумал.

Очень хорошие, мотивирующие советы. Главный совет — доводите начатое до конца и все получится

Большое спасибо за подробную статью о SPA и MPA и в целом развитии веб приложений, это было очень интересно и познавательно.

Удобство все же вполне осязаемая штука. Если взять две системы и попробовать научить использовать их секретаршу, а потом еще предложить ей консультирование в течении месяца, то все становится довольно быстро понятным. Учить Joomla например будет весьма непросто. Люди просто забывают как там и что работает, как только закрывают ее больше чем на неделю. И посмотрите для примера MODx. Для понимания всех основных и необходимых возможностей управления уходит примерно 3-4 часа (включая последующие консультации).

Разумеется сначала человеку нужно разобраться в интерфейсе. Так вот скорость изучения как раз и зависит от удобства.

В общем-то правда, что данные CMS делаются программистами для программистов. Потому что именно программисты потом проводят внедрение этих систем, допилку напильником под нужды заказчика. У всех систем свои интерфейсы, так как слишком разная у всех концепция хранения, представления и управления информацией. Унифицированного ничего нет. Даже windows вам удобна только потому что вы к ней привыкли. А если посадить человека первый раз за компьютер, то интерфейс любой CMS будет ему не на много отличаться от интерфейса винды — также неудобен и незнаком.

Друпал это CMF а не CMS. Отсюда и сложность разработки конечного продукта. Друпал это заготовка, а не готовый движок на который можно просто натянуть дизайн и будет работать.

HostCMS — вполне устраивает всем вышеперечисленным требованиям. Простой сайт создается очень быстро. XSLT шаблонизатор, хорошая админка. Много возможностей. Есть бесплатная редакция, хорошая техподдержка.

NetCat — вполне неплохая система с широкими возможностями. Но уж очень кривой интерфейс редактирования и тяжелочитаемый код. Также если брать под нее модули… то это кошмар просто. Очень большое количество ошибок в коде, начиная от простой невнимательности разработчиков, заканчивая достаточно серьезными недоработками. Если будете работать с модулем — придется от и до разбираться как он работает внутри. Плюс всей в целом — позволяет создавать нетривиальные и гибкие проекты.

Joomla — не пользовался, но в багтраках проскакивает очень часто. Будте осторожнее

И потом, у любой CMS есть, скажем так, некий баланс между легкостью разработки и возможностями, и сложностью и возможностями админки. Т.е. система, которая создана программистами для обычных пользователей, скорее всего проиграет в возможностях и скорости. «программистами для обычных пользователей» — в данном случае имеется ввиду кастомизация системы под определенный проект с помощью админки без знания каких-либо специальных знаний (языков программирования и т.д.)

никогда не возникала мысль о простой, гибкой и простой в освоении системы? Я не говорю о пропиаренных системах — тлько о существующих? Или вы всерьез полагаете, что гибкая система должна быть сложна в освоении?..

На самом деле пробелма в том, что имеющиеся на рынке CMS (я говорю сейчас в первую очередь об отчуждаемых) во-первых — модульные (либо напрямую, либо идеологически), а во вторых — отнаследовавшие все ограничения древнего мускуля (поясню термин — в данном случае он означает, что следы этих естественных ограничений вроде максимального объема текстового пола в 8192 байта, или блокирования таблиц при совместном доступе до сих пор встречаются в идеологииCMS). Почему так получилось — отдельная тема, и, скорее всего, не тема данного разговора.

А чтобы все было более менее гибко_ CMS должна быть (IMHO!!! — это на тему должна и если мы говорим о гибкости) объектно-полиморфичная, и если уж привязанная к БД, то к какой-нить более мощной. Oracle, PostcgreSQL. Помимо прочегоЮ было бы очень даже правильно, чтобы параметры внутрь передавались целочисленные (коротенький кусочек PHP (int) лечит бошльшинство SQL инъекций).

А еще — и это уже сугубо IMHO — в идеале объем кода CMS не должен превышать 100 Кб кода. чем меньше — тем лучше. Достигается адекватным проектированием.

Мы с 1999 по 2004 работали с модульной системой собственного изготовления (поскольку оно изначально работало на postgresql, одной засады мы благополучно избежали), где-то во времена PHP5 RC1 собрали первый прототип фреймворка для клепания на лету кастоимзированных CMS. Не могу сказать, что все получилось идеально (например интерфейс, в свое время придуманный программистом, борется до сих пор и пока, к сожалению, побеждает), но вот при необходимости «с нуля» сотворить за неделю сайтик с уникальной функциональностью у нас вроде бы ка получается.

Господа — проектируйте, а не воюйте!

Вы точно внимательно читали заметку?
То что вы говорите, есть пункт первый. Это маркетинговое преимущество, типа «с нашими сайтами оооочень удобно работать, потому что они использую НашаSuperCMS, там можно делать то-то и то-то, так-то и так-то».

И даже тут, лучший вариант изменения сайта владельцем, это не админ панель вовсе, а хитроумный AJAX JavaScript. Когда нет необходимости обучатся админ-панеле, а можно менять свой сайт на своём сайте.

А автоматизация процесса всё равно нужно, потомучто увелечение производственной мощности только с помощю увелечения персонала, не есть хороший тон ведения бизнеса…

Все указанные автором комментария цели – частный случай. Со стороны разработчика.
Вы бы лучше посмотрели на CMS со стороны владельца сайта. На то ведь она и _CMS_ (content management system, т.е. система управления контентом), а не система создания сайтов.