Почему веб такой сложный?

    Обсуждение итогов года во фронтэнде внезапно стало предметом дискуссии. Добавлю свое мнение, и буду рад услышать мнение других.


    Как мне кажется, имеет смысл поговорить о том, что то, что творится в современном вебе, воспринимается снаружи и внутри совершенно иначе. Да и "внутри" имеет несколько уровней. Взгляд "они опять усложняют верстку" с одной стороны абсолютно корректен, а с другой — ошибочен и порочен, но и взгляд "не мешайте нам строить абстракции" тоже неэффективен.


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


    image
    источник картинки


    Под современным фронтэндом и его друзьями сейчас понимают куда больше, чем кажется со стороны. Это и классические веб-сайты и 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, потому что ему нужна строгая типизация и декораторы для верстки лэндинга, не поддавайтесь на уговоры.

    Поделиться публикацией

    Комментарии 111

      +17
      Веб сложный не потому что сложный, а потому что пресловутые «требования бизнеса» требуют, чтобы код/приложение/сайт был написан еще вчера, но вы все еще его пишете.

      Чем быстрее написали код/запустили стартап/запилили сайт — тем быстрее (это распространенное заблуждение, потому что не всегда) «отобьются» расходы на этот самый сайт и он «начнет приносить прибыль».

      А современный бизнес — это быстрее, быстрее, быстрее, обогнать конкурентов и урвать свою копеечку. Работа не на перспективу, а на сиюминутную прибыль.

      В результате погони за скоростью создания того, что раньше делали месяца, а теперь хотят за два дня, сложность инструментов выросла. И чем быстрее надо решить задачу — тем сложнее инструмент, который эту задачу решает и тем больше нужно навыков для овладения этим инструментом. Закономерный процесс, ничего тут не сделаешь.

      Ну ничего, сингулярность близко.

      P.S.
      современному вебу он доверяет свои деньги в интернет-банках и формах покупки, личную переписку в социальных сетях и веб-версиях мессенджеров, и личные файлы в облаках.

      Ну как-то же личная переписка в социальных сетях и интернет-банки работали 10 лет назад, когда веб был «проще»? :)

      P.P.S. Разумеется, это все моё IMHO.
        +5
        Выживает простое и легковесное, поэтому большинство фреймворков просто уйдут, а язык JS уже почти хорош, еще немного доработать стандарты — и написать что-то приличное на голом JS будет быстрее, чем вникать в тонкости десятка библиотек.
          +6
          Хочется в это верить ;)
            +3
            Большинство фреймворков уйдут, но кто-то останется и станет повсеместно используемым, как стандарт де-факто. Поскольку фреймворк — это куча готовых наработок, которые писать с нуля под каждый проект никто не будет.
            И это не особенность веба, в игрострое есть Unity и Unreal, например.
            Единственное возможное исключение, это гиганты отрасли типа Google и FaceBook, которые могут поддерживать полностью самописную огромную кодовую базу.
            Хотя, если посмотреть, то именно они сейчас и являются разработчиками популярных фреймворков и продвигают их в массы:Bootstrap (Twitter), Angular (Google), React (FaceBook)…
              0
              Они нарабатывают «сырец», а потом придет ECMA, и всем расскажет как писать правильно. То же в бизнесе — стартаперы просто используются гигантами для исследования возможностей, а потом остаются только гиганты и стандарты.
                +2
                Я просто хотел сказать, что даже самый идеальный и стандартизованный язык все-равно дополнительно требует фреймворков для серьезной работы, потому что фреймворк — это не костыль для языка, а набор шаблонов, библиотек, и т.п. готовых наработок для реальных задач.
              +7
              Make jQuery Great Again
                0
                Когда я вижу в коде знак доллара, рука тянется к пистолету, а пистолет к виску :)
                  +3
                  Вы в node_modules давно последний раз заглядывали? Сколько там у вас версий $, штук 5 минимум наверное?)
                  А то как не копнёшь jq хейтера, так в его поделии внутре бутстрап без кастомизации, и да, jquery-3.3.1.
                    0
                    Но ведь общепринятое обозначение стримов это <название>$. Вроде user$ или socket$.
                      0
                      То есть это единственная причина лютейшего хейта PHP и jQuery у всех? Ясно…
                        +1
                        Про PHP некомпетентен, а jQuery не пользую, ибо нет смысла с новыми стандартами-то. Мы должны быть благодарны библиотекам и фреймворкам JS, что они стимулировали развитие языка. Но пользоваться ими сейчас — не факт.
                          0
                          Понятно, просто сам факт того, что у людей просто как-то нереально бомбит от знака доллара, вот я и пытаюсь установить причину острот на эту тему, то есть как-будто бы знаки доллара тормозят прогресс и развитие языка.
                            0
                            Ну всегда же приятно, когда функции называются простыми и понятными словами, например document.querySelector(). Да, неприятно бить много букв, намного быстрее написать $(), но, блин, потом через несколько лет кто-то будет это все читать. Я даже return лишние расставляю в асинхронном коде — просто чтобы глаз цеплялся за точку выхода.
                              0
                              Позвольте-с, это же все бессмысленная писанина) Да и я не совсем понимаю что значит «кто-то будет это читать»? Это же не собственные конструкции, из-за чего нужно искать написавшего это и спрашивать что он имел ввиду, это базовые лексемы языка, это все-равно что считать что в языке каком-то слова не нужны, на нем же будут говорить, какой ужас)
                    +1
                    Недавно проводил исследование на тему, могу ли я писать компоненты на чистом стандарте (Web Components) и без фреймворка. В итоге все равно пришлось обмазаться дополнительными либами, потому что стандарт не решает большей части проблем. Даже доклад потом прочитал.
                    0
                    Это и с бекенду применимо, но бекенд пока не на столько сложен.
                      +2
                      бекенд пока не на столько сложен.
                      Вот на этих словах я аж чаем подавился.

                      Я даже не смог придумать, а на чем может быть основана эта мысль?
                        0
                        На собственном опыте.
                          –1

                          Работали с проектами уровня хотя бы ВК?

                            +1
                            Управление производством зубных коронок подойдет?
                            И почему в «проектах уровня ВК» бекенд усложняется, а фронтенд нет?
                              –1
                              Управление производством зубных коронок подойдет?

                              Нет


                              И почему в «проектах уровня ВК» бекенд усложняется

                              Потому что производству зубных коронок, скорее всего, не требуется обрабатывать 75 тысяч сообщений в секунду со всего мира (не говоря уже об аудио и видео)


                              (А про фронтенд я ничего не говорил)

                                +1
                                Потому что производству зубных коронок, скорее всего, не требуется обрабатывать 75 тысяч сообщений в секунду со всего мира (не говоря уже об аудио и видео)

                                Рискну предположить, что соотношение числа проектов, которым надо обрабатывать 75 тысяч сообщений в секунду со всего мира, к числу проектов, нагрузка на которые не требует никаких хитрых инженерных решений, составляет примерно 1 к неисчислимому легиону. Так что опыт разработки софта для управления производством зубных коронок вполне себе репрезентативен.
                                  0
                                  Рискну предположить, что у фронтенда соотношение примерно такое же)
                                    0
                                    Фронт энтерпрайзных приложений часто бывает более навороченный, чем интерфейс ВК. Только требования к совместимости обычно более легкие.
                                      0
                                      часто

                                      Рад за ваш опыт, но в моём опыте — редко, зато сложностей на бэкенде хватало даже если до ВК не расти

                                  0
                                  High load — основная сложность в backend?
                                  На моем опыте масштабирование уже достаточно хорошо решенная задача. В какой-то момент приходится отказаться от баз данных с развитыми языками запросов и переходить на noSQL, но с этим можно справиться.
                                    0
                                    На моем опыте масштабирование уже достаточно хорошо решенная задача.

                                    Очень странно, во ВК видимо говнокодеры сидят, что у них задачи на бэкенде нередко занимают кучу времени с миграциями по полгода, о чём они даже завели целый блог на хабре


                                    и переходить на noSQL

                                    То есть фактически переписывать бэкенд почти с нуля


                                    но с этим можно справиться.

                                    И у вас уже есть такой опыт, что вы так смело это утверждаете? Мне вот одного лишь блога ВК уже с лихвой хватает, чтобы сильно сомневаться в подобного вида утверждениях

                        +2
                        Моё ИМХО — проблема не в заказчиках, а в платформе. Веб сложный потому, что он изначально вырос из инструментов, которые не предназначались для создания приложений, и год за годом набирал тонны абстракций, каждая из которых тянула груз обратной совместимости. И мы теперь пишем сложнейшие приложения, используя для этого язык разметки текста и разросшийся скриптовый язык, причем не особо эффективный и не особо продуманный. Просто оказавшийся в нужное время в нужном месте.
                          0

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

                          0
                          И скорее всего он на самом деле хочет, чтобы процесс разработки этих систем был сложным, тяжелым, но надежным и не дающим сбоев.

                          нет, он должен быть простым и надёжным, а для этого надо использовать правильные инстурменты, а не делать приложения с помощью технологий созданных для гипертекста.
                          Вот пример технологии, которую делали люди с пониманием того как оно должно быть.
                            +9

                            Ну да, как же. А вот на сайте, который "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 world
                              0
                              Понятно, что это исследовательские проекты и там всё далеко от идеала, и наверное надо было дать ссылку не на этот проект, в нём действительно не так все хорошо, а на исходный, где подход именно компонентного интерфейса т.е. по сути не должно быть разницы под какую платформу делать приложение — должно быть декларативное описание гуя в терминах компонентов, таблица стилей и код обработки, а реализация под кокретную платформу, в том числе веб, это где-то там, под капотом. Веб не должен быть особой платформой, для этого нет никаких оснований — приложения и приложения, клиент-сервер такой же как везде.
                                +2

                                Вы сейчас описали архитектуру React. Там тоже есть разделение на платформо-независимое ядро React и отдельные имплементации под платформу:


                                • react-dom — браузеры
                                • react-native — мобильные приложения
                                • react-art — графика на SVG или Canvas
                                • react-test-renderer – примитивный рендерер для тестирования компонентов

                                Есть и гайд о том, как написать свой кастомный рендерер. В принципе, все так же, как и в вашем описании, разве что используется Javascript вместо Python, но это уже вкусовщина.

                                  0
                                  Да, современные фреймворки движутся в этом направлении, это хорошо, но очень уж медленно идёт процесс и плохо, что нет стандартизации, слишком часто всё меняется.
                                0
                                Вообще-то идея отказа от XML в пользу JSON не нова, в последнем меньший оверхед на служебную информацию, меньше символов требуют экранирования, проще писать руками, проще читать. Все больше межсетевых интерфейсов слазит с XML и переходят к JSON, следующий логичный шаг — от HTML перейти к какому-нибудь JSON-подобному языку разметки.
                                  +3
                                  Не факт.
                                  JSON удобен для обмена небольшими блоками информации, но если написать на нем размер средней страницы современной, то в ее коде сложней будет визуально ориентироваться. Наличие закрывающих тегов у блочных элементов это плюс при анализе большой простыни верстки — понятней где что заканчивается.
                                    0
                                    Возможно, хотя зависит от редактора. Мой SublimeText умеет даже ад колбэков представить в удобном виде, вложения в 10 уровней читаютя отлично.
                                      0
                                      А мой дефолтный этого не умеет. Не продемонстрируете пример, чтобы понять о чем речь?
                              +30
                              Мне вообще иногда кажется, что история была такая:
                              2000 е: Ох уж эти Сшиники! Все их любят, все их ценят, они делают богоподобную работу. А вон там сидят Джависты — у них куча сложнейших объектов, рабочих проектов, куча абстракций, какие вещи они творят! А мы? Чего мы то делаем? Мы сидим и днями и ночами задрачиваем вёрстки на IE6, Opera и Firefox! Вот бы и нас так ценили и уважали как их… А давайте придумаем своих сложных абстракций и инструментов, чтобы тоже резко повысить вход в профессию? Тогда и предложение упадет, и спрос вырастет, и зарплаты подрастут! Кроме глобальных конференций про Java появятся и конференции по нашим выдуманным тулзам! И чтобы постоянно доказывать нашу значимость и сохранять высокий порог входа, мы будем усложнять свои инструменты, делать абстракцию в абстракции, говоря что так всем будет только проще!
                              /тэг сарказм
                                +11
                                И пригласили Сишника им это всё реализовать…
                                  +2
                                  Все их любят, все их ценят, они делают богоподобную работу.


                                  Сарказм в сарказме. Когда к нам (к сишникам) из другого отдела перешел сотрудник другие думали что он так шутит и выражали свое презрение.
                                  +2
                                  Сложно было на ванила скрипт и джейквери сайты делать в один файл с кучей собственно придуманных костылей.
                                  А сейчас благодать, куча фреймворков и инструментов, язык развивается, куча подходов к построению приложений.
                                    +9
                                    Веб не сложный, просто старый и костыльный. По сути все браузеры вместе с CSS и Javascript и HTML — нужно закопать и забыть, разработав при этом что-то современное.
                                      +6
                                      И получится как всегда:
                                      image
                                        +3
                                        Да, то ли дело одна современная ОС для мобильных устройств. В ней нужно для каждого сайта скачивать и устанавливать приложение, внутри которого все те же самые код Javascript и разметка XHTML. Просто API другое.
                                        Ничего, скоро так будет и в десктопных браузерах. С перспективой внедрения WebAssembly это уже совсем не шутка.
                                        +4
                                        А на вопрос так и не ответили, а все ведь просто. Потому что раньше компьютеры пользователей были слабыми и сессионное состоние пользователя хранилось на сервере/мейнфрейме (в памяти/сессии).

                                        Со временем компьютеры пользователей стали мощнее и инженерные компании решили давайте будем выполнять больше кода на стороне клиента и забивать память у пользоваталей, а не у себя. Так появились SPA приложение и хранение сессионного состояния пользователя уже стало происходить на стороне клиента просто в JavaScript переменных. Ввиду того что на сервере состояние больше не хранится со временем стал моден Rest подход к разработке ендпоинтов и написание типового бэкенда упростилось. Количество веб кода и размер проектов стали быстро расти и пришлось изобретать TypeScript и всякие фреймворки для управления сложностью.

                                        Теперь потролю бэкендеров следующим выводом: хардкорным фронтендерам нужно платить больше чем бекендерам потому что типовой бекенд в наши дни делать проще, а хардкорным фуллстекерам которых мало нужно платить как за троих.
                                          0

                                          SPA появились, скорее, ради ускорения работы на медленных каналах, чтобы приких-либо действиях пользователя можно было слать ему только изменения, а не всю огромную страницу целиком, и бонусом появилось ускорение работы в медленных браузерах: опять же, нужно перерендерить только фрагмент страницы, а не парсить, дергать контент из кэша и композитить активный документ полностью.

                                            +5
                                            Правда, сейчас типичный SPA на медленных каналах просто не загружается, а медленные браузеры разработчики вполне целенаправленно отказываются поддерживать, и получается, что сайты десятилетней давности работают быстрее и надеждее, чем современные, «оптимизированные ради ускорения работы».
                                              +1
                                              Потому что сайты десятилетней давности имеет довольно простой фронтент, там сервер делает отрисовку страниц, хранит состояние сесси и тд. Но это только про начальную загрузку страницы. В случае SPA переход между «страницым» почти не ощущается тк все страницы по сути уже подгружены, нужно только вызвать простой Rest ендпоинт чтобы получить данные для отрисовки в шаблон.
                                                0
                                                Все потому, что изначально задуманные веб-страницы «внизапна» стали не веб-страницами, а веб-приложениями.

                                                Перетягивание одеяла от клиента к серверу было и будет: сначала были мейнфреймы с терминалами, каждое нажатие клавиши обрабатывалось «на сервере» и (т е на мейнфрейме) и передавалось на него, когда появились персоналки, то все, включая вычисления, перетекло на «клиент» (в связи с возросшей его мощностью), а по сетям гонялись только общие данные.

                                                Потом появился интернет и браузеры, и начато было с того же — клиент фактически голый и ничего не умеет, зато «централизация». Потом клиент начал обрастать и обрастать, вспомогательный встроенный скриптовой язык стали использовать не для простых визуальных эффектов, а для построения той или иной логики, опять же, все уменьшая и уменьшая роль сервера и обмен данными с клиентом.

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

                                                Ну и из-за обратной совместимости все эти фреймворки все равно всего лишь генераторы того самого изначально не предназначенного для таких целей js, что и дает такую сложность всей картины.
                                                  0
                                                  Вы мое сообщение поторяете :) чуть выше которое.
                                              0
                                              Рендеринг шаблонов/страниц в наше время это часть SPA функционала, и это стало происходить тоже потому что машины пользователей стали мощнее. В прошлые века отрисовку страниц делали на сервере (и сейчас иногда начальную делают — server side rendering в понятиях SPA).
                                                0
                                                Только перерисовка всего на JS зачастую медленнее, чем браузер парсит чистый HTML с CSS.
                                                  0
                                                  Это смотря как ее делать.
                                                  На заре SPA часто просто через XMLHttpRequest получали кусок HTML-кода, который нужно обновить, и через element.innerHTML= обновляли его целиком.
                                                  В таком варианте производится по сути дела точно такой же парсинг чистого HTML.
                                                  А уже потом, когда захотелось нормального REST API, валидации на клиенте, сложных интерфейсов, и т.д., тогда уже начали использовать все эти MVC и шаблонизаторы, благо, вычислительные ресурсы стали позволять.
                                                0

                                                А кому сейчас нужен типовой бэкенд? Тем кому нужен берут какой нибудь firebase и досвидания.
                                                Бэкенд сегодня сильно изменился...

                                                  +1
                                                  Шта? Кампьютеры пользователей были настолько слабыми, что я им сувал xml-ки в чистом виде, вот прям в наичистейшем виде, которые юзеры открывали прям в браузере, содержащие исключительно и только данные, с поверх навернутыми xslt-шаблонами с вообще любой версткой какой захочу, и html-дерево влет строилось у них на клиентских кампах, причем само, причем само смотрело что за данные и применяло нужный шаблон. Это был насколько помню 2003-2004 год, если не ошибаюсь. И подгружались прочие динамические шматки так же, тока через аякс ессно, но исключительно и только подгружались новые шаблоны, абсолютно понятные для понимания. А то что xslt имел зачатки ооп, и на основе шаблонов можно было влет городить производные шаблоны — про это вообще наверное знают единицы) Сайты строились наура, данные были сами по себе и это было изумительно, шаблоны были идеальные, строилось все на ооп и это было изумительно, верстка вообще никого не колыхала, с верстальщика оно бралось и в шаблоны вставлялось влет. Юзер же получал все это и обрабатывал у себя в итоговый html и это было изумительно.
                                                  Это я про то, как оно вообще-то на самом деле все вменяемо начиналось на стороне клиента, и в какое унылое гавно превратилось в итоге.
                                                  +3
                                                  Когда кто-то жалуется на то, что современный веб стал слишком сложным, мне каждый раз хочется напомнить этому человеку, что этому современному вебу он доверяет свои деньги в интернет-банках и формах покупки, личную переписку в социальных сетях и веб-версиях мессенджеров, и личные файлы в облаках.
                                                  И веб это доверие регулярно «оправдывает».
                                                    0
                                                    Чтобы сказать, что сложное, а что нет, нужно с чем то сравнивать, было бы круто тогда добавить какую то шкалу и разместить на ней.
                                                      +3
                                                      сравнивать нужно с разработкой десктопных приложений на современных фреймворках типа qt и др, где например, никому в голову не приходит позиционировать компоненты с помощью таблиц стилей, есть элемент grid, а стили они для стилей.
                                                        0
                                                        В вебе есть проблемы, которых нет в классическом десктопном приложении — гибкая адаптация под принципиально разные размеры экранов. При этом хочется отзывчивый дизайн, а не переписывание всей верстки три раза под каждый вариант.
                                                        Таблицы стилей не плохи для позиционирования, плохо то, что там есть куча разных, зачастую совсем не очевидных, способов сделать одно и тоже позиционирование (float, flexbox, grid). И вот с этим бардаком надо действительно бороться и приводить стандарты к какому-то одному отлаженному решению.
                                                          0
                                                          Так десктопом сейчас не ограничивается, есть же мобильные платформы, и упомянутый ENAML заявляет переносимость на все платформы, как-то решили эту проблему без всего этого сумасшествия.
                                                            0
                                                            Хммм…
                                                            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 Guide
                                                              0
                                                              Да какие таблицы стили сейчас не проектируй они будут похожи на существующие, понятно почему, я так понял based именно в этом смысле.
                                                                0
                                                                Хотя не исключаю, что какие-то проблемы переползли, элемента grid когда смотрел не заметил, хотя смотрел бегло.
                                                                Хотя вроде там были элементы для группировки, вполне может быть и норм.
                                                              0
                                                              В вебе есть проблемы, которых нет в классическом десктопном приложении — гибкая адаптация под принципиально разные размеры экранов

                                                              Как это нет? Наоборот, десктопные оконные ОС изначально предполагают, что окно вашего приложения может быть вообще любого произвольного размера, и вы должны это учитывать при построении интерфейса. Просто проблема адаптации под принципиально разные размеры окон в десктопных приложениях была решена централизованно и задолго до появления веба. А веб пошел по пути «давайте сейчас будем табличками верстать, потом в будущем как-нибудь поправим». При этом для каких-то востребованных фич у разработчиков стандартов веба не принято вводить новые атрибуты/теги/параметры. Если есть решение, основанное на «грязном хаке», оно будет там жить веками. Как, например, чтобы нарисовать треугольник/уголок, мы все делаем толстый бордер и с одной стороны не закрашиваем. Чтобы сделать в гриде перетекание элементов при изменении размеров окна, такого атрибута CSS тоже нет, достигается с помощью хитрожопого сочетания. И так везде. Такое ощущение, что все эти титулованные ребята, которые придумывают стандарты CSS/HTML, кроме самих стандартов, вообще ничего не пишут.
                                                                +2
                                                                Просто проблема адаптации под принципиально разные размеры окон в десктопных приложениях была решена централизованно и задолго до появления веба.

                                                                Расскажите об этом централизованном решении.


                                                                Как, например, чтобы нарисовать треугольник/уголок, мы все делаем толстый бордер и с одной стороны не закрашиваем.

                                                                Нет, треугольничек можно через SVG рисовать.


                                                                Чтобы сделать в гриде перетекание элементов при изменении размеров окна, такого атрибута CSS тоже нет

                                                                Grid layout это из коробки умеет.

                                                                  0
                                                                  Расскажите об этом централизованном решении.

                                                                  Оно очень простое — привязки элементов к границам контейнера, якоря, автозаполнение свободного пространства. Всё это неплохо решало проблемы масштабирования в 1990-е годы (если этим пользоваться, конечно). Сейчас, естественно, этого недостаточно — нужна поддержка разных layout'ов и корректное масштабирование шрифтов, чего тогда не было. Но не суть важно, речь была о том, что на десктопе гибкая адаптация под произвольные размеры была всегда, и веб в этом плане страдает не из-за какой-то уникальнйо проблемы, а лишь из-за неудобных инструментов её решения.
                                                                  Нет, треугольничек можно через SVG рисовать.

                                                                  Можно. А потом с помощью такой-то матери состыковать с бордером блока, к которому он должен приклеиваться. Адок ещё тот.
                                                                  Grid layout это из коробки умеет.

                                                                  Да, как я написал. С помощью хитрожопого сочетания настроек. Чтобы в гриде получилось корректное перетекание элементов, вы должны задать колонкам атрибут auto-fit и выставить ограничение на размеры. То, что оно после этого начинает перетекать, это называется «побочный эффект». А «умеет» — это когда есть атрибут вида «grid-columns-count: auto;»
                                                                  Это та самая профессиональная деформация. Оно откровенно реализовано через задницу, но мы это воспринимаем как должное, просто потому что многие люди, изначально выросшие на вебе, просто не понимают, как оно может быть иначе, проще и удобнее.
                                                                    0
                                                                    Оно очень простое — привязки элементов к границам контейнера, якоря, автозаполнение свободного пространства. Всё это неплохо решало проблемы масштабирования в 1990-е годы (если этим пользоваться, конечно). Сейчас, естественно, этого недостаточно — нужна поддержка разных layout'ов и корректное масштабирование шрифтов

                                                                    То есть решение давно было, но его недостаточно? Вы сами себе противоречите. Это видно хотя бы потому, что тех средств не хватало для нормальной адаптивности.


                                                                    А потом с помощью такой-то матери состыковать с бордером блока, к которому он должен приклеиваться.

                                                                    Стоп. А зачем его приклеивать к бордеру блока? В исходной задаче такого не было.


                                                                    Да, как я написал. С помощью хитрожопого сочетания настроек. Чтобы в гриде получилось корректное перетекание элементов, вы должны задать колонкам атрибут auto-fit и выставить ограничение на размеры.

                                                                    Сформулируйте, пожалуйста, точную задачу, потому что вёрстка сильно зависит от того, что вы хотите получить. Сами понимаете.


                                                                    То, что оно после этого начинает перетекать, это называется «побочный эффект».

                                                                    Нет. Перетекание в grid layout — это изначально специфицированное поведение.

                                                                      0
                                                                      Перетекание и во float, и в inline-block специфицировано. Но для раскладки подходит не очень.
                                                                        0
                                                                        То есть решение давно было, но его недостаточно? Вы сами себе противоречите.

                                                                        Ни капли не противоречу. В 90-е годы, про которые я писал, были одни требования, сейчас другие, только и всего. Современные фреймворки для нативной разработки вполне себе им удовлетворяют.
                                                                        Стоп. А зачем его приклеивать к бордеру блока? В исходной задаче такого не было.

                                                                        А где вы там вообще «исходную задачу» увидели? Я вам никакую задачу не ставил, я всего лишь упомянул кейс, в котором нужный результат достигается через хитро закрученную задницу. От того, что я недостаточно подробно расписал условия кейса — что имеется в виду не какой-то непонятно зачем нужный отдельно стоящий треугольник, а самый обычный распространенный треугольник для маркировки текстовых блоков, например, в чатах или хинтах, суть не меняется.
                                                                        Сформулируйте, пожалуйста, точную задачу, потому что вёрстка сильно зависит от того, что вы хотите получить.

                                                                        Точно так же — хочу получить всего лишь самый популярный вариант расположения блоков, который чаще других вариантов подходит для всяких галерей, списков объектов и т.д… Чтобы они всегда занимали 100% по ширине, масштабируясь в некотором диапазоне, а при дальнейшем изменении ширины экрана перетекали.
                                                                +2
                                                                никому в голову не приходит позиционировать компоненты с помощью таблиц стилей, есть элемент grid

                                                                Да, но параметры этого самого grid будут заданы либо в .cpp, либо в .ui (xml). Принципиальной разницы всё равно нет.

                                                                  0
                                                                  Во-первых, если я правильно понимаю, грид и без параметров должен работать, параметры это тюниг.
                                                                  Во-вторых, понятно, что какие-то параметры где-то всегда будут, вопрос архитектурный, это должны быть параметры компонента, а не стиля.
                                                                    0
                                                                    Во-первых, если я правильно понимаю, грид и без параметров должен работать, параметры это тюниг.

                                                                    А как именно должен работать грид «по дефолту»?

                                                                      0
                                                                      Размещать элементы как указано и переносить их при очень малых размерах экрана.
                                                                        +1

                                                                        Как указано — это уже не дефолт.

                                                              +2

                                                              Сложно — это написать платформонезависимую вейт-фри структуру данных. Там надо думать
                                                              А в вебе надо просто выучить дохрена всего

                                                                +1
                                                                Но если к вам придет верстальщик и начнет рассказывать про то, что ему нужен react, потому что ему нужна строгая типизация и декораторы для верстки лэндинга, не поддавайтесь на уговоры.

                                                                Не понял, что здесь такого? И почему верстальщик должен рассказывать об инструментах, используемых в работе? Он должен ими уметь пользоваться и работать в срок. И React и строгая типизация очень даже помогают для верстки, с серверным рендерингом, CSS-in-JS, технически стало верстать проще. Да и лэндинг точно так же состоит из компонентов и у грамотного специалиста, эти компоненты всегда под рукой. Готовые фреймворки для сетки, форм, кнопок и т.д. опять же. Например, semantic-ui-react — шикарная вещь
                                                                  +2
                                                                  Вполне нормально, когда заказчик определяет стек технологий на котором должен быть выполнен проект.
                                                                  Если у него простой лендинг, то зачем ему завязываться на навороченный стек технологий специалисты которого стоят на рынке очень не дешево, чтобы потом его поддержка была дороже? Это все равно что в булочную на камазе ездить.
                                                                    –1
                                                                    Нормально, полностью согласен, хотя мы вроде говорили о том, когда предлагает специалист, а не заказчик.
                                                                    Кажется я чего то не понимаю в ваших суждениях. По моей логике, чем дороже специалист, чем дороже его час, тем меньше ему требуется времени на разработку и поддержку. Иначе, какой смысл вообще в дорогостоящих специалистах?
                                                                    Т.е. если специалист знает весь стек, то и поддержка будет дешевой, так как часов нужно в разы меньше, чем дешевого специалиста.
                                                                      +1
                                                                      Заказчик может быть не совсем чайником, и уж точно может узнать какие технологии доступней на рынке и по какой цене. При этом цели заказчика — работающий проект при минимуме усилий и затрат и цели разработчика — заработать как можно больше, могут не совпадать

                                                                      Дорогостоящий специалист имеет смысл на серьезный проект, а так, сейчас этот специалист сделает ему визитку на самом навороченном стеке, а потом каждое мелкое изменение, то есть поддержку, будет оценивать в приличную сумму. А дешевый новичок уже эти изменения сделать не сможет, так как там мега-комбайн с кучей взаимозависимостей. Если та же визитка на простом Bootstrap сделана, то какую-то мелочь в ней и обычный админ поверхностно знакомый с веб-разработкой сможет подправить.

                                                                      Да и в целом, чем больше технологий задействовано в проекте, тем дольше и соответственно дороже его собрать в рабочее состояние, натроить все зависимости и т.п…
                                                                      Для сложных проектов это оправданная необходимость, которая будет экономить время на решение дальнейших сложных задач, а для сайта-визитки это лишние затраты ничем не обоснованные.

                                                                      Грубо говоря, не надо множить сущности без меры. Если сайт визитка из 3-х страниц, то не надо туда тащить технологии которые разрабатывались для создания огромных порталов и социальных сетей — они слишком громоздки для мелких задач.
                                                                        0

                                                                        Вы описываете не специалиста, а какого-то не очень честного разработчика. Ну да, можно еще трояны в код вставлять, а потом деньги вымогать за ремонт сайта. Вы знаете, для этого не нужен ни навороченный стек, ни дорогостоящий специалист...

                                                                          +1
                                                                          Дело не в честности.
                                                                          Программист может работать в качестве машинистки, набирая текст на клавиатуре, но это будет очень дорогая машинистка.
                                                                          Точно также и тут получается, если задача поправить пару мелочей на странице, то у крутого специалиста это все равно будет намного дороже, чем у новичка, потому что это все равно время: обсудить задачу, подключиться к проекту, найти нужное место и т.п. не интересные и малопродуктивные траты времени, дорогого времени.
                                                                            +1
                                                                            С ваших слов, чем человек профессиональнее, тем он хуже для заказчика, медленнее обсуждает задачу, медленнее подключается к проекту и т.д. Поэтому в итоге выходит дороже.
                                                                            Я с этим абсолютно не согласен, считаю, что именно скорость всего вышеперечисленного и определяет качество специалиста. И да, время профессионала дороже, но на конечную цену это должно влиять только в сторону ее уменьшения, иначе это не профессионал, а зазвездившийся товарищ.
                                                                              0
                                                                              Я лишь хочу донести, что уровень профессионала и технологий должен соответствовать уровню проекта.
                                                                                0
                                                                                А я утверждаю, что дело не в технологиях.
                                                                                Ну не вижу я технических причин долго вносить правки в лендинг, сделанный при помощи даже такого громадного количества слов React + TypeScript + CSS + HTML + Webpack + TSLint + Prettier + SemanticUI + VSCode + Windows/MacOS.

                                                                                И у меня есть другая догадка, объясняющая ваши сомнения, основанная на собственном опыте. Не все заказчики способны работать с той же скоростью, что и профессионалы. И уровень проекта определяется не технической начинкой стека, а именно «начинкой» заказчика. (*под заказчиком подразумевается не обязательно человек).

                                                                                Если заказчик, к примеру, требует работать только на удаленном рабочем столе, к которому нужно подключаться через VPN, доступ к которому нужно выпрашивать у админа полдня, через тормозящий интернет 50Кбит/с. Если каждое согласование проходит все ады бюрократии, то, действительно, преимущества профессионала в виде скорости становятся бессмысленными, большую часть времени ему придется сидеть и ждать ответа.
                                                                                Но это никак не связано со сложностью стека технологий!
                                                                                  0

                                                                                  Все гораздо проще.
                                                                                  Если, например, итоговую верстку надо будет интегрировать в проект на джанго или чем-то еще похуже без участия автора, то верстальщика, не способного отгрузить верстку в формате, который либо нечитаем, либо не поддерживает интеграцию с фреймворком без дополнительного тулинга, будут ненавидеть.


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

                                                                  +3
                                                                  Почему веб такой сложный? Потому что
                                                                  1. Нужно поддерживать legacy из 90х годов
                                                                  2. Заказчик требует, чтобы сайт, по функционалу сравнимый с полноценным десктопным приложением, был написан за неделю.
                                                                  3. Потому что есть куча браузеров с разными реализациями
                                                                  4. Как и во всех индустриях, люди, которые меньше всего понимают, кричат громче всех.
                                                                  5. Заказчик требует «Новомодный_фреймворк», значит нужно им пользоваться!
                                                                    0
                                                                    Потому что есть куча браузеров с разными реализациями

                                                                    Есть сорта Хрома и Firefox. И всё, больше уже ничего не осталось.
                                                                      0
                                                                      См. пункт 1 и ужасайтесь. Кому-то критически важно поддерживать IE черт-знает-какой версии, а кому-то наоборот нужен самый свежий Chromium. Хуже всего, если поддержка всего этого ложится на плечи одной команды. Тогда и получаем всяких жутких монстров.
                                                                        0
                                                                        См. пункт 1 и ужасайтесь. Кому-то критически важно поддерживать IE черт-знает-какой версии

                                                                        Такие есть, но их весьма и весьма немного, думаю, на порядки меньше, чем кривых и корявых веб-проектов.
                                                                      0

                                                                      Я вам очень сочувствую и советую найти другую компанию, где не занимаются воплощением безумных хотелок заказчика, а взаимодействуют конкретно с бизнесом по time & materials, либо занимаются внутренней разработкой. Там, к счастью, есть понимание сложности и сроков разработки, цены поддержки старых платформ (она гигантская), и есть люди, умеющие напомнить заказчику, что ему нужен веб-сервис, который приносит деньги, а не повод для хвастовства про технологии.


                                                                      P.S. в моей практике случалось требование технологии (причем в формате "бан на технологию") во фронтэнде только единожды, причем по юридической причине.

                                                                        0
                                                                        React и его история с файлом Patents?
                                                                          +1

                                                                          Нет, не это. К сожалению, не считаю этичным рассказывать подробности и описывать что-то конкретное.


                                                                          Если говорить совсем абстрактно — был риск примерно той же истории, что была с ReactOS, когда слили исходники винды — им все пришлось провести аудит всего кода, чтобы убедиться, что ничего не скопировано/не переписано из исходников винды, решили, что проще на всякий случай отказаться от технологий.


                                                                          В итоге под запретом был конкретный технологический стек. Приятно было то, что он в основном был весьма "ретро", поэтому все с радостью выдохнули, узнав, что не надо будет мучиться с старьем. В случае с фронтом был запрет на ангуляр 1, ну и "на всякий случай" на ангуляр 2 и выше.

                                                                      0
                                                                      www.npmjs.com/package/quokka-script — один из промежуточных итоговр у ребят.

                                                                      github.com/obitel/fw — когда-то давно была такая задумка (код не нахожу, не помню имя репы)
                                                                        0
                                                                        Появился GraphQL, решающий проблемы со сложностью описания, документирования и поддержания REST.

                                                                        IMHO GraphQL больше об агрегации данных, чем об улучшении REST. Является всего лишь подмножеством REST и невозможно использовать HATEOAS в GraphQL.
                                                                          0

                                                                          GraphQL является просто другим уровнем по OSI. Он может работать поверх хоть REST, хоть WebSockets, хоть голого TCP по факту, но наиболее частое использование поверх rest-а, это правда.
                                                                          Он решает проблемы, которые накладывали глаголы REST, потому что стандартных действий get-post-put-delete в общем случае недостаточно, решает проблемы с описательными возможностями get-запросов, и проблемой с необходимостью запроса одной сущности с разными "линзами", и бонусом дает решение огромной кучи проблем с кэшированием (но не всех, да).


                                                                          К сожалению, HATEOAS вживую нигде не встречал, не могу понять его плюсы и прокомментировать.

                                                                          0

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


                                                                          Уже кто-то написал:
                                                                          и получается, что сайты десятилетней давности работают быстрее и надеждее, чем современные, «оптимизированные ради ускорения работы»....


                                                                          Я лично вижу усложнение всего из-за того, что из ксс и хтмл пытаются сделать яп каковыми они не являются… а делают это как раз те кто на прямую не пишет верстку, а лишь программит на её основе… вот и решили мол в баню верстальщиков, сейчас я как придумаю какой нить дроч и буду кодить верстку… это как лопатой и косить и накидывать сено… придумывают мега комбайны для полей размером с палисадник… Все

                                                                            +1
                                                                            из ксс и хтмл пытаются сделать яп

                                                                            Простите, а где и кто? Они как были чисто декларативными и неполными по Тьюрингу, так и остались. JSX и css-in-js — это шаблонизация, как Smarty, Twig, Jinja, ERB, Thymeleaf, Razor.

                                                                              0
                                                                              Ну само понятие компиляции из препроцессоров и переменные у меня это вызывает… видимо не приходилось мне сталкиваться с серьезными задачами… х3
                                                                                +2

                                                                                Ну то есть один раз задать в переменных цвета или размеры и пользоваться во всех стилях — это костыли, а правильные пацаны мужественно инлайнят их вручную?

                                                                              0

                                                                              Могу еще раз, но простым языком — все фронтэндеры мнят себя дохрена инженерами и хотят закладывать возможности "по-максимуму", поэтому те инструменты, которые решают 20% самых сложных задач, и выглядят круто, но которыми надо уметь пользоваться и контролировать, тащат к себе абсолютно все, чтобы потом на митапах хвастаться. А остальная часть поста — это про то, из чего эти 20% задач состоят, и почему оставшимся инженерам они важны.

                                                                              +1
                                                                              Ну не знаю… по-моему веб не сложный. Для меня сложно, это когда говоришь iOS программисту, сделай, плиз, чтобы вот этот компонент работал чуть по-другому. А он такой, сорян босс, но встроенный компонент такое не поддерживает, поэтому надо писать кастомный, неделя минимум. И ты такой, :facepalm:, потому что такое на веб-стеке за пару дней можно сделать, со всеми свистелками и перделками от дизайнера.
                                                                                0
                                                                                И ты такой, :facepalm:, потому что такое на веб-стеке за пару дней можно сделать, со всеми свистелками и перделками от дизайнера.

                                                                                В общем случае программист iOS тоже так может. Но не хочет.
                                                                                  0
                                                                                  Все возможно)
                                                                                    0
                                                                                    Что значит возможно? И что значит хочет/не хочет? Есть мануалы и прочие доки, где указано как и что лепить в иос. Общий вид компонентов здорово стандартизован. А в таком случае зачем делать кастомные «свистелки и перделки от якобы дизайнера»? Смысл же отсутствует. Напрочь отсутствует. Может «якобы дизайнера» носом тыкнуть в мануалы по иос, ну что бы уже не лепил никогда никому непонятную хрень?
                                                                                      +1
                                                                                      Есть мануалы и прочие доки, где указано как и что лепить в иос. Общий вид компонентов здорово стандартизован.

                                                                                      Полагаю что дело именно в этом.

                                                                                      А в таком случае зачем делать кастомные «свистелки и перделки от якобы дизайнера»? Смысл же отсутствует.

                                                                                      Потому что заказчики обычно не хотят «общий вид компонентов», «стандартных решений» и «быть как все». Я то может и соглашусь с тем, что юзеру чаще всего удобнее использовать привычные решения. С другой стороны, можно понять авторов приложений, которые хотят, чтобы их интерфейс был максимально преспособлен к конкретно их задаче.

                                                                                      Короче это палка о двух концах и не нужно уходить в крайности.
                                                                                        0
                                                                                        Потому что заказчики обычно не хотят «общий вид компонентов», «стандартных решений» и «быть как все»

                                                                                        Я не претендую на тотальную объективность, но по моему личному опыту подавляющее большинство заказчиков прислушиваются к замечаниям вида «так делать не принято и ваше приложение будет выглядеть непрофессионально». А вариант «окей, мы это можем сделать, но это будет стоить 3 цены от той, что вы ожидаете» — это эффективный «аварийный» аргумент, когда другие методы на заказчика не действуют. В конце-концов, если заказчик настолько упрямо, что согласится, то за трехкратную наценку и самому разработчику легко полюбить и работу, которую делать откровенно неинтересно, и результат откровенно не нравится.
                                                                                          +1
                                                                                          Все зависит от специфики приложения. Встроенные компоненты далеко не всегда дают приемлемый пользовательский опыт, когда речь идет не о приложении с фоточками. Это первое. Во-вторых, я говорю даже не о вариантах, когда заказчит хочет компонент, полностью отличный от стандартного. Бывает так, что нужно поменять прям какую-то ерунду, по мнению заказчика, по типу «как это вы не можете сделать, чтобы этот label был на пару пикселей ниже? разве мы многого просим?». По факту нативный компонет реально не предоставляет таких возможностей и в этом случае очень трудно объяснить заказчику почему такая мелочь должна решаться так дорого. Часто это лишь приводит к тому, что заказчик начинает сомневаться в компетенциях исполнителя.
                                                                                            0
                                                                                            В вебе с этим проще – нативную кнопку можно перекрасить как угодно, а в нативном мире – строго в заданных рамках, если нужно больше – придется писать с нуля.

                                                                                            По моему опыту общения с iOSниками, именно поэтому они не любят кастомные контролы – слишком много ручной работы, намного больше, чем в вебе.
                                                                                              0
                                                                                              Именно это я и имел ввиду, спасибо.

                                                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                              Самое читаемое