Anatoly MoskovskyВладимир2012Неудачная /мягко сказано/ архитектура WWW
Как может быть неудачной архитектура платформы, которой пользуется половина населения Земли, а объем трафика растет экспоненциально последние 15 лет?
Ровно так же, как и x86-тая

Коммерческий успех и "архитектурность" вещь конечно связанные, но не 100%.

Современный www, это как современный x86. Идеи 20-30 летней давности сдобренные бесконечным кол-вом дополнений и расширений

IMHO

Про WebComponents ничего сказать не могу, т.к. даже не знаю, что данный термин обозначает )))

Весь веб пошел от HTML (Hypertext Markup Language) и/или SGML (Standard Generalized Markup Language)

Как язык СТАНДАРТНОЙ разметки ДОКУМЕНТОВ (а не средство разработки мультимедиа, приложений, рекламы и так далее ))) ) он провалился более чем полностью:
1. Проблема стандартизации и кросс-браузерности до сих пор существуют. Все браузеры кто в лес, кто по дрова
2. Как язык разметки документов, вообще не прижился и не удобен. Лично я всю жизнь RTF-ом пользуюсь, за "стандарт" готов еще PDF признать. Но что бы кто-то серьезно воспринимал идею документы хранить в HTML последних версий... я даже такого не помню. Средства отчетности конечно умеют и HTML генерировать ))), но это обычное такое убожество )))
3. По удобству использования (для пользователей).... ну я как-то пытался sql.ru почитать без мышки (батарейка села) - занятие не из легких. В Windows 7 работать кое-как можно, в Eclipse кодить можно (хотя shourtcut'ы совершенно убожеские), sql.ru - проще повеситься.

Т.ч. изначальных концепт полностью провалился и все последующее использование доказала полную несостоятельность изначального стандарта. IMHO

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

А HTML просто повезло.
1) Он был первыми на рынке, когда начался бум связи (в hardware) - т.ч. при "всем богатстве выбора другой алтернатывы не было" ( C ) реклама /немного изменено/.
2) Он был открытым (в чем был залог успеха и IBM PC)
3) Он был достаточно прост, т.ч. многие могли повторить его реализацию (клоны IBM PC)

IMHO & AFAIK

p.s. Почитал что такое SPDY и HTTP/2.0 -
понятно, что расширения HTTP. Которые пытаются (и не факт, что получается) устранить недостатки изначального протокола *. Только вот интересно, насколько эти расширения в целом сейчас используются и насколько обеспечивают выигрыш.

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

* - почему сомневаюсь в успешности:

Лечат следствие, а не болезнь. Попытки сделать "Основной задачей SPDY является снижение времени загрузки веб-страниц и их элементов[6]. Это достигается за счёт расстановки приоритетов и мультиплексирования передачи нескольких файлов таким образом, чтобы требовалось только одно соединение для каждого клиента."

без слома основного порока HTML с его развесистой клюквой файлов/картинок/скриптов - еще один костыль к web 20-30 летней давности. А ломать основу - полностью потерять всякую совместимость.

IMHO & AFAIK

Изопропилс коммерческим успехом - понятно, что есть "архитектурность"?

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

В сети попадался доклад Вирта на какой-то ООП-конференции в конце 90-х, смысл был примерно следующий "смотрю, что мы за последние 10-ть лет с языками программирования сделали, но ведь сделать-то хотели совершенно другое" )))

Изопропила как без картинок/ресурсов в том же rtf и pdf?
Они там как минимум внутри (или могут быть внутри).

В языках программирования, ресурсы обычно можно собрать в модули и управлять их загрузкой. (например оверлей в Turbo Pascal, jar в java)

skyANAМожете процитировать то, на основании чего Вы пришли к выводу, что SPDY и HTTP/2.0 - это расширение HTTP?
СловарьСинонимов где-то в Инетрасширение

продолжение , распространение, рост, развертывание, увеличение; растяжение; пополнение; иррадиация, растягивание, расколачивание, раскрытие, разрастание, возрастание, разбухание , клеш, рассверливание, разбуравливание, дилатация, разращение, наращивание, растачивание, развитие , эктазия, наращение, уширение, расставка, набухание, рассверловка, паректазис, экспансия, раструб, усиление, углубление, ширение, эскалация, раздувание, разверчивание


Словарь_ЕфремовойРасширение
ср.
1) Процесс действия по знач. глаг.: расширить, расширять, расшириться, расширяться.
2) Состояние по знач. глаг.: расшириться, расширяться.
3) Более широкая, постепенно расширяющаяся часть чего-л.
4) Патологическое увеличение размеров (сердца, сосудов и т.п.).

Последнее IMHO лучшим образом характеризует всю It-индустрию в последние годы )))

Как минимум того, что:
1) сохранена обратная совместимость с HTTP
2) заявленные цели, как минимум по версии Wiki, попытка устранения недостатков исходного протокола. О предоставлении каких-то новых принципиальных возможностей речи и не идет.
При этом именно попытка, т.к. кардинального решения проблемы не предлагают. Просто оптимизация (бинарный формат, сжатие). Сжатие и до этого использовалось.
3) в связи с пунктом 1 + 2, для меня как программиста, что исходный HTTP, что HTTP 2.0 - одно и то же. )))
Считать это чем-то самостоятельным? С учетом, что уже как минимум они умудрились сделать 4-ые версии протокола SPDY + версию HTTP/2 - IMHO совершенно эволюционное развитие. Вынужденное наследовать пороки решений 20-30 летний давности.

Изопропилэти оверлеи с давних времён были от бедности(нехватки как минимум адресного пространства)
померли с появлением страничной памяти (на мейнфреймах раньше, чем появились персоналки)
В общем-то, название Dynamic Linking Library говорит само за себя )))

Никто не мешает загружать-выгружать DLL'ки. Лично я, когда участвовал в создании системы в начале 2000-х, подсистему обработки изображений динамически загружал/выгружал. Т.к. занимать в 2-а раза больше памяти, чем нужно приложению, нафиг надо. А Image Magic в памяти занимал почти столько же, сколько и весь Oracle Forms 6i Runtime

AFAIK большинство API нормальных библиотек имеют функции для "память запрошенную вернуть" и "хэндлы позакрывать". Лично я ни с одним API, где это бы требовало "выгружать DLL" (за исключением багов) - не сталкивался.

Я не путаю. Просто никто не мешает такой функционал и сейчас использовать. Другое дело, что сейчас память под код пока еще обычно хватает ))) Хотя, глядя как мой телефон на андроеде работает после установки штук 5-и приложений, я в этом уже не уверен )))

Риторический вопрос: почему в 2016 г, для ввода даты-время мне требуется какие-то дополнительные виджеты дли bootstrap искать и скачивать? Мне кажется, охарактеризовать такую ситуацию можно только матным словом.