Pull to refresh

Comments 84

Ну, идея в целом хороша. Кто и зачем это будет делать — совсем другой вопрос.
В плане защиты как минимум, вебом я недоволен целиком. Слишком много векторов атаки, чтобы уверенно сказать, что мы «защищены от самых дешевых атак».
Если такое большое недовольство защитой веба, так почему не попытаться улучшить ее, а не заменять веб целиком? Неужели это будет проще?
UFO landed and left these words here
Да, проще. В вебе слишком много легаси и обратной совместимости аж с девяностых, когда веб использовался для совершенно других задач.

Конечно, это кажется сложнее, потому что надо разрабатывать с нуля. Но рано или поздно количество всяких архитектурных костылей и прослоек достигает критического, или же изначально заложенные идеи начинают слишком уж мешать, и в итоге почти любой проект рано или поздно переписывается с нуля или почти с нуля. Иногда даже не раз. Netscape → Mozilla, Firefox → Servo (возможно), IE → Edge (не полностью с нуля, но уверяют о очень капитальных переделках), DOS/Windows 9x → Windows NT (в контексте ОС для десктопа), Win32 → UWP (или на чём там нынче под вин10 пишут, сильно не слежу), Mac OS 9 → Mac OS X, Blender 2.4 → Blender 2.5 ну и так далее.
Netscape → Mozilla, Firefox → Servo (возможно),

Firefox → Firefox Quantum — уже в бете.

UFO landed and left these words here
UFO landed and left these words here
По-моему логичнее идти к некой виртуальной машине-браузеру. Случайно создаваемая машина-песочница, которая не имеет возможности взаимодействовать с хостом и не может никак сообщить о нем и его пользователе, и не может нанести вред хосту.
Но XSS останется.
Веб кривой до невозможности, с этим трудно спорить. Но заменить его можно только сообща. Либо имея достаточно ресурсов, как у Фейсбука, например. И цель у них может быть соответствующая — навязать предоставить юзерам браузер (на самом деле небраузерный клиент к соцсети), который будет работать по очень хитрому протоколу (например как Скайп в своё время) и не допускать вырезания рекламы.
Вот тогда и не будет всяких XSS и нанесения вреда хосту.
Сразу возникает вопрос, а что делать с upload/download файлов? Если нет доступа к хосту то и нет доступа к файлам, в таком случае вещи из серии File API теряют смысл, что, в рамках современности, достаточно актуально, много приложение которые есть и будут завязываться на данную функциональность.
Да очень легко — при любом запросе к «настоящей» хостовой файловой системе пользователь видит системный запрос «разрешить xxx доступ к yyy?» и всё. В этом плане, если помните, очень удачно было реализовано в мобильных приложениях на J2ME — при обращении к файлам, сети, sms, к другому приложению всегда задавался запрос, который невозможно было обойти. И пользователь сам выбирал, какому приложению он доступ разрешит, которому запретит, а которому будет каждый раз по запросу решать.
Возможно, только, к сожалению, обычному обывателю такие запросы не очень нужны, он хочется пользоваться и не задумываться, увы, о том что и как внутри. А такие вещи заставляют думать :(((
Отмечу, что в Android 6+ сейчас примерно то же самое, что и в J2ME
Только вот про интернет он не спрашивает, да и про доступ к файлам или обращение/открытие других программ не припомню.
Да, поэтому лишь «примерно». Хотя про доступ к файлам у меня некоторые приложения таки спрашивали. Предположу, что текущий беспорядок с правами связан со всяким легаси, и доведение управления доступом до совсем как в J2ME — дело времени
Эх, ещё бы сделали чтобы при отказе приложение не падало и вообще не знало об отказе — а получало пустой результат… Тогда бы было не «как в j2me», а лучше :)
да и про доступ к файлам

спрашивает, если надо что то открыть не в своей локальной песочнице и к примеру на внешней флешки то нужны пермишены.
Тольуо увы у Android сейчас 3 разные системы для открытия файлов не из родной директории. :( Это куча костылей для каждой версии андроида.

Вы предлагаете вернуться во времена IE7 опять. Там эта "безопасность" была именно так и реализована. Вместо просмотра страниц тыкаем на постоянно всплывающее окно блокировок.

Вы видимо невнимательно прочитали. Я же пишу, что варианты ответа были не просто «да-нет», а «да-нет-всегда разрешать-всегда запрещать».
И 90% пользователей будет всегда нажимать «разрешать все», как сейчас запускает исполняемые файлы из непонятных источников.
Да, это проблема, согласен. Но её вообще никак не понятно, как решать — так что если хоть на оставшиеся 10% улучшится безопасность то уже хорошо.

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

Вообще не понимаю, откуда такой вывод (для пользователей, кто хоть немного разбирается). Если запрос на постоянно нужный приложению ресурс, типа интернета для браузера, то пользователь просто нажмёт «разрешать всегда». Если вообще лишнее, типа того же интернета для калькулятора или доступа к контактам для файлового менеджера — «запрещать всегда». И затем будут задаваться только запросы, которые пользователь считает что нужно каждый раз решать отдельно. С файлами и интернетом, кстати, можно реализовать в духе «разрешать всегда для директории /home/abc/def/*» и аналогично с сайтами.

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

Под это определение попадает меньше процента пользователей, это раз. Даже те, кто разбирается задолбаются разрешать приложению каждый чих и либо скажут «вот тебе права на всё, только отстань уже», либо снесут к чертям, это два.
А ещё случается так, что автор продаёт своё приложение не очень порядочным людям или сам решает срубить зелени (см. AdBlock с его «заплати и твоя порнуха реклама станет кошерной»), это три.

Хотя пример iOS с «либо ты думаешь как работать с урезанными правами, либо проваливай из магазина» показывает, что да, требовать можно. Иногда.
Даже те, кто разбирается задолбаются разрешать приложению каждый чих и либо скажут «вот тебе права на всё, только отстань уже», либо снесут к чертям, это два.

Когда они «задолбаются», если на большую часть запросов достаточно будет ответить один раз за всё время использования приложения? А оставшиеся разрешения — даже если поставят «разрешать всегда», всё равно будет лучше, чем сейчас.

При этом можно будет выкладывать/распространять/использовать конфиги разрешений для приложений, то есть достаточно взять чей-нибудь адекватный конфиг и будет уже неплохо для начала.
Вы (или в данном случае «простой пользователь») просто не настраивали файрволы.
UFO landed and left these words here
Такие вещи виртуальная машина возьмет от хоста при запуске, если разрешение на это будет определено пользователем.
То есть как сейчас с геолокацией и сервайсами?
Да, как приустановке приложений на Android.
К сожалению похоже современный веб все больше похож на реальный мир.
Масса публикаций на хабре в последнее время о том как пытаются следить за пользователем… ломятся в окна, в двери, смотрят что ешь, что заказываешь, что смотришь, что пишешь в email…
Отгородиться от веба высоким забором будет всё актуальнее.
Ставить AdBlock, Ghostery, NoScript, RequestPolicy и т.п. вещи — это не уровень обычного пользователя. Для массового пользователя необходима защита из коробки. С объяснением зачем необходимо то или иное разрешение.
image
Массового пользователя это не волнует. Кому-то нравится когда ему предлагают вечером заказать пиццу, починить машину… Даже если они этого не искали, а просто говорили об этом с друзьями.
Пока не волнует т.к. не видит связи. И это до момента когда например и банк и магазин будут отлично знать что пользователь искал и иметь возможность настойчиво предлагать кредит на покупку. А возможностей будет много — адресно на устройствах, которые он видит, на рекламных щитах мимо которых он будет проходить или проезжать, на скамейке в парке где он присядет.
«Если у вас паранойя, это еще не значит, что вас не преследуют». В таком мире будет востребована анонимность.
Для этого уже существуют соответствующие проекты. Зачем не просто делать велосипед, а изобретать самолёт с нуля?
Существование не означает известность или массовую доступность.
Проблема в том, что «кто платит, тот и заказывает музыку», а в Вебе платит как правило этот самый рекламодатель, заказывающий сбор данных и показы рекламы, а не конечный пользователь, за исключением отдельных платных сервисов по подписке\продаже.
Зачем крупным разработчикам бороться за приватность пользователей, если у них доход с продажи этой самой приватной инфы, хоть и опосредованный?
Пользователи будут покупать анонимность.
И много сейчас пользователей «покупает анонимность»? Хотя бы покупает услуги платных проки/VPN и т.п.? Большинству пользователей пофиг, наоборот реклама показывается более персональная, а 1% те кто не считают себя неуловимыми Джо (то есть нафиг никому не нужными) ставят VPN/Tor'ы и прочее.
Сейчас еще нет острой необходимости и понимания пользователями реализации своей потребности. Лет через 10 будут другие пользователи, как и способы адресной рекламы.
А как быть в ситуации, когда вам необходимо загрузить файл со своего хоста в приложение?
Как выше описали либо запрос пользователю либо некий модерируемый накопитель в песочнице, через который возможен обмен с хостом. Хотя логичнее будет просто использовать некий браузер для профессиональных целей.
Интересная статья. Но мне кажется, что автор оригинальной статьи сильно углубляется в детали реализации. Он советует какие форматы данных использовать, на каких языках программирования нужно писать. Вряд ли замена JSON на PBF решил проблемы с SQL инъекциями.
Мне кажется, что создавать новый Web нужно со стандартизации виртуальной машины, API браузера, API межпрограммного общения (аналоги OAuth и других протоколов в новой реализации). Нужно понимать, что современный Web не стоит на месте, браузеры внедряют новые возможности (работа со звуком и видео, уведомления на рабочем столе, HTTP/2). При разработке NewWeb нужно заложить расширяемость с учетом обратной совместимости. А вопросы IDE вообще не должны подниматься на этапе формирования идеи/концепции.
Ого, удивлен что никто еще не дал нормальной критики на статью, потому что автор совсем не разбирается в теме.

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

prepared statements оказались костылем, оооок. Я то думал что это основной способ делать sql запросы, к тому же безопасный.
Но теперь средний размер веб-страницы превышает 2 мегабайта, не говоря уже о веб-приложениях. Даже скучные веб-странички со статичным текстом часто содержат массу минифицированных скриптов, в которых без машинной помощи вы не сможете даже начать разбираться.

В бинарных программах еще сложнее разобраться. Где же плюсы?

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

А что, кто то мешает это сделать уже сейчас?

Вторая проблема в том, что машинам тоже сложно воспринимать URL'ы

Которые для этих же машин и писались, ооок.

Например, подумайте, что мешает вашему серверу установить куки для домена .com. А что насчёт kamagaya.chiba.jp?

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

Просмотр исходника определённо помог мне столько раз, что я не могу сосчитать

Зато предлагаемую автором бинарную хрень вы просто не прочитаете.

Результаты выполнения SQL-запроса нельзя нативно отправить по соединению HTTP или встроить в веб-страницу

Мне кажется автор предлагает добавить еще больше дырок в его реализацию.

Ещё одним способом выполнения этого требования может стать умная IDE: если позволить разработчикам сначала работать с нетипизированными структурами (всё что определяется как Any), среда выполнения может попробовать определить, какими должны быть исходные типы, и транслировать эту информацию обратно в IDE. Затем она может предложить замену на лучшие аннотации типов. Если разработчик сталкивается с ошибками приведения типа во время работы программы, то IDE может предложить снова ослабить ограничение.

Нехватало еще чтобы IDE было обязательным требованием для разработки.

Грустный приговор веб-платформе, что WebAssembly — единственная попытка добавить новый язык, и этим языком является C… на котором, я надеюсь, вы не захотите писать веб-приложения!

Я думаю здесь можно остановиться, ибо некомпетентность автора доходит до предела.
Wasm это все что сможет скомпилироваться в wasm, как минимум все что компилируется в llvm, а это уже не мало.

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

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

Да, это значит, что я хочу оставить возможность использовать JavaScript (на высокой скорости), помимо Ruby, Python, Haskell, и да  —  C, C++ и Rust тоже останутся в игре. Всё это возможно благодаря двум действительно классным проектам, которые называются Graal и Truffle, о которых я подробно рассказывал. Эти проекты позволяют JVM запускать даже код на неожиданных языках (таких как Rust) в виртуализированной среде, быстро и и интероперабельно

А кто мешает их гонять вместе с рантаймом поверх wasm? это по сути тоже самое, но оно уже реализовано!

Песочница OpenJDK годами подвергалась упорным атакам, и разработчики браузеров усвоили ряд болезненных уроков. Последний 0-day эксплоит датируется 2015-м годом, а предыдущий был в 2013-м. Всего два 0-day эксплоита в песочнице за пять лет — неплохо, на мой взгляд, особенно с учётом того,

с учетом того, что java потом из браузеров выкинули, и эксплойты стало писать не так рентабельно.

Бинарных структур данных недостаточно. Нужны ещё и бинарные протоколы

Которые уже есть. Тот же messagepack вполне себе эффективно гоняется по http.

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

Платформа которая хочет конкурировать с вебом, должна озаботиться вопросами собственной необходимости. Нам нужны: перечисление всего что с безопасностью слабо связано, например бинарные протоколы. И как же они улучшают безопасность? а вот дебажить все это — одно удовольствие.
Человеку просто хочется обратно в теплые ламповые времена когда тащили Oracle client package для подключения к ораклу из своего приложения, вот там всё было круто, а то наворатили тут понимаешь с вебом, куча слоёв и ничего не понятно.

Да, как раз хотел написать то же самое. Жесть на жести. Но про SQL и webAssembly круче всего. Уровень некомпетентности зашкаливает разумные пределы.

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

Первая статья была такой многообещающей — видимо потому, что в ней с умным говорилось про очевидные в общем-то недостатки современного веб-стека…
А вот выводы, к которым пришли — какой-то разочарование.


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


Конечно же, от такой статьи ждёшь каких-то глобальных идей, не привязанных к реализации и языку. И выводом из этой статьи должен был стать тезис о неизбежности приближения ОС к браузеру, браузера к ОС и их сингулярного слияния в одну сущность в недалёком будущем.
На смотря на провал ChromeOS и отсутствия кардинального развития desktop os начиная с появления оконных интерфейсов, этот процесс идёт, будет идти и неизбежно нас к чему нибудь приведёт.
Возможно, Javascript в таком мире не найдёт себе место, но скорее он видоизменится так, что от него останется лишь название. Ибо уже сегодня видны тенденции к ухода от языка "разработки" к языку "assembly", который возможно в дальнейшем можно будет прозрачно для пользователей и безопасно очистить от всего накопившегося говнеца.


Но, уж извините, хаять SQL, заменяя его на какого-то потомка KV и Protobuf, говорить что серверы должны возвращать через RPC фьючерсы (насколько я понимаю, фьючерсов нету нигде кроме Java мира), строгая привязка этого NewWeb к ООП (не из-за java, а исходя из выводов статьи, потому что "новая ORM" и тыды), какие-то там IDE…
И ни слова о том, что действительно важно, то что превалирует в комментариях к предыдущей статье: замене HTML как языка гипертекста на другой markup lang, сэндбоксинг, сохранение многообразия технологи, а лучше и его увеличение....


Эх, статья-статья. Грустно...

UFO landed and left these words here

Первая статья была такой многообещающей — видимо потому, что в ней с умным говорилось про очевидные в общем-то недостатки современного веб-стека…
А вот выводы, к которым пришли — какой-то разочарование.


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


Конечно же, от такой статьи ждёшь каких-то глобальных идей, не привязанных к реализации и языку. И выводом из этой статьи должен был стать тезис о неизбежности приближения ОС к браузеру, браузера к ОС и их сингулярного слияния в одну сущность в недалёком будущем.
На смотря на провал ChromeOS и отсутствия кардинального развития desktop os начиная с появления оконных интерфейсов, этот процесс идёт, будет идти и неизбежно нас к чему нибудь приведёт.
Возможно, Javascript в таком мире не найдёт себе место, но скорее он видоизменится так, что от него останется лишь название. Ибо уже сегодня видны тенденции к ухода от языка "разработки" к языку "assembly", который возможно в дальнейшем можно будет прозрачно для пользователей и безопасно очистить от всего накопившегося говнеца.


Но, уж извините, хаять SQL, заменяя его на какого-то потомка KV и Protobuf, говорить что серверы должны возвращать через RPC фьючерсы (насколько я понимаю, фьючерсов нету нигде кроме Java мира), строгая привязка этого NewWeb к ООП (не из-за java, а исходя из выводов статьи, потому что "новая ORM" и тыды), какие-то там IDE…
И ни слова о том, что действительно важно, то что превалирует в комментариях к предыдущей статье: замене HTML как языка гипертекста на другой markup lang, сэндбоксинг, сохранение многообразия технологи, а лучше и его увеличение....


Эх, статья-статья. Грустно...

насколько я понимаю, фьючерсов нету нигде кроме Java мира

Неправильно вы понимаете.

Я хотел сказать, что почему бы какому-нибудь виджету не подписаться на канал PubSub и не изменять состояние вместе с новыми сообщениями?
Или к примеру использовать fibers, channels, actors и ещё кучу разной технологии, которая не привязана к Java/C#/JS коллбэчистому стилю программирования?

Кстати, в дополнение к новому языку разметки, вполне допустимо оставить например CSS или аналог. Это позволит использовать различные темы в приложениях, системные и кастомные.
Также возможна реализация единой виртуальной машины, встроенной в систему. В байткод этой ВМ будут компилироваться все языки, что также увеличит многообразие. Ну а ОС будут реализовывать стандарт этой ВМ и пытаться сделать более быструю и крутую реализацию)
Эх, розовые мечты…

Я ещё не дочитал статью, но уже возмущён:


Создание GUI в Matisse, редакторе UI с автоматическим выравниванием и ограничителями. Да здравствует (новый стильный) король?

Автор уже который раз (и в первой статье и в этой) рассуждает так, как будто перетаскивать кнопочки мышкой на формочку — удобнее, чем писать код (html/css/js).


Нет, это не так! По многим причинам:


  1. В GUI вы можете разместить кнопочку на окне фиксированного размера. Совершенно непонятно, что произойдёт с ней, если окно другого размера. Или экран другого размера. Когда у пользователей есть и компьютеры с мониторами самых разных размеров и разрешений, и планшеты, и телефоны (а у планшетов и телефонов есть ещё горизонтальная и вертикальная ориентация), нам бы хотелось, чтобы интерфейс работал при любом разрешении и размере экрана. Когда мы пишем код руками, мы сразу можем задать поведение (всякие Media Queries и разные обёртки над ними). Когда мы делаем интерфейс в GUI, нам нужно отдельно как-то задавать поведение.
  2. Тыкать мышкой GUI — просто медленнее, чем писать код.
  3. Как это потом хранить и версионировать? А как мержить? Это же всё равно хранится во всяких файлах (xml?). То есть, нам всё равно придётся работать с текстовыми файлами. Так давайте сразу работать с текстовыми файлами и затачивать наши инструменты для работы с текстовыми файлами.
В GUI вы можете разместить кнопочку на окне фиксированного размера. Совершенно непонятно, что произойдёт с ней, если окно другого размера. Или экран другого размера.

В нормальных GUI для создания GUI это вообще не проблема. Помню, ещё во времена Delphi можно было нормально мышкой накидать форму с динамической расстановкой элементов.
Сейчас можно глянуть на дизайнер UI в Android Studio: там можно сразу посмотреть макет на разных экранах, использовать всю мощь всяких разных LayoutManager-ов, прибиндить разметку к данным, и тд


Тыкать мышкой GUI — просто медленнее, чем писать код.

Далеко не всегда. Иногда удобнее написать код, иногда набросать мышкой элементы на форму, иногда чередовать


Как это потом хранить и версионировать? А как мержить? давайте затачивать наши инструменты для работы с текстовыми файлами

Так вот эти GUI-билдеры и есть заточенный инструмент. Под капотом они просто передвигают блоки кода и просто рендерят это всё на экран сразу. Версионировать и мёржить всё это можно точно так же, как и текст (потому что это и есть текст).

Помню, ещё во времена Delphi можно было нормально мышкой накидать форму с динамической расстановкой элементов.

Я помню, как во времена Delphi я с этим мучился, и я знаю, насколько просто это сделать сейчас, с помощью HTML и CSS. Особенно, если взять какой-нибудь фреймворк типа бутстрапа, где всё уже сделано.


Так вот эти GUI-билдеры и есть заточенный инструмент. Под капотом они просто передвигают блоки кода и просто рендерят это всё на экран сразу. Версионировать и мёржить всё это можно точно так же, как и текст (потому что это и есть текст).

Да, я про это и говорю. Если нам нужно что-то смержить, нам всё равно надо будет лезть в код. Следовательно, нужно одновременно понимать, как этот код работает и помнить, куда нужно ткнуть мышкой, чтобы сделать кнопку. То есть, эти GUI не избавляют нас от сложности, они добавляют ещё один уровень сложности.

То есть, эти GUI не избавляют нас от сложности, они добавляют ещё один уровень сложности.

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

А вообще, ИМХО, чтобы веб-стандарты превратились в хорошие стандарты построения (общих) приложений, им не хватает многоуровневости: должны быть API/стандарты и более низких уровней, чем в W3C Web.
Эта статья вместе с предыдущей обозначила очень важную проблему современного интернета -обосрать чужое значительно проще, чем сделать хоть что-нибудь своё.
Предвкушал фееричность продолжения уже после первых абзацев первой части. Выше есть отличный комментарий, от себя добавлю только одну вещь, которую я не могу развидеть: автор называет деминификатор компилятором, а после этого рассуждает на тему концепции веба будущего, это просто занавес.
Как говорится «И ляпай. Но ляпай уверенно. Тогда это называется точкой зрения.» ©
UFO landed and left these words here
почему то никто не вспомнил silverlight?
Если бы микрософт не пыталась захватить мир и открыла технологию для всех то может быть взлетело.
Лет десять назад попалась мне статья о том что Yahoo! пыталась разработать стандарт web, основанный на использовании прямых запросов к серверам баз данных, в которых хранятся данные одновременно об интерфейсе и наполнении. Иными словами, браузер, как клиент, при подключении к ресурсу напрямую обращается к серверу БД и получает из БД структуру страницы (+ поведение) и наполнение.
Этот проект Yahoo тогда забуксовал. Хотя, по-моему, работа web на серверах БД дала бы ряд преимуществ: упрощение, универсализация, масштабирование, скорость. Интернет превратился бы в совокупность взаимосвязанных БД и клиентов к ним. Это не отменяло бы работу традиционного web, но браузеры могли бы работать дополнительно и в таком режиме.
Двадцать минут потратил чтобы найти статью — никак.

А чем это отличается от того, чтобы обращаться к прикладным серверам, которые возвращают "данные об интерфейсе и наполнении"?

Если Вы имеете ввиду обращение к традиционным web-серверам, то их функционирование сложнее: отдельно шаблоны или генерация шаблонов, отдельно css, отдельно генерация HTML-кода страниц с необходимым функционалом из скриптов, написанных на разных языках(php, asp и т.д.), + подтянутым из прочих подключаемых скриптов (js и тд), отдельно web-серверы, БД отдельно — короче, куча модулей. В то время как теоретически всё это можно заменить серверами баз данных и свести к универсуму.
Насколько я понимаю.
В то время как теоретически всё это можно заменить серверами баз данных.

… которые будут выполнять те же самые функции (потому что кто-то же должен их выполнять). В чем отличие-то?

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

Почему вдруг? То, что вы раньше писали для прикладного сервера, придется писать для БД.


и масштабирование

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

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

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


В БД легко создавать любые структуры и связи между сущностями.

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

TLDR; возможность писать сайт в блокноте — один из его столбов.
Вот только среди веб разработчиков много любителей не особо умных IDE в стиле sublime, notepad++, vim. Плюющихся при любой попытке подсунуть что-то с кучей интерфейсов, которыми проще всего управлять мышкой.
не особо умных IDE в стиле sublime, notepad++, vim

Про sublime ничего не знаю, но когда это редакторы с подсветкой кода и макросами типа notepad++ и vim стали IDE?
если бы микрософт запилила нормальный магазин приложений в начале 2000-х и интегрировала его в винду, то кому были бы нужны эти веб приложения?
UFO landed and left these words here

SQL и PHP относятся к бэкенду, и мешать они могут разве что его разработчикам, но никак ни вебу в целом.


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

По-моему лечится вкладкой "Console" в инструментах разработчика

UFO landed and left these words here

OpenOffice, который пытается распарсить xls, не всегда успешно. Архиваторы на Windows, которые не всегда понимают архивы сделанные на Mac.


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

UFO landed and left these words here

То есть вас не смущает, что множеству разработчиков приходится реверс-инжeнeрить формат XLS, придуманный Майкрософтом, вместо использования какой-нибудь свободной спецификации?

UFO landed and left these words here
http2 кое-какие беды порешал…
И добавил новые, посидите на нём с плохой связью (которая может быть и внезапно на стороне хостинг-провайдера). У вас его «конвейер» встанет и вся сессия повесится на несколько минут. Для обычного пользователя поможет только выход из обозревателя. Короче HTTP2 плох если пакеты вдруг теряются. Пока сам не нарвался, относился к этому скептически.
Веб взял верх над Delphi и Visual Basic не потому что JavaScript настолько крут. Есть более глубокие причины.


Т.е. вы хотите сказать что жопоскрипт-таки «крут»? Перед расстрелом из реактивного говномёта дадим автору шанс и сделаем вид будто он просто некорректно составил предложение. Ну или на худой конец, что подобная нелепица — погрешности перевода.
Only those users with full accounts are able to leave comments. Log in, please.