Здравствуйте, bnk, Вы писали:
bnk>А каким, если не секрет? bnk>Тоже вот хочу, но чтобы он на телефоне тоже был.
bnk>Вот представь себе, есть 5 аккаунтов IMAP, и идеально было бы, чтобы оно с ними синхронизировало почту и показывало бы некий объединенный inbox. bnk>На телефоне, в браузере, и на десктопе. GMail такое не умеет (только pop), Outlook тоже (только раздельно)
Thunderbird, но что у него с телефоном я не знаю, с мобилы 2 раза в году захожу стандартным приложением, чаще не требуется, поэтому не озаботился.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, vdimas, Вы писали:
DM>>Я говорил про первое — "WebAssembly's local variables are outside the address space", а ты — про второе, про то, как конкретный компилятор С++ обходит это ограничение. Теперь все на своих местах.
V>Я же говорю — низкое кач-во спеки.
Ну нет, спека WebAssembly описывает именно ВМ WebAssembly, это уровень ассемблера, и там никакого aliased stack'a нет, как нет и структур.
То, как отдельные языки будут выкручиваться, — уже спеку WebAssembly не волнует. Она ничего не знает и знать не хочет ни про структуры, ни про требования GC отдельных языков.
Здравствуйте, D. Mon, Вы писали:
DM>>>Я говорил про первое — "WebAssembly's local variables are outside the address space", а ты — про второе, про то, как конкретный компилятор С++ обходит это ограничение. Теперь все на своих местах. V>>Я же говорю — низкое кач-во спеки. DM>Ну нет, спека WebAssembly описывает именно ВМ WebAssembly, это уровень ассемблера, и там никакого aliased stack'a нет, как нет и структур.
Состояние спеки WebAssembly на сегодня — ну это примерно как схема функциональная.
Паять по такой схеме еще нельзя, надо разработать схему принципиальную.
А её нет.
DM>То, как отдельные языки будут выкручиваться, — уже спеку WebAssembly не волнует.
Мде? ))
Но С/С++ упоминает более одного раза (что ес-но, ведь дотнетные, джавовские, хаскель и чуть не все прочие рантаймы будут написаны под webasm на С или С++).
Однако, такое усердное упоминание создаёт видимость того, что проблема касается только С++, но это достоверно НЕ так.
DM>Она ничего не знает и знать не хочет ни про структуры, ни про требования GC отдельных языков.
Верно. Проблема в авторах спеки.
Там орудют птички, скажем прямо, не самого высокого полёта.
Нет таких как Герб Саттер в плюсах (а таких как Саттер в плюсах огромное кол-во людей), нет спецов сравнимого уровня с уровнем разработчиков того же дотнета когда-то.
Более того, описывать модель webasm в терминах JS...
это не просто роспись в нубстве, это днище.
Это махание своей профнепригодностью на весь интернет.
Как грится, куда вы соколики лезете, что пытаетесь проглотить...
И это они когда-то к 2015-му году хотели "повсеместно перейти", потом к 2018-му.
ИМХО, даже 2025-й сильно под вопросом, потому что это край современного нубства, а в таких случаях награда лишь одна — долгострой.
==============
Скажу так.
Идея мне импонировала, пока с твоей подачи я не полез в самые кишки как грится...
В нашей конторе такие нубы сидели бы на поддержке продуктов, разработанных другими коллегами.
И ни боже упаси руками трогать то, чего не понимают.
Здравствуйте, vdimas, Вы писали:
DM>>То, как отдельные языки будут выкручиваться, — уже спеку WebAssembly не волнует.
V>Мде? )) V>Но С/С++ упоминает более одного раза (что ес-но, ведь дотнетные, джавовские, хаскель и чуть не все прочие рантаймы будут написаны под webasm на С или С++).
Здравствуйте, Codealot, Вы писали:
V>>Идея мне импонировала, пока с твоей подачи я не полез в самые кишки как грится... C>Достаточно посмотреть на сроки и прогресс. Идея в общем мне нравится, но к сожалению — не думаю, что эти люди смогут ее вытянуть.
+1
Да. В этом же и заключается суть софтового долгостроя.
Сами разработчики должны пройтись по всем граблям, "вырасти", накопить опыта.
Некоторые из разрабов "отвалятся" в процессе, ниасилив, их заменят на более квалифицированных.
В общем, долгострой продолжается ровно до тех пор, пока команда разрабов не подтянется до уровня решаемых задач.
Как только подтянется — можно отсчитывать примерно 9 месяцев до первого вменяемого релиза.
Судя по-спеке — на сейчас еще происходит этап активного обучения, через пляски по граблям, ес-но.
Здравствуйте, D. Mon, Вы писали:
V>>Но С/С++ упоминает более одного раза (что ес-но, ведь дотнетные, джавовские, хаскель и чуть не все прочие рантаймы будут написаны под webasm на С или С++). DM>Нет. Вот спека DM>https://webassembly.github.io/spec/core/bikeshed/index.html
Я тебе давал выдержки из более принципиального документа — Design Rationale.
Как там говорил Козьма Прутков — смотри в корень! ))
А по твоей ссылке всё слишком сыро пока мест.
Сравни с описаниями стандартов VM .Net, или языка С++ (который идёт с описанием подразумеваемой абстрактной машины исполнения).
Это совершенно несравнимое кач-во спецификаций, даже лень тут что-либо обсуждать, сорри.
В общем, это серьёзный факап... запасайтесь терпением...
Других адекватных выводов пока мест быть не может.
Здравствуйте, Mamut, Вы писали:
A>>Для браузеров такие библиотеки уже есть, и никому не надо каждый раз делать компоненты, и не любить себя. M>Ага-ага. Только вот незадача: любой чих, и эти компоненты ломаются. Любой компонент — с кучей ограничений нато, где, как и почему он может появляться, строгие требования к разметке и т.п. А крупные (типа той же sencha) просто банально берут на себя контроль за всем, практически не позволяют ничего стороннего, и все равно имеют кучу собственных ограничений на то, где как и почему какой-либо элемент может находиться.
Есть ограничения, да. И что? Я напомню, что речь изначально шла о том, что всем нужно себя не любить и пилить собственные компоненты на основе span и div. А теперь ты вынужден согласиться с тем, что это не обязательно, но тут же меняешь тактику: нужно подчиняться некоторым ограничениям и, видимо, снова не любить себя.
M>И все равно. Любой залетный html * { padding: 2em } убьет любой «компонент».
А какой-нибудь залётный exec("rm -rf /") убьёт систему. Зачем вообще обсуждать залёты?
Здравствуйте, bzig, Вы писали:
B>А как это будет выглядеть в нормальном фрэймворке (можно, кстати, список?)? Те же самые вычисления и простановка какого-нибудь проперти. В чём принципиальная разница? Кроме той, что (я подозреваю) в нормальном фрэймворке-то и "em/ex" поддерживаться не будет, а будут пиксели и плевать, что там у юзера выставлено в настройках броузера 120%.
В нормальных фреймворках вообще не надо беспокоиться о таких вопросах. Там размер окна автоматически масштабируется так, чтобы вместить весь контент. Если же требуемый для этого размер, будет превышать максимально возможный, то автоматически появятся полосы прокрутки. Даже странно видеть такие вопросы в 2019-ом году, а не в начале 90-ых. Хотя да, Web GUI действительно так и не дорос пока хотя бы до уровня стандартных контролов Window95...
Здравствуйте, Mamut, Вы писали:
A>>Так вот ситуация та же самая. Поверх примитивов создаются библиотеки компонентов и далее все пишут GUI, используя их.
M>почти та же самая. Ну то есть такая же, как земля и небо.
A>>Для браузеров такие библиотеки уже есть, и никому не надо каждый раз делать компоненты, и не любить себя.
M>Ага-ага. Только вот незадача: любой чих, и эти компоненты ломаются. Любой компонент — с кучей ограничений нато, где, как и почему он может появляться, строгие требования к разметке и т.п. А крупные (типа той же sencha) просто банально берут на себя контроль за всем, практически не позволяют ничего стороннего, и все равно имеют кучу собственных ограничений на то, где как и почему какой-либо элемент может находиться.
M>И все равно. Любой залетный html * { padding: 2em } убьет любой «компонент».
С другой стороны, когда надо изменить где-нибудь какую-то визуальную мелочь внутри, можно написать что-то типа:
В WPF\UWP для такого иногда приходится переделывать километровые шаблоны для целой иерархии. И при мелких обновлениях компонентов, переделывать по новой.
Мне вот сейчас надо переписать шаблоны кнопок в UWP-приложении, потому, что мои сломались после очередного обновления винды, а в стандартных захордкожены размеры иконок
И кода там будет на несколько экранов.
Я вот совсем не фанат html, но есть ощущение, что с появлением flex, grid раскладок как-то с этим стало можно жить.
В конце-концов VSCode сейчас чуть ли не самый популярный редактор кода, а от Figma тащатся знакомые дизайнеры.
M>>И все равно. Любой залетный html * { padding: 2em } убьет любой «компонент». A>А какой-нибудь залётный exec("rm -rf /") убьёт систему. Зачем вообще обсуждать залёты?
exec("rm -rf /") просто так в твое приложение не залетит. А любой CSS в твое веб-приложение может залететь очень легко. По той причине, что все эти «компоненты» валяются в плоском глобальном неймспейсе.
Простейший пример, где банально размер шрифта твоего «компонента» напрямую зависит от того, сколько дивов стоит до него.
<css>
div > div { font-size: 0.8em }
div { font-size: 1em }
</css>
<div>
hello
<div>
hello
<div>
hello
</div>
</div>
</div>
Поэтому любые сторонние «компоненты» засраны !important'ами по самое немогу. И все равно ломаются от любого левого взгляда. За исключением, повторюсь, полутора полноценных систем типа sencha, в которых все управляется JS'ом и каждый прыжок в сторону карается расстрелом.
ЕА>Я вот совсем не фанат html, но есть ощущение, что с появлением flex, grid раскладок как-то с этим стало можно жить. ЕА>В конце-концов VSCode сейчас чуть ли не самый популярный редактор кода, а от Figma тащатся знакомые дизайнеры.
Здравствуйте, Mamut, Вы писали:
ЕА>>Я вот совсем не фанат html, но есть ощущение, что с появлением flex, grid раскладок как-то с этим стало можно жить. ЕА>>В конце-концов VSCode сейчас чуть ли не самый популярный редактор кода, а от Figma тащатся знакомые дизайнеры.
M>Угу. Только в Фигме ровно ноль HTML и CSS и им пришлось с нуля реализовывать свой собственный движок: https://www.figma.com/blog/building-a-professional-design-tool-on-the-web/
Ты ее хоть запускал? Весь UI там на html\css и он не сказать чтоб сильно простой.
На WebAssembly\WebGL — там только непосредственно графический редактор.
Здравствуйте, Mamut, Вы писали:
M>Угу. Только в Фигме
Сорри, но постоянно приводить в качестве аргумента один довольно специфичный и не так чтобы суперпопулярный продукт это перебор. Ты там работаешь что ли?
Здравствуйте, Mamut, Вы писали:
M>exec("rm -rf /") просто так в твое приложение не залетит. А любой CSS в твое веб-приложение может залететь очень легко. По той причине, что все эти «компоненты» валяются в плоском глобальном неймспейсе.
Ну вообще-то shadow dom для этого уже давно придуман и реализован. Никто не заставляет валять компоненты в плоском неймспейсе. В самых популярных фреймворках (react, angular) эта проблема тоже решена по-своему. Я даже не совсем понимаю, о каких компонентах ты говоришь. jQuery? Ну это уровень 10-летней давности. Те проблемы уже решены.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Mamut, Вы писали:
M>>Угу. Только в Фигме
НС>Сорри, но постоянно приводить в качестве аргумента один довольно специфичный и не так чтобы суперпопулярный продукт это перебор. Ты там работаешь что ли?
Да он ее даже не видел
Фигма — это как раз идеальный аргумент за веб-интерфейсы. Весь гуй там чисто на html, и что удивительно, он более навороченный и работает более шустро, чем у десктопных конкурентов.
Но вот на счёт специфичности/непопулярности не соглашусь — очень популярная тулза сейчас для проектирования/дизайна интерфейсов
