Уже есть сервисы, которые позволяют делать все что угодно. Но проблема их в том, о чем Вы написали, по сути нужно выучить html+css. Мы решили эту проблему. В сервисе можно делать все, но при это в нем сокрыты все эти моменты. Научиться в нем работать можно буквально за пару часов. Так же можно автоматизировать создание сайта. Созданную с нуля секцию можно добавить в шаблоны, и использовать на других сайтах, не делая одно и тоже по сто раз.
В дальнейшем буду писать статьи о некоторых моментах, которые нельзя сделать не в каком сервисе. Например в нем можно сделать тему практически под любую CMS.
Согласен, именно для этого конструкторы и нужны. Но создавая сайт в конструкторе, можно сразу получить чистый код, который не придется потом переделывать. То что код будет выдаваться чистым, то это не как не усложнит работу в конструкторе. Даже в некоторых ситуация работу в конструкторе ускорит и упросит.
Например есть список товара, 20 наименований. Вам нужно изменить цвет заголовка. Если в конструкторе используются id, то Вам придется этот цвет изменять у всех 20 заголовков. Если будет использоваться class, то всего у одного.
Это тоже зависит от ситуации. Хотя против Вашего возражения не имею нечего против.
Напишу как это у нас сделано в сервисе.
Если в родители есть один p, то конструктор записывает .parent > p. Если несколько p, то класс не очищается. Так же есть возможность поставить в редакторе, что бы класс не очищался в любом случае.
В сервисе когда создаете сайт, то в редакторе работаете всегда с классами, когда код выгружается, то сервис решает если можно убрать класс, то он его убирает, если нет то нет.
Например на первом скрине именно такая ситуация. В родителе mode-row есть два потомка p, у одного также есть дополнительный класс. И прописывается 2 селектора
1) .mode-row > p. Это общий
2) .hlp-site .title-mode-marketer. Это дополнительный. Дописывается .hlp-site, что бы перебить верхний селектор.
Сервис еще разрабатывается, поэтому открыты для обратной связи.
Всем конструкторам не нужен чистый код. Он нужен только тем, которые заявляют, что мы замена ручной верстки. Потому что если кто то заявляет, что он замена чего то, то это должно быть хоть бы по качеству сопоставимо. Может хуже, но хотя бы сопоставимо.
Если честно, то что влияет на чистоту кода в конструкторах, это же влияет и на простоту работу в нем. Именно поэтому не смотря на большое количество конструкторов, в большинстве случаев они не удобные. Причины этому те же, что и причины плохого кода.
Одну из следующих статью напишу про конструкторы сайтов с точки зрения бизнеса. В этой статье была затронута только техническая сторона создаваемого сайта в таких сервисах. Статья больше была предназначена для верстальщиков и программистов, потому что была опубликована в разделе «Разработка». Следующая будет опубликована в разделе «Маркетинг», потому что она будет про бизнес, а не про технологии.
Наверное в некоторых ситуациях именно так и есть, что разработчику поставили задачу, а он ее решает. Установка стилей для конкретного элемента, не мешает использованию классов. Я специально не указывал ссылки на сервисы, даже перед тем как делать скрины убирал упоминания о конкретном сервисе в коде. Думаю так более правильнее.
Причины такой реализации, есть субъективные и объективные. Объективная, то что если элементы имею свойство position, в значение absolute, то использование классов в принципе тяжело реализуемо. Субъективная причина, то что так легче и быстрей в реализации, использовать id, а не class.
Если сервис позиционируется для конечных пользователей, то качество коде не имеет не какого значения, почти все именно такие конструкторы сайтов. А вот если сервис позиционируется как замена ручной верстки, то и должен рассматриваться и с этой точки зрения(качества кода), таких сервисов совсем не много.
Потому что подобные сервисы позиционируют себя, как замена ручной верстки. Например Wix не позиционируется так, поэтому его код и не был приведен. Я привел код сервисов, которые себя так позиционируют. С этой точки зрения я их сравнивал.
Для Ваших клиентов, код не нужен. Чистый код нужен для веб студий, который можно будет при необходимости доработать. Там и ценик немного выше, чем тысяча рублей.
Первый скрин с кодом в начале статьи, это тоже код сгенерирован в конструкторе сайтов, который я разрабатываю. Преимущество этого сервиса, не только в коде, есть преимущества и для клиентов, которым нужен сайт за 1 тыс рублей. Но статья именно про качество кода, поэтому и заострил на нем внимание.
Конкуренция именно в том и заключается, что человек сначала пошел создавать сайт в конструкторе, а потом пришел до Вас с заказом. Есть пользователи, которые на конструкторах и остались. Именно в этом и заключается конкуренция, что часть людей остается на конструкторах, а не идут за разработкой сайтов в веб-студии или к фрилансеру.
Я думаю если бы пользователь создал сайт в сервисе, экспортировал код и установил его на свой хостинг. Я больше имел ввиду именно такие сервисы, в которых можно экспортировать код сайта. А потом когда ему потребовалась доработка, то прейдя к Вам с этим заказом, его было бы уже сложней уговорить полностью переделать сайт, потому что сайт был у него уже на хостинге, а ему нужна была только доработка. А в Вашем случае нужен был перенос сайта т.е создание сайта с нуля, только такого же как у заказчика был на конструкторе.
Проблема не в размере css файла, а с дублированием кода при использовании id. Например если у нас список товаров состоящий из 20 наименований, то это будут 20 дублирующих стилей при использовании id, при использовании class, будет только один стиль. Использование id влияет не только на качество кода, но и на быстроту и удобство работы в конструкторе. Если id, то придется у всех 20 элементов изменять стили, например цвет заголовка, а если класс то только у одного.
Я приводил скрины кода сервисов, которые позиционируют себя, как сервисы для замены ручной верстки, поэтому, и требования к экспортируемого кода с этой позиции. Если Wix позиционирует себя как конструктор для конечного пользователя, то и вопросов к нему нет по этому поводу.
Насчет времени разработки, то я сам являюсь разработчиком такого сервиса, поэтому смотрю на это именно с этой позиции.
Думаю bootstrapstudio по принципу работы больше сопостовим с Webflow, проблемой которого является не возможность свободно передвигать элементы по полотну.
Немного уточню, что мы говорим о сервисе по созданию только сайтов. В этом сервисе нельзя создавать интерфейсы для декстопных и мобильных приложений.
Если так, то знание этих технология необходимо лишь в одном случае, если это программа на десктоп, а не сервис в браузере. Если писать конструктор сайтов как программу, то его будет еще тяжелей сделать, по причине того, что средой отработки сайта является браузер, а не оболочка рабочего стола. Как знаю хороших реализаций конструкторов сайтов, как программа особо нет.
Наш конструктор сделан, как сервис, который отрабатывается в браузере, поэтому для самого конструктора необходимо только javascript. Серверная часть может быть написана на чем угодно, это не имеет особого значения, потому что работа пользователя и создание сайта происходит непосредственно на javascript.
Думаю, что одна из реализаций такого сервису уже сделана. Разработчики, которой решили основные проблемы существующих сервисов. Наберите в поиске слово hollpee. Это сервис, который я разрабатываю.
Это тоже одна из главных причин, хотя она наверное и является основой.
Есть еще одна этому причина, это выбранный подход к созданию конструктора. Например если у элементов сделан тот же position:absolute, то по определению код не может быть хорошим. Так же если конструктор сделан, как программа на компьютер, там тоже будет сложно получить хороший код, потому что по сути этой программе придется эмитировать некоторый функционал браузера. Особенно если сайт нужен с responsive дизайном.
Думаю этот проект не особо легкий, как минимум по причине того, что хороших проектов подобного плана немного. С технической стороны это конечно реализуемо.
Чтобы небыли перезаписаны margin и другие стили, это нужно конструктору проверять, если все нормально, то записывать сокращенно, если нет, то нужно записывать полностью(margin-top и тд.) Все зависит от конкретной ситуации.
Для стабильности, да лучше не убирать, для чистоты лучше убрать. Тут уже каждый в зависимости от ситуации решает как лучше.
Первопричина этому это плохой код, если код хороший, то и с производительностью будет нормально. Например кода на первом скрине, это код сгенерированный в конструкторе.
За плагин спасибо.
Мне кажется основная этому причина это отсутствие подходящего инструмента, потому что они больше заточены под конечного пользователя, а не под веб-студии.
С accessibility есть такая проблема. Думаю со временем конструкторы тоже это добавят. В некоторых это есть, но они специфичные. Например в конструкторах для создания сайтов для учителей.
Конструкторы для веб студий тоже потихоньку начинают появляться. У веб студий тоже есть проблемы со стоимостью разработки сайтов, она слишком высокой получается, и становиться все менее конкурентно способной.
Насчет первого согласен. Но если код будет форматированным, то это будет лучше, потому что возможно с ним придется потом в ручную работать. Когда пользователь получит код, то пусть лучше решает сам, нужно его сжимать или нет.
Есть конструкторы, которые дают возможность экспортировать код, а есть те которые не дают. Несмотря на их схожесть задачи и требования к ним немного различаются. Хотя те и другие преследуют цель ускорения и удешевления разработки. Те, в которых нет экспорта кода, то к ним нет вопросов. Там может быть любой код, потому что с ним человек не как ни работает, это как машинный код. Но если конструктор отдает код, то это предполагает, что есть высокая вероятность, что его будут вручную дорабатывать. Обычно такие конструкторы(с экспортом кода) больше предназначены для веб-студий и фрилансеров, а не для конечных пользователей.
В дальнейшем буду писать статьи о некоторых моментах, которые нельзя сделать не в каком сервисе. Например в нем можно сделать тему практически под любую CMS.
Например есть список товара, 20 наименований. Вам нужно изменить цвет заголовка. Если в конструкторе используются id, то Вам придется этот цвет изменять у всех 20 заголовков. Если будет использоваться class, то всего у одного.
Напишу как это у нас сделано в сервисе.
Если в родители есть один p, то конструктор записывает .parent > p. Если несколько p, то класс не очищается. Так же есть возможность поставить в редакторе, что бы класс не очищался в любом случае.
В сервисе когда создаете сайт, то в редакторе работаете всегда с классами, когда код выгружается, то сервис решает если можно убрать класс, то он его убирает, если нет то нет.
Например на первом скрине именно такая ситуация. В родителе mode-row есть два потомка p, у одного также есть дополнительный класс. И прописывается 2 селектора
1) .mode-row > p. Это общий
2) .hlp-site .title-mode-marketer. Это дополнительный. Дописывается .hlp-site, что бы перебить верхний селектор.
Сервис еще разрабатывается, поэтому открыты для обратной связи.
Если честно, то что влияет на чистоту кода в конструкторах, это же влияет и на простоту работу в нем. Именно поэтому не смотря на большое количество конструкторов, в большинстве случаев они не удобные. Причины этому те же, что и причины плохого кода.
Одну из следующих статью напишу про конструкторы сайтов с точки зрения бизнеса. В этой статье была затронута только техническая сторона создаваемого сайта в таких сервисах. Статья больше была предназначена для верстальщиков и программистов, потому что была опубликована в разделе «Разработка». Следующая будет опубликована в разделе «Маркетинг», потому что она будет про бизнес, а не про технологии.
Причины такой реализации, есть субъективные и объективные. Объективная, то что если элементы имею свойство position, в значение absolute, то использование классов в принципе тяжело реализуемо. Субъективная причина, то что так легче и быстрей в реализации, использовать id, а не class.
Если сервис позиционируется для конечных пользователей, то качество коде не имеет не какого значения, почти все именно такие конструкторы сайтов. А вот если сервис позиционируется как замена ручной верстки, то и должен рассматриваться и с этой точки зрения(качества кода), таких сервисов совсем не много.
Для Ваших клиентов, код не нужен. Чистый код нужен для веб студий, который можно будет при необходимости доработать. Там и ценик немного выше, чем тысяча рублей.
Первый скрин с кодом в начале статьи, это тоже код сгенерирован в конструкторе сайтов, который я разрабатываю. Преимущество этого сервиса, не только в коде, есть преимущества и для клиентов, которым нужен сайт за 1 тыс рублей. Но статья именно про качество кода, поэтому и заострил на нем внимание.
Я думаю если бы пользователь создал сайт в сервисе, экспортировал код и установил его на свой хостинг. Я больше имел ввиду именно такие сервисы, в которых можно экспортировать код сайта. А потом когда ему потребовалась доработка, то прейдя к Вам с этим заказом, его было бы уже сложней уговорить полностью переделать сайт, потому что сайт был у него уже на хостинге, а ему нужна была только доработка. А в Вашем случае нужен был перенос сайта т.е создание сайта с нуля, только такого же как у заказчика был на конструкторе.
Я приводил скрины кода сервисов, которые позиционируют себя, как сервисы для замены ручной верстки, поэтому, и требования к экспортируемого кода с этой позиции. Если Wix позиционирует себя как конструктор для конечного пользователя, то и вопросов к нему нет по этому поводу.
Насчет времени разработки, то я сам являюсь разработчиком такого сервиса, поэтому смотрю на это именно с этой позиции.
Если так, то знание этих технология необходимо лишь в одном случае, если это программа на десктоп, а не сервис в браузере. Если писать конструктор сайтов как программу, то его будет еще тяжелей сделать, по причине того, что средой отработки сайта является браузер, а не оболочка рабочего стола. Как знаю хороших реализаций конструкторов сайтов, как программа особо нет.
Наш конструктор сделан, как сервис, который отрабатывается в браузере, поэтому для самого конструктора необходимо только javascript. Серверная часть может быть написана на чем угодно, это не имеет особого значения, потому что работа пользователя и создание сайта происходит непосредственно на javascript.
Адрес сервиса http://hollpee.ru
Есть еще одна этому причина, это выбранный подход к созданию конструктора. Например если у элементов сделан тот же position:absolute, то по определению код не может быть хорошим. Так же если конструктор сделан, как программа на компьютер, там тоже будет сложно получить хороший код, потому что по сути этой программе придется эмитировать некоторый функционал браузера. Особенно если сайт нужен с responsive дизайном.
Думаю этот проект не особо легкий, как минимум по причине того, что хороших проектов подобного плана немного. С технической стороны это конечно реализуемо.
Для стабильности, да лучше не убирать, для чистоты лучше убрать. Тут уже каждый в зависимости от ситуации решает как лучше.
Мне кажется основная этому причина это отсутствие подходящего инструмента, потому что они больше заточены под конечного пользователя, а не под веб-студии.
Конструкторы для веб студий тоже потихоньку начинают появляться. У веб студий тоже есть проблемы со стоимостью разработки сайтов, она слишком высокой получается, и становиться все менее конкурентно способной.
Есть конструкторы, которые дают возможность экспортировать код, а есть те которые не дают. Несмотря на их схожесть задачи и требования к ним немного различаются. Хотя те и другие преследуют цель ускорения и удешевления разработки. Те, в которых нет экспорта кода, то к ним нет вопросов. Там может быть любой код, потому что с ним человек не как ни работает, это как машинный код. Но если конструктор отдает код, то это предполагает, что есть высокая вероятность, что его будут вручную дорабатывать. Обычно такие конструкторы(с экспортом кода) больше предназначены для веб-студий и фрилансеров, а не для конечных пользователей.