описанию бокс-модели

если надо сделать 100 форм то да, надо выдумывать что-то декларативное для них а придумать что-то декларативное да еще чтобы подходило под любую задачу это я даж не знаю что должно быть

видимо что-то типа реакта получится с кучей ручек которые крутить можно при необходимости

там нет любой задачи

там все таже задача отображения

нарисовать бокс

контент взять оттуда

бокс засунуть в бокс, боксы в боксе имеют алаймент один над другим если бокс ресайзится

этот весь ваш респонсив

все это уже было в симпсонах...

любом гуи тулките

wx, фоксе и даже fltk кажется

бокс модель это боль конечно, но с другой стороны когда раньше надо было на mfc сделать что-то что хорошо себя ведет на ресайзах окна -- боли было еще больше )

в общем, вопрос стоит так - а есть ли в вебе какая-то специфика, которой не было в desktop приложениях? десктопные тулкиты мы все более-менее хорошо знаем

знаем, но они разве лучше и удобнее того что сейчас в вебе?

а про веб всё крайне мутно, и думаю, что причины этого скорее социальные

они такие же. и я не вижу почему модель любого из них не подойдет для организации ui на вебе

специфики нет, но мне кажется в вебе ща пытаются сделать "как на десктопе но без боли qt"

я не могу сказать про qt его я мало знаю

но например были вполне нормальные и удобные в плане программирования фреймворки, типа того же fltk

на все это дело конечно накладывается что (исторически) там js

да и fox ничего был

вот fltk не трогал вообще (

да даже в openlaszlo была вполне нормальная бокс-модель и виджеты.

а gtk то же -- это боль не меньше чем сейчас веб

ну его недостаток - слабая интеграция с системой, ненативный вид контролов и архаичный лук н фил

т.е это не какие-то фундаментальные проблемы. и он туп, как пробка и... вполне удобен.

тебе все же нужна готовая библиотека виджетов?

конечно нужна. потому что проблема эта верстка же и особенности бравзеров

и DOM

у веба еще особенность что хоть все и хотят desktop experience, никто не хочет унифицированных контролов. хотят свой дизайн и полет мысли

ну по идее это до определенной степени решается стилями

но да, не хотят. возможно, в этом проблема

неужели такая проблема сделать edsl и вебню генерить из него?

поддержка браузеров, и плюшек, а также нововведения и апдейт всего этого - крайне больше ресурсы нужны.

"до определенной степени" но на самом деле не решается (

но кстати -- библиотеки виджетов есть

@weonn а какие там "нововведения" на самом деле?

чего там нововвели. в вебе, я имею ввиду, а не в тулкитах, которые плодятся как тараканы

@weonn а какие там "нововведения" на самом деле?

например механика асинхронки, менялась сильно и часто

есть material ui, есть grommet

как-то это... неконкретно.

есть еще че-то китайское большое (не помню как называется)

как-то это... неконкретно.

http://caniuse.com/#feat=websockets другие плюшки также, реализуются по разному и в разной степени

это да.. до появления flexbox выровнять блок по вертикали было той еще историей )

вот таких тонкостей милиард и они множатся

если есть едсл, однозначно он не учитывает _все_ тонкости, а значит попровить чтото мелкое становится невозможным, и снова костыли

я не понимаю как это влияет на поведение квадратиков на экране

какая по сути разница, через вебсокеты данные подсасывать или XHR

можно и так и так

это слово - бекенд

в смысле бекенд для транспорта.

какая по сути разница, через вебсокеты данные подсасывать или XHR

поддержка разная, работа разная

речь не про данные

ну есть квадратики - которые надо по разному относительно друг друга рисовать при изменении разрешения

есть данные, которые там показываются

косистентность отображения и поведения дерева дом

если есть едсл, однозначно он не учитывает _все_ тонкости, а значит попровить чтото мелкое становится невозможным, и снова костыли

ну я про это и говорил 95% покроет, а на оставшихся 5% сойдешь с ума

котоыре берутся с бэка

ну я про это и говорил 95% покроет, а на оставшихся 5% сойдешь с ума

да

а в 5% легко попадут нужные или критические моменты

5% написать на js ?

5% написать на js ?

тогда его надо както стыковать с генеренным

хуки, вот это всё

это у твоего edsl должны быть особые ручки чтобы в нужных местах прицеплять js

вроде бы в десктопах все это проходили

ВЖУХ и у тебя реакт

или еще хуже - EMBER

ERROR: S client not available

это у твоего edsl должны быть особые ручки чтобы в нужных местах прицеплять js

и квалификация фронтера нехилая, чтобы он точечные фиксы жсом мог делать

то, что edsl будет покрывать только 95% это нормально, если это будут 95 процентов, нужные мне

но возникает вопрос = этого никто до сих пор не сделал, потому что это невозможно?

в этом случае да

или потому что никому не нужно?

но речь же о маинстриме

или потому что никому не нужно?

никто не вложил такие ресурсы в это

просто реально фронтенд это такая боль, причем и когда сам, и когда пытаешься кого-то нанять, что каждый раз задумываешься - а не написать ли такую хрень уже

думаю есть какое-то количество велосипедов которые внутри для себя пилили крупные игроки но то что у них получилось заюзать где-то еще почти невозможно )

то что получилось сделать более-менее общим -- мы видим

да что-то оно неубедительно выглядит. т.е даже ЦА этих вещей плохо умеет в них

думаю есть какое-то количество велосипедов которые внутри для себя пилили крупные игроки но то что у них получилось заюзать где-то еще почти невозможно )

яховский фреймворк какоето время жил и даже чуток популярным был

и не похоже, что оно как-то улучшает или ускоряет или уменьшает сложность

или удешевляет

yii?

это до реактов было еще )

их сотни были - и щас есть - yii, qooxdoo, extjs

только оно все отгнивает

как по мне так и слава богу разок сталкивался с extjs -- врагу не пожелал бы

оно еще и глючное было

угу

мы в то время в итоге делали на qooxdoo бэкенды

это mfc для веба

но хоть работало и получалось

но очень verbose много писанины

ну, как и на mfс наверное

я надеюсь на elm

что у него что-то получится

но по моему они не с того конца начинают

т.е начать надо было бы с модели UI

а язык для нее - дело второе