Pull to refresh

Comments 243

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

UFO just landed and posted this here
Но теперь флеш из браузеров выкинули т.к. производители не хотят чтоб кто-то со стороны имел такое влияние.

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

UFO just landed and posted this here
Это же идеальный аргумент с который невозможно оспорить

Что "это"?


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

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

UFO just landed and posted this here

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

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

UFO just landed and posted this here
А всё для чего использовали флеш/жава-апплету уже может обычный хтмл5.

Сильное заявление.
UFO just landed and posted this here
Я к тому, что неужели браузерный API способен потягаться в возможностях с (почти) полноценной JVM/CLR?
UFO just landed and posted this here
Тут разница в мотивации. Вместо создания просто хорошей альтернативы для повседневных задач они намеренно убивали технологию, подменяя ее «плюшевым» API.

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


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

UFO just landed and posted this here
UFO just landed and posted this here
Через остановку requestAnimationFrame-обновлений в неактивных вкладках. Флеш же, для сравнения, в неактивных вкладках радостно продолжает тормозить.
UFO just landed and posted this here
Это почему-то не мешает ему вешать браузер при загрузке в неактивных вкладках…
UFO just landed and posted this here
Еcли вы уверены, что эту схему можно обойти и дернуть нативный вызов напрямую, обойдя песочницу, то предлагаю вам написать в bughunt программу гугла и получить ваши ~15000$
Не стоит так кидаться словами.

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

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

P.S. Комментарий я действительно не туда отписал.
UFO just landed and posted this here
Наши недостатки — продолжение наших достоинств. Флешом было удобно пользоваться, в частности, потому, что работа с DOM'ом — в нём была синхронной, как в JavaScript.

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

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

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

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

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


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

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

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

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

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

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

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


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

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

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


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

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

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

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


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


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

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

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

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


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


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

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

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


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

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

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

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

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

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


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

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

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

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

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

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

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

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

Они так же устареют еще до того, как наконец наступит «коммунизм».
а как же WebAssembly? Или его ждёт судьба узконаправленных задач?
UFO just landed and posted this here
Отсюда автору статьи более радикальный вывод — «выкинуть всё и с нуля» надо начиная с html!

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

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


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

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

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

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

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

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

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

Нет, Вы не вполне поняли самую Суть™ идеи, и действительно, здесь тонкие нюансы. Озвучивавшийся вариант — он не вместе с браузером, а вместобраузера — и всего современного веба — целиком. Юзер не хочет возиться с плагином, и вообще лишними сущностями. И да, юзеру и песочница/контейнер по большому счеты не важны — можно было бы запускать и бинарные файлы (ну в наше время, понятно, можно иметь подписи). Ведь вдумайтесь — раньше приложения именно так и были, запускаешь просто бинарники. Проблемы для их авторов были работать в любом возможном окружении, но даже больше — иметь всегда самую свежую версию, со всеми багфиксами. Пол Грэм именно это про Web и рассказывал — на сервере работает всегда самая свежая версия, которой управляет разработчик. Вот ведь что на самом деле решил Web, и на что на самом деле надо смотреть, а не на стек контейнеров.
И да, юзеру и песочница/контейнер по большому счеты не важны — можно было бы запускать и бинарные файлы (ну в наше время, понятно, можно иметь подписи).
А вот на этом обжёгся Microsoft. Подписи не работают. Вначале пользователь научается жать кнопку «да» на всё на свете, потом, несколько раз переустановив систему — научается жать кнопку «нет». Изучать подписи он, в общем, так и не научается.

Вот ведь что на самом деле решил Web, и на что на самом деле надо смотреть, а не на стек контейнеров.
Совершенно верно, но непонятно как ваша нирвана может придти на компьютеры пользователей.

Потому что веб-браузер — он уже как-то эту задачу решает и он уже есть. Почему вдруг кто-то захочет куда-то переходить?

Ну разве что если Android придёт на рынок desktop'ов и принесёт своё решение этой проблемы (Google Play)… что возможно, но явно не в ближайшей перспективе…
Ну разве что если Android придёт на рынок desktop'ов и принесёт своё решение этой проблемы (Google Play)… что возможно, но явно не в ближайшей перспективе…

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

Но ведь вопрос исходного поста таки был не в том, как именно «такая нирвана придет» в нам, не правда ли?..
Разве это волнует кого-то, кроме спамеров?

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

UFO just landed and posted this here
Потому что в письмах должен быть только текст. Тогда и проблем с вёрсткой не будет.
Пожалуй, я бы согласился на RsT. Ну или MD, ладно.

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

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

В геймдеве вроде всё вполне себе норм. Не могу припомнить никаких особых архитектурных проблем. Даже от вечной обратной совместимости GAPI уже ушли.
А с чьей точки зрения веб стал лучше?
Моя точка зрения пользователя такая что с каждым годом веб становится все тяжелым и неуклюжим. Раньше мне не доставляло проблем запустить 20 вкладок и работать с ними. И я не парился что мне не хватит памяти и все зависнет и упадет. А сейчас даже закрытие вкладки зачастую не означает что память освободится. И теперь для работы в вебе мне нужно 8 гиг памяти…
Потому что веб-сайты превратились в веб-сервисы. Проблема тормозов (например, если вы сидите на Eee PC с 1Гб памяти) решается отказом от веб-сервисов: в браузере просматриваются лишь странички, а для сервисов используются отдельные приложения.
Так, вместо тормознутых почтовых веб-сервисов типа GMail используется старый добрый почтовый клиент. Хотя по нынешним временам стало очень трудно найти почтовик без встроенного браузера со всеми его тормозами, так на вскидку кроме Sylpheed ничего и не припомню.
Для просмотра лент с соцсетей и новостных лент используется RSS-агрегатор. Хотя по нынешним временам крайне сложно найти RSS-клиент без встроенного браузера — я не знаю ни одного GUI-клиента, который не тянул бы с собой тормознутый браузерный движок.
Вместо youtube и подобных видеосервисов используется потоковый плеер.
Ну и всё в том же духе. Большинство веб-сервисов заменяется автономными приложениями, а немногие статические странички просматриваются в links2 или подобном браузере, который отлично их рендерит, даже с графикой. В таком режиме можно хоть с Raspberry Pi комфортно в Интернете сидеть.
UFO just landed and posted this here
А в чём тут проблема? Даже на древнем POP3 никто не заставлял письма с сервера удалять сразу же после загрузки, а уж с IMAP вообще проблем нет.
UFO just landed and posted this here
А зачем мне на смартфоне все письма целиком? Где хранить черновики? Почему нельзя написать письмо на компе, а дописать и отправить его со смартфона?
Это хорошие вопросы, но они не обьясняют — зачем вам для всего этого гонять туда-сюда мегабайты кода. Драфт записать на сервер — отлично, но зачем для этого весь UI с сервера скачивать каждый раз, когда вы почту хотите почитать…

Впрочем GMail на смартфоне и не скачивает и HTML5 для UI не пользуется… что как бы и показывает ненужность всего «котла», который обсуждается в статье…
UFO just landed and posted this here
Это легко проверить, нажмите F12 — увидите что ничего из вашего юая не скачивается, все берется из дискового кеша.
А вы проверьте. Мой эксперимент — первый запуск при «пустом» кеше скачивается порядка 10 мегабайт, повторное открытие сразу после этого — где-то мегабайта два.

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

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

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

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

Сравните хотя бы MS Office и Google Docs. Я, кстати, активно пользуюсь Google Docs — так как тот факт, что за них не нужно платить и их не нужно устанавливать часто решает… но над второй проблемой уже работают, а первая, как бы, к качеству технологий вообще отношения не имеет.
UFO just landed and posted this here
И что? Два, десять, пятьдесят. Да хоть триста. В чем проблема, с точки зрения юзер экспириенса, если сеть позволяет? Почему вы технические хотелки выдаете за проблему?
Потому что они становятся проблемой как только вы ступаете за пределы МКАД. Не обязательно куда-нибудь в Карелию. Вот, например, ОпСоС из вполне себе продвинутой страны — Германии. Что мы видим на первой странице? Правильно: гордое заявление о том, что в самом популярном тарифе количество траффика увеличено с 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-навороты?
какой-нибудь Visual Basic четвертьвековой давности (или Delphi, если вам так нравится) — дадут фору 100 очков вперёд всем этим БЭМ'ам и Angular'ам

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

UFO just landed and posted this here
Да, не могут. Точно так же они не смогут пользоваться инстант приложениями, которые вы упомянули как решение проблемы. Вот к чему я веду. Эти инстант приложения точно так же будут потреблять трафик.
При использовании их как инстант приложений — да. Но… читаем:
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 вам тоже нужно поддерживать).
К огромному счастью, гмыло до сих пор позволяет ходить через хтмл-интерфейс. Если бы его убрали (тьфу-тьфу-тьфу), не представляю, как бы я это пережил… :)

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


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

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

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


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

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

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


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

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

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


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

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

Это то и грустно…
Раньше страница которая жрет 100мг памяти считалась написанной дилетантами и студентами, теперь это норма. А по факту ничего снаружи не поменялось…
Мне просто любопытно, какие именно 20 вкладок мне надо открыть, чтобы что-то стало тормозить… Ни разу не сталкивался, ноут 2012 года, 6 Гб памяти, SSD.
Я абсолютно серьезно, расскажите.
У меня adblock отжирает 200-300 мб, и этого достаточно, чтобы браузер начал тормозить вместе со всей системой. 4 Гига и HDD.
UFO just landed and posted this here
Последовал вашему совету. Пока доволен.
Переведите его в режим «Advanced», и, в принципе, можно и от noScript начинать отказываться.

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


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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

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


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

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

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

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


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


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

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

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

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


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

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

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

Процесс идёт. Медленно (хотя по историческим меркам — достаточно быстро: с нуля до половины — за 8 лет… надо полагать переход с половины до конца примерно столько же времени займёт), но уверенно.
Годное описание того, почему я 9 лет назад забил на Веб несмотря на все его радужные перспективы в те годы. И не жалею.
Но одно обидно: за столько лет веб-разработка не устаканилась до состояния внутренней согласованности. И не скоро устаканится. Но, как говорится, не было бы счастья, да несчастье помогло: десктоп тоже не особо устаканился.
В общем, пошёл дальше пилить формочки да консольки.
Эх… «бросить бы все и уехать в урюпинск» (с)
Что у нас по формочкам сегодня в тренде? WPF, Qt?
UFO just landed and posted this here
1) Браузер — это не View, а Controller.
2) Ваша портянка про стандартные библиотеки элементов — полное противоречие и реальности и тому, что в статье написано.
Сейчас браузер предоставляет стандартный набор элементов и всё. Если тебе не хватает — ССЗБ. Задача про «поменять цвет кнопки при нажатии на другую» — это как раз оттуда. Браузер дает стандартные контролы и минимум возможности как-то их расгирять и изменять.
Имхо vsb все правильно пишет. Людям хочется красивых нестандартных кнопок, и если обычные баттоны не поддерживают достаточную кастомизацию — их просто не используют.
и если обычные баттоны не поддерживают достаточную кастомизацию — их просто не используют

Вместо того, чтобы сделать базовые элементы более кастомизируемыми, вы предлагаете от них отказаться полностью, и каждому пилить что-то своё? Из-за невозможности отрегулировать седло, каждому приходится делать собственный велосипед, под свой рост. Разве это нормально?
А можно узнать каким именно людям хочется таких кнопок?
Меня лично устроили бы совершенно некрасивые, лишь бы все работало быстро на любом железе, которое сейчас встречается.
А в реальности мне достаточно комфортно использовать любой сайт (ах да, веб-приложение) на стационарном i5-2500k@4Ghz с 16 Гб памяти, ноут с Pentium 3558U и 4 Гб памяти иногда ощутимо подтормаживает. Про ноуты на Atom я вообще молчу, а они есть, да.
Поэтому в гробу я видал красивые кнопочки и тех, кому они нужны. В погоне за красотой они сделали веб таким тормозным, что я даже не знаю с чем его сравнить.
А можно узнать каким именно людям хочется таких кнопок?
«Поколению Apple», условно говоря. Вот типичная ремарка: Есть еще Gerrit, который там как-то с этим борется, но интерфейс из 90х убивает все желание пользоваться этим.

Заметьте, что речь идёт об инструменте для работы с Git-репозиториями — то о гиковстве вполне себе ненулевого уровня… и тем не менее первый критерий, по которому это всё оценивается — это по параметру «модно, стильно, молодёжно»…

Поэтому в гробу я видал красивые кнопочки и тех, кому они нужны.
Увы. Их слишком много и потому всё что делается — делается под из нужды.

Времена гиков — прошли, теперь компьютеры делают для людей, которые выбирают не удобную одежду, а модную.

В погоне за красотой они сделали веб таким тормозным, что я даже не знаю с чем его сравнить.
Сравните с каким-нибудь Visual Studio 2017… и вы увидите, что тормознутость web'а — это, увы, частный случай.
Вы не поняли главную суть, которую изложил автор статьи.
Любой, у кого стоит Firefox, пользуется её плодами каждый день — потому что в нём на языке XUL полностью запрограммирован пользовательский интерфейс.

Через неделю уже неактуально, из Quantum выпилили.

Оперативно реагируют!

Пока что не соответствует действительности. Из Firefox потихоньку "выпиливают" фирменную технологию байндингов XBL (но и то ещё на ранних этапах), а XUL пока что остаётся и даже кое-где развивается (например, одной из составляющих в замене XBL станет поддержка Custom Elements в XUL). Другое дело, что с Quantum XUL окончательно становится деталью реализации, поскольку дополнения доступа к нему лишаются.

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

Все верно. Там проблема только в том что старая версия спецификации web components, потому что polymer сделали когда их только Хром поддерживал как раз в том числе, чтобы продемонстрировать, что технология жизнеспособна

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

Вот с момента, как ютуб на полимер перешел (об этом я узнал от разраба качалки видео, он ругался на него), он стал ЕЩЕ медленнее работать, хотя казалось, что это невозможно. :) Страницы теперь иногда вообще не отрисовываются до конца, пока видео не КОНЧИТСЯ…
Вот поэтому я занимаюсь backend разработкой. Построение ПО для браузера — это программирование средствами описания гипертекстовых документов, а не программ. Ну вот например файл microsoft excel — это тоже документ. Он тоже открывается и рендерится в специализированной программе подобно тому как открывается HTML документ в веб-браузере. Да, там тоже есть возможность некоторой кастомизации поведения скриптами. Но кому придёт в голову называть microsoft excel языком программирования?
Но кому придёт в голову называть microsoft excel языком программирования?
Нудным голосом: К вашим услугам 91 в категории «Разработка приложений», специализирующихся на услуге «Разработка приложений для Excel ».

Да, Excel нонче менее популярен, чем HTML+JS, но было время, когда на нём немало приложений писалось…
Это, скорее всего, разработчики их т. н. «add-ins», а не программисты на макросах :-)
Там и тех и других хватает. Но нет — в основном это люди, которые встраивают скрипты в «продвинутую Excel-таблицу», после чего она становится таким себе «приложением для бедных»

Для богатых тоже… я лично наблюдал приложение (в виде десятка excel разного назначения), где было порядка сотни тысяч строк VBA кода. И написали его простые бедные трейдеры, ни разу не программисты, математики по образованию.


И другое такое же — для оценки рисков кредитования.

Но кому придёт в голову называть microsoft excel языком программирования?

Но VBA ведь вполне себе язык программирования. Когда говорят про программирование для браузера, имеют в виду не HTML (по крайней мере, грамотные люди), а JavaScript.

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

запросы к базе данных никому не придет в голову называть программированием

Сильное заявление. В энтерпрайзе BL нередко оказывается в БД.

Вы хоть видели на что я отвечал?

В самом деле, пардон, контекст не уловил.

Разделяю ваши фрустрации! Но, боюсь, срыва покровов не произошло:


В мире веб-программирования считается хорошим тоном блуждать в трех соснах, которые называются M, V и C

Вот в них-то и проблема, и изящно избавиться от "M" и "C" вашим методом не выйдет. Во-первых "M" на бэк-енде и "M" на клиенте малость разные от слова совсем. "M" клиента обычно обрастает состояниями, про которые бэк-енд понятия не имеет. "C" не тождественно браузеру уже лет пятнадцать, с тех пор как появился AJAX и асинхронность. А вот с "V" который всем так интересен как раз все теперь относительно хорошо, по крайней мере не так плохо как на десктопе.


С моей точки зрения проблемы совсем не в экосистеме, а в архитектуре, которая ее породила:


  1. Где состояние, Зин? Изначально браузер (да и весь интернет) был документ-ориентированным, состояние жило на сервере, клиент был предельно тупым. Потом мир малость поменялся, и сейчас у нас stateless backend (потому что масштабирование) и stateful client (потому что пользователь так хочет). А обработка и данные по прежнему удаленные. Из-за этого нам приходится решать кучку нетривиальных задач по управлению всем этим хозяйством (распределенное состояние, асинхрон, безопасность и т.д).
  2. Где у этого мозги? Раньше мы обычно "говорили" с одним сервером и могли, хоть и с натяжкой, думать об этом как об RPC, можно было (с оговорками) считать сервер источником правды, рассуждать про границы транзакций, какие-то операционные контракты и т.д. Теперь работать с кучей гетерогенных сервисов, половина которых вообще не наши и в лучшем случае eventually consistent — скорее норма чем исключение. В такой ситуации источник правды переехал на клиента, равно как и добрая половина бизнес-логики, хотите вы в этом себе признаваться или нет. Так что мозги теперь повсюду.
  3. Один как Леонид Ильич МакЛауд. У веб приложений практически нет реальных альтернатив, т.к. только они позволяют начать взаимодействовать с пользователем без установки, консента и работают более-менее везде предсказуемо. Был шанс что мобильные устройства развернут ситуацию, но победила жадность, которая родила аппстор и устроила сегрегацию. Заменой веба им теперь не быть. Это сместило фокус в сторону веб-разработки с прицелом делать десктопный UX, что как раз породило весь зоопарк уродов. И толпы программистов которые умеют только веб программирование. Так что теперь у нас будут веб программы на десктопе. И вот я скрепя зубами следующий десктопный проект уже делаю с Electron, потому что Xamarin-а комманда не знает.
  4. Декларативное против императивного. Веб раньше был декларативным (потому как был заточен под документы, см выше). И хочет им остаться как можно дольше в силу традиции. Может быть если бы когда-то давно люди забили на 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 тестирование, с двумя версиями интерфейса в параллель, потому что эта хитрая жопа не хочет брать на себя ответственность за свои решения. Не, я не против. Если у меня бюджет будет как в Амазоне и Нетфликсе — за ваши деньги любой каприз, а так…


Я к чему… Это больше не поле деятельности инженеров, тут правят дизайнеры и частенько маркетинг, а им чаще всего плевать как все работает, откуда берутся данные, как они вяжутся к интерфейсу, что повторно используется и т.д. Что, в свою очередь пораждает любовь к абстракциям и фремворкам, потому что собственно свой код все равно выраждается в адову копипасту со временем, а душа не терпит посредственности.


Прошу прощения за простыню, сегодня грустный вечер ;-)

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

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

UFO just landed and posted this here

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

Изначально браузер (да и весь интернет) был документ-ориентированным, состояние жило на сервере, клиент был предельно тупым.

Изначально в вебе состояния не было. О благословенные времена...

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

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

Ух, ну и коммент — такой в отдельную статью размером! И не вода, а полезные замечания.

Потом мир малость поменялся, и сейчас у нас stateless backend (потому что масштабирование) и stateful client (потому что пользователь так хочет). А обработка и данные по прежнему удаленные. Из-за этого нам приходится решать кучку нетривиальных задач по управлению всем этим хозяйством (распределенное состояние, асинхрон, безопасность и т.д).

Концепция «stateless backend и stateful client» с успехом применялась в клиент-серверной архитектуре на SQL. Да, еще в эпоху мезозоя.
Да. За вычетом собственно сессии и временных таблиц, которые появились далеко не сразу.
А вы хотели только вопрос задать или у вас есть опровергающие аргументы?

Так, стоп, давайте оговоримся. Я неверно употребил термин SQL, имея вместо него в виду RDBMS (которые традиционно являлись бэкендом в таких системах). Вы все еще считаете, что они stateless?

Я имел в виду конкретно SQL, поэтому и так написал. В языке нет передачи состояний.
Но мне все равно интересно, почему вы считаете, что реляционные базы не stateless?
Я имел в виду конкретно SQL, поэтому и так написал. В языке нет передачи состояний.

Ну язык — не бэкенд, чего уж.


Но мне все равно интересно, почему вы считаете, что реляционные базы не stateless?

Потому что два последовательных идентичных запроса (INSERT INTO SomeTable (ID) VALUES(1)) будут иметь разный результат. А если взять транзакции, то будет еще веселее.

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


Тем не менее, в SQL даже такое состояние есть, в виде транзакций, временных сеансовых таблиц и переменных.

Бэкэнд который совсем не содержит изменяемых частей никому не нужен даже в эпоху поклонения иммутабельности.

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

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

Но я говорю не о том, что SQL не допускает сессионные состояния, тем более, что это не так. А о том, что эта концепция совсем не нова. И только от разработчика-архитектора зависит, будет ли он делать бэкенд с состояниями или без, как на HTTP, так и на SQL.
А о том, что эта концепция совсем не нова.

Да много концепций не ново, вопрос в том, насколько они востребованы.

Если использовать серверную генерацию HTML, то написание новых тэгов и прочие ништяки доступны любому школьнику. Он сам может сочинить за 10 минут такую систему, либо взять готовую в том же Java JSP.

Все это уже придумано и отлично работаетб вещи типа JSP не менялись годами, а SpringMVC меняется лишь косметически, так что изменения нового мажорного релиза осваиваются за час.
Сайты и веб-приложения используются в том числе для маркетинга. Нет никакого смысла в двух конкурирующих офисных веб-приложениях, имеющих одинаковый UI/UX на стандартных виджетах.

То же и об остальных попытках навязать стандартность. У нас уже есть стандартный HTTP и вебсокеты, есть стандартнейший REST. Все что выше — это область прямой конкуренции между решениями. Я могу взять REST, а могу намутить свой адовый ад, но такой, который даст конкурентное преимущество — в перфомансе сетевой подсистемы, или в скорости реализации API (по сути, скорости вывода новых фичей на рынок), что позволит убить конкурента.

Имхо, вот эта супер-кастомизируемость и стала причиной изначального успеха и непрерывного роста «нового веба» («нового» начиная с аякса и свежего CSS). Этот успех держится на непрерывной конкурентной борьбе, в которую вкачиваются тонны сил/людей и бабла. Похожая ситуация у мобильной разработки, в которой идет инфляция ресурсов относительно жадных до ресурсов приложений (не только процессоров, но скажем — непрерывное желание новых датчиков). Похожая битва была на платформе ПК во времена, когда предположение Мура было законом. Если Бесконечная Битва остановится, то вебу капец.

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


Мы, динозавры, этого кокрастыке очень хотим. Остановка закона Мура не за горами. Давно пора уже направить усилия людей во что-то реально полезное, а не переизобретение велосипедов. Если, за столько лет, Web не смог справиться с этой задачей — может, оно уже и не стоит того? Подумайте, наконец, о конкуренции в глобальному смысле — у веба толком конкурентов нет, вот он и деградирует? А если даже с конкурентами деградирует — тем более пора хоронить.
Об определении новых тегов, чтобы кратко выразить новые контролы хотя бы в том, что есть — в HTML — разумеется, даже мечтать не приходится. Проект Polymer скорее мёртв, чем жив, во всяком случае для практической работы пока что не пригоден. Возможно, так во младенчестве и умрёт.

Это бред. Автор, советую разобраться в теме сперва, прежде чем делать такие заявления.


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

Аналогично. Явный недостаток знаний матчасти.


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

P. S. А еще автор, похоже, не очень понимает что такое WebAssembly и зачем он, если упомянул его в суе в контексте работы с представлениями.

Возможно, так во младенчестве и умрёт.

О, да. Во младенчестве, выпустив версию 1.9.1, и благополучно смигрировав в ветку 2.х. Я тоже поржал.

Каков процент использования Полимера в реальных сайтах? Стремится к нулю линейно или асимптотически?

А вам зачем в штуках сайтов? Не понимаю, зачем это нужно может быть.


Я оцениваю число людей в коммьюнити, качество документации, качество кода, благо он весь открыт, как самой библиотеки, так и конкретных компонент. И это все на вполне приличном уровне. Баги есть, кудаж без них. Пожелания неисполнимые к авторам тоже есть. Скажем, они видимо живут в идеальном мире, где компонент — это лишь HTML, у меня же масса SVG, а с поддержкой namespaces у них того, сложности…


Тем не менее: 130 коммитеров у самого полимера, без библиотеки компонентов. Далеко не все из гугля, я бы сказал, что основные 10-20 оттуда, а остальные кто попало. Десятки релизов, тысячи компонент выпущено, сотнями я лично пользуюсь, написал примерно 20 своих. Среди сообщества — такие компании, известные лично мне, как Vaadin Ltd.


Это никаким боком не похоже на умирающий проект. Скорее уж на какой-нибудь Кобол, который даже если захотеть — не умрет все равно. Займет свою нишу, и будет жить вечно.


И да, я ни разу за полгода не вспомнил о Shadow DOM, не понимаю, откуда взялось ваше нежелание его видеть. Может, вы на версию типа 0.5 смотрели?


Причем, заметьте — авторы, они все на node. У них все средства разработки — это polymer-cli, bower и т.п., и все это нода. У меня ее нет, от слова вообще. Java, и все такое. И при этом я не испытываю особых неудобств, разрабатывая как приложение, так и компоненты.

Зачем в штуках сайтов? Узнать, пошла ли технология в массы. Вы не будете, надеюсь, утверждать, что компоненты в HTML — это сугубо нишевая технология, нужная лишь в узкоспециализированных задачах?
Какое отношение Полимер имеет к компонентам в HTML кроме исторического?
Простите, а помимо использования Web Components там есть что-то еще интересное, что отличало бы ее от десятка других?

В смысле историческое? Последний коммит — 12 дней назад, какаяж это история? Можно сколько угодно считать, что это неперспективно, но это живет прямо сегодня.

Полимер больше не включает в себя полифил для веб-компонентов; веб-компоненты можно делать и без него.

Так их и раньше можно было без него, какая тут связь-то?

"Раньше" без него можно было только на тех браузерах которые веб-компоненты поддерживают.

Раньше без него можно было делать компоненты например на x-tag. И?


Куда-то делись старые браузеры? Стали поддерживать веб-компоненты сами, без полифила? Куда-то делся сам полифилл, AFAIK написанный командой полимера? Вроде нет, лежит на гитхабе.


Кроме всего прочего, полимер это еще и библиотека компонент, и не маленькая. Они тоже стали историей?


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

Я уже писал выше. Полифил для веб-компонентов начиная с некоторой версии был выделен из полимера в отдельный проект.


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

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

Понял вашу поправку. Считайте, что в статье я имел в виду Веб-компоненты.

Нет конечно, это самая что ни на есть массовая технология.


Я просто все равно не очень понимаю, зачем вам массовость в таком смысле? Ну разве что если вы технологию собираетесь продавать (либо саму, либо услуги), книжки там писать. Тогда чем массовее (и чем ниже квалификация), тем лучше.


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

жаваскрипт — именно так читается, а не транслитерируется
Читается американцами. Но разве это американцы пишут кириллицей слово «Джаваскрипт»?
И русскими тоже английское слово javascript читается как жаваскрипт. Я не спорю с тем что русские пишут и читают иначе (а жаль, нас бы лучше понимали). Но автор в статье приводит пример слова mocha, и говорит что его нельзя писать и читать по русски транслитерируя. Т.е. в этом случае правильнее читать как читают американцы. Неконсистентные рассуждения, или некорректный пример.
А Пекин вы тоже Беньжингом называете?
Кстати, задался вопросом, а как русские читают JS, как ЯС, следуя логике?
Предлагаю вариант ЖабийСкрип :)
Хочу пару слов сказать про деньги. На мой взгляд, если бы Ларри Эллисон из Oracle не был бы таким жадным до денег, Java-машина уже давно бы была встроена во все браузеры, а доминирующим языком веб-разработки был бы Java.

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

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

Ларри купил Sun в те времена, когда в апплетах уже многие разочаровались. Так что я хоть и согласен в целом с выводами, но только вы их не по адресу. И реально сделать то, что вы хотите, вероятно станет возможным только сейчас, с выпуском модульной JVM 9. Да и то, не факт, не факт.


Понимаете, JVM же не ставится вместе с браузером. И она большая, даже по нынешним временам. А уж 20 лет назад — и подавно была.


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

Так что я хоть и согласен в целом с выводами, но только вы их не по адресу.
По-адресу-по-адресу. Я лично знаю как минимум одну компанию, которая хотела интегрировать Java в браузер — так же, как сейчас интегрирован JavaScript. И имела работающий прототип к тому моменту когда Ларри решил, что можно срубить с неё через Java многа многаааа, МНОГАААА денег.

Разумеется все разработки были тут же свёрнуты.

Понимаете, JVM же не ставится вместе с браузером. И она большая, даже по нынешним временам. А уж 20 лет назад — и подавно была.
И, тем не менее, она ставилась вместе с самыми первыми версиями Netscape. Только вот уж очень сначала Sun, а потом Oracle хотели денег получить. Потому вместо полноценной интеграции и были придуманы апплеты и NPAPI.

Вот если кого стоило бы поругать — так это хозяев Adobe. Которые по сути убивают Flash уже много лет, своими руками. Им даже помошники не особо нужны в этом.
Ну тут скорее Стива благодарить нужно. После его демарша закат, фактически, начался…

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


А тут компания сама делает все, чтобы убить свой же продукт, который сначала купила… Вот это я не пойму.

UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Я, обычно, когда передаю дату в json, перевожу её в миллисекунды методом .getTime(). Это гораздо удобней, чем парсить потом разные форматы. Заодно и вопрос с timezone решается. Для сервера сразу всё становится однозначно.
UFO just landed and posted this here
Вы же не генерируете для JS особый код на ассемблере для вызова процедур с возвратом, который покладёт на стек соответствующий адрес, а потом заберёт его назад? Не запускаете линкеры, которые соединят вам два модуля и пропишут настоящие адреса глобальных переменных?

Генерируем, к сожалению. Emscripten/asm.js/WebAssembly.
Филологическое отступление.

Правила русского языка говорят нам, что имена собственные не перводятся, поэтому какой-нибудь Jackob Jason Jupiter по-русски правильно будет назваеться Джекобом Джейсоном Джупитер, а не Якобом Ясоновичом Юпитером. То же касается и Java/JavaScript. Да и .js все же удобнее звать джей-эс. Однако язык не стоит на месте и подозреваю, что правильным произношением на русском будут уже оба варианта — в качестве консенсуса: разработчикам часто приходится использовать английские слова и аббревиатуры в своих сферах и для того чтобы иметь возможность обратную устную связь приходится поддерживать несколько вариаций произношения одного и того же слова.
P.S. Известная Studio Ghibli, ранее при переводах озвучивалась как Студия Гибли. Вполне корректно, учитывая итальянско-арабско-ливийское происхождение названия. Однако же Миядзаки назвал свою компанию ジブリ и на русском оно должно называться Дзибли согласно поливановской транскрипции, поэтому некоторые русские озвучки были скорректированы под это название. Но моя душонка не приемлет такого изуверства, поэтому продолжаю при случае называть ее на итальянский манер.
Имя собственное страны USA отлично переводится как США.
Это аббревиатура названия страны — раз.
Топологические названия вообще не очень из английского заимствуются да и вообще имеют особое отношения с заимствованиями. Например, у нас Румыния, а не Романия (Romania) и Кёльн, а не Колон (Cologne). Это два.
Самоназвания часто просто игнорируются, причем в обе стороны — вы для них я буду рашн фром Раша, а не русский из России.
Скорее всего вы сможете найти еще несколько исключений, где будут кальки/портмоне-слова/синтаксические переносы не попадающие под основные правила русского языка. Исключения найдутся везде.
В правила русского языка отнюдь не входит дословное отражение иностранной речи даже в именах. Знаете такого писателя Генриха Гейне? А он ведь Хайнрих Хайне.

Да и «Мао Цзэдун» у нас пишется без тонов.
Э-э-э, а почему Колон (Cologne) а не Köln? Это в конце концов немецкий город, а не английский.
Просто для наглядности.
Парадный портрет автора, заодно иллюстрирующий идею современной веб-разработки
Отлично! В лучших традициях конца прошлого века. Ностальгия! Оч. понравилось. Теперь о том, что не совсем понравилось:
Неужели отображение данных на экране для просмотра и редактирования — такая неслыханная и невиданная задача, что никто не знает, с какой стороны к ней даже подступиться? Я вас умоляю. Она решалась столько раз, что даже просто перечислить — заболит палец, жмущий на клавишу «запятая». Так, навскидку, то, о чем я слышал: терминалы IBM 3270, Смоллтолк, экранный Постскрипт, WinAPI, TurboVision, VisualBasic, dBase, Tcl/Tk, XUL, Rebol/View, XAML.

Зачем валить в одну кучу как минимум два решения с противоположными целями? — Так будет еще меньше ясности. Постскрипт и т.д. (еще TeX забыли упомянуть!) своей целью имеет точное 1 в 1 воспроизведение верстки на любом устройстве — будь то стационарный дисплей, принтер или eBook или телефон. У HTML противоположная цель — переформатировать контент в зависимости от устройства вывода наиболее удобным для чтения образом. В первом случае задача решаема и решение найдено, нпр., pdf-формат. А во втором — задача в общем случае неразрешима, поэтому все попытки правильного отображения элементов оформления работают в не очень широких пределах. Чем больше таких элементов оформления и чем они сложнее — тем хуже они воспроизводятся на всем зоопарке возможных устройств. Это закон природы, и ничего тут не поделать. Поэтому чем проще веб-документ — тем лучше. Однако многие веб-дизайнеры не страдают отсутствием аппетита и так хотят кушать, что очень часто пытаются ухудшить уже сделанное. Т.о. ИМХО проблема даже не в вебе, а в недоедании дизайнеров.
Display 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. И что это меняет в моих словах?

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

Остров этот по-русски называется Ява, а не Джава, соответственно, кофе на нём яванский, а языки именуются, следовательно, Ява и Яваскрипт

А где в русском есть слово script? Так и пишите — Яваносценарий.
А где в русском есть слово script?

скрипт — см. анализ трансакционный. Словарь практического психолога. М.: АСТ, Харвест. С. Ю. Головин. 1998
Есть слово, низачот вам
Я рад, что есть люди, которые не стесняются написать «а король-то голый».

Недавно вышла статья Using a React 16 Portal to do something cool. Что же такое «something cool» в понимании современного веба? Это когда два [зал затаил дыхание] браузерных окошка [барабанная дробь] принадлежат одному react-приложению! Whole New Thing, киллер-фича, инновации и нанотехнологии, блеск и нищета. Посмотрите как просто это делается.

Это всё похоже на какой-то чудовищный культ карго. Хватит делать кнопки, выпадающие списки и лагающие датагриды из дивов и палок. Нужно просто (ок, не просто) засунуть Qt/GTK/Wx в браузер и миллионы людей, пишущих скучные безликие приложения для далёких от IT розовощёких директоров, которым кто-то поездил по ушам и сказал «десктоп — прошлый век, веб — круто», вздохнут с облегчением.
UFO just landed and posted this here
Этим уже занялись. Да, процесс идёт неспешно, ну так и Москва не сразу строилась.
UFO just landed and posted this here
Не статья, а нытьё какое-то. Не понимаю, что за ажиотаж вокруг неё
Наверное, потому что у множества людей современные веб-технологии вызывают глубокую печаль.
Просто в противовес неуместной восторженности статьи «Объясняем современный JavaScript динозавру»
Ну, сам иногда страдаю нытьём. Но это ж не посиделки на кухне за чарочкой со слезами. Это ж всё таки вашу статью будет читать народ, скажем так, с критическим отношением ко всему и новому, и старому. А то получается, jQuery видите ли ему ерунда полная! Придумай другое, своё. Или я что-то не понимаю? Критика ж должна опираться на железобетонные аргументы, а не быть настроением.
Так ведь придумывают, и придумывали не раз, в статье даже список длинный список технологий приведён. Проблема в том, что в массы оно не пойдёт без таких статей, ибо не будет критического осмысления. Ведь если кто-то не видел альтернатив, то так и будет писать «видите ли ему ерунда полная», не так ли?

Вот jQuery как раз-таки жизнеспособна. А почему она "выстрелила"? Да потому что убрала "лишнюю" сложность. Было два способа получить список DOM-узлов:
в JS — document.getElement[s]*
в CSS — селекторы.
jQuery принесла в JS возможность работы с селекторами. И, по моему скромному разумению, она ещё долго протянет :)

Читается на одном дыхании. Респект за критический анализ, полезный таким как я, неспециалистам.
UFO just landed and posted this here
Sign up to leave a comment.

Articles