Обсуждение итогов года во фронтэнде внезапно стало предметом дискуссии. Добавлю свое мнение, и буду рад услышать мнение других.
Как мне кажется, имеет смысл поговорить о том, что то, что творится в современном вебе, воспринимается снаружи и внутри совершенно иначе. Да и "внутри" имеет несколько уровней. Взгляд "они опять усложняют верстку" с одной стороны абсолютно корректен, а с другой — ошибочен и порочен, но и взгляд "не мешайте нам строить абстракции" тоже неэффективен.
Когда кто-то жалуется на то, что современный веб стал слишком сложным, мне каждый раз хочется напомнить этому человеку, что этому современному вебу он доверяет свои деньги в интернет-банках и формах покупки, личную переписку в социальных сетях и веб-версиях мессенджеров, и личные файлы в облаках. И скорее всего он на самом деле хочет, чтобы процесс разработки этих систем был сложным, тяжелым, но надежным и не дающим сбоев.
Под современным фронтэндом и его друзьями сейчас понимают куда больше, чем кажется со стороны. Это и классические веб-сайты и SPA, и приложения на электроне, и мобильные приложения на cordova, NativeScript, React Native, и даже на Flutter. Это сложная инфраструктура с CDN-ами, геодецентрализованными службами, это чат-боты на JS, и даже инструменты машинного обучения для оптимизации сборки и даже генерации верстки.
А в самом вебе появляются чудовищно сложные решения, которые раньше могли работать исключительно в десктопном режиме. Я сам успел пару лет назад прикоснуться к разработке полноценного браузера генома в браузере — я занимался обеспечением перформанса и 60FPS, что было достаточно большой, но решаемой проблемой. Еще лет 5 назад никто и подумать не мог, что браузер генома мог бы быть не чем-то устанавливаемым на мощный компьютер, а это решение позволило врачам и исследователям работать с геномом даже с планшета или легковесного ноутбука.
Почему?
На данный момент связка HTML+CSS+JS является одной из самых мощных в вопросах построения интерфейсов — не только за счет своих возможностей, но и количества решений, построенных на ней — css-фреймворки, библиотеки визуальных компонент, интерфейсы к огромному количеству сервисов и SAAS. По КПД в часах разработки на потенциальную аудиторию и доступность — веб-технологии опережают и мобильные, и десктопные решения. И сейчас она распалась на целых три направления:
- Разработка полностью статических и около-статических сайтов с частично динамическим контентом (галереи, попапы и так далее)
- Разработка "классических" веб-приложений на серверных фреймворках (django, rails)
- Разработка клиентских веб-приложений
И каждое из них обладает абсолютно отличающейся от других спецификой.
Разработка на JS действительно была болезненной, поэтому начали появляться решения, которые решали эту боль.
Если посмотреть на них, можно увидеть кое-что очень интересное: сначала начали появляться решения вроде jQuery и CoffeeScript, уменьшающие избыточность и многословность языка. Но они быстро угасли, и на их место пришли инструменты, позволяющие максимально эффективно повторно использовать код, статически обнаруживать ошибки, и строить эффективные абстракции, "пряча" отдельные уровни сложности за простыми и хорошо описанными интерфейсами.
Появился GraphQL, решающий проблемы со сложностью описания, документирования и поддержания REST. Появились TypeScript и Flow, которые решали проблемы нехватки типизации. Появились новые сущности языка, позволяющие эффективно работать с асинхронными операциями, классами, потоками данных. Появился WebAssembly, позволяющий переиспользовать код из других языков, и делать это быстро.
Все эти решения направлены на одно и то же: переиспользование кода и потенциал построения "плоских" команд. Они решают проблему с тем, чтобы взять чужой код и начать использовать.
Это явное свидетельство того, что веб развивается в сторону работы в больших командах, он стал платформой для "взрослых" решений.
Еще более явным свидетельством стал ряд событий, произошедший дальше: появились React Native, NativeScript, Dart + Flutter и другие решения для переиспользования кода на нативных платформах. Это очень важный момент: за отсутствием возможности использовать в вебе другие языки, компании начали подстраивать свои процессы в поисках "серебрянной пули", которая им позволит сократить далеко не маленькие затраты на разработку и время на доставку нового функционала до всех клиентов. Любому проекту важно быть быстрым, и специалисты высокого уровня начали объединяться в поисках возможности эффективно работать на JS.
Кстати, по этой же причине начали частично отмирать шаблонизаторы: использование еще одной семантики показало себя менее эффективным, нежели использование знакомого всем HTML с небольшими расширениями на JS (Angular, Vue) или использование просто языка для описания верстки (React, Flutter). Невозможность расширить, необходимость знакомить разработчиков с новым языком, риск отмирания платформы, децентрализованность привели к тому, что начали предпочитать шаблонизаторы фреймворков, которые старались быть как можно ближе к платформам HTML/DOM.
Однако, помимо эффективного написания кода, есть еще и "коэффициент" для синхронизации команды. Если язык позволяет работать сверх-быстро, но при этом синхронизация отдельного функционала между двумя разработчиками создает чудовищную боль, он скорее всего остается нишевым. Поэтому многие возможности языка и решения направлены именно на уменьшение проблем с синхронизацией и отсутствием проблем. Они уменьшают этот "коэффициент", говорящий о том, сколько джуниоров может одновременно контролировать миддл, и сколько миддлов может контролировать ведущий разработчик. Из последних примеров таких возможностей — es6 imports частично решают в том числе проблему циклических зависимостей, а prettier позволяет получить ожидаемый, хорошо поддающийся merge-ам в git-е код вне зависимости от того, как пишет сам разработчик. Он не должен быть красивым, он должен хорошо синхронизироваться.
И в итоге за буквально несколько лет веб как платформа была захвачена большими компаниями и серьезными командами, отчего у большинства случилась "усталость от javascript". Кстати, основная претензия к почти-монополии Google на веб в лице Chromium и заключается в том, что они проталкивают в возможности веб-платформы и JS то, что им нужно (хотя это обычно совпадает с тем, что нужно большинству компаний).
В итоге мы получили с одной стороны совершенно восхитительную платформу для переиспользуемого везде кода, синтаксис, позволяющий работать большими плоскими командами. Но...
Все стало сложно и все запутались
И никто не понимал, что делать. В чем, собственно, проблема? В тех самых трех отличающихся категориях.
- Разработка полностью статических и около-статических сайтов с частично динамическим контентом: для этого типа приложений характерен HTML как точка входа, максимальная скорость загрузки и опциональный JS
- Разработка "классических" веб-приложений на серверных фреймворках (django, rails): для этих решений на данный момент характерна загрузка c HTML как точкой входа, но вместо максимальной скорости загрузки они акцентированы на переиспользовании кода, DRY и интеграции с бэкэндом. JS-код частично сгенерирован фреймворком (нотификации, формы, турбо-ссылки и так далее), частично надо писать самим
- Разработка клиентских веб-приложений. Вот тут происходит неожиданное: HTML вместо точки входа становится одновременно манифестом приложения и платформой рендеринга, а "точкой входа" становится JS.
Что я подразумеваю под точкой входа: это некая сущность, загрузка которой равна минимальной доставке до пользователя продукта. Если пользователю нужно показать информацию, то нам нужен HTML+CSS, если запустить приложение — нужен JS, который запускается из HTML.
И, чтобы запутать всех окончательно — появилась четвертая категория:
Изоморфные приложения
Под "изоморфным" в веб-разработке обычно подразумевают нечто, что работает и на сервере, и на клиенте. В таком режиме умеют работать приложения на react, angular, vue.js, есть готовые фреймворки — Next и Nuxt, например.
Для них актуальны обе задачи: веб-приложение должно и доставлять свое изначальное состояние до пользователя максимально быстро, и выступать в качестве приложения. Иначе говоря, они должны доставить и HTML, и JS как две точки входа, одну для контента, другую для приложения. Это создает два противоречащих параграфа: с одной стороны, объем доставляемых данных должен быть минимальным, с другой — нужно переиспользование кода. Для JS это решается чанками вебпака, code splitting-ом и динамической загрузкой кода, шаблоны уехали в JS, но остается еще CSS. А самое главное — нам хочется не доставлять ни одного лишнего байта пользователю. А потом кому-то в голову все-таки дошла идея: у таких приложений действительно две точки входа. Их можно обрабатывать как две автономных сущности.
Из этого и родилась концепция CSS-in-JS, сфокусированная на двух отдельных процессах: генерации CSS-файла для статического контента, и сохранения стилей рядом с компонентами.
Все уехало в JS.
Теперь в JS можно найти и стили, и верстку, и собственно код.
Теперь все в JS и это хорошо
Стоит сделать еще одно отступление — теперь в продуктовую сторону.
Любому продукту в разработке или развитии важно иметь возможность "перехода" в другую сторону. Это действует на любом из уровней:
Возможность превратить визуальный компонент в компонент с минимальной логикой добавлением строчки кода — это очень круто. Необходимость переписывания его с нуля — не круто.
Дешевое превращение в SPA или в приложение с серверным рендером — это действительно круто, но это очень редко возможно. Разумнее, если это не накладывает издержек, начинать с самого начала с такой платформы.
Поэтому почти любой веб-проект, который имеет риск того, что ему понадобится стать отрисовываемым на сервере, риск того, что придется рефакторить компоненты, переезжать с одного движка шаблонизации на другой — старается убежать от рисков.
Когда есть единая платформа, в рамках которой одни сущности могут превратиться в другие достаточно дешево, разработка осуществляется чертовски быстро.
В случае с приложением на angular/react/vue это именно так. Они сложные в понимании. Не так сложны, как Angular 1, конечно, но все равно — путь к их осознанию долог, и полугодичных онлайн-курсов не хватает для их понимания. Но они дают возможность за несколько часов сделать то, что раньше делалось несколько недель, а за несколько дней — то, что раньше занимало несколько месяцев.
Впрочем, верно и обратное — многим они не нужны, но их используют, потому что "модно".
Когда разговаривают архитектор инфраструктуры группы веб- и мобильных приложений и верстальщик — им будет чертовски тяжело. Сейчас это настолько разные направления, что пересечений по знаниям у них не будет, кроме JS.
Когда вы в следующий раз захотите сказать "веб стал очень сложным и раздутым" — подумайте о том, насколько сложно проектировать и делать почтовый клиент уровня google inbox (с интеллектуальными сущностями, включающимися в зависимости от письма), Web IDE типа Cloud9 или интернет-банк.
Но если к вам придет верстальщик и начнет рассказывать про то, что ему нужен react, потому что ему нужна строгая типизация и декораторы для верстки лэндинга, не поддавайтесь на уговоры.
Комментарии (81)
worldmind
21.12.2018 19:18+1И скорее всего он на самом деле хочет, чтобы процесс разработки этих систем был сложным, тяжелым, но надежным и не дающим сбоев.
нет, он должен быть простым и надёжным, а для этого надо использовать правильные инстурменты, а не делать приложения с помощью технологий созданных для гипертекста.
Вот пример технологии, которую делали люди с пониманием того как оно должно быть.staticlab
21.12.2018 23:47+4Ну да, как же. А вот на сайте, который "Built entirely using enaml-web", даже картинки не ужаты: https://www.codelv.com/projects/ Эти люди точно понимают, как оно должно быть?
И чем, собственно, писать
from web.components.api import * enamldef Index(Html): Head: Title: text = "Hello world" Body: H1: text = "Hello world"
лучше, чем писать гипертекст на языке разметки гипертекста?
<!doctype html> <html> <head> <title>Hello world</title> </head> <body> <h1>Hello world</h1> </body> </html>
Если не нравится многословность, то есть Haml, Pug, Slim...
doctype html html head title Hello world body h1 Hello worldworldmind
22.12.2018 10:03Понятно, что это исследовательские проекты и там всё далеко от идеала, и наверное надо было дать ссылку не на этот проект, в нём действительно не так все хорошо, а на исходный, где подход именно компонентного интерфейса т.е. по сути не должно быть разницы под какую платформу делать приложение — должно быть декларативное описание гуя в терминах компонентов, таблица стилей и код обработки, а реализация под кокретную платформу, в том числе веб, это где-то там, под капотом. Веб не должен быть особой платформой, для этого нет никаких оснований — приложения и приложения, клиент-сервер такой же как везде.
justboris
22.12.2018 12:56Вы сейчас описали архитектуру React. Там тоже есть разделение на платформо-независимое ядро React и отдельные имплементации под платформу:
- react-dom — браузеры
- react-native — мобильные приложения
- react-art — графика на SVG или Canvas
- react-test-renderer – примитивный рендерер для тестирования компонентов
Есть и гайд о том, как написать свой кастомный рендерер. В принципе, все так же, как и в вашем описании, разве что используется Javascript вместо Python, но это уже вкусовщина.
worldmind
22.12.2018 14:04Да, современные фреймворки движутся в этом направлении, это хорошо, но очень уж медленно идёт процесс и плохо, что нет стандартизации, слишком часто всё меняется.
epishman
22.12.2018 10:05Вообще-то идея отказа от XML в пользу JSON не нова, в последнем меньший оверхед на служебную информацию, меньше символов требуют экранирования, проще писать руками, проще читать. Все больше межсетевых интерфейсов слазит с XML и переходят к JSON, следующий логичный шаг — от HTML перейти к какому-нибудь JSON-подобному языку разметки.
DaneSoul
22.12.2018 11:36+2Не факт.
JSON удобен для обмена небольшими блоками информации, но если написать на нем размер средней страницы современной, то в ее коде сложней будет визуально ориентироваться. Наличие закрывающих тегов у блочных элементов это плюс при анализе большой простыни верстки — понятней где что заканчивается.
TimsTims
21.12.2018 21:19+14Мне вообще иногда кажется, что история была такая:
2000 е: Ох уж эти Сшиники! Все их любят, все их ценят, они делают богоподобную работу. А вон там сидят Джависты — у них куча сложнейших объектов, рабочих проектов, куча абстракций, какие вещи они творят! А мы? Чего мы то делаем? Мы сидим и днями и ночами задрачиваем вёрстки на IE6, Opera и Firefox! Вот бы и нас так ценили и уважали как их… А давайте придумаем своих сложных абстракций и инструментов, чтобы тоже резко повысить вход в профессию? Тогда и предложение упадет, и спрос вырастет, и зарплаты подрастут! Кроме глобальных конференций про Java появятся и конференции по нашим выдуманным тулзам! И чтобы постоянно доказывать нашу значимость и сохранять высокий порог входа, мы будем усложнять свои инструменты, делать абстракцию в абстракции, говоря что так всем будет только проще!
/тэг сарказм
staticmain
22.12.2018 12:17Все их любят, все их ценят, они делают богоподобную работу.
Сарказм в сарказме. Когда к нам (к сишникам) из другого отдела перешел сотрудник другие думали что он так шутит и выражали свое презрение.
vyacheslav_ka
22.12.2018 01:11+2Сложно было на ванила скрипт и джейквери сайты делать в один файл с кучей собственно придуманных костылей.
А сейчас благодать, куча фреймворков и инструментов, язык развивается, куча подходов к построению приложений.
ideological
22.12.2018 02:18+3Веб не сложный, просто старый и костыльный. По сути все браузеры вместе с CSS и Javascript и HTML — нужно закопать и забыть, разработав при этом что-то современное.
DaneSoul
22.12.2018 14:24+1И получится как всегда:
uhf
22.12.2018 19:46Да, то ли дело одна современная ОС для мобильных устройств. В ней нужно для каждого сайта скачивать и устанавливать приложение, внутри которого все те же самые код Java
scriptи разметка XHTML. Просто API другое.
Ничего, скоро так будет и в десктопных браузерах. С перспективой внедрения WebAssembly это уже совсем не шутка.
serf
22.12.2018 02:42+1А на вопрос так и не ответили, а все ведь просто. Потому что раньше компьютеры пользователей были слабыми и сессионное состоние пользователя хранилось на сервере/мейнфрейме (в памяти/сессии).
Со временем компьютеры пользователей стали мощнее и инженерные компании решили давайте будем выполнять больше кода на стороне клиента и забивать память у пользоваталей, а не у себя. Так появились SPA приложение и хранение сессионного состояния пользователя уже стало происходить на стороне клиента просто в JavaScript переменных. Ввиду того что на сервере состояние больше не хранится со временем стал моден Rest подход к разработке ендпоинтов и написание типового бэкенда упростилось. Количество веб кода и размер проектов стали быстро расти и пришлось изобретать TypeScript и всякие фреймворки для управления сложностью.
Теперь потролю бэкендеров следующим выводом: хардкорным фронтендерам нужно платить больше чем бекендерам потому что типовой бекенд в наши дни делать проще, а хардкорным фуллстекерам которых мало нужно платить как за троих.Whuthering
22.12.2018 10:16SPA появились, скорее, ради ускорения работы на медленных каналах, чтобы приких-либо действиях пользователя можно было слать ему только изменения, а не всю огромную страницу целиком, и бонусом появилось ускорение работы в медленных браузерах: опять же, нужно перерендерить только фрагмент страницы, а не парсить, дергать контент из кэша и композитить активный документ полностью.
fogx
22.12.2018 13:18+3Правда, сейчас типичный SPA на медленных каналах просто не загружается, а медленные браузеры разработчики вполне целенаправленно отказываются поддерживать, и получается, что сайты десятилетней давности работают быстрее и надеждее, чем современные, «оптимизированные ради ускорения работы».
serf
22.12.2018 13:58Потому что сайты десятилетней давности имеет довольно простой фронтент, там сервер делает отрисовку страниц, хранит состояние сесси и тд. Но это только про начальную загрузку страницы. В случае SPA переход между «страницым» почти не ощущается тк все страницы по сути уже подгружены, нужно только вызвать простой Rest ендпоинт чтобы получить данные для отрисовки в шаблон.
serf
22.12.2018 13:54Рендеринг шаблонов/страниц в наше время это часть SPA функционала, и это стало происходить тоже потому что машины пользователей стали мощнее. В прошлые века отрисовку страниц делали на сервере (и сейчас иногда начальную делают — server side rendering в понятиях SPA).
sumanai
23.12.2018 20:42Только перерисовка всего на JS зачастую медленнее, чем браузер парсит чистый HTML с CSS.
Whuthering
24.12.2018 11:48Это смотря как ее делать.
На заре SPA часто просто через XMLHttpRequest получали кусок HTML-кода, который нужно обновить, и через element.innerHTML= обновляли его целиком.
В таком варианте производится по сути дела точно такой же парсинг чистого HTML.
А уже потом, когда захотелось нормального REST API, валидации на клиенте, сложных интерфейсов, и т.д., тогда уже начали использовать все эти MVC и шаблонизаторы, благо, вычислительные ресурсы стали позволять.
Virviil
22.12.2018 17:05А кому сейчас нужен типовой бэкенд? Тем кому нужен берут какой нибудь firebase и досвидания.
Бэкенд сегодня сильно изменился...
InterceptorTSK
23.12.2018 10:47+1Шта? Кампьютеры пользователей были настолько слабыми, что я им сувал xml-ки в чистом виде, вот прям в наичистейшем виде, которые юзеры открывали прям в браузере, содержащие исключительно и только данные, с поверх навернутыми xslt-шаблонами с вообще любой версткой какой захочу, и html-дерево влет строилось у них на клиентских кампах, причем само, причем само смотрело что за данные и применяло нужный шаблон. Это был насколько помню 2003-2004 год, если не ошибаюсь. И подгружались прочие динамические шматки так же, тока через аякс ессно, но исключительно и только подгружались новые шаблоны, абсолютно понятные для понимания. А то что xslt имел зачатки ооп, и на основе шаблонов можно было влет городить производные шаблоны — про это вообще наверное знают единицы) Сайты строились наура, данные были сами по себе и это было изумительно, шаблоны были идеальные, строилось все на ооп и это было изумительно, верстка вообще никого не колыхала, с верстальщика оно бралось и в шаблоны вставлялось влет. Юзер же получал все это и обрабатывал у себя в итоговый html и это было изумительно.
Это я про то, как оно вообще-то на самом деле все вменяемо начиналось на стороне клиента, и в какое унылое гавно превратилось в итоге.
mistergrim
22.12.2018 05:51Когда кто-то жалуется на то, что современный веб стал слишком сложным, мне каждый раз хочется напомнить этому человеку, что этому современному вебу он доверяет свои деньги в интернет-банках и формах покупки, личную переписку в социальных сетях и веб-версиях мессенджеров, и личные файлы в облаках.
И веб это доверие регулярно «оправдывает».
bro-dev0
22.12.2018 09:17Чтобы сказать, что сложное, а что нет, нужно с чем то сравнивать, было бы круто тогда добавить какую то шкалу и разместить на ней.
worldmind
22.12.2018 10:06сравнивать нужно с разработкой десктопных приложений на современных фреймворках типа qt и др, где например, никому в голову не приходит позиционировать компоненты с помощью таблиц стилей, есть элемент grid, а стили они для стилей.
DaneSoul
22.12.2018 11:54В вебе есть проблемы, которых нет в классическом десктопном приложении — гибкая адаптация под принципиально разные размеры экранов. При этом хочется отзывчивый дизайн, а не переписывание всей верстки три раза под каждый вариант.
Таблицы стилей не плохи для позиционирования, плохо то, что там есть куча разных, зачастую совсем не очевидных, способов сделать одно и тоже позиционирование (float, flexbox, grid). И вот с этим бардаком надо действительно бороться и приводить стандарты к какому-то одному отлаженному решению.worldmind
22.12.2018 11:59Так десктопом сейчас не ограничивается, есть же мобильные платформы, и упомянутый ENAML заявляет переносимость на все платформы, как-то решили эту проблему без всего этого сумасшествия.
DaneSoul
22.12.2018 12:06Хммм…
Enaml style sheets are a powerful feature which allow the developer to customize the visual appearance of a view independent from the view’s structural definition. The concepts and nomenclature used in Enaml style sheets are heavily based on CSS and WPF, but are adapted to the dynamic and declarative world of Enaml.
Developer Guideworldmind
22.12.2018 12:11Да какие таблицы стили сейчас не проектируй они будут похожи на существующие, понятно почему, я так понял based именно в этом смысле.
worldmind
22.12.2018 12:19Хотя не исключаю, что какие-то проблемы переползли, элемента grid когда смотрел не заметил, хотя смотрел бегло.
Хотя вроде там были элементы для группировки, вполне может быть и норм.
DrPass
23.12.2018 04:34-1В вебе есть проблемы, которых нет в классическом десктопном приложении — гибкая адаптация под принципиально разные размеры экранов
Как это нет? Наоборот, десктопные оконные ОС изначально предполагают, что окно вашего приложения может быть вообще любого произвольного размера, и вы должны это учитывать при построении интерфейса. Просто проблема адаптации под принципиально разные размеры окон в десктопных приложениях была решена централизованно и задолго до появления веба. А веб пошел по пути «давайте сейчас будем табличками верстать, потом в будущем как-нибудь поправим». При этом для каких-то востребованных фич у разработчиков стандартов веба не принято вводить новые атрибуты/теги/параметры. Если есть решение, основанное на «грязном хаке», оно будет там жить веками. Как, например, чтобы нарисовать треугольник/уголок, мы все делаем толстый бордер и с одной стороны не закрашиваем. Чтобы сделать в гриде перетекание элементов при изменении размеров окна, такого атрибута CSS тоже нет, достигается с помощью хитрожопого сочетания. И так везде. Такое ощущение, что все эти титулованные ребята, которые придумывают стандарты CSS/HTML, кроме самих стандартов, вообще ничего не пишут.staticlab
23.12.2018 11:47+1Просто проблема адаптации под принципиально разные размеры окон в десктопных приложениях была решена централизованно и задолго до появления веба.
Расскажите об этом централизованном решении.
Как, например, чтобы нарисовать треугольник/уголок, мы все делаем толстый бордер и с одной стороны не закрашиваем.
Нет, треугольничек можно через SVG рисовать.
Чтобы сделать в гриде перетекание элементов при изменении размеров окна, такого атрибута CSS тоже нет
Grid layout это из коробки умеет.
DrPass
23.12.2018 16:14Расскажите об этом централизованном решении.
Оно очень простое — привязки элементов к границам контейнера, якоря, автозаполнение свободного пространства. Всё это неплохо решало проблемы масштабирования в 1990-е годы (если этим пользоваться, конечно). Сейчас, естественно, этого недостаточно — нужна поддержка разных layout'ов и корректное масштабирование шрифтов, чего тогда не было. Но не суть важно, речь была о том, что на десктопе гибкая адаптация под произвольные размеры была всегда, и веб в этом плане страдает не из-за какой-то уникальнйо проблемы, а лишь из-за неудобных инструментов её решения.
Нет, треугольничек можно через SVG рисовать.
Можно. А потом с помощью такой-то матери состыковать с бордером блока, к которому он должен приклеиваться. Адок ещё тот.
Grid layout это из коробки умеет.
Да, как я написал. С помощью хитрожопого сочетания настроек. Чтобы в гриде получилось корректное перетекание элементов, вы должны задать колонкам атрибут auto-fit и выставить ограничение на размеры. То, что оно после этого начинает перетекать, это называется «побочный эффект». А «умеет» — это когда есть атрибут вида «grid-columns-count: auto;»
Это та самая профессиональная деформация. Оно откровенно реализовано через задницу, но мы это воспринимаем как должное, просто потому что многие люди, изначально выросшие на вебе, просто не понимают, как оно может быть иначе, проще и удобнее.staticlab
23.12.2018 21:00Оно очень простое — привязки элементов к границам контейнера, якоря, автозаполнение свободного пространства. Всё это неплохо решало проблемы масштабирования в 1990-е годы (если этим пользоваться, конечно). Сейчас, естественно, этого недостаточно — нужна поддержка разных layout'ов и корректное масштабирование шрифтов
То есть решение давно было, но его недостаточно? Вы сами себе противоречите. Это видно хотя бы потому, что тех средств не хватало для нормальной адаптивности.
А потом с помощью такой-то матери состыковать с бордером блока, к которому он должен приклеиваться.
Стоп. А зачем его приклеивать к бордеру блока? В исходной задаче такого не было.
Да, как я написал. С помощью хитрожопого сочетания настроек. Чтобы в гриде получилось корректное перетекание элементов, вы должны задать колонкам атрибут auto-fit и выставить ограничение на размеры.
Сформулируйте, пожалуйста, точную задачу, потому что вёрстка сильно зависит от того, что вы хотите получить. Сами понимаете.
То, что оно после этого начинает перетекать, это называется «побочный эффект».
Нет. Перетекание в grid layout — это изначально специфицированное поведение.
sumanai
23.12.2018 21:20Перетекание и во float, и в inline-block специфицировано. Но для раскладки подходит не очень.
DrPass
23.12.2018 22:25То есть решение давно было, но его недостаточно? Вы сами себе противоречите.
Ни капли не противоречу. В 90-е годы, про которые я писал, были одни требования, сейчас другие, только и всего. Современные фреймворки для нативной разработки вполне себе им удовлетворяют.
Стоп. А зачем его приклеивать к бордеру блока? В исходной задаче такого не было.
А где вы там вообще «исходную задачу» увидели? Я вам никакую задачу не ставил, я всего лишь упомянул кейс, в котором нужный результат достигается через хитро закрученную задницу. От того, что я недостаточно подробно расписал условия кейса — что имеется в виду не какой-то непонятно зачем нужный отдельно стоящий треугольник, а самый обычный распространенный треугольник для маркировки текстовых блоков, например, в чатах или хинтах, суть не меняется.
Сформулируйте, пожалуйста, точную задачу, потому что вёрстка сильно зависит от того, что вы хотите получить.
Точно так же — хочу получить всего лишь самый популярный вариант расположения блоков, который чаще других вариантов подходит для всяких галерей, списков объектов и т.д… Чтобы они всегда занимали 100% по ширине, масштабируясь в некотором диапазоне, а при дальнейшем изменении ширины экрана перетекали.
staticlab
23.12.2018 01:53+1никому в голову не приходит позиционировать компоненты с помощью таблиц стилей, есть элемент grid
Да, но параметры этого самого grid будут заданы либо в .cpp, либо в .ui (xml). Принципиальной разницы всё равно нет.
worldmind
23.12.2018 14:43Во-первых, если я правильно понимаю, грид и без параметров должен работать, параметры это тюниг.
Во-вторых, понятно, что какие-то параметры где-то всегда будут, вопрос архитектурный, это должны быть параметры компонента, а не стиля.staticlab
23.12.2018 21:01Во-первых, если я правильно понимаю, грид и без параметров должен работать, параметры это тюниг.
А как именно должен работать грид «по дефолту»?
SiliconValleyHobo
22.12.2018 12:14+1Сложно — это написать платформонезависимую вейт-фри структуру данных. Там надо думать
А в вебе надо просто выучить дохрена всего
arvitaly
22.12.2018 12:19Но если к вам придет верстальщик и начнет рассказывать про то, что ему нужен react, потому что ему нужна строгая типизация и декораторы для верстки лэндинга, не поддавайтесь на уговоры.
Не понял, что здесь такого? И почему верстальщик должен рассказывать об инструментах, используемых в работе? Он должен ими уметь пользоваться и работать в срок. И React и строгая типизация очень даже помогают для верстки, с серверным рендерингом, CSS-in-JS, технически стало верстать проще. Да и лэндинг точно так же состоит из компонентов и у грамотного специалиста, эти компоненты всегда под рукой. Готовые фреймворки для сетки, форм, кнопок и т.д. опять же. Например, semantic-ui-react — шикарная вещьDaneSoul
22.12.2018 14:16+2Вполне нормально, когда заказчик определяет стек технологий на котором должен быть выполнен проект.
Если у него простой лендинг, то зачем ему завязываться на навороченный стек технологий специалисты которого стоят на рынке очень не дешево, чтобы потом его поддержка была дороже? Это все равно что в булочную на камазе ездить.arvitaly
22.12.2018 15:27Нормально, полностью согласен, хотя мы вроде говорили о том, когда предлагает специалист, а не заказчик.
Кажется я чего то не понимаю в ваших суждениях. По моей логике, чем дороже специалист, чем дороже его час, тем меньше ему требуется времени на разработку и поддержку. Иначе, какой смысл вообще в дорогостоящих специалистах?
Т.е. если специалист знает весь стек, то и поддержка будет дешевой, так как часов нужно в разы меньше, чем дешевого специалиста.DaneSoul
22.12.2018 16:06Заказчик может быть не совсем чайником, и уж точно может узнать какие технологии доступней на рынке и по какой цене. При этом цели заказчика — работающий проект при минимуме усилий и затрат и цели разработчика — заработать как можно больше, могут не совпадать
Дорогостоящий специалист имеет смысл на серьезный проект, а так, сейчас этот специалист сделает ему визитку на самом навороченном стеке, а потом каждое мелкое изменение, то есть поддержку, будет оценивать в приличную сумму. А дешевый новичок уже эти изменения сделать не сможет, так как там мега-комбайн с кучей взаимозависимостей. Если та же визитка на простом Bootstrap сделана, то какую-то мелочь в ней и обычный админ поверхностно знакомый с веб-разработкой сможет подправить.
Грубо говоря, не надо множить сущности без меры. Если сайт визитка из 3-х страниц, то не надо туда тащить технологии которые разрабатывались для создания огромных порталов и социальных сетей — они слишком громоздки для мелких задач.arvitaly
22.12.2018 16:12Вы описываете не специалиста, а какого-то не очень честного разработчика. Ну да, можно еще трояны в код вставлять, а потом деньги вымогать за ремонт сайта. Вы знаете, для этого не нужен ни навороченный стек, ни дорогостоящий специалист...
DaneSoul
22.12.2018 16:23Дело не в честности.
Программист может работать в качестве машинистки, набирая текст на клавиатуре, но это будет очень дорогая машинистка.
Точно также и тут получается, если задача поправить пару мелочей на странице, то у крутого специалиста это все равно будет намного дороже, чем у новичка, потому что это все равно время: обсудить задачу, подключиться к проекту, найти нужное место и т.п. не интересные и малопродуктивные траты времени, дорогого времени.arvitaly
22.12.2018 17:01С ваших слов, чем человек профессиональнее, тем он хуже для заказчика, медленнее обсуждает задачу, медленнее подключается к проекту и т.д. Поэтому в итоге выходит дороже.
Я с этим абсолютно не согласен, считаю, что именно скорость всего вышеперечисленного и определяет качество специалиста. И да, время профессионала дороже, но на конечную цену это должно влиять только в сторону ее уменьшения, иначе это не профессионал, а зазвездившийся товарищ.DaneSoul
22.12.2018 17:07Я лишь хочу донести, что уровень профессионала и технологий должен соответствовать уровню проекта.
arvitaly
22.12.2018 17:35А я утверждаю, что дело не в технологиях.
Ну не вижу я технических причин долго вносить правки в лендинг, сделанный при помощи даже такого громадного количества слов React + TypeScript + CSS + HTML + Webpack + TSLint + Prettier + SemanticUI + VSCode + Windows/MacOS.
И у меня есть другая догадка, объясняющая ваши сомнения, основанная на собственном опыте. Не все заказчики способны работать с той же скоростью, что и профессионалы. И уровень проекта определяется не технической начинкой стека, а именно «начинкой» заказчика. (*под заказчиком подразумевается не обязательно человек).
Если заказчик, к примеру, требует работать только на удаленном рабочем столе, к которому нужно подключаться через VPN, доступ к которому нужно выпрашивать у админа полдня, через тормозящий интернет 50Кбит/с. Если каждое согласование проходит все ады бюрократии, то, действительно, преимущества профессионала в виде скорости становятся бессмысленными, большую часть времени ему придется сидеть и ждать ответа.
Но это никак не связано со сложностью стека технологий!
balsoft
22.12.2018 15:18Почему веб такой сложный? Потому что
- Нужно поддерживать legacy из 90х годов
- Заказчик требует, чтобы сайт, по функционалу сравнимый с полноценным десктопным приложением, был написан за неделю.
- Потому что есть куча браузеров с разными реализациями
- Как и во всех индустриях, люди, которые меньше всего понимают, кричат громче всех.
- Заказчик требует «Новомодный_фреймворк», значит нужно им пользоваться!
sumanai
23.12.2018 20:47Потому что есть куча браузеров с разными реализациями
Есть сорта Хрома и Firefox. И всё, больше уже ничего не осталось.balsoft
24.12.2018 11:16См. пункт 1 и ужасайтесь. Кому-то критически важно поддерживать IE черт-знает-какой версии, а кому-то наоборот нужен самый свежий Chromium. Хуже всего, если поддержка всего этого ложится на плечи одной команды. Тогда и получаем всяких жутких монстров.
DrPass
24.12.2018 13:05См. пункт 1 и ужасайтесь. Кому-то критически важно поддерживать IE черт-знает-какой версии
Такие есть, но их весьма и весьма немного, думаю, на порядки меньше, чем кривых и корявых веб-проектов.
rsivakov
23.12.2018 02:57www.npmjs.com/package/quokka-script — один из промежуточных итоговр у ребят.
github.com/obitel/fw — когда-то давно была такая задумка (код не нахожу, не помню имя репы)
igor_suhorukov
23.12.2018 15:27Появился GraphQL, решающий проблемы со сложностью описания, документирования и поддержания REST.
IMHO GraphQL больше об агрегации данных, чем об улучшении REST. Является всего лишь подмножеством REST и невозможно использовать HATEOAS в GraphQL.
facetus
23.12.2018 18:45Пост автора ели дочитал, комментарии ближе к сути.
Я как Джун заставший то время и реснулся в это могу сказать, что люди которые говорят, что все это жесткое извращение — реально правы.
Может у меня мало опыта, но примитивным хтмл я и чище и качественней сверстаю, чем Джун используя все извращения...
Уже кто-то написал:
и получается, что сайты десятилетней давности работают быстрее и надеждее, чем современные, «оптимизированные ради ускорения работы»....
Я лично вижу усложнение всего из-за того, что из ксс и хтмл пытаются сделать яп каковыми они не являются… а делают это как раз те кто на прямую не пишет верстку, а лишь программит на её основе… вот и решили мол в баню верстальщиков, сейчас я как придумаю какой нить дроч и буду кодить верстку… это как лопатой и косить и накидывать сено… придумывают мега комбайны для полей размером с палисадник… Все
staticlab
23.12.2018 21:08из ксс и хтмл пытаются сделать яп
Простите, а где и кто? Они как были чисто декларативными и неполными по Тьюрингу, так и остались. JSX и css-in-js — это шаблонизация, как Smarty, Twig, Jinja, ERB, Thymeleaf, Razor.
facetus
23.12.2018 21:34Ну само понятие компиляции из препроцессоров и переменные у меня это вызывает… видимо не приходилось мне сталкиваться с серьезными задачами… х3
Arris
Веб сложный не потому что сложный, а потому что пресловутые «требования бизнеса» требуют, чтобы код/приложение/сайт был написан еще вчера, но вы все еще его пишете.
Чем быстрее написали код/запустили стартап/запилили сайт — тем быстрее (это распространенное заблуждение, потому что не всегда) «отобьются» расходы на этот самый сайт и он «начнет приносить прибыль».
А современный бизнес — это быстрее, быстрее, быстрее, обогнать конкурентов и урвать свою копеечку. Работа не на перспективу, а на сиюминутную прибыль.
В результате погони за скоростью создания того, что раньше делали месяца, а теперь хотят за два дня, сложность инструментов выросла. И чем быстрее надо решить задачу — тем сложнее инструмент, который эту задачу решает и тем больше нужно навыков для овладения этим инструментом. Закономерный процесс, ничего тут не сделаешь.
Ну ничего, сингулярность близко.
P.S.
Ну как-то же личная переписка в социальных сетях и интернет-банки работали 10 лет назад, когда веб был «проще»? :)
P.P.S. Разумеется, это все моё IMHO.
epishman
Выживает простое и легковесное, поэтому большинство фреймворков просто уйдут, а язык JS уже почти хорош, еще немного доработать стандарты — и написать что-то приличное на голом JS будет быстрее, чем вникать в тонкости десятка библиотек.
Arris
Хочется в это верить ;)
DaneSoul
Большинство фреймворков уйдут, но кто-то останется и станет повсеместно используемым, как стандарт де-факто. Поскольку фреймворк — это куча готовых наработок, которые писать с нуля под каждый проект никто не будет.
И это не особенность веба, в игрострое есть Unity и Unreal, например.
Единственное возможное исключение, это гиганты отрасли типа Google и FaceBook, которые могут поддерживать полностью самописную огромную кодовую базу.
Хотя, если посмотреть, то именно они сейчас и являются разработчиками популярных фреймворков и продвигают их в массы:Bootstrap (Twitter), Angular (Google), React (FaceBook)…
epishman
Они нарабатывают «сырец», а потом придет ECMA, и всем расскажет как писать правильно. То же в бизнесе — стартаперы просто используются гигантами для исследования возможностей, а потом остаются только гиганты и стандарты.
DaneSoul
Я просто хотел сказать, что даже самый идеальный и стандартизованный язык все-равно дополнительно требует фреймворков для серьезной работы, потому что фреймворк — это не костыль для языка, а набор шаблонов, библиотек, и т.п. готовых наработок для реальных задач.
Alexufo
Make jQuery Great Again
epishman
Когда я вижу в коде знак доллара, рука тянется к пистолету, а пистолет к виску :)
vanxant
Вы в node_modules давно последний раз заглядывали? Сколько там у вас версий $, штук 5 минимум наверное?)
А то как не копнёшь jq хейтера, так в его поделии внутре бутстрап без кастомизации, и да, jquery-3.3.1.
defaultvoice
Но ведь общепринятое обозначение стримов это <название>$. Вроде user$ или socket$.
potan
Это и с бекенду применимо, но бекенд пока не на столько сложен.
hexploy
Я даже не смог придумать, а на чем может быть основана эта мысль?
potan
На собственном опыте.
andreymal
Работали с проектами уровня хотя бы ВК?
potan
Управление производством зубных коронок подойдет?
И почему в «проектах уровня ВК» бекенд усложняется, а фронтенд нет?
andreymal
Нет
Потому что производству зубных коронок, скорее всего, не требуется обрабатывать 75 тысяч сообщений в секунду со всего мира (не говоря уже об аудио и видео)
(А про фронтенд я ничего не говорил)
DrPass
Рискну предположить, что соотношение числа проектов, которым надо обрабатывать 75 тысяч сообщений в секунду со всего мира, к числу проектов, нагрузка на которые не требует никаких хитрых инженерных решений, составляет примерно 1 к неисчислимому легиону. Так что опыт разработки софта для управления производством зубных коронок вполне себе репрезентативен.
andreymal
Рискну предположить, что у фронтенда соотношение примерно такое же)
DrPass
Моё ИМХО — проблема не в заказчиках, а в платформе. Веб сложный потому, что он изначально вырос из инструментов, которые не предназначались для создания приложений, и год за годом набирал тонны абстракций, каждая из которых тянула груз обратной совместимости. И мы теперь пишем сложнейшие приложения, используя для этого язык разметки текста и разросшийся скриптовый язык, причем не особо эффективный и не особо продуманный. Просто оказавшийся в нужное время в нужном месте.
i360u
В хаотических системах генетические алгоритмы часто бывают эффективнее редукционистского подхода. И это хорошо — это позволяет молодым и гибким конкурировать со старыми и тяжеловесными. Поэтому да, скорость — важнее, потому что достижимая точность предсказаний (оценки перспективы) в быстро-меняющейся среде очень низкая.