Не сайты медленные, а браузеры, которые как раз и есть десктопные приложения.
Сайт не может быть быстрым или медленным. Это всего лишь текст. Медленным может быть тот кто текст оьрабатывает
Здравствуйте, vsb, Вы писали:
vsb>Все жалуются на медленные сайты. Ну в принципе правильно жалуются, я в целом согласен. Десктопные приложения пошустрей работают. vsb>Но жаловаться любой дурак может. А вот что бы вы сделали по-другому? Чтобы при этом не терять удобство использования веба, которое есть сейчас.
1. Отвязаться от интерпретатора JS. WebAssembly — не плохое решение.
2. Добавить для WebAssembly полноценный доступ к DOM и видеокарте (на уровне GLSL).
Но вообще все к тому и идет — вопрос времени.
Т.е., как сказал один чел, браузер превратится в вирт. машину + графический движок.
vsb>Десктопные приложения пошустрей работают. vsb>что бы вы сделали по-другому? Чтобы при этом не терять удобство использования веба, которое есть сейчас.
Каждой странице свою виртуальную машину с WinXP, пусть скачивает туда бинарники на C++ и C#.
Здравствуйте, vsb, Вы писали:
vsb>Все жалуются на медленные сайты. Ну в принципе правильно жалуются, я в целом согласен. Десктопные приложения пошустрей работают.
Вы видели как работал flash. Так же и веб он утилизирует типовые ресурсы. Если они чуть ниже тормозит, если выше вроде терпимо.
Такое отношение к ресурсам.
vsb>Но жаловаться любой дурак может. А вот что бы вы сделали по-другому? Чтобы при этом не терять удобство использования веба, которое есть сейчас.
Что называется удобством. Что разработку можно разбить по разным узкоспециализированным специалистами и делать деньги.
Что бы что-то делать по другому надо сформулировать цели которых хочется достичь.
Здравствуйте, vsb, Вы писали:
vsb>Но жаловаться любой дурак может. А вот что бы вы сделали по-другому? Чтобы при этом не терять удобство использования веба, которое есть сейчас.
Отобрал бы у разработчиков навороченные компы и выдал бы каждому средний пользовательский терминал.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, vsb, Вы писали:
vsb>Все жалуются на медленные сайты. Ну в принципе правильно жалуются, я в целом согласен. Десктопные приложения пошустрей работают.
Давай для начала разделим.
1. Клиентская программа имеет базу данных.
2. Клиентская программа не имеет базы данных.
В базе данных клиентская программа может хранить скачанные с серверной программы данные. Причём делать оно это может оптимальным образом, перезаписывая данные транзакциями, чтобы ускорить запись на порядок или даже порядки, а так же не насиловать лишний раз диск, в особенности SSD.
Так вот особенность браузеров в том, что у них нет базы данных, у них есть кеш для данных. И поскольку они не знают схему данных, не имеют вспомогательных данных для блокировок, таких как оптимистические и прочие, то и обновить данные оптимальным образом они не могут.
А ещё в вебе нет разницы между данными и графикой, что при каждом запросе накладывает дополнительные расходы на получение данных.
Потому фактически есть всего лишь два выхода.
1. Создаётся какая-то особая клиент-серверная программа и она идеально управляет данными и их обменом как на сервере, так и на клиенте. В случае распределённой программы разницы между клиентом и сервером может как таковой и не быть.
2. Продолжаем использовать обычный веб. А это заметь тоже клиент-серверные программы, которые являются стандартом лишь потому, что их считают стандартом, а в реальности вместо них можно нагородить всё, что угодно. Но в этом случае уменьшаем поток данных, то есть оптимизируем веб. Убираем оттуда лишний текст, ненужные клиентские скрипты и прочее.
Думаю никто не будет спорить, что во втором варианте с вебом можно достичь выдающихся результатов насколько это возможно, когда каждый раз для обновления нужно отправлять запрос на сервер.
Вот только есть одно но, в первом случае программа может сохранять данные на клиенте или в случае распределённой программы клиент сервере. Причём оно может делать это с теми же веб-страничками, конечно по умному нужно сохранять содержимое, а не обрамляющую графику, скрипты, рекламу и прочий мусор.
В итоге программа, которая синхронизируется с сервером, а часть данных оптимально хранит в базе данных очевидно будет превосходить программу кэширующую случайные данные, такое как браузер. А как это сделать описано в книге Мартина Фаулера "Архитектура корпоративных программных приложений". Но то, что мы это знаем никак не отменит тот же традиционный веб.
И я ещё раз подчеркну следующее обстоятельство. Сам html и css это формат данных и это одно. Его можно хранить в базе данных той же распределённой программы. А вот http это совершенно другое. Проблема именно в http, не в html и css, потому и отказываться нужно будет от http, но не от html и css.
Теперь давай предположим, что некто создал вариант с распределённым обменом. Пользователю дали возможность настроек, сохранять ли только изменения, сохранять всё, ничего не сохранять, сохранять только просмотренное и так далее. У него есть возможность видеть занятые у него на диске данные и выборочно чистить всё, что он хочет с помощью мощного фильтра.
То есть мы дошли до стадии, когда можно хранить полные зеркала сайтов с одной стороны, и ничего не хранить с другой. И каждый раз формат данных оптимален без лишнего мусора, дублирований и прочего. Но теперь возник вопрос, нужно будет продвинуть эту технологию в народ.
А здесь мы приходим к тому, что какой-то браузер есть везде, но вот такой клиент-серверной программы может и не быть. Для заманивания всё равно придётся делать обмен по http со всеми его минусами. Так же эплы могут посчитать, что такой программе не место на их платформе. Тоже самое с сони, нинтендо и прочими.
И только, если создатель интернет ресурса создаст его на этом движке, а пользователи скачают клиент, опять же в случае распределённого приложения они скачают тоже, что установлено на сервере, то есть клиент-сервер в одном флаконе, только тогда появятся все те самые эффективные особенности, которых нет в http.
Фактически нужно создать CMS, причём оптимальным выбором будет C++, которая заменит как сервер, так и клиент. А сама она ко всему прочему будет воплощать как протокол распределённого обмена, так и традиционный файловый и http доступ. Вот насколько эта CMS распространится, настолько и удачным будет замена или дополнения традиционного http.
И ещё раз повторюсь html и css вполне можно продолжить использовать в полях документа, даже если отображение идёт с помощью сторонних виджетов десктопного приложения, наглядный пример Qt. А как создать разные виды для десктопа и веб так же описано в той же книге Мартина Фаулера.
Потому думаю финальный ответ на твой вопрос новый вид CMS, что, кстати, вполне доступно очень крутым разработчикам C++, коих мало и к коим лично я не отношусь, но всё же.
Здравствуйте, vsb, Вы писали:
vsb>Все жалуются на медленные сайты. Ну в принципе правильно жалуются, я в целом согласен. Десктопные приложения пошустрей работают.
vsb>Но жаловаться любой дурак может. А вот что бы вы сделали по-другому? Чтобы при этом не терять удобство использования веба, которое есть сейчас.
1) сделать загрузку контента однопоточной.
на целероне с одним ядром cel 540M очень даже заметно )) как ютуб прогружается.
при этом сам ноут заточен под 64бит. недавно перестал грузиться с двумя плашками. теперь 890МБ + 128МБ видео.
все это 2008 года выпуска.
при этом убунта 2009 летает. xp летает. и даже IE летает(видимо потому что не умеет в многопоточность). правда не грузить почти ничего.
а вот ФФ 102 открывает ютуб минут 5 минимум. а вот видео без тормозов воспроизводится.
2) запретить делать рич контент.
никаких скриптов на клиенте. голый html. я бы даже css запретил. пусть будут только нативные контролы.
тогда гарантированно будет летать. и тут же очевидный плюс — сайт будет выглядеть так как удобно пользователю,
а не коммерсам и дизайнеру.
а сколько кислорода сбережем! привет гуглам и прочим зеленым реактивщикам.
никакой реактивности!
Здравствуйте, Нomunculus, Вы писали:
Н>Не сайты медленные, а браузеры, которые как раз и есть десктопные приложения. Н>Сайт не может быть быстрым или медленным. Это всего лишь текст. Медленным может быть тот кто текст оьрабатывает
Ведущий разработчик Яндекс.Деньги Андрей Мелихов (также редактор/переводчик сообщества devSchacht) на примере движка V8 рассказывает о том, как и через какие стадии проходит программа, прежде чем превращается в машинный код, и зачем на самом деле нужен новый компилятор.
Напоминаю, что движок V8 используется в Chrome/Chromium и Node.js.
УП>Отобрал бы у разработчиков навороченные компы и выдал бы каждому средний пользовательский терминал.
Сразу видно, что учил в институте философию еще в СССР...
Бытие определяет сознание — оно самое и есть!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Сразу видно, что учил в институте философию еще в СССР... LVV>
Не, не дорос я тогда до изучения философии, еще в школе учился, когда СССР не стало.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
LVV>>Сразу видно, что учил в институте философию еще в СССР... УП>Не, не дорос я тогда до изучения философии, еще в школе учился, когда СССР не стало.
Вот она — советская школа!
Как мои первые выпуски 1999-2003 года — все в советской школе учились, все умные!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, vsb, Вы писали:
vsb>Все жалуются на медленные сайты. Ну в принципе правильно жалуются, я в целом согласен. Десктопные приложения пошустрей работают. vsb>Но жаловаться любой дурак может. А вот что бы вы сделали по-другому? Чтобы при этом не терять удобство использования веба, которое есть сейчас.
Я считаю, что веб хорош как есть. Проблема в браузерах и в нежелании разработчиков сайтов заниматься оптимизацией своего кода.
O>>Чтобы все сайты стали пальцем деланные? УП>Колхозный фронтэндщик в теме? Да, лучше пальцем, чем тем местом, которым вы код пишете.
Почему у тебя от этой фразы так взбомбануло?
Здравствуйте, vsb, Вы писали:
vsb>Все жалуются на медленные сайты. Ну в принципе правильно жалуются, я в целом согласен. Десктопные приложения пошустрей работают. vsb>Но жаловаться любой дурак может. А вот что бы вы сделали по-другому? Чтобы при этом не терять удобство использования веба, которое есть сейчас.
Я бы сделал быстрые сайты. При текущем уровне развития веба это сделать можно. RSDN же быстро работает.
