Слово богу нет, и нужно этому препятствовать изо всех сил.
Есть у меня идейка в закромах чертогов разума, написать похожую статейку про фронтов, в которой, в том числе объяснить и почему у них такие ЗП, спойлер, работают как минимум за 2х.
Отличная статья, приятно и структурировано написана.
Касаемо темы, не совсем понял проблематику и как следствие для меня повисло в воздухе и решение.
Не секрет, что индустрия устала от новых технологий, есть предположение, что к любому новому стеку/синтаксису уже будет предвзятое отношение. Исходя из этого, хотелось бы увидеть какие-то сравнения с существующими решениями и доказательства, что Nulm более эффективен. Как он будет выглядеть и вести себя в реальном приложении?
Если же это не цель, то конечно, как творчество, самовыражение и возможная альтернатива, имеет место быть.
Думаю придираться к синтаксису дело не очень благодарное, это вкусовщина, но для меня не совместимость с HTML/CSS является минусом. Это подразумевает более высокий порог вхождения.
В любом случаи, желаю удачи и очень интересно будет понаблюдать за развитием проекта.
Хороший и интересный вопрос.
Конечно, нужно рассмотреть это случай более подробно, понять в какой ситуации мы решаем проблему именно таким образом. Так же, похоже стоит проговорить точно, я ни в коем случае не стараюсь полностью убрать вёрстку рукам, от сюда и концепция 2-х сторонней связи кода и визуального редактора. То есть если Вам нужно написать такое условие, просто напишите его, в автоматизации оно не нуждается.
Но так же и саму проблему стоит рассмотреть с другого ракурса. Не стоит забывать, что calc это инструмент введённый для помощи верстальщикам, долгое время обходились без него. И большую часть задач, так же можно решить без него. Тут как раз автоматизации и поможет.
Нет, я хочу оптимизировать свой рабочий процесс.
У меня есть абсолютно точный запросы и желание проверить гипотезу. Зачем кому-то про это сообщать? Почему бы и нет.
Пользы от этой публикации я получил уже неоценимо много.
Спасибо за столь развёрнутый ответ, конечно я по другому смотрю на ряд проблем, ввиду этого Ваше видение очень ценно и открывает для меня другой взгляд на поднятые вопросы. Что конечно и являлось одной из целей публикации данной статьи.
Но как бы там ни было, лично для себя я вижу ряд проблем в создании интерфейсов, а как следствие, и приложений. Мои исследования направлены на их формализацию и поиска решений. И если это мне поможет хоть сколько ускорить и оптимизировать мой рабочий процесс, то это уже будет победа.
Как я понимаю, Вас вполне устраивает текущее положение дел.
Вот уж не знаю, каким боком эта статья попала в мои рекомендации, но привет из Минска 2020, каждый день работаю из кофеен, попивая капучино и закусывая круассанами)). А их только рядом с домом штук 10.
Ну судя по описанию, мы с Вами практически родные души)))).
А не приходилось сталкиваться с тем же Storybook или аналогами?
Я это к тому, что в любом большом приложении будут и правила на структурирование кода, та же организация дизайн системы? Отделение бизнес логики от отображения и тп.
Неужели никогда не хотелось просто взять и подвигать элемент, изменяя его положение? Например, поигравшись с маржингами/шрифтами/другим в инспекторе, чтобы они автоматом применились к коду? Что-то подобное уже когда-то было кстати. Или забросить компонент из библиотеки сразу на экран? Или чтобы изменения, сделанные дизайнером сразу применились к интерфейсу? А как вы решаете вопрос со сложной анимацией?
По всей видимости мы с Вами сталкивались с различными задачами в своей проф. деятельности. Если не секрет, какая у Вас профессия? Данная информация для меня будет полезна, когда буду более тщательно продумывать область применения.
Опять же, не со всеми Вашими утверждениями согласен, но конечно доказать что-то или переубедить Вас цели у меня нет).
Да и 30% уже не плохо.
Если это перевести на деньги, да в мировом масштабе, то получиться очень существенная экономия.
Хотя я с Вами конечно не совсем согласен, как один из результатов этой статьи, мне удалось познакомиться с людьми, которые погружены в эту проблему довольно глубоко. Я узнал о существовании ещё большего количества решений именно по созданию разметки, которые просто поражают воображения.
Вопрос в другом, почему они не известны и не пользуются популярностью?
Да, маня как раз и волнует в первую очередь вопрос, как это реализовать так, чтобы оно встроилось в уже в существующие рабочие процессы и именно что помогало, а не создавало новый уровень абстракций и сложностей.
Для этого я описал в 2-х словах, что для меня есть идеальный варианты и постарался определить важные критерии вёрстки.
Есть ли у Вас мысли, чтобы можно ещё добаить или изменить?
Конечно, вёрстка с абсолютным позиционированием это сразу не наш случай, для любого разработчика это богомерзкое решение). Собственно об этом я писал в части про «показателями качества для разработчиков».
Для того чтобы автоматизировать «сложные с точки зрения дизайна и человеческой логики макеты» нужно более подробно раскрыть тему, формализовать и классифицировать задачи.
Ну и конечно, не стоит стараться достигнуть 100% не участия человека, я думаю это в корни не верный подход.
Как раз для этого и считаю следующий шаг важным — двухсторонняя связь между кодом и графическим отображением. Доказав эти два концепта далее можно уже прорабатывать полее специальные и сложные случаи.
Ох, боюсь всё уже изменилось. Проблема вёрстки с помощью ИИ уже решена, что я так же в статье озвучил. Не идеально, но закон Парето соблюдён. github.com/tonybeltramelli/pix2code или habr.com/ru/post/347120, другое дело, что на мой взгляд это избыточно и что самое важное — плохо контролируемо.
Спасибо за обратную связь, подскажите, что Вас натолкнуло на мысль, что статья о построении основного макета? Данная информация будет для меня очень полезна и смогу более чётко раскрыть мысль.
Статья поднимает проблематику современной вёрстки. Как вариант решения, я предлагаю автоматизацию и уже проблемы связанные с ней. Выделяю основную проблему и
далее описываею подход для её решения — построения всего дерева, опуская ряд крайних случаев. Так же в рамках статья я показываю, что описанный подход является работоспособным.
Конечно, если свести всю вёрстку к flexbox и grid, то в этом нет смысла. Но на мой скромный взгляд, тема немного шире, так у нас есть ещё как минимум таблицы, ну и ещё пара другая сотен сущностей с которыми приходится работать верстальщику, как шрифты или градиенты. Также жизненный цикл разметки не заканчивается после создания.
Но конечно я не претендую на истину в финальной инстанции и каждый сам волен для себя решать, что для него является бессмысленным, а что нет.
Глаза боятся, а руки делают). Но я конечно не стараюсь сформулировать серебрённую пулю, которая всё за меня сделает. Нет, только инструмент, который позволит упростить хотя бы 80% кейсов. И думаю, нам немного больше повезло. В отличие от издательского дела, любой инженер, который занимается созданием интерфейсов, сможет на низком уровне его доработать.
Да, согласен, есть много случаев, которые не относятся к просто технической задачи построения дерева. Как раз их вот и стоит оставить для работы специалисту. В рамках исследований буду по максимуму стараться сократить рутину.
В концепте очень мало уделил внимание перекрытию, особенно двойному, от сюда и подобный не очень качественный результат. С другой стороны я ещё и усложнил себе задачу, так как совсем не пользовался в концепте информацией о порядке элементов).
Технология очень интересная. Довольно давно сам погружён в проблематику управления данными и redux в частности. Любой проект на опрделенённой стадии развития сталкнётся с проблемами, что пытаются решить подобные технологии.
Очень полезная и нужная статься, считаю что нужно популяризировать альтернативы дорогим решениям типа redux.
В качестве обратной связи, авторский стиль отталкивает от восприятия информации.
Привет!
Мне, как фронту часто приходится открывать макеты, нарисованные дизайнером в Figma, зачастую это 4 — 5 одновременных вкладок. На моей машине с 32гб памяти всё работает как часы и я могу ещё запускать IDE, 2 — 3 сервера разработки, и парочку эмуляторов, например MacOs и Windows.
Это я к чему, могу посоветовать увеличить объём оперативной памяти.
Интересно, как у Вас получается справляться со всеми задачами с таким лимитированным объёмом памяти в 2019 году?
Есть у меня идейка в закромах чертогов разума, написать похожую статейку про фронтов, в которой, в том числе объяснить и почему у них такие ЗП, спойлер, работают как минимум за 2х.
Касаемо темы, не совсем понял проблематику и как следствие для меня повисло в воздухе и решение.
Не секрет, что индустрия устала от новых технологий, есть предположение, что к любому новому стеку/синтаксису уже будет предвзятое отношение. Исходя из этого, хотелось бы увидеть какие-то сравнения с существующими решениями и доказательства, что Nulm более эффективен. Как он будет выглядеть и вести себя в реальном приложении?
Если же это не цель, то конечно, как творчество, самовыражение и возможная альтернатива, имеет место быть.
Думаю придираться к синтаксису дело не очень благодарное, это вкусовщина, но для меня не совместимость с HTML/CSS является минусом. Это подразумевает более высокий порог вхождения.
В любом случаи, желаю удачи и очень интересно будет понаблюдать за развитием проекта.
Конечно, нужно рассмотреть это случай более подробно, понять в какой ситуации мы решаем проблему именно таким образом. Так же, похоже стоит проговорить точно, я ни в коем случае не стараюсь полностью убрать вёрстку рукам, от сюда и концепция 2-х сторонней связи кода и визуального редактора. То есть если Вам нужно написать такое условие, просто напишите его, в автоматизации оно не нуждается.
Но так же и саму проблему стоит рассмотреть с другого ракурса. Не стоит забывать, что calc это инструмент введённый для помощи верстальщикам, долгое время обходились без него. И большую часть задач, так же можно решить без него. Тут как раз автоматизации и поможет.
У меня есть абсолютно точный запросы и желание проверить гипотезу. Зачем кому-то про это сообщать? Почему бы и нет.
Пользы от этой публикации я получил уже неоценимо много.
Но как бы там ни было, лично для себя я вижу ряд проблем в создании интерфейсов, а как следствие, и приложений. Мои исследования направлены на их формализацию и поиска решений. И если это мне поможет хоть сколько ускорить и оптимизировать мой рабочий процесс, то это уже будет победа.
Как я понимаю, Вас вполне устраивает текущее положение дел.
А не приходилось сталкиваться с тем же Storybook или аналогами?
Я это к тому, что в любом большом приложении будут и правила на структурирование кода, та же организация дизайн системы? Отделение бизнес логики от отображения и тп.
Неужели никогда не хотелось просто взять и подвигать элемент, изменяя его положение? Например, поигравшись с маржингами/шрифтами/другим в инспекторе, чтобы они автоматом применились к коду? Что-то подобное уже когда-то было кстати. Или забросить компонент из библиотеки сразу на экран? Или чтобы изменения, сделанные дизайнером сразу применились к интерфейсу? А как вы решаете вопрос со сложной анимацией?
Опять же, не со всеми Вашими утверждениями согласен, но конечно доказать что-то или переубедить Вас цели у меня нет).
Если это перевести на деньги, да в мировом масштабе, то получиться очень существенная экономия.
Хотя я с Вами конечно не совсем согласен, как один из результатов этой статьи, мне удалось познакомиться с людьми, которые погружены в эту проблему довольно глубоко. Я узнал о существовании ещё большего количества решений именно по созданию разметки, которые просто поражают воображения.
Вопрос в другом, почему они не известны и не пользуются популярностью?
Для этого я описал в 2-х словах, что для меня есть идеальный варианты и постарался определить важные критерии вёрстки.
Есть ли у Вас мысли, чтобы можно ещё добаить или изменить?
Подскажите, какие возникли проблемы с тестированием?
Для того чтобы автоматизировать «сложные с точки зрения дизайна и человеческой логики макеты» нужно более подробно раскрыть тему, формализовать и классифицировать задачи.
Ну и конечно, не стоит стараться достигнуть 100% не участия человека, я думаю это в корни не верный подход.
Как раз для этого и считаю следующий шаг важным — двухсторонняя связь между кодом и графическим отображением. Доказав эти два концепта далее можно уже прорабатывать полее специальные и сложные случаи.
github.com/tonybeltramelli/pix2code или habr.com/ru/post/347120, другое дело, что на мой взгляд это избыточно и что самое важное — плохо контролируемо.
Статья поднимает проблематику современной вёрстки. Как вариант решения, я предлагаю автоматизацию и уже проблемы связанные с ней. Выделяю основную проблему и
далее описываею подход для её решения — построения всего дерева, опуская ряд крайних случаев. Так же в рамках статья я показываю, что описанный подход является работоспособным.
Конечно, если свести всю вёрстку к flexbox и grid, то в этом нет смысла. Но на мой скромный взгляд, тема немного шире, так у нас есть ещё как минимум таблицы, ну и ещё пара другая сотен сущностей с которыми приходится работать верстальщику, как шрифты или градиенты. Также жизненный цикл разметки не заканчивается после создания.
Но конечно я не претендую на истину в финальной инстанции и каждый сам волен для себя решать, что для него является бессмысленным, а что нет.
В концепте очень мало уделил внимание перекрытию, особенно двойному, от сюда и подобный не очень качественный результат. С другой стороны я ещё и усложнил себе задачу, так как совсем не пользовался в концепте информацией о порядке элементов).
Очень полезная и нужная статься, считаю что нужно популяризировать альтернативы дорогим решениям типа redux.
В качестве обратной связи, авторский стиль отталкивает от восприятия информации.
Мне, как фронту часто приходится открывать макеты, нарисованные дизайнером в Figma, зачастую это 4 — 5 одновременных вкладок. На моей машине с 32гб памяти всё работает как часы и я могу ещё запускать IDE, 2 — 3 сервера разработки, и парочку эмуляторов, например MacOs и Windows.
Это я к чему, могу посоветовать увеличить объём оперативной памяти.
Интересно, как у Вас получается справляться со всеми задачами с таким лимитированным объёмом памяти в 2019 году?