Привет из мезозоя

    image

    Парадный портрет автора, заодно иллюстрирующий идею современной веб-разработки


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


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


    Я с интересом ознакомился с эпохальной статьей "Объясняем современный JavaScript динозавру", где мне на пальцах разъясняют, почему горы мусорного кода крайне необходимы, а мазохизм полезен и приятен. Ничего нового оттуда я, впрочем, не узнал, поскольку сам занимаюсь веб-разработкой, и все это давно испытал на своей шкуре — ну кроме приятной части.


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


    Каждый год часть лапши разбухает и уходит на дно. Много там уже лежит такого, что в приличном яваскриптовском обществе сейчас и упомянуть стыдно — Бэкбоны там разные, Ангуляры, не говорю уже о Jquery или там библиотеке Prototype. Зато сверху тут же взбухает новая пена, и тогда вокруг котла радостно танцуют и поют, как наконец-то на этот раз все проблемы решены.


    Но я не только смотрю, я еще периодически из этого кипящего чана пробую — много лет пробую — и каждый раз обнаруживаю, что результат по-прежнему несъедобен. Мутно, сложно, некрасиво и при этом… примитивно. Горы хлама, монбланы оверинжиниринга ("горе от ума"), число используемых языков уже приближается к десятку (если считать разные версии JS и языки конфигов различных припарок), время сборки всего этого добра растет экспоненциально… И что же в результате?


    Может, компилятор мегаязыка, который сам напишет программу по телепатической постановке задачи? Расчет необходимых и достаточных условий для счастья человечества? Моделирование эволюции с кнопками Step и Step over? Отказоустойчивый код запуска реактора ядерного звездолёта? Универсальная кнопка "Пыщь — сделать красиво"?


    Да нет, дневничок "To Do" с тремя кнопками, не дотягивающий даже до своего бумажного дедушки.


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


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


    Вы же не генерируете для JS особый код на ассемблере для вызова процедур с возвратом, который покладёт на стек соответствующий адрес, а потом заберёт его назад? Не запускаете линкеры, которые соединят вам два модуля и пропишут настоящие адреса глобальных переменных? Не описываете в отдельном файле зависимости между метками и переходами в операторе if? А ведь всё это до сих пор в компьютере нужно — и всё это кто-то делает. Только делают давно отлаженные автоматические инструменты, про которые вы, скорее всего, даже не знаете — потому что оперируете на гораздо более высоком уровне, где нет ни адресов, ни меток, ни стека вызовов.


    Но вы не можете написать что-то вроде


    application ToDo
    {
      use grid;
      layout "todo";
      init { ...}
    }

    и обойтись при этом без всяких подстановщиков кода и систем сборки, как это делали в девяносто лохматом году счастливые программисты на ТурбоПаскале. Почему?


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


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


    Для чего, собственно, используется браузер? Для двух не очень-то пересекающихся вещей.


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


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


    В мире веб-программирования считается хорошим тоном блуждать в трех соснах, которые называются M, V и C. В результате этого саморасходящегося процесса смысл каждой из этих букв стал настолько неопределенным, что даже пророчества Нострадамуса стали на их фоне просто-таки эталоном ясности. Хотя всё проще простого: модель живет на сервере, вид — это то, что маячит перед пользователем на экране, а роль контроллера выполняет браузер, с одной стороны посылающий и принимающий запросы HTTP, а с другой — слушающий мышку и клавиатуру, и передающий их события в программу. Банально, не правда ли?


    Программирование серверной части давно устоялось и не вызывает ни у кого затруднений. Браузер дан нам свыше.


    Видите, мы уже избавились от двух букв. Осталась всего лишь одна — Вид.


    Неужели отображение данных на экране для просмотра и редактирования — такая неслыханная и невиданная задача, что никто не знает, с какой стороны к ней даже подступиться? Я вас умоляю. Она решалась столько раз, что даже просто перечислить — заболит палец, жмущий на клавишу "запятая". Так, навскидку, то, о чем я слышал: терминалы IBM 3270, Смоллтолк, экранный Постскрипт, WinAPI, TurboVision, VisualBasic, dBase, Tcl/Tk, XUL, Rebol/View, XAML.


    Отличается ли чем-то именно браузерное отображение от этой традиционной задачи? Да, отличается. Тем, что модель живёт где-то далеко и ее надо тягать по сети, откуда возникает латентность и необходимость что-то делать в случае ошибок. По сети же надо передавать обновления обратно и проверять, что они правильно пришли. Ещё что-то? Да нет, больше ничего.


    Все перечисленные выше аббревиатуры, если глядеть на них абстрактно, состоят из трех больших частей:


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


    Есть ли в этом что-то сложное и непостижимое среднему уму? Отнюдь. Тяжело ли всё это написать? Ну, задание, конечно, не для студенческой курсовой: виджеты требуют кучу нудной работы, упаковщик — некоторой изощрённости, интерпретатор языка — знакомства с рекурсивным спуском, но в целом это всё-таки не квантовая механика и не ракетная техника.


    Теперь давайте поглядим критическим взором, что же из перечисленного реально имеется в экосистеме браузер + Яваскрипт.


    1) Взаимодействие модели с видом (то есть, сервера с браузером): частично. Есть HTTP-запросы и веб-сокеты, но всё приходится писать самими — кто во что горазд. Стандартные протоколы отсутствуют, не говоря уже о каких-то абстракциях на эту тему, включающих автоматическую проверку подтверждения при обновлении.


    2) Набор виджетов. Фиксированный, встроенный в браузер, да ещё и не совсем совместимый между браузерами разных типов. Расширяется с большим скрипом — понадобилось больше десяти лет на то, чтобы дождаться поля ввода даты. О стандартных сортируемых таблицах до сих пор остается только вздыхать.


    3) Агрегирующие виджеты. Практически отсутствуют, если не считать вездесущий <DIV>, который, собственно, не определяет ни верстки, ни поведения.


    4) Создание виджетов на базе готовых, в стиле ООП. К сожалению, отсутствует. Вы не можете стандартно взять виджет и использовать его как прототип. Честно говоря, и виджета-то никакого нет, а есть только узел DOM, который за неимением лучшего играет роль интерфейсного элемента.


    Собственно, все модные нынче библиотеки пытаются решить именно задачи 2-4), но увы, делают это кто в лес, кто по дрова. В результате имеем 100500 отдельных систем, каждая из которых предлагает лишь необходимый минимум, потому что силы разработчиков распылены на повторное переизобретение колес — причем нередко эллипсоидальных. И да — каждая выдумывает ещё один язык, разумеется, тоже несовместимый с другими. Нужно ведь больше языков.


    Об определении новых тегов, чтобы кратко выразить новые контролы хотя бы в том, что есть — в HTML — разумеется, даже мечтать не приходится. Проект Polymer скорее мёртв, чем жив, во всяком случае для практической работы пока что не пригоден. Возможно, так во младенчестве и умрёт.


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


    5) Упаковщик. Его скорее нет, чем он есть. Его функции размазаны между двумя левыми языками — причем один из них предназначен для представления текстов (!), а второй — просто список атрибутов для графического дооформления элементов (ну там мигание включить или цвет поменять), функциональность которого к тому же дублируется в третьем языке (JS). Говорить о чем-то типа упаковщика можно лишь применительно к появившимся недавно флексам*. Всё, что было до того, — такое же извращение, как вёрстка таблицами или размещение декларативного языка прямо внутрь Яваскрипта. Смесь, так сказать, французского с нижегородским.


    6) Визуальное проектирование интерфейсов стандартными инструментами — это вообще из области фэнтези с эльфами Гэндальфами. Сама идея может лишь вызвать в широких массах недоумение.


    7) Язык… Ну Яваскрипт** — конечно, не самый плохой язык, люди и не на таких монстрах пишут. Но он, вообще-то, не специализированный — в нём нет ничего для решения той самой задачи: представления данных. Да и как универсальный тоже так себе. Никакой, если честно. Самый близкий его родственник — Lua, маленький скромный язычок для скриптования больших приложений. JS весьма минималистичный, потому не слишком выразительный, и вряд ли кто-нибудь о нём вообще знал бы, если бы его не засунули в самый популярный тип программ. В нём даже модулей до последнего времени не было и их приходилось имитировать с помощью совершенно посторонних средств.


    Из интересных идей разве что прототипное наследование — но от него всё равно нет никакой практической пользы — см. п. 4.


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


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


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


    И вот все эти "частично", "нет" и "нужно делать руками" по всей системе в результате как раз складываются в ту самую адскую трудоемкость, глючность, тонны памяти и непрерывный поиск святого Грааля, который каждый раз оказывается лишь одноразовым пластиковым стаканчиком.


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


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


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


    И в этих скромных требованиях они, чёрт возьми, совершенно правы.


    Есть ли свет в конце туннеля? Теоретически да. Если, наконец, производители браузеров выкинут всё накопившееся старьё и напишут с нуля нормальную интерфейсную среду с нормальной иерархией виджетов и упаковщиком, договорятся об автоматическом обмене информацией с сервером, приделают к браузеру самую банальную виртуальную машину общего назначения, можно даже не особо быструю****, ну и в качестве вишенки сочинят стандартный DSL для построения интерфейсов, то веб-разработка станет тем, чем она и должна быть, — несложным ремеслом, и главную роль в ней будет играть не программист, а дизайнер UX. А программисты, наконец, займутся нейронными сетями, обработкой больших данных, расчётами холодного термояда, сочинением увлекательных игр и другими полезными вещами, о которых в старости не стыдно будет рассказать детям. "Я всю жизнь добивался, чтобы при нажатии на одну кнопочку другая меняла цвет" — это как-то всё-таки не то.


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


    Примечания


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


    ** Филологическое отступление. Язык Javascript был назван по аналогии с другим языком по имени Java. Этот язык получил своё название по имени сорта кофе, который выращивается на определённом острове. Остров этот по-русски называется Ява, а не Джава, соответственно, кофе на нём яванский, а языки именуются, следовательно, Ява и Яваскрипт. Между прочим, Яваскрипт первоначально хотели окрестить по имени другого сорта кофе "Mocha", который на русский переводится как "мокко". Боюсь подумать, как бы тогда называли новый язык любители тупо переписать латинские буквы кириллицей.


    *** Прототипная модель очевидно шире классовой. Последняя имитируется на ней совершенно тривиально: заведите объекты, назовите их с большой буквы и порождайте экземпляры только от них. А вот из классовой прототипы никак не устроишь.
    Другое дело, что конкретно в Яваскрипте даже метод родителя вызывается с таким ужасным синтаксисом, что его и запомнить-то невозможно. Но это недостаток языка, а не модели.


    **** Где же ты, WebAssembly ?

    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 234
    • –4

      И где обсуждение ява-апплетов? Они решали многие из перечисленных проблем.

      • +5
        флешевые модули работали так же как явовые апплеты и раздавили браузерную яву как муху. Даже выбор браузера какое-то время назад сводился к вопросу «опера флеш не поддерживает, значит в топку»

        Но теперь флеш из браузеров выкинули т.к. производители не хотят чтоб кто-то со стороны имел такое влияние.
        • +23
          Но теперь флеш из браузеров выкинули т.к. производители не хотят чтоб кто-то со стороны имел такое влияние.

          Вариант "потому что было слишком много дыр" не рассматривается?

          • +9
            Это же идеальный аргумент с который невозможно оспорить, такой же как «давайте оградим детей от порнографии и наркотиков, и для этого заблокируем ресурсы с этой информацией».
            Но это все борьба со следствием, а не с проблемой.
            • 0
              Это же идеальный аргумент с который невозможно оспорить

              Что "это"?


              Но это все борьба со следствием, а не с проблемой.

              И что же здесь проблема?

              • 0
                Что «это»?

                «потому что было слишком много дыр»
                И что же здесь проблема?

                Собственно дыры.
                • +8

                  Есть мнение, что дыры — это как раз следствие. А проблема — это архитектура.

                  • 0

                    Да, можно было бы бороться с самой проблемой, с дырами. Если бы адобе открыл код. А так-то так? Производителям браузеров нужно было бинарник патчить или что?

              • +2
                Вариант «потому что было слишком много дыр» не рассматривается?


                Нет.

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

                А всё для чего использовали флеш/жава-апплету уже может обычный хтмл5.
                • +4
                  А всё для чего использовали флеш/жава-апплету уже может обычный хтмл5.

                  Сильное заявление.
                  • +1
                    так утверждают эппл, гугл и микрософт. Это крупные компании.
                    • 0
                      Я к тому, что неужели браузерный API способен потягаться в возможностях с (почти) полноценной JVM/CLR?
                      • 0
                        а зачем?

                        В тексте написано немного другое

                        А всё для чего использовали флеш/жава-апплету уже может обычный хтмл5
                        • +4
                          Тут разница в мотивации. Вместо создания просто хорошей альтернативы для повседневных задач они намеренно убивали технологию, подменяя ее «плюшевым» API.
                  • +1

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


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

                    • 0
                      Ну вот хочет эппл чтоб флешевая игра/видео была жёстко ограничена в потреблении энергии, а адоб не хочет (не может) ничего менять. Причём тут АПИ?
                      • 0
                        Каким образом аналогичная задача решается для html5?
                        • 0
                          Через остановку requestAnimationFrame-обновлений в неактивных вкладках. Флеш же, для сравнения, в неактивных вкладках радостно продолжает тормозить.
                          • 0
                            Посмотрите на PPAPI для хрома, через который уже лет 5 как работает флеш плеер
                            • 0
                              Это почему-то не мешает ему вешать браузер при загрузке в неактивных вкладках…
                              • 0
                                Значит хром ему это позволяет

                                Вот схема вызова вашего render call из документации:
                                Life cycle of a plugin -> renderer call
                                Plugin calls PPAPI function.
                                Thunk layer converts this to a C++ call on the proxy resource object.
                                Proxy resource does a CallRenderer with its message. This gets embedded into a «resource call» IPC message which encodes the resource ID and instance.
                                The ResourceHost in the renderer receives the message and finds the corresponding resource host object.
                                The resource host decodes the message and performs the operation.

                                Еcли вы уверены, что эту схему можно обойти и дернуть нативный вызов напрямую, обойдя песочницу, то предлагаю вам написать в bughunt программу гугла и получить ваши ~15000$
                                • +1
                                  Еcли вы уверены, что эту схему можно обойти и дернуть нативный вызов напрямую, обойдя песочницу, то предлагаю вам написать в bughunt программу гугла и получить ваши ~15000$
                                  Не стоит так кидаться словами.

                                  Дело в том, что все звери равны — но некоторые равнее. Специально для флеша Хром предоставляет несколько приватных интерфейсов, которые, с одной стороны далают «Flash на PPAPI (да-да, точно-точно, верим-верим)» возможным, а с другой — приводят к том, что Flash-таки может «вешать браузер».

                                  Ну не смогли они сделать из PPAPI что-то, чем реально можно пользоваться.
                                  • 0
                                    Ну так где я кидался словами?
                                    Значит хром ему это позволяет
                                    • 0
                                      Ну так где я кидался словами?
                                      Вот тут:
                                      Посмотрите на PPAPI для хрома, через который уже лет 5 как работает флеш плеер
                                      Есть «безопасный» и «правильный» PPAPI. А есть «PPAPI для флеша» — и это разные вещи.

                                      P.S. Комментарий я действительно не туда отписал.
                                      • –1
                                        Хорошо, уберем fp, напишем свой плагин по правильному PPAPI. Предложенная вами оптимизация в ней все так-же невозможна?
                                        • +3
                                          Наши недостатки — продолжение наших достоинств. Флешом было удобно пользоваться, в частности, потому, что работа с DOM'ом — в нём была синхронной, как в JavaScript.

                                          PPAPI (без «заднего прохода для флеша») не позволяет этого сделать в принципе, что автоматически ставит крест на том, чего люди хотели от NaCl'я больше всего: возможности писать на более вменяемых языках, чем JavaScript.

                                          Что, правда, приносит и пользу, как бы: PPAPI-плагины не могут «завесить» браузер, ура. Но вред, хотя и менее очевиден, но более весом: в силу того, что пользоваться этим крайне проблематично и «замену флеша» сделать невозможно — то этих плагинов, как бы, так и не появилось в сколько-нибудь ощутимом количестве.
                      • +1
                        Но этого не было сделано именно потому что, согласно современным представлениям, само наличие каких-то левых плагинов — уже дыра в браузерной песочнице.

                        А разве это не так? По-моему, львиная доля дыр в Java и Flash — в самих плагинах. Не все, далеко не все — но очень большая доля.

                        • +3

                          Да, так и есть. И пальма первенства тут, кстати — у Java, где браузерный плагин позволял апплетам из соображений совместимости использовать устаревшие версии JRE :-)

                          • 0

                            Ну и что бы тут изменил другой API? Ведь по любому, плагин, такой как Java или Flash, и только он, знает, что он там исполняет. Он видит и работает с кодом. Полноценный статический анализ безопасности практически не возможен (для JS в первую очередь, я совсем не уверен, что для Java и Flash с этим реально хуже — хотя тоже грустно). И контролировать его целиком браузер вряд ли сможет.


                            В какой-то мере это ведь и к wasm относится, хотя тут конечно все иначе — тут байткод, и сравнительно простой.

                            • 0
                              Полноценный статический анализ безопасности практически не возможен (для JS в первую очередь, я совсем не уверен, что для Java и Flash с этим реально хуже — хотя тоже грустно).
                              Вот как раз эту проблема — разрешима. Посмотрите на NaCl — там не то, что C с C++, там ассеблер можно было использовать — и всё это безопасно потом запускать. Даже на Windows XP.

                              Убили всё это из политических соображений, а не технических./
                              • –2

                                Не, ну там кажется внутри все равно байткод (LLVM), разве не?

                                • 0
                                  Нет. Там есть LLVM и байтокод — но с их помощью достигается переносимость, не безопасность. Мегабайты кода LLVM'а вполне явно отнесены к untrusted зоне — то есть к коду, которому NaCl не доверяет и ошибки в котором не являются проблемой.

                                  Вот тут описано как программировать в NaCl на ассемблере, без всяких компиляторов и байткодов…
                    • +1

                      А вы считаете, что в V8 мало дыр? Ну или в движке у IE/Edge? Не, я даже согласен, что их меньше — но они были, и наверняка есть. И их вряд ли когда-либо устранят полностью, потому что задача исполнения недоверенного кода, взятого где-то в интернете, а возможно и подмененного по пути хакером, так чтобы он работал, но ничего не поломал — она сложная. Ну т.е., да, может на какой-то момент во флеше и было многовато дыр — так у него и возможностей намного больше, чем у тогдашнего JS-движка (да и у сегодняшнего пожалуй тоже).


                      Ну т.е. это не причина — это повод.

                      • +5
                        А вы считаете, что в V8 мало дыр? Ну или в движке у IE/Edge?

                        Я считаю, что их (должно быть) радикально меньше просто потому, что surface ограничен браузером. А у плагинов — как я их помню — surface как раз и был больше.


                        Ну т.е., да, может на какой-то момент во флеше и было многовато дыр — так у него и возможностей намного больше, чем у тогдашнего JS-движка

                        Вот-вот. Именно эти возможности и давали дыры.

                        • +3
                          Вот-вот. Именно эти возможности и давали дыры.

                          В V8 когда-то (правда, давненько уже) были дыры даже в движке регулярных выражений. Уровня remote code execution. Давайте запретим регулярки, чего уж там? :)


                          Я позволю себе в который раз напомнить забавную историю про то, как кто-то из известных чуваков в команде мозиллы громко заявил: "Да этот ваш Acrobat Reader — сплошная дырка в безопасности. Мы его выпилим, и сделаем средство просмотра на чистом javascript, без плагинов". И все знают, чем это кончилось.


                          Ну просто это (запрет чего-либо) — не метод решения проблемы, ни разу не метод.

                          • +3
                            В V8 когда-то (правда, давненько уже) были дыры даже в движке регулярных выражений. Уровня remote code execution

                            Понимаете ли, одно дело, когда у вас есть регулярки, в которых возможен RCE. Закрыли RCE, проблема решена. Другое дело, когда у вас есть плагин, который позволяет слать запросы к любому серверу в контексте браузера, но игнорируя CORS (это я для примера, я уже не помню, что там было). Границы песочницы разные.

                            • 0

                              Я не очень понял, в чем вы видите разницу (CORS, если уж на то пошло, вообще появился позже, чем Flash, и в нем в каком-то виде поддерживался (crossdomain.xml, сколько я помню), так что мне кажется вы тут ошибаетесь). Ну да, границы разные. Но тут вполне было за что платить-то, разница в возможностях уж очень велика.


                              И кроме того, набор доступных разработчику на JS возможностей — он же тоже постоянно растет, так что границы песочницы только расширяются. Причем в частности и потому, что разработчикам не хватает возможностей, которые были в том же Flash. Добавили поддержку микрофона, веб камеры, bluetooth, геолокации, канвас, WebGL, и много чего еще. Ходят слухи, что хакеры научились майнить биткоины через браузер. Думаете, число потенциальных векторов атаки сокращается? Да ладно...


                              По-хорошему, бороться с дырами в плагинах можно было, причем несколькими вполне очевидными способами. Один из них даже реализован — в FF, скажем, есть механизм отключения плагинов, про которые известно, что там дырки. Ну т.е. браузер отключит ваш Flash, как только получит оповещение. И включит после обновления. Значительно быстрее, чем это сделаете вы сами.

                              • 0
                                Я не очень понял, в чем вы видите разницу

                                Разницу я вижу в том, сколько систем отвечает за границы песочницы.


                                Но тут вполне было за что платить-то, разница в возможностях уж очень велика.

                                Собственно, кто-то решил, что плата слишком высока.

                • +6
                  Практически отсутствуют, если не считать вездесущий, который,

                  У вас, кажется, парсер что-то не то съел.

                  • +1
                    наверное, имелся в виду div?
                  • +3

                    С аргументами в целом согласен — но я не понимаю как из них следуют выводы.


                    Вот есть технология X. Которая упрощает разработку. Почему от нее надо отказаться только на основании того что она не делает Y — при полном отсутствии делающих Y технологий?

                    • 0
                      Вообще-то выводы чуть другие. Технология X — это костыль, и ничем, кроме костыля она не будет, потому что задача на этом уровне (библиотек JS к уже готовой экосистеме) не решается.

                      А дальше уже каждый думает для себя — готов ли он с этим костылем жить и дальше, учитывая, что Y нет и не будет, и не питать иллюзий о быстрой и производительной веб-разработке, или же заниматься чем-то другим.
                      • 0
                        Под «заниматься чем-то другим» вы подразумеваете уйти из веба? Да, это вариант. Но до тех пор пока вы в вебе — надо пользоваться тем что упрощает разработку. Пусть это и костыли.
                        • 0
                          Уйти из веба. Попробовать какие-то другие технологии. Сразу закладываться на то, что разработка фронтэнда на имеющихся инструментах будет занимать *3 времени и сил, и планировать под нее соответствующие ресурсы.

                          Главное — сознавать ограничения и не вестись на рекламу.
                    • +5
                      Автор начал за упокой, закончил за здравие.

                      Говорил правильно но закончил слегка не тем.
                      Проблема не в самих языках HTML, CSS, JS или их ущербности. А в том, что много фич просто находится на полпути к готовому продукту. И вместо того, что бы взять и за «5 минут» допилить существующие, все усилия сообщества ГОДАМИ уходят на изобретение велосипедов (В этом я с автором согласен).

                      Это как пришли болты, но без резьбы, и их приходится кувалдой заколачивать. Зато если стал на место то перманентно на века. А если не стал… победа.

                      P.S. Вся «стройная» структура JS заточена на то, чтобы быстро обрабатываться интерпретатором. И только… Смысла менять её НЕТ. А то, что кому-то не удобно, это его проблемы (пусть сломает себе мозг).

                      Хорошему танцору и кегли в радость!
                      • 0
                        А в том, что много фич просто находится на полпути к готовому продукту.

                        Они так же устареют еще до того, как наконец наступит «коммунизм».
                        • 0
                          а как же WebAssembly? Или его ждёт судьба узконаправленных задач?
                        • +12
                          Когда вам кажется что веб застрял где-то в мезозое — просто взгляните на ситуацию с почтовыми клиентами в 2017ом году, и успокойтесь) Там вообще до сих пор таблицами верстают, и каждый раз нет гарантии что оно правильно отобразится, потому что каждый клиент режет html как хочет.
                          • +3
                            Отсюда автору статьи более радикальный вывод — «выкинуть всё и с нуля» надо начиная с html!

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

                            Отвечаю. По сравнению с куда более мощными и тщательно разработанными десктопными интерфейсами у веба есть два мощных козыря: идеальная независимость от платформы и ненужность инсталляции приложений


                            Во-первых, идеальной независимости от платформы нет и у веба, если не от ОС, то от браузера (свежа еще память об IE6?). Во-вторых, как показал опыт мобильных гаджетов, «ненужность инсталляции приложений» вовсе не являет собой непреодолимую преграду для пользователей — буквально на каждом углу висят призывы «скачайте наше мобильное приложение!». То есть вопрос, на самом деле, можно поставить так: как сделать это проще?.. Ведь что такое загрузка современного сайта по своей сути? Это всего лишь скачивание самой последней (текущей) версии приложения, написанного на JavaScript!

                            А теперь давайте пофантазируем: представим, что какая-то из упомянутых автором технологий, ну например Tcl/Tk, будучи кроссплатформенной и скриптовой, может каким-то образом, аналогично сайту, скачиваться на любое устройство пользователя, хоть Android, хоть десктоп на Windows или Linux, и тут же отображать пользователю GUI. Представили? Ведь это же и будет тот самый убийца Web, так как решает те же задачи!

                            Oh, wai~~
                            • 0
                              Не только Tcl, но и Rebol. Диалект последнего Red уже работает на Андроиде.
                              • 0
                                Спасибо за упоминание Ребола и РЕДа, ну и XUL-а, причем — в правильном контексте. :)
                                И спасибо за статью, очень верно разложено все. И еще очень хорошо, что автор сам тоже занимался веб-разработкой, чтобы нельзя было нахрапом к нему применить спервадоб-аргумент. :)
                              • 0
                                А теперь давайте пофантазируем: представим, что какая-то из упомянутых автором технологий, ну например Tcl/Tk, будучи кроссплатформенной и скриптовой, может каким-то образом, аналогично сайту, скачиваться на любое устройство пользователя, хоть Android, хоть десктоп на Windows или Linux, и тут же отображать пользователю GUI. Представили? Ведь это же и будет тот самый убийца Web, так как решает те же задачи!

                                Так это же и пытались сделать Ява-апплеты и Флэш. Основным недостатком Ява-апплетов, на мой взгляд была излишняя громоздкость (в сравнении с Питоном или Тсл/Тк), основным недостатком Флэш была закрытость. Но в целом они именно это и делали.

                                Легковесный контейнер, жёстко, на уровне железа изолирующий скачиваемое приложение от клиентской машины и предоставляющий ограниченный, контролируемый системой прав доступа и квот интерфейс к устройствам на клиенте (можно дополнить его встроенным легковесный интерпретатор типа Питона/TclTk) по идее должен бы решить проблему безопасности. Но это будет громоздкая конструкция. Если же такой контейнер соорудить, то почему бы тогда не разрешить запускать в нём бинарные файлы?

                                Кстати, что-то я не вижу, чтобы всякие игрушки, типа огорода на ок.ру, написанные на Флэш, активно переписывались на HTML5, что ставит под сомнение утверждение о том что HTML5 может его заменить…
                                • 0
                                  HTML5 может его заменить…

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

                              • 0
                                Разве это волнует кого-то, кроме спамеров?
                                • +5

                                  Может я не правильный человек какой-то, но я всегда выключаю html отображение письма.

                                  • 0
                                    я в mutt наоборот: вынужден html через фильтр w3c прогонять, чтоб увидеть что там написано :)
                                  • +4
                                    Потому что в письмах должен быть только текст. Тогда и проблем с вёрсткой не будет.
                                    • +1
                                      Пожалуй, я бы согласился на RsT. Ну или MD, ладно.
                                      • 0

                                        Там кстати rich text есть. Не все об этом знают, но подавляющее большинство клиентов поддерживает простое форматирование (жирный/курсив и т.д.) в соответствии с каким-то богом забытым стандартом.

                                        • 0
                                          Хм, я думал это только в аутлуке. Но все равно, это же просто альтернатива хтмл, не?
                                      • +1
                                        А в сайтах не должно быть JSа, все должно работать статически. Я помню.
                                    • +7
                                      джва чая этому динозавру
                                      • +3
                                        Если есть люди, говорящие «в этом вашем вебе все через ж...», то, наверное, есть в IT какая-то область, где все хорошо. Расскажите, пожалуйста, что это за область, я обязательно переквалифицируюсь.
                                        А пока все ищут ту самую работу мечты, я поделюсь мыслями о вебе:
                                        1. Доля open-source в вебе как на клиенте, так и на сервере близка к 100%. И мне это очень нравится. Какой еще сегмент IT может похвастаться тем, что проприетарный код там вообще не котируется?
                                        2. Огромное, дружелюбное и открытое сообщество (я, конечно, имею в виду англоязычное ;) ).
                                        3. Вакансии на любой вкус. Зарплаты, на которые вполне можно жить.
                                        4. В конце концов, здесь реально что-то происходит. А какие последние новости, например у разработчиков SCADA? И, кстати, где их можно почитать?
                                        Я, конечно, еще довольно молод, но я помню веб эпохи диал-апа и IE5. Так вот: веб стал лучше. Намного лучше.
                                        • +1
                                          Если есть люди, говорящие «в этом вашем вебе все через ж...», то, наверное, есть в IT какая-то область, где все хорошо.

                                          В геймдеве вроде всё вполне себе норм. Не могу припомнить никаких особых архитектурных проблем. Даже от вечной обратной совместимости GAPI уже ушли.
                                          • +2
                                            А с чьей точки зрения веб стал лучше?
                                            Моя точка зрения пользователя такая что с каждым годом веб становится все тяжелым и неуклюжим. Раньше мне не доставляло проблем запустить 20 вкладок и работать с ними. И я не парился что мне не хватит памяти и все зависнет и упадет. А сейчас даже закрытие вкладки зачастую не означает что память освободится. И теперь для работы в вебе мне нужно 8 гиг памяти…
                                            • +1
                                              Потому что веб-сайты превратились в веб-сервисы. Проблема тормозов (например, если вы сидите на Eee PC с 1Гб памяти) решается отказом от веб-сервисов: в браузере просматриваются лишь странички, а для сервисов используются отдельные приложения.
                                              Так, вместо тормознутых почтовых веб-сервисов типа GMail используется старый добрый почтовый клиент. Хотя по нынешним временам стало очень трудно найти почтовик без встроенного браузера со всеми его тормозами, так на вскидку кроме Sylpheed ничего и не припомню.
                                              Для просмотра лент с соцсетей и новостных лент используется RSS-агрегатор. Хотя по нынешним временам крайне сложно найти RSS-клиент без встроенного браузера — я не знаю ни одного GUI-клиента, который не тянул бы с собой тормознутый браузерный движок.
                                              Вместо youtube и подобных видеосервисов используется потоковый плеер.
                                              Ну и всё в том же духе. Большинство веб-сервисов заменяется автономными приложениями, а немногие статические странички просматриваются в links2 или подобном браузере, который отлично их рендерит, даже с графикой. В таком режиме можно хоть с Raspberry Pi комфортно в Интернете сидеть.
                                              • 0
                                                Так, вместо тормознутых почтовых веб-сервисов типа GMail используется старый добрый почтовый клиент.

                                                Это все хорошо, когда у вас один стационарный компьютер. Сейчас же, один и тот же почтовый ящик должен быть доступен с нескольких устройств, как минимум это комп и смартфон.
                                                • +2
                                                  А в чём тут проблема? Даже на древнем POP3 никто не заставлял письма с сервера удалять сразу же после загрузки, а уж с IMAP вообще проблем нет.
                                                  • 0
                                                    А зачем мне на смартфоне все письма целиком? Где хранить черновики? Почему нельзя написать письмо на компе, а дописать и отправить его со смартфона? Проблема в том, что вы решаете непонятную проблему, непонятно зачем. Ну то есть если у вас десятилетний eee pc и нет возможности купить ничего новее, то понятно. Но это какой-то исключительный случай. Большинству людей удобнее пользоваться почтой в облаке, пользоваться ютубом вместо настройки потокового плеера и так далее. Значит и разработчики будут делать сервисы под них.

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

                                                    В таком режиме можно хоть с Raspberry Pi комфортно в Интернете сидеть.

                                                    Можно. Но опять таки, для чего? Проблема памяти, на которую жалуется автор выше решается гораздо проще.
                                                    • +1
                                                      А зачем мне на смартфоне все письма целиком? Где хранить черновики? Почему нельзя написать письмо на компе, а дописать и отправить его со смартфона?
                                                      Это хорошие вопросы, но они не обьясняют — зачем вам для всего этого гонять туда-сюда мегабайты кода. Драфт записать на сервер — отлично, но зачем для этого весь UI с сервера скачивать каждый раз, когда вы почту хотите почитать…

                                                      Впрочем GMail на смартфоне и не скачивает и HTML5 для UI не пользуется… что как бы и показывает ненужность всего «котла», который обсуждается в статье…
                                                      • 0
                                                        А оно и не скачивает каждый раз и ничего не гоняет. Это легко проверить, нажмите F12 — увидите что ничего из вашего юая не скачивается, все берется из дискового кеша.

                                                        Впрочем GMail на смартфоне и не скачивает и HTML5 для UI не пользуется

                                                        Да все то же самое. Не считая того, что это приложение точно так же надо скачать (хотя конкретно это уже поставили за вас). А у разработчиков опционально добавляется геморрой в виде поддержки нескольких версий апи.

                                                        И да, gmail приложение не использует IMAP, а использует свой внутренний протокол, насколько мне известно. А это значит, что для другой почты мне нужно другое приложение. Которое опять надо скачать и обновлять. И с которым нет нужной функциональности. Или у вас есть в имапе возможность сохранять драфт на сервер и создавать правила?
                                                        • 0
                                                          Это легко проверить, нажмите F12 — увидите что ничего из вашего юая не скачивается, все берется из дискового кеша.
                                                          А вы проверьте. Мой эксперимент — первый запуск при «пустом» кеше скачивается порядка 10 мегабайт, повторное открытие сразу после этого — где-то мегабайта два.

                                                          Или, что ещё проще, перестаньте полагаться на F12, а просто подключитесь к телефону на 2G и испытайте весь «amazing experience» современных веб-технологий.

                                                          Да все то же самое. Не считая того, что это приложение точно так же надо скачать (хотя конкретно это уже поставили за вас). А у разработчиков опционально добавляется геморрой в виде поддержки нескольких версий апи.
                                                          Это временно.

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

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

                                                          Сравните хотя бы MS Office и Google Docs. Я, кстати, активно пользуюсь Google Docs — так как тот факт, что за них не нужно платить и их не нужно устанавливать часто решает… но над второй проблемой уже работают, а первая, как бы, к качеству технологий вообще отношения не имеет.
                                                          • –4
                                                            первый запуск при «пустом» кеше скачивается порядка 10 мегабайт, повторное открытие сразу после этого — где-то мегабайта два

                                                            И что? Два, десять, пятьдесят. Да хоть триста. В чем проблема, с точки зрения юзер экспириенса, если сеть позволяет? Почему вы технические хотелки выдаете за проблему?
                                                            и испытайте весь «amazing experience» современных веб-технологий.

                                                            Да, с устаревшим телефоном на дохлой сети с современными технологиями будет неудобно. Как и работать на пентиум-1. С чего вы решили, что это проблема создателей этих технологий?

                                                            , кстати, активно пользуюсь Google Docs — так как тот факт, что за них не нужно платить и их не нужно устанавливать часто решает…

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

                                                            но над второй проблемой уже работают,

                                                            Ну как доработают приходите. Вы серьезно считаете эти инстант-апы не будут вообще скачивать никакой трафик и юай и прекрасно работать на старом телефоне на GPRS? Иначе непонятно, к чему все эти ваши ожидания.
                                                            • +1
                                                              И что? Два, десять, пятьдесят. Да хоть триста. В чем проблема, с точки зрения юзер экспириенса, если сеть позволяет? Почему вы технические хотелки выдаете за проблему?
                                                              Потому что они становятся проблемой как только вы ступаете за пределы МКАД. Не обязательно куда-нибудь в Карелию. Вот, например, ОпСоС из вполне себе продвинутой страны — Германии. Что мы видим на первой странице? Правильно: гордое заявление о том, что в самом популярном тарифе количество траффика увеличено с 1GB до 1.25GB. В месяц! Не в день! А у нас тут открытие письма в три строки пару мег сжирает… и как с этим жить? Ответ: никак. Потому и происходит переход с HTML на выделенные приложения.

                                                              Да, с устаревшим телефоном на дохлой сети с современными технологиями будет неудобно. Как и работать на пентиум-1. С чего вы решили, что это проблема создателей этих технологий?
                                                              С того, что люди по-прежнему пользуются нетбуками на Атомах и «дохлыми сетями».

                                                              Ну как доработают приходите. Вы серьезно считаете эти инстант-апы не будут вообще скачивать никакой трафик и юай и прекрасно работать на старом телефоне на GPRS? Иначе непонятно, к чему все эти ваши ожидания.
                                                              Развитие технологий идёт по спирали. Web-технологии, на самом деле, ужасны. То есть да, вбухав кучу времени и сил можно сделать почти всё, что угодно, но какой-нибудь Visual Basic четвертьвековой давности (или Delphi, если вам так нравится) — дадут фору 100 очков вперёд всем этим БЭМ'ам и Angular'ам. Однако у них есть и недостаток — для того, чтобы начать полученным продуктом пользоваться вам нужно скачать инсталлятор на 10-20-30 мегабайт и установить программу! И вот только и исключительно за счёт этого Web-приложения вообще существуют. Никакого другого преимущества у них нет. Так вот: утяжеление фреймворков уже сейчас привело к тому, что если только вам не нужно запустить программу буквально один-два раза «нативное» приложение требует меньше траффика. А распространение Instant Apps приведёт к тому, что и второе преимущество Web-приложений испарится. После чего смысл в web-приложениях пропадёт. Произойдёт то, за что, собственно ратует автор статьи: приложения будут писаться на более вменяемом фреймфорке, а HTML5+ (или как его там сегодня называют) станет legacy (хотя, как обычно, его продолжат использовать завернув в обёртки… legacy просто так не исчезает).

                                                              Уже сейчас имеется масса людей, которые никогда в жизни не пользовались web-приложениями потому что не могут себе этого позволить! В мире, где Android популярнее Windows, а месячный траффик, которым эти люди располагают, измеряется единицами гигабайт в месяц это для них — недоступная роскошь.

                                                              А если вас всё равно приходится делать нативное приложение, то зачем вам все эти Web-навороты?
                                                              • –1
                                                                какой-нибудь Visual Basic четвертьвековой давности (или Delphi, если вам так нравится) — дадут фору 100 очков вперёд всем этим БЭМ'ам и Angular'ам

                                                                По производительности — возможно. По фичам — нет.

                                                                • 0
                                                                  Я не очень понял за что вы мне поставили минусы, но да ладно.
                                                                  Я не защищаю текущую ситуацию, но и демонизировать ее тоже не стоит.
                                                                  Однако у них есть и недостаток — для того, чтобы начать полученным продуктом пользоваться вам нужно скачать инсталлятор на 10-20-30 мегабайт и установить программу!
                                                                  Уже сейчас имеется масса людей, которые никогда в жизни не пользовались web-приложениями потому что не могут себе этого позволить!

                                                                  Да, не могут. Точно так же они не смогут пользоваться инстант приложениями, которые вы упомянули как решение проблемы. Вот к чему я веду. Эти инстант приложения точно так же будут потреблять трафик.

                                                                  С того, что люди по-прежнему пользуются нетбуками на Атомах и «дохлыми сетями».

                                                                  Простите, но если бы реально, для Германии использование Gmail-а было бы какой-то проблемой, будьте уверены, гугл бы уже давно эту проблему решил. Судя по тому что он ее не решает — проблема не настолько критична.
                                                                  Уже сейчас имеется масса людей, которые никогда в жизни не пользовались web-приложениями потому что не могут себе этого позволить! В мире, где Android популярнее Windows, а месячный траффик, которым эти люди располагают, измеряется единицами гигабайт в месяц это для них — недоступная роскошь.

                                                                  Ок, я понял вашу точку зрения. Я только не понял, как переход на instant apps эту проблему решит.
                                                                  • 0
                                                                    Да, не могут. Точно так же они не смогут пользоваться инстант приложениями, которые вы упомянули как решение проблемы. Вот к чему я веду. Эти инстант приложения точно так же будут потреблять трафик.
                                                                    При использовании их как инстант приложений — да. Но… читаем:
                                                                    Q:Can I implement an instant app without an installable Android app?
                                                                    No, you need to have an installable version of your Android app in the Google Play.
                                                                    Так что…

                                                                    Простите, но если бы реально, для Германии использование Gmail-а было бы какой-то проблемой, будьте уверены, гугл бы уже давно эту проблему решил.
                                                                    А он и решил её. Почти 10 лет назад. Почти на всех сматрфонах Gmail'у не требуется качать десятки мегабайт даже при первом запуске.

                                                                    Ок, я понял вашу точку зрения. Я только не понял, как переход на instant apps эту проблему решит.
                                                                    Очень просто: любое приложение для Андроида может быть установлено на телефон с Андоидом (неожиданно, правда?). А инстант — это всего лишь способ на него посмотреть не устанавливая. Если у вас есть возможность гонять туда-сюда гигабайты траффика — может вообще GMail никогда не устанавливать, ваше право. А если нет — установили и «спите спокойно», гигабайты без разрешения не накачаются.

                                                                    Ситуация примерно такая же, как она уже есть сейчас — но с важным отличием: вам не нужно писать два приложения — одно для web'а, одно — для установки на устройство. Достаточно одного (ну или, возможно, двух — если iOS вам тоже нужно поддерживать).
                                                  • 0
                                                    К огромному счастью, гмыло до сих пор позволяет ходить через хтмл-интерфейс. Если бы его убрали (тьфу-тьфу-тьфу), не представляю, как бы я это пережил… :)
                                                  • –5

                                                    А у меня 20 вкладок открыты и ничего не тормозит.


                                                    Чтобы проблема была признана официально, она должна воспроизводиться у значительного числа пользователей

                                                    • +1
                                                      Попробуйте воспроизвести на компьютера без SSD и не более 4Гб оперативки.
                                                      • 0

                                                        У меня был Mac Mini 2012 года выпуска, в нем как раз 4 Гб памяти и нет SSD.


                                                        Стандартный набор: браузер, почта, мессенджер — работал нормально. По памяти затык случался только при просмотре FullHD видео или открытом фотошопе.

                                                        • 0
                                                          у меня на работе есть MacBook Pro 2012 года с 4Гб памяти и без SSD, иногда хочется его об стенку швырнуть… (мой личный мак точно такойже с SSD и домашний комп (с виндой) тоже с SSD… земля и небо)
                                                          • 0

                                                            С этим согласен, больше памяти лишним не будет, программы станут отзывчивее.


                                                            Однако, я не понимаю как из утверждения "программы жрут все больше памяти" следует "веб тяжелый и неуклюжий". Только браузерам нужна память? Остальные программы по-прежнему вмещаются в 640 килобайт?

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

                                                                  Если браузер открыт постоянно, то почему бы ему не выделить больше памяти, раз он вам нужен? Звучит справедливо.


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

                                                                  • 0
                                                                    я так и не увидел предпосылок к снижению потребления памяти.

                                                                    Это то и грустно…
                                                                    Раньше страница которая жрет 100мг памяти считалась написанной дилетантами и студентами, теперь это норма. А по факту ничего снаружи не поменялось…
                                                      • +1
                                                        Мне просто любопытно, какие именно 20 вкладок мне надо открыть, чтобы что-то стало тормозить… Ни разу не сталкивался, ноут 2012 года, 6 Гб памяти, SSD.
                                                        Я абсолютно серьезно, расскажите.
                                                        • +1
                                                          У меня adblock отжирает 200-300 мб, и этого достаточно, чтобы браузер начал тормозить вместе со всей системой. 4 Гига и HDD.
                                                          • 0

                                                            Поставьте же uBlock Origin.

                                                            • 0
                                                              Последовал вашему совету. Пока доволен.
                                                              • 0
                                                                Переведите его в режим «Advanced», и, в принципе, можно и от noScript начинать отказываться.
                                                          • 0

                                                            Не могу вам ответить конкретно, но субъективные ощущения примерно такие же. Несколько лет назад тоже не закрывал вкладки никогда, и держал их по 100 штук. Были периоды, когда Firefox на этом падал, но были и периоды, когда это стабильно жило месяцами. А сейчас при 20-30 вкладках подмывает позакрывать.


                                                            Ваши 6 гигов и SSD, кстати, могут достаточно сильно менять дело.

                                                        • +2
                                                          > В конце концов, здесь реально что-то происходит.

                                                          Фреймворки по раскрашиванию кнопочек устаревают быстрее, чем пишется статья про них?
                                                        • +1
                                                          то, о чем я слышал: терминалы IBM 3270, Смоллтолк, экранный Постскрипт, WinAPI, TurboVision, VisualBasic, dBase, Tcl/Tk, XUL, Rebol/View, XAML

                                                          Ну, передергивать-то не стоило. Я вот не просто слышал, но и вполне застал 3270, и скажем DMS для них. Да, надо сказать, что DMS + REXX в качестве языка разработки формочек и интерактивных приложений вполне бы сгодились и сегодня… для кассы например. Не более. Для чего-то сложнее — уже вряд ли.

                                                          • +1
                                                            Ну так сорок лет прошло, ничего удивительного.
                                                          • +1
                                                            Всё потому, что тут рулят всякие консорциумы и прочие бюрократические комитеты. И вместо того, чтоб сразу сделать всё как надо, приходится годами искать компромиссы между кучей организаций, тянущих одеяло в свою сторону. Найденные компромиссы, естественно, оказываются убогими и костыльными, да ещё и рождаются сразу устаревшими лет на семь.
                                                            Вот если когда-нибудь WebKit займёт 99% рынка (или не WebKit, а любой другой движок), то его владелец сможет послать бюрократов на три весёлых буквы и принудительно сделать всё как надо.
                                                            А до тех пор веб-сообщество обречено жить среди завалов костылей.
                                                            • +17
                                                              Вот если когда-нибудь WebKit займёт 99% рынка (или не WebKit, а любой другой движок), то его владелец сможет послать бюрократов на три весёлых буквы и принудительно сделать всё как надо.

                                                              Было такое время. И браузер такой был. И посланы все были на три буквы. Плохо кончилось. Как плохо заканчивается любое отсутствие конкуренции. Начинается бесперспективный застой и диктат одного монополиста. Хорошо что не ушли и вернулись.
                                                              • 0
                                                                сделать всё как надо.

                                                                именно ему, не нам :)

                                                                • 0
                                                                  сразу сделать всё как надо

                                                                  Кто определит, как надо?

                                                                  • –1
                                                                    А не важно, кто именно. Главное, чтобы это был кто-то один. Одна команда. Только тогда архитектура обретёт целостность, а не будет эклектической смесью кучи разных концепций, зачастую вообще взаимоисключающих. И костыли не понадобятся.
                                                                    Именно в этом и заключался секрет успеха Flash — он делался одним разработчиком, поэтому продукт получился целостным.
                                                                    Я понимаю, что Microsoft, по каким-то причинам забившая на Веб вообще, сильно напугала разработчиков. Что многие до сих пор покрываются холодным потом при одной мысли об IE 6. Однако это — не правило, а лишь весьма досадное исключение. Образно говоря, мы могли бы получить DirectX, а вместо этого в MS гоняли балду, пока всё не скатилось к варианту OpenGL.
                                                                    • +3
                                                                      А не важно, кто именно. Главное, чтобы это был кто-то один. Одна команда.

                                                                      И почему вы считаете, что их "надо" совпадет с вашими задачами?


                                                                      И костыли не понадобятся.

                                                                      Понадобятся — для того, чтобы реализовывать то ваше "надо", которое эта команда забыла учесть.

                                                                      • 0
                                                                        Образно говоря, мы могли бы получить DirectX, а вместо этого в MS гоняли балду, пока всё не скатилось к варианту OpenGL.

                                                                        Справедливости ради, это как раз-таки Майкрософт извратила DOM и отвергла концепции Netscape. И теперь, например, DOM очень тормозной и его нельзя толком ускорить, потому что коллекции в нём (например, NodeList) должны автоматически обновляться. Отсюда возникла потребность во всяких ангулярах и реактах, которые могут щадящим образом обновлять модель документа.

                                                                        • +1
                                                                          Ваша ошибка в том, что вы наивно полагаете, что возможности браузера преимущественно определяет некая сильная техническая команда, искренне озабоченная тем, что бы сделать мир чище и лучше. Даже если оставить в стороне тот факт, что понятие 'лучше' у каждого своё, всё равно в жизни, увы, это не так.
                                                                          В жизни, ключевые решения, в большей мере принимаются бизнесом с точки зрения зарабатывания денег. А деньги всегда хочется заработать побыстрее. Посему, в отсутствии конкуренции и противовесов, решения будут приниматься исходя из сиюминутной жадности. Так уж мы устроены. Уже как раз сто лет как это наглядно демонстрируется. Пора бы и выводы сделать.

                                                                          PS: И даже эта техническая команда не святым духом питается. Далеко не все будут работать за идею. Некоторая часть, почему-то, захочет ещё и денег.
                                                                          • 0

                                                                            Вообще-то правило. Когда есть кто-то один, люди, там работающие, редко видят мотивацию делать лучше — не с кем сравнивать. Они же уже делают круто. И все достаточно быстро скатывается.

                                                                            • 0
                                                                              лавное, чтобы это был кто-то один. Одна команда. Только тогда архитектура обретёт целостность, а не будет эклектической смесью кучи разных концепций, зачастую вообще взаимоисключающих.
                                                                              А все кто посмеет не согласится с этим кем-то-одним и его мироустройством, как например я или автор этой статьи, могут идти куда? Строить свой альтернативный браузер?
                                                                              • –3
                                                                                Если это решение будет достаточно универсальным, чтобы покрывать, допустим, 80% потребностей, то это гораздо лучше нынешнего бедлама.
                                                                                • +2

                                                                                  А с остальными 20% что делать?

                                                                                  • –1
                                                                                    А остальные 20% потребуют 80% усилий :-) Вплоть до написания собственного браузера.
                                                                                    • +2

                                                                                      После чего все вернется на предыдущую стадию. И где профит?

                                                                                      • –1
                                                                                        Почему вернется? Универсальное решение-то останется, и будет верно служить людям.
                                                                                        • 0

                                                                                          Потому что будет неопределенное множество неуниверсальных, с которыми тоже придется считаться.

                                                                                          • 0
                                                                                            Неуниверсальных, значит, специализированных, применимых для узкого круга задач. А по-другому никак. Если делать универсальное решение под браузер, которое будет применимо для 100% задач, то это вообще невозможно или результат будет настолько низкоуровневым, что никому будет не нужен.
                                                                                            • 0
                                                                                              Неуниверсальных, значит, специализированных, применимых для узкого круга задач.

                                                                                              Не совсем так. В реальности людям всегда будет нужно "80% и еще немного", поэтому будут появляться "браузеры", покрывающие 80% (не обязательно так же, как универсальное решение) + ту часть, которая нужна их разработчикам. Соответственно, разработчики "сервиса", работающего с этим "браузером", будут ориентироваться на то, как 80% имплементированы там (потому что это проще). Так и расползется.

                                                                                            • 0
                                                                                              Вы двое, с gatoazul, куда-то не туда повернули. :) Потому что спрашивать про 20% и 80% нужно при условии, что существующее решение покрывает 100% запросов (ну или хотя бы больше 80%), а это не так, о чем и написал автор статьи. :)
                                                                                              • 0

                                                                                                Вас не смущает, что gatoazul — это и есть автор статьи?

                                                                                                • 0
                                                                                                  Нет, а должно смущать?
                                                                                                  А, кажется понял. Нет, это намеренное абстрагирование. :)
                                                                                    • +1
                                                                                      это гораздо лучше нынешнего бедлама

                                                                                      Ровно до тех пор пока вы в счастливых 80%, вам будет "гораздо лучше". Как только вам понадобится сделать что-то из неохваченных 20%, то все нытье начнется заново: убогая платформа, костыль на костыле.

                                                                                      • 0
                                                                                        Разумеется. Но как по-другому?
                                                                                        • 0

                                                                                          Так текущее состояние веб-платформы вполне удовлетворяет потребности 80% сайтов. Лишь 20%, которые не сайты, а веб-приложения с трудом вписываются.


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


                                                                                          И ради чего тогда это затевать?

                                                                                          • 0
                                                                                            Если что-то радикально перекраивать, то это может негативно затронуть те самые 80% обычных сайтов, которые в общем-то и сейчас неплохо работают.
                                                                                            Те 80% сайтов, которые и так работают никто не предлагает перекраивать. Речь идёт о 80% решении для 20%, которые «не вписались»…
                                                                                            • 0

                                                                                              Статья завершается параграфом


                                                                                              Если, наконец, производители браузеров выкинут всё накопившееся старьё и напишут с нуля нормальную интерфейсную среду

                                                                                              то есть никакой обратной совместимости в идеальном плане автора.

                                                                                              • 0
                                                                                                И это даже сработает! Наверное. Ну, хотя бы есть успешный пример среди осей — BeOS. Нкакой легаси не было, сделали с нуля и — все летало. :)
                                                                                                • 0

                                                                                                  В Mozilla тоже пробуют переписать браузер с нуля: project servo.


                                                                                                  Насколько я понимаю, под словами "выкинут накопившееся старьё" автор имел в виду не легаси код, а легаси веб стандарты, которые вынуждены поддерживать существующие браузеры.


                                                                                                  Перестать их поддерживать, не сломав при этом часть сайтов в интернете — не получится.

                                                                                                  • 0
                                                                                                    Угу, я на них надеюсь, но что-то там все мрачнее с каждым годом… :)
                                                                                                    Ну в общем случае легаси — как нечто, что требует совместимости за счет каких-то ресурсов.
                                                                                                    Да в принципе может получиться, но придется как бы заморозить «старый» интернет и параллельно отображать «новый», это как два движка в одном браузере, такие даже были, хотя это и не про контекст… :)
                                                                                                • 0
                                                                                                  А её и не надо. Делаем новую среду со своим движком, когда на неё все переходят — убираем старую.

                                                                                                  Да собственно всё уже сделано, осталось только дождаться пока его можно будет использовать вместо HTML+JS+CSS…
                                                                                                  • +1

                                                                                                    По ссылке рассказывается про Android Instant Apps. Если серьезно рассматривать это как альтернативу текущей веб-платформе, то остается вопросов больше чем ответов.


                                                                                                    1. Откуда загружаются данные? Насколько я понял, с серверов Гугла. То есть доступность вашего сервиса будет зависеть от милости Гугла. Это не ок.
                                                                                                    2. Какой размер у типичного android-приложения? Из этой статьи cледует что hello world весит 1,5 мегабайта. В то время как современный сайт загружает около 500 килобайт и это уже кому-то кажется много.
                                                                                                    3. А что с десктопом? По ссылке рассказывается только про Android-девайсы, поддержки iPhone или десктопов там не видно.
                                                                                                    • 0
                                                                                                      Откуда загружаются данные? Насколько я понял, с серверов Гугла. То есть доступность вашего сервиса будет зависеть от милости Гугла. Это не ок.
                                                                                                      Во-первых, как показывает успех iPhone — многих это устраивает. Во-вторых — ничто не мешает развить технологию и сделать возможным установку и из других источников.

                                                                                                      Какой размер у типичного android-приложения? Из этой статьи cледует что hello world весит 1,5 мегабайта. В то время как современный сайт загружает около 500 килобайт и это уже кому-то кажется много.
                                                                                                      А 500 килобайт — это уже минифицированная версия? Да и в той же статье — если удалить AppCompat — то будет 108К, что уже более, чем сравнимо с современными «гостевыми книгами».

                                                                                                      А что с десктопом? По ссылке рассказывается только про Android-девайсы, поддержки iPhone или десктопов там не видно.
                                                                                                      Вот поэтому я говорю: " осталось только дождаться пока его можно будет использовать вместо HTML+JS+CSS"…

                                                                                                      Процесс идёт. Медленно (хотя по историческим меркам — достаточно быстро: с нуля до половины — за 8 лет… надо полагать переход с половины до конца примерно столько же времени займёт), но уверенно.
                                                                              • +2
                                                                                Годное описание того, почему я 9 лет назад забил на Веб несмотря на все его радужные перспективы в те годы. И не жалею.
                                                                                Но одно обидно: за столько лет веб-разработка не устаканилась до состояния внутренней согласованности. И не скоро устаканится. Но, как говорится, не было бы счастья, да несчастье помогло: десктоп тоже не особо устаканился.
                                                                                В общем, пошёл дальше пилить формочки да консольки.
                                                                                • 0
                                                                                  Эх… «бросить бы все и уехать в урюпинск» (с)
                                                                                  • 0
                                                                                    Что у нас по формочкам сегодня в тренде? WPF, Qt?
                                                                                  • –10
                                                                                    Все недостатки, которые вы указали, при желании можно решить с помощью того же тьюринг-полного джаваскрипта. Нет стандартного протокола обмена? Ну так изобретите его и реализуйте в виде библиотеки с любыми нужными вам фичами. Нет библиотеки виджетов? Ну это вовсе несерьёзно, библиотек виджетов на JS полным полно, пишите свои, если чего-то не хватает. Зачем вам новые теги? Пишите <div data-tag="mytag" data-attr1="value1"> и т.д., оверхед совсем несерьёзный ну или сделайте препроцессор, всё равно там всё препроцессируется так или иначе и от этого никуда не деться, не писать же на ES5 в 2017 году.

                                                                                    JavaScript даёт вам все нужные возможности. Лет 15 назад можно было жаловаться, что он медленный, но сегодня он быстрый, сегодня если что и тормозит, то это C++ в браузере, а не JavaScript. И на этих возможностях построено множество фреймворков. А то, что их множество и все не идеальны говорит только о том, что задача построения пользовательского интерфейса сложнее, чем вы пытаетесь её представить. View это только самый примитивный подход. Вот попросят вас сделать offline сайт, чтобы на айфоне в метро продолжал работать и уже у вас не View а полноценное приложение. То, что вы назвали MVC называется трёхзвенной архитектурой и браузер тут это звено, а не просто View. Если у вас он только View, вам повезло, но не всем так везёт.

                                                                                    Нет никакой причины тащить какие-то стандартные библиотеки элементов в браузеры. Нет уже давно стандартных элементов, посмотрите на коммерческие приложения — в каждом свой стиль, в каждом свои кнопки. Да и не было никогда, вспомните самый популярный медиаплеер 90-х WinAMP, в котором из стандартного был только диалог открытия файлов. Вспомните Microsoft Office, который в своё время на все эти стандарты наплевал, выпустив ни на что не похожий интерфейс. Так и тут — не нужны никому стандартные элементы. Я бы даже сказал — если браузеру будет проще рисовать разметку из одних div-ов, то нужен облегчённый режим, вообще без всяких предрассчитанных стилей, всё равно крупные проекты пишут всё своё, а мелкие используют всякие бутстрапы. Хотя скорее всего браузеру всё равно, посему текущая ситуация каких то проблем не имееет.
                                                                                    • +1
                                                                                      1) Браузер — это не View, а Controller.
                                                                                      2) Ваша портянка про стандартные библиотеки элементов — полное противоречие и реальности и тому, что в статье написано.
                                                                                      Сейчас браузер предоставляет стандартный набор элементов и всё. Если тебе не хватает — ССЗБ. Задача про «поменять цвет кнопки при нажатии на другую» — это как раз оттуда. Браузер дает стандартные контролы и минимум возможности как-то их расгирять и изменять.
                                                                                      • 0
                                                                                        Имхо vsb все правильно пишет. Людям хочется красивых нестандартных кнопок, и если обычные баттоны не поддерживают достаточную кастомизацию — их просто не используют.