Здравствуйте, Alekzander, Вы писали:
A>Давай не будем перескакивать с одного на другое. Полно приложений, которые не "поднимается локальный веб-сервер в одном процессе, запускается целый браузер в другом процессе", а просто используют webview в основном процессе, и открывают в нём локальный HTML-ресурс. А дальше уже он изнутри на JS работает с DOM. К их авторам какие претензии? Почему они должны выкидывать JS на свалку истории? JS, конечно, реально отстойный по сравнению с лучшими скриптовыми языками, но всяко больше для этого подходит, чем манипулирование DOM'ом на нативном языке снаружи. Хотя бы тем, что бизнес-логика автоматически отделяется от чисто интерфейсных вещей.
Что значит "манипулирование DOM снаружи"? Может не нужно было DOM наружу выносить и тогда нативный язык был бы не снаружи?
А то сами себе проблемы создали, героически придумали как их обойти, а потом ещё радуются что интерфейсные вещи отдельно от бизнес-логики.
Ну, да, приходится объекты из бизнес-логики сериализовать в json, чтобы потом их из JS парсить и распихивать по DOM — очень оптимально.
A>Кстати про предков. Как же с облегчением вздохнули юзеры одного продукта в 2003 году, когда загрузчик-хранилище файлов вынесли из внутрипроцессного COM-сервера в локальный (отдельный процесс). Он перестал, наконец, при крешах, связанных с импортом кривых файлов плохо специфицированных форматов, утягивать за собой само приложение с расчётными модулями. Хотя приложение и замедлилось за счёт передачи данных... аж на 5%, наверно.
Ну, тогда нужно каждую кнопку в отдельной процесс вынести, а то вдруг чего где не обработано, а любая ошибка может уронить всё приложение.
A>Ты хоть раз через профайлер GUI-приложение прогонял? Если бы да, знал бы, чтО там реально тормозит. (И нет, это не парсер). Это копеечная оптимизация, которая на общий расклад вообще не влияет, зато испоганит жизнь тысячам разработчиков, которые не смогут больше просто в ресурсы заглянуть и посмотреть, что там.
А ты прямо так в профайлере проваливаешься и изучаешь?
Или просто: ну, у меня пустое окно без разметки открывается 10 секунд, а заполненное — 11 секунд — ну, значит всё норм, секунда погоды не делает?
Прямо отдельно в недра движка браузера лезешь, выискиваешь отдельно парсер, отдельно рендер?
Или чисто от балды взял?
Ну, тогда нужно начинать с того, что нативной библиотеке не нужно тянуть сотню мегабайт библиотек от движка браузера.
Даже если сам парсинг будет быстрый, всё в сумме даст потерю и по памяти и по скорости.
A>Сейчас, допустим, есть у тебя dll, в которой собраны все ресурсы и HTML. Ты придумал какой-то компилированный бинарный формат. И опачки — уже без выгрузки в файл и декомпиляции не посмотришь на него. А ради чего? Ты это ускорение в микроскоп не увидишь.
т.е. *.cpp файлы не нужны? Они компилируются в какой-то придуманный бинарный формат и даже с декомпиляцией dll исходники не достать.
Ну, всё, переходим на JS, а то все эти ускорения нативных языков в микроскоп не увидишь.
Почему тот же XAML можно скомпилировать, а HTML — нельзя и обязательно вместо него нужно что-то бинарное придумывать?
A>Я думаю, так рассуждать могут только те, кто далёк от реального GUI-строения. И вообще, сильно похоже на бабкино нытьё на лавочках: нынче молодёжь распоясалась, GUI не компилируют, то ли дело мы...
Если раньше много однотипного дурацкого кода писали на "нативных" языках, это сильно раздражало, но достаточно легко отлаживалось за счёт имеющихся отладчиков.
То сейчас по-моему отлаживать GUI — то ещё приключение. Что HTML отлично отлаживается, что CSS туда же, а уж раскиданный везде JS — ещё веселее, особенно когда половину делают фреймворки.
