Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Sharov, Вы писали:

S>>>> Недавно либу выкладывали для deep learning'а от ms research, так она на цпп. У ms research на дотнете совсем игрушечные вещи.

НС>>>Ресечь это баловство в основном. Поэтому там чего только нет.

S>>Из этого баловства обычно мейнстрим вырастает.

I>Наоборот — обычно из ресёрча ничего не вырастает, потому что 99% вещей тупо дохнет. Но это совсем не из-за технологий. Это наоборот влияет на применяемые технологии. Быстро получить результат, не важно каким качеством — вот главное. А в мейнстриме все крутится вокруг качества.

1% как раз индустрию и определяет. См. Xerox PARC.

Здравствуйте, Ikemefula, Вы писали:

_>>Вообще то JS уже более 20 лет и он вполне себе ровесник того же PHP, Ruby и т.п. Однако у последних уже давно наблюдается вполне сформировавшаяся картинка фреймворков (а у того же Ruby один фреймворк временами вообще весь язык представлял).
I>А почему должно быть так же как в каких то нишевых решениях, где никогда не было больше трех фремворков ?
I>Js на несколько порядков больше фремворков имеет. И это правильно — новые задачи лучше решать новыми инструментами, а не обрабатывать напильником.

Каких ещё нишевых? ) Тот же один фреймворк из руби (который рельсы) занимает на рынке на порядок больше места, чем все серверные фреймворки на JS вместе взятые. )))

_>>Да ничего подобного. ) Уже тогда были всяческие MFC/OWL/VCL и т.п. или вообще какой-нибудь TurboVision, если вспомнить вообще время GUI в DOS'е.
I>Было, только с небольшой разницей
I>1. Количество либ-фремворков изначально было мизерным.
I>2. Трудоемкость создания либы-фремворка в нативе адски высокая.
I>3. Ни один из нативных фремворков не дал и не может дать внятную абстракцию. Даже менеджед платформы навроде дотнета и джавы не дают решения.

Разговоры об абстракциях — это конечно весело, но меня интересует практика. Давай я верну разговор к началу и снова сформулирую свой вопрос (на который не видно пока ответа).

1. В области построения нативного GUI есть общеизвестные комплексные инструменты, позволяющие элементарно (частенько даже с помощью визуального редактора) решать задачу? Ответ: есть (думаю можно не перечислять?).
2. В области создания сайтов по технологии генерации html с данными на сервере есть общеизвестные комплексные инструменты, позволяющие элементарно решать задачу? Ответ: есть (думаю можно не перечислять?).
3. В области создания сайтов на базе статических страниц с дизайном и js кодом (забирающим пользовательские данные с сервера) есть общеизвестные комплексные инструменты, позволяющие элементарно решать задачу? Ответ жду от тебя, т.к. сам не готов назвать такого.

Здравствуйте, Ikemefula, Вы писали:

_>>А причём тут браузер и Кордова? ) Да, там используется веб-технологии (html, js и т.п.), но это совсем не веб-приложение, работающее в браузере.
I>И ты не видишь связи между браузером и веб-технологиями, так что ли ?

А какая связь? ) Вот скажем если встрою в своё приложение на C++ полноценных показ html страниц (например с помощью того же CEF) для каких-то своих целей (может для показа документации, а может для создания GUI, а может ещё для чего-то), то какое это всё будет иметь отношение к браузеру? И я думаю можно не пояснять, что при таком раскладе я могу дать доступ своему JS коду к любым низкоуровневым действиям? )

_>>P.S. Если бы у меня сейчас была возможность доступа к определённому железу из JS (в Cordova или браузере или ещё где), плюс возможность интеграции визуализации в JS с визуализацией из C++ кода, то я бы вполне подумал бы о реализации GUI через html+js. Но до этого ещё далеко похоже. Хотя Cordova двигается именно в этом направление.
I>Кордова двигается исключительно в сторону расширения апи. В неё, в силу архитектуры, есть куча принципиально неустранимых проблем. Даже если у тебя доступ ко всему апи системы, далеко не уедешь.

Ну это хотя бы движение в правильном направление. )

Здравствуйте, Ikemefula, Вы писали:

_>>Что же касается нагрузки на процессор, то это просто смешно. Нет, конечно я же тоже видел различные уникальные JS творения. Помнится на демо-сайте одного вроде как прорывного GUI-фреймворка (уже не помню название, вроде там было слово ракета) тормозило нажатие кнопок на моём рабочем компьютере (4Гц Xeon с 16Гб оперативки и топовой видеокартой)!
I>И ты уверен, что это именно проблемы с JS не студенческий код ?

Нуу как тебе сказать... С одной стороны конечно же понятно, что это вина не JS, а криворуких разработчиков. С другой стороны это же были как раз не студенты, а какие-то очередные гуру веб-разработки, которые создавали очередной прорывной фреймворк. Просто он (как писали сами авторы) опередил своё время. Т.е. типа сейчас ещё компы на порядок мощность нарастят и тогда будет самое оно его использовать. Так вот эта история является не какой-то очень странной, а скорее типичной в мире js веб-разработки и в полной мере характеризует все тенденции. )))

_>>Я не говорил, что таких инструментов нет (собственно я сам указал на их существование в паре сообщение выше). Я говорю скорее об общепринятой практике. Что сейчас из 10 разных JS разработчиков 5 будут использовать разные фреймворки (причём про каждый из которых только он один и слышал), а 5 напишут свой велосипед. )))
I>И правильно. В нативных либах стоимость разработки фремворка велика. Потому ты дожен изучать и допилить именно стандартную либу.
I>В JS либа и даже фремворк пилится очень быстро, то есть, задачу решаешь именно тем инструментом, что надо.

Хм, а тебе не кажется, что подобный бардак несколько неудобен? )

Здравствуйте, Sharov, Вы писали:

_>>Да, область неоднозначная. ) Но как раз на неё сейчас перемещается основной фокус развития в IT. )
S>Кроме IoT'а ничего в голову не приходит, что еще?

Ну собственно о нём и речь. Просто IoT — это такой термин, который сейчас вешают на всё. А на самом деле есть целый набор близких индустрий, которые все сейчас попали в фокус развития. Это и персональные гаджеты (всякие спортивные и медицинские) и устройства умного дома и робототехника. Всё это сейчас на пике интереса, легко получает инвестиции и т.п. И т.к. обычно все перечисленные вещи как-то общаются между собой, то на них всех вешают ярлык IoT.

Здравствуйте, Ночной Смотрящий, Вы писали:

_>> Даже если сейчас пошла мода на такой веб, это не значит что текущие проекты перейдут на него. )
НС>А кто то говорил, что непременно перейдут существующие проекты?

Всё же тебе надо как-то научиться читать форум. А то в который раз приходится тебя отправлять к сообщениям верх по ветке. Я отвечал здесь на фразу

_>Только почти весь инет из них и состоит. )))
Уже давно не так. Ты называешь сайтами принципиально разные вещи.
Фактически это HTML-приложения. Эпоха сайтов закончилась.

Здравствуйте, alex_public, Вы писали:

НС>>А кто то говорил, что непременно перейдут существующие проекты?
_>Всё же тебе надо как-то научиться читать форум.

Скорее тебе надо научится понимать русский текст.

_>

_>>Только почти весь инет из них и состоит. )))
_>Уже давно не так. Ты называешь сайтами принципиально разные вещи.
_>Фактически это HTML-приложения. Эпоха сайтов закончилась.

Здесь не сказано, что надо срочно переписывать существующие сайты.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Это тоже неверно. Для SPA вполне достаточно удобных инструментов. Самый известный, наверное, ExtJs.
_>>Я не говорил, что таких инструментов нет (собственно я сам указал на их существование в паре сообщение выше).
НС>Вот только не надо вилять:
НС>

НС> А при работе в рамках второго подхода все колбасят код руками

Если ты прочитаешь внимательно, то увидишь, что там речь шла не про разработку веб-приложения (где как раз подходят решения типа ExtJs), а про удобное создание обычного сайта. Только без генерации html сервером на лету под данным дизайна из БД, как делается сейчас у всех популярных систем (типа wordpress).

НС>Это утверждение в принципе неверно.

ОК, тогда приведи пример хоть одного инструмента, позволяющего мне создать сайт с такой же лёгкостью, как это делает wordpress/drupal/joomla, но чтобы он при этом работал не на основе генерации html сервером на лету(т.е. чтобы в предельном случае полного отсутствие пользовательских данных БД вообще была бы не нужна), а с помощью статических страниц и js.

_>> Что сейчас из 10 разных JS разработчиков 5 будут использовать разные фреймворки (причём про каждый из которых только он один и слышал), а 5 напишут свой велосипед. )))
НС>Это тоже неправда.

Это всего лишь твоё слово против моего, без всякой аргументации.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Скорее тебе надо научится понимать русский текст.
_>>

_>>>Только почти весь инет из них и состоит. )))
_>>Уже давно не так. Ты называешь сайтами принципиально разные вещи.
_>>Фактически это HTML-приложения. Эпоха сайтов закончилась.

НС>Здесь не сказано, что надо срочно переписывать существующие сайты.

Угу, здесь сказано всё гораздо круче, что как будто бы это уже давно произошло. )))

Здравствуйте, Sharov, Вы писали:

I>>Наоборот — обычно из ресёрча ничего не вырастает, потому что 99% вещей тупо дохнет. Но это совсем не из-за технологий. Это наоборот влияет на применяемые технологии. Быстро получить результат, не важно каким качеством — вот главное. А в мейнстриме все крутится вокруг качества.

S>1% как раз индустрию и определяет. См. Xerox PARC.

Не надо вилять. Ты говорил про применяемые в ресерче технологии, а не результат ресёрча. Так вот технологии ксерокса издохли и ты даже сказать не сможешь на чем же первый UI писали.

Точно так же совершенно не важно, на чем ресерч пилят, на сиплюсе, на дельфи или на дотнете — вообще нет никакой разницы. Ибо не это определяет успех.
Более того — как правило, после выхода в индустрию эти продукты первым делом переписываются с нуля.

Здравствуйте, alex_public, Вы писали:

I>>А почему должно быть так же как в каких то нишевых решениях, где никогда не было больше трех фремворков ?
I>>Js на несколько порядков больше фремворков имеет. И это правильно — новые задачи лучше решать новыми инструментами, а не обрабатывать напильником.

_>Каких ещё нишевых? ) Тот же один фреймворк из руби (который рельсы) занимает на рынке на порядок больше места, чем все серверные фреймворки на JS вместе взятые. )))

Рельсы и есть нишевой фремворк. Сравнивай с лидерами, а не экзотикой.

I>>Было, только с небольшой разницей
I>>1. Количество либ-фремворков изначально было мизерным.
I>>2. Трудоемкость создания либы-фремворка в нативе адски высокая.
I>>3. Ни один из нативных фремворков не дал и не может дать внятную абстракцию. Даже менеджед платформы навроде дотнета и джавы не дают решения.

_>Разговоры об абстракциях — это конечно весело, но меня интересует практика. Давай я верну разговор к началу и снова сформулирую свой вопрос (на который не видно пока ответа).

Ты пытаешься сравнить платформы и экосистемы без учета степени развития каждой.
25 лет назад, когда QT только появился, OS уже предлагали весь необходимый функционал для приложений — рендеринг, зависимости, юзеринпут, многозадачность, сеть и тд и тд.

В браузере все это пока развивается. Фактически, есть только кое что, по кусочкам, и те проработаны пока что слабо.
Сейчас, например, во всех без исключения фремворках огромные проблемы с многозадачностью. Это слабое место любого фремворка. QT здесь взял готовые решения. С рендерингом и юзеринпутом на той же винде QT взял готовые окна. В браузере таких высокоуровневых концептов еще нет.

То есть, QT на том же виндовсе предоставляет всего лишь апи. Всё остальное готово и реализовано в ОС. В браузере совершенно все иначе — браузер как платформа активно расширяется за счет заимствования функционала из JS фремворков. Примеры
— jQuery. Cтал лидером, после чего браузеры изменили АПИ соответсвующим образом
— Promise A+ — стал лидером, после чего браузеры изменили АПИ соответсвующим образом
— DHTML — да,да. Это лидер, благодаря IE, который убил нетшкапа.
— HTML5/CSS3
— собственно сейчас идет борьба за то, какой будет компонентная технология во фронтенде
— следующий этап, не знаю, пудозреваю это может быть первый полноценный фремворк. Это в ближайшие лет 5.

Сейчас основной тренд — микробиблиотеки, см jQuery, промисы и тд. Они позволяют наполнять браузер функионалом.

Собтсвенно фронтенд формируется слой за слоем. В конечном итоге браузеры превратятся в 'кроссплатформенную' операционную систему.

_>3. В области создания сайтов на базе статических страниц с дизайном и js кодом (забирающим пользовательские данные с сервера) есть общеизвестные комплексные инструменты, позволяющие элементарно решать задачу? Ответ жду от тебя, т.к. сам не готов назвать такого.

Я уже трижды ответил на твой вопрос. Научись читать, наконец.

Здравствуйте, alex_public, Вы писали:

_>>>А причём тут браузер и Кордова? ) Да, там используется веб-технологии (html, js и т.п.), но это совсем не веб-приложение, работающее в браузере.
I>>И ты не видишь связи между браузером и веб-технологиями, так что ли ?

_>А какая связь? )

Прямая — веб-технологии вышли из своей ниши и проникают
1 десктоп
2 мобайл
3 кроссплатформенные приложения
4 сервер
5 и тд

>Вот скажем если встрою в своё приложение на C++ полноценных показ html страниц (например с помощью того же CEF) для каких-то своих целей (может для показа документации, а может для создания GUI, а может ещё для чего-то), то какое это всё будет иметь отношение к браузеру?

Тем самым ты изобретёшь браузер.

I>>Кордова двигается исключительно в сторону расширения апи. В неё, в силу архитектуры, есть куча принципиально неустранимых проблем. Даже если у тебя доступ ко всему апи системы, далеко не уедешь.

_>Ну это хотя бы движение в правильном направление. )

Это движение приведет туда же, куда пришел ActiveX(несчетное количество), Java Applet(миллионы), Flash, Silverlight и тд и тд.

Нужно не расширять браузер, а пилить аналог веб-сервера который даст нужный функционал. Вот его как раз портировать можно будет легко и просто, а браузер при этом может быть любым.
При этом унутренний IPC нужно оптимизировать, оптимизировать, оптимизировать. Реально целая куча приложений уже не сможет влететь изза внутренностей кордовы, то есть, той части, где еще браузера нет.

Здравствуйте, alex_public, Вы писали:

_>Нуу как тебе сказать... С одной стороны конечно же понятно, что это вина не JS, а криворуких разработчиков. С другой стороны это же были как раз не студенты, а какие-то очередные гуру веб-разработки, которые создавали очередной прорывной фреймворк.

Странные какие то гуру, которые кнопку сделать не могут.

>Просто он (как писали сами авторы) опередил своё время. Т.е. типа сейчас ещё компы на порядок мощность нарастят и тогда будет самое оно его использовать. Так вот эта история является не какой-то очень странной, а скорее типичной в мире js веб-разработки и в полной мере характеризует все тенденции. )))

В нативном мире, джаве, дотнете и прочих питонах есть ровно такие же эксперименты, с еще более чудовищными провалами.


I>>В JS либа и даже фремворк пилится очень быстро, то есть, задачу решаешь именно тем инструментом, что надо.

_>Хм, а тебе не кажется, что подобный бардак несколько неудобен? )

Этот этап в нативном мире началася где то в 70х и закончился тогда, когда АПИ операционных систем и их возможности более-менее устаканились, то есть, в 90х.
Собственно только после этого и пошли развиваться те фремворки, что известны сейчас. Фремворки 80х сейчас никто не помнит, они вымерли.

Здравствуйте, alex_public, Вы писали:

_>>>

_>>>>Только почти весь инет из них и состоит. )))
_>>>Уже давно не так. Ты называешь сайтами принципиально разные вещи.
_>>>Фактически это HTML-приложения. Эпоха сайтов закончилась.

НС>>Здесь не сказано, что надо срочно переписывать существующие сайты.

_>Угу, здесь сказано всё гораздо круче, что как будто бы это уже давно произошло. )))

Нет, там сказано не это. Эпоха Кобола закончилась в 70. Из этого не следует, что на коболе никто не пишет и кобола нет в продакшне. 2 года назад был релиз очередной версии.

Переписывают только тогда, когда полностью сдохнет сама платформа, ОС, язык или приложение. Сдохнет полностью — значит не остаётся людей для её поддержки на должном уровне.
Вот тогда и переписывают. И разницы нет, на чем написано — на фортране, лиспе, коболе или на суперновом дотнете.

Здравствуйте, alex_public, Вы писали:

НС>>Здесь не сказано, что надо срочно переписывать существующие сайты.
_>Угу, здесь сказано всё гораздо круче, что как будто бы это уже давно произошло. )))

Нет, такого там тоже не сказано. Я вообще не понимаю зачем ты хочешь словам придать не тот смысл, что они очевидным образом означают. Там совершенно справедливо замечено, что современные сайты это все больше приложения. И rsdn тут даже близко не исключение, даже с учетом оставшихся старых кусков. Классический веб-сайт здесь это статьи. И они таки явно сейчас не образуют основу сайта. А форум был и остается приложением с самого своего рождения, о чем тебе Икемефула практически сразу и намекнул, предложив реализовать форум на Qt.
А вот ты зачем то решил извратить это, подменив понятие веб-приложения понятием SPA. И это не смотря на то, что я тебе несколько раз говорил, что SPA подход не лишен серьезных недостатков, и вовсе не факт что это будущее веба.

С>Может я и ошибаюсь, но в 30кб нельзя запихнуть полноценный стек TCP/IP даже на ассемблере. То есть, мы берем хорошую вещь и обрубаем от нее все, что можно, огрызком гордимся. За это и платят, за впихивание невпихуемого, сжатие с потерями.
Ошибаешься. Полноценные мелкие решения вполне существуют, например SharkSSL

Для ARM TCP/IP + Драйвера + SSL + MQ (собственное) — 38KB ROM + 13 RAM. Если нужен только TCP/IP + Драйвера, То его там <15 KB. За ещё десяток килобайтов дают WebSocket'ы (клиент и сервер) и HTTP Server.

Здравствуйте, alex_public, Вы писали:

НС>>Вот только не надо вилять:
НС>>

НС>> А при работе в рамках второго подхода все колбасят код руками

_>Если ты прочитаешь внимательно, то увидишь, что там речь шла не про разработку веб-приложения (где как раз подходят решения типа ExtJs), а про удобное создание обычного сайта.

Что такое "обычный сайт", и почему его обязательно колбасить руками?

_> Только без генерации html сервером на лету под данным дизайна из БД,

Ты сейчас вообще о чем?

_> как делается сейчас у всех популярных систем (типа wordpress).

Wordpress это вообще не тема, когда мы рассуждаем о перспективе. И что это за "все популярные системы" тоже непонятно. Если речь про CMS, то это, мягко говоря, далеко не весь веб, это ширпотреб в мире веб-разработки.

НС>>Это утверждение в принципе неверно.
_>ОК, тогда приведи пример хоть одного инструмента, позволяющего мне создать сайт с такой же лёгкостью, как это делает wordpress/drupal/joomla

Я правильно понял — ты не понимаешь отличия между внедрением CMS и разработкой сайта с нуля?
Давай я тебе на более понятным примерах проиллюстрирую: нет ни одной унверсальной среды разработки, которая позволила бы создать бухгалтерскую софтинку с такой же скоростью, с какой это позволяет сделать 1С. Но это же не делает 1С мерилом прогресса в области разработки любого десктопного софта, верно?
Отвечая на твой вопрос — я вообще не в курсе, есть ли готовая CMS, построенная на принципах SPA, и мне, честно говоря, на данный момент совершенно пофигу, потому что внедрение CMS сейчас лежит сильно далеко за пределами сферы моих интересов. Думаю, в чистом, дистиллированом виде такой нет, потому что с SPA масса проблем и оно нахрен такое никому не нужно. А если с активной генерацией контента на клиенте — гугль подсказывает что таких CMS есть: dotCMS, OpenWGA от авторов ExtJS, Koala, HippoCMS и т.д.

НС>>Это тоже неправда.
_>Это всего лишь твоё слово против моего, без всякой аргументации.

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

Здравствуйте, Ikemefula, Вы писали:

_>>Каких ещё нишевых? ) Тот же один фреймворк из руби (который рельсы) занимает на рынке на порядок больше места, чем все серверные фреймворки на JS вместе взятые. )))
I>Рельсы и есть нишевой фремворк. Сравнивай с лидерами, а не экзотикой.

Что за ниша такая у него? ) "веб-разработка"? )))

_>>Разговоры об абстракциях — это конечно весело, но меня интересует практика. Давай я верну разговор к началу и снова сформулирую свой вопрос (на который не видно пока ответа).
I>Ты пытаешься сравнить платформы и экосистемы без учета степени развития каждой.
I>25 лет назад, когда QT только появился, OS уже предлагали весь необходимый функционал для приложений — рендеринг, зависимости, юзеринпут, многозадачность, сеть и тд и тд.
I>В браузере все это пока развивается. Фактически, есть только кое что, по кусочкам, и те проработаны пока что слабо.
I>Сейчас, например, во всех без исключения фремворках огромные проблемы с многозадачностью. Это слабое место любого фремворка. QT здесь взял готовые решения. С рендерингом и юзеринпутом на той же винде QT взял готовые окна. В браузере таких высокоуровневых концептов еще нет.

Хыхы, вот чувствуется, что ты ничего не знаешь, но при этом смело рассуждаешь.

Как раз Qt имеет полностью свою прорисовку (по сути эта библиотека — это универсальная оконная система с набором скинов под все известные платформы), причём частенько более оптимальную, через оригинальная на платформе (может использовать ускорение). Именно поэтому она так легко была портирована на Андроид (в отличие от той же wxWidgets, которая как раз основана на родных контролах под каждой платформой и переписывается на Андроид со страшными муками в виде java-прокси) и даже имеет версию работающую вообще без ОС (прямо на устройствах).

Более того, особенно забавно слушать твои рассуждения о наличие такой поддержки в ОС и отсутствие подобного в браузерах с учётом того, что Qt была портирована и в браузеры (с помощью компилятора C++ в JS emscripten): http://vps2.etotheipiplusone.com:30176/redmine/projects/emscripten-qt/wiki/Demos. Причём работает там намного быстрее самых крутых js фреймворков. Если реализовать на каком-нибудь из них полноценный сложный интерфейс типа такого http://vps2.etotheipiplusone.com:30176/redmine/emscripten-qt-examples/kate/kate.html, то оно будет тупить нереально. А тут, как видно, всё нормально работает. Не смотря на то, что в браузере (и даже без webassembly пока).

I>То есть, QT на том же виндовсе предоставляет всего лишь апи. Всё остальное готово и реализовано в ОС. В браузере совершенно все иначе — браузер как платформа активно расширяется за счет заимствования функционала из JS фремворков. Примеры
I>- jQuery. Cтал лидером, после чего браузеры изменили АПИ соответсвующим образом
I>- Promise A+ — стал лидером, после чего браузеры изменили АПИ соответсвующим образом
I>- DHTML — да,да. Это лидер, благодаря IE, который убил нетшкапа.
I>- HTML5/CSS3
I>- собственно сейчас идет борьба за то, какой будет компонентная технология во фронтенде
I>- следующий этап, не знаю, пудозреваю это может быть первый полноценный фремворк. Это в ближайшие лет 5.
I>Сейчас основной тренд — микробиблиотеки, см jQuery, промисы и тд. Они позволяют наполнять браузер функионалом.
I>Собтсвенно фронтенд формируется слой за слоем. В конечном итоге браузеры превратятся в 'кроссплатформенную' операционную систему.

Если ты взглянешь на многие кроссплатформенные gui библиотеки, то увидишь, что им от платформы необходимо (обычно это абстрагируют в специальный интерфейс, который и реализуют под каждую платформу) исключительно возможность прорисовки на плоскость (аналог canvas в браузере) и возможность реакции на события мышки/клавиатуры. Это имеется в наличие уже очень давно.

_>>3. В области создания сайтов на базе статических страниц с дизайном и js кодом (забирающим пользовательские данные с сервера) есть общеизвестные комплексные инструменты, позволяющие элементарно решать задачу? Ответ жду от тебя, т.к. сам не готов назвать такого.
I>Я уже трижды ответил на твой вопрос. Научись читать, наконец.

Да, я уже понял, что неявным ответом у тебя было: "нет, такого не существует". Но самое забавно, что весь текст выше (про Qt или его аналоги в мире JS, типа ExtJS) вообще никакого отношения не имеет к этому моему изначальному вопросу. Потому что тут я хочу именно сайт, а не веб-приложение! Поэтому мне тут не нужен ни Qt, ни ExtJS или аналоги. Более того, эта задача уже давно решена в виде серверных решений, генерирующих html на лету. Так что не вижу никаких технических оправданий отсутствию существованию аналогичного клиентского решения на js.

Здравствуйте, Ikemefula, Вы писали:

_>>А какая связь? )
I>Прямая — веб-технологии вышли из своей ниши и проникают
I>1 десктоп
I>2 мобайл
I>3 кроссплатформенные приложения
I>4 сервер
I>5 и тд

Давай разберёмся, как веб-технологии проникают. В виде доступа к сайтам с этих устройств или же в виде применения этих технологий скажем для реализации веб-интерфейсах в приложениях и т.п. Это как бы совсем разные вещи.

>>Вот скажем если встрою в своё приложение на C++ полноценных показ html страниц (например с помощью того же CEF) для каких-то своих целей (может для показа документации, а может для создания GUI, а может ещё для чего-то), то какое это всё будет иметь отношение к браузеру?
I>Тем самым ты изобретёшь браузер.

Да, в какой-то мере. Только этот кастомный браузер будет полностью лишён всех ограничений обычного в контексте данной моей задачи. )

_>>Ну это хотя бы движение в правильном направление. )
I>Это движение приведет туда же, куда пришел ActiveX(несчетное количество), Java Applet(миллионы), Flash, Silverlight и тд и тд.
I>Нужно не расширять браузер, а пилить аналог веб-сервера который даст нужный функционал. Вот его как раз портировать можно будет легко и просто, а браузер при этом может быть любым.

Пока-что браузер не способен до конца выполнить роль даже универсального плеера интерфейсов. Я тебе уже приводил примеры с видео и т.п.

I>При этом унутренний IPC нужно оптимизировать, оптимизировать, оптимизировать. Реально целая куча приложений уже не сможет влететь изза внутренностей кордовы, то есть, той части, где еще браузера нет.

Ну Кордова то пока явно недоделанное решение, с этим никто не спорит. ) Но вдруг вырастет куда надо. )))

Здравствуйте, Ikemefula, Вы писали:

I>Этот этап в нативном мире началася где то в 70х и закончился тогда, когда АПИ операционных систем и их возможности более-менее устаканились, то есть, в 90х.
I>Собственно только после этого и пошли развиваться те фремворки, что известны сейчас. Фремворки 80х сейчас никто не помнит, они вымерли.

Если мы говорим про API для приложений (окна там, контролы и т.п.), то почему не взять готовые решения из мира нативного GUI? Думаешь в JS в итоге найдут какой-то совершенно другой подход? Глядя на тот же ExtJs очень сомневаюсь... )))

Если же мы говорим про API для сайтов, то это опять же всё уже давно готово в мире серверного веб'а. И десятки движков шаблонизаторов. И готовые схемы сайтов с целыми каталогами готовых шаблонов (реализующих дизайн) и много чего. Просто переноси это на клиента и всё. Или вообще в процесс разработки в случае статического сайта (кстати, вот такие решения вполне себе существуют, хотя и опять же не сильно популярны).