Re[6]: C# vs Dart - перспективы
От: karbofos42 Россия  
Дата: 27.08.23 09:01
Оценка: +4
Здравствуйте, Alekzander, Вы писали:

A>И наплевать, что у него есть своя ниша, где он вписывается лучше всего.


Просто так исторически сложилось, сам язык ужасен и его заслуги тут нет.

A>Ты противопоставил его и "тащить целый браузер". А это и есть браузер, только хорошо написанный, в отличие от гуглошлака. Разницы нет. Ведь, в принципе, если тебя не устраивает read-only C++ DOM access в Хромиуме, можно спуститься на более низкий уровень, и рулить там из C++ напрямую. И всегда было так можно, со времён IHtmlElement. Видишь? Нет разницы. И там, и там можно на низкоуровневом языке управлять высокоуровневыми объектами. И там, и там вменяемые люди предпочитают вместо этого использовать ЯП, специально заточенный под задачу.


Разница в том, что сейчас часто ради веб-UI в десктопном приложении по сути поднимается локальный веб-сервер в одном процессе, запускается целый браузер в другом процессе и всё это обменивается json-чиками, т.к. нужно реализовывать IPC.
Если уж XAML всякие не нравятся и хочется именно HTML, то можно рендеринг так же в процесс библиотекой подключить и не ходить через огороды типа того же WASM.
WPF, Qt и другие библиотеки ведь как-то работают без всех этих усложнений.

A>Попробуй на плюсах типичный сложный случай реализовать, где в одном куске ивент хендлер, лямбда, замыкание, отложенный вызов, и создание кучи объектов. И поуправляй памятью для всего этого дела. А при работе с разметкой это именно типично. Если у тебя реально rich UI приложение, а не очередной хелло-ворлд.


А кто-то людям мешает для плюсов нормальную библиотеку сделать?
В моей жизни были и голый WinAPI и MFC и wxWidgets, как-то управлял памятью, не умер.
В том же .NET на WPF как-то народ сложные интерфейсы делает и некоторым даже нравится.
При том, что в момент появления библиотека WPF казалась очень медленной и прожорливой.
На современном железе уже и это поделие летает, поэтому решили придумывать ещё более упоротые библиотеки, которые будут потреблять ещё больше накладных ресурсов.
Зачем нам GUI компилировать, мы будем в рантайме парсить HTML, дабы сформировать его DOM, чтобы и память сожрать и процессор не бездельничал.
Современное железо конечно всё это перемелет, но я не понимаю зачем вот так через огороды заходить, героически выдумывать как оптимальнее тот же DOM формировать?
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.