История изменений
Исправление user_id_68054, (текущая версия) :
Не знаю, что лучше - html5 или flash, но ИМХО flash легче html5 только из-за того что в его время компы были слабее.
в каком смысле легче? flash использовался восновном только для повышения полномочий, типа там проброс сокетов (когда не было websocket), или получения доступа к микрофону.
альтернативный подход в браузерах был - когда сервисы требовали установку плагинов в браузеры.
альтернативный подход — это когда сайты используют фрэймворки сделанные на со стороны самого сайта (js) вместо того чтобы использовать CSS. только это дурацкий подход вышел на практике, так как тормоза от js — неимоверные.
спасти всё это может только «webassembly», при условии что фрэймворки будут компилироваться в WASM-код.
это (фреймворки на webassembly) может сдержать БЕСКОНЕЧНЫЙ рост усложнения CSS (в дальнейшем), так как разработка бесконечнйх усложнений перейдёт в руки разработчиков фреймворков (уйдёт с плеч разработчиков web-браузеров).
js-фреймворки со своей задачай справляются только на теоретическом уровне (всё тормозит и долго загружается — дольше чем сам контент сайта :)).
в каком-то смысле это напоминает ситуацию которая как раз образовалась в Wayland — теперь композитор занимается только композитной работой — а различные GUI-toolkit-ы уже сами могут усложняться как хотят (в том числе усложнять Client-Side-заголовок окна :))
Исходная версия user_id_68054, :
Не знаю, что лучше - html5 или flash, но ИМХО flash легче html5 только из-за того что в его время компы были слабее.
в каком смысле легче? flash использовался восновном только для повышения полномочий, типа там проброс сокетов (когда не было websocket), или получения доступа к микрофону.
альтернативный подход в браузерах был - когда сервисы требовали установку плагинов в браузеры.
альтернативный подход — это когда сайты используют фрэймворки сделанные на со стороны самого сайта (js) вместо того чтобы использовать CSS. только это дурацкий подход вышел на практике так как тормоза от js — неимоверные.
спасти всё это может только «webassembly», при условии что фрэймворки будут компилироваться в WASM-код.
это (фреймаорки на webassembly) может сдержать БЕСКОНЕЧНЫЙ рост усложнения CSS (в дальнейшем), так как разработка бесконечнйх усложнений перейдёт в руки разработчиков фреймворков (уйдёт с плеч разработчиков web-браузеров).
js-фреймворки со своей задачая справляются только на теоретическом уровне (всё тормозит и долго загружается — дольше чем сам сайт).
в каком-то смысле это напоминает ситуацию которая как раз образовалась в Wayland — теперь композитор занимается только композитной работой — а различные GUI-toolkit-ы уже сами могут усложняться как хотят (в том числе усложнять Client-Side-заголовок окна :))