Комментарии 243
И где обсуждение ява-апплетов? Они решали многие из перечисленных проблем.
Но теперь флеш из браузеров выкинули т.к. производители не хотят чтоб кто-то со стороны имел такое влияние.
Вариант "потому что было слишком много дыр" не рассматривается?
А всё для чего использовали флеш/жава-апплету уже может обычный хтмл5.
Сильное заявление.
Так влиять-то и не нужно. Нужно было выпустить новую версию API для плагинов, а их разработчики бы дальше сами суетились.
Но этого не было сделано именно потому что, согласно современным представлениям, само наличие каких-то левых плагинов — уже дыра в браузерной песочнице.
Еcли вы уверены, что эту схему можно обойти и дернуть нативный вызов напрямую, обойдя песочницу, то предлагаю вам написать в bughunt программу гугла и получить ваши ~15000$Не стоит так кидаться словами.
Дело в том, что все звери равны — но некоторые равнее. Специально для флеша Хром предоставляет несколько приватных интерфейсов, которые, с одной стороны далают «Flash на PPAPI (да-да, точно-точно, верим-верим)» возможным, а с другой — приводят к том, что Flash-таки может «вешать браузер».
Ну не смогли они сделать из PPAPI что-то, чем реально можно пользоваться.
Ну так где я кидался словами?Вот тут:
Посмотрите на PPAPI для хрома, через который уже лет 5 как работает флеш плеерЕсть «безопасный» и «правильный» PPAPI. А есть «PPAPI для флеша» — и это разные вещи.
P.S. Комментарий я действительно не туда отписал.
PPAPI (без «заднего прохода для флеша») не позволяет этого сделать в принципе, что автоматически ставит крест на том, чего люди хотели от NaCl'я больше всего: возможности писать на более вменяемых языках, чем JavaScript.
Что, правда, приносит и пользу, как бы: PPAPI-плагины не могут «завесить» браузер, ура. Но вред, хотя и менее очевиден, но более весом: в силу того, что пользоваться этим крайне проблематично и «замену флеша» сделать невозможно — то этих плагинов, как бы, так и не появилось в сколько-нибудь ощутимом количестве.
Но этого не было сделано именно потому что, согласно современным представлениям, само наличие каких-то левых плагинов — уже дыра в браузерной песочнице.
А разве это не так? По-моему, львиная доля дыр в Java и Flash — в самих плагинах. Не все, далеко не все — но очень большая доля.
Да, так и есть. И пальма первенства тут, кстати — у Java, где браузерный плагин позволял апплетам из соображений совместимости использовать устаревшие версии JRE :-)
Ну и что бы тут изменил другой API? Ведь по любому, плагин, такой как Java или Flash, и только он, знает, что он там исполняет. Он видит и работает с кодом. Полноценный статический анализ безопасности практически не возможен (для JS в первую очередь, я совсем не уверен, что для Java и Flash с этим реально хуже — хотя тоже грустно). И контролировать его целиком браузер вряд ли сможет.
В какой-то мере это ведь и к wasm относится, хотя тут конечно все иначе — тут байткод, и сравнительно простой.
Полноценный статический анализ безопасности практически не возможен (для JS в первую очередь, я совсем не уверен, что для Java и Flash с этим реально хуже — хотя тоже грустно).Вот как раз эту проблема — разрешима. Посмотрите на NaCl — там не то, что C с C++, там ассеблер можно было использовать — и всё это безопасно потом запускать. Даже на Windows XP.
Убили всё это из политических соображений, а не технических./
Не, ну там кажется внутри все равно байткод (LLVM), разве не?
Вот тут описано как программировать в 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, как только получит оповещение. И включит после обновления. Значительно быстрее, чем это сделаете вы сами.
Практически отсутствуют, если не считать вездесущий, который,
У вас, кажется, парсер что-то не то съел.
С аргументами в целом согласен — но я не понимаю как из них следуют выводы.
Вот есть технология X. Которая упрощает разработку. Почему от нее надо отказаться только на основании того что она не делает Y — при полном отсутствии делающих Y технологий?
А дальше уже каждый думает для себя — готов ли он с этим костылем жить и дальше, учитывая, что Y нет и не будет, и не питать иллюзий о быстрой и производительной веб-разработке, или же заниматься чем-то другим.
Говорил правильно но закончил слегка не тем.
Проблема не в самих языках HTML, CSS, JS или их ущербности. А в том, что много фич просто находится на полпути к готовому продукту. И вместо того, что бы взять и за «5 минут» допилить существующие, все усилия сообщества ГОДАМИ уходят на изобретение велосипедов (В этом я с автором согласен).
Это как пришли болты, но без резьбы, и их приходится кувалдой заколачивать. Зато если стал на место то перманентно на века. А если не стал…
P.S. Вся «стройная» структура JS заточена на то, чтобы быстро обрабатываться интерпретатором. И только… Смысла менять её НЕТ. А то, что кому-то не удобно, это его проблемы (пусть сломает себе мозг).
Хорошему танцору и кегли в радость!
И ведь, если задуматься, то, на самом-то деле это вовсе не так безумно, как может показаться на первый взгляд. Ведь:
Отвечаю. По сравнению с куда более мощными и тщательно разработанными десктопными интерфейсами у веба есть два мощных козыря: идеальная независимость от платформы и ненужность инсталляции приложений
Во-первых, идеальной независимости от платформы нет и у веба, если не от ОС, то от браузера (свежа еще память об IE6?). Во-вторых, как показал опыт мобильных гаджетов, «ненужность инсталляции приложений» вовсе не являет собой непреодолимую преграду для пользователей — буквально на каждом углу висят призывы «скачайте наше мобильное приложение!». То есть вопрос, на самом деле, можно поставить так: как сделать это проще?.. Ведь что такое загрузка современного сайта по своей сути? Это всего лишь скачивание самой последней (текущей) версии приложения, написанного на JavaScript!
А теперь давайте пофантазируем: представим, что какая-то из упомянутых автором технологий, ну например Tcl/Tk, будучи кроссплатформенной и скриптовой, может каким-то образом, аналогично сайту, скачиваться на любое устройство пользователя, хоть Android, хоть десктоп на Windows или Linux, и тут же отображать пользователю GUI. Представили? Ведь это же и будет тот самый убийца Web, так как решает те же задачи!
Oh, wai~~
И спасибо за статью, очень верно разложено все. И еще очень хорошо, что автор сам тоже занимался веб-разработкой, чтобы нельзя было нахрапом к нему применить спервадоб-аргумент. :)
А теперь давайте пофантазируем: представим, что какая-то из упомянутых автором технологий, ну например Tcl/Tk, будучи кроссплатформенной и скриптовой, может каким-то образом, аналогично сайту, скачиваться на любое устройство пользователя, хоть Android, хоть десктоп на Windows или Linux, и тут же отображать пользователю GUI. Представили? Ведь это же и будет тот самый убийца Web, так как решает те же задачи!
Так это же и пытались сделать Ява-апплеты и Флэш. Основным недостатком Ява-апплетов, на мой взгляд была излишняя громоздкость (в сравнении с Питоном или Тсл/Тк), основным недостатком Флэш была закрытость. Но в целом они именно это и делали.
Легковесный контейнер, жёстко, на уровне железа изолирующий скачиваемое приложение от клиентской машины и предоставляющий ограниченный, контролируемый системой прав доступа и квот интерфейс к устройствам на клиенте (можно дополнить его встроенным легковесный интерпретатор типа Питона/TclTk) по идее должен бы решить проблему безопасности. Но это будет громоздкая конструкция. Если же такой контейнер соорудить, то почему бы тогда не разрешить запускать в нём бинарные файлы?
Кстати, что-то я не вижу, чтобы всякие игрушки, типа огорода на ок.ру, написанные на Флэш, активно переписывались на HTML5, что ставит под сомнение утверждение о том что HTML5 может его заменить…
HTML5 может его заменить…
Да он его, честно говоря, даже в области бизнес-приложений (т.е. Flex) все еще не может заменить полноценно. Т.е. там, где не нужна ни быстрая графика, ни видео стримы, ни все такое. Потому что фреймворк виджетов в Flex, и сам набор виджетов, которые там были (в том числе — и написанные пользователями) был настолько хорош уже к 2009 году, что мы и сегодня ничего подобного не имеем.
И да, юзеру и песочница/контейнер по большому счеты не важны — можно было бы запускать и бинарные файлы (ну в наше время, понятно, можно иметь подписи).А вот на этом обжёгся Microsoft. Подписи не работают. Вначале пользователь научается жать кнопку «да» на всё на свете, потом, несколько раз переустановив систему — научается жать кнопку «нет». Изучать подписи он, в общем, так и не научается.
Вот ведь что на самом деле решил Web, и на что на самом деле надо смотреть, а не на стек контейнеров.Совершенно верно, но непонятно как ваша нирвана может придти на компьютеры пользователей.
Потому что веб-браузер — он уже как-то эту задачу решает и он уже есть. Почему вдруг кто-то захочет куда-то переходить?
Ну разве что если Android придёт на рынок desktop'ов и принесёт своё решение этой проблемы (Google Play)… что возможно, но явно не в ближайшей перспективе…
Ну разве что если Android придёт на рынок desktop'ов и принесёт своё решение этой проблемы (Google Play)… что возможно, но явно не в ближайшей перспективе…
такое решение для десктопов уже есть в виде AppStore и MS Store, и судя по количеству софта там оно не взлетело.
Но ведь вопрос исходного поста таки был не в том, как именно «такая нирвана придет» в нам, не правда ли?..
Может я не правильный человек какой-то, но я всегда выключаю html отображение письма.
А пока все ищут ту самую работу мечты, я поделюсь мыслями о вебе:
1. Доля open-source в вебе как на клиенте, так и на сервере близка к 100%. И мне это очень нравится. Какой еще сегмент IT может похвастаться тем, что проприетарный код там вообще не котируется?
2. Огромное, дружелюбное и открытое сообщество (я, конечно, имею в виду англоязычное ;) ).
3. Вакансии на любой вкус. Зарплаты, на которые вполне можно жить.
4. В конце концов, здесь реально что-то происходит. А какие последние новости, например у разработчиков SCADA? И, кстати, где их можно почитать?
Я, конечно, еще довольно молод, но я помню веб эпохи диал-апа и IE5. Так вот: веб стал лучше. Намного лучше.
Если есть люди, говорящие «в этом вашем вебе все через ж...», то, наверное, есть в IT какая-то область, где все хорошо.
В геймдеве вроде всё вполне себе норм. Не могу припомнить никаких особых архитектурных проблем. Даже от вечной обратной совместимости GAPI уже ушли.
Моя точка зрения пользователя такая что с каждым годом веб становится все тяжелым и неуклюжим. Раньше мне не доставляло проблем запустить 20 вкладок и работать с ними. И я не парился что мне не хватит памяти и все зависнет и упадет. А сейчас даже закрытие вкладки зачастую не означает что память освободится. И теперь для работы в вебе мне нужно 8 гиг памяти…
Так, вместо тормознутых почтовых веб-сервисов типа GMail используется старый добрый почтовый клиент. Хотя по нынешним временам стало очень трудно найти почтовик без встроенного браузера со всеми его тормозами, так на вскидку кроме Sylpheed ничего и не припомню.
Для просмотра лент с соцсетей и новостных лент используется RSS-агрегатор. Хотя по нынешним временам крайне сложно найти RSS-клиент без встроенного браузера — я не знаю ни одного GUI-клиента, который не тянул бы с собой тормознутый браузерный движок.
Вместо youtube и подобных видеосервисов используется потоковый плеер.
Ну и всё в том же духе. Большинство веб-сервисов заменяется автономными приложениями, а немногие статические странички просматриваются в links2 или подобном браузере, который отлично их рендерит, даже с графикой. В таком режиме можно хоть с Raspberry Pi комфортно в Интернете сидеть.
А зачем мне на смартфоне все письма целиком? Где хранить черновики? Почему нельзя написать письмо на компе, а дописать и отправить его со смартфона?Это хорошие вопросы, но они не обьясняют — зачем вам для всего этого гонять туда-сюда мегабайты кода. Драфт записать на сервер — отлично, но зачем для этого весь UI с сервера скачивать каждый раз, когда вы почту хотите почитать…
Впрочем GMail на смартфоне и не скачивает и HTML5 для UI не пользуется… что как бы и показывает ненужность всего «котла», который обсуждается в статье…
Это легко проверить, нажмите F12 — увидите что ничего из вашего юая не скачивается, все берется из дискового кеша.А вы проверьте. Мой эксперимент — первый запуск при «пустом» кеше скачивается порядка 10 мегабайт, повторное открытие сразу после этого — где-то мегабайта два.
Или, что ещё проще, перестаньте полагаться на F12, а просто подключитесь к телефону на 2G и испытайте весь «amazing experience» современных веб-технологий.
Да все то же самое. Не считая того, что это приложение точно так же надо скачать (хотя конкретно это уже поставили за вас). А у разработчиков опционально добавляется геморрой в виде поддержки нескольких версий апи.Это временно.
А это значит, что для другой почты мне нужно другое приложение. Которое опять надо скачать и обновлять.Но вы можете контролировать этот процесс, хотя бы.
Да все то же самое.Всё — но не всё. Инструменты разработки — невероятно убоги. Ресурсы, необходимое для запуска приложений — отличаются на порядки (либо, что чаще, нативное приложение на пару порядков больше умеет).
Сравните хотя бы MS Office и Google Docs. Я, кстати, активно пользуюсь Google Docs — так как тот факт, что за них не нужно платить и их не нужно устанавливать часто решает… но над второй проблемой уже работают, а первая, как бы, к качеству технологий вообще отношения не имеет.
И что? Два, десять, пятьдесят. Да хоть триста. В чем проблема, с точки зрения юзер экспириенса, если сеть позволяет? Почему вы технические хотелки выдаете за проблему?Потому что они становятся проблемой как только вы ступаете за пределы МКАД. Не обязательно куда-нибудь в Карелию. Вот, например, ОпСоС из вполне себе продвинутой страны — Германии. Что мы видим на первой странице? Правильно: гордое заявление о том, что в самом популярном тарифе количество траффика увеличено с 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'ам
По производительности — возможно. По фичам — нет.
Да, не могут. Точно так же они не смогут пользоваться инстант приложениями, которые вы упомянули как решение проблемы. Вот к чему я веду. Эти инстант приложения точно так же будут потреблять трафик.При использовании их как инстант приложений — да. Но… читаем:
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 вкладок открыты и ничего не тормозит.
Чтобы проблема была признана официально, она должна воспроизводиться у значительного числа пользователей
У меня был Mac Mini 2012 года выпуска, в нем как раз 4 Гб памяти и нет SSD.
Стандартный набор: браузер, почта, мессенджер — работал нормально. По памяти затык случался только при просмотре FullHD видео или открытом фотошопе.
С этим согласен, больше памяти лишним не будет, программы станут отзывчивее.
Однако, я не понимаю как из утверждения "программы жрут все больше памяти" следует "веб тяжелый и неуклюжий". Только браузерам нужна память? Остальные программы по-прежнему вмещаются в 640 килобайт?
Если браузер открыт постоянно, то почему бы ему не выделить больше памяти, раз он вам нужен? Звучит справедливо.
Кроме того, прочтя раздел "Есть ли свет в конце туннеля?", я так и не увидел предпосылок к снижению потребления памяти. DSL для построения интерфейсов, иерархия виджетов — выглядит как повод для браузеров сожрать еще больше памяти, которой и так немного.
Я абсолютно серьезно, расскажите.
Не могу вам ответить конкретно, но субъективные ощущения примерно такие же. Несколько лет назад тоже не закрывал вкладки никогда, и держал их по 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.
А не важно, кто именно. Главное, чтобы это был кто-то один. Одна команда.
И почему вы считаете, что их "надо" совпадет с вашими задачами?
И костыли не понадобятся.
Понадобятся — для того, чтобы реализовывать то ваше "надо", которое эта команда забыла учесть.
В жизни, ключевые решения, в большей мере принимаются бизнесом с точки зрения зарабатывания денег. А деньги всегда хочется заработать побыстрее. Посему, в отсутствии конкуренции и противовесов, решения будут приниматься исходя из сиюминутной жадности. Так уж мы устроены. Уже как раз сто лет как это наглядно демонстрируется. Пора бы и выводы сделать.
PS: И даже эта техническая команда не святым духом питается. Далеко не все будут работать за идею. Некоторая часть, почему-то, захочет ещё и денег.
Вообще-то правило. Когда есть кто-то один, люди, там работающие, редко видят мотивацию делать лучше — не с кем сравнивать. Они же уже делают круто. И все достаточно быстро скатывается.
лавное, чтобы это был кто-то один. Одна команда. Только тогда архитектура обретёт целостность, а не будет эклектической смесью кучи разных концепций, зачастую вообще взаимоисключающих.А все кто посмеет не согласится с этим кем-то-одним и его мироустройством, как например я или автор этой статьи, могут идти куда? Строить свой альтернативный браузер?
А с остальными 20% что делать?
После чего все вернется на предыдущую стадию. И где профит?
Потому что будет неопределенное множество неуниверсальных, с которыми тоже придется считаться.
Неуниверсальных, значит, специализированных, применимых для узкого круга задач.
Не совсем так. В реальности людям всегда будет нужно "80% и еще немного", поэтому будут появляться "браузеры", покрывающие 80% (не обязательно так же, как универсальное решение) + ту часть, которая нужна их разработчикам. Соответственно, разработчики "сервиса", работающего с этим "браузером", будут ориентироваться на то, как 80% имплементированы там (потому что это проще). Так и расползется.
это гораздо лучше нынешнего бедлама
Ровно до тех пор пока вы в счастливых 80%, вам будет "гораздо лучше". Как только вам понадобится сделать что-то из неохваченных 20%, то все нытье начнется заново: убогая платформа, костыль на костыле.
Так текущее состояние веб-платформы вполне удовлетворяет потребности 80% сайтов. Лишь 20%, которые не сайты, а веб-приложения с трудом вписываются.
Если что-то радикально перекраивать, то это может негативно затронуть те самые 80% обычных сайтов, которые в общем-то и сейчас неплохо работают.
И ради чего тогда это затевать?
Если что-то радикально перекраивать, то это может негативно затронуть те самые 80% обычных сайтов, которые в общем-то и сейчас неплохо работают.Те 80% сайтов, которые и так работают никто не предлагает перекраивать. Речь идёт о 80% решении для 20%, которые «не вписались»…
Статья завершается параграфом
Если, наконец, производители браузеров выкинут всё накопившееся старьё и напишут с нуля нормальную интерфейсную среду
то есть никакой обратной совместимости в идеальном плане автора.
В Mozilla тоже пробуют переписать браузер с нуля: project servo.
Насколько я понимаю, под словами "выкинут накопившееся старьё" автор имел в виду не легаси код, а легаси веб стандарты, которые вынуждены поддерживать существующие браузеры.
Перестать их поддерживать, не сломав при этом часть сайтов в интернете — не получится.
Ну в общем случае легаси — как нечто, что требует совместимости за счет каких-то ресурсов.
Да в принципе может получиться, но придется как бы заморозить «старый» интернет и параллельно отображать «новый», это как два движка в одном браузере, такие даже были, хотя это и не про контекст… :)
Да собственно всё уже сделано, осталось только дождаться пока его можно будет использовать вместо HTML+JS+CSS…
По ссылке рассказывается про Android Instant Apps. Если серьезно рассматривать это как альтернативу текущей веб-платформе, то остается вопросов больше чем ответов.
- Откуда загружаются данные? Насколько я понял, с серверов Гугла. То есть доступность вашего сервиса будет зависеть от милости Гугла. Это не ок.
- Какой размер у типичного android-приложения? Из этой статьи cледует что hello world весит 1,5 мегабайта. В то время как современный сайт загружает около 500 килобайт и это уже кому-то кажется много.
- А что с десктопом? По ссылке рассказывается только про Android-девайсы, поддержки iPhone или десктопов там не видно.
Откуда загружаются данные? Насколько я понял, с серверов Гугла. То есть доступность вашего сервиса будет зависеть от милости Гугла. Это не ок.Во-первых, как показывает успех iPhone — многих это устраивает. Во-вторых — ничто не мешает развить технологию и сделать возможным установку и из других источников.
Какой размер у типичного android-приложения? Из этой статьи cледует что hello world весит 1,5 мегабайта. В то время как современный сайт загружает около 500 килобайт и это уже кому-то кажется много.А 500 килобайт — это уже минифицированная версия? Да и в той же статье — если удалить AppCompat — то будет 108К, что уже более, чем сравнимо с современными «гостевыми книгами».
А что с десктопом? По ссылке рассказывается только про Android-девайсы, поддержки iPhone или десктопов там не видно.Вот поэтому я говорю: " осталось только дождаться пока его можно будет использовать вместо HTML+JS+CSS"…
Процесс идёт. Медленно (хотя по историческим меркам — достаточно быстро: с нуля до половины — за 8 лет… надо полагать переход с половины до конца примерно столько же времени займёт), но уверенно.
Но одно обидно: за столько лет веб-разработка не устаканилась до состояния внутренней согласованности. И не скоро устаканится. Но, как говорится, не было бы счастья, да несчастье помогло: десктоп тоже не особо устаканился.
В общем, пошёл дальше пилить формочки да консольки.
2) Ваша портянка про стандартные библиотеки элементов — полное противоречие и реальности и тому, что в статье написано.
Сейчас браузер предоставляет стандартный набор элементов и всё. Если тебе не хватает — ССЗБ. Задача про «поменять цвет кнопки при нажатии на другую» — это как раз оттуда. Браузер дает стандартные контролы и минимум возможности как-то их расгирять и изменять.
и если обычные баттоны не поддерживают достаточную кастомизацию — их просто не используют
Вместо того, чтобы сделать базовые элементы более кастомизируемыми, вы предлагаете от них отказаться полностью, и каждому пилить что-то своё? Из-за невозможности отрегулировать седло, каждому приходится делать собственный велосипед, под свой рост. Разве это нормально?
Меня лично устроили бы совершенно некрасивые, лишь бы все работало быстро на любом железе, которое сейчас встречается.
А в реальности мне достаточно комфортно использовать любой сайт (ах да, веб-приложение) на стационарном i5-2500k@4Ghz с 16 Гб памяти, ноут с Pentium 3558U и 4 Гб памяти иногда ощутимо подтормаживает. Про ноуты на Atom я вообще молчу, а они есть, да.
Поэтому в гробу я видал красивые кнопочки и тех, кому они нужны. В погоне за красотой они сделали веб таким тормозным, что я даже не знаю с чем его сравнить.
А можно узнать каким именно людям хочется таких кнопок?«Поколению Apple», условно говоря. Вот типичная ремарка: Есть еще Gerrit, который там как-то с этим борется, но интерфейс из 90х убивает все желание пользоваться этим.
Заметьте, что речь идёт об инструменте для работы с Git-репозиториями — то о гиковстве вполне себе ненулевого уровня… и тем не менее первый критерий, по которому это всё оценивается — это по параметру «модно, стильно, молодёжно»…
Поэтому в гробу я видал красивые кнопочки и тех, кому они нужны.Увы. Их слишком много и потому всё что делается — делается под из нужды.
Времена гиков — прошли, теперь компьютеры делают для людей, которые выбирают не удобную одежду, а модную.
В погоне за красотой они сделали веб таким тормозным, что я даже не знаю с чем его сравнить.Сравните с каким-нибудь Visual Studio 2017… и вы увидите, что тормознутость web'а — это, увы, частный случай.
Пока что не соответствует действительности. Из Firefox потихоньку "выпиливают" фирменную технологию байндингов XBL (но и то ещё на ранних этапах), а XUL пока что остаётся и даже кое-где развивается (например, одной из составляющих в замене XBL станет поддержка Custom Elements в XUL). Другое дело, что с Quantum XUL окончательно становится деталью реализации, поскольку дополнения доступа к нему лишаются.
Проект Polymer скорее мёртв, чем жив, во всяком случае для практической работы пока что не пригоден.Вроде весь интерфейс YouTube на нем построен, разве нет?
Все верно. Там проблема только в том что старая версия спецификации web components, потому что polymer сделали когда их только Хром поддерживал как раз в том числе, чтобы продемонстрировать, что технология жизнеспособна
Но кому придёт в голову называть microsoft excel языком программирования?Нудным голосом: К вашим услугам 91 в категории «Разработка приложений», специализирующихся на услуге «Разработка приложений для Excel ».
Да, Excel нонче менее популярен, чем HTML+JS, но было время, когда на нём немало приложений писалось…
Но кому придёт в голову называть microsoft excel языком программирования?
Но VBA ведь вполне себе язык программирования. Когда говорят про программирование для браузера, имеют в виду не HTML (по крайней мере, грамотные люди), а JavaScript.
Это примерно как заявить, что запросы к базе данных никому не придет в голову называть программированием. В современных реалиях, фронт, нередко оказывается гораздо сложнее бека. И тут я имею в виду системную и алгоритмическую сложность, а не распухший тулчейн, который сбивает с толку.
Разделяю ваши фрустрации! Но, боюсь, срыва покровов не произошло:
В мире веб-программирования считается хорошим тоном блуждать в трех соснах, которые называются 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 тестирование, с двумя версиями интерфейса в параллель, потому что эта хитрая жопа не хочет брать на себя ответственность за свои решения. Не, я не против. Если у меня бюджет будет как в Амазоне и Нетфликсе — за ваши деньги любой каприз, а так…
Я к чему… Это больше не поле деятельности инженеров, тут правят дизайнеры и частенько маркетинг, а им чаще всего плевать как все работает, откуда берутся данные, как они вяжутся к интерфейсу, что повторно используется и т.д. Что, в свою очередь пораждает любовь к абстракциям и фремворкам, потому что собственно свой код все равно выраждается в адову копипасту со временем, а душа не терпит посредственности.
Прошу прощения за простыню, сегодня грустный вечер ;-)
Прекрасный комментарий! Вот только стереотипные камни в огороды дизайнеров и маркетологов его портят. И те и другие могут (и должны) относится к своим задачам очень даже инженерно, порой нужно просто сделать над собой небольшое усилие, для того, чтобы увидеть в каком поле абстракций происходит их магический инжиниринг. Грустить по этому поводу точно не стоит.
Камни может и стереотипные, но, по моему опыту, весьма заслуженные. Я говорю о том, что процесс разработки интерфейса стал из двунаправленного односторонним, и реализация (а иногда и функция) сейчас часто вторична по отношению к дизайну. Торг за требования — это часть работы архитектора, передача дизайна в разработку — это передача (и прием) ответственности. Теперь же мне приходится очень часто беседовать на повышенных тонах с дизайнерами и менеджерами по поводу целесообразности очередного решения. И, как правило, убедить кого-то можно только угрожая увеличением бюджета, потому что технические детали не интересны, а "на вебе можно все". Может просто я стал старый и сварливый?
Вы сейчас описали проблему "водопада" — это недостаток организации конкретного рабочего процесса. Я согласен, мало кто из менеджеров и членов команд способен организовать эффективную работу по другой (итеративно-эволюционной) схеме, но, к примеру в моей работе этой проблемы нет. У нас в команде реализуется непрерывное внедрение дизайна и делается это весьма органично. Ключ к победе над "водопадом" — декомпозиция процессов (как и элементов системы) на уровне представлений.
Изначально браузер (да и весь интернет) был документ-ориентированным, состояние жило на сервере, клиент был предельно тупым.
Изначально в вебе состояния не было. О благословенные времена...
Из-за этого нам приходится решать кучку нетривиальных задач по управлению всем этим хозяйством (распределенное состояние, асинхрон, безопасность и т.д).
Вот это и откровенно раздражает. Веб активно развивается более 20 лет, потребность во всём этом барахле появилась без малого полтора десятилетия назад, но эти задачи для нас по-прежнему нетривиальны.
Ух, ну и коммент — такой в отдельную статью размером! И не вода, а полезные замечания.
Потом мир малость поменялся, и сейчас у нас stateless backend (потому что масштабирование) и stateful client (потому что пользователь так хочет). А обработка и данные по прежнему удаленные. Из-за этого нам приходится решать кучку нетривиальных задач по управлению всем этим хозяйством (распределенное состояние, асинхрон, безопасность и т.д).
Концепция «stateless backend и stateful client» с успехом применялась в клиент-серверной архитектуре на SQL. Да, еще в эпоху мезозоя.
Это SQL-то stateless?
А вы хотели только вопрос задать или у вас есть опровергающие аргументы?
Так, стоп, давайте оговоримся. Я неверно употребил термин SQL, имея вместо него в виду RDBMS (которые традиционно являлись бэкендом в таких системах). Вы все еще считаете, что они stateless?
Но мне все равно интересно, почему вы считаете, что реляционные базы не stateless?
Я имел в виду конкретно SQL, поэтому и так написал. В языке нет передачи состояний.
Ну язык — не бэкенд, чего уж.
Но мне все равно интересно, почему вы считаете, что реляционные базы не stateless?
Потому что два последовательных идентичных запроса (INSERT INTO SomeTable (ID) VALUES(1)
) будут иметь разный результат. А если взять транзакции, то будет еще веселее.
Под состоянием обычно понимают состояние сеанса, подключения и т.п… Бэкэнд который совсем не содержит изменяемых частей никому не нужен даже в эпоху поклонения иммутабельности.
Тем не менее, в SQL даже такое состояние есть, в виде транзакций, временных сеансовых таблиц и переменных.
Бэкэнд который совсем не содержит изменяемых частей никому не нужен даже в эпоху поклонения иммутабельности.
Вот поэтому, на самом деле, полезно разделять "бэкенд" и "прикладные сервера". Прикладные сервера вполне могут не содержать никаких изменяемых частей (и, как следствие, легко масштабироваться).
Но я говорю не о том, что SQL не допускает сессионные состояния, тем более, что это не так. А о том, что эта концепция совсем не нова. И только от разработчика-архитектора зависит, будет ли он делать бэкенд с состояниями или без, как на HTTP, так и на SQL.
Все это уже придумано и отлично работаетб вещи типа JSP не менялись годами, а SpringMVC меняется лишь косметически, так что изменения нового мажорного релиза осваиваются за час.
То же и об остальных попытках навязать стандартность. У нас уже есть стандартный 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, и все такое. И при этом я не испытываю особых неудобств, разрабатывая как приложение, так и компоненты.
В смысле историческое? Последний коммит — 12 дней назад, какаяж это история? Можно сколько угодно считать, что это неперспективно, но это живет прямо сегодня.
Так их и раньше можно было без него, какая тут связь-то?
"Раньше" без него можно было только на тех браузерах которые веб-компоненты поддерживают.
Раньше без него можно было делать компоненты например на x-tag. И?
Куда-то делись старые браузеры? Стали поддерживать веб-компоненты сами, без полифила? Куда-то делся сам полифилл, AFAIK написанный командой полимера? Вроде нет, лежит на гитхабе.
Кроме всего прочего, полимер это еще и библиотека компонент, и не маленькая. Они тоже стали историей?
Я никак не могу понять, что за мысль вы хотите донести. Сформулируйте попроще, может тут и вопрос не стоит выеденного яйца.
Я уже писал выше. Полифил для веб-компонентов начиная с некоторой версии был выделен из полимера в отдельный проект.
С этого момента стало возможным пользоваться веб-компонентами без полимера. Поэтому считать веб-компоненты и Полимер синонимами и свободно прыгать в разговоре между ними, как это делает gatoazul, некорректно.
А, я понял. Ну да, считать их синонимами неправильно, веб компоненты вообще сильно шире. Даже если понимать под этим только те, что сделаны на базе четырех свежих технологий… их где-то под десяток разных. И даже если полимер вдруг реально умрет (я удивлюсь), сами эти четыре технологии — однозначный шаг вперед (хотя и не идеальный).
Нет конечно, это самая что ни на есть массовая технология.
Я просто все равно не очень понимаю, зачем вам массовость в таком смысле? Ну разве что если вы технологию собираетесь продавать (либо саму, либо услуги), книжки там писать. Тогда чем массовее (и чем ниже квалификация), тем лучше.
В случае же выбора для себя — какая мне разница, сколько таких как я еще? Все равно 99% этих людей ни на что не влияют. Есть какой-то нижний предел размеров коммьюнити, но на сегодня, при наличии интернета, и он очень даже низкий.
В свою очередь JavaScript является ярким примером компромисса огромного числа бизнес-интересов. Новые же библиотеки и языки, расширяющие базовый JavaScript, это всего лишь попытки крупных компаний и молодых предпринимателей создать и затем монополизировать свою нишу веб-разработки с последующей капитализацией своей интеллектуальной собственности.
Вывод же простой – бесплатный сыр бывает только в мышеловке, поэтому писать по возможности нужно на стандарте, что позволит избежать больших головняков в будущем.
Ларри купил Sun в те времена, когда в апплетах уже многие разочаровались. Так что я хоть и согласен в целом с выводами, но только вы их не по адресу. И реально сделать то, что вы хотите, вероятно станет возможным только сейчас, с выпуском модульной JVM 9. Да и то, не факт, не факт.
Понимаете, JVM же не ставится вместе с браузером. И она большая, даже по нынешним временам. А уж 20 лет назад — и подавно была.
Вот если кого стоило бы поругать — так это хозяев Adobe. Которые по сути убивают Flash уже много лет, своими руками. Им даже помошники не особо нужны в этом.
Так что я хоть и согласен в целом с выводами, но только вы их не по адресу.По-адресу-по-адресу. Я лично знаю как минимум одну компанию, которая хотела интегрировать Java в браузер — так же, как сейчас интегрирован JavaScript. И имела работающий прототип к тому моменту когда Ларри решил, что можно срубить с неё через Java многа многаааа, МНОГАААА денег.
Разумеется все разработки были тут же свёрнуты.
Понимаете, JVM же не ставится вместе с браузером. И она большая, даже по нынешним временам. А уж 20 лет назад — и подавно была.И, тем не менее, она ставилась вместе с самыми первыми версиями Netscape. Только вот уж очень сначала Sun, а потом Oracle хотели денег получить. Потому вместо полноценной интеграции и были придуманы апплеты и NPAPI.
Вот если кого стоило бы поругать — так это хозяев Adobe. Которые по сути убивают Flash уже много лет, своими руками. Им даже помошники не особо нужны в этом.Ну тут скорее Стива благодарить нужно. После его демарша закат, фактически, начался…
Не, Стива-то как раз можно понять, хоть как-то. Мне не нравится, что такие решения принимаются из маркетинговых по сути соображений, но он — конкурент. Ему плевать на Adobe, если они не приносят денег — ну и хрен с ними.
А тут компания сама делает все, чтобы убить свой же продукт, который сначала купила… Вот это я не пойму.
Вы же не генерируете для JS особый код на ассемблере для вызова процедур с возвратом, который покладёт на стек соответствующий адрес, а потом заберёт его назад? Не запускаете линкеры, которые соединят вам два модуля и пропишут настоящие адреса глобальных переменных?
Генерируем, к сожалению. Emscripten/asm.js/WebAssembly.
Филологическое отступление.
Правила русского языка говорят нам, что имена собственные не перводятся, поэтому какой-нибудь Jackob Jason Jupiter по-русски правильно будет назваеться Джекобом Джейсоном Джупитер, а не Якобом Ясоновичом Юпитером. То же касается и Java/JavaScript. Да и .js все же удобнее звать джей-эс. Однако язык не стоит на месте и подозреваю, что правильным произношением на русском будут уже оба варианта — в качестве консенсуса: разработчикам часто приходится использовать английские слова и аббревиатуры в своих сферах и для того чтобы иметь возможность обратную устную связь приходится поддерживать несколько вариаций произношения одного и того же слова.
P.S. Известная Studio Ghibli, ранее при переводах озвучивалась как Студия Гибли. Вполне корректно, учитывая итальянско-арабско-ливийское происхождение названия. Однако же Миядзаки назвал свою компанию ジブリ и на русском оно должно называться Дзибли согласно поливановской транскрипции, поэтому некоторые русские озвучки были скорректированы под это название. Но моя душонка не приемлет такого изуверства, поэтому продолжаю при случае называть ее на итальянский манер.
Топологические названия вообще не очень из английского заимствуются да и вообще имеют особое отношения с заимствованиями. Например, у нас Румыния, а не Романия (Romania) и Кёльн, а не Колон (Cologne). Это два.
Самоназвания часто просто игнорируются, причем в обе стороны — вы для них я буду рашн фром Раша, а не русский из России.
Скорее всего вы сможете найти еще несколько исключений, где будут кальки/портмоне-слова/синтаксические переносы не попадающие под основные правила русского языка. Исключения найдутся везде.
Да и «Мао Цзэдун» у нас пишется без тонов.
Парадный портрет автора, заодно иллюстрирующий идею современной веб-разработкиОтлично! В лучших традициях конца прошлого века. Ностальгия! Оч. понравилось. Теперь о том, что не совсем понравилось:
Неужели отображение данных на экране для просмотра и редактирования — такая неслыханная и невиданная задача, что никто не знает, с какой стороны к ней даже подступиться? Я вас умоляю. Она решалась столько раз, что даже просто перечислить — заболит палец, жмущий на клавишу «запятая». Так, навскидку, то, о чем я слышал: терминалы IBM 3270, Смоллтолк, экранный Постскрипт, WinAPI, TurboVision, VisualBasic, dBase, Tcl/Tk, XUL, Rebol/View, XAML.
Зачем валить в одну кучу как минимум два решения с противоположными целями? — Так будет еще меньше ясности. Постскрипт и т.д. (еще TeX забыли упомянуть!) своей целью имеет точное 1 в 1 воспроизведение верстки на любом устройстве — будь то стационарный дисплей, принтер или eBook или телефон. У HTML противоположная цель — переформатировать контент в зависимости от устройства вывода наиболее удобным для чтения образом. В первом случае задача решаема и решение найдено, нпр., pdf-формат. А во втором — задача в общем случае неразрешима, поэтому все попытки правильного отображения элементов оформления работают в не очень широких пределах. Чем больше таких элементов оформления и чем они сложнее — тем хуже они воспроизводятся на всем зоопарке возможных устройств. Это закон природы, и ничего тут не поделать. Поэтому чем проще веб-документ — тем лучше. Однако многие веб-дизайнеры не страдают отсутствием аппетита и так хотят кушать, что очень часто пытаются ухудшить уже сделанное. Т.о. ИМХО проблема даже не в вебе, а в недоедании дизайнеров.
en.wikipedia.org/wiki/Display_PostScript
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. И что это меняет в моих словах?
Остров этот по-русски называется Ява, а не Джава, соответственно, кофе на нём яванский, а языки именуются, следовательно, Ява и Яваскрипт
А где в русском есть слово script? Так и пишите — Яваносценарий.
Недавно вышла статья Using a React 16 Portal to do something cool. Что же такое «something cool» в понимании современного веба? Это когда два [зал затаил дыхание] браузерных окошка [барабанная дробь] принадлежат одному react-приложению! Whole New Thing, киллер-фича, инновации и нанотехнологии, блеск и нищета. Посмотрите как просто это делается.
Это всё похоже на какой-то чудовищный культ карго. Хватит делать кнопки, выпадающие списки и лагающие датагриды из дивов и палок. Нужно просто (ок, не просто) засунуть Qt/GTK/Wx в браузер и миллионы людей, пишущих скучные безликие приложения для далёких от IT розовощёких директоров, которым кто-то поездил по ушам и сказал «десктоп — прошлый век, веб — круто», вздохнут с облегчением.
Вот jQuery как раз-таки жизнеспособна. А почему она "выстрелила"? Да потому что убрала "лишнюю" сложность. Было два способа получить список DOM-узлов:
в JS — document.getElement[s]*
в CSS — селекторы.
jQuery принесла в JS возможность работы с селекторами. И, по моему скромному разумению, она ещё долго протянет :)
Привет из мезозоя