Пора убить веб

https://blog.plan99.net/its-time-to-kill-the-web-974a9fe80c89
  • Перевод
Что-то происходит. Люди недовольны. Призрак гражданских беспорядков преследует наши программистские сообщества.

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


Это ты, хакер фронтенда

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

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

Во второй части я предложу новую платформу для приложений, которую способна создать небольшая группа разработчиков за разумное время, и которая (IMHO) должна быть гораздо лучше, чем то, что мы имеем сейчас. Конечно, не все согласятся с последним. Согласиться с проблемами всегда проще, чем согласиться с решениями.

Часть 1. Поехали.


Почему веб должен умереть


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

  1. Веб-разработка медленно повторяет 1990-е годы.
  2. Веб-приложения невозможно защитить.

Вот хороший пост по 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 взрывается под весом своего собственного бессмысленного намолота.

Время вернуться назад к чистой доске. А теперь возьмите выпить и прочитайте следующую статью в серии: что последует за вебом?
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 410
  • +14
    Так можно совершено обо всем сказать, ведь все что есть в нашем мире имеет проблемы и может, да и должно стать ещё лучше.
    • +2
      Вкусная статья, посмотрим что автор предложит.
      • 0

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

        • +1

          Автор как всегда предлагает убить то, в чём не разбирается. Достаточно было дочитать про Flux. Flux/redux имеют весьма посредственное отношение к скорости рендеринга. Это методология организации кода. REST api, разрабатывается всегда с предположением, что клиент скомпроментирован. Для жизнено важных приложений используется дмз и другие способы отсечь удаленное управление, что небесполезно и для защиты десктопных прилад. Зато так приятно ощутить, а то и возглавить панику)

          • +2
            Да и http был разработан исходя из модели запрос-ответ, что безо всякого «выворачивания» ложится на REST api.
            • 0
              Это методология организации кода

              Которая воссоздаёт модель программирования, которую использовала Windows 1.0, выпущенная в 1985 году
          • +10
            Это не про веб, это про конец времени разработчиков-одиночек (плач, продолжающийся с 80-90хх). Веб-платформу нужно не со стороны иконок рассматривать, а со стороны стандартов, REST, масштабирования, развёртывания, кроссплатформенности. Веб не хорош или плох, это просто данность, закономерный результат развития человеческих технологий, решивших по пути своего становления естественно возникающие задачи. Статья вообще ниочём, если есть предложения — предлагай, если есть вера в конструктивность этих предложений — внедряй и конкурируй с вебом. А не смог — смирись с наивностью своих претензий.
            • +24
              Мне кажется Вы несколько недооцениваете про конец-времени и уж тем более плач… каждый то вообщем выбирает для себя формат деятельности, который его радует и позволяет жить с удовольствием… местами статья перегиб, но в целом попытки последних N лет запихать все что можно и нельзя в какие то веб-решения лично у меня вызывают изжогу… Вы путаете «данность» и притягивание за уши всего что вокруг к этой технологической «данности»…

              Мне скажем не жалко памяти моего компьютера… как бы сколько надо столько и купим =), я понимаю _почему_ так получается, но мне кажется что-то с «данностью» не так если десктопный Slack под win10 прямо сейчас жрет у меня 523Mb памяти… представляя из себя окно, показывающее одновременно 20-30 текстовых сообщений и при этом с невозможностью посмотреть историю если нет сети, при этом считаясь почти эталоном корпоративного общения…

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

              Вот опять же, глубокое IMHO, банк-клиент ВТБ24 — обычный для «физиков»… 10 лет назад он был легким, быстрым, работал почти на любых каналах… имел нормальные человеческие функции поиска платежа по описанию, по типу, по строчкам в получателе итд… на тот момент это объективно был лучший банк клиент для физ лиц… да и для юриков тоже был не плох… за 10 лет после 4-5 реинкарнаций, первую кстати начала студия Лебедева… он превратился в чуть шевелящегося уродца с невнятным, абсолютно неочевидным интерфейсом, весом в полтонны… зато обзавелся кучей модных свистелко-перделок…

              • 0
                Я понимаю вашу точку зрения, и сам тоже «страдаю» от потери того чувства всемогущества, которое испытывал будучи школьником, сидевшим перед ассемблерным кодом на сферическом мониторе своего 486-го :). Но подобные идеализмы всегда разбиваются о твёрдость физической и экономической реальности, увы :).
                • +6
                  ну когда я был школьником то больше как-то мне запомнились мк-52, паяльник и синклеры=) 486 уже ближе к концу института… но не в этом дело… я не расцениваю это как «всемогущество», скорее просто лично мой взгляд на высказанное в статье мнение как человека, который последние лет 25 каждый день пишет код ) моя область деятельности далека от веба, хотя в несольких проектах я поучаствовал, поэтому в данном случае я могу позволить себе высказаться просто как пользователь-обыватель… я не пытаюсь разбить голову ни о физические не тем более об экономические реалии, поэтому смело шагаю в магазин за соотвествующим железом, но опять же это не мешает мне иметь точку зрения состоящую в том, что за последние N лет, скажем так — added value для конечного пользователя (меня) в разделе веб продуктов носит очень сомнительный характер, особенно в пропорции к тем ресурсам которые все это добро требует… опять же я не хочу что то агрегировать или делать какие то выводы «за всех», я лишь говорю о том что по сути лично мне не стало удобнее за последние годы читать gmail (если я читаю его в онлайне) или пользоваться своим банк клиентом…
                  • 0
                    за последние N лет, скажем так — added value для конечного пользователя (меня) в разделе веб продуктов носит очень сомнительный характер, особенно в пропорции к тем ресурсам которые все это добро требует…

                    Поддерживаю на все 100!
                • +2
                  С ВТБ24 в точку! Я даже из-за этого ублюдочного интерфейса закрыл там все вклады.
                  • 0
                    Не забудьте написать отзыв в их суппорт, а то они там и не поймут причину оттока клиентов… :)
                  • 0
                    Для интернет-банков это наверно нынешний тренд.
                • +6
                  Потеря контроля над размером буферов — классический источник уязвимостей в программах C, а в вебе возникла в точности такая же проблема: все инъекции XSS и SQL основаны на создании путаницы насчёт того, где начинается буфер для кода и заканчивается буфер для данных. Веб крайне зависим от текстовых протоколов и форматов, так что приходится неизменно парсить буферы, чтобы определить их размер. Это открывает целую вселенную проблем с выходом (escaping), заменой и прочими вещами, которые совсем необязательны.

                  Эмм… Причём тут размеры буферов, если в основе уязвимостей XSS и SQL Injection включение в запрос нативных данных от клиента? Конкатенация на высокоуровневых языках вполне себе корректно выполняется, а вставить в запрос к базе строку из txtClientName без эскейпа можно и на десктопе.

                  • +1

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

                    • +2

                      SELECT * FROM client WHERE name='$client'


                      Можно подставить "Константиновский Константин Константинович", а можно подставить "1' OR 1=1 --". Как вы собираетесь по длине запроса его валидировать?


                      Хотя, конечно, конкретно этот запрос в целом бестолковый, но наглядный

                      • +3

                        Тем не менее, проблема SQL injection "успешно" возникла в Web, как и buffer overflow в C/C++ за 20 лет до этого. Вот автор и говорит о том, что Web повторяет путь десктопного софта, включая схожие грабли.


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

                        • 0

                          В данном случае под текстовым протоколом понимается сам SQL. Вот только полностью заменить его сейчас невозможно. В крайнем случае обернуть (что делают разнообразные ORM, да и рекламируемый автором Permazen).

                          • 0

                            Так SQL и не является частью Web (deprecated WebSQL не в счет).


                            Автор говорит именно о Web и его протоколах, которые до недавних пор были исключительно тесктовыми, да и сейчас ключевые протоколы остаются таковыми.
                            Так что он предлагает (во второй чати статьи) заменить текстовые протоколы на бинарные.

                            • +4

                              Смотрите, в моём примере уязвимости абсолютно нет ни вебоспецифичных, ни текстово-транспортных деталей. Мы в принципе не знаем по какому протоколу в бэкендный код передавались данные в переменную $client. Значение могло быть передано и с десктопа, и с мобильника, и через браузер любым протоколом. И уязвимость именно в механизме формирования SQL-запроса. Как я уже сказал, здесь либо заменять протокол общения с базой на бинарный, либо делать обёртку поверх SQL.

                              • +1

                                Протокол общения backend'а с базой данных здесь вообще ни при чем. Ни с какого боку (подозреваю, они и так бинарные в большинстве DB).


                                Уязвимость возникла из-за комбинации пагубной практики программистов строить свои SQL запросы конкатенацией с сырыми данными, полученными из браузера, и возможности очень легко подменить данные в HTTP запросе с текстовым протоколом. И если первое можно победить, заставив программистов использовать параметры в SQL, то второе никуда не делось, и еще будет источником новых уязвимостей.

                                • 0
                                  Протокол общения backend'а с базой данных здесь вообще ни при чем. Ни с какого боку (подозреваю, они и так бинарные в большинстве DB).

                                  Сам-то запрос бинарный, но внутри него хакнутая SQL-инструкция.


                                  Уязвимость возникла из-за комбинации пагубной практики программистов строить свои SQL запросы конкатенацией с сырыми данными, полученными из браузера, и возможности очень легко подменить данные в HTTP запросе с текстовым протоколом.

                                  Наивно полагать, что в бинарный протокол нельзя подсунуть свои данные. Да и не в протоколе передачи данных дело. Ему сказано передать такую-то строку из поля ввода, он её и передаёт. Более того, бинарный протокол может передать ту самую "1' OR 1=1 --" как есть, предварив полем с длиной строки, а вот текстовый протокол вполне себе может что-нибудь заэкранировать. Но на стороне сервера значение будет деэкранировано. И на этом этапе уязвимости не будет. Просто такая защита не входит в обязанности протокола передачи. Ему надо передать эти данные как есть, какими бы они ни были. Наоборот, уязвимостью было бы полагаться на одностороннее экранирование на клиентской стороне.


                                  Вот когда эта наша строка придёт в код, реально формирующий SQL-запрос, вот тогда-то уязвимость и появится. Да, это следствие текстовой природы SQL. Но это сейчас общепринятый стандарт работы с реляционными СУБД и другого у нас нет.


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

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

                                  • +1
                                    Сам-то запрос бинарный, но внутри него хакнутая SQL-инструкция.

                                    Неверно. Хакнут был HTTP запрос, а не SQL. В таком случае замена протокола общения сервера с базой на бинарный, либо введение обёртки поверх SQL (как вы предлагали) вообще ничего не даст.


                                    Наивно полагать...

                                    А я и не полагаю наивно ;-)


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


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


                                    К тому же, основная цель NewWeb (как автор это называет) не в устранении всех возможных уязвимостей на 100% (сам автор считает это невозможным), а в минимизации возможных ошибок, что приведет к уменьшению числа дыр.


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


                                    Бинарность протокола делает ненужным всякие ухищрения с экранированием/эскейпингом, а также существенно облегчает парсинг (особенно если данные типизированы). Это ведет к уменьшению числа потенциальных ошибок и новых дыр.


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

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


                                    Да, это следствие текстовой природы SQL. Но это сейчас общепринятый стандарт работы с реляционными СУБД и другого у нас нет.

                                    Как я уже говорил, SQL injection — просто частный случай. Проблема в самом текстовом протоколе без всяких средств контроля данных.

                                    • +1
                                      Неверно. Хакнут был HTTP запрос, а не SQL. В таком случае замена протокола общения сервера с базой на бинарный, либо введение обёртки поверх SQL (как вы предлагали) вообще ничего не даст.

                                      Вы неправильно понимаете суть SQL Injection. Она не в проблеме передачи данных.


                                      Бинарность протокола делает ненужным всякие ухищрения с экранированием/эскейпингом, а также существенно облегчает парсинг (особенно если данные типизированы). Это ведет к уменьшению числа потенциальных ошибок и новых дыр.

                                      Экранирование не потребуется, а вот сериализация/десериализация всё равно будут нужны.

                                      • +1
                                        Вы неправильно понимаете суть SQL Injection. Она не в проблеме передачи данных.

                                        Сам хак SQL Injection происходит только на этапе передачи данных, и никак иначе (если мы о Web говорим). Если вы этого не понимаете, то… это вы не понимаете суть SQL Injection ;-)


                                        Например, если вы передаете числовые данные в бинарном виде (т.е. с фиксированной длинной и в строго определенном формате), то SQL Injection невозможен в принципе. Как видите, проблема решена полностью именно выбором способа передачи данных.


                                        сериализация/десериализация всё равно будут нужны.

                                        Конечно. Это должна быть стандартная часть протокола, и будет делаться через стандартный API.

                                        • 0
                                          Сам хак SQL Injection происходит только на этапе передачи данных, и никак иначе (если мы о Web говорим).

                                          SQL Injection это всегда отсутствие валидации входных данных

                                          • +3

                                            Да, вы можете валидировать текстовые данные, добавиви в ваш стек еще одно место потенциальных ошибок и дыр. Именно так и делается в современном Web, и именно это критикует автор.


                                            А можно перейти на другой протокол, который в ряде случаев вообще не допускает SQL injection "by design".

                                            • 0

                                              А как вы зарегистрируетесь на каком-нибудь Хабре Нового Веба, не введя свой никнейм, почту и пароль?

                                              • +2

                                                Используя SQL с параметрами.


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

                                              • 0
                                                добавиви в ваш стек еще одно место потенциальных ошибок и дыр

                                                Без ошибок только тот код, которого нет. Переход на другой протокол, это просто перенос валидации на уровень протокола, а не приложения. Но да же и тут без валидации на уровне приложения никак.

                                                • 0

                                                  Но ведь можно попробовать хотя бы уменьшить количество потенциальных дыр. В этом и состоит предложение автора статьи.

                                                  • 0
                                                    Или выгнать плохих разработчиков.
                                                    • 0

                                                      Или и то, и другое :-)

                                                    • 0

                                                      Только предлагается этой ценой замены всего стека технологий, наработанного за последние 30 лет, в том числе и highload, и написание нового. Сомнительно, что этот новый стек быстро избавится от багов.

                                                      • 0

                                                        Даже в текущем стеке Web постоянно появляются новые технологии, и никто особо не переживает по поводу небыстрого избавления от багов :-)

                                                        • 0

                                                          Ок, а что мешает уже сейчас использовать Java, TypeScript, Thrift API для контроля типов и бинарного протокола?

                                                          • 0

                                                            У среднестатистического пользователя Web-приложения есть только браузер в качестве клиента, который вы не можете контроллировать. Как вы будете доставлять все это (Java, Thrift etc.) к нему в браузер? Особенно если он не хочет ваших плагинов.


                                                            Вот автор и "предлагает" сделать новый Web (NewWeb) с улучшенным дизайном для улучшения безопасности и производительности. Чтобы клиенты (e.g. браузеры) "из коробки" поддерживали новые протоколы.

                                                            • 0

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

                                                      • 0
                                                        Оно идиотское. Есть очень хороший пример, не помню откуда — детям на велосипед ставят дополнительные колесики сзади, когда они учатся кататься. Автор посчитал сколько травм получают люди падая с велосипедов, и теперь требует ставить на все велосипеды колесики. «Можно хотя бы попробовать уменьшить число потенциальных травм».
                                                        • 0
                                                          Некорректный пример. С его помощью можно выставить любую попытку улучшить что угодно бессмысленной с точки зрения «Можно хотя бы попробовать уменьшить число потенциальных травм»
                                                    • +1

                                                      А при чем тут протокол? Исходные данные вводит пользователь. И это будет текст, как ни крути. Мы можем что угодно делать при передаче, придумывать текстовые, бинарные, да хоть квантовые протоколы, но конце нам нужно получить SQL-запрос, содержащий эти данные и передать его в СУБД. А для этого нам нужно будет получить то, что ввел пользователь. И это будет текстовая строка. И если мв не умеем безопасно строить запрос с этой строкой, то никакие ухищрения нам не помогут.
                                                      А вообще для SQL injection веб не нужен, от слова совсем. В криво написанном десктопном приложении он может осуществляться ничуть не хуже.

                                                  • 0
                                                    Например, если вы передаете числовые данные в бинарном виде (т.е. с фиксированной длинной и в строго определенном формате), то SQL Injection невозможен в принципе. Как видите, проблема решена полностью именно выбором способа передачи данных.

                                                    С подменой числа строкой справится и парсинг JSON на типизированной платформе (Java, .NET). А вот что насчёт подмены строки как в моём примере?

                                                    • 0

                                                      JSON — тоже текстовый. Вставка во время транспорта делается также легко, как и в URL простого HTTP GET.


                                                      Да, вы можете использовать JSON валидацию — так же как программисты, допустившие SQL injection, могли бы использовать SQL с параметрами. А можете и не использовать, что является дырой.


                                                      Автор предлагает NewWeb, в котором накоторые дыры будут закрыты "by design", независимо от того, что вы используете (или не используете) на своем backend'е.


                                                      А вот что насчёт подмены строки как в моём примере?

                                                      Использовать параметризированный SQL :-)


                                                      Еще раз повторю: проблема — в возможности очень легко подменить данные в HTTP запросе с текстовым протоколом. Это будет источником новых уязвимостей.

                                                      • +1
                                                        проблема — в возможности очень легко подменить данные в HTTP запросе с текстовым протоколом.

                                                        А какое это отношение имеет к SQL injection? Для этой атаки ничего подменять не надо.

                                                    • +1
                                                      Сам хак SQL Injection происходит только на этапе передачи данных, и никак иначе (если мы о Web говорим).

                                                      С чего это вдруг? Он происходит после передачи данных, при обработке в приложении.


                                                      Например, если вы передаете числовые данные в бинарном виде (т.е. с фиксированной длинной и в строго определенном формате), то SQL Injection невозможен в принципе.

                                                      С чего это вдруг? Какая разница, передали мы значение $client в виде "OR 1=1\n" или в виде "0x06OR 1=1"?

                                              • 0
                                                и возможности очень легко подменить данные в HTTP запросе с текстовым протоколом

                                                Почему вы решили, что в двоичном протоколе подменить данные сложнее?

                                        • 0
                                          > Тем не менее, проблема SQL injection «успешно» возникла в Web

                                          Это с чего бы? SQL-инъекции возможны в любом приложении, которое принимает данные от пользователя и подставляет их в запрос. Не важно, десктоп это или веб.
                                        • 0
                                          дичь, потому что есть Prepared statement
                                          • 0

                                            Разумеется, но речь-то про некие буферы и форматы веба.

                                          • 0
                                            Если знать что следующие n байт буффера это текст, а не исполняемый код мы можем просто игнорить эти n байт пока не возникнет желание провернуть какие-нибудь еще манипуляции именно с данными.
                                      • +9
                                        Flux, последнему модному веб-фреймворку от Facebook

                                        В вебе минули геологические эпохи с тех пор, как Flux был последним и модным (не то чтобы пришедшее на замену шибко лучше, но все-таки).


                                        На C++ невозможно написать безопасный код, а виноват, конечно, веб, ну да.


                                        Веб, со всеми его недостатками, с REST-ом, Flux-ом и прочим грузом, по факту оказался самой удобной системой доставки контента и приложений (что, впрочем, трудно разделить, потому что современный контент требует интерактива (привет, комменты на хабре), а приложения работают с контентом (well, duh)).


                                        Как только появится что-то кардинально лучшее, мы все немедленно на него перейдем: разработчики, если они не застряли в ностальгии, как им любовно и прельстиво кодилось в 90-ые под Win3.x, любят вскакивать на hype-train как никто другой. Боюсь, только, что оно будет организовано на примерно тех же принципах: гипертекст и скриптовый язык.

                                        • +1
                                          > Как только появится что-то кардинально лучшее

                                          Не «что-то», а «что-то + экосистема». Именно поэтому надеяться на то, что оно само появится… Не стоит?

                                          Я прошел путь от Rails до собственной lightweight библиотеки по типу React, и тут понял… Что HTML и пр. тут просто не нужен… Бери себе C++/Python/Ruby/etc. + xWidgets, замути такую библиотеку и… Ну разве что, еще нужны всякие API для доступа к сенсорам (если нужно). Но экосистемы-то нет, потому, что нет моды, потому, что нет…

                                          А мода на комбайны под названием «браузеры» (заметьте, еще и несколько!) — плохая. Даже с учетом налаженного процесса стандартизации… Это я спустя десяти лет web programming говорю, спустя годы восхищений… Сейчас я понимаю, что даже идея комбайна JVM — возможно, лучше…

                                          Иллюстрация? Восхищения по поводу WebAssembly: взяли ОС, создали браузер со своей «ОС», сделали «стандартный» высокоуровневый ЯП, а WebAssembly — инновация, которой нам не хватало! Ассемблер внутри всего этого.

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

                                          Боль.
                                          • 0
                                            Скриптовый язык — вряд ли: это замена шила на мыло. Скорее наоборот, появится броузер приложений, который будет скачивать архив с исходным кодом, собирать его на клиентской стороне, и запускать как обычное desktop-приложение в контейнере с ограниченными правами. На мой взгляд, лучше всего для таких целей сейчас подходит язык Go в связке либо с Qt, либо xwWidgets.
                                            • 0

                                              Надо просто пересажать пересадить всех на Gentoo.

                                          • +3
                                            Office 2000 вполне довольствовался CPU на 75 МГц и 32 МБ памяти

                                            А сейчас этого мало даже дня нативного десктопного мессенджера, да и для мобильного тоже. Так что вы правы, html — зло. Хотя, при чем здесь html?
                                            • 0
                                              Подмена понятий же)
                                              • +4
                                                Подмена понятий происходит тогда, когда из технологий, основанных на веб-страницах, делают веб-приложения. Backend должен быть ничем иным, как веб-сервисом, а между браузером и сервером должен быть стандартизованный API.
                                                • 0
                                                  А что не так с вэб-приложениями и чем оно отличается от вэб-страницы? Второе ваше предложение вообще не связано с первым, о чём вы??
                                                  • 0

                                                    А какой API следует считать стандартизованным в случае клиент-серверного десктопного приложения?

                                                    • 0

                                                      Тот же GraphQL

                                                      • 0

                                                        Stateless API поверх HTTP, да ещё и текстовый?

                                                • +2
                                                  сейчас куча приложений на десктопе внутри html рисует и имеет webkit в зависимостях, в том числе месенджеры. Разумеется, это не целиком веб-приложение, но и не целиком нативное.
                                                  • 0
                                                    В отличии от веба, авторы десктопных приложений вольны выбирать любой вариант форматирования текста. Если кто-то выбрал для этого полноценный html, то это не вина html. Хотя и с его отображения Operа когда-то справлялась на 75 МГц и 32 МБ памяти.
                                                    • 0
                                                      На самом деле и сейчас есть броузер dillo, который может показывать Web-страницы с очень небольшими затратами ресурсов. В частности на эту страницу ему потребовалось всего 32 Мб памяти. Только вот JavaScript в нем нет и поддержка CSS неполная.
                                                    • +2

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

                                                  • 0
                                                    Мир не идеален и решения не могут быть идеальными, всегда будут проблемы, всегда будут те, кто будет пользоваться этим, по крайней мере такая песня будет ещё долго.
                                                    • +7
                                                      Только не пинайте сильно ногами. Но почти всё то, за что тут ругается веб, решено во Flash…
                                                      • 0

                                                        Так автор ещё и бэкенд ругает.

                                                        • 0
                                                          Кроме безопасности
                                                          • 0

                                                            А с ней там плохо по другим причинам.

                                                            • 0
                                                              Да все те же упомянутые буферы переполняли. Ну и песочниц так и не сделали. Если отдадут таки флеш в OpenSource, то может найдутся желающие переписать его на Rust.
                                                              • 0

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

                                                                • 0
                                                                  Каких, например?
                                                                  • 0

                                                                    Ну самое очевидное — то что там изначально аналог shadow dom, т.е. один компонент не может что-то сломать в родительском приложении или его стилях. Или в другом компоненте. Т.е. только публичный API, и ничего больше. Такой вещи, как глобальный window, как document.write — вообще никогда не было за ненадобностью. Там нет загрузки скриптов, как таковой — есть загрузка swc, но это совсем другая история.

                                                          • 0

                                                            Чистая правда. Я сейчас после длительного перерыва смотрю на веб-фреймворки, и вижу, что да, shadow dom и кастомные элементы все-таки сделают революцию рано или поздно — но все это уже было в Flash/Flex, причем много лет назад.

                                                            • 0
                                                              Автор об этом и говорил: «Suggesting that Macromedia Flash might actually be good would get your geek card revoked.»
                                                            • +8
                                                              Простите, конечно, но мне почти половина всей статьи показалась дичайшим бредом.
                                                              • +9

                                                                Серьезно? В другой половине вы смысл нашли?

                                                                • 0
                                                                  Неужели автор так не прав, что даже наполовину не мог?
                                                              • +19
                                                                Полностью согласен, т.н. «веб-технологии» — самое мерзкое, что случалось с ИТ-индустрией за всю ее историю: неудобный и многословный язык разметки (зачем надо было придумывать этот велосипед, когда уже существовал хоть тот же TeX?), ущербный язык стилей, в котором до самых последних версий не было даже возможности отцентровать элемент по горизонтали, самый нелогичный скриптовый язык с невероятно идиотской системой типов и убогой стандартной библиотекой (из-за чего развелись миллионы фреймворков-однодневок, пытающихся замазать его убогость), примитивный протокол, работающий только в одну сторону (что допустимо для документов, но немыслимо для приложений), и т.д.

                                                                Давно пора заменить все это дно на какой-нибудь «контейнер приложений» вместо браузера, которые распространялись бы в бинарном виде, работали по нормальному «дуплексному» протоколу, а для UI использовался бы нормальный язык разметки, в идеале поддающийся автоматизации (чтобы дизайнеры могли «рисовать» его в редакторе, не заморачиваясь с версткой).
                                                                • –1
                                                                  Давно пора заменить все это дно на какой-нибудь «контейнер приложений» вместо браузера, которые распространялись бы в бинарном виде, работали по нормальному «дуплексному» протоколу

                                                                  WebAssembly+WebSocket+WebGL? А все остальное вопрос фреймворков.

                                                                  • 0
                                                                    А все остальное вопрос фреймворков.

                                                                    То есть заменяем язык с убогой стандартной библиотекой на платформу вообще без стандартной библиотеки, и разводим поверх неё "миллионы фреймворков-однодневок"?

                                                                    • 0
                                                                      на платформу вообще без стандартной библиотеки

                                                                      С чего это вы взяли? Можно хоть существующие фреймворки на других языках прикрутить

                                                                      • +2

                                                                        И каждое такое приложение будет тянуть за собой Qt, .NET, Java Standard Library, Unity? Чем тогда та же пара мегабайт Ангуляра не устраивает?

                                                                        • 0
                                                                          Это автора(Mike Hearn) и zugo не устраивает.
                                                                          • 0
                                                                            Речь-то шла про замену современного «фронтенда» на какой-нибудь гипотетический нормальный унифицированный стек технологий, а не о том, чтобы дать возможность запихнуть в браузер .NET целиком.
                                                                            • 0
                                                                              запихнуть в браузер .NET целиком.

                                                                              Так он уже там есть. Unity называется.

                                                                          • 0
                                                                            Зачем тянуть каждому приложению? Можно сделать систему зависимостей.
                                                                      • +1

                                                                        Зачем Использовать WebAssembly, WebSocket и WebGL, есл можно использовать Assembly, Socket и GL, чуть-чуть поменяв популяпные ОСи и добавив полслоя абстракции?

                                                                        • 0

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

                                                                          • +6

                                                                            Клиенты хотят запускать всё не из браузера, а из унифицированной платформы, которая на сегодняшний день имеет только одну реализацию — браузер.
                                                                            Если бы существовала другая реализация унифицированной платформы, причём более быстрая (то есть использовала Sockets, Assembly и GL без приставки Web), то про браузер бы никто не вспоминал.
                                                                            Об этой другой, воображаемой и желаемой реализации и ведёт речь автор этой статьи.

                                                                            • –1
                                                                              • 0
                                                                                Осталось прикрутить к ним работу приложений без установки и безопасность
                                                                                • 0

                                                                                  Я бы не назвал Java платформой. Хотя, я конечно имею посредственное представление обо всех её возможностях, но это скорее ВМ в моём видении. Браузер унифицирует большее количество вещей, чем ВМ.
                                                                                  Вот Android SDK уже можно назвать такой платформой. Потому что унифицируется доступ к ресурсам ОС, файловой системе, взаимодействию между приложениям, забавушкам.
                                                                                  Вот только она не унифицирована :)
                                                                                  Если слить вместе Android, iOS и .NET стек (а не кросскомпилировать как в Xamarin), унифицировать его, плюс убрать слой абстракции между ОС и ВМ, которая несёт эти приложения — т.е. так, как сделано в мобилках и так как не сделано в десктопах — HTML+JS утонет в Лете.


                                                                                  Flash по сути не решает проблему из-за проприетарности и ограничений. Помоему флеш не умеет UDP, не умеет работать с файлами и тыды

                                                                                  • –4
                                                                                    Платформа — это то, от чего можно уверенно отталкиваться. Пока что, так называемая, Java Platform имеет ряд минусов:
                                                                                    — Строгая типизация
                                                                                    — Необходимость обработки исключений
                                                                                    — Необходимость установки среды исполнения
                                                                                    — Принудительное ООП
                                                                                    — Управление памятью и системным треем доступно только через платформозависимый JNI
                                                                                    • +2
                                                                                      Что такое «строгая типизация»?
                                                                                      Если вы имеете в виду статическую типизацию, то я имею место с вами не соглашаться, поскольку типизация динамическая, по большому счёту, создаёт слишком много проблем, не давая взамен ничего, кроме возможности иногда не писать одно «лишнее» слово.

                                                                                      И да, непроверяемые исключения — это рак из той же оперы. Ради того, чтобы не писать некоторые обработчики, люди вынуждены гадать, какие исключения может бросать функция, и не врёт ли javadoc.
                                                                                      • +1
                                                                                        Вы смешали в одну кучу синтаксис джавы как языка, ее семантику, возможности JVM как платформы, проблемы установки на конкретную проприетарную ОС, да еще зачем то сюда системно-зависимый юай приплели.

                                                                                        Из этого складывается ощущение, что вы слабо понимаете, о чем говорите.
                                                                                        • 0
                                                                                          Платформа — это то, от чего можно уверенно отталкиваться. Пока что, так называемая, 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 платформе.
                                                                                      • 0
                                                                                        Да, согласен, Андроид больше подходит под замену браузеру. У него есть очень жирный плюс в виде стандартной интерфейсной библиотеки, которой достаточно удобно пользоваться, как накидывая контролы редактором, так и в коде. А поскольку интернет у нас — про порно котят визуальные интерфейсы, удобный и гибкий способ графического отображения информации играет решающую роль.
                                                                                        • 0
                                                                                          Наверное именно поэтому немалая часть приложений под андроид — это обертки над браузером, заточенные под конкретный сайт. А-ля фейсбуковское приложение несколько лет назад, сейчас без понятия что там.
                                                                                          • 0
                                                                                            Нет, не поэтому. Браузер это браузер, где CSS, верстка, интерпретатор JS и прочие ужасы, и к построению приложений таким образом прибегают только в случае совсем уж примитивных приложений, либо с надеждой написать один раз для всех платформ, что очень быстро упирается в потолок производительности. В нативных же приложениях — байткод, существенно более быстрый и безопасный.
                                                                                            • 0
                                                                                              Для большинства приложений производительность не нужна. Вот честно, для 95% приложений единственная задача это отрисовать информацию из базы. Приложений, требующих производительности на андроиде то и нет почти, если не считать игр.
                                                                                              • 0
                                                                                                Когда на несчастном телефоне одновременно запущены несколько приложений, написаных в стиле «производительность не нужна», внезапно оказывается, что она таки нужна.
                                                                                        • 0
                                                                                          Осталось добавить плеер Android приложений в… браузер!
                                                                                    • +1
                                                                                      Эту платформу все равно нужно будет устанавливать на телефон, комп.
                                                                                      т.е. это будет некое приложение. ладно представим что оно будет вмонтировано в операционные системы, т.е. как браузер по умолчанию.

                                                                                      Что делать с гуглом, как он теперь будет анализировать приложения, нажатия, переходы? мы не имеем DOM, мы имеем байткод, т.е. черный ящик.
                                                                                      Создавать разметку? тогда мы вернемся к созданию браузера.
                                                                                      google врядли будет создавать технологию которая убьет их основной бизнес.
                                                                                      А как уже сказали выше, кроме гугла и майкрасофта это никто не сделает

                                                                                      • 0
                                                                                        Создавать разметку?

                                                                                        Да, создавать разметку. Специально для поисковиков.


                                                                                        Вообще, её даже создавать не надо, такая разметка уже есть, и она как раз изобретена поисковиками для поисковиков — schema.org. Просто берём её готовую и не паримся.

                                                                                        • 0
                                                                                          Просто берём её готовую и не паримся.

                                                                                          Она прибита к HTML. Возможно, её можно применить к похожим языкам разметки документов. Но она никак не приспособлена для приложений.
                                                                                          • 0
                                                                                            Она прибита к HTML.

                                                                                            Нет, microdata в HTML — это лишь один из вариантов представления schema.org, там же есть и, например, JSON-LD (который к тому же рекомендуется для использования гуглом), не связанный с HTML вообще никак; ну и в любом случае никто не мешает придумать ещё один формат представления по необходимости.


                                                                                            А вообще нахрена индексировать приложения, лол?

                                                                                            • 0
                                                                                              Так идея то не создать облако приложений, а заменить сайты на эти приложения. Заходишь на vasya.ru и тебе генерируется в неком контейнере нечто похожее на сайт.
                                                                                              Если нужно облако приложений то тупо создавайте apple store/google play, точней его аналог и накатывайте туда свои приложения.

                                                                                              что делать с 10000000 сайтами? как вырастить репку, как починить люстру, кулинарные сайты. и т.д.
                                                                                              Нужен поисковик, если делать так как предложили выше(тупо на основе разметки), то вернемся в 2007 год, алгоритмы яндексе и гугла раньше анализировали текст и ссылки (в 2007+ была жесть в выдаче)

                                                                                              • –2
                                                                                                Гиблое это дело. Веб устраивает веб программистов.
                                                                                                Веб не устраивает C# / java программистов.

                                                                                                Я часто слышу такое мнение именно от C# C++ Java android программистов, вдумайтесь, люди с другой ниши, переживают за бедненьких веб разработчиков))


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

                                                                                                Самое забавное вот что: C#/java программисты переживают за душевные страдания веб разработчиков, они искренне недовольны что в вебе все плохо. Переживают за чужой мозг, что бедным веб разработчикам приходится так напрягаться на работе.

                                                                                                Кому не нравится стандартный JS берут что-то вроде react/angular и прикручивают TS/flow
                                                                                                Меня устраивают, если ты хочешь разрабатывать не веб приложения, то тебе вообще закрыта дорога в веб, бери C++ и пиши драйвера, делай мир лучше.
                                                                                                • 0
                                                                                                  Зайдите в профили к людям которые яро хейтят веб, в 90% случаях это будет Java/ c#/C++ программист.
                                                                                                  • +1
                                                                                                    5 лет назад никто не жаловался на 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 был ещё доступен программный рендеринг без какого-либо ускорения вообще, который к тому же неплохо работал на компах того времени (ну, может, плюс пара лет).

                                                                                                    • 0
                                                                                                      Вот вообще плевать на них. Мне не плевать на то, что новый скайп-фор-линукс нормально завести на интел-атоме вообще нереально по причине лютых тормозов и зашкаливающего потребления оперативы. Зато разработчикам скайпа удобно, блджад! Конечно говнокодить удобно, кто ж спорит, только вот на выходе говно и получается.


                                                                                                      Речь при 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)

                                                                                                      • 0
                                                                                                        Фреймворки есть во всех языках и почем-то хейтят только JS фреймворки.

                                                                                                        Разве? Сколько говна не забывают вылить на PHP фреймворки в соответствующих тредах, не замечали? И это я со своей узкой колокольни, а ругают везде и всё.
                                                                                                        • 0
                                                                                                          Про PHP я не видел постов уже год, что там все плохо.
                                                                                                          Если они и есть, то от разработчиков других ЯП.
                                                                                                          Если не нравится PHP, пишешь на другом языке.

                                                                                                          Возьмем C# Entity Framework
                                                                                                          Я считаю это полным шлаком, с ним все лагает, криво распознает META Таблиц.
                                                                                                          Но ты мне скажешь: он идеален, просто ты не умеешь его готовить и что-то делаешь не так.

                                                                                                          C# веб сервисы, кому пришло в голову писать веб сервисы на C#, я видел код этих сервисов и ужаснулся, 2000 строк кода, ради создания простого REST API (куки, сессии, подмена заголовков, CORS)
                                                                                                          Это считаю шлаком, зачем они лезут в ВЕБ сервера с своим говном?
                                                                                                          ASP.NET такое же дерьмо, сейчас эра SPA, и ваши проекты, которые перезагружают страничку никому не нужны.
                                                                                                          Знаешь что я еще видел, я видел C#, PHP, JAVA который генерирует JS код (пишешь на PHP. JAVA, а тебе генерируется JS код на ангуляре)
                                                                                                          Какой дурак до такого додумался? Ваш язык не предназначен для современного веба.

                                                                                                          • 0
                                                                                                            Во-первых, написать REST-сервис на ASP.NET MVC можно быстрее и качественнее, чем на любом PHP-фреймворке.

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

                                                                                                            Правда, к сожалению, работодатели очень часто требуют именно PHP — чтоб потом проект можно было поддерживать силами дешевых макак (что, конечно, заблуждение — писать на PHP хорошо куда сложнее, чем на нормальном языке, и почти никто из «PHP only» разработчиков на это не способен).
                                                                                                            • 0
                                                                                                              И тянуть за собой WINDOWS sever?

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

                                                                                                              Я видел приложения на IIS+ASP.NET + react, шлак шлаком, куча оберток для JS, куча костылей, господи там даже некоторые генерировали react на коде через C#, а не разделяли на rest + client, и вы что-то про костыли в JS говорите.

                                                                                                              Понимаю конечно что это экономия на сотрудниках.

                                                                                                              PHP разработчики могут писать хороший код, но для этого нужен не PHP Junior За 60 000 рублей, а PHP Разработчик за 170 000 рублей, если работодатель не готов платить такие деньги, то может ему и качество не нужно? Почему все работодели считают что человек за 60 000 рублей должен быть спецаилистом? это оклад джуниора. и они никак не может быть спецаилистом и он будет, как вы выражаетесь — макакой.


                                                                                                              • 0
                                                                                                                Это тоже самое, если для ремонта квартиры нанимать не бригаду за 150 000 рублей в месяц, а алкаша, который только только скоречник мастерил, нанять его за 1000 рублей и жаловаться что специалистов почти не осталось, одни неумехи и шарлотаны.

                                                                                                                а у нас как получается:
                                                                                                                — Нам нужен специалист, но на рынке никого нет, жаль что одни немехи
                                                                                                                — Шев может повысим зп, будем искать хотя бы от 120 000 ну и опыт от 7 лет, а не за 30 000?
                                                                                                                — ты что? кто он такой что бы я ему столько платил? там же просто кнопки рисовать, открой авито или циан, ну что там сложного? кнопка, кнопка, текст, любой справится, нет ищем за 40 000 максимум! Веб это игрушки, HTML учить 1 неделю, нет, максимум 42000, как найдем начинаем делать свою соц сеть для знакомств(с)

                                                                                                                • 0
                                                                                                                  И тянуть за собой 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к, он хочет брать макак с улицы. Это, в том числе, и вина скриптовых языков с низким порогом вхождения — что в принципе возникла такая идея, что программист может быть дешевым.
                                                                                                                  • 0
                                                                                                                    Макаки есть даже в С++ нише.
                                                                                                                    Хотите избавится от макак, платите им вместо 60 000 рублей, минимум 140 000 — 200 000 и сразу же найдутся специалисты с 5-10 летним опытом.
                                                                                                                    (если меня сейчас читают начальники и руководители, HR спецы, поймите, ну нельзя найти специалиста за 60 000 рублей и требовать от него постановки архитектуру на 3 летний проект, сейчас охранник больше получает, минимум 200 000 рублей — и будет вам специалист)

                                                                                                                    Про стек согласен, если есть деньжатки то можно и стек сменить.

                                                                                                                    А зачем PHP программисту знать как устроена память, как работать с битностью? это сделает его не макакой и C++ программисты перестанут их опускать?)

                                                                                                                    Самое главное что ему нужно знать по моему мнению — уметь строить грамотную архитектуру и писать быстрые SQL запросы) ну и чистый код еще)

                                                                                                                    Считаете ли высокий порог вхождения у Frontend (современный с его 10 обертками и 100 конфигами, кросбраузерность)?
                                                                                                              • +1
                                                                                                                сейчас эра SPA, и ваши проекты, которые перезагружают страничку никому не нужны.

                                                                                                                Большая часть SPA — лагучее неюзабельное говно, которые убивают уже существующий функционал браузеров, а потом героически их решают своими костылями. SPA — не нужны, SPA не решают никаких проблем для пользователя.
                                                                                                                • 0
                                                                                                                  Они, быть может, не решают _ваши проблемы_. А если бы они не решали проблем пользователя — то их бы никто и не использовал, не-спа сайты просто побеждали бы спа в конкурентной борьбе.
                                                                                                                  • 0
                                                                                                                    Покажите мне пример лагучего SPA пожалуйста.
                                                                                                          • 0
                                                                                                            Меня веб не устраивает не как программиста, а как пользователя. Веб чудовищно жирный и тормознутый, он неэффективно расходует аппаратные ресурсы. Я, как пользователь, не хочу чтобы веб приходил в мобильную разработку, иначе мы увидим приложения уровня «список покупок», которые требуют для работы 8 ядер процессора и 16 Гб оперативки, и при этом сажают батарею за полчаса.
                                                                                                          • 0
                                                                                                            Не понял проблемы. Сайты пусть будут сайтами, приложения пусть будут приложениями, и нечего их смешивать, как это происходит сейчас. В каком-нибудь скайпе индексировать в поиске вообще нечего, кроме самого факта существования скайпа как онлайн-приложения. Для какого-нибудь гуглдока для публичных документов в нём не составит никакой проблемы накатать этот самый JSON-LD. Кулинарные сайты пусть остаются кулинарными сайтами на HTML+CSS, они же не приложения.
                                                                                                            • –1
                                                                                                              Возможно у нас разные понятия просто
                                                                                                              Я называю веб-приложением некий масштабный сайт.

                                                                                                              Например cian — веб приложения
                                                                                                              Яндекс карты — веб приложение
                                                                                                              Фейсбук — веб — приложение.
                                                                                                              Яндекс Маркет — веб приложение.
                                                                                                              Ютуб — веб — приложение.
                                                                                                              рецепты ру — сайт
                                                                                                              пикабу — сайт/Портал

                                                                                                              Вот эти веб приложения, что я перечислил я считаю нужно писать их на JavaScript + css+ html + svg и ничего не нужно менять, нужно расширять эти языки.
                                                                                                              Кому не нравится отсутствие типизации, подключают TS или flow
                                                                                                              Кого напрягают всякая магия JS, просто не идут в веб разработку и пишут себе драйвера на C++, забудьте про веб разработку если она вам не по душе, вот что я хотел донести.

                                                                                                              Люди в посте пишут, что пора прекращать расширять монстра(js css html), нужно убить эти языки и создать что-то новое, предлагают создать аналог браузера, при заходе по ссылке, будет отдаваться не гипертекст, а байткод приложение, которые будет исполняться в этом «браузере»

                                                                                                              Это пишут не веб разработчики, это пишут C++ / C# /Java разработчики, которые и CSS то в руках никогда не вертели, не говоря уж о JS(ts)

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

                                                                                                              • 0
                                                                                                                вы под веб приложениями подразумеваете… когда на 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 всё ещё мало.)