Парадный портрет автора, заодно иллюстрирующий идею современной веб-разработки
Сразу честно признаюсь: я существо отсталое. Ну чтобы потом меня пальцами на этот счет не тыкали. Программировать я начал чуть позже изобретения палки-копалки, но намного раньше постройки пирамид — в общем, когда еще птеродактили по небу летали.
Несмотря на некоторые недостатки — в виде ревматизма и отсиженного перед монитором зада — такой опыт дает и отдельные преимущества. Можно уютно расположившись в теплом болоте с умилением смотреть, как перед глазами мельтешат молодые и прогрессивные, неистово изобретая очередной велосипед с квадратными колесами.
Я с интересом ознакомился с эпохальной статьей "Объясняем современный 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 ?
Комментарии (186)
prefrontalCortex
07.11.2017 13:43Практически отсутствуют, если не считать вездесущий, который,
У вас, кажется, парсер что-то не то съел.
mayorovp
07.11.2017 13:44С аргументами в целом согласен — но я не понимаю как из них следуют выводы.
Вот есть технология X. Которая упрощает разработку. Почему от нее надо отказаться только на основании того что она не делает Y?
gatoazul Автор
08.11.2017 11:00-1Вообще-то выводы чуть другие. Технология X — это костыль, и ничем, кроме костыля она не будет, потому что задача на этом уровне (библиотек JS к уже готовой экосистеме) не решается.
А дальше уже каждый думает для себя — готов ли он с этим костылем жить и дальше, учитывая, что Y нет и не будет, и не питать иллюзий о быстрой и производительной веб-разработке, или же заниматься чем-то другим.mayorovp
08.11.2017 11:05Под «заниматься чем-то другим» вы подразумеваете уйти из веба? Да, это вариант. Но до тех пор пока вы в вебе — надо пользоваться тем что упрощает разработку. Пусть это и костыли.
gatoazul Автор
08.11.2017 12:19Уйти из веба. Попробовать какие-то другие технологии. Сразу закладываться на то, что разработка фронтэнда на имеющихся инструментах будет занимать *3 времени и сил, и планировать под нее соответствующие ресурсы.
Главное — сознавать ограничения и не вестись на рекламу.
PretorDH
07.11.2017 13:45+2Автор начал за упокой, закончил за здравие.
Говорил правильно но закончил слегка не тем.
Проблема не в самих языках HTML, CSS, JS или их ущербности. А в том, что много фич просто находится на полпути к готовому продукту. И вместо того, что бы взять и за «5 минут» допилить существующие, все усилия сообщества ГОДАМИ уходят на изобретение велосипедов (В этом я с автором согласен).
Это как пришли болты, но без резьбы, и их приходится кувалдой заколачивать. Зато если стал на место то перманентно на века. А если не стал…победа.
P.S. Вся «стройная» структура JS заточена на то, чтобы быстро обрабатываться интерпретатором. И только… Смысла менять её НЕТ. А то, что кому-то не удобно, это его проблемы (пусть сломает себе мозг).
Хорошему танцору и кегли в радость!
Free_ze
07.11.2017 15:16А в том, что много фич просто находится на полпути к готовому продукту.
Они так же устареют еще до того, как наконец наступит «коммунизм».
vlreshet
07.11.2017 14:32+8Когда вам кажется что веб застрял где-то в мезозое — просто взгляните на ситуацию с почтовыми клиентами в 2017ом году, и успокойтесь) Там вообще до сих пор таблицами верстают, и каждый раз нет гарантии что оно правильно отобразится, потому что каждый клиент режет html как хочет.
nuclight
08.11.2017 10:40Отсюда автору статьи более радикальный вывод — «выкинуть всё и с нуля» надо начиная с html!
И ведь, если задуматься, то, на самом-то деле это вовсе не так безумно, как может показаться на первый взгляд. Ведь:
Отвечаю. По сравнению с куда более мощными и тщательно разработанными десктопными интерфейсами у веба есть два мощных козыря: идеальная независимость от платформы и ненужность инсталляции приложений
Во-первых, идеальной независимости от платформы нет и у веба, если не от ОС, то от браузера (свежа еще память об IE6?). Во-вторых, как показал опыт мобильных гаджетов, «ненужность инсталляции приложений» вовсе не являет собой непреодолимую преграду для пользователей — буквально на каждом углу висят призывы «скачайте наше мобильное приложение!». То есть вопрос, на самом деле, можно поставить так: как сделать это проще?.. Ведь что такое загрузка современного сайта по своей сути? Это всего лишь скачивание самой последней (текущей) версии приложения, написанного на JavaScript!
А теперь давайте пофантазируем: представим, что какая-то из упомянутых автором технологий, ну например Tcl/Tk, будучи кроссплатформенной и скриптовой, может каким-то образом, аналогично сайту, скачиваться на любое устройство пользователя, хоть Android, хоть десктоп на Windows или Linux, и тут же отображать пользователю GUI. Представили? Ведь это же и будет тот самый убийца Web, так как решает те же задачи!
Oh, wai~~gatoazul Автор
08.11.2017 10:52Не только Tcl, но и Rebol. Диалект последнего Red уже работает на Андроиде.
Tallefer
08.11.2017 23:00Спасибо за упоминание Ребола и РЕДа, ну и XUL-а, причем — в правильном контексте. :)
И спасибо за статью, очень верно разложено все. И еще очень хорошо, что автор сам тоже занимался веб-разработкой, чтобы нельзя было нахрапом к нему применить спервадоб-аргумент. :)
sena
08.11.2017 15:11А теперь давайте пофантазируем: представим, что какая-то из упомянутых автором технологий, ну например Tcl/Tk, будучи кроссплатформенной и скриптовой, может каким-то образом, аналогично сайту, скачиваться на любое устройство пользователя, хоть Android, хоть десктоп на Windows или Linux, и тут же отображать пользователю GUI. Представили? Ведь это же и будет тот самый убийца Web, так как решает те же задачи!
Так это же и пытались сделать Ява-апплеты и Флэш. Основным недостатком Ява-апплетов, на мой взгляд была излишняя громоздкость (в сравнении с Питоном или Тсл/Тк), основным недостатком Флэш была закрытость. Но в целом они именно это и делали.
Легковесный контейнер, жёстко, на уровне железа изолирующий скачиваемое приложение от клиентской машины и предоставляющий ограниченный, контролируемый системой прав доступа и квот интерфейс к устройствам на клиенте (можно дополнить его встроенным легковесный интерпретатор типа Питона/TclTk) по идее должен бы решить проблему безопасности. Но это будет громоздкая конструкция. Если же такой контейнер соорудить, то почему бы тогда не разрешить запускать в нём бинарные файлы?
Кстати, что-то я не вижу, чтобы всякие игрушки, типа огорода на ок.ру, написанные на Флэш, активно переписывались на HTML5, что ставит под сомнение утверждение о том что HTML5 может его заменить…
sshikov
08.11.2017 21:08HTML5 может его заменить…
Да он его, честно говоря, даже в области бизнес-приложений (т.е. Flex) все еще не может заменить полноценно. Т.е. там, где не нужна ни быстрая графика, ни видео стримы, ни все такое. Потому что фреймворк виджетов в Flex, и сам набор виджетов, которые там были (в том числе — и написанные пользователями) был настолько хорош уже к 2009 году, что мы и сегодня ничего подобного не имеем.
redmanmale
08.11.2017 13:11Потому что в письмах должен быть только текст. Тогда и проблем с вёрсткой не будет.
Tallefer
08.11.2017 23:03+1Пожалуй, я бы согласился на RsT. Ну или MD, ладно.
acmnu
09.11.2017 10:15Там кстати rich text есть. Не все об этом знают, но подавляющее большинство клиентов поддерживает простое форматирование (жирный/курсив и т.д.) в соответствии с каким-то богом забытым стандартом.
Tallefer
09.11.2017 13:52Хм, я думал это только в аутлуке. Но все равно, это же просто альтернатива хтмл, не?
maxfox
07.11.2017 20:51+2Если есть люди, говорящие «в этом вашем вебе все через ж...», то, наверное, есть в IT какая-то область, где все хорошо. Расскажите, пожалуйста, что это за область, я обязательно переквалифицируюсь.
А пока все ищут ту самую работу мечты, я поделюсь мыслями о вебе:
1. Доля open-source в вебе как на клиенте, так и на сервере близка к 100%. И мне это очень нравится. Какой еще сегмент IT может похвастаться тем, что проприетарный код там вообще не котируется?
2. Огромное, дружелюбное и открытое сообщество (я, конечно, имею в виду англоязычное ;) ).
3. Вакансии на любой вкус. Зарплаты, на которые вполне можно жить.
4. В конце концов, здесь реально что-то происходит. А какие последние новости, например у разработчиков SCADA? И, кстати, где их можно почитать?
Я, конечно, еще довольно молод, но я помню веб эпохи диал-апа и IE5. Так вот: веб стал лучше. Намного лучше.
AllexIn
08.11.2017 08:19Если есть люди, говорящие «в этом вашем вебе все через ж...», то, наверное, есть в IT какая-то область, где все хорошо.
В геймдеве вроде всё вполне себе норм. Не могу припомнить никаких особых архитектурных проблем. Даже от вечной обратной совместимости GAPI уже ушли.
Satim
08.11.2017 10:40А с чьей точки зрения веб стал лучше?
Моя точка зрения пользователя такая что с каждым годом веб становится все тяжелым и неуклюжим. Раньше мне не доставляло проблем запустить 20 вкладок и работать с ними. И я не парился что мне не хватит памяти и все зависнет и упадет. А сейчас даже закрытие вкладки зачастую не означает что память освободится. И теперь для работы в вебе мне нужно 8 гиг памяти…Alexey2005
08.11.2017 11:20Потому что веб-сайты превратились в веб-сервисы. Проблема тормозов (например, если вы сидите на Eee PC с 1Гб памяти) решается отказом от веб-сервисов: в браузере просматриваются лишь странички, а для сервисов используются отдельные приложения.
Так, вместо тормознутых почтовых веб-сервисов типа GMail используется старый добрый почтовый клиент. Хотя по нынешним временам стало очень трудно найти почтовик без встроенного браузера со всеми его тормозами, так на вскидку кроме Sylpheed ничего и не припомню.
Для просмотра лент с соцсетей и новостных лент используется RSS-агрегатор. Хотя по нынешним временам крайне сложно найти RSS-клиент без встроенного браузера — я не знаю ни одного GUI-клиента, который не тянул бы с собой тормознутый браузерный движок.
Вместо youtube и подобных видеосервисов используется потоковый плеер.
Ну и всё в том же духе. Большинство веб-сервисов заменяется автономными приложениями, а немногие статические странички просматриваются в links2 или подобном браузере, который отлично их рендерит, даже с графикой. В таком режиме можно хоть с Raspberry Pi комфортно в Интернете сидеть.balexa
08.11.2017 13:09Так, вместо тормознутых почтовых веб-сервисов типа GMail используется старый добрый почтовый клиент.
Это все хорошо, когда у вас один стационарный компьютер. Сейчас же, один и тот же почтовый ящик должен быть доступен с нескольких устройств, как минимум это комп и смартфон.K0styan
08.11.2017 14:57А в чём тут проблема? Даже на древнем POP3 никто не заставлял письма с сервера удалять сразу же после загрузки, а уж с IMAP вообще проблем нет.
balexa
10.11.2017 16:51А зачем мне на смартфоне все письма целиком? Где хранить черновики? Почему нельзя написать письмо на компе, а дописать и отправить его со смартфона? Проблема в том, что вы решаете непонятную проблему, непонятно зачем. Ну то есть если у вас десятилетний eee pc и нет возможности купить ничего новее, то понятно. Но это какой-то исключительный случай. Большинству людей удобнее пользоваться почтой в облаке, пользоваться ютубом вместо настройки потокового плеера и так далее. Значит и разработчики будут делать сервисы под них.
Вы предлагаете решить «проблему» радикально — все сжечь, написать заново, пользоваться линксом. Зачем, для чего, какую проблему это решает?
В таком режиме можно хоть с Raspberry Pi комфортно в Интернете сидеть.
Можно. Но опять таки, для чего? Проблема памяти, на которую жалуется автор выше решается гораздо проще.khim
10.11.2017 17:53+1А зачем мне на смартфоне все письма целиком? Где хранить черновики? Почему нельзя написать письмо на компе, а дописать и отправить его со смартфона?
Это хорошие вопросы, но они не обьясняют — зачем вам для всего этого гонять туда-сюда мегабайты кода. Драфт записать на сервер — отлично, но зачем для этого весь UI с сервера скачивать каждый раз, когда вы почту хотите почитать…
Впрочем GMail на смартфоне и не скачивает и HTML5 для UI не пользуется… что как бы и показывает ненужность всего «котла», который обсуждается в статье…balexa
10.11.2017 23:24А оно и не скачивает каждый раз и ничего не гоняет. Это легко проверить, нажмите F12 — увидите что ничего из вашего юая не скачивается, все берется из дискового кеша.
Впрочем GMail на смартфоне и не скачивает и HTML5 для UI не пользуется
Да все то же самое. Не считая того, что это приложение точно так же надо скачать (хотя конкретно это уже поставили за вас). А у разработчиков опционально добавляется геморрой в виде поддержки нескольких версий апи.
И да, gmail приложение не использует IMAP, а использует свой внутренний протокол, насколько мне известно. А это значит, что для другой почты мне нужно другое приложение. Которое опять надо скачать и обновлять. И с которым нет нужной функциональности. Или у вас есть в имапе возможность сохранять драфт на сервер и создавать правила?khim
11.11.2017 02:44Это легко проверить, нажмите F12 — увидите что ничего из вашего юая не скачивается, все берется из дискового кеша.
А вы проверьте. Мой эксперимент — первый запуск при «пустом» кеше скачивается порядка 10 мегабайт, повторное открытие сразу после этого — где-то мегабайта два.
Или, что ещё проще, перестаньте полагаться на F12, а просто подключитесь к телефону на 2G и испытайте весь «amazing experience» современных веб-технологий.
Да все то же самое. Не считая того, что это приложение точно так же надо скачать (хотя конкретно это уже поставили за вас). А у разработчиков опционально добавляется геморрой в виде поддержки нескольких версий апи.
Это временно.
А это значит, что для другой почты мне нужно другое приложение. Которое опять надо скачать и обновлять.
Но вы можете контролировать этот процесс, хотя бы.
Да все то же самое.
Всё — но не всё. Инструменты разработки — невероятно убоги. Ресурсы, необходимое для запуска приложений — отличаются на порядки (либо, что чаще, нативное приложение на пару порядков больше умеет).
Сравните хотя бы MS Office и Google Docs. Я, кстати, активно пользуюсь Google Docs — так как тот факт, что за них не нужно платить и их не нужно устанавливать часто решает… но над второй проблемой уже работают, а первая, как бы, к качеству технологий вообще отношения не имеет.
Tallefer
08.11.2017 23:07К огромному счастью, гмыло до сих пор позволяет ходить через хтмл-интерфейс. Если бы его убрали (тьфу-тьфу-тьфу), не представляю, как бы я это пережил… :)
justboris
08.11.2017 11:59-1А у меня 20 вкладок открыты и ничего не тормозит.
Чтобы проблема была признана официально, она должна воспроизводиться у значительного числа пользователей
DMGarikk
08.11.2017 12:20Попробуйте воспроизвести на компьютера без SSD и не более 4Гб оперативки.
justboris
08.11.2017 12:52У меня был Mac Mini 2012 года выпуска, в нем как раз 4 Гб памяти и нет SSD.
Стандартный набор: браузер, почта, мессенджер — работал нормально. По памяти затык случался только при просмотре FullHD видео или открытом фотошопе.
DMGarikk
08.11.2017 13:05у меня на работе есть MacBook Pro 2012 года с 4Гб памяти и без SSD, иногда хочется его об стенку швырнуть… (мой личный мак точно такойже с SSD и домашний комп (с виндой) тоже с SSD… земля и небо)
justboris
08.11.2017 14:04С этим согласен, больше памяти лишним не будет, программы станут отзывчивее.
Однако, я не понимаю как из утверждения "программы жрут все больше памяти" следует "веб тяжелый и неуклюжий". Только браузерам нужна память? Остальные программы по-прежнему вмещаются в 640 килобайт?
DrPass
08.11.2017 14:57Просто у браузеров это выражено ярче всего. Странички с куцым функционалом занимают сотни мегабайт. И да, при этом они зачастую тяжелые и неуклюжие.
gatoazul Автор
08.11.2017 15:11Де-факто браузер открыт постоянно, остальные программы (кроме мессенджеров) — лишь иногда.
justboris
08.11.2017 15:50Если браузер открыт постоянно, то почему бы ему не выделить больше памяти, раз он вам нужен? Звучит справедливо.
Кроме того, прочтя раздел "Есть ли свет в конце туннеля?", я так и не увидел предпосылок к снижению потребления памяти. DSL для построения интерфейсов, иерархия виджетов — выглядит как повод для браузеров сожрать еще больше памяти, которой и так немного.
Satim
10.11.2017 15:14я так и не увидел предпосылок к снижению потребления памяти.
Это то и грустно…
Раньше страница которая жрет 100мг памяти считалась написанной дилетантами и студентами, теперь это норма. А по факту ничего снаружи не поменялось…
maxfox
08.11.2017 13:08Мне просто любопытно, какие именно 20 вкладок мне надо открыть, чтобы что-то стало тормозить… Ни разу не сталкивался, ноут 2012 года, 6 Гб памяти, SSD.
Я абсолютно серьезно, расскажите.sshikov
08.11.2017 21:13Не могу вам ответить конкретно, но субъективные ощущения примерно такие же. Несколько лет назад тоже не закрывал вкладки никогда, и держал их по 100 штук. Были периоды, когда Firefox на этом падал, но были и периоды, когда это стабильно жило месяцами. А сейчас при 20-30 вкладках подмывает позакрывать.
Ваши 6 гигов и SSD, кстати, могут достаточно сильно менять дело.
Eldhenn
08.11.2017 13:15> В конце концов, здесь реально что-то происходит.
Фреймворки по раскрашиванию кнопочек устаревают быстрее, чем пишется статья про них?
sshikov
07.11.2017 21:00то, о чем я слышал: терминалы IBM 3270, Смоллтолк, экранный Постскрипт, WinAPI, TurboVision, VisualBasic, dBase, Tcl/Tk, XUL, Rebol/View, XAML
Ну, передергивать-то не стоило. Я вот не просто слышал, но и вполне застал 3270, и скажем DMS для них. Да, надо сказать, что DMS + REXX в качестве языка разработки формочек и интерактивных приложений вполне бы сгодились и сегодня… для кассы например. Не более. Для чего-то сложнее — уже вряд ли.
Alexey2005
07.11.2017 21:06Всё потому, что тут рулят всякие консорциумы и прочие бюрократические комитеты. И вместо того, чтоб сразу сделать всё как надо, приходится годами искать компромиссы между кучей организаций, тянущих одеяло в свою сторону. Найденные компромиссы, естественно, оказываются убогими и костыльными, да ещё и рождаются сразу устаревшими лет на семь.
Вот если когда-нибудь WebKit займёт 99% рынка (или не WebKit, а любой другой движок), то его владелец сможет послать бюрократов на три весёлых буквы и принудительно сделать всё как надо.
А до тех пор веб-сообщество обречено жить среди завалов костылей.
Steamus
07.11.2017 21:13+3Вот если когда-нибудь WebKit займёт 99% рынка (или не WebKit, а любой другой движок), то его владелец сможет послать бюрократов на три весёлых буквы и принудительно сделать всё как надо.
Было такое время. И браузер такой был. И посланы все были на три буквы. Плохо кончилось. Как плохо заканчивается любое отсутствие конкуренции. Начинается бесперспективный застой и диктат одного монополиста. Хорошо что не ушли и вернулись.
lair
07.11.2017 21:58сразу сделать всё как надо
Кто определит, как надо?
Alexey2005
07.11.2017 22:19А не важно, кто именно. Главное, чтобы это был кто-то один. Одна команда. Только тогда архитектура обретёт целостность, а не будет эклектической смесью кучи разных концепций, зачастую вообще взаимоисключающих. И костыли не понадобятся.
Именно в этом и заключался секрет успеха Flash — он делался одним разработчиком, поэтому продукт получился целостным.
Я понимаю, что Microsoft, по каким-то причинам забившая на Веб вообще, сильно напугала разработчиков. Что многие до сих пор покрываются холодным потом при одной мысли об IE 6. Однако это — не правило, а лишь весьма досадное исключение. Образно говоря, мы могли бы получить DirectX, а вместо этого в MS гоняли балду, пока всё не скатилось к варианту OpenGL.lair
07.11.2017 22:21А не важно, кто именно. Главное, чтобы это был кто-то один. Одна команда.
И почему вы считаете, что их "надо" совпадет с вашими задачами?
И костыли не понадобятся.
Понадобятся — для того, чтобы реализовывать то ваше "надо", которое эта команда забыла учесть.
staticlab
07.11.2017 22:50Образно говоря, мы могли бы получить DirectX, а вместо этого в MS гоняли балду, пока всё не скатилось к варианту OpenGL.
Справедливости ради, это как раз-таки Майкрософт извратила DOM и отвергла концепции Netscape. И теперь, например, DOM очень тормозной и его нельзя толком ускорить, потому что коллекции в нём (например, NodeList) должны автоматически обновляться. Отсюда возникла потребность во всяких ангулярах и реактах, которые могут щадящим образом обновлять модель документа.
Steamus
08.11.2017 01:16Ваша ошибка в том, что вы наивно полагаете, что возможности браузера преимущественно определяет некая сильная техническая команда, искренне озабоченная тем, что бы сделать мир чище и лучше. Даже если оставить в стороне тот факт, что понятие 'лучше' у каждого своё, всё равно в жизни, увы, это не так.
В жизни, ключевые решения, в большей мере принимаются бизнесом с точки зрения зарабатывания денег. А деньги всегда хочется заработать побыстрее. Посему, в отсутствии конкуренции и противовесов, решения будут приниматься исходя из сиюминутной жадности. Так уж мы устроены. Уже как раз сто лет как это наглядно демонстрируется. Пора бы и выводы сделать.
PS: И даже эта техническая команда не святым духом питается. Далеко не все будут работать за идею. Некоторая часть, почему-то, захочет ещё и денег.
Hardcoin
08.11.2017 10:34Вообще-то правило. Когда есть кто-то один, люди, там работающие, редко видят мотивацию делать лучше — не с кем сравнивать. Они же уже делают круто. И все достаточно быстро скатывается.
dravor
08.11.2017 10:42лавное, чтобы это был кто-то один. Одна команда. Только тогда архитектура обретёт целостность, а не будет эклектической смесью кучи разных концепций, зачастую вообще взаимоисключающих.
А все кто посмеет не согласится с этим кем-то-одним и его мироустройством, как например я или автор этой статьи, могут идти куда? Строить свой альтернативный браузер?gatoazul Автор
08.11.2017 12:23Если это решение будет достаточно универсальным, чтобы покрывать, допустим, 80% потребностей, то это гораздо лучше нынешнего бедлама.
lair
08.11.2017 12:28А с остальными 20% что делать?
gatoazul Автор
08.11.2017 15:07А остальные 20% потребуют 80% усилий :-) Вплоть до написания собственного браузера.
lair
08.11.2017 15:08+1После чего все вернется на предыдущую стадию. И где профит?
gatoazul Автор
08.11.2017 17:13-1Почему вернется? Универсальное решение-то останется, и будет верно служить людям.
lair
08.11.2017 17:39Потому что будет неопределенное множество неуниверсальных, с которыми тоже придется считаться.
gatoazul Автор
08.11.2017 21:07Неуниверсальных, значит, специализированных, применимых для узкого круга задач. А по-другому никак. Если делать универсальное решение под браузер, которое будет применимо для 100% задач, то это вообще невозможно или результат будет настолько низкоуровневым, что никому будет не нужен.
lair
09.11.2017 12:16Неуниверсальных, значит, специализированных, применимых для узкого круга задач.
Не совсем так. В реальности людям всегда будет нужно "80% и еще немного", поэтому будут появляться "браузеры", покрывающие 80% (не обязательно так же, как универсальное решение) + ту часть, которая нужна их разработчикам. Соответственно, разработчики "сервиса", работающего с этим "браузером", будут ориентироваться на то, как 80% имплементированы там (потому что это проще). Так и расползется.
justboris
08.11.2017 17:41+1это гораздо лучше нынешнего бедлама
Ровно до тех пор пока вы в счастливых 80%, вам будет "гораздо лучше". Как только вам понадобится сделать что-то из неохваченных 20%, то все нытье начнется заново: убогая платформа, костыль на костыле.
gatoazul Автор
08.11.2017 21:07Разумеется. Но как по-другому?
justboris
08.11.2017 21:15Так текущее состояние веб-платформы вполне удовлетворяет потребности 80% сайтов. Лишь 20%, которые не сайты, а веб-приложения с трудом вписываются.
Если что-то радикально перекраивать, то это может негативно затронуть те самые 80% обычных сайтов, которые в общем-то и сейчас неплохо работают.
И ради чего тогда это затевать?
khim
08.11.2017 23:08Если что-то радикально перекраивать, то это может негативно затронуть те самые 80% обычных сайтов, которые в общем-то и сейчас неплохо работают.
Те 80% сайтов, которые и так работают никто не предлагает перекраивать. Речь идёт о 80% решении для 20%, которые «не вписались»…justboris
08.11.2017 23:31Статья завершается параграфом
Если, наконец, производители браузеров выкинут всё накопившееся старьё и напишут с нуля нормальную интерфейсную среду
то есть никакой обратной совместимости в идеальном плане автора.
Tallefer
08.11.2017 23:35И это даже сработает! Наверное. Ну, хотя бы есть успешный пример среди осей — BeOS. Нкакой легаси не было, сделали с нуля и — все летало. :)
justboris
08.11.2017 23:40В Mozilla тоже пробуют переписать браузер с нуля: project servo.
Насколько я понимаю, под словами "выкинут накопившееся старьё" автор имел в виду не легаси код, а легаси веб стандарты, которые вынуждены поддерживать существующие браузеры.
Перестать их поддерживать, не сломав при этом часть сайтов в интернете — не получится.
Tallefer
08.11.2017 23:47Угу, я на них надеюсь, но что-то там все мрачнее с каждым годом… :)
Ну в общем случае легаси — как нечто, что требует совместимости за счет каких-то ресурсов.
Да в принципе может получиться, но придется как бы заморозить «старый» интернет и параллельно отображать «новый», это как два движка в одном браузере, такие даже были, хотя это и не про контекст… :)
khim
08.11.2017 23:40А её и не надо. Делаем новую среду со своим движком, когда на неё все переходят — убираем старую.
Да собственно всё уже сделано, осталось только дождаться пока его можно будет использовать вместо HTML+JS+CSS…justboris
08.11.2017 23:55По ссылке рассказывается про Android Instant Apps. Если серьезно рассматривать это как альтернативу текущей веб-платформе, то остается вопросов больше чем ответов.
- Откуда загружаются данные? Насколько я понял, с серверов Гугла. То есть доступность вашего сервиса будет зависеть от милости Гугла. Это не ок.
- Какой размер у типичного android-приложения? Из этой статьи cледует что hello world весит 1,5 мегабайта. В то время как современный сайт загружает около 500 килобайт и это уже кому-то кажется много.
- А что с десктопом? По ссылке рассказывается только про Android-девайсы, поддержки iPhone или десктопов там не видно.
khim
09.11.2017 23:43Откуда загружаются данные? Насколько я понял, с серверов Гугла. То есть доступность вашего сервиса будет зависеть от милости Гугла. Это не ок.
Во-первых, как показывает успех iPhone — многих это устраивает. Во-вторых — ничто не мешает развить технологию и сделать возможным установку и из других источников.
Какой размер у типичного android-приложения? Из этой статьи cледует что hello world весит 1,5 мегабайта. В то время как современный сайт загружает около 500 килобайт и это уже кому-то кажется много.
А 500 килобайт — это уже минифицированная версия? Да и в той же статье — если удалить AppCompat — то будет 108К, что уже более, чем сравнимо с современными «гостевыми книгами».
А что с десктопом? По ссылке рассказывается только про Android-девайсы, поддержки iPhone или десктопов там не видно.
Вот поэтому я говорю: " осталось только дождаться пока его можно будет использовать вместо HTML+JS+CSS"…
Процесс идёт. Медленно (хотя по историческим меркам — достаточно быстро: с нуля до половины — за 8 лет… надо полагать переход с половины до конца примерно столько же времени займёт), но уверенно.
a-tk
07.11.2017 21:40-2Годное описание того, почему я 9 лет назад забил на Веб несмотря на все его радужные перспективы в те годы. И не жалею.
Но одно обидно: за столько лет веб-разработка не устаканилась до состояния внутренней согласованности. И не скоро устаканится. Но, как говорится, не было бы счастья, да несчастье помогло: десктоп тоже не особо устаканился.
В общем, пошёл дальше пилить формочки да консольки.
vsb
07.11.2017 22:21Все недостатки, которые вы указали, при желании можно решить с помощью того же тьюринг-полного джаваскрипта. Нет стандартного протокола обмена? Ну так изобретите его и реализуйте в виде библиотеки с любыми нужными вам фичами. Нет библиотеки виджетов? Ну это вовсе несерьёзно, библиотек виджетов на 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-ов, то нужен облегчённый режим, вообще без всяких предрассчитанных стилей, всё равно крупные проекты пишут всё своё, а мелкие используют всякие бутстрапы. Хотя скорее всего браузеру всё равно, посему текущая ситуация каких то проблем не имееет.AllexIn
08.11.2017 08:231) Браузер — это не View, а Controller.
2) Ваша портянка про стандартные библиотеки элементов — полное противоречие и реальности и тому, что в статье написано.
Сейчас браузер предоставляет стандартный набор элементов и всё. Если тебе не хватает — ССЗБ. Задача про «поменять цвет кнопки при нажатии на другую» — это как раз оттуда. Браузер дает стандартные контролы и минимум возможности как-то их расгирять и изменять.
olegchir
08.11.2017 10:28Имхо vsb все правильно пишет. Людям хочется красивых нестандартных кнопок, и если обычные баттоны не поддерживают достаточную кастомизацию — их просто не используют.
Cryvage
08.11.2017 17:30и если обычные баттоны не поддерживают достаточную кастомизацию — их просто не используют
Вместо того, чтобы сделать базовые элементы более кастомизируемыми, вы предлагаете от них отказаться полностью, и каждому пилить что-то своё? Из-за невозможности отрегулировать седло, каждому приходится делать собственный велосипед, под свой рост. Разве это нормально?
novice2001
08.11.2017 21:46А можно узнать каким именно людям хочется таких кнопок?
Меня лично устроили бы совершенно некрасивые, лишь бы все работало быстро на любом железе, которое сейчас встречается.
А в реальности мне достаточно комфортно использовать любой сайт (ах да, веб-приложение) на стационарном i5-2500k@4Ghz с 16 Гб памяти, ноут с Pentium 3558U и 4 Гб памяти иногда ощутимо подтормаживает. Про ноуты на Atom я вообще молчу, а они есть, да.
Поэтому в гробу я видал красивые кнопочки и тех, кому они нужны. В погоне за красотой они сделали веб таким тормозным, что я даже не знаю с чем его сравнить.khim
08.11.2017 23:18А можно узнать каким именно людям хочется таких кнопок?
«Поколению Apple», условно говоря. Вот типичная ремарка: Есть еще Gerrit, который там как-то с этим борется, но интерфейс из 90х убивает все желание пользоваться этим.
Заметьте, что речь идёт об инструменте для работы с Git-репозиториями — то о гиковстве вполне себе ненулевого уровня… и тем не менее первый критерий, по которому это всё оценивается — это по параметру «модно, стильно, молодёжно»…
Поэтому в гробу я видал красивые кнопочки и тех, кому они нужны.
Увы. Их слишком много и потому всё что делается — делается под из нужды.
Времена гиков — прошли, теперь компьютеры делают для людей, которые выбирают не удобную одежду, а модную.
В погоне за красотой они сделали веб таким тормозным, что я даже не знаю с чем его сравнить.
Сравните с каким-нибудь Visual Studio 2017… и вы увидите, что тормознутость web'а — это, увы, частный случай.
Antelle
07.11.2017 23:17Любой, у кого стоит Firefox, пользуется её плодами каждый день — потому что в нём на языке XUL полностью запрограммирован пользовательский интерфейс.
Через неделю уже неактуально, из Quantum выпилили.
Tanriol
08.11.2017 10:43Пока что не соответствует действительности. Из Firefox потихоньку "выпиливают" фирменную технологию байндингов XBL (но и то ещё на ранних этапах), а XUL пока что остаётся и даже кое-где развивается (например, одной из составляющих в замене XBL станет поддержка Custom Elements в XUL). Другое дело, что с Quantum XUL окончательно становится деталью реализации, поскольку дополнения доступа к нему лишаются.
kafeman
08.11.2017 01:47+1Проект Polymer скорее мёртв, чем жив, во всяком случае для практической работы пока что не пригоден.
Вроде весь интерфейс YouTube на нем построен, разве нет?
marshinov
08.11.2017 08:40Все верно. Там проблема только в том что старая версия спецификации web components, потому что polymer сделали когда их только Хром поддерживал как раз в том числе, чтобы продемонстрировать, что технология жизнеспособна
i360u
08.11.2017 09:49Вы хоть зайдите на сайт Полимера, ради приличия, гляньте какую версию спецификаций он поддерживает и что с ним вообще происходит.
Tallefer
08.11.2017 23:21Вот с момента, как ютуб на полимер перешел (об этом я узнал от разраба качалки видео, он ругался на него), он стал ЕЩЕ медленнее работать, хотя казалось, что это невозможно. :) Страницы теперь иногда вообще не отрисовываются до конца, пока видео не КОНЧИТСЯ…
Strain
08.11.2017 02:14Вот поэтому я занимаюсь backend разработкой. Построение ПО для браузера — это программирование средствами описания гипертекстовых документов, а не программ. Ну вот например файл microsoft excel — это тоже документ. Он тоже открывается и рендерится в специализированной программе подобно тому как открывается HTML документ в веб-браузере. Да, там тоже есть возможность некоторой кастомизации поведения скриптами. Но кому придёт в голову называть microsoft excel языком программирования?
khim
08.11.2017 02:19Но кому придёт в голову называть microsoft excel языком программирования?
Нудным голосом: К вашим услугам 91 в категории «Разработка приложений», специализирующихся на услуге «Разработка приложений для Excel ».
Да, Excel нонче менее популярен, чем HTML+JS, но было время, когда на нём немало приложений писалось…kafeman
08.11.2017 03:55Это, скорее всего, разработчики их т. н. «add-ins», а не программисты на макросах :-)
khim
08.11.2017 14:15Там и тех и других хватает. Но нет — в основном это люди, которые встраивают скрипты в «продвинутую Excel-таблицу», после чего она становится таким себе «приложением для бедных»
sshikov
09.11.2017 20:59Для богатых тоже… я лично наблюдал приложение (в виде десятка excel разного назначения), где было порядка сотни тысяч строк VBA кода. И написали его простые бедные трейдеры, ни разу не программисты, математики по образованию.
И другое такое же — для оценки рисков кредитования.
DrPass
08.11.2017 02:25-1Но кому придёт в голову называть microsoft excel языком программирования?
Но VBA ведь вполне себе язык программирования. Когда говорят про программирование для браузера, имеют в виду не HTML (по крайней мере, грамотные люди), а JavaScript.
i360u
08.11.2017 10:50Это примерно как заявить, что запросы к базе данных никому не придет в голову называть программированием. В современных реалиях, фронт, нередко оказывается гораздо сложнее бека. И тут я имею в виду системную и алгоритмическую сложность, а не распухший тулчейн, который сбивает с толку.
borv
08.11.2017 04:57Разделяю ваши фрустрации! Но, боюсь, срыва покровов не произошло:
В мире веб-программирования считается хорошим тоном блуждать в трех соснах, которые называются M, V и C
Вот в них-то и проблема, и изящно избавиться от "M" и "C" вашим методом не выйдет. Во-первых "M" на бэк-енде и "M" на клиенте малость разные от слова совсем. "M" клиента обычно обрастает состояниями, про которые бэк-енд понятия не имеет. "C" не тождественно браузеру уже лет пятнадцать, с тех пор как появился AJAX и асинхронность. А вот с "V" который всем так интересен как раз все теперь относительно хорошо, по крайней мере не так плохо как на десктопе.
С моей точки зрения проблемы совсем не в экосистеме, а в архитектуре, которая ее породила:
- Где состояние, Зин? Изначально браузер (да и весь интернет) был документ-ориентированным, состояние жило на сервере, клиент был предельно тупым. Потом мир малость поменялся, и сейчас у нас stateless backend (потому что масштабирование) и stateful client (потому что пользователь так хочет). А обработка и данные по прежнему удаленные. Из-за этого нам приходится решать кучку нетривиальных задач по управлению всем этим хозяйством (распределенное состояние, асинхрон, безопасность и т.д).
- Где у этого мозги? Раньше мы обычно "говорили" с одним сервером и могли, хоть и с натяжкой, думать об этом как об RPC, можно было (с оговорками) считать сервер источником правды, рассуждать про границы транзакций, какие-то операционные контракты и т.д. Теперь работать с кучей гетерогенных сервисов, половина которых вообще не наши и в лучшем случае eventually consistent — скорее норма чем исключение. В такой ситуации источник правды переехал на клиента, равно как и добрая половина бизнес-логики, хотите вы в этом себе признаваться или нет. Так что мозги теперь повсюду.
- Один как Леонид Ильич МакЛауд. У веб приложений практически нет реальных альтернатив, т.к. только они позволяют начать взаимодействовать с пользователем без установки, консента и работают более-менее везде предсказуемо. Был шанс что мобильные устройства развернут ситуацию, но победила жадность, которая родила аппстор и устроила сегрегацию. Заменой веба им теперь не быть. Это сместило фокус в сторону веб-разработки с прицелом делать десктопный UX, что как раз породило весь зоопарк уродов. И толпы программистов которые умеют только веб программирование. Так что теперь у нас будут веб программы на десктопе. И вот я скрепя зубами следующий десктопный проект уже делаю с Electron, потому что Xamarin-а комманда не знает.
- Декларативное против императивного. Веб раньше был декларативным (потому как был заточен под документы, см выше). И хочет им остаться как можно дольше в силу традиции. Может быть если бы когда-то давно люди забили на HTML+CSS и начали бы манипулировать SVG из JS, мы бы сейчас жили в другой реальности (с компонентной моделью близкой к десктопной). Но, по состоянию на сегодня, layout в коде не одобрен институтом кашрута, а ведический HTML+CSS — очень даже одобрен. Но, увы, у декларативного синтаксиса есть свои пределы, в то время как у фантазии UX дизайнеров похоже нет. В итоге без фреймворка и тулчейнов вроде вебпака запилить что-то с профессиональным качеством весьма трудоемкая задача.
А если честно, то есть еще Power-point driven development. Вот это пожалуй и есть объективный корень всего зла. Мой первый опыт веб-программирования был в 2000-м. Мы обсуждали штуки вроде "визуальный язык", "метафоры управления", "поведение элементов", "доступность данных", "стандартные представления", "control flow/data flow" и т.д. Было много торга с дизайнерами за выразительность против универсальности, и это был спор в духе Сократа. Что было необходимо, т.к. компоненты приходилось писать и поддерживать самостоятельно. Сейчас я этого практически не вижу. Если что-то вышло из UX специалиста (чаще в формате PPT или PSD, с описанием в духе "новый дизайн!!!"), обратно это можно запихнуть только со слезами и насилием над личностью последнего (он же ж нарисовал и уже согласовал, и вообще чем нам не угодил pivot table с аггрегацией по 10MM записей, эксель же тянет). А потом еще начнется A/B тестирование, с двумя версиями интерфейса в параллель, потому что эта хитрая жопа не хочет брать на себя ответственность за свои решения. Не, я не против. Если у меня бюджет будет как в Амазоне и Нетфликсе — за ваши деньги любой каприз, а так…
Я к чему… Это больше не поле деятельности инженеров, тут правят дизайнеры и частенько маркетинг, а им чаще всего плевать как все работает, откуда берутся данные, как они вяжутся к интерфейсу, что повторно используется и т.д. Что, в свою очередь пораждает любовь к абстракциям и фремворкам, потому что собственно свой код все равно выраждается в адову копипасту со временем, а душа не терпит посредственности.
Прошу прощения за простыню, сегодня грустный вечер ;-)
i360u
08.11.2017 10:37Прекрасный комментарий! Вот только стереотипные камни в огороды дизайнеров и маркетологов его портят. И те и другие могут (и должны) относится к своим задачам очень даже инженерно, порой нужно просто сделать над собой небольшое усилие, для того, чтобы увидеть в каком поле абстракций происходит их магический инжиниринг. Грустить по этому поводу точно не стоит.
borv
08.11.2017 18:35+1Камни может и стереотипные, но, по моему опыту, весьма заслуженные. Я говорю о том, что процесс разработки интерфейса стал из двунаправленного односторонним, и реализация (а иногда и функция) сейчас часто вторична по отношению к дизайну. Торг за требования — это часть работы архитектора, передача дизайна в разработку — это передача (и прием) ответственности. Теперь же мне приходится очень часто беседовать на повышенных тонах с дизайнерами и менеджерами по поводу целесообразности очередного решения. И, как правило, убедить кого-то можно только угрожая увеличением бюджета, потому что технические детали не интересны, а "на вебе можно все". Может просто я стал старый и сварливый?
linuxover
08.11.2017 18:56нужна перманентная «драка» разработчика с дизайнерами и прочими влияющими на «условно ТЗ», драка за архитектуру.
сколько проектов наблюдаю: и проект хороший, а пришли к тому что простейшие изменения в своей кодовой базе сделать не могут: а почему? а об архитектуре не думали: пришли указивки сверху «сделать такую-то штучку» (котиков), выполнили, пришли еще — выполнили еще.
Об архитектуре задумываться начали только тогда когда пришли к нередактируемому состоянию.
i360u
09.11.2017 09:57Вы сейчас описали проблему "водопада" — это недостаток организации конкретного рабочего процесса. Я согласен, мало кто из менеджеров и членов команд способен организовать эффективную работу по другой (итеративно-эволюционной) схеме, но, к примеру в моей работе этой проблемы нет. У нас в команде реализуется непрерывное внедрение дизайна и делается это весьма органично. Ключ к победе над "водопадом" — декомпозиция процессов (как и элементов системы) на уровне представлений.
lair
08.11.2017 11:49Изначально браузер (да и весь интернет) был документ-ориентированным, состояние жило на сервере, клиент был предельно тупым.
Изначально в вебе состояния не было. О благословенные времена...
DigitalSmile
08.11.2017 11:56Спасибо за очень дельный коммент! Полностью согласен, даже добавить нечего особо…
DrPass
08.11.2017 13:08Из-за этого нам приходится решать кучку нетривиальных задач по управлению всем этим хозяйством (распределенное состояние, асинхрон, безопасность и т.д).
Вот это и бесит. Веб активно развивается более 20 лет, потребность во всём этом барахле появилась без малого полтора десятилетия назад, но эти задачи для нас по-прежнему нетривиальны.
questor
08.11.2017 17:33Ух, ну и коммент — такой в отдельную статью размером! И не вода, а полезные замечания.
olegchir
08.11.2017 07:21Если использовать серверную генерацию HTML, то написание новых тэгов и прочие ништяки доступны любому школьнику. Он сам может сочинить за 10 минут такую систему, либо взять готовую в том же Java JSP.
Все это уже придумано и отлично работаетб вещи типа JSP не менялись годами, а SpringMVC меняется лишь косметически, так что изменения нового мажорного релиза осваиваются за час.
olegchir
08.11.2017 07:32Сайты и веб-приложения используются в том числе для маркетинга. Нет никакого смысла в двух конкурирующих офисных веб-приложениях, имеющих одинаковый UI/UX на стандартных виджетах.
То же и об остальных попытках навязать стандартность. У нас уже есть стандартный HTTP и вебсокеты, есть стандартнейший REST. Все что выше — это область прямой конкуренции между решениями. Я могу взять REST, а могу намутить свой адовый ад, но такой, который даст конкурентное преимущество — в перфомансе сетевой подсистемы, или в скорости реализации API (по сути, скорости вывода новых фичей на рынок), что позволит убить конкурента.
Имхо, вот эта супер-кастомизируемость и стала причиной изначального успеха и непрерывного роста «нового веба» («нового» начиная с аякса и свежего CSS). Этот успех держится на непрерывной конкурентной борьбе, в которую вкачиваются тонны сил/людей и бабла. Похожая ситуация у мобильной разработки, в которой идет инфляция ресурсов относительно жадных до ресурсов приложений (не только процессоров, но скажем — непрерывное желание новых датчиков). Похожая битва была на платформе ПК во времена, когда предположение Мура было законом. Если Бесконечная Битва остановится, то вебу капец.
А мы ведь не хотим, чтобы вебу когда-то настал капец? Так что, давайте активней подкидывать дровишек в печь! Я тут кстати фреймворк написал :)gatoazul Автор
08.11.2017 10:56Вы забыли огромную категорию веб-приложений, использующихся внутри организаций. Там стандартные контролы и все остальное — это огромный плюс, а не минус.
i360u
08.11.2017 09:35Об определении новых тегов, чтобы кратко выразить новые контролы хотя бы в том, что есть — в HTML — разумеется, даже мечтать не приходится. Проект Polymer скорее мёртв, чем жив, во всяком случае для практической работы пока что не пригоден. Возможно, так во младенчестве и умрёт.
Это бред. Автор, советую разобраться в теме сперва, прежде чем делать такие заявления.
Вместо новых тегов — то есть, высокого уровня, разработчики браузеров нам предлагают подумать о теневом DOMе, то есть, о низком уровне. Я ничего не имеют против теневого DOMа, но я не хочу его видеть, как не желаю дома видеть канализационные трубы. Это подробности реализации, они не относятся к моей задаче.
Аналогично. Явный недостаток знаний матчасти.
В целом я могу согласиться с большей частью статьи, однако есть один маленький нюанс, который перечеркивает все: автор считает, что знает "как надо было" развивать веб-платформу, что это относительно просто и тому уже есть примеры. Нет, это не так. В этой системе с конечным числом относительно простых элементов, возможно бесконечное число конфигураций, каждая из которых очень по разному соотносится с бизнес-требованиями и требованиями технологической среды. Никаких простых рецептов, убивающих всех зайцев разом, тут быть не может, не стоит экстраполировать свои иллюзии.
i360u
08.11.2017 09:42P. S. А еще автор, похоже, не очень понимает что такое WebAssembly и зачем он, если упомянул его
в суев контексте работы с представлениями.sshikov
09.11.2017 21:12Возможно, так во младенчестве и умрёт.
О, да. Во младенчестве, выпустив версию 1.9.1, и благополучно смигрировав в ветку 2.х. Я тоже поржал.
gatoazul Автор
10.11.2017 16:00-2Каков процент использования Полимера в реальных сайтах? Стремится к нулю линейно или асимптотически?
sshikov
10.11.2017 20:09А вам зачем в штуках сайтов? Не понимаю, зачем это нужно может быть.
Я оцениваю число людей в коммьюнити, качество документации, качество кода, благо он весь открыт, как самой библиотеки, так и конкретных компонент. И это все на вполне приличном уровне. Баги есть, кудаж без них. Пожелания неисполнимые к авторам тоже есть. Скажем, они видимо живут в идеальном мире, где компонент — это лишь HTML, у меня же масса SVG, а с поддержкой namespaces у них того, сложности…
Тем не менее: 130 коммитеров у самого полимера, без библиотеки компонентов. Далеко не все из гугля, я бы сказал, что основные 10-20 оттуда, а остальные кто попало. Десятки релизов, тысячи компонент выпущено, сотнями я лично пользуюсь, написал примерно 20 своих. Среди сообщества — такие компании, известные лично мне, как Vaadin Ltd.
Это никаким боком не похоже на умирающий проект. Скорее уж на какой-нибудь Кобол, который даже если захотеть — не умрет все равно. Займет свою нишу, и будет жить вечно.
И да, я ни разу за полгода не вспомнил о Shadow DOM, не понимаю, откуда взялось ваше нежелание его видеть. Может, вы на версию типа 0.5 смотрели?
Причем, заметьте — авторы, они все на node. У них все средства разработки — это polymer-cli, bower и т.п., и все это нода. У меня ее нет, от слова вообще. Java, и все такое. И при этом я не испытываю особых неудобств, разрабатывая как приложение, так и компоненты.
xitt
08.11.2017 10:48жаваскрипт — именно так читается, а не транслитерируется
gatoazul Автор
08.11.2017 10:50+1Читается американцами. Но разве это американцы пишут кириллицей слово «Джаваскрипт»?
xitt
08.11.2017 17:24И русскими тоже английское слово javascript читается как жаваскрипт. Я не спорю с тем что русские пишут и читают иначе (а жаль, нас бы лучше понимали). Но автор в статье приводит пример слова mocha, и говорит что его нельзя писать и читать по русски транслитерируя. Т.е. в этом случае правильнее читать как читают американцы. Неконсистентные рассуждения, или некорректный пример.
leossnet
08.11.2017 10:50+1Хочу пару слов сказать про деньги. На мой взгляд, если бы Ларри Эллисон из Oracle не был бы таким жадным до денег, Java-машина уже давно бы была встроена во все браузеры, а доминирующим языком веб-разработки был бы Java.
В свою очередь JavaScript является ярким примером компромисса огромного числа бизнес-интересов. Новые же библиотеки и языки, расширяющие базовый JavaScript, это всего лишь попытки крупных компаний и молодых предпринимателей создать и затем монополизировать свою нишу веб-разработки с последующей капитализацией своей интеллектуальной собственности.
Вывод же простой – бесплатный сыр бывает только в мышеловке, поэтому писать по возможности нужно на стандарте, что позволит избежать больших головняков в будущем.sshikov
09.11.2017 21:17Ларри купил Sun в те времена, когда в апплетах уже многие разочаровались. Так что я хоть и согласен в целом с выводами, но только вы их не по адресу. И реально сделать то, что вы хотите, вероятно станет возможным только сейчас, с выпуском модульной JVM 9. Да и то, не факт, не факт.
Понимаете, JVM же не ставится вместе с браузером. И она большая, даже по нынешним временам. А уж 20 лет назад — и подавно была.
Вот если кого стоило бы поругать — так это хозяев Adobe. Которые по сути убивают Flash уже много лет, своими руками. Им даже помошники не особо нужны в этом.
khim
09.11.2017 22:32Так что я хоть и согласен в целом с выводами, но только вы их не по адресу.
По-адресу-по-адресу. Я лично знаю как минимум одну компанию, которая хотела интегрировать Java в браузер — так же, как сейчас интегрирован JavaScript. И имела работающий прототип к тому моменту когда Ларри решил, что можно срубить с неё через Java многа многаааа, МНОГАААА денег.
Разумеется все разработки были тут же свёрнуты.
Понимаете, JVM же не ставится вместе с браузером. И она большая, даже по нынешним временам. А уж 20 лет назад — и подавно была.
И, тем не менее, она ставилась вместе с самыми первыми версиями Netscape. Только вот уж очень сначала Sun, а потом Oracle хотели денег получить. Потому вместо полноценной интеграции и были придуманы апплеты и NPAPI.
Вот если кого стоило бы поругать — так это хозяев Adobe. Которые по сути убивают Flash уже много лет, своими руками. Им даже помошники не особо нужны в этом.
Ну тут скорее Стива благодарить нужно. После его демарша закат, фактически, начался…sshikov
10.11.2017 20:13Не, Стива-то как раз можно понять, хоть как-то. Мне не нравится, что такие решения принимаются из маркетинговых по сути соображений, но он — конкурент. Ему плевать на Adobe, если они не приносят денег — ну и хрен с ними.
А тут компания сама делает все, чтобы убить свой же продукт, который сначала купила… Вот это я не пойму.
linuxover
08.11.2017 11:20Расширяется с большим скрипом — понадобилось больше десяти лет на то, чтобы дождаться поля ввода даты.
и поле ввода даты так и не появилось. увы.
больное место интернета — ввод даты, времени.
да, можно написать
<input type="date" />, только вопрос как на сервере понять какая дата пришла из ввода02/03/2018? 02 марта или 03 февраля?
этот вопрос не решен, а следовательно ввода даты пока и нету.
порыскав по интернету найдем 100500 "красивейших" (наши соленые огурцы самые солёные в мире!) "плагинов jquery/bootstrap/etc" на тему ввода даты, но увы ни один не решает попутно проблему передачи этой самой даты по сети.
Если говорить о вводе времени, то там еще бОльшая труба. Де-факто если в JS одновременно сказать
(new Date()).valueOf()на двух устройствах двух пользователей получим время отличающееся на 3600.000, 7200.000 в произвольную сторону. При том что эти два устройства показывают одинаковую дату/время.
"мегаплагинов" решающих и эту проблему тоже нет, увы.
domix32
08.11.2017 11:56Вы же не генерируете для JS особый код на ассемблере для вызова процедур с возвратом, который покладёт на стек соответствующий адрес, а потом заберёт его назад? Не запускаете линкеры, которые соединят вам два модуля и пропишут настоящие адреса глобальных переменных?
Генерируем, к сожалению. Emscripten/asm.js/WebAssembly.
Филологическое отступление.
Правила русского языка говорят нам, что имена собственные не перводятся, поэтому какой-нибудь Jackob Jason Jupiter по-русски правильно будет назваеться Джекобом Джейсоном Джупитер, а не Якобом Ясоновичом Юпитером. То же касается и Java/JavaScript. Да и .js все же удобнее звать джей-эс. Однако язык не стоит на месте и подозреваю, что правильным произношением на русском будут уже оба варианта — в качестве консенсуса: разработчикам часто приходится использовать английские слова и аббревиатуры в своих сферах и для того чтобы иметь возможность обратную устную связь приходится поддерживать несколько вариаций произношения одного и того же слова.
P.S. Известная Studio Ghibli, ранее при переводах озвучивалась как Студия Гибли. Вполне корректно, учитывая итальянско-арабско-ливанское происхождение названия. Однако же Миядзаки назвал свою компанию ??? и на русском оно должно называться Дзибли согласно поливановской транскрипции, поэтому некоторые русские озвучки были скорректированы под это название. Но моя душонка не приемлет такого изуверства, поэтому продолжаю при случае называть ее на итальянский манер.gatoazul Автор
08.11.2017 12:26Имя собственное страны USA отлично переводится как США.
domix32
08.11.2017 16:53+2Это аббревиатура названия страны — раз.
Топологические названия вообще не очень из английского заимствуются да и вообще имеют особое отношения с заимствованиями. Например, у нас Румыния, а не Романия (Romania) и Кёльн, а не Колон (Cologne). Это два.
Самоназвания часто просто игнорируются, причем в обе стороны — вы для них я буду рашн фром Раша, а не русский из России.
Скорее всего вы сможете найти еще несколько исключений, где будут кальки/портмоне-слова/синтаксические переносы не попадающие под основные правила русского языка. Исключения найдутся везде.gatoazul Автор
08.11.2017 21:10В правила русского языка отнюдь не входит дословное отражение иностранной речи даже в именах. Знаете такого писателя Генриха Гейне? А он ведь Хайнрих Хайне.
Да и «Мао Цзэдун» у нас пишется без тонов.
novice2001
08.11.2017 21:56+1Э-э-э, а почему Колон (Cologne) а не Koln? Это в конце концов немецкий город, а не английский.
third112
08.11.2017 16:54+1Парадный портрет автора, заодно иллюстрирующий идею современной веб-разработки
Отлично! В лучших традициях конца прошлого века. Ностальгия! Оч. понравилось. Теперь о том, что не совсем понравилось:
Неужели отображение данных на экране для просмотра и редактирования — такая неслыханная и невиданная задача, что никто не знает, с какой стороны к ней даже подступиться? Я вас умоляю. Она решалась столько раз, что даже просто перечислить — заболит палец, жмущий на клавишу «запятая». Так, навскидку, то, о чем я слышал: терминалы IBM 3270, Смоллтолк, экранный Постскрипт, WinAPI, TurboVision, VisualBasic, dBase, Tcl/Tk, XUL, Rebol/View, XAML.
Зачем валить в одну кучу как минимум два решения с противоположными целями? — Так будет еще меньше ясности. Постскрипт и т.д. (еще TeX забыли упомянуть!) своей целью имеет точное 1 в 1 воспроизведение верстки на любом устройстве — будь то стационарный дисплей, принтер или eBook или телефон. У HTML противоположная цель — переформатировать контент в зависимости от устройства вывода наиболее удобным для чтения образом. В первом случае задача решаема и решение найдено, нпр., pdf-формат. А во втором — задача в общем случае неразрешима, поэтому все попытки правильного отображения элементов оформления работают в не очень широких пределах. Чем больше таких элементов оформления и чем они сложнее — тем хуже они воспроизводятся на всем зоопарке возможных устройств. Это закон природы, и ничего тут не поделать. Поэтому чем проще веб-документ — тем лучше. Однако многие веб-дизайнеры не страдают отсутствием аппетита и так хотят кушать, что очень часто пытаются ухудшить уже сделанное. Т.о. ИМХО проблема даже не в вебе, а в недоедании дизайнеров.gatoazul Автор
08.11.2017 17:16Под экранным Постскриптом имелась в виду вот это:
en.wikipedia.org/wiki/Display_PostScriptthird112
08.11.2017 17:20Display PostScript (or DPS) is a 2D graphics engine system for computers which uses the PostScript (PS) imaging model and language (originally developed for computer printing) to generate on-screen graphics.
Ok. И что это меняет в моих словах?Xitsa
10.11.2017 12:28Так лучше понятно, что автор не валит в кучу решения с противоположными целями.
Насколько я помню, DPS — это активный язык, на котором в частности писались и обработчики событий, таких как динамическая смена размеров.
thelongrunsmoke
И где обсуждение ява-апплетов? Они решали многие из перечисленных проблем.
musicriffstudio
флешевые модули работали так же как явовые апплеты и раздавили браузерную яву как муху. Даже выбор браузера какое-то время назад сводился к вопросу «опера флеш не поддерживает, значит в топку»
Но теперь флеш из браузеров выкинули т.к. производители не хотят чтоб кто-то со стороны имел такое влияние.
lair
Вариант "потому что было слишком много дыр" не рассматривается?
sentyaev
Это же идеальный аргумент с который невозможно оспорить, такой же как «давайте оградим детей от порнографии и наркотиков, и для этого заблокируем ресурсы с этой информацией».
Но это все борьба со следствием, а не с проблемой.
lair
Что "это"?
И что же здесь проблема?
sentyaev
«потому что было слишком много дыр»
Собственно дыры.
lair
Есть мнение, что дыры — это как раз следствие. А проблема — это архитектура.
Hardcoin
Да, можно было бы бороться с самой проблемой, с дырами. Если бы адобе открыл код. А так-то так? Производителям браузеров нужно было бинарник патчить или что?
musicriffstudio
Нет.
Производители браузеров чётко обозначили почему они не будут поддерживать флеш.
Как и к жава-апплетам претензии сходные — невозможно влиять на адоб (или тогдашний сун) и заставить его что-то поменять под конкретный браузер. Эппл, скажем, поставил на первое место энергопотребление.
А всё для чего использовали флеш/жава-апплету уже может обычный хтмл5.
Free_ze
Сильное заявление.
musicriffstudio
так утверждают эппл, гугл и микрософт. Это крупные компании.
Free_ze
Я к тому, что неужели браузерный API способен потягаться в возможностях с (почти) полноценной JVM/CLR?
musicriffstudio
а зачем?
В тексте написано немного другое
Free_ze
Тут разница в мотивации. Вместо создания просто хорошей альтернативы для повседневных задач они намеренно убивали технологию, подменяя ее «плюшевым» API.
mayorovp
Так влиять-то и не нужно. Нужно было выпустить новую версию API для плагинов, а их разработчики бы дальше сами суетились.
Но этого не было сделано именно потому что, согласно современным представлениям, само наличие каких-то левых плагинов — уже дыра в браузерной песочнице.
musicriffstudio
Ну вот хочет эппл чтоб флешевая игра/видео была жёстко ограничена в потреблении энергии, а адоб не хочет (не может) ничего менять. Причём тут АПИ?
fzn7
Каким образом аналогичная задача решается для html5?
mayorovp
Через остановку requestAnimationFrame-обновлений в неактивных вкладках. Флеш же, для сравнения, в неактивных вкладках радостно продолжает тормозить.
fzn7
Посмотрите на PPAPI для хрома, через который уже лет 5 как работает флеш плеер
mayorovp
Это почему-то не мешает ему вешать браузер при загрузке в неактивных вкладках…
fzn7
Значит хром ему это позволяет
Вот схема вызова вашего render call из документации:
Еcли вы уверены, что эту схему можно обойти и дернуть нативный вызов напрямую, обойдя песочницу, то предлагаю вам написать в bughunt программу гугла и получить ваши ~15000$
khim
Дело в том, что все звери равны — но некоторые равнее. Специально для флеша Хром предоставляет несколько приватных интерфейсов, которые, с одной стороны далают «Flash на PPAPI (да-да, точно-точно, верим-верим)» возможным, а с другой — приводят к том, что Flash-таки может «вешать браузер».
Ну не смогли они сделать из PPAPI что-то, чем реально можно пользоваться.
fzn7
Ну так где я кидался словами?
khim
Есть «безопасный» и «правильный» PPAPI. А есть «PPAPI для флеша» — и это разные вещи.
P.S. Комментарий я действительно не туда отписал.
fzn7
Хорошо, уберем fp, напишем свой плагин по правильному PPAPI. Предложенная вами оптимизация в ней все так-же невозможна?
khim
Наши недостатки — продолжение наших достоинств. Флешом было удобно пользоваться, в частности, потому, что работа с DOM'ом — в нём была синхронной, как в JavaScript.
PPAPI (без «заднего прохода для флеша») не позволяет этого сделать в принципе, что автоматически ставит крест на том, чего люди хотели от NaCl'я больше всего: возможности писать на более вменяемых языках, чем JavaScript.
Что, правда, приносит и пользу, как бы: PPAPI-плагины не могут «завесить» браузер, ура. Но вред, хотя и менее очевиден, но более весом: в силу того, что пользоваться этим крайне проблематично и «замену флеша» сделать невозможно — то этих плагинов, как бы, так и не появилось в сколько-нибудь ощутимом количестве.
sshikov
А разве это не так? По-моему, львиная доля дыр в Java и Flash — в самих плагинах. Не все, далеко не все — но очень большая доля.
mayorovp
Да, так и есть. И пальма первенства тут, кстати — у Java, где браузерный плагин позволял апплетам из соображений совместимости использовать устаревшие версии JRE :-)
sshikov
Ну и что бы тут изменил другой API? Ведь по любому, плагин, такой как Java или Flash, и только он, знает, что он там исполняет. Он видит и работает с кодом. Полноценный статический анализ безопасности практически не возможен (для JS в первую очередь, я совсем не уверен, что для Java и Flash с этим реально хуже — хотя тоже грустно). И контролировать его целиком браузер вряд ли сможет.
В какой-то мере это ведь и к wasm относится, хотя тут конечно все иначе — тут байткод, и сравнительно простой.
khim
Убили всё это из политических соображений, а не технических./
sshikov
Не, ну там кажется внутри все равно байткод (LLVM), разве не?
khim
Нет. Там есть LLVM и байтокод — но с их помощью достигается переносимость, не безопасность. Мегабайты кода LLVM'а вполне явно отнесены к untrusted зоне — то есть к коду, которому NaCl не доверяет и ошибки в котором не являются проблемой.
Вот тут описано как программировать в NaCl на ассемблере, без всяких компиляторов и байткодов…
sshikov
А вы считаете, что в V8 мало дыр? Ну или в движке у IE/Edge? Не, я даже согласен, что их меньше — но они были, и наверняка есть. И их вряд ли когда-либо устранят полностью, потому что задача исполнения недоверенного кода, взятого где-то в интернете, а возможно и подмененного по пути хакером, так чтобы он работал, но ничего не поломал — она сложная. Ну т.е., да, может на какой-то момент во флеше и было многовато дыр — так у него и возможностей намного больше, чем у тогдашнего JS-движка (да и у сегодняшнего пожалуй тоже).
Ну т.е. это не причина — это повод.
lair
Я считаю, что их (должно быть) радикально меньше просто потому, что surface ограничен браузером. А у плагинов — как я их помню — surface как раз и был больше.
Вот-вот. Именно эти возможности и давали дыры.
sshikov
В V8 когда-то (правда, давненько уже) были дыры даже в движке регулярных выражений. Уровня remote code execution. Давайте запретим регулярки, чего уж там? :)
Я позволю себе в который раз напомнить забавную историю про то, как кто-то из известных чуваков в команде мозиллы громко заявил: "Да этот ваш Acrobat Reader — сплошная дырка в безопасности. Мы его выпилим, и сделаем средство просмотра на чистом javascript, без плагинов". И все знают, чем это кончилось.
Ну просто это (запрет чего-либо) — не метод решения проблемы, ни разу не метод.
lair
Понимаете ли, одно дело, когда у вас есть регулярки, в которых возможен RCE. Закрыли RCE, проблема решена. Другое дело, когда у вас есть плагин, который позволяет слать запросы к любому серверу в контексте браузера, но игнорируя CORS (это я для примера, я уже не помню, что там было). Границы песочницы разные.
sshikov
Я не очень понял, в чем вы видите разницу (CORS, если уж на то пошло, вообще появился позже, чем Flash, и в нем в каком-то виде поддерживался (crossdomain.xml, сколько я помню), так что мне кажется вы тут ошибаетесь). Ну да, границы разные. Но тут вполне было за что платить-то, разница в возможностях уж очень велика.
И кроме того, набор доступных разработчику на JS возможностей — он же тоже постоянно растет, так что границы песочницы только расширяются. Причем в частности и потому, что разработчикам не хватает возможностей, которые были в том же Flash. Добавили поддержку микрофона, веб камеры, bluetooth, геолокации, канвас, WebGL, и много чего еще. Ходят слухи, что хакеры научились майнить биткоины через браузер. Думаете, число потенциальных векторов атаки сокращается? Да ладно...
По-хорошему, бороться с дырами в плагинах можно было, причем несколькими вполне очевидными способами. Один из них даже реализован — в FF, скажем, есть механизм отключения плагинов, про которые известно, что там дырки. Ну т.е. браузер отключит ваш Flash, как только получит оповещение. И включит после обновления. Значительно быстрее, чем это сделаете вы сами.
lair
Разницу я вижу в том, сколько систем отвечает за границы песочницы.
Собственно, кто-то решил, что плата слишком высока.