Сообщение Re[7]: C# vs Dart - перспективы от 27.08.2023 11:09
Изменено 27.08.2023 11:20 Alekzander
Re[7]: C# vs Dart - перспективы
Здравствуйте, karbofos42, Вы писали:
K>Разница в том, что сейчас часто ради веб-UI в десктопном приложении по сути поднимается локальный веб-сервер в одном процессе, запускается целый браузер в другом процессе и всё это обменивается json-чиками, т.к. нужно реализовывать IPC.
K>Если уж XAML всякие не нравятся и хочется именно HTML, то можно рендеринг так же в процесс библиотекой подключить и не ходить через огороды типа того же WASM.
K>WPF, Qt и другие библиотеки ведь как-то работают без всех этих усложнений.
Давай не будем перескакивать с одного на другое. Полно приложений, которые не "поднимается локальный веб-сервер в одном процессе, запускается целый браузер в другом процессе", а просто используют webview в основном процессе, и открывают в нём локальный HTML-ресурс. А дальше уже он изнутри на JS работает с DOM. К их авторам какие претензии? Почему они должны выкидывать JS на свалку истории? JS, конечно, реально отстойный по сравнению с лучшими скриптовыми языками, но всяко больше для этого подходит, чем манипулирование DOM'ом на нативном языке снаружи. Хотя бы тем, что бизнес-логика автоматически отделяется от чисто интерфейсных вещей.
A>>Попробуй на плюсах типичный сложный случай реализовать, где в одном куске ивент хендлер, лямбда, замыкание, отложенный вызов, и создание кучи объектов. И поуправляй памятью для всего этого дела. А при работе с разметкой это именно типично. Если у тебя реально rich UI приложение, а не очередной хелло-ворлд.
K>А кто-то людям мешает для плюсов нормальную библиотеку сделать?
K>В моей жизни были и голый WinAPI и MFC и wxWidgets, как-то управлял памятью, не умер.
Когда-то вообще перфокарты юзали и... БЛИН! Они все умерли!!
Хреновый это аргумент — что наши предки без современных удобств обходились, и ничего.
Кстати про предков. Как же с облегчением вздохнули юзеры одного продукта в 2003 году, когда загрузчик-хранилище файлов вынесли из внутрипроцессного COM-сервера в локальный (отдельный процесс). Он перестал, наконец, при крешах утягивать за собой само приложение с расчётными модулями. Хотя приложение и замедлилось за счёт передачи данных... аж на 5%, наверно.
K>Зачем нам GUI компилировать, мы будем в рантайме парсить HTML, дабы сформировать его DOM, чтобы и память сожрать и процессор не бездельничал.
Ты хоть раз через профайлер GUI-приложение прогонял? Если бы да, знал бы, чтО там реально тормозит. (И нет, это не парсер). Это копеечная оптимизация, которая на общий расклад вообще не влияет, зато испоганит жизнь тысячам разработчиков, которые не смогут больше просто в ресурсы заглянуть и посмотреть, что там.
Сейчас, допустим, есть у тебя dll, в которой собраны все ресурсы и HTML. Ты придумал какой-то компилированный бинарный формат. И опачки — уже без выгрузки в файл и декомпиляции не посмотришь на него. А ради чего? Ты это ускорение в микроскоп не увидишь.
Я думаю, так рассуждать могут только те, кто далёк от реального GUI-строения. И вообще, сильно похоже на бабкино нытьё на лавочках: нынче молодёжь распоясалась, GUI не компилируют, то ли дело мы...
K>Современное железо конечно всё это перемелет, но я не понимаю зачем вот так через огороды заходить, героически выдумывать как оптимальнее тот же DOM формировать?
K>Разница в том, что сейчас часто ради веб-UI в десктопном приложении по сути поднимается локальный веб-сервер в одном процессе, запускается целый браузер в другом процессе и всё это обменивается json-чиками, т.к. нужно реализовывать IPC.
K>Если уж XAML всякие не нравятся и хочется именно HTML, то можно рендеринг так же в процесс библиотекой подключить и не ходить через огороды типа того же WASM.
K>WPF, Qt и другие библиотеки ведь как-то работают без всех этих усложнений.
Давай не будем перескакивать с одного на другое. Полно приложений, которые не "поднимается локальный веб-сервер в одном процессе, запускается целый браузер в другом процессе", а просто используют webview в основном процессе, и открывают в нём локальный HTML-ресурс. А дальше уже он изнутри на JS работает с DOM. К их авторам какие претензии? Почему они должны выкидывать JS на свалку истории? JS, конечно, реально отстойный по сравнению с лучшими скриптовыми языками, но всяко больше для этого подходит, чем манипулирование DOM'ом на нативном языке снаружи. Хотя бы тем, что бизнес-логика автоматически отделяется от чисто интерфейсных вещей.
A>>Попробуй на плюсах типичный сложный случай реализовать, где в одном куске ивент хендлер, лямбда, замыкание, отложенный вызов, и создание кучи объектов. И поуправляй памятью для всего этого дела. А при работе с разметкой это именно типично. Если у тебя реально rich UI приложение, а не очередной хелло-ворлд.
K>А кто-то людям мешает для плюсов нормальную библиотеку сделать?
K>В моей жизни были и голый WinAPI и MFC и wxWidgets, как-то управлял памятью, не умер.
Когда-то вообще перфокарты юзали и... БЛИН! Они все умерли!!
Хреновый это аргумент — что наши предки без современных удобств обходились, и ничего.
Кстати про предков. Как же с облегчением вздохнули юзеры одного продукта в 2003 году, когда загрузчик-хранилище файлов вынесли из внутрипроцессного COM-сервера в локальный (отдельный процесс). Он перестал, наконец, при крешах утягивать за собой само приложение с расчётными модулями. Хотя приложение и замедлилось за счёт передачи данных... аж на 5%, наверно.
K>Зачем нам GUI компилировать, мы будем в рантайме парсить HTML, дабы сформировать его DOM, чтобы и память сожрать и процессор не бездельничал.
Ты хоть раз через профайлер GUI-приложение прогонял? Если бы да, знал бы, чтО там реально тормозит. (И нет, это не парсер). Это копеечная оптимизация, которая на общий расклад вообще не влияет, зато испоганит жизнь тысячам разработчиков, которые не смогут больше просто в ресурсы заглянуть и посмотреть, что там.
Сейчас, допустим, есть у тебя dll, в которой собраны все ресурсы и HTML. Ты придумал какой-то компилированный бинарный формат. И опачки — уже без выгрузки в файл и декомпиляции не посмотришь на него. А ради чего? Ты это ускорение в микроскоп не увидишь.
Я думаю, так рассуждать могут только те, кто далёк от реального GUI-строения. И вообще, сильно похоже на бабкино нытьё на лавочках: нынче молодёжь распоясалась, GUI не компилируют, то ли дело мы...
K>Современное железо конечно всё это перемелет, но я не понимаю зачем вот так через огороды заходить, героически выдумывать как оптимальнее тот же DOM формировать?
Re[7]: C# vs Dart - перспективы
Здравствуйте, karbofos42, Вы писали:
K>Разница в том, что сейчас часто ради веб-UI в десктопном приложении по сути поднимается локальный веб-сервер в одном процессе, запускается целый браузер в другом процессе и всё это обменивается json-чиками, т.к. нужно реализовывать IPC.
K>Если уж XAML всякие не нравятся и хочется именно HTML, то можно рендеринг так же в процесс библиотекой подключить и не ходить через огороды типа того же WASM.
K>WPF, Qt и другие библиотеки ведь как-то работают без всех этих усложнений.
Давай не будем перескакивать с одного на другое. Полно приложений, которые не "поднимается локальный веб-сервер в одном процессе, запускается целый браузер в другом процессе", а просто используют webview в основном процессе, и открывают в нём локальный HTML-ресурс. А дальше уже он изнутри на JS работает с DOM. К их авторам какие претензии? Почему они должны выкидывать JS на свалку истории? JS, конечно, реально отстойный по сравнению с лучшими скриптовыми языками, но всяко больше для этого подходит, чем манипулирование DOM'ом на нативном языке снаружи. Хотя бы тем, что бизнес-логика автоматически отделяется от чисто интерфейсных вещей.
A>>Попробуй на плюсах типичный сложный случай реализовать, где в одном куске ивент хендлер, лямбда, замыкание, отложенный вызов, и создание кучи объектов. И поуправляй памятью для всего этого дела. А при работе с разметкой это именно типично. Если у тебя реально rich UI приложение, а не очередной хелло-ворлд.
K>А кто-то людям мешает для плюсов нормальную библиотеку сделать?
K>В моей жизни были и голый WinAPI и MFC и wxWidgets, как-то управлял памятью, не умер.
Когда-то вообще перфокарты юзали и... БЛИН! Они все умерли!!
Хреновый это аргумент — что наши предки без современных удобств обходились, и ничего.
Кстати про предков. Как же с облегчением вздохнули юзеры одного продукта в 2003 году, когда загрузчик-хранилище файлов вынесли из внутрипроцессного COM-сервера в локальный (отдельный процесс). Он перестал, наконец, при крешах, связанных с импортом кривых файлов плохо специфицированных форматов, утягивать за собой само приложение с расчётными модулями. Хотя приложение и замедлилось за счёт передачи данных... аж на 5%, наверно.
K>Зачем нам GUI компилировать, мы будем в рантайме парсить HTML, дабы сформировать его DOM, чтобы и память сожрать и процессор не бездельничал.
Ты хоть раз через профайлер GUI-приложение прогонял? Если бы да, знал бы, чтО там реально тормозит. (И нет, это не парсер). Это копеечная оптимизация, которая на общий расклад вообще не влияет, зато испоганит жизнь тысячам разработчиков, которые не смогут больше просто в ресурсы заглянуть и посмотреть, что там.
Сейчас, допустим, есть у тебя dll, в которой собраны все ресурсы и HTML. Ты придумал какой-то компилированный бинарный формат. И опачки — уже без выгрузки в файл и декомпиляции не посмотришь на него. А ради чего? Ты это ускорение в микроскоп не увидишь.
Я думаю, так рассуждать могут только те, кто далёк от реального GUI-строения. И вообще, сильно похоже на бабкино нытьё на лавочках: нынче молодёжь распоясалась, GUI не компилируют, то ли дело мы...
K>Современное железо конечно всё это перемелет, но я не понимаю зачем вот так через огороды заходить, героически выдумывать как оптимальнее тот же DOM формировать?
K>Разница в том, что сейчас часто ради веб-UI в десктопном приложении по сути поднимается локальный веб-сервер в одном процессе, запускается целый браузер в другом процессе и всё это обменивается json-чиками, т.к. нужно реализовывать IPC.
K>Если уж XAML всякие не нравятся и хочется именно HTML, то можно рендеринг так же в процесс библиотекой подключить и не ходить через огороды типа того же WASM.
K>WPF, Qt и другие библиотеки ведь как-то работают без всех этих усложнений.
Давай не будем перескакивать с одного на другое. Полно приложений, которые не "поднимается локальный веб-сервер в одном процессе, запускается целый браузер в другом процессе", а просто используют webview в основном процессе, и открывают в нём локальный HTML-ресурс. А дальше уже он изнутри на JS работает с DOM. К их авторам какие претензии? Почему они должны выкидывать JS на свалку истории? JS, конечно, реально отстойный по сравнению с лучшими скриптовыми языками, но всяко больше для этого подходит, чем манипулирование DOM'ом на нативном языке снаружи. Хотя бы тем, что бизнес-логика автоматически отделяется от чисто интерфейсных вещей.
A>>Попробуй на плюсах типичный сложный случай реализовать, где в одном куске ивент хендлер, лямбда, замыкание, отложенный вызов, и создание кучи объектов. И поуправляй памятью для всего этого дела. А при работе с разметкой это именно типично. Если у тебя реально rich UI приложение, а не очередной хелло-ворлд.
K>А кто-то людям мешает для плюсов нормальную библиотеку сделать?
K>В моей жизни были и голый WinAPI и MFC и wxWidgets, как-то управлял памятью, не умер.
Когда-то вообще перфокарты юзали и... БЛИН! Они все умерли!!
Хреновый это аргумент — что наши предки без современных удобств обходились, и ничего.
Кстати про предков. Как же с облегчением вздохнули юзеры одного продукта в 2003 году, когда загрузчик-хранилище файлов вынесли из внутрипроцессного COM-сервера в локальный (отдельный процесс). Он перестал, наконец, при крешах, связанных с импортом кривых файлов плохо специфицированных форматов, утягивать за собой само приложение с расчётными модулями. Хотя приложение и замедлилось за счёт передачи данных... аж на 5%, наверно.
K>Зачем нам GUI компилировать, мы будем в рантайме парсить HTML, дабы сформировать его DOM, чтобы и память сожрать и процессор не бездельничал.
Ты хоть раз через профайлер GUI-приложение прогонял? Если бы да, знал бы, чтО там реально тормозит. (И нет, это не парсер). Это копеечная оптимизация, которая на общий расклад вообще не влияет, зато испоганит жизнь тысячам разработчиков, которые не смогут больше просто в ресурсы заглянуть и посмотреть, что там.
Сейчас, допустим, есть у тебя dll, в которой собраны все ресурсы и HTML. Ты придумал какой-то компилированный бинарный формат. И опачки — уже без выгрузки в файл и декомпиляции не посмотришь на него. А ради чего? Ты это ускорение в микроскоп не увидишь.
Я думаю, так рассуждать могут только те, кто далёк от реального GUI-строения. И вообще, сильно похоже на бабкино нытьё на лавочках: нынче молодёжь распоясалась, GUI не компилируют, то ли дело мы...
K>Современное железо конечно всё это перемелет, но я не понимаю зачем вот так через огороды заходить, героически выдумывать как оптимальнее тот же DOM формировать?