Впервые значимое число веб-разработчиков открыто ставят под сомнение веб-платформу. Вот характерная статья и обсуждение. Вот другая статья. И ещё одна. Я бы мог перечислить и больше, но если вы достаточно интересуетесь программированием, чтобы читать эту статью, то наверняка уже читали в этом году хотя бы одну напыщенную декламацию о современном состоянии веб-разработки. Эта статья не из таких. Я не могу соревноваться в издевательствах над существующим статусом-кво с людьми, которым приходится заниматься веб-разработкой каждый день. Это другая статья.
Это ты, хакер фронтенда
Я хочу поразмышлять о том, можно ли создать настолько хорошего конкурента вебу, что он в итоге заменит его и включит в себя, по крайней мере, для написания приложений. У веба есть ещё проблемы как у системы распространения документов, но не настолько серьёзные, чтобы о них беспокоиться.
Это первая из двух статей. В первой части рассмотрим глубокие, неразрешимые проблемы веб-платформы: я хочу убедить вас, что отказ от неё является единственным вариантом. В конце концов, невозможно решить проблему, если сначала не подвергнуть её анализу. Также кратко рассмотрим, почему сейчас стало политически приемлемо обсуждать такие вопросы, хотя они не являются чем-то новым.
Во второй части я предложу новую платформу для приложений, которую способна создать небольшая группа разработчиков за разумное время, и которая (IMHO) должна быть гораздо лучше, чем то, что мы имеем сейчас. Конечно, не все согласятся с последним. Согласиться с проблемами всегда проще, чем согласиться с решениями.
Часть 1. Поехали.
Почему веб должен умереть
Веб-приложения. На что они похожи, а? Я могу перечислить кучу их проблем, но давайте остановимся на двух.
- Веб-разработка медленно повторяет 1990-е годы.
- Веб-приложения невозможно защитить.
Вот хороший пост по Flux, последнему модному веб-фреймворку от Facebook. Автор обращает внимание, что Flux воссоздаёт модель программирования, которую использовала Windows 1.0, выпущенная в 1985 году. Microsoft использовала эту модель, потому что она подходила для медленных компьютеров, но под неё было настолько неудобно программировать, так что не прошло и десятилетия, как выросла целая экосистема продуктов (вроде OWL), позволяющих абстрагироваться над лежащей в основе системой сообщений WndProc.
Одна из причин, почему React/Flux работают таким образом — очень медленные движки веб-рендеринга. Это правда, и конечный видимый пользователю результат лишь немного более замысловатый, чем пользователь Windows мог видеть 20 лет назад:
Windows 98
Конечно, разрешение экрана стало больше. Изменились оттенки серого, которые нам нравятся. Но UI, который вы видите вверху, по сложности довольно похож на UI, который вы видите внизу:
Даже мода на иконки не изменилась! Windows 98 представила новый тренд плоских иконок в оттенках серого, в то время как предыдущие были цветными, плотно упакованными пиксельными изображениями.
Но Office 2000 вполне довольствовался CPU на 75 МГц и 32 МБ памяти, в то время как Google Docs со скриншота использует CPU на 2,5 ГГц и почти в десять раз больше памяти.
Если бы мы получили десятикратный прирост в производительности и функциональности, это было бы простительно, но мы его не получили. Платформы разработки в 1995 году по умолчанию обладали всем нижеперечисленным, только для начала:
- Визуальный редактор UI с ограничениями макета и привязкой данных.
- Продвинутая поддержка программных компонентов на многих языках. Вы могли смешивать статически типизированный нативный код и языки сценариев.
- Выпускаемые исполняемые файлы были настолько эффективны, что работали на нескольких мегабайтах RAM.
- Поддержка построения графиков, тематизации, 3D-графики, программирования сокетов, интерактивной отладки…
Многие из этих функций появились на веб-платформе только в последние несколько лет, и часто весьма поверхностно. Веб-приложения не могут использовать реальные сокеты, так что вместо этого серверы приходится переводить на поддержку «веб-сокетов». Такие базовые вещи как компоненты UI — это тихий ужас. Не существует серьёзной Web IDE, а насчёт смешивания разных языков программирования… ну, вы можете попытаться всё скомпилировать в JavaScript. Иногда.
Разработчики любят писать веб-приложения по одной причине — ожидания пользователей от таких приложений исключительно низки. От приложений для Windows 95 вы ожидаете наличия пиктограмм, перетягивания мышкой, отмены произведённых действий, ассоциаций с расширениями файлов, нормальных сочетаний «горячих клавиш», полезной деятельности в фоновом режиме… и даже работы в офлайне! Но это самые простые приложения. По настоящему крутой софт мог встраиваться в документы Office или расширять функциональность Explorer, или допускать расширение функциональности произвольными плагинами, которые изначально неизвестны автору программы. Веб-приложения обычно не делают ничего подобного.
Всё это накапливается. Я чувствую себя гораздо продуктивнее, когда пишу десктопную программу (даже с учётом разных «налогов», которые вам придётся платить, вроде изготовления пиктограмм для своих типов файлов). Использовать я тоже предпочитаю их. И из разговоров с другими знаю, что я не один такой.
Думаю, что веб стал таким, потому что HTML вышел с вполне вразумительной философией дизайна и инструментарием как платформа для документов, но в качестве платформы для приложений HTML пришлось закреплять на соплях, и ничего хорошего до сих пор не получилось. Поэтому не существует самых базовых вещей вроде ассоциаций файлов. Зато в HTML5 имеется пиринговый видеостриминг, потому что Google хотела сделать Hangouts, ну а приоритеты Google — это главное в том, какие функции добавлять в стандарт. Чтобы избежать такой проблемы, нам нужна платформа, которая изначально спроектирована с мыслью о приложениях, а затем, может быть, добавить сверху ещё и документы, а не наоборот.
Веб-приложения невозможно защитить
В конце 1990-х ужасная реализация ЯП нависла над программной индустрией: уязвимости безопасности в программах C/C++ перестали быть редкими ошибками, которые можно исправить по отдельности. Они появились повсюду. Люди стали понимать, что если код C/C++ выставить в интернет, неизбежно появятся эксплоиты.
Можно оценить невинность того мира, если почитать отчёт SANS по сетевому червю Code Red от 2001 года:
«Представители Microsoft и агентств безопасности США провели пресс-конференцию, где инструктировали пользователей скачать патч с сайта Microsoft и назвали „гражданским долгом” скачивание этого патча. CNN и другие новостные издания после распространения Code Red предупредили пользователей о необходимости установить патчи на свои системы».
В Windows существовали автоматические обновления, но если я правильно помню, отключенные по умолчанию. Идея, что программа может изменяться без ведома пользователя, была эдаким табу.
Первые признаки заражения Blaster
Постепенно индустрия начала меняться, но с криками и протестами. В то время пользователи Linux и Mac частенько говорили, что это вообще чисто проблема Microsoft… а их системы созданы некими сверхпрограммистами. Так что в то время как Microsoft приняла факт, что столкнулась с экзистенциальным кризисом и ввела «жизненный цикл безопасной разработки» (гигантская программа переобучения и новый процесс), её конкуренты практически бездействовали. Редмонд добавил файрвол в Windows XP и выпустил сертификаты для подписи кода. Мобильный код запретили. Когда стало ясно, что уязвимости в безопасности идут бесконечным потоком, ввели периодический выпуск патчей “Patch Tuesday”. Умные хакеры продолжали делать открытия, как эксплуатировать известные ранее баги, которые казались безопасными, и как обходить защиты от эксплоитов, ранее казавшиеся надёжными. Сообщества Mac и Linux начали постепенно выходить из спячки и осознавать факт, что они не являются волшебным образом защищёнными от вирусов и эксплоитов.
Последним поворотным моментом стал 2008 год, когда Google выпустила Chrome, важный проект с той точки зрения, что они потратили массу усилий на создание сложной, но совершенно незаметной песочницы для движка рендеринга. Другими словами, лучшие в индустрии разработчики признали, что они не способны написать безопасный код C++ независимо от того, как упорно будут над ним работать. Такой тезис и изолированная архитектура стали стандартами де-факто.
Пришла очередь веб-платформы
К сожалению, веб не вывел нас на благословенную землю безопасных приложений. Хотя веб-приложения в каком-то роде изолированы от материнской ОС, и это хорошо, но сами приложения вряд ли более надёжны, чем код Windows от 2001 года. Вместо того, чтобы навсегда избавиться от доставшихся по наследству проблем, веб просто заменил один тип переполнения буфера другим. В десктопных приложениях эксплуатировались уязвимости типа двойного освобождения одной и той же памяти (double free), уязвимости целостности стека (stack smash), использования памяти после освобождения (use after free) и прочие. Веб-приложения исправили их, но представили собственные такие же ошибки: инъекции SQL, XSS, XSRF, инъекции заголовков, смешение типов MIME и так далее.
Всё это ведёт к простому тезису:
Невозможно написать безопасное веб-приложение.
Не будем педантами. Я не говорю буквально обо всех веб-приложениях. Да, можно написать безопасный HTML Hello World, флаг в руки.
Я говорю о реальных веб-приложениях пристойного размера, написанных в реалистичных условиях, и это заявление далось нелегко. Понимание пришло ко мне после восьми лет работы в Google. Там я наблюдал, как самые лучшие и талантливые веб-разработчики снова и снова выдают код с эксплуатируемыми багами.
Отдел безопасности Google — один из лучших в мире, может и лучший, и для внутренней учебной программы они выпустили это полезное руководство с перечислением самых популярных ошибок веб-разработки. Вот их совет, как безопасно отправлять данные для отображения в браузере:
Для исправления вы можете сделать несколько изменений. Любое из этих изменений предотвратит ныне возможные атаки, но если добавить несколько уровней защиты («глубокая защита»), вы защититесь от того, что какой-то из уровней не сработает в случае уязвимостей в браузере, которые найдут в будущем. Во-первых, используйте токен XSRF, как обсуждалось ранее, это гарантирует, что результаты JSON с конфиденциальными данными возвращаются только для ваших страниц. Во-вторых, ваши страницы ответа JSON должны поддерживать только запросыPOST, чтобы предотвратить загрузку скрипта через тег <script>. В-третьих, следует убедиться, что скрипт неисполняемый. Стандартный способ сделать это — добавить к нему какой-нибудь неисполняемый префикс, вроде])}while(1);</x>. Работающий в том же домене скрипт способен прочитать содержимое ответа и избавиться от префикса, но скрипты из других доменов не могут.
ПРИМЕЧАНИЕ: Сделать скрипты неисполняемыми не так просто. Возможно, исполняемость скриптов изменится в будущем, с появлением новых скриптовых функций и языков. Некоторые полагают, что можно защитить скрипт, превратив его в комментарий, то есть поместив в/*и*/, но всё не так просто. (Подсказка: что, если кто-то использует*/в одном из своих сниппетов?)
Чтение такой забавной охоты на ведьм и фольклора всегда вызывает у меня улыбку. Это должно быть шуткой, но в реальности здесь базовые вещи, которые обязан знать каждый веб-разработчик в Google, просто чтобы вывести какую-то информацию на экран.
На самом деле вы можете сделать всё вышеперечисленное, но этого будет недостаточно. Атака HEIST позволяет украсть данные из веб-приложения, которое безошибочно реализовало все меры защиты. Она эксплуатирует неустранимые изъяны архитектуры в самой веб-платформе. Конец игры.
Не совсем! Всё ещё хуже! Защита оконечных точек REST/JSON — только одна из разнообразных проблем безопасности, которые должен понимать современный веб-разработчик. Имеются десятки других (вот интересный пример и ещё один прикольный).
По опыту могу сказать, что невозможно нанять веб-разработчика, который хотя бы слышал обо всех этих подводных камнях, не говоря уже о разработчике, который способен от них защититься. Вот мой вывод: если вы не можете найти веб-разработчика, который понимает, как писать безопасные веб-приложения, то написать безопасное веб-приложение невозможно.
Ключевая проблема
Практически все проблемы безопасности в вебе объясняются несколькими ключевыми проблемами архитектуры:
- Буферы, не соответствующие своему размеру
- Протоколы, разработанные для документов, а не для приложений
- Правило ограничения домена (same origin policy)
Потеря контроля над размером буферов — классический источник уязвимостей в программах C, а в вебе возникла в точности такая же проблема: все инъекции XSS и SQL основаны на создании путаницы насчёт того, где начинается буфер для кода и заканчивается буфер для данных. Веб крайне зависим от текстовых протоколов и форматов, так что приходится неизменно парсить буферы, чтобы определить их размер. Это открывает целую вселенную проблем с экранированием (escaping), заменой и прочими вещами, которые совсем необязательны.
Исправление: Размер всех буферов должен иметь метку числом: от базы данных до сервера фронтенда и интерфейс пользователя. Не должна возникать необходимость что-то сканировать в поиске волшебных символов и смотреть, где они заканчиваются. Обратите внимание, что для этого требуются бинарные протоколы, форматы и логика UI по всему стеку.
HTTP и HTML спроектированы для документов. Даже Егор Хомаков сумел сломать двухфакторную аутентификацию Authy, просто набрав “../sms” в поле ввода кода SMS. Ему это удалось, потому что подобно всем веб-сервисам Authy создана на стеке для гипертекста, а не программного обеспечения. Обход каталога имеет смысл, если вы реально имеете доступ к директориям с файлами HTML, как и задумал сэр Тим. Если же вы представляете программный API как «документы», то обход директории может стать фатальным.
REST был достаточно ужасен уже тогда, когда возвращал XML, но в наше время XML вышел из моды и теперь веб использует JSON — формат, настолько плохо спроектированный, что у них в вики целый раздел посвящён проблемам безопасности.
Исправление: Прекратим притворяться, что REST — хорошая идея. REST — это плохая идея, которая перекручивает HTTP в то, чем он не является, только чтобы обойти ограничения браузера. Это ещё один инструмент, который перекрутили в то, чем он не должен быть изначально. Такое всегда плачевно заканчивается. Учитывая предыдущий пункт, клиент-серверные коммуникации должны использовать бинарный протокол, спроектированный специально для RPC.
Правило ограничения домена для веб-разработчика — ещё один опыт из книги Стивена Кинга. Цитата из вики:
Способы проверки на ограничение домена и соответствующие механизмы не очень ясно определены для ряда пограничных случаев… исторически это вызывало немалое число уязвимостей в безопасности.
Вдобавок, многие легаси кросс-доменные операции, появившиеся до JavaScript, не подлежат проверкам на ограничение домена.
В конце концов, определённые типы атак, такие как DNS rebinding или серверные прокси, позволяют частично разрушить проверку имени хоста.
SOP (same origin policy) стал результатом того, что Netscape прикрутила программный код к формату для документов. На самом деле это не имеет никакого смысла. Вы бы никогда не создавали платформу для приложений такого вида, если бы у вас было больше 10 дней времени на ввод её в эксплуатацию. Но на самом деле мы не можем их винить, потому что Netscape был стартапом, который работал в условиях острой нехватки времени, и как мы уже отметили выше, в то время вообще никто серьёзно не думал о безопасности. Результат 10-дневного марафона кодирования мог оказаться даже хуже.
Независимо от ваших симпатий, в сердце атаки HEIST лежит именно SOP, а атака HEIST ломает почти все веб-приложения такими способами, от которых, вероятно, никогда нельзя будет защититься, по крайней мере, без отказа от обратной совместимости. Это ещё одна причина, почему невозможно написать безопасное веб-приложение.
Исправление: Приложениям нужна ясная идентичность, и следует прекратить обмен друг с другом токенами безопасности по умолчанию. Если у вас нет разрешения на доступ к серверу, вы не должны иметь возможность отправлять ему сообщения. Это понятно на каждой платформе, кроме веба.
Есть масса других проблем с архитектурой, которые затрудняют создание безопасных веб-приложений, но вышеприведённых примеров, надеюсь, достаточно, чтобы убедить вас.
Заключение
HTML5 — чума нашей индустрии. Хотя он хорошо делает некоторые вещи, эти преимущества легко повторяются на других платформах для веб-приложений, и практически никакие из ключевых проблем архитектуры веба невозможно устранить. Вот почему веб теряется на мобильных устройствах: при сравнении с конкурирующими платформами, которые действительно специально спроектированы, а не выросли естественным путём, разработчики почти всегда выбирают нативный вариант. Но за пределами мобильного мира у нас нет ничего хорошего. Мы отчаянно нуждаемся в способе удобно распространять изолированные, безопасные, автообновляемые приложения для настольных компьютеров и ноутбуков.
Десять лет назад меня бы распяли за написание такой статьи. Ожидаю некоторого ворчания и сейчас, но в последнее время стало социально допустимо критиковать веб. В прошлые времена веб был втянут в соревнование с проприетарными платформами вроде Flash, Shockwave и Java. Веб был открыт, но его выживание в качестве конкурентной платформы вызывало сомнения. Его итоговое возрождение и победа — это история, которая жмёт на все эмоциональные кнопки: открытость лучше, чем закрытость, коллективное владение лучше, чем проприетарный код, Давид победил Голиафа и так далее. У многих программистов выработалась настоящая племенная верность по отношении к нему. Добавление ко всему приставки «веб-» мгновенно делает это модным. Выскажите мнение, что Macromedia Flash хорош — и у вас могут отобрать удостоверение гика.
Но времена изменились. Веб так разжирел, что называть его открытым практически бессмысленно: у вас нет шансов внедрять HTML5, если в кармане отсутствуют несколько миллиардов долларов, которые вы хотите спустить. Консорциум W3C не прислушался к запросам пользователей и теперь стал ненужным, так что если вы не работаете в Google или Microsoft, то не можете как-то влиять на техническое развитие веба. Некоторые из ранее закрытых конкурирующих платформ теперь открылись. А экосистема JavaScript взрывается под весом своего собственного бессмысленного намолота.
Время вернуться назад к чистой доске. А теперь возьмите выпить и прочитайте следующую статью в серии: что последует за вебом?
Комментарии (401)
MonkAlex
28.09.2017 11:55+2Вкусная статья, посмотрим что автор предложит.
staticlab
28.09.2017 12:23Автор предлагает некую платформу с приложениями по типу мобильных, правда крайне сомнительно, что в плане безопасности всё будет намного лучше.
mclander
29.09.2017 10:52+1Автор как всегда предлагает убить то, в чём не разбирается. Достаточно было дочитать про Flux. Flux/redux имеют весьма посредственное отношение к скорости рендеринга. Это методология организации кода. REST api, разрабатывается всегда с предположением, что клиент скомпроментирован. Для жизнено важных приложений используется дмз и другие способы отсечь удаленное управление, что небесполезно и для защиты десктопных прилад. Зато так приятно ощутить, а то и возглавить панику)
Leopotam
29.09.2017 11:45+2Да и http был разработан исходя из модели запрос-ответ, что безо всякого «выворачивания» ложится на REST api.
BeppeGrillo
30.09.2017 18:31Это методология организации кода
Которая воссоздаёт модель программирования, которую использовала Windows 1.0, выпущенная в 1985 году
napa3um
28.09.2017 11:56+10Это не про веб, это про конец времени разработчиков-одиночек (плач, продолжающийся с 80-90хх). Веб-платформу нужно не со стороны иконок рассматривать, а со стороны стандартов, REST, масштабирования, развёртывания, кроссплатформенности. Веб не хорош или плох, это просто данность, закономерный результат развития человеческих технологий, решивших по пути своего становления естественно возникающие задачи. Статья вообще ниочём, если есть предложения — предлагай, если есть вера в конструктивность этих предложений — внедряй и конкурируй с вебом. А не смог — смирись с наивностью своих претензий.
evilruff
28.09.2017 15:46+24Мне кажется Вы несколько недооцениваете про конец-времени и уж тем более плач… каждый то вообщем выбирает для себя формат деятельности, который его радует и позволяет жить с удовольствием… местами статья перегиб, но в целом попытки последних N лет запихать все что можно и нельзя в какие то веб-решения лично у меня вызывают изжогу… Вы путаете «данность» и притягивание за уши всего что вокруг к этой технологической «данности»…
Мне скажем не жалко памяти моего компьютера… как бы сколько надо столько и купим =), я понимаю _почему_ так получается, но мне кажется что-то с «данностью» не так если десктопный Slack под win10 прямо сейчас жрет у меня 523Mb памяти… представляя из себя окно, показывающее одновременно 20-30 текстовых сообщений и при этом с невозможностью посмотреть историю если нет сети, при этом считаясь почти эталоном корпоративного общения…
Проблема даже не столько в вебе, как мне кажется… он ведь по сути дал просто некий инструментарий… проблема в том, что под флагами маркетинга и завоевания всего и вся, этот инструментарий начали использовать для совершенно непригодных вещей…
Вот опять же, глубокое IMHO, банк-клиент ВТБ24 — обычный для «физиков»… 10 лет назад он был легким, быстрым, работал почти на любых каналах… имел нормальные человеческие функции поиска платежа по описанию, по типу, по строчкам в получателе итд… на тот момент это объективно был лучший банк клиент для физ лиц… да и для юриков тоже был не плох… за 10 лет после 4-5 реинкарнаций, первую кстати начала студия Лебедева… он превратился в чуть шевелящегося уродца с невнятным, абсолютно неочевидным интерфейсом, весом в полтонны… зато обзавелся кучей модных свистелко-перделок…
napa3um
28.09.2017 16:56Я понимаю вашу точку зрения, и сам тоже «страдаю» от потери того чувства всемогущества, которое испытывал будучи школьником, сидевшим перед ассемблерным кодом на сферическом мониторе своего 486-го :). Но подобные идеализмы всегда разбиваются о твёрдость физической и экономической реальности, увы :).
evilruff
28.09.2017 19:11+6ну когда я был школьником то больше как-то мне запомнились мк-52, паяльник и синклеры=) 486 уже ближе к концу института… но не в этом дело… я не расцениваю это как «всемогущество», скорее просто лично мой взгляд на высказанное в статье мнение как человека, который последние лет 25 каждый день пишет код ) моя область деятельности далека от веба, хотя в несольких проектах я поучаствовал, поэтому в данном случае я могу позволить себе высказаться просто как пользователь-обыватель… я не пытаюсь разбить голову ни о физические не тем более об экономические реалии, поэтому смело шагаю в магазин за соотвествующим железом, но опять же это не мешает мне иметь точку зрения состоящую в том, что за последние N лет, скажем так — added value для конечного пользователя (меня) в разделе веб продуктов носит очень сомнительный характер, особенно в пропорции к тем ресурсам которые все это добро требует… опять же я не хочу что то агрегировать или делать какие то выводы «за всех», я лишь говорю о том что по сути лично мне не стало удобнее за последние годы читать gmail (если я читаю его в онлайне) или пользоваться своим банк клиентом…
1nd1go
01.10.2017 01:03за последние N лет, скажем так — added value для конечного пользователя (меня) в разделе веб продуктов носит очень сомнительный характер, особенно в пропорции к тем ресурсам которые все это добро требует…
Поддерживаю на все 100!
staticlab
28.09.2017 12:13+6Потеря контроля над размером буферов — классический источник уязвимостей в программах C, а в вебе возникла в точности такая же проблема: все инъекции XSS и SQL основаны на создании путаницы насчёт того, где начинается буфер для кода и заканчивается буфер для данных. Веб крайне зависим от текстовых протоколов и форматов, так что приходится неизменно парсить буферы, чтобы определить их размер. Это открывает целую вселенную проблем с выходом (escaping), заменой и прочими вещами, которые совсем необязательны.
Эмм… Причём тут размеры буферов, если в основе уязвимостей XSS и SQL Injection включение в запрос нативных данных от клиента? Конкатенация на высокоуровневых языках вполне себе корректно выполняется, а вставить в запрос к базе строку из txtClientName без эскейпа можно и на десктопе.
lpre
28.09.2017 14:25+1Имелось в вид, что если вы контроллируете длинну "буферов" (длинну данных, или длинну запроса), никто не может добавить к запросу посторонний код.
staticlab
28.09.2017 14:40+2SELECT * FROM client WHERE name='$client'
Можно подставить "Константиновский Константин Константинович", а можно подставить "1' OR 1=1 --". Как вы собираетесь по длине запроса его валидировать?
Хотя, конечно, конкретно этот запрос в целом бестолковый, но наглядный
lpre
28.09.2017 14:56+3Тем не менее, проблема SQL injection "успешно" возникла в Web, как и buffer overflow в C/C++ за 20 лет до этого. Вот автор и говорит о том, что Web повторяет путь десктопного софта, включая схожие грабли.
Так что хотя SQL injection и победили параметризацией, тесктовый протокол с текстовыми же маркерами начала и конца данных далек от того, чтобы считаться полность безопасным.
staticlab
28.09.2017 15:10В данном случае под текстовым протоколом понимается сам SQL. Вот только полностью заменить его сейчас невозможно. В крайнем случае обернуть (что делают разнообразные ORM, да и рекламируемый автором Permazen).
lpre
28.09.2017 15:20Так SQL и не является частью Web (deprecated WebSQL не в счет).
Автор говорит именно о Web и его протоколах, которые до недавних пор были исключительно тесктовыми, да и сейчас ключевые протоколы остаются таковыми.
Так что он предлагает (во второй чати статьи) заменить текстовые протоколы на бинарные.staticlab
28.09.2017 15:32+4Смотрите, в моём примере уязвимости абсолютно нет ни вебоспецифичных, ни текстово-транспортных деталей. Мы в принципе не знаем по какому протоколу в бэкендный код передавались данные в переменную $client. Значение могло быть передано и с десктопа, и с мобильника, и через браузер любым протоколом. И уязвимость именно в механизме формирования SQL-запроса. Как я уже сказал, здесь либо заменять протокол общения с базой на бинарный, либо делать обёртку поверх SQL.
lpre
28.09.2017 15:46+1Протокол общения backend'а с базой данных здесь вообще ни при чем. Ни с какого боку (подозреваю, они и так бинарные в большинстве DB).
Уязвимость возникла из-за комбинации пагубной практики программистов строить свои SQL запросы конкатенацией с сырыми данными, полученными из браузера, и возможности очень легко подменить данные в HTTP запросе с текстовым протоколом. И если первое можно победить, заставив программистов использовать параметры в SQL, то второе никуда не делось, и еще будет источником новых уязвимостей.
staticlab
28.09.2017 16:00Протокол общения backend'а с базой данных здесь вообще ни при чем. Ни с какого боку (подозреваю, они и так бинарные в большинстве DB).
Сам-то запрос бинарный, но внутри него хакнутая SQL-инструкция.
Уязвимость возникла из-за комбинации пагубной практики программистов строить свои SQL запросы конкатенацией с сырыми данными, полученными из браузера, и возможности очень легко подменить данные в HTTP запросе с текстовым протоколом.
Наивно полагать, что в бинарный протокол нельзя подсунуть свои данные. Да и не в протоколе передачи данных дело. Ему сказано передать такую-то строку из поля ввода, он её и передаёт. Более того, бинарный протокол может передать ту самую "1' OR 1=1 --" как есть, предварив полем с длиной строки, а вот текстовый протокол вполне себе может что-нибудь заэкранировать. Но на стороне сервера значение будет деэкранировано. И на этом этапе уязвимости не будет. Просто такая защита не входит в обязанности протокола передачи. Ему надо передать эти данные как есть, какими бы они ни были. Наоборот, уязвимостью было бы полагаться на одностороннее экранирование на клиентской стороне.
Вот когда эта наша строка придёт в код, реально формирующий SQL-запрос, вот тогда-то уязвимость и появится. Да, это следствие текстовой природы SQL. Но это сейчас общепринятый стандарт работы с реляционными СУБД и другого у нас нет.
второе никуда не делось, и еще будет источником новых уязвимостей.
Здесь можно согласиться, но опять-таки наивно полагать, что бинарные данные сами по себе безопаснее. Там тоже можно скормить парсеру невалидную последовательность байтов, и тоже что-то может пойти не так.
lpre
28.09.2017 16:49+1Сам-то запрос бинарный, но внутри него хакнутая SQL-инструкция.
Неверно. Хакнут был HTTP запрос, а не SQL. В таком случае замена протокола общения сервера с базой на бинарный, либо введение обёртки поверх SQL (как вы предлагали) вообще ничего не даст.
Наивно полагать...
А я и не полагаю наивно ;-)
Автор предлагает не просто бинарный протокол, а еще и типизированный, что автоматически делает невозможным в принципе любые вставки в нетекстовые данные, потому что они фиксированной динны (а в HTTP можно сделать вставки в любые данные, не только текстовые, но и числа, даты и т.д.)
С текстом посложнее, но тоже решаемо. Например, в ряде случаев от текста можно вообще отказаться -> проблема решена полностьб — см. выше. Можно работать с текстом фиксированной длинны. И т.д.
К тому же, основная цель NewWeb (как автор это называет) не в устранении всех возможных уязвимостей на 100% (сам автор считает это невозможным), а в минимизации возможных ошибок, что приведет к уменьшению числа дыр.
Всё это должно делаться стандартными средствами протокола, чтобы не плодить ошибок от кастомных решений.
Бинарность протокола делает ненужным всякие ухищрения с экранированием/эскейпингом, а также существенно облегчает парсинг (особенно если данные типизированы). Это ведет к уменьшению числа потенциальных ошибок и новых дыр.
а вот текстовый протокол вполне себе может что-нибудь заэкранировать. Но на стороне сервера значение будет деэкранировано. И на этом этапе уязвимости не будет.
Вот как раз на это автор указывает как на еще один недостаток современного Web: разные экранирования/эскейпинги и постоянные парсинги текста, причем с обеих сторон. Во-первых, никаким экранированием и эскейпингом вы не сделаете текстовый запрос из Web приложения безопасными с точки зрения injection (разве что вы будете его подписывать, но там уже свои проблемы). Во-вторых, все эти манипуляции являются потенциальным источником ошибок и новых дыр.
Да, это следствие текстовой природы SQL. Но это сейчас общепринятый стандарт работы с реляционными СУБД и другого у нас нет.
Как я уже говорил, SQL injection — просто частный случай. Проблема в самом текстовом протоколе без всяких средств контроля данных.
staticlab
28.09.2017 16:56+1Неверно. Хакнут был HTTP запрос, а не SQL. В таком случае замена протокола общения сервера с базой на бинарный, либо введение обёртки поверх SQL (как вы предлагали) вообще ничего не даст.
Вы неправильно понимаете суть SQL Injection. Она не в проблеме передачи данных.
Бинарность протокола делает ненужным всякие ухищрения с экранированием/эскейпингом, а также существенно облегчает парсинг (особенно если данные типизированы). Это ведет к уменьшению числа потенциальных ошибок и новых дыр.
Экранирование не потребуется, а вот сериализация/десериализация всё равно будут нужны.
lpre
28.09.2017 17:06+1Вы неправильно понимаете суть SQL Injection. Она не в проблеме передачи данных.
Сам хак SQL Injection происходит только на этапе передачи данных, и никак иначе (если мы о Web говорим). Если вы этого не понимаете, то… это вы не понимаете суть SQL Injection ;-)
Например, если вы передаете числовые данные в бинарном виде (т.е. с фиксированной длинной и в строго определенном формате), то SQL Injection невозможен в принципе. Как видите, проблема решена полностью именно выбором способа передачи данных.
сериализация/десериализация всё равно будут нужны.
Конечно. Это должна быть стандартная часть протокола, и будет делаться через стандартный API.
RPG18
28.09.2017 17:10Сам хак SQL Injection происходит только на этапе передачи данных, и никак иначе (если мы о Web говорим).
SQL Injection это всегда отсутствие валидации входных данных
lpre
28.09.2017 17:16+3Да, вы можете валидировать текстовые данные, добавиви в ваш стек еще одно место потенциальных ошибок и дыр. Именно так и делается в современном Web, и именно это критикует автор.
А можно перейти на другой протокол, который в ряде случаев вообще не допускает SQL injection "by design".
staticlab
28.09.2017 17:20А как вы зарегистрируетесь на каком-нибудь Хабре Нового Веба, не введя свой никнейм, почту и пароль?
lpre
28.09.2017 17:29+2Используя SQL с параметрами.
А что в этом такого? :-)
Разве автор статьи призвает отказаться от этого?
Он предлагает уменьшить количество потенциальных дыр, считая избавление от них на 100% невозможным.
RPG18
28.09.2017 17:26добавиви в ваш стек еще одно место потенциальных ошибок и дыр
Без ошибок только тот код, которого нет. Переход на другой протокол, это просто перенос валидации на уровень протокола, а не приложения. Но да же и тут без валидации на уровне приложения никак.
lpre
28.09.2017 17:32Но ведь можно попробовать хотя бы уменьшить количество потенциальных дыр. В этом и состоит предложение автора статьи.
staticlab
28.09.2017 18:00Только предлагается этой ценой замены всего стека технологий, наработанного за последние 30 лет, в том числе и highload, и написание нового. Сомнительно, что этот новый стек быстро избавится от багов.
lpre
29.09.2017 00:05Даже в текущем стеке Web постоянно появляются новые технологии, и никто особо не переживает по поводу небыстрого избавления от багов :-)
staticlab
29.09.2017 06:21Ок, а что мешает уже сейчас использовать Java, TypeScript, Thrift API для контроля типов и бинарного протокола?
lpre
29.09.2017 11:57У среднестатистического пользователя Web-приложения есть только браузер в качестве клиента, который вы не можете контроллировать. Как вы будете доставлять все это (Java, Thrift etc.) к нему в браузер? Особенно если он не хочет ваших плагинов.
Вот автор и "предлагает" сделать новый Web (NewWeb) с улучшенным дизайном для улучшения безопасности и производительности. Чтобы клиенты (e.g. браузеры) "из коробки" поддерживали новые протоколы.
staticlab
29.09.2017 12:07Java на стороне сервера, TypeScript на клиенте, протокол Thrift реализуется и там, и там. Это будет работать уже сейчас.
balexa
29.09.2017 19:15Оно идиотское. Есть очень хороший пример, не помню откуда — детям на велосипед ставят дополнительные колесики сзади, когда они учатся кататься. Автор посчитал сколько травм получают люди падая с велосипедов, и теперь требует ставить на все велосипеды колесики. «Можно хотя бы попробовать уменьшить число потенциальных травм».
noavarice
01.10.2017 20:49Некорректный пример. С его помощью можно выставить любую попытку улучшить что угодно бессмысленной с точки зрения «Можно хотя бы попробовать уменьшить число потенциальных травм»
alsii
04.10.2017 16:46А при чем тут протокол? Исходные данные вводит пользователь. И это будет текст, как ни крути. Мы можем что угодно делать при передаче, придумывать текстовые, бинарные, да хоть квантовые протоколы, но конце нам нужно получить SQL-запрос, содержащий эти данные и передать его в СУБД. А для этого нам нужно будет получить то, что ввел пользователь. И это будет текстовая строка. И если мв не умеем безопасно строить запрос с этой строкой, то никакие ухищрения нам не помогут.
А вообще для SQL injection веб не нужен, от слова совсем. В криво написанном десктопном приложении он может осуществляться ничуть не хуже.
staticlab
28.09.2017 17:15Например, если вы передаете числовые данные в бинарном виде (т.е. с фиксированной длинной и в строго определенном формате), то SQL Injection невозможен в принципе. Как видите, проблема решена полностью именно выбором способа передачи данных.
С подменой числа строкой справится и парсинг JSON на типизированной платформе (Java, .NET). А вот что насчёт подмены строки как в моём примере?
lpre
28.09.2017 17:26JSON — тоже текстовый. Вставка во время транспорта делается также легко, как и в URL простого HTTP GET.
Да, вы можете использовать JSON валидацию — так же как программисты, допустившие SQL injection, могли бы использовать SQL с параметрами. А можете и не использовать, что является дырой.
Автор предлагает NewWeb, в котором накоторые дыры будут закрыты "by design", независимо от того, что вы используете (или не используете) на своем backend'е.
А вот что насчёт подмены строки как в моём примере?
Использовать параметризированный SQL :-)
Еще раз повторю: проблема — в возможности очень легко подменить данные в HTTP запросе с текстовым протоколом. Это будет источником новых уязвимостей.
alsii
04.10.2017 16:49проблема — в возможности очень легко подменить данные в HTTP запросе с текстовым протоколом.
А какое это отношение имеет к SQL injection? Для этой атаки ничего подменять не надо.
michael_vostrikov
29.09.2017 19:10+1Сам хак SQL Injection происходит только на этапе передачи данных, и никак иначе (если мы о Web говорим).
С чего это вдруг? Он происходит после передачи данных, при обработке в приложении.
Например, если вы передаете числовые данные в бинарном виде (т.е. с фиксированной длинной и в строго определенном формате), то SQL Injection невозможен в принципе.
С чего это вдруг? Какая разница, передали мы значение
$clientв виде "OR 1=1\n" или в виде "0x06OR 1=1"?
michael_vostrikov
29.09.2017 19:13и возможности очень легко подменить данные в HTTP запросе с текстовым протоколом
Почему вы решили, что в двоичном протоколе подменить данные сложнее?
Druu
29.09.2017 04:00> Тем не менее, проблема SQL injection «успешно» возникла в Web
Это с чего бы? SQL-инъекции возможны в любом приложении, которое принимает данные от пользователя и подставляет их в запрос. Не важно, десктоп это или веб.
domix32
29.09.2017 11:23Если знать что следующие n байт буффера это текст, а не исполняемый код мы можем просто игнорить эти n байт пока не возникнет желание провернуть какие-нибудь еще манипуляции именно с данными.
k12th
28.09.2017 12:30+9Flux, последнему модному веб-фреймворку от Facebook
В вебе минули геологические эпохи с тех пор, как Flux был последним и модным (не то чтобы пришедшее на замену шибко лучше, но все-таки).
На C++ невозможно написать безопасный код, а виноват, конечно, веб, ну да.
Веб, со всеми его недостатками, с REST-ом, Flux-ом и прочим грузом, по факту оказался самой удобной системой доставки контента и приложений (что, впрочем, трудно разделить, потому что современный контент требует интерактива (привет, комменты на хабре), а приложения работают с контентом (well, duh)).
Как только появится что-то кардинально лучшее, мы все немедленно на него перейдем: разработчики, если они не застряли в ностальгии, как им любовно и прельстиво кодилось в 90-ые под Win3.x, любят вскакивать на hype-train как никто другой. Боюсь, только, что оно будет организовано на примерно тех же принципах: гипертекст и скриптовый язык.
kuraga333
28.09.2017 20:17+1> Как только появится что-то кардинально лучшее
Не «что-то», а «что-то + экосистема». Именно поэтому надеяться на то, что оно само появится… Не стоит?
Я прошел путь от Rails до собственной lightweight библиотеки по типу React, и тут понял… Что HTML и пр. тут просто не нужен… Бери себе C++/Python/Ruby/etc. + xWidgets, замути такую библиотеку и… Ну разве что, еще нужны всякие API для доступа к сенсорам (если нужно). Но экосистемы-то нет, потому, что нет моды, потому, что нет…
А мода на комбайны под названием «браузеры» (заметьте, еще и несколько!) — плохая. Даже с учетом налаженного процесса стандартизации… Это я спустя десяти лет web programming говорю, спустя годы восхищений… Сейчас я понимаю, что даже идея комбайна JVM — возможно, лучше…
Иллюстрация? Восхищения по поводу WebAssembly: взяли ОС, создали браузер со своей «ОС», сделали «стандартный» высокоуровневый ЯП, а WebAssembly — инновация, которой нам не хватало! Ассемблер внутри всего этого.
Но, наверное, во всех других бизнес-моделях была бы куча стандартов (например, API доступа к сенсорам), ну и тоже бы ничего путного не вышло…
Боль.
XXXXPro
30.09.2017 19:41Скриптовый язык — вряд ли: это замена шила на мыло. Скорее наоборот, появится броузер приложений, который будет скачивать архив с исходным кодом, собирать его на клиентской стороне, и запускать как обычное desktop-приложение в контейнере с ограниченными правами. На мой взгляд, лучше всего для таких целей сейчас подходит язык Go в связке либо с Qt, либо xwWidgets.
marenkov
28.09.2017 13:20+3Office 2000 вполне довольствовался CPU на 75 МГц и 32 МБ памяти
А сейчас этого мало даже дня нативного десктопного мессенджера, да и для мобильного тоже. Так что вы правы, html — зло. Хотя, при чем здесь html?
DenimTornado
28.09.2017 13:27Подмена понятий же)
windymindy
28.09.2017 15:26+4Подмена понятий происходит тогда, когда из технологий, основанных на веб-страницах, делают веб-приложения. Backend должен быть ничем иным, как веб-сервисом, а между браузером и сервером должен быть стандартизованный API.
DenimTornado
28.09.2017 15:32А что не так с вэб-приложениями и чем оно отличается от вэб-страницы? Второе ваше предложение вообще не связано с первым, о чём вы??
knstqq
28.09.2017 14:32+2сейчас куча приложений на десктопе внутри html рисует и имеет webkit в зависимостях, в том числе месенджеры. Разумеется, это не целиком веб-приложение, но и не целиком нативное.
marenkov
28.09.2017 15:18В отличии от веба, авторы десктопных приложений вольны выбирать любой вариант форматирования текста. Если кто-то выбрал для этого полноценный html, то это не вина html. Хотя и с его отображения Operа когда-то справлялась на 75 МГц и 32 МБ памяти.
XXXXPro
30.09.2017 19:44На самом деле и сейчас есть броузер dillo, который может показывать Web-страницы с очень небольшими затратами ресурсов. В частности на эту страницу ему потребовалось всего 32 Мб памяти. Только вот JavaScript в нем нет и поддержка CSS неполная.
wert_lex
28.09.2017 16:22+2И ответ на это тоже один — аналогичный функционал для одной платформы на нативных компонентах требует больше времени разработки. Нативные приложения — это здорово. Но между нативное послезавтра и webkit сегодня, ответ, за редким исключением, очевиден.
cubit
28.09.2017 14:15Мир не идеален и решения не могут быть идеальными, всегда будут проблемы, всегда будут те, кто будет пользоваться этим, по крайней мере такая песня будет ещё долго.
ZurgInq
28.09.2017 14:35+7Только не пинайте сильно ногами. Но почти всё то, за что тут ругается веб, решено во Flash…
domix32
29.09.2017 11:26Кроме безопасности
sshikov
29.09.2017 19:25А с ней там плохо по другим причинам.
domix32
29.09.2017 22:44Да все те же упомянутые буферы переполняли. Ну и песочниц так и не сделали. Если отдадут таки флеш в OpenSource, то может найдутся желающие переписать его на Rust.
sshikov
30.09.2017 19:18Ну, если так подходить, то вообще все проблемы безопасности можно считать везде одинаковыми. Тем не менее, некоторых проблем, характерных для экосистемы веб, в Flash никогда не было.
domix32
30.09.2017 19:39Каких, например?
sshikov
30.09.2017 19:51Ну самое очевидное — то что там изначально аналог shadow dom, т.е. один компонент не может что-то сломать в родительском приложении или его стилях. Или в другом компоненте. Т.е. только публичный API, и ничего больше. Такой вещи, как глобальный window, как document.write — вообще никогда не было за ненадобностью. Там нет загрузки скриптов, как таковой — есть загрузка swc, но это совсем другая история.
sshikov
29.09.2017 19:25Чистая правда. Я сейчас после длительного перерыва смотрю на веб-фреймворки, и вижу, что да, shadow dom и кастомные элементы все-таки сделают революцию рано или поздно — но все это уже было в Flash/Flex, причем много лет назад.
Lsh
30.09.2017 14:15Автор об этом и говорил: «Suggesting that Macromedia Flash might actually be good would get your geek card revoked.»
theaklair
28.09.2017 14:53+8Простите, конечно, но мне почти половина всей статьи показалась дичайшим бредом.
zugo
28.09.2017 15:47+19Полностью согласен, т.н. «веб-технологии» — самое мерзкое, что случалось с ИТ-индустрией за всю ее историю: неудобный и многословный язык разметки (зачем надо было придумывать этот велосипед, когда уже существовал хоть тот же TeX?), ущербный язык стилей, в котором до самых последних версий не было даже возможности отцентровать элемент по горизонтали, самый нелогичный скриптовый язык с невероятно идиотской системой типов и убогой стандартной библиотекой (из-за чего развелись миллионы фреймворков-однодневок, пытающихся замазать его убогость), примитивный протокол, работающий только в одну сторону (что допустимо для документов, но немыслимо для приложений), и т.д.
Давно пора заменить все это дно на какой-нибудь «контейнер приложений» вместо браузера, которые распространялись бы в бинарном виде, работали по нормальному «дуплексному» протоколу, а для UI использовался бы нормальный язык разметки, в идеале поддающийся автоматизации (чтобы дизайнеры могли «рисовать» его в редакторе, не заморачиваясь с версткой).RPG18
28.09.2017 16:05-1Давно пора заменить все это дно на какой-нибудь «контейнер приложений» вместо браузера, которые распространялись бы в бинарном виде, работали по нормальному «дуплексному» протоколу
WebAssembly+WebSocket+WebGL? А все остальное вопрос фреймворков.
staticlab
28.09.2017 16:37А все остальное вопрос фреймворков.
То есть заменяем язык с убогой стандартной библиотекой на платформу вообще без стандартной библиотеки, и разводим поверх неё "миллионы фреймворков-однодневок"?
RPG18
28.09.2017 16:46на платформу вообще без стандартной библиотеки
С чего это вы взяли? Можно хоть существующие фреймворки на других языках прикрутить
staticlab
28.09.2017 17:00+2И каждое такое приложение будет тянуть за собой Qt, .NET, Java Standard Library, Unity? Чем тогда та же пара мегабайт Ангуляра не устраивает?
Virviil
29.09.2017 00:16+1Зачем Использовать WebAssembly, WebSocket и WebGL, есл можно использовать Assembly, Socket и GL, чуть-чуть поменяв популяпные ОСи и добавив полслоя абстракции?
RPG18
29.09.2017 00:36Потому что клиенты платят деньги и хотят все запускать из браузера.
Virviil
29.09.2017 11:22+6Клиенты хотят запускать всё не из браузера, а из унифицированной платформы, которая на сегодняшний день имеет только одну реализацию — браузер.
Если бы существовала другая реализация унифицированной платформы, причём более быстрая (то есть использовала Sockets, Assembly и GL без приставки Web), то про браузер бы никто не вспоминал.
Об этой другой, воображаемой и желаемой реализации и ведёт речь автор этой статьи.
snuk182
29.09.2017 13:15-1Virviil
29.09.2017 14:15Я бы не назвал Java платформой. Хотя, я конечно имею посредственное представление обо всех её возможностях, но это скорее ВМ в моём видении. Браузер унифицирует большее количество вещей, чем ВМ.
Вот Android SDK уже можно назвать такой платформой. Потому что унифицируется доступ к ресурсам ОС, файловой системе, взаимодействию между приложениям, забавушкам.
Вот только она не унифицирована :)
Если слить вместе Android, iOS и .NET стек (а не кросскомпилировать как в Xamarin), унифицировать его, плюс убрать слой абстракции между ОС и ВМ, которая несёт эти приложения — т.е. так, как сделано в мобилках и так как не сделано в десктопах — HTML+JS утонет в Лете.
Flash по сути не решает проблему из-за проприетарности и ограничений. Помоему флеш не умеет UDP, не умеет работать с файлами и тыды
Wargamer
29.09.2017 14:23-4Платформа — это то, от чего можно уверенно отталкиваться. Пока что, так называемая, Java Platform имеет ряд минусов:
— Строгая типизация
— Необходимость обработки исключений
— Необходимость установки среды исполнения
— Принудительное ООП
— Управление памятью и системным треем доступно только через платформозависимый JNIizzholtik
29.09.2017 14:46+2Что такое «строгая типизация»?
Если вы имеете в виду статическую типизацию, то я имею место с вами не соглашаться, поскольку типизация динамическая, по большому счёту, создаёт слишком много проблем, не давая взамен ничего, кроме возможности иногда не писать одно «лишнее» слово.
И да, непроверяемые исключения — это рак из той же оперы. Ради того, чтобы не писать некоторые обработчики, люди вынуждены гадать, какие исключения может бросать функция, и не врёт ли javadoc.
balexa
29.09.2017 19:19+1Вы смешали в одну кучу синтаксис джавы как языка, ее семантику, возможности JVM как платформы, проблемы установки на конкретную проприетарную ОС, да еще зачем то сюда системно-зависимый юай приплели.
Из этого складывается ощущение, что вы слабо понимаете, о чем говорите.
vedenin1980
29.09.2017 21:20Платформа — это то, от чего можно уверенно отталкиваться. Пока что, так называемая, Java Platform имеет ряд минусов:
— Строгая типизация
— Необходимость обработки исключений
— Необходимость установки среды исполнения
— Принудительное ООП
— Управление памятью и системным треем доступно только через платформозависимый JNI
Какая-то ерунда, вы про такой язык как Groovy не слышали, который в JVM позволяет писать функциональные скрипты без ООП с динамической типизацией?
>> Строгая типизация — даже в Java можно использовать переменные Object и явное приведение типов везде, вот вам динамическая типизация. На JVM платформе достаточно языков с динамической типизацией.
>> Необходимость обработки исключений — в чем необходимость? В новом JVM языке не используйте проверяемые исключения, оборачивайте все возможные вызовы старых Java методов в непроверяемые исключения на этапе компиляции и не будет такой необходимости.
>> Принудительное ООП — за неиспользование ООП в JVM вас арестовывает Java полиция? Никто не мешает вам даже в Java написать весь код приложения в методе main одного входного класса и использовать только статические функции и переменные без всякого ООП.
В JVM легко может существовать функциональный или процедурный язык без всякого ООП, байт-коду все равно как выполняется в ООП или не ООП.
>> Управление памятью и системным треем доступно только через платформозависимый JNI
Есть много способов низкоуровеневой работы в JVM, вплоть до подключения C/C++/машинных кодов и вручную обращения к api ОС. JNI это лишь один из них.
>> Необходимость установки среды исполнения — а вот тут не понял, что это значит? Необходимость наличия на устройстве JRE в принципе? Но странно если платформа могла работать без платформы. Или вы предлагаете в каждому приложение тащить весь JRE (сотни мегабайт) с собой? Есть возможности компилировать Java байт сразу в машинные коды и тащить все с собой, но ими мало кто пользуется.
В общем, странные у вас представления о Java платформе.
snuk182
29.09.2017 16:04Да, согласен, Андроид больше подходит под замену браузеру. У него есть очень жирный плюс в виде стандартной интерфейсной библиотеки, которой достаточно удобно пользоваться, как накидывая контролы редактором, так и в коде. А поскольку интернет у нас — про
порнокотятвизуальные интерфейсы, удобный и гибкий способ графического отображения информации играет решающую роль.balexa
29.09.2017 19:30Наверное именно поэтому немалая часть приложений под андроид — это обертки над браузером, заточенные под конкретный сайт. А-ля фейсбуковское приложение несколько лет назад, сейчас без понятия что там.
snuk182
29.09.2017 21:27Нет, не поэтому. Браузер это браузер, где CSS, верстка, интерпретатор JS и прочие ужасы, и к построению приложений таким образом прибегают только в случае совсем уж примитивных приложений, либо с надеждой написать один раз для всех платформ, что очень быстро упирается в потолок производительности. В нативных же приложениях — байткод, существенно более быстрый и безопасный.
balexa
01.10.2017 23:38Для большинства приложений производительность не нужна. Вот честно, для 95% приложений единственная задача это отрисовать информацию из базы. Приложений, требующих производительности на андроиде то и нет почти, если не считать игр.
userphp1024
29.09.2017 17:47+1Эту платформу все равно нужно будет устанавливать на телефон, комп.
т.е. это будет некое приложение. ладно представим что оно будет вмонтировано в операционные системы, т.е. как браузер по умолчанию.
Что делать с гуглом, как он теперь будет анализировать приложения, нажатия, переходы? мы не имеем DOM, мы имеем байткод, т.е. черный ящик.
Создавать разметку? тогда мы вернемся к созданию браузера.
google врядли будет создавать технологию которая убьет их основной бизнес.
А как уже сказали выше, кроме гугла и майкрасофта это никто не сделает
andreymal
29.09.2017 18:19Создавать разметку?
Да, создавать разметку. Специально для поисковиков.
Вообще, её даже создавать не надо, такая разметка уже есть, и она как раз изобретена поисковиками для поисковиков — schema.org. Просто берём её готовую и не паримся.
sumanai
29.09.2017 21:46Просто берём её готовую и не паримся.
Она прибита к HTML. Возможно, её можно применить к похожим языкам разметки документов. Но она никак не приспособлена для приложений.andreymal
29.09.2017 21:51Она прибита к HTML.
Нет, microdata в HTML — это лишь один из вариантов представления schema.org, там же есть и, например, JSON-LD (который к тому же рекомендуется для использования гуглом), не связанный с HTML вообще никак; ну и в любом случае никто не мешает придумать ещё один формат представления по необходимости.
А вообще нахрена индексировать приложения, лол?
userphp1024
29.09.2017 23:04Так идея то не создать облако приложений, а заменить сайты на эти приложения. Заходишь на vasya.ru и тебе генерируется в неком контейнере нечто похожее на сайт.
Если нужно облако приложений то тупо создавайте apple store/google play, точней его аналог и накатывайте туда свои приложения.
что делать с 10000000 сайтами? как вырастить репку, как починить люстру, кулинарные сайты. и т.д.
Нужен поисковик, если делать так как предложили выше(тупо на основе разметки), то вернемся в 2007 год, алгоритмы яндексе и гугла раньше анализировали текст и ссылки (в 2007+ была жесть в выдаче)
userphp1024
29.09.2017 23:23-2Гиблое это дело. Веб устраивает веб программистов.
Веб не устраивает C# / java программистов.
Я часто слышу такое мнение именно от C# C++ Java android программистов, вдумайтесь, люди с другой ниши, переживают за бедненьких веб разработчиков))
Пуканы начали гореть, потому что JS начал лезть в мобильную разработку, серверную, отбирают чужой хлеб негодяи, 5 лет назад никто не жаловался на JS, никому никакого дела не было до того что в вебе все плохо.
Самое забавное вот что: C#/java программисты переживают за душевные страдания веб разработчиков, они искренне недовольны что в вебе все плохо. Переживают за чужой мозг, что бедным веб разработчикам приходится так напрягаться на работе.
Кому не нравится стандартный JS берут что-то вроде react/angular и прикручивают TS/flow
Меня устраивают, если ты хочешь разрабатывать не веб приложения, то тебе вообще закрыта дорога в веб, бери C++ и пиши драйвера, делай мир лучше.userphp1024
29.09.2017 23:29Зайдите в профили к людям которые яро хейтят веб, в 90% случаях это будет Java/ c#/C++ программист.
andreymal
29.09.2017 23:47+15 лет назад никто не жаловался на JS
Я жаловался :D
C#/java программисты переживают за душевные страдания веб разработчиков
Вот вообще плевать на них. Мне не плевать на то, что новый скайп-фор-линукс нормально завести на интел-атоме вообще нереально по причине лютых тормозов и зашкаливающего потребления оперативы. Зато разработчикам скайпа удобно, блджад! Конечно говнокодить удобно, кто ж спорит, только вот на выходе говно и получается.
Кому не нравится стандартный JS берут что-то вроде react/angular и прикручивают TS/flow
Обёртки над обёртками над обёртками над тормозящими HTML-CSS-JS, а в итоге чятики, по своим возможностям едва превосходящие IRC из 1989-го, еле шевелятся на моём относительно новеньком ноуте из 2014-го (да, это камень в Slack).
если ты хочешь разрабатывать не веб приложения, то тебе вообще закрыта дорога в веб, бери C++ и пиши драйвера, делай мир лучше.
Я хочу разрабатывать не-веб приложения. И я, допустим, даже могу их разрабатывать и разработаю. Но это всего лишь я. Всё ещё осаётся две проблемы:
1) Все начинают делать веб-приложения без десктоп-альтернатив — взять хотя бы те же Slack и Skype. Как пользователь я вынужден использовать их тупо по причине отсутствия альтернатив (замену на какой-нибудь XMPP пока опустим, представим производственную необходимость).
2) Продвигать веб-приложения проще и выгоднее, потому что они не требуют установки и браузер уже есть у всех (а для желающих иконку в трее клепается Electron-версия на коленке). Никто не заинтересован в создании нормальных десктоп-приложений, и см. п. 1.
Нужна платформа, которая не содержала бы ничего лишнего (условный один-единственный canvas плюс API для доступа к системе, как я уже ранее упоминал), имела бы эффективно интерпретируемый байткод без костылей (в том же V8 уже работает чуть ли не ИИ, пытаясь скомпилировать наиболее эффективные версии js-функций, хотя всё можно легко порешать тупо статической типизацией) и как следствие не тормозила бы. Варианты, как могла бы выглядеть такая платформа, уже неоднократно предлагались здесь в комментариях, да и в более старых хабрапостах с нытьём про веб.
Мне нужна такая платформа в первую очередь как пользователю, чтоб скайп на линуксе не тормозил.
Кстати насчёт тормозов, есть WebGL-версия UT99 (почти целиком урезанная, чтоб поменьше весила, к сожалению), было бы очень интересно вычислить её минимальные системные требования и сравнить с требованиями оригинального UT99. А потом вспомнить, что в оригинальном UT99 был ещё доступен программный рендеринг без какого-либо ускорения вообще, который к тому же неплохо работал на компах того времени (ну, может, плюс пара лет).
userphp1024
30.09.2017 00:33Вот вообще плевать на них. Мне не плевать на то, что новый скайп-фор-линукс нормально завести на интел-атоме вообще нереально по причине лютых тормозов и зашкаливающего потребления оперативы. Зато разработчикам скайпа удобно, блджад! Конечно говнокодить удобно, кто ж спорит, только вот на выходе говно и получается.
Речь при electron (десктопные приложения написанные на JS)? Соглашусь, это лагучая фигня, не стоит с JS лезть в десктоп, Но это экономит кучу денег работодателю черт возьми))
В скайпе работают не лохи, относительно простых контор, если скайп умудрился написать лагучее приложение, представляю что будет в простых Московских конторках, так что тут я поддерживаю.
Обёртки над обёртками над обёртками над тормозящими HTML-CSS-JS, а в итоге чятики, по своим возможностям едва превосходящие IRC из 1989-го, еле шевелятся на моём относительно новеньком ноуте из 2014-го (да, это камень в Slack).
речь теперь про простые сайты (которые запускаются в браузере)? ( такие как фейсбук, ютуб, хабрахабр, циан, Яндекс карты)
Мне как веб разработчику не вредит обертка, что бы сделать из JS нормальный язык, мне нужно ровно 3 минуты, что бы развернуть всю экоститему, react+ redux + Eslint + flow +…
Из коробки JS — плох, все согласятся.
Без «обертки» рендеринг страницы был 0.1s с обертками стал 0.2 s, разница вообще не ощущается. TS/FLOW удаляется на момент компиляции JS бандла.
Фреймворки есть во всех языках и почем-то хейтят только JS фреймворки. (Мы не собираемся создавать на вебе в браузерах аналог фотошопа(по крайней мере в 2017 :D))
Дальше не стал комментировать, вы там рассуждали про electon, как я уже сказал, что соглашусь что не стоит писать десктопные приложения на JS (по крайней мере в 2017 :D)
sumanai
30.09.2017 02:08Фреймворки есть во всех языках и почем-то хейтят только JS фреймворки.
Разве? Сколько говна не забывают вылить на PHP фреймворки в соответствующих тредах, не замечали? И это я со своей узкой колокольни, а ругают везде и всё.userphp1024
30.09.2017 12:38Про PHP я не видел постов уже год, что там все плохо.
Если они и есть, то от разработчиков других ЯП.
Если не нравится PHP, пишешь на другом языке.
Возьмем C# Entity Framework
Я считаю это полным шлаком, с ним все лагает, криво распознает META Таблиц.
Но ты мне скажешь: он идеален, просто ты не умеешь его готовить и что-то делаешь не так.
C# веб сервисы, кому пришло в голову писать веб сервисы на C#, я видел код этих сервисов и ужаснулся, 2000 строк кода, ради создания простого REST API (куки, сессии, подмена заголовков, CORS)
Это считаю шлаком, зачем они лезут в ВЕБ сервера с своим говном?
ASP.NET такое же дерьмо, сейчас эра SPA, и ваши проекты, которые перезагружают страничку никому не нужны.
Знаешь что я еще видел, я видел C#, PHP, JAVA который генерирует JS код (пишешь на PHP. JAVA, а тебе генерируется JS код на ангуляре)
Какой дурак до такого додумался? Ваш язык не предназначен для современного веба.
zugo
30.09.2017 14:06Во-первых, написать REST-сервис на ASP.NET MVC можно быстрее и качественнее, чем на любом PHP-фреймворке.
Во-вторых, PHP с его умиранием после каждого запроса и отсутствием асинхронности и многопоточности, для написания пресловутых приложений подходит весьма посредственно. А если требуется дуплексный протокол типа WebSocket, то вообще туши свет.
Правда, к сожалению, работодатели очень часто требуют именно PHP — чтоб потом проект можно было поддерживать силами дешевых макак (что, конечно, заблуждение — писать на PHP хорошо куда сложнее, чем на нормальном языке, и почти никто из «PHP only» разработчиков на это не способен).userphp1024
30.09.2017 16:01И тянуть за собой WINDOWS sever?
Вы лезете в веб со своими технологиями, которые не предназначены для этого и еще жалуетесь что веб лезет в десктоп, негодяи, щупальца свои во все области запускают через костыли.
Я видел приложения на IIS+ASP.NET + react, шлак шлаком, куча оберток для JS, куча костылей, господи там даже некоторые генерировали react на коде через C#, а не разделяли на rest + client, и вы что-то про костыли в JS говорите.
Понимаю конечно что это экономия на сотрудниках.
PHP разработчики могут писать хороший код, но для этого нужен не PHP Junior За 60 000 рублей, а PHP Разработчик за 170 000 рублей, если работодатель не готов платить такие деньги, то может ему и качество не нужно? Почему все работодели считают что человек за 60 000 рублей должен быть спецаилистом? это оклад джуниора. и они никак не может быть спецаилистом и он будет, как вы выражаетесь — макакой.
userphp1024
30.09.2017 16:09Это тоже самое, если для ремонта квартиры нанимать не бригаду за 150 000 рублей в месяц, а алкаша, который только только скоречник мастерил, нанять его за 1000 рублей и жаловаться что специалистов почти не осталось, одни неумехи и шарлотаны.
а у нас как получается:
— Нам нужен специалист, но на рынке никого нет, жаль что одни немехи
— Шев может повысим зп, будем искать хотя бы от 120 000 ну и опыт от 7 лет, а не за 30 000?
— ты что? кто он такой что бы я ему столько платил? там же просто кнопки рисовать, открой авито или циан, ну что там сложного? кнопка, кнопка, текст, любой справится, нет ищем за 40 000 максимум! Веб это игрушки, HTML учить 1 неделю, нет, максимум 42000, как найдем начинаем делать свою соц сеть для знакомств(с)
zugo
30.09.2017 20:51И тянуть за собой WINDOWS sever?
.NET Core (существует с 2014 года) прекрасно работает на Linux. Это если не упоминать Mono (неофициальную реализацию, которая еще старше).
Я видел приложения на IIS+ASP.NET + react, шлак шлаком
А уж сколько приложений на PHP, которые «шлак шлаком»… Более того, я абсолютно уверен, что их больше, т.к. уровень среднего PHP-разработчика близок к уровню макаки.
PHP — объективно плохой язык. На нем, конечно, можно писать хорошо, но зачем, если есть нормальные языки?
PHP разработчики могут писать хороший код, но для этого нужен не PHP Junior За 60 000 рублей, а PHP Разработчик за 170 000 рублей
Ну так за 170к можно найти и специалиста по более серьезному стеку, чем PHP. Но «бизнес» не хочет платить 170к, он хочет брать макак с улицы. Это, в том числе, и вина скриптовых языков с низким порогом вхождения — что в принципе возникла такая идея, что программист может быть дешевым.userphp1024
01.10.2017 01:39Макаки есть даже в С++ нише.
Хотите избавится от макак, платите им вместо 60 000 рублей, минимум 140 000 — 200 000 и сразу же найдутся специалисты с 5-10 летним опытом.
(если меня сейчас читают начальники и руководители, HR спецы, поймите, ну нельзя найти специалиста за 60 000 рублей и требовать от него постановки архитектуру на 3 летний проект, сейчас охранник больше получает, минимум 200 000 рублей — и будет вам специалист)
Про стек согласен, если есть деньжатки то можно и стек сменить.
А зачем PHP программисту знать как устроена память, как работать с битностью? это сделает его не макакой и C++ программисты перестанут их опускать?)
Самое главное что ему нужно знать по моему мнению — уметь строить грамотную архитектуру и писать быстрые SQL запросы) ну и чистый код еще)
Считаете ли высокий порог вхождения у Frontend (современный с его 10 обертками и 100 конфигами, кросбраузерность)?
fatronix
03.10.2017 12:59+1сейчас эра SPA, и ваши проекты, которые перезагружают страничку никому не нужны.
Большая часть SPA — лагучее неюзабельное говно, которые убивают уже существующий функционал браузеров, а потом героически их решают своими костылями. SPA — не нужны, SPA не решают никаких проблем для пользователя.Druu
03.10.2017 17:27Они, быть может, не решают _ваши проблемы_. А если бы они не решали проблем пользователя — то их бы никто и не использовал, не-спа сайты просто побеждали бы спа в конкурентной борьбе.
RedCatX
03.10.2017 17:05Меня веб не устраивает не как программиста, а как пользователя. Веб чудовищно жирный и тормознутый, он неэффективно расходует аппаратные ресурсы. Я, как пользователь, не хочу чтобы веб приходил в мобильную разработку, иначе мы увидим приложения уровня «список покупок», которые требуют для работы 8 ядер процессора и 16 Гб оперативки, и при этом сажают батарею за полчаса.
andreymal
29.09.2017 23:24Не понял проблемы. Сайты пусть будут сайтами, приложения пусть будут приложениями, и нечего их смешивать, как это происходит сейчас. В каком-нибудь скайпе индексировать в поиске вообще нечего, кроме самого факта существования скайпа как онлайн-приложения. Для какого-нибудь гуглдока для публичных документов в нём не составит никакой проблемы накатать этот самый JSON-LD. Кулинарные сайты пусть остаются кулинарными сайтами на HTML+CSS, они же не приложения.
userphp1024
29.09.2017 23:47-1Возможно у нас разные понятия просто
Я называю веб-приложением некий масштабный сайт.
Например cian — веб приложения
Яндекс карты — веб приложение
Фейсбук — веб — приложение.
Яндекс Маркет — веб приложение.
Ютуб — веб — приложение.
рецепты ру — сайт
пикабу — сайт/Портал
Вот эти веб приложения, что я перечислил я считаю нужно писать их на JavaScript + css+ html + svg и ничего не нужно менять, нужно расширять эти языки.
Кому не нравится отсутствие типизации, подключают TS или flow
Кого напрягают всякая магия JS, просто не идут в веб разработку и пишут себе драйвера на C++, забудьте про веб разработку если она вам не по душе, вот что я хотел донести.
Люди в посте пишут, что пора прекращать расширять монстра(js css html), нужно убить эти языки и создать что-то новое, предлагают создать аналог браузера, при заходе по ссылке, будет отдаваться не гипертекст, а байткод приложение, которые будет исполняться в этом «браузере»
Это пишут не веб разработчики, это пишут C++ / C# /Java разработчики, которые и CSS то в руках никогда не вертели, не говоря уж о JS(ts)
вы под веб приложениями подразумеваете JS Electron? т.е. когда на JS пытаются писать десктопные приложения?
Тут соглашусь, что не надо такое делать на JS
andreymal
30.09.2017 00:34вы под веб приложениями подразумеваете… когда на JS пытаются писать десктопные приложения?
Да
Коммент получился длинный, запихнул под спойлерНе, масштабный сайт не обязательно приложение. Если собрать сто тыщ мильёнов документов в большую кучу, они не станут волшебным образом приложением :) В моём понимании приложение делает что-то интерактивное и существенное, а просто сайты это коллекции документов и связей между ними, которые нужны по сути только для чтения. Вообще, сейчас так смешались в кучу кони люди, что местами хрен разберёшь, кого кем считать. Предлагаю следующее эмпиричское правило: если нечто можно переписать на HTML+CSS без JS полнофункционально и без лютейшей потери неудобства, то это не приложение.
Тогда:
cian
Не доводилось юзать. Если это «база недвижимости», то на первый взгляд это по сути лишь пара простых формочек для поиска и текст с его результатами. Можно запилить аналог хоть для IE4 без каких-либо скриптов. Не приложение. (Могу ошибаться, ибо не юзал)
Яндекс карты — веб приложение
Вся суть в интерактиве, так что да. И в поиске индексировать нечего, кстати. (Точки интереса можно оформить отдельными документами)
Фейсбук — веб — приложение.
Тоже не юзал, но если считать ВК его клоном и сравнение с ним допустимо, то тоже нет, так как это по сути опять же база документов с парой формочек поиска и редактирования. Мобильная версия ВК способна работать без скриптов. Не приложение.
Яндекс Маркет — веб приложение.
Нет по той же причине, что cion и ВК.
Ютуб — веб — приложение.
Спорно. По идее видео уже выходит за рамки текстового документа, но его, наверно, можно считать дополнением к документу, к тому же в HTML5 есть тег video, работающий без скриптов. Если рассматривать ютуб как базу видеофайлов и комментов к ним, то наверно не приложение. А вот имеющиеся там средства для редактирования видео наверно уже тянут на приложения.
рецепты ру — сайт
А если это рецепты.яндекс.ру с миллиардом рецептов блюд всего мира всех времён, то по вашей логике будет уже приложение? :)
пикабу — сайт/Портал
Ага.
нужно писать их на JavaScript + css+ html + svg
Для всего, что я счёл приложениями, данный стек технологий не подходит вообще. Гугл-карты по-моему сейчас рисуются вообще через WebGL, то есть от HTML и CSS там одно лишь название, а JS используется вынужденно по причине отсутствия альтернатив. На картах нет гипертекста, который можно было бы размечать с помощью HTML. В том же скайпе тоже нет гипертекста, за исключением разве что сообщений в чате, но это не основная фича скайпа. Для групповых видеозвонков не нужны ни HTML, ни CSS.
Вообще, для создания простых сайтов с инфой HTML и CSS умеют слишком много, а JS чаще всего вообще не нужен. А для создания приложений возможностей HTML-CSS-JS всё ещё мало.)
userphp1024
30.09.2017 00:47Просто все по разному называют, для меня веб-приложение это некий сервис (Яндекс метрика или гугл адденс — я считаю это приложениями написанными на JS+html+CSS. кто-то назовет это сайты)
На рынке таких приложений как яндекс карты очень мало.
давайте будет честны, 95% работы (заказы по вебу) это: Сайты визитки, интернет магазины, интерфейсы для оборудования (для роутеров, камер и маршрутизаторов), корпоративные мини CRM (формочки, список сотрудников, парочка графиков), библиотеки данных (авто ру, циан), админки для биллингов(привет мтс билайн итд)
Веб справляется на ура с этими задачами.
под какие задачи вы собрались всю эту кашу заваривать?
Все хотят ускорить веб, сделать его крутым, грубо гоовря, но зачем? Пилить фотошоп и редактор видео в браузере?
Пилите на C++andreymal
30.09.2017 00:5595% работы (заказы по вебу) это:
Против этого я ничего не имею, им HTML самое то. Хотя CRM и админки, наверно, спорно, но против них я не настроен столь негативно, как против каких-нибудь слаков и скайпов (да, я буду ещё стопицот раз упоминать скайп, потому что он и тормоза его веб-клиента — единственная причина, почему моих родителей невозможно сейчас перевести на линукс)
Пилить фотошоп и редактор видео в браузере?
Я-то этого не хочу делать, проблема в том, что другие хотят! Компиляторы из C++ в JS есть уже несколько лет, так что появление полноценного веб-фотошопа — лишь дело времени. А потом десктоп-фотошоп возьмёт да и прекратит своё существование (торренты, конечно, никто не отменял, но пользоваться устаревшим ПО тоже не очень круто). Как прекратил своё существование десктоп-клиент скайпа для линукса (некоторые утверждают, что он ещё работает, но это тоже дело времени)
userphp1024
30.09.2017 12:58Вряд ли в ближайшие 10 лет вообще о таком задумываться будут.
Кстати, веб фотошоп защитит от пиратства.
Покупаешь лицензию, входишь в аккаунт.
Никакие пираты уже не смогут украсть, вряд ли кто-то будет выкладывать на торенте логин пароль, его быстро сменят, если зашел с другого региона то подтверждаешь СМС.
Почему вы не хотите пользоваться фотошопом в веб?
Потому что это не удобно?
Кто запрещает в браузере сделать кнопочку: «Убрать служебные кнопки браузера, сконвертировать вкладку в обычное окно window»
Скорость — да, согласен, но я и говорю, в близжайшие 10 лет о таком даже думать не стоит,
andreymal
30.09.2017 13:37+2Почему вы не хотите пользоваться фотошопом в веб?
Потому что скорость.
в близжайшие 10 лет о таком даже думать не стоит,
В этом-то и проблема! Через десять лет появится условный веб-фотошоп, и, если веб останется примерно таким же что и сейчас, скорость его будет как на компьютерах 2002-го! За эти условные 25 лет процессоры ускорились на десятки гигагерц и десятки ядер, техпроцесс всё нанометровее, оператива начинает измеряться чуть ли не терабайтами — а производительность конечных приложений не меняется! Весь прогресс уходит в обсуживание многочисленных слоёв абстракции, половина которых к тому же не используется. Меня вот это жутко бесит. Тот же стопицот раз упоминавшийся скайп, который когда-то давно успешно работал на компьютерах 2005-го, не способен работать на компьютерах 2010-го из-за того, что он стал веб. Пора убить веб.
Lsh
30.09.2017 14:44+1Почему вы не хотите пользоваться фотошопом в веб?
Зависимость и небезопасность. Отключили интернет — работать не могу. Набежали хакеры на сервера — работать не могу. Устроили конкуренты DDOS — работать не могу. Поменяли интерфейс, он не понравился, а не обновляться уже не получится, буду жрать чего дают. Где мои файлы гиговые, на серверах? Как мне их, условно, в типографию отнести? Как мне их в других приложениях использовать? Порисовал в шопе, экспортировал, скачал импортировал в другое приложение. Понадобилось что-то подкрасить, опять экспортировать, скачать, импортировать?andreymal
30.09.2017 14:50Вот, кстати, хорошая-годная платформа для онлайн-приложений должна позволять эти самые приложения кэшировать для последующей работы в оффлайне. Вроде пару лет назад намечались какие-то веб-стандарты на эту тему (точные названия уже забыл), но потом от всего отказались и всё, что успели нареализовать, выпилили :(
userphp1024
30.09.2017 16:43Проблемы, согласен, но со временем и их решат.
Биткойн кошельки видели? веб версия грузится за 10 секунд через сайт, локальная версия кошелька весит ~200 гб.
Хочешь надежность, качаешь локальную версию кошелька.
Я думаю никто не будет пилить фотошоп чисто на вебе, 100% будет возможность запустить как обычное приложение. веб лишь альтернативаandreymal
30.09.2017 16:46+1100% будет возможность запустить как обычное приложение
… сделанное на базе Electron со всеми вытекающими )
userphp1024
30.09.2017 16:52Electron возможно убогий сейчас, я не запускал новый скайп на электроне, но верю что там все лагает.
Давайте будем честны, 95% задач на рынке разработчиков это проекты для работы с данными: показать формочку сотрудников, получить данные, отправить данные, нарисовать на графике информацию за 1 год. Эти задача не требует высокой производительности. слабое место всегда БД!!!
Понятное дело что если вам нужна какая-то 3D игра, то не стоит ее пилить на react native, и никто и не пилит. Но если вам нужно приложение для заказа Пиццы,(Task менеджер) то react native идеальное решение.
Это очень выгодно работодателям.
Тоже самое и с electron, нужен фотошоп — берите С++
Нужно пара формочек (мини CRM) — берем electron
andreymal
30.09.2017 17:07+2Эти задача не требует высокой производительности.
Это не даёт им право жрать ресурсы как фотошоп. Вообще-то я хочу, чтобы ресурсы использовались для дела этим самым фотошопом, а не какой-то жалкой формочкой :) Если не запускать формочку и фотошоп одновременно, то проблемы нет, но блин, и нахрена тогда нужна многозадачность в ОС?
Нужно пара формочек (мини CRM) — берем electron
То же самое: в результате «мини CRM» не умеет почти ничего, а ресурсов жрёт как тот же фотошоп. Не кажется ли вам это абсурдом?
Кстати, у меня сейчас открыт Adobe Illustrator CC с двумя совсем не маленькими файлами с кучей слоёв, векторов и встроенных растров, занимает это всё в оперативе 300 мегабайт. Нижеупомянутые гуглдоки с простым текстовым документом жрали те же 300 мегабайт. Мессенджер Slack, когда я его юзал, в котором кроме текста, разбавленного редкими картинками, толком ничего и нету, временами кушал памяти раза в полтора больше.
Хочется разбить монитор.
userphp1024
30.09.2017 17:53-1если рассматривать CRM мини.
Ваше приложение на C# хавает 120МБ, мое хавает 350.
Разница прям ощутимая? 21 век на дворе, у всех минимум 8гб оперативки, в игровой индустрии тоже разработчики виноваты, что их игры не запускаются на 4 пеньке?
Ладно, все же это проблема, соглашусь.
Продукт сырой, в будущем косяки с оперативкой продумают, мне так кажется.
Но какие мы имеем плюсы?
— Выгода работодателям в плане денег на разработку под все платформы.
— Визуализация 78 уровня, вы с своим C++ C# все на канвасе будете рисовать пол века, а веб разработчик нарисует за 1 неделю.
— Кросплотформенность, нам не нужны 10 разработчиков, теперь достаточно 3-4
— скорость разработки
Может стоит пожертвовать 20% оперативки ради таких плюсов?
Бизнесу важны деньги, а не красивый код и оперативка.
Сейчас очень мало кто вообще слышал что-то про react native и electron, мало кто понимает что это выгодно для бизнеса, мало кто доверяет этим технология.
Тогда вопрос к вам:
1) Cкайп это технология Microsoft
2) Visual studio code это технология Microsoft
Почему они пишут на JS вместо своего любимого C#?
Wargamer
30.09.2017 18:02Продукт сырой, в будущем косяки с оперативкой продумают, мне так кажется.
У GNU нет такой проблемы, соблюдается принцип KISS (Keep It Simple and Small), благодаря OpenSource не приходится постоянно изобретать велосипед, разделяемые библиотеки помогают экономить память. А если чувствуются тормоза, смотрим что в памяти жрёт больше всех, оставляем столько, на сколько хватает ОЗУ и делаем
# swapoff -a # swapon -a
и нет тормозов
andreymal
30.09.2017 18:16+3Ваше приложение на C# хавает 120МБ, мое хавает 350.
Мое приложение на Rust+GTK3 будет хавать максимум 40МБ :D
Разница прям ощутимая?
Да. В 230МБ можно запихнуть очень много полезного. Например, Adobe Illustrator с двумя тяжёлыми файлами.
в игровой индустрии тоже разработчики виноваты, что их игры не запускаются на 4 пеньке?
У них есть уважительные причины для потребления всех ресурсов компьютера. И, кстати, их до сих пор не хватает: абсолютно реалистичных игр до сих пор как-то не видать. Им простительно.
Но какие мы имеем плюсы?
Всё так. Но того же самого можно добиться, выбрав какую-нибудь платформу полегче. Только такой платформы для онлайн-приложений не существует, и вся суть поста и комментариев к нему — такую платформу нужно создать!
мало кто понимает что это выгодно для бизнеса
Мы все понимаем, что «выгодно для бизнеса» и «выгодно для пользователя» — вещи противоположные. Сейчас всё делается на «выгодно для бизнеса»: бизнес берёт js-макак-первокурсников, которые за еду клепают веб-приложения (можно вместо «веб-приложения» подставить любую другую модную абстракцию), веб-приложения жрут ресурсы и тормозят, пользователи идут покупать новый комп чтоб не тормозило, веб-приложений становится больше, всё снова начинает тормозить, пользователи идут покупать ещё более новый комп, и всё по новому кругу. В результате компы становятся в десятки-сотни раз мощнее, а возможности те же, что и у компьютеров восьмидесятых. Прогресс имеется разве что в играх, думаю потому что там до сих пор старый добрый C++ без лишних абстракций: ещё 10 лет назад о каком-нибудь VR никто и мечтать не мог (жалкие попытки в 90-х вспоминать не стоит), а сейчас вполне годный шлем можно в любой эльдораде купить, и будет неплохо работать. Или в нейросетях, которые, вовсю эксплуатируя GPU, автоматизируют кучу полезных вещей, которые раньше автоматизировать было почти нереально. А теперь сравним какой-нибудь Word 95 и гуглдоки. Какие есть существенные отличия, кроме онлайна? Куда тратятся три сотни мегабайт? Почему оно жрёт три сотни мегабайт, а тормозит и глючит сильнее, чем Word 95 на компах того времени? Почему текстовый документ оказывается тяжелее, чем пара тяжёлых графических файлов в том же иллюстраторе, который у меня до сих пор запущен? Хотя чего это я — потому что «выгодно для бизнеса». А мне как пользователю нихрена не выгодно.
Почему они пишут на JS вместо своего любимого C#?
Потому что, простите, долбоёбы, экономящие на индусах. Я как конечный пользователь буду безмерно рад, если всё перепишут на C#, хоть сам и не очень люблю C#, но лучше уж C#, чем JS.
userphp1024
30.09.2017 19:11-2Ваши 40 мб никому не нужны, это нужно только вам.
Пользователю и бизнесу срать на ваши 40мб.
Это писькомерство среди программистов.
Конечный пользователь этого даже не заметит(опять хочу отметить что речь про приложения малого и среднего бинеса, а не приложения уровня фотошоп)
Я сейчас проверил VS CODE (написан на JS), нацепил на него плагины и загрузил большой проект, оперативки заняло 100мб.
Загрузил этот же проект в WEbstorm — 500мб.
Саблайм — 60мб.
Так что не все так плохо даже сейчас, дальше будет еще лучше.
Веб никак не убить (html+js+css) и ничего не поменять, смиритесь.
Google себя убивать не станет.
Microsoft подстроился под современные тенденции и взял в стек JS.
кто остался? больше никто массово не может повлиять на пользователей.
Единственное что можно сделать, это создать альтернативный веб, но он нафиг никому не нужен, кроме C# программистов, которые переживают за свое рабочее место и будущее.
JS не идеален, но многие проблемы у него уже решены через обертки, фреймворки. установить обертку дело 2 минут, если вы не можете установить обертку, то вы не веб разработчик.
Да… круто было бы без оберток, но лет через 5-7 JS к этому придет думаю и все будет из коробки.
Вебасембли, это тоже не убьет веб, это даст ему очень сильный буст, JS станет еще сильней, а за ним и Node.JS и Electron.
Никто не будет писать ан C# байткод для сайтов и простых веб приложений, напомню 95% проектов рынка не нуждаются в скоростях уровня «фотошоп».
Вебасембли создается для 5% рынка, как раз для тех самый сложных приложений. (карты теперь будут лучше рисоваться у яндекса, видео плееры и еще куча всего сложного)
Веб будет жить еще долго.
andreymal
30.09.2017 19:37Ваш комментарий целиком и полностью верен. Но он никак не противоречит тому, что веб говно. Можно сделать конфетку на js типа VS Code (я установлю его и проверю ваши утверждения про память), можно написать говнокод на сишапре. Однако вы же сами говорите, что «JS не идеален». Он не просто «не идеален» — он ужасен. HTML и CSS также ужасны и до сих пор не решают многих задач, нужных приложениям (весь список проблем прям щас не приведу; но в комментах тут по чуть-чуть уже упоминали). В конце концов все делают один canvas и рисуют на нём, а HTML и CSS лежат без дела и жрут память и процессор, потому что браузер всё равно выполняет какую-то логику для их обработки. Если писать конфетку на веб-технологиях и конфетку на не-веб-технологиях, то в общем случае не-веб будет меньше и шустрее; тот же ваш Sublime это подтверждает (при том что у него плагины на Python, который даже хуже чем JS, лол).
Я уже делал несколько других сравнений веба и не-веба здесь в комментариях, мне неохота повторяться.
Веб будет жить, конечно. Но было бы намного лучше, если бы вместо него жило что-нибудь другое. Но, думаю, каждый комментатор здесь понимает, что этому не бывать и вы правы, так что всё, что остаётся — писать нытьё подобное моему в комментах. Ну и ещё я ярый сторонник, как вы выразились, «писькомерства», да.)userphp1024
30.09.2017 19:53Даже если завтра вместо JS сделают C# и уберут DOM, думаете говно кода убавится в проектах?
Все равно будут нанимать батраков за 50 000 рублей, они так же будут писать говно код (но рабочий), кому нужен хороший код нанимают специалистов за 160 000 рублей условно.
И не забывайте про поисковики, без поисковика нет смысла в интернете и всем обилии сайтов, информации.
Поисковик индексирует и анализирует сайт по тексту и разметке, они шли к этому 10++ лет и сейчас сделали вроде бы нормальные алгоритмы анализа.
Как анализировать сайт который не имеет текста(DOM)? так же как Flash? это отбросит всех на 10 лет назад.
Круто было бы иметь не DOM, а холст где будут элементы меню и прочее добро (Canvas), Но это уже есть и в 2017 году, google свою карту рисует не на DOM а в холсте.
Для сложных задач веб плох (5% рынка)
Для остальных задач — веб хорош)
Кому нужна типизация — подключают TS / flow, там почти все тоже самое что в вашем C#andreymal
30.09.2017 19:56Как анализировать сайт который не имеет текста(DOM)?
JSON-LD, я уже писал про это в комментах. И да, сайту DOM нужен, я ничего против этого не имею. DOM не нужен только приложениям, не стоит меня передёргивать.
google свою карту рисует не на DOM а в холсте.
«… а HTML и CSS лежат без дела и жрут память и процессор» и далее по тексту предыдущего и всех остальных моих комментариев.)
userphp1024
30.09.2017 20:10Это тоже самое что было с Flash сайтами, поисковикам отдельно подкидывали разметку, а тут вы предлагаете прокинуть текст в Json.
На основе текста нельзя провести анализ сайта, мы вернемся в 2000 года, в 2000 годах все обманывали поисковики путем манипуляций с внутренней разметкой, потому что в те времена анализ был только за счет текста и ссылок.
Потому что такие манипуляции больше не работают (по крайне мере в Yandex)
Сейчас я открыл Ctrl+alt+del, у Меня браузер жрет 2 гб.
не так круто, соглашусь, но я сам виноват, у меня открыто 50 вкладок, играет музыка, открыт ютуб)
Хотите сократить оперативку до 30мб? настраиваем в хроме, что бы сайт выгружался из памяти, при активации вкладки он подгружался заново :D
andreymal
30.09.2017 20:13Моё сообщение о том, что против DOM-сайтов я ничего не имею, вы успешно проигнорировали
userphp1024
30.09.2017 20:26Вы имеет что-то против elctron приложений? (таких как Skype и Vs Code, дескоп приложения у которых под капотом JS + Node + Хромиум)
Напомню что в бизнесе 95% задач простых и только 5% сложных. (как правило эти задачи в Google Adobe Yandex и т.д.)
Про 5% — На вебе это делать очень сложно и код будет убогий, отладка говно + куча костылей. Но гигантам некуда деваться и они используют эту технологи.
Они справились и сделали не лагающее приложение.
НО если дать эти технологии в руки джуниору, он сделает приложение которое будет хавать 5гб оперативки
95% — задачи не требуют высокой производительности, веб (JS) там хватает за глаза, не нравится язык? берем фреймворк и статичную типизацию + EsLint и проче едобро. Хотите сделать так что бы приложенеи хавало 40мб оперативки вместо 700мб? Нанимаете разработчика не за 40 000 рублей, а за 130 000 рублей условно. (тут вы согласны?)
andreymal
30.09.2017 20:29На это всё я уже отвечал тут всюду в комментах, чего-то нового мне добавить пока нечего.
userphp1024
30.09.2017 20:31Я просто не понимаю, люди переживают что на вебе убого делать сложные задачи, но блин, эти люди никогда не будут делать эти сложные задачи.
тут почти все работают над CRM, какими-то аналитическими системами, все это не требует производительности, слабое место всегда в расчетах, т.е. в бд и сервере.
Сложные задачи оставим гигантам, и как сделать круто — они сами разберутся, вон взять VSCODE — они сделали круто, у меня ничего не Лагает.andreymal
30.09.2017 20:37Сколь бы правы вы ни были, это никак не изменит того, что новый веб-скайп не идёт у моей мамы на ноутбуке, выпущенном в 2010 году. Я готов отказаться от всех своих слов, если вы дадите тысяч 60 рублей на покупку ей нового ноутбука и ещё тысяч 60 на апгрейд моих собственных железок, чтобы я мог все свои задачи запускать не по очереди :)
RedCatX
03.10.2017 20:02Не знаю, как насчёт Flash, но вот Silverlight, например, очень даже можно анализировать по тексту и разметке, ибо XAML.
XXXXPro
30.09.2017 20:47Вот тут вы не правы: 40 Мб и быстрое время запуска приложений нужно всем тем, кто сел за компьютер до середины 2000х или просто в силу тех или иных причин вынужден сидеть за старым компьютером. Кстати, замечу, что еще в конце 2013 года типовой комплектацией ноутбука среднего ценового класса было всего 4 Гб оперативки, и далеко не все считают нужными менять компьютеры так часто.
В остальном же соглашусь с andreymal: есть информационные сайты, и для них действительно не надо придумывать новый стек технологий, а заставлять людей эффективно использовать уже существующие (т.е. оптимизация картинок, минификация CSS и JS, поддержка HTTP/2 и просто минимализм и отказ от злоупотребления красивостями), а есть именно приложения, где важна интерактивность. И вот для них и нужно создать новое решение, к чему и призывает автор исходной статьи (хотя соглашусь, спорных заявлений у него хватает).
andreymal
30.09.2017 21:01+1Свежеустановленный и свежезапущенный VS Code незамедлительно выкушал около 450МБ оперативы, хотя я не успел ещё сделать вообще ничего.
Кажется, что-то пошло не так.
Кстати, свежезапущенный Chromium выкушивает примерно столько же.
Не свежезапущенный Sublime с открытым проектом и несколькими плагинами кушает примерно 100МБ. По-моему тоже многовато, но не полгига всё-таки)
VovanZ
01.10.2017 13:14Мы все понимаем, что «выгодно для бизнеса» и «выгодно для пользователя» — вещи противоположные.
Это совершенная глупость. Для бизнеса выгодно делать то, что выгодно для пользователей, т. к. именно пользователи платят бизнесу деньги.
andreymal
01.10.2017 13:16Глупость глупостью, только вот тогда почему бизнес этого не делает, лол?)
VovanZ
01.10.2017 14:58Бизнес именно это и делает.
andreymal
01.10.2017 15:44
Предоставим пользователю право выбора, ага.
Безопасность пользователей превыше всего.
Супер выгода — всего $0.99 за одну небольшую настройку!
Можно приводить ещё тысячи и тысячи примеров, как бизнес только и думает, что бы ещё такого сделать ради пользователей. Но мне надоело ещё вчера вести такие бессмысленные разговоры, и я предпочту закрыть тему.
Druu
01.10.2017 16:13-1> Можно приводить ещё тысячи и тысячи примеров, как бизнес только и думает, что бы ещё такого сделать ради пользователей.
А вы не пытайтесь решать за пользователей ;)
Большинство пользователей предпочитает иметь работающее приложение (пусть и медленно работающее, допустим), чем не иметь вообще.
zugo
30.09.2017 20:57Тогда вопрос к вам:
1) Cкайп это технология Microsoft
2) Visual studio code это технология Microsoft
Почему они пишут на JS вместо своего любимого C#?
1) Только linux-версия скайпа на электроне. Виндовая на Qt. Видимо, им по понятным причинам плевать на Linux-юзеров.
2) В VS Code как раз критические части были переписаны на С++, в следствие чего тормозит она в разы меньше, чем изначальный Atom
Ну и да, они на TS пишут, который, хоть и компилируется в JS, но статически типизирован, и создан автором C#.
Wargamer
30.09.2017 07:22Для начала, web — (с англ) это сеть. Сеть подразумевает стек технологий в рамках OSI. Туда входит много, проще сказать что туда не входит или к ней не относится.
Site — (с англ.) место, то что имеет адрес в сети.
Приложение — дополнение чего либо, например операционной системы ПК или мобильника. Приложение может работать через веб, тогда это веб-приложение.
sumanai
30.09.2017 02:05ну и в любом случае никто не мешает придумать ещё один формат представления по необходимости.
Картинка с форматами.
А вообще нахрена индексировать приложения, лол?
Спросите это у гугла, который вводил соответствующие технологии.
Просто сейчас цела куча информации может прятаться исключительно внутри приложений.andreymal
30.09.2017 02:06Просто сейчас цела куча информации может прятаться исключительно внутри приложений.
Можно какой-нибудь пример? Я сходу чё-то ничего не могу припомнить помимо гуглдоков
sumanai
30.09.2017 02:14Я не любитель приложений, и мало где зарегистрирован, поэтому не знаю. Инстаграм подходит или у него инфа дублируется на сайт?
andreymal
30.09.2017 02:17Инстаграм — обыкновеннейший веб-сайт с картиночками, который хрен знает зачем сделали как SPA, так что не. А индексируется он, похоже, тупо через meta-тег description
sumanai
30.09.2017 02:41Тогда не знаю, видимо, зря проверил той статье. Сейчас конкретно её найти не могу, но всплывает куча статей про то, как же круто, что приложения индексируются и как все этого ждали.
andreymal
30.09.2017 02:45Гугл-поисковик выполняет js, и, наверно, «та статья» (или «те статьи») радовалась именно этому. Но, похоже, инстаграм этим не пользуется, в результатах поиска отображается только содержимое meta-тега description. В любом случае это использование технологий не по назначению: сайтам уровня инстаграма js нахрен не нужен.
UPD: Кстати, картинок из инстаграма в поиске гугла нету)
userphp1024
30.09.2017 13:11как это зачем? SPA удобен тем, что мне не нужно жддать перезагрузки страницы, тыкаю кнопку, интерфейс остается на своем месте, подгружаются новые фоточки и меняется структура сайта. без мерцания интерфейса. (если я накходился в центер страницы, мне не нужно заново прокручивать до центра)
Идеология SPA Такая: Для пользователей включаем режим SPA, для поисковиков и тех кто перешел по GET Запросу — грузим слепок DOM с сервера.
Обычное поведение, работают все те же принципы SEOandreymal
30.09.2017 13:42+1SPA удобен тем, что мне не нужно жддать перезагрузки страницы
SPA тут вообще ни разу ни причём и нахрен не нужен. Для этого достаточно прикрутить какой-нибудь PJAX или аналог, который будет аяксом подгружать куски HTML-кода с сервера. При этом с включенным js получаем ускорение без всякого мерцания, а с отключенным js просто отваливается PJAX, а сайт остаётся полностью работоспособным, а не с белым экраном, как у инстаграма сейчас. (Я лично не измерял, но поговаривают, что так получается даже быстрее, чем с «классическими» SPA.)
Идеология SPA Такая: Для пользователей включаем режим SPA, для поисковиков и тех кто перешел по GET Запросу — грузим слепок DOM с сервера.
Ну и зачем так мудрить и оверинжинирить, когда можно сгружать DOM и пользователям тоже? Все мерцания фиксятся PJAX'ом.
userphp1024
30.09.2017 16:30И еще все делать на JQUERY (нафиг нам ваши бабелы, вебпаки, ES6. ES7), так?
Nerlin
01.10.2017 20:52Простите, но в чем тогда принципиальная разница между SPA и не SPA, если все равно прикручиваем AJAX для асинхронного изменения контента, только кашу на сервере и клиенте наводить. Или у Вас каждый день встречаются случаи, когда у пользователя отключен JS?
andreymal
01.10.2017 21:14+1в чем тогда принципиальная разница между SPA и не SPA
SPA-cайт типа Instagram создаёт HTML на клиенте и не работает без JS. Сайт на PJAX/Turbolinks и аналогах создаёт HTML на сервере и успешно работает без JS. Во втором случае JS занимается лишь ускорением сайта AJAX-запросами и ничем больше (в контексте данного обсуждения; пихать дополнительные скрипты никто не запрещает, конечно).
Или у Вас каждый день встречаются случаи, когда у пользователя отключен JS?
Во-первых, лично знаю нескольких таких человек. Во-вторых, я выступаю за то, чтобы абсолютно все сайты могли работать без JS и чтобы абсолютно любой пользователь мог его спокойно отключить.
Nerlin
02.10.2017 12:56Может неправильно выразился, попробую переформулировать. Если есть намек на какую-то динамику на странице, почему бы и не сделать SPA, тем более в век адекватного пререндеринга или вообще возможности создавать изоморфное приложение? Из минусов вижу только Вами представленный случай с отключенным JS, но лично я не знаю насколько этот случай охватывает рынок, чтобы о нем задумываться.
выступаю за то, чтобы абсолютно все сайты могли работать без JS и чтобы абсолютно любой пользователь мог его спокойно отключить.
А зачем? Этот момент мне лично не понятен.andreymal
02.10.2017 13:34+2Если есть намек на какую-то динамику на странице
Я инстаграмом сильно не пользовался, просветите, что там есть такого очень динамичного?
А зачем?
Все избаловались включенными по умолчанию скриптами, а на самом деле вопрос должен стоять по-другому: зачем я должен включать JS? Типичное времяпрепровождение в вебе (не считая веб-приложений) — это чтение статей, текстов и постов, иногда оставление каких-нибудь комментариев (типа этого), гуглинг, копипаст из stackoverflow и всё такое. Всё это умеет HTML без лишних дополнений, зачем для этого JS? Хорошо, JS может служить неплохим дополнением ко всему этому (предпросмотр коммента без обновления страницы, кнопки HTML-редактора над формой, экономия трафика и времени за счёт ajax-подгрузки только новых комментов, тот же PJAX и т.п.), с этими вещами всё понятно, но это всё лишь дополнительные плюшки; зачем делать на JS такие вещи, которые могут работать и без JS?
Nerlin
02.10.2017 14:05Потому что человек не способен предугадать развитие функциональных требований и стоит появиться случаю, когда понадобится более сложное поведение, придется бежать приделывать костыли и палки. Да, не всегда это так, бесспорно, но только ради того, чтобы не включать JS, я не готов строить свою систему с надеждой, что мне он никогда и не понадобится. Лично мне будет проще сразу взять тот же React и быть готовым к любой необходимой динамике в интерфейсе или любым взаимодействиям.
andreymal
02.10.2017 14:24Мне как пользователю какая выгода от того, что вам проще взять React? Я вам сегодня доверился и включил JS ради вашего удобства, а завтра вы подсовываете майнер, а послезавтра собираете fingerprint моего браузера и продаёте меня рекламщикам.
Я бы сидел с отключенным JS, но, к сожалению, ВСЕ сайты его требуют. И альтернатив у веба не существует. Приходится прогибаться под любителей реакта :(
Druu
02.10.2017 14:46-1> Мне как пользователю какая выгода от того, что вам проще взять React?
Та, что вы получите работающее приложение (пусть и с js).andreymal
02.10.2017 14:52+1Напомню, эта ветка про сайты, а не про приложения. В приложениях от исполняемого кода никуда не деться, конечно. А инстаграм — не приложение (то, что его зачем-то сделали SPA, ничего не значит).
А работающий сайт я могу получить и без js. Но я его не получаю, потому что разработчикам лень его таким делать. И это единственная причина, почему все сайты требуют js. То есть мы опять пришли к «выгодно для бизнеса», которое уже обсуждалось в другой ветке.
Druu
02.10.2017 18:19+1> А работающий сайт я могу получить и без js. Но я его не получаю,
Ну почему же можете? Именно что не можете! Чтобы получить работающий сайт — его кто-то должен сделать. Либо у вас есть работающий инстаграмм в виде спа, либо у вас нет работающего инстаграмма, потому что разработчики инстаграмма решили, что не хотят делать его не-спа. При этом вам, конечно, никто не мешает сделать свой инстаграмм, без жс и всего такого. Только вот тогда ваш продукт не сможет конкурировать с продуктами тех разработчиков, которые жс используют свободно, и вы к хренам собачьим вылетите с рынка.andreymal
02.10.2017 19:05+1Вылечу я или нет, от наличия или отсутствия JS никак не зависит. ВК прекрасно работает без JS (кроме аудиозаписей из-за копирастов; а, например, видеозаписи работают). Что-то не похоже, чтобы он куда-то вылетал.
justboris
02.10.2017 19:51Стоит заметить, что без JS работает только мобильная версия. То есть дополнительная версия сайта, написанная специально для маломощных и мобильных устройств, а не основная, на которой сидит большиство.
Не у всех компаний есть возможность потратиться на такую спец.версию.
andreymal
02.10.2017 19:58Ни за что не поверю, что нет возможности потратиться у фейсбука :)
Тем не менее всё равно не вижу никаких серьёзных проблем совмещать JS и не-JS и делать полнофункциональную версию веб-сайта (ещё раз: не онлайн-приложения) в обоих случаях, кроме лени разработчиков. Ну и даже если брать реакт, можно ж было хотя бы server-side рендеринг прикрутить, он это умеет блинjustboris
02.10.2017 20:01+1лени разработчиков
это не лень, а прагматизм. Лучше сделать больше свистелок для привлечения обычных пользователей, чем поддерживать 3,5 человек, заходящих на сайт с калькулятора.
Druu
03.10.2017 03:03+1> Ни за что не поверю, что нет возможности потратиться у фейсбука :)
Очевидно, фейсбук считает что есть более полезные направления, для приложения усилий. Вы рассуждаете с какой-то странной позиции наличия бесконечных ресурсов. Но на практике ресурсы ограничены, и если вы тратите их на то, чтобы ваш сайт работал без js — то вы то забираете у чего-то другого.
Nerlin
02.10.2017 23:28+1Доля рынка таких пользователей настолько мала, что ими сейчас можно пренебречь. Рынок диктует потребитель и пока таких, как Вы, не станет большинство, то смысла изворачиваться разработчикам и нет. Важнее поставлять работающий функционал в более краткие сроки, чем это делают конкуренты, а для этого разработчик будет использовать то, что ему более удобно, будь то React, jQuery или чистый JS с биндингом напрямую к DOM.
Разработчики Instagram решили, что реализуя приложение как SPA, им будет проще его сопровождать, а может им просто нравился тот инструментарий, получать удовольствие от работы тоже важно. Эти простые истины переписать не так легко.
userphp1024
02.10.2017 21:28-1Для вас есть консольные браузеры, пользуетесь ими.
userphp1024
02.10.2017 22:08-1Во-первых, лично знаю нескольких таких человек. Во-вторых, я выступаю за то, чтобы абсолютно все сайты могли работать без JS и чтобы абсолютно любой пользователь мог его спокойно отключить.
Доля бомжей равна 0.00001% на весь мир, «7 одного не ждут.»©
Есть 4 пеньки на многих предприятиях, под них тоже подстраиваться? На них идеально встает Window xp, но на XP не запускается много приблуд.
Есть разумный минимум в 2017 и я вам его опишу.
1) у каждого должен быть мобильный телефон на базе Android / IOs / Window OS ( цена от 10 000 рублей)
2) Компьютер или ноутбук (4гб — 8гб ОЗУ / 500ГБ, core i3-i5) (цена от 15 000 рублей)
Вы можете отказаться от JS хоть сегодня, вам никто не запрещает делать сайты без анимации, без JPG и SVG.
Можно сделать просто в виде текста, это будет грузится за 1 секунду и занимать 1 МБ в оперативной памяти.
Но вы не сможете конкурировать с другими игроками, ваш сайт будет сильно отставать. Я могу предложить пользователю Autocompete с картинкой, а вы просто Input, я предложу realtive фильтры, а вы клик на чекбокс с перезагрузкой страницей.
Ответьте на вопрос: Кому выгоден отказ от JS?
А никому, всех все устраивает кроме Java и С# разработчиков, которые переживают за свой рынок.
andreymal
02.10.2017 22:27Опять доводим до абсурда?
Во-первых, про JPG, SVG и графику я ничего не говорил. Они не являются исполняемым кодом. (а в SVG пихать скрипты тем более нефиг)
Во-вторых, я в этой ветке нигде не говорил про отказ от JS. Я говорил про отказ от обязательного JS. Сайты, которые я делаю и буду делать, тоже имеют автокомплит, аякс и прочую дребедень — только, если захочется, всё это можно отключить, и сайт останется работоспособен. Опять же, смотрите мобильную версию ВК — там сделано именно так.
userphp1024
02.10.2017 23:11-2Во-вторых, я в этой ветке нигде не говорил про отказ от JS. Я говорил про отказ от обязательного JS.
Имеется ввиду по умолчанию отключить JS, но если пользователь захочет, то для конкретного сайта включит JS.
Что мешает вам сделать это сейчас?
Вы можете это сделать, отключаем JS в браузере, но включаем для определенных сайтов через плагин браузера.
Хотя я знаю что мешает — 99% сайтов поломаются.
Но представим что сделали все браузера мира такую фичу, предположим что все исправили косяки на сайтах и теперь их сайты работают без JS.
Только зачем это пользователям? Не вам лично, а пользователям и всему миру, какая в этом польза?
andreymal
02.10.2017 23:28+1Только зачем это пользователям? Не вам лично, а пользователям и всему миру, какая в этом польза?
Минус ещё одна потенциальная дырка в безопасности, минус майнер на The Pirate Bay, минус шпионство через fingerprint, плюс свобода выбора у пользователей, которые получат возможность выбирать, доверять разработчикам или не доверять, плюс возможность отрезать потенциальный вектор атаки на девайсы людей, плохо умеющих в интернет, вроде всяких бабушек да дедушек (как минимум на первое время, пока не освоятся). Вам этого мало? (В теории ещё экономия электричества и как следствие благоприятное влияние на экологию, но это уже на грани бреда.)
Мне всё ещё плевать, что это сложно и не выгодно для бизнеса.
justboris
03.10.2017 00:59ну если вы такой молодец, то утрите всем нос, напишите свой сервис без JS но со всей функциональностью.
Пока в этом треде просто какая-то демагогия "все должно работать без JS просто потому что так 10 лет назад все делали и всем было норм". Но это было 10 лет назад, а сейчас все немного по-другому
andreymal
03.10.2017 01:04Я и пишу, не волнуйтесь. Только вот одного меня не очень хватает, чтобы «переписать» весь интернет.
userphp1024
03.10.2017 14:07-1Минус ещё одна потенциальная дырка в безопасности, минус майнер на The Pirate Bay, минус шпионство через fingerprint, плюс свобода выбора у пользователей, которые получат возможность выбирать, доверять разработчикам или не доверять, плюс возможность отрезать потенциальный вектор атаки на девайсы людей, плохо умеющих в интернет, вроде всяких бабушек да дедушек (как минимум на первое время, пока не освоятся). Вам этого мало? (В теории ещё экономия электричества и как следствие благоприятное влияние на экологию, но это уже на грани бреда.)
Мне всё ещё плевать, что это сложно и не выгодно для бизне
1) На WIN тоже полно дыр и они будут всегда. последние 3 года я не слышал о серьезных уязвимостях в вебе, пробив связок сплойтов с годами пришел к 5%
2) Я создал сайт и хочу заработать на нем денег, не хочешь пользоваться моим сайтом, иди в библиотеку читать книги, там не будет рекламу и прочей фигни.
Но зачем я создал этот сайт? что бы на нем заработать, почему то все пользователи России думают что им обязаны чем-то разработчики сайтов, да плевал я на вас всех, мне главное заработать денег. (для заработка нужно сделать лучше чем у конкурентов, нельзя заработать на говне) была бы моя воля я бы ввел на все сайты платные подписки, хочешь читать рецепты — плати 0.01$ за каждый рецепт и плевать что это общая информация, я организовал удобный доступ к этой информации значит плати мне деньги, не хочешь — иди в библиотеку и читай бумажные рецепты или иди на сайты, которые не обновляются и там нет удобных фильтров по ингредиентам.
Сайты создаются не для вас, уважаемые пользователи, сайты создаются для заработка админов.
Только в России люди думают что им обязаны предоставлять бесплатный контент, я потратил 100 000 рублей на разработку сайта для вас любимых, вот такой вот я добряк, да плевать мне не вас всех. Если реклама перестанет приносить деньги, я включу майнер.sumanai
03.10.2017 16:20Но зачем я создал этот сайт? что бы на нем заработать
Эх, а раньше сайты делали для души, для того, чтобы поделится интересной информацией, для себя наконец, в виде блога с полезными рецептами. И делали специальные страницы, где размещали (бесплатно!) баннеры других интересных сайтов.
И только потом в веб пришли крупные компании, и теперь все тут только и делают, что зарабатывают.
RedCatX
03.10.2017 21:06была бы моя воля я бы ввел на все сайты
Зачем на все? Вводите на свои, это исключительно ваша воля. Кстати, такие сайты уже давно существуют и здравствуют.
Вот лично я был бы не против возможности купить платную подписку на поисковые системы, социальные сети, электронную почту, и т.д. Но с условием: на этих сайтах никакая информация обо мне не будет собираться ни в каких целях. Думаю, не только я хотел бы такую услугу…
vlivyur
03.10.2017 16:17SPA неудобен тем, что чтоб увидеть что сайт мне не нужен, нужно дождаться:
а) загрузки всего этого вороха скриптов
б) загрузки данных от этих скриптов
в) рендеринга всего этого.
Если сайт мне нужен, то плюсом ко всему этому:
г) непонятно то ли сеть отвалилась, то ли просто тормозит
д) а, нет, это всё-таки сеть отвалилась, и приложение не хочет дальше загружать — придётся обновлять страничку: IF (RANDOM() > 0.2) GOTO а)
е) найти бы то место, где бросил читать
ж) в особых случаях: ссылку на текст можно получить, соответственно можно закладку поставить.staticlab
03.10.2017 17:04SPA неудобен тем, что чтоб увидеть что сайт мне не нужен, нужно дождаться:
а) загрузки всего этого вороха скриптов
б) загрузки данных от этих скриптов
в) рендеринга всего этого.С серверным рендерингом страница и с отключенными скриптами отрисуется.
userphp1024
03.10.2017 21:44SPA неудобен тем, что чтоб увидеть что сайт мне не нужен, нужно дождаться:
а) загрузки всего этого вороха скриптов
б) загрузки данных от этих скриптов
в) рендеринга всего этого.
Если сайт мне нужен, то плюсом ко всему этому:
г) непонятно то ли сеть отвалилась, то ли просто тормозит
д) а, нет, это всё-таки сеть отвалилась, и приложение не хочет дальше загружать — придётся обновлять страничку: IF (RANDOM() > 0.2) GOTO а)
е) найти бы то место, где бросил читать
ж) в особых случаях: ссылку на текст можно получить, соответственно можно закладку поставить.
Средний размер JS бандла около 2МБ.
7 одного не ждут, слышали такую пословицу?
Чините свой компьютер, вызывайте системного администратора, повышайте скорость интернета.
Разумный минимум в 2017 году это: 4ГБ ОЗУ + Core i3 + 30 Мбит интернет.
Почему всех людей на планете все устаривает, а вас нет? Под вас никто не будет подстраиваться, у нас 21 век и если вы сидите с Window XP, то это ваша проблема, а не наша.
Хотите пользоваться современным вебом установите себе разумный минимум, который я описал выше.
Ладно, я могу поверить что вы живете в Якутии где скорость интернета равна 10 Мбит и Core I3 Там роскошь, я предлагаю вам воспользоваться альтерантивами:
1) новости читайте через RSS
2) Не пользуйтесь Хромом, он не выгружает сайты из памяти и забивает оперативку, он оптимизирован под современные компы
3) вместо фотошопа берите paint
4) Вместо goole Maps берите бумажную карту или скачиваете приложение внутрь системы.
Если у вас лагает сайт под мобильный интернет что делать?
1) осознать что создатель сайта вам ничего не должен., россияне привыкли что им должны все нахаляву делать качественно.
2) платите создателю денег что бы он развивал свой сайт и вкладывал в SSR
3) у крупных компаний как правило есть отдельное мобильное приложение, которое оптимизировано под мобильникиsumanai
03.10.2017 22:11Разумный минимум в 2017 году это: 4ГБ ОЗУ + Core i3 + 30 Мбит интернет.
У меня 24ГБ ОЗУ, Core i5 на 4ГГц и 100 мегабит, и экономичная Windows XP на борту. Но я недоволен SPA, особенно первой загрузкой.
у нас 21 век и если вы сидите с Window XP, то это ваша проблема, а не наша.
Под XP сижу я, проблем с ОС нет.userphp1024
03.10.2017 23:20-1И сколько он у вас грузится? целую секунду?
Как вы поняли что проблема именно в SPA? замеряли скорость?
можно пример глючного SPA сайта?sumanai
04.10.2017 11:225 секунд на белой странице, иногда с издевательским прелоадером. Примеры не приведу уже, я такие сайты стороной обхожу, а не вношу в закладки на память.
Virviil
29.09.2017 21:03+1Если Гугл в AndroidSDK в класс
android.widget.Buttonвлепит колбэк на отправку нажатия на кнопочку в Гугл — большинство андроид приложений будет всю свою статистику слать прямиком туда. Потому что никто свои виджеты не делат (разве что в играх на Unity каких нибудь).
А если будет слать через сокет а не через http-запрос — то раз в стопицот быстрее чем Google Analytics.
Так что не вижу принципиальной разницы.
Насчёт установки — я лично считаю что понятие операционная система в современных реалиях должна быть пересмотрена.
Например такие вещи как расширения файлов и древовидная файловая система кажутся очевидными, но это не так :)
staticlab
28.09.2017 16:06Давно пора заменить все это дно на какой-нибудь «контейнер приложений» вместо браузера, которые распространялись бы в бинарном виде, работали по нормальному «дуплексному» протоколу, а для UI использовался бы нормальный язык разметки, в идеале поддающийся автоматизации (чтобы дизайнеры могли «рисовать» его в редакторе, не заморачиваясь с версткой).
Мобильные приложения, не?
justboris
28.09.2017 21:14+6Ну конечно, спустя 20 лет очень просто рассказывать, как именно надо было делать Веб.
И, по моему мнению, если бы вместо html мы бы писали TeX, Веб лучше бы не стал.
torbasow
29.09.2017 13:45+1ущербный язык стилей, в котором до самых последних версий не было даже возможности отцентровать элемент по горизонтали
По вертикали.
Lsh
30.09.2017 14:49зачем надо было придумывать этот велосипед, когда уже существовал хоть тот же TeX
Что-то слабо себе представляю его применение. Как там с изменением размеров окна, например?
Columnistdc
28.09.2017 15:47Вангование ниже:
Скрытый текстЯ посмотрел в блог Майка и мне кажется, он будет во второй части продвигать Kotlin
romy4
28.09.2017 16:02+2Веб ущербен от начала и до конца. Но он там же и останется, потому что выгода получаемая от дырявого говнокода перекрывает потенциально возможные проблемы от взломов. Почему тот же Facebook, огромнейший гигант, как и Amazon всё ещё не используют для загрузки, например websockets и https/2? а) возможность взлома сведена к минимуму кучей надстроек внутри API. 2) проще докупить ещё аппаратной части для обеспечения производительности, чем менять инфраструктуру. Корпорации в данном случае решают _как_ должен выглядеть веб.
DarthVictor
28.09.2017 16:03+9У меня, как у фронтенд разработчика, конечно довольно много претензий к современному вебу, но хотелось бы сначала увидеть альтернативы причем, с вменяемыми средствами разработки и примерами сценариев использования.
Татарский, конечно, ненавидел советскую власть в большинстве её проявлений, но все же ему было непонятно – стоило ли менять империю зла на банановую республику зла, которая импортирует бананы из Финляндии.
Zverienish
29.09.2017 06:23В виду того, что сейчас все завязалось веб стек, других средств вменяемых появляться не будет.
denismaster
29.09.2017 10:13А если соединить все лучшее из мира десктопа и Web?
Например, реализовать единый стандарт байт-кода. Основать его на байткоде CLR, JVM, V8. WebAssembly же смогли сделать, смогли договориться, так и тут)
И реализовать его поддержку на уровне ОС. В этот байткод будет компилироваться JS, .NET, Java-приложения и т.д.
Для поддержки приложений реализовать единый стандартный язык разметки, можно например на основе XAML. Обеспечить поддержку модных нынче компонентов. Можно встраивать в систему готовые компоненты.
На уровне ОС обеспечиваем удобный интерфейс, похожий на браузер, для просмотра HTML-документов(которые останутся документами, максимум интерактивными страничками).
Также в этом интерфейсе можно будет зайти на сайт, а он предложит установить приложение, либо автоустановка в безопасном месте, только с пользовательскими правами. Можно сделать на основе идей мобильных приложений)
В разных вкладках этого браузера 2.0 можно будет запускать как просмотр документов, так и приложения.
При этом исполняющая среда не будет по одной копии на вкладку, а общая на систему.
Таким образом, получаем настоящие кроссплатформенные приложения, удобство для разработки, красивые интерфейсы, при этом решаем проблему Electron(где отдельный Chromium на каждое приложение), и можно делать на любом языке программирования.
А ОС будут уже соревноваться между собой кто как лучше реализует эти стандарты и быстрее исполняет этот байткод.
И можно будет вводить стандарты на API к различным элементам системы, при этом делать их безопасными. Все равно все корпорации так или иначе стараются выполнять веб-стандарты)
Это будет ОС 2.0 и Браузер 2.0.
Эх, мечты…
semmaxim
29.09.2017 11:20Например, реализовать единый стандарт байт-кода… В этот байткод будет компилироваться JS, .NET, Java-приложения и т.д.
Уже есть. «Система команд x86» называется.
реализовать единый стандартный язык разметки
Уже есть. HTML называется. На мой взгляд, ужасен.
На уровне ОС обеспечиваем удобный интерфейс, похожий на браузер, для просмотра HTML-документов(которые останутся документами, максимум интерактивными страничками).
Чем эти «документы» тогда будут отличаться от приложений? А уж интерфейс для запуска приложений в ОС и так хорош.
При этом исполняющая среда не будет по одной копии на вкладку, а общая на систему.
Копию на вкладку сделали не просто так, а ради стабильности и безопасности.
Вобщем, всё уже либо было либо уже придумано и реализовано.denismaster
29.09.2017 12:00Вы немного переиначили все.
Уже есть. «Система команд x86» называется.
Имелось в виду байт-код, не привязанный ни к платформе, ни к языку программирования. Что-то похожее на WebAssembly или LLVM IL.
Уже есть. HTML называется. На мой взгляд, ужасен.
HTML — предназначен для текстовых документов. Я же предлагал XAML. Можно взять любой другой, tex и т.д. Сделать поддержку компонентов в первую очередь.
Чем эти «документы» тогда будут отличаться от приложений? А уж интерфейс для запуска приложений в ОС и так хорош.
А чем сейчас документы отличаются от приложений? Я имел в виду единый интерфейс, чтобы юзер захотел — открыл сайт, документ, захотел — запустил приложение и было удобно. Это будет скорее tabbed shell, чем браузер, где каждая вкладка может быть окном, а каждое окно — набором вкладок.
Копию на вкладку сделали не просто так, а ради стабильности и безопасности.
Я критикую подход электрона, который запускает Chromium на каждое окно. При этом можно было бы вынести все таки эту общую часть и не грузить ее каждый раз по новой.
worldmind
28.09.2017 16:40> Думаю, что веб стал таким, потому что HTML вышел с вполне вразумительной философией дизайна и инструментарием как платформа для документов, но в качестве платформы для приложений HTML пришлось закреплять на соплях, и ничего хорошего до сих пор не получилось.
это ключевое, давно об этом пишу и говорю — HTML это язык разметки гипертекста, а для современных задач нужен язык разметки приложений. Javascript это клей для вывода alert окон и т.п., а сегодня нужен полноценный, грамотно спроектированный язык.
ragequit
28.09.2017 16:50-2О, очередной вой очередного «бородатого ортодокса». Друг мой, сейчас маленький гуманитарий, который очень долго соприкасался с миром разработки, но так и не стал его частью, объяснит тебе, почему Web — это хорошо. Я понимаю, что это перевод, но переводчик же должен разделять идеи оригинала, так?
Так вот, переводчик, Web — это не замена десктопным приложениям, это альтернатива им. «Каждый дрочит так, как хочет» — слыхал? Если тебе нравится обмазываться десктопом — флаг в руки. Не мешай наяривать другим.
Web не должен быть быстрым, это понятно любой мартышке.
Люди пользуются Web-приложениями типа Google Docs, потому что они дают свободу от сраных десктопных приложений. Я могу править документы откуда угодно, все что мне нужно — не удариться по пути головой и помнить данные моей электронной почты.
Возможно, ты, мой друг, еще с года 2001 перетаскиваешь с винта на винт всякий хлам, типа альбомов Арии или КиШа в качестве MP3 в 64 битрейте. Твое право. Но то, что ты не способен понять и принять парадигму альтернативы — лишь твоя проблема. Не будет универсального «единого приложения», которое придет на смену Вебу, не будет вообще приложений. Потому что Web в том смысле, в котором мы его сейчас обсуждаем, возник как раз для того, чтобы ничего не качать, чтобы все крутилось на стороне больших и умных дядь. Кстати, это, как раз таки, одна из альтернатив на тему и Информационной Безопасности. Да, чтобы за ней следили большие, умные и совсем не ленивые дяди-разработчики на местах. Согласись, это проще, чем пытаться латать дыры у миллионов пользователей на их устройствах. Или нет?
Безопасность — это вообще миф. Идеального кода, приложений, производительности, даже собеседников — не бывает. Весь мир состоит из компромисса между скоростью и функциями, безопасностью и простотой, офлайновым и онлайновым доступом. И хватит тут разводить бредни про «Веб должен умереть!». Вылезь уже из своего уютного мирка, где образ «бородатого разработчика с котэ» все еще моден, и встреться с реальностью.
Без уважения, мимо пробегающий гуманитарий.
Toshiro
28.09.2017 17:09-13+1
FlameStorm
29.09.2017 15:14+2Как одним неловким комментарием молодой хабраюзер может уничтожить свой аккаунт. Глянул, в целом комментарии нередко годные писал Toshiro, но тут его настиг лютый фейл и хабрахаммер силой в минус двадцатку кармы, даже как-то жестоко.
Относительно предыдущего коммента — не разделяю хейта к десктопу и прям обожания к вебу, и про дядь всё понимаю. Да и облака оно такое, сегодня есть, завтра ветром развеяло. С винта на винт таскаю конечно всякое нужное, и если о музыке говорить, то в годном качестве, включая флаки. Но это не отменяет того, что к вебу тоже отношусь с теплотой и моё следующее приложение будет разрабатываться на REST JSON API и всё такое этому сопутствующее. А будет что-то лучше, так посмотрим.FlameStorm
29.09.2017 15:29+2PS:Хотя может и не из-за этого коммента, было ещё парочку с непопулярным мнением, а оно тут нередко карается, свобода слова ж такая она. :) Имел место наблюдать не единожды. Beware, %username%.
MacIn
28.09.2017 17:29-2Возможно, ты, мой друг, еще с года 2001 перетаскиваешь с винта на винт всякий хлам, типа альбомов Арии или КиШа в качестве MP3 в 64 битрейте. Твое право.
Как же энтропия?
zugo
28.09.2017 18:09+14Гуманитарий на то и гуманитарий, чтобы вообще не понять, о чем идет речь. Нет проблемы в идее распространения и запуска контента и приложений через веб. Проблема только в том, что стек «веб-технологий» — говно на палке, и никак не улушает производительность и безоспасность.
ragequit
28.09.2017 20:18-2А, извините, значит мне померещилось заявление
Почему веб должен умереть
Целый подзаголовок. Или там должно было быть «Почему текущий стек веб-технологий должен умереть»? Что-то не склеивается, знаете ли.
Кстати, как гуманитарий я читать умею внимательно, и карту текста делать в уме. А как активный автор Хабра и Гика — отличить «Веб» как явление от «стека технологий».
CoreTeamTech
28.09.2017 18:51+18Вы ничего не поняли, «перевернули» слова автора(переводчика), выплеснули эмоции, перешли на личности, сделали «капитанские» выводы… Хм, а что сказать-то хотели? В чем преимущество веб-приложений от десктопных? Вот честно?
Вот установлен у меня десктопный менеджер, написанный на QT, обновляется за минуту абсолютно прозрачно и возвращает тот же самый чат на том же самом месте, где был до обновления. Работает быстро и гладко. А вот приложение Gmail, которое периодически само обновляется, не спрашивая меня и тоже минуту и открывается на главной странице, а не в треде писем который был открыт до этого. А еще вот у меня на телефоне приложение написанное на Xamarin, которое побыстрому накидано в редакторе форм и работает отлично на разных платформах, в том числе и десктопных. Рядом PWA, которое не следует гайдам платформы, а потому регулярно обновляется и качает несколько мегабайт нового фронтового кода ради замены цвета панелек и какой от него прок тогда?ragequit
28.09.2017 20:17-6Мы о веб-приложениях, кстати, или о клиентских сервисах? Если мне не изменяет память, то Веб-приложение подразумевает клиент в лице браузера, который работает в качестве «форточки», если совсем утрировать. Все остальное — на стороне разработчиков (сервера). А вы мне про приложения Gmail и скачивание обновлений.
maniacscientist
28.09.2017 23:17+1Редактор форм для хамарина? Это где ж такое? Они предварительный просмотр запилить толком не могут, чушки мохнорылые
CoreTeamTech
29.09.2017 10:12-1Ну да, они только сейчас его запилили. Поэтому у нас свой дизайнер прото-форм, который потом транслирует это все в другие языки, платформы и фреймворки :) Но я писал не столько о быстрой разработке, сколько о том, что это работает и подход десктопный.
lightman
29.09.2017 11:16+8«Каждый дрочит так, как хочет» — слыхал? Если тебе нравится обмазываться десктопом — флаг в руки.
Если бы мы все жили и работали каждый в своём маленьком индивидуальном пузырьке, то да. После этого вашего высказывания можно было бы поставить точку и закрыть тему.
Но мы живём во взаимосвязанном мире. И поэтому нет, противникам веба отнюдь не всё равно, что выбирают юзеры и организации по всему миру. Распространение продуманных стандартизированных решений полезно для нас всех, т.к. улучшает качество софта, увеличивает количество вакансий, удовольствие от работы, в конце концов.
Поэтому нет, затыкать и тыкать «сперва добейся» никого не надо, наоборот, нужно больше говорить о проблемах, кричать о них в провокационных статьях, вопрошать и убеждать, выступать по телевизору и раздавать листовки,создать террористическую организацию антивебное государство и начать ломать веб-сайтыragequit
29.09.2017 11:43-3В статье присутствует типичная подмена понятий «веб-сервиса» и «инструментария веб-сервисов». Первые — благо. Вторые — да, местами ужасают.
0xd34df00d
29.09.2017 21:06+3Возможно, ты, мой друг, еще с года 2001 перетаскиваешь с винта на винт всякий хлам, типа альбомов Арии или КиШа в качестве MP3 в 64 битрейте.
Перетаскиваю с винта на винт (rsync'ом) всякий хлам вроде техникал детха во флаке и не завишу от наличия интернета, прихотей правообладателей и кривости реализации gapless playback в онлайн-плеерах.
При этом пользуюсь стимом, потому что удобно. Что не так?
Lorys
28.09.2017 17:38+2IMHO: все проблемы из-за JS.
Стараюсь пользоваться web'ом с отключенным JS, включаю его только на тех сайтах, которые без него не работают, но мне очень нужны, либо включаю временно, что бы получить нужный функционал.
Изначально созданный в гонке за фичами, JS стал огромной проблемой для всего web'а…
jakobz
28.09.2017 17:45+1В целом, я с автором согласный. Можно посмотреть, скажем интерфейсы в играх — такое на вебе вообще никогда не сделаешь, даже если деньги не считать. А ведь UI в играх делают небось не супер-джедаи, на каких-нибудь там доморощенных фреймворках со скриптами и кнопочками.
Слепить несложный стандарт из готовых штук, и впилить в тот же Chromium второй режим вкладки для его поддержки — вполне посильная задача. Там не надо никаких гипертекстов даже — достаточно будет JVM, WebGL, API для мышки/клавиатуры, и RPC. И сразу уже игрушки можно будет по ссылке открывать. А с остальным — заменой для CSS/HTML, accessibility, индексированием, и прочим всем — вполне можно по ходу дела разбираться, добавляя стандарты и библиотеки.wert_lex
28.09.2017 22:55+3JVM какой версии держать будем? Обновлять как будем? Сэндбоксом для JVM кто будет управлять? RPC как построить так, чтобы можно было получить ограничение по доменам? На стороне клиента нужен какой-то стандарт для хранения данных? Окей, будем считать с десктопом вопрос зарешаем. Тут ходовых платформ всё же всего полторы — x86 + unix/windows.
Теперь дело за малым, перенести эту референсную реализацию на ARM да под android, windows phone, ios… tizen, remix, sailfish, symbian, webOS и заставить на телевизорах работать.
Это я всё к чему? Если сделать замену вот такую: JVM -> V8, WebGL -> WebGL, API мышки/клавиатуры -> MouseEvents, RPC -> Ajax/XHR то получится, внезапно, то что сейчас есть, только оно более-менее работает почти на всех платформах старше IE9.
andreymal
28.09.2017 23:21Собственно, вся суть нытья в том, что то, что сейчас есть, кривое. Будь у меня достаточно квалификации, я бы предпочёл попытаться порешать вопросы из первых двух абзацев)
wert_lex
29.09.2017 00:35-2Да ну ёлки, где оно кривее остальных-то?
Я года три назад перескочил из уютного Java мира с Java/Scala в node + frontend. Нормальное оно. Другое просто сильно.
Стандарты менее стандартные, но если не упарываться по всякой разработке игр на WebGL и другим крайне интересными, но не мейнстримовым вещам, то нормальное оно. И даже работает.
Берёшь Babel — и практически все проблемы с JS закрыты. Берёшь bootstrap, и не надо даже начинать думать о чем-то кроме того, в какой цвет кнопки покрасишь. Фреймворков для того, чтобы формочки и кнопки рисовать уйма. Начиная от крайне ванильного HTML/CSS/JS, заканчивая всякими Elm, ReasonML, ClojureScript, в связке с чем угодно, которые вполне себе работают.
Ну и React, раз уж столько хайпа про него. Автор про Flux упомянул. Он может быть и из времен Win3.1, но проблему-то он решает вполне неплохо. Если сравнивать, условно, Redux, который, конечно не совсем Flux, но из той же оперы, с правильным и расово-верным Qt (или что там автор предлагает?), то хм… кто из этих двоих ребят позволяет сделать replay приложения практически искоробки?
В общем, я конечно не могу сказать, что во фронтенде всё такое классное и блестящее — нужно ещё пилить и пилить. Но сегодня большинство проблем кривизны решается с помощью npm install left-pad… OH WHAI~~
andreymal
29.09.2017 01:17+3если не упарываться по всякой разработке игр на WebGL и другим крайне интересными, но не мейнстримовым вещам, то нормальное оно
Это утверждение из разряда «в принципе, если ничего не покупать, цены нормальные». Если не упарываться и ограничиваться примитивными вещами, можно даже продолжать сидеть в IE5 — его возможностей хватит почти для всего «не упоротого». Веб нужно убить именно потому, что как только задача становится капельку сложнее примитивной — начинается лютый трэш и угар. USB, нормальная многооконность, трей, протоколы помимо HTTP(S), FTP, WebSocket и WebRTC, UDP, вменяемый доступ к файловой системе и прочие плюшки — всё это или в зачаточном состоянии, или отсутствует вообще. У меня прямо сейчас запущены мессенджер с протокол XMPP, почтовый клиент с протоколом IMAP, торрент-клиент, аудиоплеер читающий flac-файлы с внешнего жёсткого диска, виртуальная машина с виндой, клиент Steam умеющий запускать заранее установленные игры в оффлайне, VNC-клиент и VNC-сервер. Вполне обычные вещи, но вебу о них остаётся только мечтать. Хотя в том же нижеупомянутом андроиде проблем с этим почти нет.
Здесь можно вспомнить про Electron. Он снимает некоторые ограничения (например, Skype получает возможность запихнуть себя в трей), но, опять же, поделки на нём жутко тормозят и лагают и жрут гигабайты памяти (на интел-атоме 2010 года можно даже не пытаться запускать), а также имеют все проблемы, перечисленные ниже. В то время как все десктоп-аналоги ведут себя довольно скромно, за 50 мегабайт оперативы вылезают редко (хотя по-моему это тоже много, но щито поделать, десктоп-разработчики тоже избалованы гигабайтами оперативы, эх), а проц не кушают вообще.
Берёшь Babel — и практически все проблемы с JS закрыты.
Высокоуровневый язык, компилируемый в другой высокоуровневый язык. Это же полный бред! Особенно когда что-то строгое и статическое компилируется в слабое и динамическое (TypeScript, C++). К счастью, с приходом WebAssembly эпоха полного бреда, возможно, закончится.
Берёшь bootstrap
Я абсолютно не переношу внешний вид бутстрапа (любой версии) и блюю от любой его кнопочки. у меня в системе установлена няшная тема Numix с не менее няшными иконками, и я хочу видеть эту тему везде в своей системе — почему же разработчики сайта решают за меня, как читаемый мной контент должен выглядеть? Ах да, веб же не позволяет использовать системную тему. В тяжёлых случаях приходится обмазываться всякими Stylish. Здесь стоит упомянуть, что даже Java умеет воровать текущую тему из GTK, да и вообще имеет биндинги к GTK.
Фреймворков для того, чтобы формочки и кнопки рисовать уйма.
По-хорошему должен быть один-единственный canvas, на котором рисуется всё что нужно приложению любым нужным фреймворком. Но нет, будем использовать язык разметки текста! И будем обходить его заточенность под текст многочисленными CSS-костылями, включая ранее упомянутый бутстрап. При этом выровнять блок по вертикали возможно лишь пару лет как, а прижать футер резиновой высоты к низу страницы невозможно до сих пор (а с js нельзя, потому что будет мерцать из-за асинхронности). А canvas — лишь один из элементов внутри потока текста. Хотя должно быть наоборот. Опять полный бред получается.
React и Flux это в данном контексте больше про архитектуру (ибо есть ещё React Native, например). Но работают-то они всё равно поверх ущербных HTML/CSS/JS.
И, напомню, всё это жутко тормозит и лагает, не делая при этом почти никакой полезной работы. (Хотя есть надежда, что с приходом WebAssembly тормозить и лагать станет чуть меньше)
Druu
29.09.2017 04:23> По-хорошему должен быть один-единственный canvas, на котором рисуется всё что нужно приложению любым нужным фреймворком.
А клиент будет каждый раз качать 100мб этого фреймворка?
> Но нет, будем использовать язык разметки текста!
Есть альтернативы? Почему в современных десктопных гуи-фреймворках тоже используется язык разметки текста, а не что-то иное?andreymal
29.09.2017 10:36+2А клиент будет каждый раз качать 100мб этого фреймворка?
А сейчас он тоже качает, это называется браузер.) Хотя проблема действительно есть, но, думаю, если посидеть подумать, можно найти пути её решения, например принудительный semver и переиспользование ранее скачанных файлов за счёт него. Но я пока воздержусь от дальнейших рассуждений.
Есть альтернативы?
QML, XAML, GTK XML, XUL в конце концов?
Почему в современных десктопных гуи-фреймворках тоже используется язык разметки текста, а не что-то иное?
А это просто враньё. Выше я перечислил, что используется на самом деле. (Веб-макаки, клепающие говноприложения на электроне, естественно не в счёт)
Druu
29.09.2017 14:26> А это просто враньё. Выше я перечислил, что используется на самом деле.
Так вы и перечислили языки разметки, с точностью до синтаксиса повторяющие html. Если подход с использованием всех этих языков плох — то почему люди их используют, а не хреначат интерфейсы программно, без декларативного описания?andreymal
29.09.2017 14:30Они все — языки разметки интерфейса (или приложений, суть не изменится), а не языки разметки текста. Я ничего не имею против языков разметки. Я против использования языков разметки не по назначению, как это сейчас происходит с HTML (вы ведь в курсе, как расшифровывается HTML вообще?)
napa3um
29.09.2017 15:59-1HTML5 уже не разметка для текстов, это именно платформа (стек технологий) для построения веб-приложений. А название досталось в наследство.
andreymal
29.09.2017 16:02В наследство досталась и заточенность именно под текст. Любая страница по умолчанию до сих пор является потоком слов и символов со всеми присущими им проблемами. Некоторые можно исправить в CSS3 (в частности, с flexbox жить стало лучше), некоторые нельзя до сих пор. Кстати, в HTML5 сильно прокачали именно семантику именно для текста, а не для приложений.
SelenIT3
29.09.2017 19:12Что особенно странно, если вспомнить, что на заре своей юности HTML5 назывался именно «Web Applications 1.0» :)
Druu
30.09.2017 13:36> Они все — языки разметки интерфейса (или приложений, суть не изменится), а не языки разметки текста.
В каких конкретно факторах проявляется, что HTML — язык разметки текста, а не интерфейса?SelenIT3
30.09.2017 18:06Например, в наличии кучи элементов для выделения в этом самом тексте мельчайших смысловых оттенков, которые даже редакторы спецификаций не всегда одинаково различают (кто сходу ответит без гугла
и драки, для чего<mark>, а для чего — обновленный<b>?) при отсутствии даже такого элементарного примитива для интерфейсов, как<panel>.
RedCatX
03.10.2017 21:17Времена, когда HTML использовали для разметки текста давно прошли. Сайты, представляющие собой текстовый документ с навигацией сегодня большая редкость, практически каждый сайт — веб-приложение, которое куда как проще создать с использованием какого-нибудь языка разметки интерфейсов, чем с современным HTML. Поэтому, было бы очень выгодно заменить HTML на что-то похожее на XUL или XAML — от этого бы выиграли как веб-разработчики, так и конечные пользователи.
RPG18
29.09.2017 12:05А клиент будет каждый раз качать 100мб этого фреймворка?
У нас свой фреймворк на C++ и приложение в wasm весит 10Mb, в жатом виде 2.7 Mb. Что бы каждый раз не скачивать используется кеширование.
staticlab
29.09.2017 15:13Но для полноценного современного веб-приложения нужно уметь и скринридеры поддерживать. Как это в принципе на WebGL сделать?
kekekeks
29.09.2017 20:22Выгружать дерево UI-контролов в примитивный невидимый кусок DOM без CSS с aria-тегами. Если фреймворк изначально портируется с десктопа, то там кроссплатформенная поддержка скринридеров скорее всего уже есть и к ней такое прикрутить не сильно сложно.
wert_lex
29.09.2017 09:34USB, нормальная многооконность, трей, протоколы помимо HTTP(S)
Стойте. Причём здесь веб? Многооконность и трей, к счастью, не очень про веб. Веб — это про рисовать странички. Многооконность, трей и всё остальное — это про операционную систему. Должен ли это уметь веб? Возможно, но зачем? Кстати, как многооконность с треем должна работать на андроиде, допустим?
Ах да, веб же не позволяет использовать системную тему
Да даже горячо любимый Qt не позволяет без плясок с бубном использовать системную тему. Должен ли это делать веб?andreymal
29.09.2017 10:44Причём здесь веб?
Если веб — платформа для приложений, то должно присутствовать всё перечисленное и не только.
Должен ли это уметь веб? Возможно, но зачем?
Затем, что веб нынче считается платформой для приложений. Если же рассматривать веб как HTML для разметки текста и его связи гиперссылками, CSS для его разукрашивания и скрипты сбоку для капельки интерактивности (чем он и является на самом деле), то тогда всё мной перечисленное действительно не нужно, но это же означает, что две трети сайтов используют веб не по назначению. Гуглдоки, скайп, слак, дискорд, трелло, Unreal Engine 4 — это всё нихрена не про разметку текста блин!
Да даже горячо любимый Qt не позволяет без плясок с бубном использовать системную тему.
Во-первых, у меня он подхватывает Numix без плясок. Во-вторых, даже если вдруг пляски где-то и нужны, прикрутить системную тему всё-таки можно, и пляски это в минус Qt, а не в плюс вебу.
staticlab
29.09.2017 09:41Но нет, будем использовать язык разметки текста!
А там выше человек предлагал вместо HTML использовать TeX.
indestructable
29.09.2017 12:53По-хорошему должен быть один-единственный canvas, на котором рисуется всё что нужно приложению любым нужным фреймворком.
Так это и сейчас можно. Только попробуйте продать такую разработку кому-нибудь. И дизайнера впридачу, т.к. на бутстрапе сверстать может даже программист, и от этого не будет тошнить, а рисовать на канвасе — это мы вернемся в век адских самописных утилит с джпег-картинками вместо кнопок.
а прижать футер резиновой высоты к низу страницы невозможно до сих пор (а с js нельзя, потому что будет мерцать из-за асинхронности)
Да вроде можно тем же флексом прижать, если устраивает скролл в рамках области контента
andreymal
29.09.2017 13:20Так это и сейчас можно.
Нельзя. Можно только canvas внутри HTML. А надо чтобы HTML рисовался на canvas. Как следствие, утверждение «Только попробуйте продать такую разработку кому-нибудь» не имеет смысла, потому что такой разработки ещё просто нет. (В десктоп-приложениях можно что угодно, но они требуют установки и поэтому не относятся к данной теме)
а рисовать на канвасе
Портировать бутстрап (или любой другой аналог) на канвас же, не думаю что получится что-то адское. И вообще должна использоваться системная тема
и всех дизайнеров выгнать из веба и отправить на создание системных тем, воот))
Да вроде можно тем же флексом прижать
И правда, тут я чёт погорячился. Тем не менее нельзя ещё много чего, но точный список не записываю и прям щас не упомню всё
userphp1024
02.10.2017 22:30-1C приходом WebAssembly эпоха полного бреда, возможно, закончится.
Хотя есть надежда, что с приходом WebAssembly тормозить и лагать станет чуть меньше
Кому выгоден отказ от JavaScript? Подумайте и ответьте на этот вопросы.
1) Конечных пользователей все устраивает.
2) Веб разработчиков все устраивает
3) Не устраивает только Java и C# программистов, потому что их рынок пытаются занять выскочки из JavaScript области.
Я вас расстрою, но WebAssembly усилит JS в 100 раз, люди так и будут писать на JS, только к супер тяжелым задачам, такие как: «Web Photoshop» будут подключены Толковые С++ программисты. Но все проекты как были на JS так и будут. React / angular как был на JS так и останется, только критические участки кода будут переписаны на C++.
Но давайте пофантазируем, предположим что будет все по вашему, все языки создали свой фреймворки, которые переводят код в байт-код.
Вы думает только С++ и C# такие умники? этого захотят все.
К чему это приведет: Распад рынка на 10 секторов. Представим что у всех равная доля, представим что часть JS-программистов пересели на С++, часть на C#.
А еще Python подтянется, далее PHP программисты начнут пилить FRONTEND На PHP (да, будут все пилить костыли в виде фреймворках, С++ можно а нам нельзя что ли? мы тоже хотим на фронте писать на своем любимом языке)
Опять ответьте на вопрос, какую проблему бизнеса это решит и какие выгоды миру будут даны? Скорость отдачи странички?
у 99% людей интернет работает быстро. Если у вас 4 пенек и 2GB ОЗУ, то это ваши проблемы. никто не будет подстариваться под бомжей, доля на рынке которых составляет 0.00001%
ОГРОМНЫЙ сдвиг будет в крупных бизнес приложениях.
Будет Photoshop на WEB, Но 95% рынка это никак не каснется.
andreymal
02.10.2017 22:50+2какую проблему бизнеса
Да плевал я на бизнес, я страдаю как пользователь
Если у вас 4 пенек и 2GB ОЗУ, то это ваши проблемы.
Почему я должен доставать кор-ай-девятьтысяч и 32+ГБ для задач, которые без напряга способен решать даже какой-нибудь третий пенёк с 128МБ оперативки? Почему лет десять назад скайп на компьютерах того времени нормально работал, а сейчас, умея всё абсолютно то же самое, тормозит не то что на мамином, а даже на моём новеньком кор-ай-пять из 2014-го? Почему у меня забирают право пустить ресурсы моего компьютера на что-то полезное и заставляют или тратить проц и оперативу на абстракции над абстракциями, или отказываться от чуть ли не всех приложений вообще? (Вообще десктоп-приложений это тоже касается, но там наглеют ещё не так сильно, как ленивые веб-макаки, клепающие скайпы на электронах.)
Вспоминается классика:
Удивительное это дело — прогресс. Чтобы набрать и распечатать одну страничку красиво оформленного текста мне уже не хватает мощности компьютера, который с легкостью может управлять двумя тысячами советских боевых спутников одновременно. Есть мнение, что если бы не
microsoftвеб-макаки, то мы давно бы уже покорили вселенную.userphp1024
02.10.2017 23:40-1Да плевал я на бизнес, я страдаю как пользователь
А на вас плевал сам бизнес, никто не будет ждать 1 человека с 4 пеньком, у которого в кармане Nokia 3310 с Os Симбиан.
Если вы страдаете как пользователь, то вызовете системного администратора на дом, возможно у вас какие-то проблемы с жестким диском, оперативной памяти или компьютером в целом.
Либо ваше оборудование устарело.
Смените браузер, Croome не отчищает память минут 5 и не закрывает соединения даже если вы закрыли вкладку, это нужно для глаз пользователя, что бы все было моментально, но жертвуется оперативка :)
Есть всяческие браузеры, которые выгружают сайт из оперативной памяти сразу после того как вы снимете фокус с вкладки, у вас будет хаваться около 50 оперативки, но при каждой активации вкладки будет отправляться новый GET запрос.
Вот какие варианты предлагает современность для бедных людей с Nokia 3310
Почему я должен доставать кор-ай-девятьтысяч и 32+ГБ для задач, которые без напряга способен решать даже какой-нибудь третий пенёк с 128МБ оперативки? Почему лет десять назад скайп на компьютерах того времени нормально работал, а сейчас, умея всё абсолютно то же самое, тормозит не то что на мамином, а даже на моём новеньком кор-ай-пять из 2014-го? Почему у меня забирают право пустить ресурсы моего компьютера на что-то полезное и заставляют или тратить проц и оперативу на абстракции над абстракциями, или отказываться от чуть ли не всех приложений вообще? (Вообще десктоп-приложений это тоже касается, но там наглеют ещё не так сильно, как ленивые веб-макаки, клепающие скайпы на электронах.)
Только пользуетесь то вы продуктом бизнеса, а он делает то что ему выгодно, все что вы ведите в интернете создано не для вас любимого, а для личного обогащения хозяина этого бизнеса(сайта)
Поверьте, я могу написать продукт на ASM за 4 года.
Но мой конкурент сделает это за 2 месяца, такой же продукт.
Да, 0.0001% рынка будет потеряна, продуктом не смогут пользоваться люди с старыми компами, но для рынка эти люди не являются ценными, если человек не может купить себе комп за 15 000 рублей, то наш продукт то он точно не купит.
Есть разумный минимум в 2017 и я вам его опишу.
1) У каждого должен быть мобильный телефон на базе Android / IOs / Window OS ( цена от 10 000 рублей)
2) Компьютер или ноутбук (4гб — 8гб ОЗУ / 500ГБ, core i3-i5) (цена от 15 000 рублей)
Никто вас не принуждает, вы всегда можете жить в бунгало и пользоваться предметами 20 века.
Это прогресс, я тоже не хотел с XP пересаживаться, но меня заставили перейти на другую OS и обновить компьютер.
andreymal
02.10.2017 23:45Только пользуетесь то вы продуктом бизнеса, а он делает то что ему выгодно, все что вы ведите в интернете создано не для вас любимого, а для личного обогащения хозяина этого бизнеса(сайта)
userphp1024
02.10.2017 23:56-1Мы все понимаем, что «выгодно для бизнеса» и «выгодно для пользователя» — вещи противоположные.
Вот эту фразу я там увидел.
Пользователи довольны, не довольны лишь 0.0001% бомжей.
Но и у бомжей есть альтернатива: берите себе браузер, который рвет соединение при закрытии вкладки и выгружает сайт из памяти.
Вкладки будут грузится долго, но это решит проблему с оперативнйо памятью.
Вместо Photoshop у вас есть альтернатива paint.
WORD 2016 -> Nodepad
sumanai
03.10.2017 16:23Это прогресс, я тоже не хотел с XP пересаживаться, но меня заставили перейти на другую OS и обновить компьютер.
То есть вами помыкают, и теперь вы хотите помыкать другими?
Я вот на ХР, и никуда не собираюсь пересаживаться, пока железо работает.
RedCatX
03.10.2017 21:311) Конечных пользователей все устраивает.
2) Веб разработчиков все устраивает
Отучаемся говорить за всех.
sshikov
29.09.2017 21:47Берёшь Babel — и практически все проблемы с JS закрыты.
Ну да, щаз. Это вам никогда видимо не приходилось пытаться запускать поделки на JS не в той среде, в которой ожидает автор. Т.е. не в браузере и не в ноде. А такие бывают, поверьте.
jakobz
30.09.2017 14:09>Берёшь Babel — и практически все проблемы с JS закрыты
В какой-то момент, фронтендеры решили что JavaScript настолько ущербный, что лучше в него какой-нибудь другой язык компилировать, чем на нем писать. Можно было выбрать любой язык. И что же они выбрали? JavaScript 6!userphp1024
02.10.2017 22:52В какой-то момент, фронтендеры решили что JavaScript настолько ущербный, что лучше в него какой-нибудь другой язык компилировать, чем на нем писать. Можно было выбрать любой язык. И что же они выбрали? JavaScript 6!
Не вижу ничего в этом плохого, теперь я трачу на 0.05s больше, раньше я просто нажимал CTRL+S, теперь мне надо подождать 0.05s :)
Конечно я был бы рад что бы все это было из коробки, подождем лет 5, возможно появится.
Я вижу плохое в JS то, что он слабый и не удобных для больших приложений, таких как WEB Photoshop или WEB AutoCAD:(
И мы разрабатываем WASM, он позволит нам нанять лучший С++ программистов, которые создают критические участки кода для web Photoshop
Кого напрягает JS? А никого, он устраивает бизнес и конечных пользователей, он напрягает только горстку C# разработчиков, которые теряют позиции на рынке, никому не нужен десктоп.
Но у всех на хабре появилась надежда в WASM, многие считают что он убьет JS, но вот что будет (впечатлительным C# разработчикам не читать):
Предположим что будет все по вашему, все языки мира создали свой фреймворки, которые переводят их код в байт-код(WASM).
Вы думает только С /С++ такие умники? этого захотят все топовые языки в мире.
К чему это приведет: Распад рынка на 10 секторов. Представим что у всех равная доля, представим что часть JS-программистов пересели на С++, часть на C#.
А еще Python подтянется, далее PHP программисты начнут пилить FRONTEND На PHP (да, будут все пилить костыли в виде фреймворках, С++ можно а нам нельзя что ли? мы тоже хотим на фронте писать на своем любимом языке)
denismaster
02.10.2017 23:09+3Хватит гнать на C#-разработчиков. У вас словно травма из детства, в каждом комментарии упоминаете. Вас обидели как-то?
userphp1024
02.10.2017 23:47C# Разработчики гонят на JS разработчиков.
На хабре от С++, PHP, JAVA разработчиков не слышно говнf в сторону JS.
Вот и весь секрет.
Не нужно быть психологом, что бы понимать почему они это делают.
JS не лезет в драйвера, контроллеры и банковский сектор, но JS лезет в средний бизнес, там где обосновался C# разработчик.
Смотрю никакие контр-аргументы не стали писать, надеюсь я вас убедил что никакие WASM не свергнут JS :)
denismaster
03.10.2017 01:03Не устраивает только Java и C# программистов, потому что их рынок пытаются занять выскочки из JavaScript области.
И штук 10 еще таких цитат в основном вашего авторства. Вы сами себе противоречите, говоря только о C#.
На хабре от С++, PHP, JAVA разработчиков не слышно говнf в сторону JS.
Вот и весь секрет.
Пруфы? На хабре принято использовать аргументы. А про языки — нет идеального языка. PHP стал источников мемов, JS странный и далек от идеала, С++ монстр во плоти, а а Шарп это лазерная пушка, которая не работает без ослика.
Не нужно быть психологом, что бы понимать почему они это делают.
JS не лезет в драйвера, контроллеры и банковский сектор, но JS лезет в средний бизнес, там где обосновался C# разработчик.
C# можно много где использовать — банки, энтерпрайз, хайлоад, десктоп и т.д. Тут JS-у до него ой как далеко. Упадок C# на десктопе связан не с JS, а с общим умиранием десктопа.
Ах да, есть еще Unity и игры. И что-то как-то там C++ и C# правят балом, а не JS.
Смотрю никакие контр-аргументы не стали писать, надеюсь я вас убедил что никакие WASM не свергнут JS :)
WASM — посмотрим, что за зверь, пока что выглядит незрело.
А JS свергать не надо, отличный язык для задачи придания интерактивности на HTML-страницах) Пусть и остается им))
Я уже выше писал про новые стандарты приложений. Они — лучший путь, чем WASM или HTML+JS
jakobz
29.09.2017 00:46+3Ты все правильно пишешь, но проблема — в другой плоскости. У нас сейчас есть единственный работающий стандарт чтобы делать приложения, которые более-менее везде запускаются. И этот стандарт такой, что:
— писать эти приложения очень дорого. Что-то примерно 10x по баблу, против Delphi 7, наверное. Т.е. для приложений веб — отвратителен.
— реализовать этот стандарт, по-факту, могут две конторы в мире — Microsoft и Google. Есть только две работающих реализации. Победи одна — и будет нам полное и безоговорочное самодурство одной конторы. А Google что-то не сильно интересно, чтобы было удобно делать на вебе приложения. Реклама крутится, бабло мутится. Нет ни у кого 100500 баксов чтобы написать что-то лучше Gmail? Ну и хорошо, Google это вполне устраивает.
Да, можно поверх веба поверх собрать POC на WebGL. Но это будет лагать, геморройно по тулам, и канет в лету. Нужна реализация с нуля, чтобы ничто не мешало. Как минимум — как выхлоп для кучи идеалистов, которые сейчас делают всякие ReactOS. Будет источник идей, будет фонтан идей, в который можно кунать авторов очередного border-radius или flexbox.
Короче, я считаю, что хайп тут — в тему. Надо всем миром замутить проект «веб X.0 с нуля» — пусть он не выстрелит, и вообще пусть будет вечным, и будет раскалываться на ветки. Но что-то должно быть, что конкурирует с вебом.RPG18
29.09.2017 11:58Да, можно поверх веба поверх собрать POC на WebGL.
Это лишнее. У нас C++ код на WebGL+Wasm работает без всяких POC.
staticlab
29.09.2017 06:59А с остальным — заменой для CSS/HTML, accessibility, индексированием, и прочим всем — вполне можно по ходу дела разбираться, добавляя стандарты и библиотеки.
То есть сначала спроектируем всё без учёта поиска и accessibility, а потом, когда стек станет популярным и обратную совместимость ломать будет уже поздно, начнём сбоку прикручивать эти фичи?
indestructable
29.09.2017 12:45+1Были джава-апплеты. Не судьба. Был Сильверлайт. Был ActiveX. WPF в браузере. Даже Флеш — и тот отходит.
А отвратительный, старый, небезопасный веб, с ужасным Джаваскриптом, с пол-гигов памяти на вкладку — живет.
Делать интерфейсы как в играх — можно с бюджетами, как в играх. Впрочем, их можно в вебе делать и сейчас — да никто не делает. Потому что все описанное в статье — хорошо как теория, как идеальная картинка, но не как решение тех проблем, которые решает веб.
andreymal
28.09.2017 18:18+1Мне тут давно думается, что ненавистников стека «веб-технологий» уже достаточно много, чтобы собраться и запилить нормальную альтернативу, хотя бы прототип в качестве эксперимента)
zugo
28.09.2017 18:23+1Если создателем альтернативы будет не гугл — она обречена быть никем не замеченной.
vil996
28.09.2017 19:19А где же плюсы??? Статью написал явно «true» кодер, который явно плохо знаком с интернет технологиями. Развитие WEB хоть и очень стремительное, но относительно новое. Сегодня все интегрируется так или иначе именно с этой средой.
ExplosiveZ
28.09.2017 19:35+1Проблема не в web как явлении, проблема в стеке технологий. Проблема в том, что сейчас весь этот стек пихают куда попало. Backend, desktop приложения, мобильные приложения.
Но точка кипения еще не достигла апогея, да и явные косяки пытаются прикрыть ширмой из webassembly.RPG18
28.09.2017 19:43пытаются прикрыть ширмой из webassembly.
Можно пример?
ExplosiveZ
28.09.2017 20:18+1Производительность же.
Появление первых транскомпиляторов в JS должно было стать звонком тому, что пора что-то делать с JS, а не добавлять костыли. Сейчас например изучают не основы JS, а какой-нибудь модный framework.
Нужно не всё выбрасывать, а 1 раз просто взять и исправить.
Например вместо JS внедрять тот же Dart, вместо websocket использовать нормальные сокеты.
Использовать для тяжелых задач настоящие потоки.
HTML/CSS сериализовывать в бинарный поток данных(на клиенте десериализовывать обратно), чтобы гонять меньше трафика.
Это можно начать делать прямо сейчас, без кардинальных изменений в самих web-сайтах, но всем пофиг, лучше будет написать очередную статью про то, какой web плохой.RPG18
29.09.2017 00:32WebAssembly не про это. WebAssembly это возможность запускать код на таких языках как C,C++,Rust в браузере. История начинается с Поддержка Portable Native Client появилась в Chrome. Кто победит в гонке за нативным быстродействием — PNaCl или Asm.js?
wert_lex
29.09.2017 00:41-1Что вы там на нём пишете? Куда ещё производительнее? https://habrahabr.ru/post/281879/
vil996
29.09.2017 12:38Чувак ты понимаешь что исправления как ты говоришь «явных ошибок» невозможно не потому что разрабам лень это делать, а потому что с учетом этих багов и недостатков построен весь веб?
imanushin
28.09.2017 20:31+1Проблема в том, что сейчас весь этот стек пихают куда попало.
А что в этом плохого? Если есть конкуренция, то выживает тот, который больше подходит покупателям. Иначе всё равно будет неудобный продукт.
ExplosiveZ
28.09.2017 20:44+1Дело не в потребителе. С зоопарком нам приходится работать, потребителю вообще пофиг, как там всё внутри работает.
sitev_ru
28.09.2017 20:25+4Вот ещё в тотже огород))
habrahabr.ru/company/hexlet/blog/303754
Алан считает Интернет, протоколы TCP/IP, интерпретаторы LISP, Nile (Math DSL for Vector Graphics) и OMeta (OO PEG) (PDF) примерами элегантного софта с минимальным кодом.
Он называет Интернет (TCP/IP) одним из немногих масштабных софтверных проектов, который был правильно разработан, и его уровень сложности — в балансе с уровнем комплексности (complication vs. complexity). Этот проект, в котором меньше 20 тысяч строк кода, работает как живая, динамическая система, способная поддерживать миллиарды узлов, и она ни разу не отключалась после первого запуска в сентябре 1969 года. Мы просто перестали считать Интернет нормальным софт-проектом, созданным людьми:
Интернет разработан настолько хорошо, что многие относятся к нему как к естественному ресурсу, вроде Тихого океана, а не к плоду человеческого труда. Когда в последний раз мы видели настолько стабильную, четкую технологию без ошибок?
Для сравнения, Веб это ерунда. Веб создан дилетантами.
geekmetwice
28.09.2017 22:37-3Интернет разработан настолько хорошо, что...
… что из рук вон плохо! Ключ: IPv4, IPv6. :)
sumanai
29.09.2017 18:16и она ни разу не отключалась после первого запуска в сентябре 1969 года.
Глобально да. Локально же проблем у интернета куча, начиная с DDos и заканчивая отключением его диктаторскими режимами.
alsii
04.10.2017 18:25Интересно, если бы дилетанты не создали веб, сколько миллиардов узлов было бы сегодня в Интернете?
vbif
28.09.2017 21:30Но UI, который вы видите вверху, по сложности довольно похож на UI, который вы видите внизу
И ведь это замечательно! Перегруженные интерфейсы, да ещё и с кучей визуальных эффектов — не то, к чему стоит стремиться.staticlab
28.09.2017 21:47Но вот если начнётся мода на Wasm + WebGL, то, боюсь, нас ждёт ещё одна волна дизайнерских "флешесайтов".
userphp1024
29.09.2017 11:20Этого никогда не будет.
Поисковики как будут распозновать текст?staticlab
29.09.2017 11:37Поисковики как будут распозновать текст?
Судя по комментариям, вебохейтерам всё равно. Главное, чтобы не было HTML и JS, а там хоть трава не расти. "Как нибудь потом" разберёмся с этой проблемой.
claygod
29.09.2017 23:23Сначала вернутся каталоги, а потом придумается что-то новое.
userphp1024
03.10.2017 00:06-3это отскок на 10 лет назад, а все для чего? чем вас не устраивает сайтики которые используют JS? Потому что какой-то долб** сказал что у него хром использует 2 гб оперативки? Так пусть выберет браузер, который выгружает сайт из памяти при снятии фокуса и закрытии вкладки и будет тебе счастье, это идиоты, которые даже не знают как работает браузер и интернет в целом.
Всегда есть альтернативы для бомжей, у которых нет 8 гб оперативки в 2017 году.
Photoshop last -> paint
Word 2017 -> nodepade
Google maps -> бумажная карта
kekekeks
29.09.2017 12:01Был небольшой период времени, когда была мода на новые SPA уже была, а пререндеров нормальных ещё не завезли (да их и сейчас не всегда можно использовать, если у вас фронт запускается несколько секунд). Индексация лечилась посредством тега
<noscript>в который сервер лил plaintext-содержимое. В принципе, вполне себе работало и нормально жевалось яндексом и гуглом.userphp1024
29.09.2017 17:18Это работало, такие сайты будут индексироваться.
Но они не будут продвигаться, почитайте что важно для SEO и как работают алгоритмы поисковиков.
Нужно будет менять всю политику поисковиков.
вы можете хоть сегодня написать фреймворк, который генерирует интерфейс на webGL, без единого DOM элемента, но это никому не нужно.
Wargamer
28.09.2017 21:49А я считаю что положение вещей вполне нормально: JavaScript исполняется на всех платформах, мы получили способ создания и доставки лёгких, кроссплатформенных приложений с широчайшим спектром возможностей. Другое дело что множество инструментов, дающих слабоподготовленному программисту возможности, которые присущи опытному, тупиковые или накладывающие ограничения. Я хочу сказать, что наиболее дальновидными являются сами разработчики языков JavaScript, PHP, а не те, кто утверждает что их фреймворк решает корявость языка. И почему ExtJS не упомянут?
Wargamer
28.09.2017 21:58Вообще, сетевые приложения обязаны быть бронетанковыми и это уже требует многого от программиста.
ExplosiveZ
28.09.2017 22:12Java даже на кофеварках запускается. Просто на js легче всего начать, а вот продолжить…
andreymal
28.09.2017 22:23Java тоже исполняется на всех платформах,
BASIC тоже исполнялся на всех платформах...)
Wargamer
28.09.2017 23:09В рамках объектной модели гипертекстового документа, разумеется. Лично я в восторге от Linux Mint, там тоже есть работа приложений без установки )) Я уверен, что будущее за OpenSource и конечно за Android
Wargamer
29.09.2017 00:53А вы знаете, если допилить к JVM управляемую песочницу, где можно было бы выставить разрешения программы, организованные иерархически, тогда можно было бы вообще использовать большинство системных ресурсов. При запуске, знакомитесь со списком, как в Android, при необходимости запрос… На сегодняшний момент SceneBuilder решает многие задачи UI.
ExplosiveZ
30.09.2017 11:44SecurityManager в Java делает это со времён java 1.0
Wargamer
30.09.2017 12:06The security manager is a class that allows applications to implement a security policy. It allows an application to determine, before performing a possibly unsafe or sensitive operation, what the operation is and whether it is being attempted in a security context that allows the operation to be performed.
Я говорю о другом.
Развитие Java было сопряжено с развитием веб. В виде дополнения к браузеру Java получил широкое распространение, но производители браузеров не позволят дополнению компрометировать себя. Как самостоятельные web-приложения (приложения, которые используют веб) JAR не могут заслужить доверия, так как доверять можно только с некоторой долей понимания намерений. В Android и GooglePlay реализовано неплохое решение, можно лучше, можно сделать песочницу с затычками для портируемых пакетов, можно сделать обучаемую систему защиты как AppArmor, чтобы было понятно, удобно и без палева.
Хочу предложить…Wargamer
30.09.2017 12:17А что до iOS, то если гора не идёт к Магомету, то пусть Магомет подвинет рекламу поближе к горе
ExplosiveZ
30.09.2017 12:58Гора текста и ничего не понятно. Вам бы романы писать.
Цитирую:
А вы знаете, если допилить к JVM управляемую песочницу, где можно было бы выставить разрешения программы[...]
Всё это делает SecurityManager.
izzholtik
29.09.2017 02:22-3Господи, сделай так, чтобы андроид не стал системой будущего. Он же абсолютно чудовищен.
TheOleg
29.09.2017 10:43Как мне на iOs исполнить Джаву?
kekekeks
29.09.2017 12:03Берёте Xamarin.iOS, берёте IKVM, перегоняете JVM-байткод в MSIL, собираете, работает. С отладчиком, правда, проблемы. Ну или robovm взять, там вроде как ещё какая-то жизнь теплится.
TheOleg
29.09.2017 19:26И это делать каждому, кто хочет мою программу запустить? Или подразумевается что вместо собственного сайта, я должен буду под Apple подстраиваться и платить им? А потом так же всё под андроид переделывать и под WP и просто Windows?
Ну это же совсем не сравнимо с JavaScript.
Foxcool
29.09.2017 00:40-3У меня тоже есть некоторые претензии к вебу, но несколько иного характера t.me/darkfox_info/9
Wargamer
29.09.2017 10:33info.cern.ch/Proposal.html
www.jcp.org (что это?)
Есть те, кто способны проворачивать такие инициативы =) А?
prodavecmacdonalds
29.09.2017 12:16Все смешалось в доме бывшего гуглатора и кони, и иконки, и буфер… Несомненно, вебер приложения ещё далеко от идеала, но весы плюсов и минусов не дремлют, например, веб приложения лучшее решение для кроссплатформенных приложений, а это многого стоит.
snuk182
29.09.2017 16:07+3Здесь столько комментариев уже, но до сих пор нет того самого, про единственно верное решение.
mike_y_k
29.09.2017 17:04Все в исконных традициях. Попытка ответа на вопрос «Кто виноват» состоялась.
Теперь осталось дождаться «Что делать?».
Ну а потом появятся труды основоположника.
История таки по спирали развивается.
Ждем-с.
VovanZ
29.09.2017 21:12+2Разработчики любят писать веб-приложения по одной причине — ожидания пользователей от таких приложений исключительно низки.
Это глупость. Я и как разработчик, и как пользователь люблю веб-приложения по двум причинам:
- Не нужно устанавливать, работает сразу. На этом шаге отваливаются очень много потенциальных пользователей. Нужно иметь сильную мотивацию запустить именно это приложение, чтобы пройти через процесс установки.
- Работает везде, а не только на любомой платформе разработчика. И на линуксе, и на мобилках, везде. Десктопные приложения, как правило, делаются под одну самую распространённую платформу, а все остальные сосут лапу. Кросплатформменность / портирование увеличивает стоимость разработки в разы.
zugo
29.09.2017 22:571. Зато, зачастую, нужно регистрироваться, что нивелирует разницу во времязатратах. Да и установка приложения из «магазина приложений» на современных мобильных платформах ничуть не сложнее, чем заход на сайт.
2. Единственное реальное преимущество. Но что, гипотетически, мешает создать нормальную «платформу приложений» (с нормальным языком разметки UI и нормальными протоколами обменами данными) вместо браузера?staticlab
29.09.2017 23:15Да и установка приложения из «магазина приложений» на современных мобильных платформах ничуть не сложнее, чем заход на сайт.
Вчера как раз понадобился сканер штрихкодов на андроид. А в требованиях просят чуть ли не доступ к контактам и переписке. Так что тут в разрезе веба скорее регистрация через соцсеть с доступом к списку контактов.
VovanZ
30.09.2017 01:50Да и установка приложения из «магазина приложений» на современных мобильных платформах ничуть не сложнее, чем заход на сайт.
Во-первых, это дольше.
Во-вторых, никто не будет устанавливать всё подряд, просто посмотреть, потому что это установленное приложение потом будет занимать место на устройстве и в списке приложений.
В-третьих, мобильные приложения хотят всяких разрешений. Иногда — непонятно, зачем.
Но что, гипотетически, мешает создать нормальную «платформу приложений» (с нормальным языком разметки UI и нормальными протоколами обменами данными) вместо браузера?
То, что ей никто не будет пользоваться, очевидно.
userphp1024
29.09.2017 23:14+1Гиблое дело эти «сайты-бинарники», пуканы начали гореть, потому что JS начал лезть в мобильную разработку, серверную, отбирают чужой хлеб негодяи, 5 лет назад никто не жаловался на JS, никому никакого дела не было до того что в вебе все плохо.
Самое забавное вот что: C#/java программисты переживают за душевные страдания веб разработчиков, они искренне недовольны что в вебе все плохо. Переживают за чужой мозг, что бедным веб разработчикам приходится так напрягаться на работе.
Кому не нравится стандартный JS берут что-то вроде react/angular и прикручивают TS/flow
Меня устраивают, если ты хочешь разрабатывать не веб приложения, то тебе вообще закрыта дорога в веб, бери C++ и пиши драйвера, делай мир лучше.
spmbt
29.09.2017 23:46+1> Выскажите мнение, что Macromedia Flash хорош — и у вас могут отобрать удостоверение гика.
Хороший оборот речи. Кто бы мог показать образец такого удостоверения? А то нашлось не совсем то, однофамилица.
OlegYch_real
30.09.2017 03:25+2честно говоря я удивлен что подобные статьи начали выходить только сейчас
вроде очевидные вещи, но люди продолжают писать о том как прекрасен яваскрипт и рест
вот интересная концепция в плане их замены unisonweb.org
Wargamer
30.09.2017 10:08-1Если вы убьёте веб, я с вами не знаю что сделаю
userphp1024
30.09.2017 17:26+1Не убьют, скорей начнут убивать JS разработчиков, которые отбирают хлеб у C# разрабов.
95% задач на рынке — это примтивные задачи для работы с формами, данными, графиками.
JS на ура справляется с этими задачами.
Это выгодно работодателям, 1 разработчик разрабатывает приложения под все системы.
Повторюсь, 95% задач на рынке — примитивные, никто из присутствующих тут не работает с 100000 строчек данных, 3D моделями для игр и прочая сложна фигня.
React native, electron? js — идеально справляется с 95% задачами без просадки скорости.
Слабое место всегда — БД.
evseev
30.09.2017 12:51-1Еще с самого начала статья мне показалась подозрительной когда речь зашла о древнем уже сейчас офисе. 75МГц и 32MB. Ну ок. Открыл гугл документ. Посмотрел в Activity Мonitor (Мас), что процесс использует 300 МБ оперативной памяти и 4% CPU. Процессор 1.6GHz. С точки зрения CPU ничего не изменилось. Памяти отожрало. Признаю. Но с учетом того, что открытый документ лежит на расстоянии тысяч километров от меня и что бы мне было комфортно с ним работать нужно его все-таки буферизировать. А как Office 2k работал с облачными документами и сколько он при этом потреблял памяти? Что-то я уже не припомню ;)
Но давайте все-таки задумаемся вот про что. 300МБ оперативки в 2017 и 32МБ в 2000. На сколько это больше? Если мне не изменяет память, то 32МБ это была _вся_ оперативка на среднем компе. 64МБ- это было очень даже хорошо. А 128МБ — это просто восторг. А что сейчас? 2GB это комп- смотрелка интернета. 4GB- разумный минимум если вы хоть что-то собираетесь делать. А так 8-16GB- самое то. Не знаю как вам, а мне кажется, что 300МБ это значительно меньше, чем 32МБ ;)
Но статью я все-таки дочитал. Похоже автор так и не понял, что можно не выбирать, а использовать все имеющиеся технологии одновременно. И как мимо него прошла та же Java ума не приложу.andreymal
30.09.2017 13:51Но с учетом того, что открытый документ лежит на расстоянии тысяч километров от меня
Это учитывать глупо и бессмысленно. Достаточно скачать файл с облака один раз во временную папку на жёстком диске, а дальше можно работать с ним как с локальным. Ну, может, периодически подгружая позиции курсоров других пользователей и диффы при совместном редактировании. Но ничего из этого не требует трёхсот мегабайт оперативы.
4GB- разумный минимум если вы хоть что-то собираетесь делать.
Всё то, что делает среднестатистический пользователь, можно уместить в полгига при желании, если не говнокодить и не обмазываться лишними абстракциями. Кроме игр, виртуалок и гигантских слоёв в фотошопе разве что, но это отдельные истории, им оператива нужна по уважительным причинам.
Wargamer
30.09.2017 13:56
Druu
30.09.2017 15:25> Всё то, что делает среднестатистический пользователь, можно уместить в полгига при желании
А зачем?andreymal
30.09.2017 15:29Чтобы оставшиеся семь с половиной гигов оставить для чего-нибудь действительно полезного? Для тех же слоёв в фотошопе, например. Или для рендеринга тяжёлой 3D-сцены, если юзер этим увлекается/зарабатывает. Или вот у меня на ноуте MySQL-реплика и две усердно трудящихся виртуалки постоянно запущены, при этом иногда фаерфокс иногда умудряется уделывать по потреблению памяти их всех сразу :\
evseev
30.09.2017 15:41Это у среднестатического пользователя все должно быть? Ну видео и фото я обрабатываю, дочка в Maya ковыряется, У жены MySQL крутится. Ну и без виртуализации то же никак. Ура! Я понял. У нас вся семья среднестатическая.
Но есть одна нескладушечка. У нас на всех компах 16GB памяти и не могу сказать, что ее всегда хватает. По вашим словам мы должны как-то в 0.5 GB помещаться. Получается не стараемся?
Druu
30.09.2017 16:29> Чтобы оставшиеся семь с половиной гигов оставить для чего-нибудь действительно полезного? Для тех же слоёв в фотошопе, например. Или для рендеринга тяжёлой 3D-сцены, если юзер этим увлекается/зарабатывает.
Так оставляйте, в чем проблема?andreymal
30.09.2017 16:35В том, что приложения для среднестатического пользователя их не оставляют. Я хоть и не среднестатистический пользователь, но приложениями для среднестатистического пользователя тоже ведь пользуюсь. Представим на минутку, что никто ничего не оптимизирует: вот гуглдоки полгига кушают, вот мессенджер полгига кушает, вот скайп отожрал целый гиг, там плеер ещё сотню-другую мегабайт подворовывает, торрент-клиент решил закэшировать все файлы в оперативе по максимуму без спроса, с десяток вкладок с рецептами.ру ещё гигабайт-другой просят… Вот так по чуть-чуть по чуть-чуть — и всё, от восьми гигов почти ничего и не остаётся. Даже простенькую 3D-игру запустить уже некуда, не говоря уже про фотошопы и рендеринги. Приходится половину приложений выключать, чтобы освободить память для текущей задачи…
… ой, кажется мы случайно деградировали до однозадачного DOS. Приехали.evseev
01.10.2017 09:20А с чего вы вообще взяли, что приложения не оптимизированы? Они оптимизированы. Просто критерием оптимизации при разработке выбраны не количество потребляемой оперативки, а другие параметры.
andreymal
01.10.2017 12:56Какие же? Производительность? Нет, тот же скайп тормозит. Удобство? Так обрезаны все возможности подстройки под мои личные потребности, даже системная тема не используется (редкие исключения типа VS Code это исключения). Так какие же?
Druu
01.10.2017 09:28> Вот так по чуть-чуть по чуть-чуть — и всё, от восьми гигов почти ничего и не остаётся. Даже простенькую 3D-игру запустить уже некуда, не говоря уже про фотошопы и рендеринги.
Зачем вам месенджер и скайп, когда вы играете в «простенькую 3д-игру»?
> … ой, кажется мы случайно деградировали до однозадачного DOS.
Во времена ДОС вы бы запустили одно приложение и не булькали бы. В 2017 вы держите активные месенджер, скайп, проигрыватель, браузер с миллионом открытых вкладок, торрент клиент, еще что-то там по чуть-чуть, а потом жалуетесь, что у вас рендеринг тормозит. И проблема-то не в скайпе, проблема в жручем рендеринге. Вот его пусть и оптимизируют, чтобы не отбирал память у скайпа.andreymal
01.10.2017 13:01Зачем вам месенджер и скайп, когда вы играете в «простенькую 3д-игру»?
Капитан Очевидность замечает, чтобы получать входящие сообщения и звонки и прервать игру по необходимости.
И проблема-то не в скайпе, проблема в жручем рендеринге.
На этот бред даже не буду пытаться отвечать. Может, какой-нибудь оскорблённый тридэшник вам позже ответит.
evseev
30.09.2017 15:33-1Это учитывать глупо и бессмысленно. Достаточно скачать файл с облака один раз во временную папку на жёстком диске, а дальше можно работать с ним как с локальным. Ну, может, периодически подгружая позиции курсоров других пользователей и диффы при совместном редактировании. Но ничего из этого не требует трёхсот мегабайт оперативы.
У меня комп есть на работе. Если быть точным, то у меня их 3, но сейчас это не так важно. У меня дома то же есть компы. Тех, с которых я открываю документы 4. Есть телефон. И с него я то же открываю документы. Вы предлагаете мне скачать на все мои устройства все мои документы? И так же предлагаете сделать всем членам моей семьи? У дочки там совсем не много. Относительно. А вот у жены 3 облачных пользователя. Два из которых — корпоративные фактически без ограничения места. И ее работа- документы. Глупо и бессмысленно? Серьезно?
Может быть вы имели ввиду качать по одному? Текущему? Даже у меня есть разные документы, а не очень много с ними работаю. Есть таблички, где нет и 100 строк, а есть и по 1500 страниц с таблицами, формулами и рисунками. Их то же качать? Полностью? Даже если я открою страницу 307 и может быть дойду до 308? А если я в дороге и работаю через мобильный интернет. Я даже не буду говорить, что он не дешев. Он медленный. Думаете разумно ждать возможно и несколько минут только для того, что бы скачать документ целиком?
Вы представляете сколько нас таких у Google, MS, Dropbox и многих других, кто хочет иметь доступ к своим документам? Интернет гиганты тошнят на различные комитеты, что они заголовок сделали длинный, а вы предлагаете документы целиком качать? Серьезно?
Что бы редактировать текст в простейшем редакторе много не нужно. Но вы ведь так не делаете? И я то же. Мы ведь хотим что бы наш документ был красивым. С хорошими шрифтами и красивой графикой. Хотим что бы редактор исправлял ошибки, что бы он на лету менял стили. И вот это уже требует места.
Всё то, что делает среднестатистический пользователь, можно уместить в полгига при желании, если не говнокодить и не обмазываться лишними абстракциями. Кроме игр, виртуалок и гигантских слоёв в фотошопе разве что, но это отдельные истории, им оператива нужна по уважительным причинам.
Я все хочу выяснить кто такой этот среднестатический пользователь. И еще более непонятно чем он должен заниматься. В моей семье все совсем не среднестатические. Я как вы выражаюсь говнокодю, жена вообще математик. На ее компе уже вторые сутки моделирование идет. Может быть мой ребенок потянет. Хотя в последний раз когда мы были в магазине электроники мы от нечего делать на витринном ноуте написали однострочник на питоне (я придумывал, дочка реализовывала), который потребовал 57GB оперативки. Это получается, что дочка моя не среднестатическая на 56,5 GB?
Может быть вы расскажите как «не обмазываться лишними абстракциями»? Сейчас оно как-то само по себе получается. Ты тыкнул в ярлычек, а оно как-то все само, само.andreymal
30.09.2017 15:41Вы предлагаете мне скачать на все мои устройства все мои документы?
Не надо доводить до абсурда, это должен делать онлайн-редактор автоматически при открытии документа. А при закрытии или отсутствии свободного места удалять, оставляя лишь сохранённую копию в облаке. Между прочим, именно так любой кэш любого браузера и работает.
Даже если я открою страницу 307 и может быть дойду до 308?
И ещё раз: не надо доводить до абсурда, грамотно организованный онлайн-редактор может скачать только нужную часть документа. И всё это по-прежнему не требует трёхсот мегабайт оперативы, даже наоборот — скачивание документа по частям позволяет эту самую память экономить.
Ты тыкнул в ярлычек, а оно как-то все само, само.
Это не имеет никакого отношения к абстракциям. То же самое можно написать хоть на голом x86 ассемблере без абстракций. И, думаю, оно потребляло бы мегабайт десять оперативы при схожем с гуглдоком функционалом. (Только этого делать никто не будет, потому что слишком сложно, поэтому делают абстракции для упрощения, но в 2017 году абстракций стало СЛИШКОМ много.)
На остальной коммент отвечать не буду, так как он весь состоит из таких доведений до абсурда.
Druu
30.09.2017 16:35> Не надо доводить до абсурда, это должен делать онлайн-редактор автоматически при открытии документа. А при закрытии или отсутствии свободного места удалять, оставляя лишь сохранённую копию в облаке. Между прочим, именно так любой кэш любого браузера и работает.
Вы, кажется, забыли, что оперативная память работает быстрее, чем жесткий диск. По-этому если что-то можно хранить в оперативной памяти — оно должно храниться в оперативной памяти. Я покупал 16гб оперативки именно для того, чтобы они были заполнены, это позволяет приложениям работать быстрее. Ну а у тех, у кого памяти мало — те, да, пусть сбрасывают на жесткий диск — к слову, для этого есть файл подкачки и работает он автоматически. Но делать это (использовать жесткий диск) надо в том и только в то случае, когда памяти нет. Не когда ваше приложение ее много занимает — а когда оно пытается занять больше, чем есть.andreymal
30.09.2017 16:40Вы, кажется, забыли, что операционная система самостоятельно автоматически кэширует активно используемые файлы с жёсткого диска. Не надо пытаться решать несуществующие проблемы. Вы молодец, что купили 16гб оперативки — ОС их будет активно использовать. А приложения не должны без крайней необходимости.
Druu
30.09.2017 16:49> Вы, кажется, забыли, что операционная система самостоятельно автоматически кэширует активно используемые файлы с жёсткого диска.
Во-первых, она очень плохо кеширует (даже винда, с линуксом вообще боль и печаль, к слову — именно хреновым системным кешем объясняется большинство тормозов браузеров), во-вторых — кеш приложения будет заведомо быстрее, так как работает напрямую, без прослоек.
> А приложения не должны без крайней необходимости.
Именно что должны. Выбирая между браузером, который при включении грузит 10гб кеша и браузером, который укладывается в компактные полгига — я (да и любой среднестатистический пользователь) всегда выберет первый. Потому что повышенное потребление памяти заметить нельзя, а вот повышение быстродействия — будет налицо.
Ну и да, если вы уж ратуете за десктопные технологии против веба — давайте вспомни про jvm, которая по дефолту вообще не отдает освобожденную память системе (чтобы потом не пришлось ее опять запрашивать).andreymal
30.09.2017 16:59Во-первых, она очень плохо кеширует
Ничего подобного ни в одной из используемых мной систем ни на одном из используемых мной компьютеров я не наблюдал. Даже проводил несколько экспериментов: искусственно забивал всю оперативу, чтобы кэш вычистился, потом освобождал — система тупит ещё несколько минут, пока очищенный кэш не прогреется снова, а потом всё норм. Склонен считать, что в ваших случаях ОС кэширует плохо, потому что оперативу уже заняли приложения и кэшировать тупо некуда :)
выберет первый
А я нет. Дайте мне право выбора, сволочи! Где волшебная галочка «экономить память» в каком-нибудь браузере? Почему все всё решают за меня?
повышение быстродействия — будет налицо.
Не спорю. А что если я не хочу быстродействия? Я хочу оставить браузер открытым, чтобы он был «в шаговой доступности», но не хочу, чтобы он занимал память, потому что я, например, сейчас играю в игру, которой память нужнее. И вот здесь этот ваш своп, кстати, не помогает: как только доходит дело до его использования, тупить и лагать начинает абсолютно всё. В тяжёлых случаях браузер приходится всё-таки закрывать, лишь бы своп не юзался.
если вы уж ратуете за десктопные технологии против веба
Замечу, что за jvm я не ратовал
jvm, которая по дефолту вообще не отдает освобожденную память системе
И от этого мне тоже временами хочется плакать. По возможности избегаю всё связанное с jvm.
Druu
30.09.2017 19:13> Ничего подобного ни в одной из используемых мной систем ни на одном из используемых мной компьютеров я не наблюдал.
Вы, видимо, из параллельной реальности. ОС никогда не сможет качественно кешировать данные, т.к. это невозможно сделать, если неизвестно, что это за данные и как они используются. Условное приложение такой информацией о своих данных обладает, ОС — нет.
> А я нет. Дайте мне право выбора, сволочи! Где волшебная галочка «экономить память» в каком-нибудь браузере? Почему все всё решают за меня?
Это рынок. Подавляющее большинство пользователей хочет функциональные, быстрые, красивые программы. А на то, что в диспетчере задач там будет указано высокое потребление памяти — этим пользователям плевать, они этого никогда не узнают. Если вы хотите использовать тормозные браузеры «зато память не жрет» — ну разрабатывайте такие браузеры, или финансируйте их разработку.
> Не спорю. А что если я не хочу быстродействия?
Вы мазохист? Ну купите компьютер послабее. Снимите лишнюю оперативку, оставьте 2гб. Или лучше 1гб. И наслаждайтесь.
> И вот здесь этот ваш своп, кстати, не помогает: как только доходит дело до его использования, тупить и лагать начинает абсолютно всё. В тяжёлых случаях браузер приходится всё-таки закрывать, лишь бы своп не юзался.
Так вот лагать начинает как раз от того, что используется жесткий диск вместо оперативной памяти. И вы сейчас предлагаете сделать так, чтобы лагало подобным образом ВСЕ, ВСЕГДА И ВЕЗДЕ, а не только тогда, когда память закончилась. Извините, но когда я покупаю оперативную память для компьютера, то я хочу чтобы не тормозило, а не чтобы все работало так,, будто этой памяти в 6 раз меньше чем по факту есть в системе.
> И от этого мне тоже временами хочется плакать.
От того, что приложения тормозят меньше, чем могли бы? Почему вы хотите использовать медленные приложения вместо быстрых?sumanai
30.09.2017 19:43ОС никогда не сможет качественно кешировать данные, т.к. это невозможно сделать, если неизвестно, что это за данные и как они используются.
А что и зачем ей знать? ОС кеширует файл блоками, блоки используются- они в кеше, блоки не используются- они выгружаются в файл или подкачку. Можно уточнить при открытии стратегию кеширования, например для последовательного чтения, когда первые прочитанные блоки будут вытесняться из кеша как ненужные.Druu
30.09.2017 21:14> А что и зачем ей знать?
Знать характер данных и то, как они используются программой.
> ОС кеширует файл блоками, блоки используются- они в кеше, блоки не используются- они выгружаются в файл или подкачку.
И именно по-этому эффективность кеша ОС очень низкая.
sumanai
30.09.2017 21:52Знать характер данных и то, как они используются программой.
Если вы не знали, то сообщаю, что в менеджере памяти по крайней мере Windows есть эвристические механизмы, которые заранее загружают в кеш данные, которые скорее всего потребуются. Например, при чтении файла последовательно, или каждые х блоков. Уверен, что в Linux и MacOS имеются аналогичные механизмы.
Если же приложение читает случайные данные, то оно и само не сможет заранее предугадать, что ему нужно.
Плюс я уже написал, что характер использования файла можно указать при его открытии. Кто же виноват, что большинство программистов указывают дефолтные параметры из справки, затормаживая свою программу и забивая кеш ненужным хламом? Впрочем, ОС с этим вполне успешно борется.Druu
30.09.2017 23:23> Если вы не знали, то сообщаю, что в менеджере памяти по крайней мере Windows есть эвристические механизмы, которые заранее загружают в кеш данные, которые скорее всего потребуются.
Проблема в том, что это «скорее всего потребуется» определяется чисто статистически, что на порядок менее эффективно, чем априорное знание, какие конкретно данные, когда и как нужны, которым обладает конкретное приложение.sumanai
30.09.2017 23:26Если в приложении априори всё известно, то зачем вообще вычисления? Покажите конечный результат, например, дипломную работу в моём текстовом редакторе.
Druu
30.09.2017 23:47> Если в приложении априори всё известно
При чем тут все известно? Известно, какие данные нужны для работы приложения и когда.
andreymal
30.09.2017 19:48Вы, видимо, из параллельной реальности.
Рад за себя.)
ОС никогда не сможет качественно кешировать данные
Рад за свой Linux 4.13, он превосходно у меня справляется.)
Это рынок.
Этим я и недоволен.
Вы мазохист?
Нет, я хочу производительности для тех задач, которые выберу сам. Но «рынок» как обычно решает всё за меня. Выбор зачастую есть только между «использовать» и «не использовать». Прощай, многозадачность!
И вы сейчас предлагаете сделать так, чтобы лагало подобным образом ВСЕ, ВСЕГДА И ВЕЗДЕ
Повторю в стопицотый раз: ОС прекрасно справляется с кэшированием файлов сама. Если ваша ОС не справляется — приглашаю к себе в параллельную реальность :)
От того, что приложения тормозят меньше, чем могли бы?
От того, что jvm не умеет эффективно использовать память. Меньшее потребление памяти совсем не обязательно означает тормоза, это вы что-то там себе навыдумавали.
Druu
30.09.2017 21:21> Рад за свой Linux 4.13, он превосходно у меня справляется.)
Как я уже говорил выше — линукс в данном случае очень сильно проигрывает винде, а там все очень плохо. За подтверждающим примером далеко ходить не надо — тормозящие браузеры :)
> Нет, я хочу производительности для тех задач, которые выберу сам.
Но вы не выбираете производительность. Вы выбираете, чтобы тормозило все.
> Повторю в стопицотый раз: ОС прекрасно справляется с кэшированием файлов сама.
ОС не знает какие данные и как кешировать. Результат — кеш на 90% забит ненужным хламом, а нужных данных там нет. Это, кстати, одна из причин, по которым файл подкачки так тормозит.
> От того, что jvm не умеет эффективно использовать память.
Но она умеет.
> Меньшее потребление памяти совсем не обязательно означает тормоза, это вы что-то там себе навыдумавали.
Меньшее потребление памяти приведет к тому, что придется чаще просить память у системы. То есть гарантирует замедление работы. Это не говоря уже о практически всех сборщиках мусора, в которых затраты на сборку обратно пропорциональны потребляемой памяти (чем больше памяти потребляет программа — тем меньше итераций гц).
Ах, да, отключить сборщик мусора тоже нельзя, так как ручное управление памятью, опять-таки, тормозит :)andreymal
30.09.2017 21:27Ваш коммент состоит из бреда, непонимания устройства всего чего можно и противоречий фактам, так что от продолжения данной ветки я воздержусь. К сожалению, навыки учителя у меня недостаточно прокачаны, чтобы во всех подробностях читать лекции и расписывать, как, где и почему вы не правы, а также нет времени клепать тесты производительности. Ну или мы действительно находимся в разных вселенных.
sumanai
30.09.2017 21:57Ах, да, отключить сборщик мусора тоже нельзя, так как ручное управление памятью, опять-таки, тормозит :)
Шутить изволите?Druu
30.09.2017 22:58> Шутить изволите?
Совсем нет. Выделение памяти в случае копирующего/перемещающего сборщика — это, фактически, простой инкремент указателя, что в десятки раз быстрее стандартных аллокаторов, а освобождение памяти и вовсе происходит мгновенно. В итоге, в случае выделения большого количества короткоживущих объектов, сборщик сильно быстрее. Естественно, можно написать свой аллокатор, который будет работать с памятью по принципу гц, но это уже разговор другой, да и с кастомным аллокатором вы в итоге все равно получите оверхед по памяти, просто не такой большой как в случае с универсальным гц.
Druu
30.09.2017 23:17Ах, да, еще забыл про локальность кеша. GC автоматически «выравнивает» линейные данные и благодаря этому зачастую сильно снижает количество кеш-миссов
michael_vostrikov
01.10.2017 05:55Меньшее потребление памяти приведет к тому, что придется чаще просить память у системы.
Вы говорите о случае, когда приложение априори берет много памяти — либо сразу 1 Гб выделить, либо кусками по 10 Мб. А вам говорят о случае, когда приложению в принципе не нужно столько памяти — выделить сразу 100 Мб и всё.
Druu
01.10.2017 09:19> Вы говорите о случае, когда приложение априори берет много памяти — либо сразу 1 Гб выделить, либо кусками по 10 Мб.
Если вам надо хранить 1гб данных — то вам надо хранить 1гб данных. Если вы не будете выделять этот 1гб в хипе — значит, вам надо выделить ее на жестком диске (тормоза) или пересчитывать данные каждый раз во время работы программы (тормоза). Размер требуемой памяти не зависит от того, выделяете ли вы память маллоком в сишечке или через gc в джаве (да, гц имеет определенный оверхед на алгоритм сборки, но он практически никогда не превышает процентов от общего потребления). В итоге это одна и та же память, которая хранит одни и те же данные.
Это во-первых, во-вторых — на практике у вас нет ограничения на потребляемую память сверху. Вот я работаю в иде, сколько вкладок открою — столько памяти и сожрет. Или сбрасывать вкладки на жесткий диск? Но тогда будет тормозить. Да и все равно нужно хранить в памяти АСТ для какого-нибудь intellisense.michael_vostrikov
01.10.2017 09:59Дак о том и речь, что эти 1 Гб данных это обертки и абстракции.
Druu
01.10.2017 10:43Так JVM тут тогда не при чем. У вас и на голой сишке будут те же абстракции.
michael_vostrikov
01.10.2017 11:00Совсем необязательно. На голой сишке будет скажем процедура в readonly памяти, а в Джаве объект фабрики в куче. И речь ведь не именно о Java, как я понял это просто один из примеров, а больше про лишние абстракции, коих в вебе много.
michael_vostrikov
01.10.2017 11:06Что впрочем не отменяет удобность веб-технологий. Сколько времени уйдет, чтобы сделать аналог главной Хабра на WinForms, Qt, или что там сейчас на десктопе?
Druu
01.10.2017 11:08> а больше про лишние абстракции, коих в вебе много
Но они не «лишние», они экономят трудозатраты. Либо у вас есть работающее приложение с абстракциями сегодня, либо без абстракций, но через год (когда оно уже не нужно в силу того, что конкурент вышел на рынок и этот год потратил на допиливание каких-то дополнительных фич, которые дадут ему преимущество). Аналогично с тем же ГЦ — код, который пишется «в лоб», на managed языках в основном работает быстрее, чем на языках с ручным управлением памятью. При желании, конечно, можно заоптимизировать ручное выделение так, чтобы оно работало быстрее — но кто это будет делать и за чей счет?
Речь о том, что переход с условного веба на какие-то другие варианты _сам по себе_ ничего не принесет — наоборот, при прочих равных мы будем получать приложения, которые сильнее глючат, больше тормозят и обладают меньшим функционалом, потому что писать их будет человек, который вчера делал визитки на php.
Ztare
01.10.2017 20:42Речь в статье об потреблении ресурсов которое технически не оправдано вообще ничем, кроме абсолютной популярности браузеров наполненных неудачными решениями и костылями.
Dethrone
01.10.2017 20:42-1Автору нужно вспомнить о принципе «Worse is better»(которому уже 30 лет) и успокоиться.
nezdhanov
03.10.2017 13:00Редко сейчас на хабре встретишь холивар вокруг статьи где скролить устаешь комменты.
На мой взгляд автор поднимает правильные вопросы, но в слишком резкой форме…
ichent
03.10.2017 13:00+1Даже авторизовался, чтобы коммент встроить.
На самом деле, очень часто посещает мысль: «Чем я вообще занимаюсь и как?». Ведь у большинства разработчиков из задач сейчас такие: «Сделаем эту фичу, чтобы кнопка эта не так отображалась», «Вот нужно это сделать, чтобы SEO-шникам хорошо жилось» и т.д. Да, иногда бывает просветление и попадаются интересные задачи, но очень редко. Естественно, я рассказываю про свою жизнь.
Или возьмем какой-нить новый фреймворк. Осваивается он достаточно быстро, но сколько он пакетов с собой тащит, это ужас. И очень часто работа разработчика (вспомните, мы инженеры, между прочим) это копаться в этих покетах и понять, почему же один с другим конфликтует и почему не работает что-то. И это работа инженера с вышкой и большим опытом? Это что вообще за задачи? В моем понимании инженерная задача, когда ты что-то оптимизируешь и например, увеличиваешь какой-то показатель в 2 раза, т.е. что-то даешь, создаешь, творишь, изучаешь предметную область, анализируешь. Это разве инструмент, который постоянно пытается развалиться или сломаться? Это современные инструменты веба, между прочим.
Давно уже хотел высказаться. Вот и статья подходящая. Спасибо.
haldagan
03.10.2017 13:25Невозможно написать безопасное веб-приложение
У человека какое-то непонятное представление о безопасности. Если нет четких критериев «секурное приложение — это...», то и возражать-то бессмысленно.
А безопасное приложение в моем понимании создать довольно несложно:
1. Не разрешай cross-origin запросы (XSS,XSRF, etc.). Если невозможно — учись предохраняться.
2. Не используй непроверенный код (HEIST). Использование сторонних библиотек иногда просто необходимо, но всегда чревато понятно чем. Да это вообще любых приложений касается.
3. Фильтруйбазарввод (XSS,SQL,header injection, etc.)andreymal
03.10.2017 14:08Во-первых, базар надо не фильтровать, а экранировать. Причём делаться это должно автоматически, чтобы нельзя было забыть заэкранировать в каком-нибудь месте.
Во-вторых, все три пункта ничего не значат. Если утрировать, где-нибудь на сайте может сидеть недокументированный API /accounts/:id/password.json, в котором есть и защита от cross-origin, и не используются сторонние библиотеки, и весь ввод фильтруется/экранируется, только какой толк от всего этого, если там разработчик тупо забыл прописать проверку доступа и любой пользователь, узнав про существование этого API, может изменить или в особо запущенных случаях даже прочитать пароль любого другого пользователя?)haldagan
03.10.2017 14:42Про фильтрацию: собственно это и имелось в виду — «экранируй и валидируй».
Если утрировать, где-нибудь на сайте может сидеть недокументированный API /accounts/:id/password.json
Собственно на приведенный Вами пример я и написал про:
Если нет четких критериев «секурное приложение — это...», то и возражать-то бессмысленно
И
безопасное приложение в моем понимании
Дело в том, что всегда можно найти способ выстрелить себе в ногу практически на любой платформе. Жаловаться на то, что веб позволяет забыть проверить права для некоей функции API — как минимум странно.
Подобную ошибку возможно допустить в любом приложении, хоть в полностью десктопном (хранить данные пользователя плейн текстом), хоть в любом другом клиент-серверном (ну, например «забыть выключить на продакшне тестовую фичу с выдачей списка пользователей, не требующую авторизации»).
Вообще автор ратует за некий NewWeb, который нужно пилить и который будет безопаснее текущего Веба. Как этот NewWeb будет защищать от косяков, подобных описанному Вами, мне не совсем понятно.
donnaAnna
03.10.2017 14:32О, подходящее место, чтобы задать давно мучающий тупой вопрос — зачем нам сейчас http? Неужто нельзя замутить новый протокол, с учетом новых требований? Мечта же — выкинуть на свалку все браузеры…
alsii
04.10.2017 19:02Заголовок спойлера
theTeacherOfEnglish
03.10.2017 17:09Но Office 2000 вполне довольствовался CPU на 75 МГц и 32 МБ памяти, в то время как Google Docs со скриншота использует CPU на 2,5 ГГц и почти в десять раз больше памяти.
Вполне разумная плата за то, что веб-приложения (включая Гугл Докс) одинаково запускаются на всех ОС, где имеется браузер.
vasIvas
Так можно совершено обо всем сказать, ведь все что есть в нашем мире имеет проблемы и может, да и должно стать ещё лучше.