_>>И отсутствует это всё не потому, что там какие-то идиоты сидят, а потому что предназначения HTML другое.
НС>Нет, потому что все это прекрасно реализуется прикладным кодом и не нужно дополнительно усложнять и так сверхсложный браузерный движок.
Нифига оно не реализуется «прекрасно». Сложность создания новых компонентов зашкаливает все разумные пределы. Собственно, это и етс одна из причин, что подавляющее большинство «компонентных библиотек» максимум осиливают табы и «аккордионы», а все, что сложнее, обычно стоит невменяемыхденег.
Здравствуйте, rFLY, Вы писали:
FLY>Здравствуйте, alex_public, Вы писали:
_>>Не, ну у меня конечно же топовый комп и видеокарта, а браузер Firefox. Но всё равно по идее не должно быть такой разницы. В разы — да. Но не в десятки или сотни раз! FLY>Ну чёрт его знает, может он часть вычислений/прорисовку на видюху переводит и встроенное граф.едро от интела этого не поддерживает.
UPDT: Дома глянул, опять же на ноуте и опять же кор ай 5, но 8 поколения. Разницы с обычным хтмл по загрузке проца нет.
Здравствуйте, Mamut, Вы писали:
НС>>Нет, потому что все это прекрасно реализуется прикладным кодом и не нужно дополнительно усложнять и так сверхсложный браузерный движок. M>Нифига оно не реализуется «прекрасно». Сложность создания новых компонентов зашкаливает все разумные пределы.
Это потому что ты не делал контролы для классических библиотек.
Здравствуйте, Codealot, Вы писали:
_>>Вот как будто бы ты сам не видел внутренности всех этих html/css/js фреймворков. На фоне этого ада, даже кривые Qt и MFC выглядят образцами архитектурной красоты! Хуже чем эти JS фреймворки, наверное только PHP фреймворки (в которых опять же есть html/css/js)... C>Пощупав недавно эти "чудеса дизайна", подумалось — а не пора ли просто отправить html/css на помоечку, и сделать фреймворк на одних плавающих дивах и абсолютном позиционировании?
Ну собственно рисование всего через canvas (не важно из wasm или js) — это и есть конечная точка этого направления. Правда при этом возникают проблемы с поиском, но это актуально только для классических сайтов, а не для веб-приложений.
M>>Нифига оно не реализуется «прекрасно». Сложность создания новых компонентов зашкаливает все разумные пределы. НС>Это потому что ты не делал контролы для классических библиотек.
Что такое «классические библиотеки»? На дворе 2019-й год. Набор примитивов для веба сейчас хуже и беднее, чем Дельфи или там Qt образца 2000-го.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Странный ты. Если ты используешь библиотеку, то писать руками не надо. _>>Писать новые контролы? Ну иногда бывает, но это скорее исключение, чем практика. НС>Ровно как и в современном вебе.
Даа? Ну покажи какой объём кода на чистом JS (без всяких дополнительных библиотек) тебе понадобится, чтобы реализовать банальное меню.
НС>>>Ну так голый HTML+JS это тоже не библиотека. _>>Я именно про это и говорю. GUI библиотека браузера — это DOM (во всяком случае большая его часть). НС>Так библиотека или не библиотека, ты уж определись.
Повторяюсь последний раз:
DOM — это слабенькая GUI библиотека (написанная на C++).
HTML/CSS/JS — это единственный (и кривой) интерфейс к ней.
Плюс к этому всему, JS — это единственное (и крайне убогое) средство расширения этой библиотеки.
НС>>>Для целей GUI современный JS, а тем более TS вполне адекватны. _>>Угу, особенно на нём хорошо выходит делать классические расширяемые с помощью ООП иерархий библиотеки... ))) НС>А зачем на нем делать классические библиотеки?
Потому что ООП подход — это пока лучшее, что придумали в отрасли, для задач модульности и расширяемости.
_>>>>HTML хорош для создания документов, но не для создания GUI. НС>>>HTML5 вполне подходит для создания GUI и с прицелом на это создавался. _>>Если бы это было так, то не существовало бы множества библиотек под браузер, добавляющих к нему самые базовые контролы НС>Ровно как существует множество библиотек под С++, добавляющих ...
Причём тут вообще C++? ) Мы говорим про GUI библиотеки, а они точно не входят в стандарт C++. А вот в стандарте HTML5 GUI часть вполне имеется, но крайне убогая.
_>>Вот что мешало записать хотя бы эти https://getbootstrap.com/docs/4.3/components контролы в HTML5 НС>Зачем?
Что бы на HTML5 можно было делать приличный GUI (ты же говорил, что это была одна из целей! ), без дополнительных диких библиотек.
_>>И отсутствует это всё не потому, что там какие-то идиоты сидят, а потому что предназначения HTML другое. НС>Нет, потому что все это прекрасно реализуется прикладным кодом и не нужно дополнительно усложнять и так сверхсложный браузерный движок.
Так вообще всё реализуется прикладным кодом. У нас же есть canvas и js — больше по идее ничего не надо! Зачем тогда в html насовали всяких там button, editbox (input), listbox (select) и т.п...
_>>Ну давай, расскажи о колоссальном прогрессе у HTML в области GUI... ))) НС>Возьми спеку HTML5 и почитай.
Вот кстати как раз это я и делал в момент выхода html5. И тогда она меня в принципе порадовала. Только вот дальше развитие пошло совсем не туда. Точнее там просто нет никакого развития с точки зрения html, а всё пошло в js. А html так и остался убогеньким с точки зрения GUI.
НС>>>Или не будет. По факту реакту уже 6 лет и своей актуальности он не потерял, а vue принципиально от него не отличается. _>>Надейся, надейся. ) НС>Да мне пофигу, в моих проектах фронта не очень много, мне пока одного фронтендера за глаза. Ну будет вместо реакта чего еще — ради бога.
Хы, у нас "фронтенда" нет вообще, в тех продуктах, которые покупают пользователи. Однако у нас есть свои сайты, которые мы делаем и обслуживаем сами (хотя это несколько не наш профиль), а не заказываем аутсорсом кому-то. Поэтому приходится в этом более менее разбираться, так сказать для внутренних целей.
_>> Кстати, помнится самым мощным GUI фреймворком для приложений (а не для сайтиков!) был ExtJS — и что это ты её не упомянул, а? ) НС>ExtJS это как раз от таких как ты любителей старого подхода. Потому и сдох. Реакт сильно лучше.
Очень забавно эта твоя фраза звучит, на фоне факта продаж (причём за очень приличные деньги) такого продукта как ExtReact. Кстати, а ещё у них там есть ExtAnglular...
И кто-то там ещё заикался о слабом знание темы или любителях старых подходов...
_>>Вот как будто бы ты сам не видел внутренности всех этих html/css/js фреймворков. НС>Видел. Ничего космического там нет.
Космического конечно нет. Там только мусорное и адское.
_>> На фоне этого ада, даже кривые Qt и MFC выглядят образцами архитектурной красоты! НС>С точностью до наоборот.
Ну давай перейдём к деталям. И так, допустим нас есть такой готовый контрол как кнопка (есть и в Qt и в MFC и в HTML). Но её поведение и внешний вид нас не устраивают.
Что мы делаем в классических ООП библиотеках? Наследуемся от этого контрола и переопределяем ему функции, отвечающие за требующее коррекцию поведение.
Что мы делаем в случае html/css/js? Сделать, как описано выше, мы банально не можем по определению. Можем только слегка кастомизировать поведение с помощью css и пары callback'ов, но в крайне узких рамках. Ну или же мы можем наплевать на стандартный код и написать новый контрол с нуля, на базе div/span/canvas, что требует гораздо больших усилий. И главное, что для разных контролов в рамках одного и того же кода могут применяться разные подходы, потому как написать button с нуля не так уж сложно, а вот сделать editbox (со всеми корректными копированиями, способами ввода и т.п.) уже гораздо сложнее и чаще предпочитают всё же как-то переиспользовать стандартный. В итоге имеем адский говнокод из смеси использования html, своих велосипедов и всё это на убогом языке с кривой модульностью и ООП.
И да, описанное выше — это описание не какого-то проекта, а большинства JS фреймворков...
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, $$, Вы писали:
Ops>$>Могло бы быть альтернативой флешу, но нет, на ослике не работает.
Ops>Он где-то еще остался? Последние динозавры с него слезают, потому что нужные им сайты перестают там работать. Пора бы окончательно закопать стюардессу.
Здравствуйте, D. Mon, Вы писали:
_>>В принципе, после добавления в wasm поддержки simd, все нужные кодеки можно будет уже писать (а точнее просто скомпилировать, т.к. большинство их них написаны на C/C++ и только некоторые используют ещё и ассемблер для ускорения) прямо на wasm. DM>Говно получится. Современные кодеки стандартных форматов давно используют GPU-ускорение, без него на одном CPU получается очень грустно даже с SIMD.
Ну SIMD в любом случае нужен хотя бы для банальных эффективных memcpy... А если говорить про GPU, то вычисления на нём уже давно доступны в браузере, и без wasm. Благо WebGL — это OpenGL ES 3.0 и там поддерживаются вполне себе современные шейдеры. Кстати, я тут ещё пару лет назад показывал тест, который как раз игрался с шейдерами из wasm.
Здравствуйте, Codealot, Вы писали:
_>>На фоне этого ада, даже кривые Qt и MFC выглядят образцами архитектурной красоты! C>Кстати, а что плохого в Qt?
Кроме того, что это ожиревший монстр-всемогутер? Лично мне больше всего не нравится то, что это C++ библиотека, написанная в стиле Java. Понятно что это всё наследие 90-ых, в которые библиотека родилась, и в которых по другому просто не умели. Но в сравнение с современными C++ библиотеками она выглядит крайне печально. Ну это естественно речь о внутренней архитектуре. А так сказать по итоге применения она по прежнему на голову опережает всех других. Только вот это всё исключительно благодаря экстенсивному подходу (затраченным человеко-часам). Вот если бы кто-то вдруг сподобился вложить столько же денег, сколько потрачено на Qt, в GUI библиотеку, написанную на современном C++ — это было бы на порядки красивее и эффективнее. Но думаю такого уже никогда не случится по бизнес-причинам.
_>Ну собственно рисование всего через canvas (не важно из wasm или js) — это и есть конечная точка этого направления. Правда при этом возникают проблемы с поиском, но это актуально только для классических сайтов, а не для веб-приложений.
Там много других проблем возникает: accessibility, рисовка шрифтов, вообще работа с текстом на canvas... В общем там вагон и маленькая тележка.
Здравствуйте, Mamut, Вы писали:
M>Что такое «классические библиотеки»? На дворе 2019-й год. Набор примитивов для веба сейчас хуже и беднее, чем Дельфи или там Qt образца 2000-го.
Здравствуйте, alex_public, Вы писали:
_>Даа? Ну покажи какой объём кода на чистом JS (без всяких дополнительных библиотек) тебе понадобится, чтобы реализовать банальное меню.
Банальное меню можно вообще без JS реализовать.
НС>>>>Ну так голый HTML+JS это тоже не библиотека. _>>>Я именно про это и говорю. GUI библиотека браузера — это DOM (во всяком случае большая его часть). НС>>Так библиотека или не библиотека, ты уж определись. _>Повторяюсь последний раз: _>DOM — это слабенькая GUI библиотека (написанная на C++). _>HTML/CSS/JS — это единственный (и кривой) интерфейс к ней.
Т.е. GDI в винде это такая слабенькая GUI библиотека, да?
_>Плюс к этому всему, JS — это единственное (и крайне убогое) средство расширения этой библиотеки.
В чем убогое?
НС>>>>Для целей GUI современный JS, а тем более TS вполне адекватны. _>>>Угу, особенно на нём хорошо выходит делать классические расширяемые с помощью ООП иерархий библиотеки... ))) НС>>А зачем на нем делать классические библиотеки? _>Потому что ООП подход — это пока лучшее, что придумали в отрасли
Докажи
_>Что бы на HTML5 можно было делать приличный GUI (ты же говорил, что это была одна из целей! ), без дополнительных диких библиотек.
Чем тебе мешают библиотеки? И почему в С++ библиотеки тебе не мешают? Почему бы не потребовать контролов от драйвера видеокарты?
_>>>И отсутствует это всё не потому, что там какие-то идиоты сидят, а потому что предназначения HTML другое. НС>>Нет, потому что все это прекрасно реализуется прикладным кодом и не нужно дополнительно усложнять и так сверхсложный браузерный движок. _>Так вообще всё реализуется прикладным кодом.
Да. И никто не требует реализации контролов от библиотечки для рисования.
_>Хы, у нас "фронтенда" нет вообще
Заметно.
_>>>Вот как будто бы ты сам не видел внутренности всех этих html/css/js фреймворков. НС>>Видел. Ничего космического там нет. _>Космического конечно нет. Там только мусорное и адское.
Давай конкретнее. Ты уже пятое сообщение выдаешь кучу эмоциональных эпитетов и не можешь их никак обосновать.
_>Что мы делаем в классических ООП библиотеках? Наследуемся от этого контрола и переопределяем ему функции, отвечающие за требующее коррекцию поведение.
Всяко бывает. В WPF, к примеру, совсем не так.
_>, но в крайне узких рамках. Ну или же мы можем наплевать на стандартный код и написать новый контрол с нуля, на базе div/span/canvas, что требует гораздо больших усилий.
Уверен? И почему именно с нуля? Почему в случае JS нельзя взять готовую библиотеку?
Здравствуйте, Ops, Вы писали:
_>>Ну и да, это плохо для случая потребности высокой производительности таких вызывов. Ops>Это плохо потому, что любое действие с DOM надо либо оборачивать в JS, либо на нем и писать, размазывая логику. Это очень неудобно при написании, даже неудобнее использования монструозных js-фреймворков.
Ну вот для Питона уже сделали полную обёртку в готовой библиотеке. Т.е. я просто пишу:
from js import document
elt = document.getElementById("targetElement")
elt.innerText = "I am changed!"
elt.style.backgroundColor = '#ffcccc'
и всё работает — никаких знаний JS не надо. Понятно, что это внутри DOM вызывается через вызoв JS функции, и это архитектурно некрасиво и не эффективно. Но с точки зрения разработчика на Питоне, он про это может даже не знать. Ну а эффективнось и Питон...
M>>Что такое «классические библиотеки»? На дворе 2019-й год. Набор примитивов для веба сейчас хуже и беднее, чем Дельфи или там Qt образца 2000-го. НС>Ты компоненты для Дельфи пробовал сам писать?
Ты компоненты для веба пробовал сам писать? Не убогое примитивное говно типа «еще одна панелька, которая скрывается по клику», а нормальный полноценный компонент. Ну какой-нибудь Tree Grid, который можно просто взять и вставить в любое место на странице.
Здравствуйте, Mamut, Вы писали:
M>>>Что такое «классические библиотеки»? На дворе 2019-й год. Набор примитивов для веба сейчас хуже и беднее, чем Дельфи или там Qt образца 2000-го. НС>>Ты компоненты для Дельфи пробовал сам писать? M>Ты компоненты для веба пробовал сам писать?
Да. Ты на вопрос ответишь?
M> Не убогое примитивное говно типа «еще одна панелька, которая скрывается по клику», а нормальный полноценный компонент. Ну какой-нибудь Tree Grid, который можно просто взять и вставить в любое место на странице.
В том числе TreeGrid. А еще я TreeGrid писал для винформсов, так что есть с чем сравнить.
Да я про осла. Если где-то его еще используют, то для легаси, где никакого развития или нового софта не предвидится. А привыкшие к нему люди с него уходят, т.к. куча ресурсов в нем уже не работает.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, alex_public, Вы писали:
_>Ну вот для Питона уже сделали полную обёртку в готовой библиотеке. Т.е. я просто пишу: _>
_>from js import document
_>elt = document.getElementById("targetElement")
_>elt.innerText = "I am changed!"
_>elt.style.backgroundColor = '#ffcccc'
_>
_>и всё работает — никаких знаний JS не надо. Понятно, что это внутри DOM вызывается через вызoв JS функции, и это архитектурно некрасиво и не эффективно. Но с точки зрения разработчика на Питоне, он про это может даже не знать. Ну а эффективнось и Питон...
Это для wasm? Клево. А с эвентами и исключениями что?
Но вообще это надо решать не "для питона", а в общем виде, и не обертками, а прямым доступом, пусть даже где-то с потерей типизации. Но такое впечатление, что это никому не интересно.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
M>>Ты компоненты для веба пробовал сам писать? НС>Да. Ты на вопрос ответишь?
Для Дельфи — нет. Что не мешало делать на Дельфи приложения хоть правой пяткой, не приходя в сознание. Потому что все, что требовалось — это положить компонент в окно. Удачи сделать то же самое с любым «компонентом» в вебе.
M>> Не убогое примитивное говно типа «еще одна панелька, которая скрывается по клику», а нормальный полноценный компонент. Ну какой-нибудь Tree Grid, который можно просто взять и вставить в любое место на странице.
НС>В том числе TreeGrid. А еще я TreeGrid писал для винформсов, так что есть с чем сравнить.
Ну и расскажи, насколько прекрасно и удобно вручную бороться с div'ами для отображения даже не самых сложных вещей, когда любой css-reset порушит люые самые лучшие начинания (если только, конечно, не прибивать все гвоздями к пискелям с помощью !important)
Здравствуйте, Mamut, Вы писали:
НС>>В том числе TreeGrid. А еще я TreeGrid писал для винформсов, так что есть с чем сравнить. M>Ну и расскажи, насколько прекрасно и удобно вручную бороться с div'ами для отображения даже не самых сложных вещей, когда любой css-reset порушит люые самые лучшие начинания (если только, конечно, не прибивать все гвоздями к пискелям с помощью !important)
Намного проще чем делать TreeGrid на основе стандартных виндовых контролов.
Ну покажи какой объём кода на чистом JS (без всяких дополнительных библиотек) тебе понадобится, чтобы реализовать банальное меню.
