Здравствуйте, Ikemefula, Вы писали:
НС>>>Здесь не сказано, что надо срочно переписывать существующие сайты. _>>Угу, здесь сказано всё гораздо круче, что как будто бы это уже давно произошло. ))) I>Нет, там сказано не это. Эпоха Кобола закончилась в 70. Из этого не следует, что на коболе никто не пишет и кобола нет в продакшне. 2 года назад был релиз очередной версии. I>Переписывают только тогда, когда полностью сдохнет сама платформа, ОС, язык или приложение. Сдохнет полностью — значит не остаётся людей для её поддержки на должном уровне. I>Вот тогда и переписывают. И разницы нет, на чем написано — на фортране, лиспе, коболе или на суперновом дотнете.
Но по сравнению с Коболом есть существенная разница — приложений на современных принципах успели наделать в тысячи раз больше, чем было/осталось на Коболе. А вот с сайтами всё наоборот. Пока что по созданных по новым принципам сайтов скорее меньшинство. Так что твоя фраза "уже давно не так" в ответ на мою "Только почти весь инет из них и состоит" очевидно бредова.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Нет, такого там тоже не сказано. Я вообще не понимаю зачем ты хочешь словам придать не тот смысл, что они очевидным образом означают. Там совершенно справедливо замечено, что современные сайты это все больше приложения. И rsdn тут даже близко не исключение, даже с учетом оставшихся старых кусков. Классический веб-сайт здесь это статьи. И они таки явно сейчас не образуют основу сайта. А форум был и остается приложением с самого своего рождения, о чем тебе Икемефула практически сразу и намекнул, предложив реализовать форум на Qt. НС>А вот ты зачем то решил извратить это, подменив понятие веб-приложения понятием SPA. И это не смотря на то, что я тебе несколько раз говорил, что SPA подход не лишен серьезных недостатков, и вовсе не факт что это будущее веба.
Это rsdn то приложение? ) Который генерирует весь контент на сервере? Я уже молчу про фреймы))) Это всё как раз классический древний подход динамического сайта, где вся работа происходит на сервере. Никаких особых отличий от какого-нибудь дикого phpBB не видно.
Да, и насчёт SPA и сайтов в стиле веб-приложения (с гуи типа десктопного) — кто тебе сказал, что оно мне нравится или я вообще об этом говорил? Речь шла о сайтах без генерации страниц на сервере из БД. Т.е. в вырожденном случае отсутствия пользовательских данных это будет просто статический сайт из html файлов, лежащих на сервере. Т.е. не одна html страничка, а множество. И нормальный дизайн, а не окна с контролами.
Здравствуйте, alex_public, Вы писали:
_>Это rsdn то приложение? )
Вне всяких сомнений.
_> Который генерирует весь контент на сервере?
Которое не генерирует весь контент на сервере. Я уж молчу про то, что генерация контента на клиенте не является обязательным признаком веб-приложения.
_> Я уже молчу про фреймы)))
Молчи. Потому что они вообще не причем.
_> Это всё как раз классический древний подход динамического сайта, где вся работа происходит на сервере. Никаких особых отличий от какого-нибудь дикого phpBB не видно.
Что в очередной раз демонстрирует, что ты не в теме.
_>Да, и насчёт SPA и сайтов в стиле веб-приложения (с гуи типа десктопного) — кто тебе сказал, что оно мне нравится или я вообще об этом говорил?
Ты неоднократно втирал, что за SPA будущее.
_> Речь шла о сайтах без генерации страниц на сервере из БД.
Это и есть SPA.
_>Т.е. не одна html страничка, а множество.
Это неважно. Не надо термин понимать слишком буквально. Single в нем означает одну загрузку из адресной строки браузера. А если есть переходы по ссылкам, то это уже совершенно классическое веб-приложение, и совершенно неважно как динамические данные с сервера передаются — в виде данных внутри страницы или отдельным запросом. Как я тебе уже писал, а ты пропустил мимо ушей — в нормальных приложениях начальные данные передаются сразу, внутри страницы, а уже в ходе деятельности страницы они забираются отдельными запросами из скрипта, причем это могут быть ровно те же самые данные.
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>Если ты прочитаешь внимательно, то увидишь, что там речь шла не про разработку веб-приложения (где как раз подходят решения типа ExtJs), а про удобное создание обычного сайта. НС>Что такое "обычный сайт", и почему его обязательно колбасить руками?
Обычный сайт — это как раз следуя твоей терминологии не SPA. А руками его надо колбасить в случае если мы не хотим использовать технику генерации html сервером на лету. Ну точнее имеется конечно же несколько инструментов и в этой области (восходящих к статическим генераторам сайтов), но крайне слабеньких, малоразвитых, да и мало кто про них вообще слышал.
_>> как делается сейчас у всех популярных систем (типа wordpress). НС>Wordpress это вообще не тема, когда мы рассуждаем о перспективе. И что это за "все популярные системы" тоже непонятно. Если речь про CMS, то это, мягко говоря, далеко не весь веб, это ширпотреб в мире веб-разработки.
Ну а во-вторых, если уж JS сообщество не может даже ширпотреб осилить, то... )))
НС>>>Это утверждение в принципе неверно. _>>ОК, тогда приведи пример хоть одного инструмента, позволяющего мне создать сайт с такой же лёгкостью, как это делает wordpress/drupal/joomla НС>Я правильно понял — ты не понимаешь отличия между внедрением CMS и разработкой сайта с нуля?
Я прекрасно знаю разницу. Но в мире серверного веба есть и фреймворки для разработки с нуля и CMS и даже на голом php можно фигачить. Соответственно я ожидаю того же и от мира веб-разработки на клиентском js.
НС>Отвечая на твой вопрос — я вообще не в курсе, есть ли готовая CMS, построенная на принципах SPA, и мне, честно говоря, на данный момент совершенно пофигу, потому что внедрение CMS сейчас лежит сильно далеко за пределами сферы моих интересов. Думаю, в чистом, дистиллированом виде такой нет, потому что с SPA масса проблем и оно нахрен такое никому не нужно.
А не надо SPA (и кстати как раз такие инструменты можно сказать что есть — тот же визуальный редактор в некоторых JS фреймворках)! Давай как раз нормальный сайт, но без серверных генераций html.
НС>А если с активной генерацией контента на клиенте — гугль подсказывает что таких CMS есть: dotCMS, OpenWGA от авторов ExtJS, Koala, HippoCMS и т.д.
Что-то я не понял как ты там пользовался гуглом... Похоже как-то неудачно. Я открыл часть твои пунктов и все они представляют собой обычные CMS. Скорее надо смотреть что-то из этой https://github.com/ahadb/flat-file-cms области. Но там опять же всё какие-то неизвестные недоделки в основном.
Здравствуйте, alex_public, Вы писали:
_>Обычный сайт — это как раз следуя твоей терминологии не SPA.
Т.е. у тебя все черно-белое? И чего то среднего быть не может в принципе?
Это не праздный вопрос, ты не подумай. Дело в том что большинство сайтов с приличным программным наполнением ныне как раз посередине — и на сервере много работы делается, и на клиенте.
_> А руками его надо колбасить в случае если мы не хотим использовать технику генерации html сервером на лету.
Я по прежнему не могу понять — в чем принципиальное отличие что генерить на сервере, HTML, XML или JSON.
_>Ну для начала на этом "ширпотребе" работает большая часть всего инета.
Нет, не работает. Эта статистика всего лишь отражает, что огромное количество мелких сайтов использует конкретную CMS. В РФ, к примеру, наверное те же 25% сайтов были на narod.ru. Отражало ли это ситуацию с технологиями?
_>Ну а во-вторых, если уж JS сообщество не может даже ширпотреб осилить, то... )))
JS сообщество все может осилить, просто ты не видишь реальных потребностей. Ты сам зачем то превознес SPA, а потом удивляешься почемцу эти самые SPA не особенно то и популярны.
НС>>Я правильно понял — ты не понимаешь отличия между внедрением CMS и разработкой сайта с нуля? _>Я прекрасно знаю разницу. Но в мире серверного веба есть и фреймворки для разработки с нуля и CMS и даже на голом php можно фигачить. Соответственно я ожидаю того же и от мира веб-разработки на клиентском js.
Ну и все там есть. ExtJS, я вижу, ты уже для себя открыл. Было бы интересно — давно бы уже нашел все что нужно. Но тебе, похоже, нужно только себя убедить в готовой теории. Все как с дотнетом, который у тебя много лет назад еще вот вот должен был умереть, да все не умрет никак, гад.
_>Давай как раз нормальный сайт, но без серверных генераций html.
А JSON для скрипта у тебя тоже статический?
_>Что-то я не понял как ты там пользовался гуглом... Похоже как-то неудачно. Я открыл часть твои пунктов и все они представляют собой обычные CMS.
Я тебе сразу сказал, что сферических коней в вакууме нет, за их ненадобностью. Есть гибридные системы. Но ты как то странно читаешь мои сообщения, самое интересное просто игнорируя.
_> Скорее надо смотреть что-то из этой https://github.com/ahadb/flat-file-cms области. Но там опять же всё какие-то неизвестные недоделки в основном.
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>Это rsdn то приложение? ) НС>Вне всяких сомнений.
Ну это вопрос терминологии. Я так понимаю, что наличие любой динамики (типа формочки обратной связи) делает для тебя сайт приложением? )
_>>Да, и насчёт SPA и сайтов в стиле веб-приложения (с гуи типа десктопного) — кто тебе сказал, что оно мне нравится или я вообще об этом говорил? НС>Ты неоднократно втирал, что за SPA будущее.
Я как раз говорил не раз говорил, что мне нужен просто сайт, а не приложение!
_>> Речь шла о сайтах без генерации страниц на сервере из БД. НС>Это и есть SPA.
С чего бы это? Т.е. к примеру чисто статический сайт (на сервере только nginx и всё) с кучей страниц — это у нас теперь тоже SPA называется? )
_>>Т.е. не одна html страничка, а множество. НС>Это неважно. Не надо термин понимать слишком буквально. Single в нем означает одну загрузку из адресной строки браузера. А если есть переходы по ссылкам, то это уже совершенно классическое веб-приложение, и совершенно неважно как динамические данные с сервера передаются — в виде данных внутри страницы или отдельным запросом. Как я тебе уже писал, а ты пропустил мимо ушей — в нормальных приложениях начальные данные передаются сразу, внутри страницы, а уже в ходе деятельности страницы они забираются отдельными запросами из скрипта, причем это могут быть ровно те же самые данные.
OK, уточняю ещё раз. ))) Хочу сайт с кучей страниц, гиперссылками между ними и т.п. Но при этом без генерации html на сервере на лету. А в случае отсутствия пользовательских данных ещё и без БД на сервере. Какой автоматический инструмент быстро реализует мне это и какие js фреймворки будут лежать в основе (ну там менюшку реализовывать и т.п.)?
Здравствуйте, alex_public, Вы писали:
_>>>Это rsdn то приложение? ) НС>>Вне всяких сомнений. _>Ну это вопрос терминологии.
Именною И ты пытаешься ею манипулировать, чтобы подогнать факты под свою теорию. А на практике нет никакой четкой границы.
_> Я так понимаю, что наличие любой динамики (типа формочки обратной связи) делает для тебя сайт приложением? )
Сайт делает приложением наличие функционала, характерного для полноценного приложения. Технологии же вторичны.
НС>>Ты неоднократно втирал, что за SPA будущее. _>Я как раз говорил не раз говорил, что мне нужен просто сайт, а не приложение!
Осталось еще понять в чем отличие для тебя.
_>С чего бы это? Т.е. к примеру чисто статический сайт (на сервере только nginx и всё) с кучей страниц — это у нас теперь тоже SPA называется? )
Здравствуйте, Ночной Смотрящий, Вы писали:
_>> А руками его надо колбасить в случае если мы не хотим использовать технику генерации html сервером на лету. НС>Я по прежнему не могу понять — в чем принципиальное отличие что генерить на сервере, HTML, XML или JSON.
Потому что на нормальном сайте большая часть страниц обычно не содержит генерируемый на ходу контент. Соответственно размещать эти данные в БД и потом прогонять через шаблонизатор для накладывания дизайна при каждом запросе пользователя глупо. Логичнее это сделать в момент формирования контента и разместить на диске сразу итоговый html.
Что же касается динамических данных (зависящих от запроса пользователя), то для них страницы естественно заранее не сгенерируешь, но зато остаётся вариант прогонки их через шаблонизатор на машине клиента (предварительно получив через ajax). В таком стиле (это как раз то, что ты называешь SPA?) можно реализовать страницы типа поиска и т.п., но естественно не весь сайт.
_>>Ну для начала на этом "ширпотребе" работает большая часть всего инета. НС>Нет, не работает. Эта статистика всего лишь отражает, что огромное количество мелких сайтов использует конкретную CMS. В РФ, к примеру, наверное те же 25% сайтов были на narod.ru. Отражало ли это ситуацию с технологиями?
Я что-то не пойму, если "огромное количество мелких сайтов использует конкретную CMS", то это типа никак не описывает ситуацию в индустрии? )))
_>>Ну а во-вторых, если уж JS сообщество не может даже ширпотреб осилить, то... ))) НС>JS сообщество все может осилить, просто ты не видишь реальных потребностей. Ты сам зачем то превознес SPA, а потом удивляешься почемцу эти самые SPA не особенно то и популярны.
Реальной потребности действительно особо нет. Но не потому, что ты думаешь. А потому что все тупо сидят на wordpress и ко, наплевав на его неэффективность для большинства их целей. Хотя вот как раз js сообщество могло бы своей реализацией полного аналога (но естественно намного эффективнее) сделать себе неплохую рекламу. Но видимо сложно... )
НС>А JSON для скрипта у тебя тоже статический?
JSON никто не прогоняет сквозь шаблонизатор (вместе с кучей дополнительных настроек из БД). Ну а для статического сайта вообще никаких JSON не будет. )))
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>Ну это вопрос терминологии. НС>Именною И ты пытаешься ею манипулировать, чтобы подогнать факты под свою теорию. А на практике нет никакой четкой границы.
Какую теорию то? ) Я изначально высказал простую мысль, что на рынке не видно общеизвестных инструментов под довольно простую задачку. И как не играйся с терминологией для этой задачки, данного инструмента от этого не появится.
_>> Я так понимаю, что наличие любой динамики (типа формочки обратной связи) делает для тебя сайт приложением? ) НС>Сайт делает приложением наличие функционала, характерного для полноценного приложения. Технологии же вторичны.
Нуу так озвучь критерии. ) Я тогда скажу мне нужен сайт или приложение в твоей терминологии.
НС>>>Ты неоднократно втирал, что за SPA будущее. _>>Я как раз говорил не раз говорил, что мне нужен просто сайт, а не приложение! НС>Осталось еще понять в чем отличие для тебя.
Что бы не было интерфейса в стиле десктопного GUI (обычно оно такое как раз у SPA).
_>>С чего бы это? Т.е. к примеру чисто статический сайт (на сервере только nginx и всё) с кучей страниц — это у нас теперь тоже SPA называется? ) НС>Можно реальные примеры таких сайтов?
Здравствуйте, alex_public, Вы писали:
_>>>Хыхы, ну вообще то все тяжёлые приложения и для мобильного мира пишутся на C++. НС>>Тут главное — верить. _>Ну а на чём по твоему пишутся например тяжёлые 3D игры под Android/iOS? )
Здравствуйте, alexzz, Вы писали:
_>>Ну а на чём по твоему пишутся например тяжёлые 3D игры под Android/iOS? ) A>Они пишутся на C# под Unity. Бóльшая часть.
Эм, ну так Unity — это и есть C++ движок. ))) А C# там только в качестве скриптового языка. И то опционального (одного из трёх предлагаемых).
Здравствуйте, alex_public, Вы писали:
I>>Переписывают только тогда, когда полностью сдохнет сама платформа, ОС, язык или приложение. Сдохнет полностью — значит не остаётся людей для её поддержки на должном уровне. I>>Вот тогда и переписывают. И разницы нет, на чем написано — на фортране, лиспе, коболе или на суперновом дотнете.
_>Но по сравнению с Коболом есть существенная разница — приложений на современных принципах успели наделать в тысячи раз больше, чем было/осталось на Коболе.
А вот по количеству кода Кобол уступает наверное только какому нибудь... JavaScript.
>А вот с сайтами всё наоборот. Пока что по созданных по новым принципам сайтов скорее меньшинство.
Ага, каждая новая опрационная система — говно, потому что на момент релиза у неё аудитория в миллион раз меньше старой.
I>>Этот этап в нативном мире началася где то в 70х и закончился тогда, когда АПИ операционных систем и их возможности более-менее устаканились, то есть, в 90х. I>>Собственно только после этого и пошли развиваться те фремворки, что известны сейчас. Фремворки 80х сейчас никто не помнит, они вымерли.
_>Если мы говорим про API для приложений (окна там, контролы и т.п.), то почему не взять готовые решения из мира нативного GUI? Думаешь в JS в итоге найдут какой-то совершенно другой подход? Глядя на тот же ExtJs очень сомневаюсь... )))
Готовые решения — это заюзать 100% готовый функционал, только обложить апишкой, как это сделали qt и mfc те же.
В браузере ничего готового нет.
Проблема не в выборе контролов. Их то как раз никто и не изобретает. Ext,js уже история, он тупо слился. И кстати говоря, в ём есть все о чем ты плакался — писать код можно практически мышом.
_>Если же мы говорим про API для сайтов, то это опять же всё уже давно готово в мире серверного веб'а.
В серверном вебе убогая динамика.
>И десятки движков шаблонизаторов. И готовые схемы сайтов с целыми каталогами готовых шаблонов (реализующих дизайн) и много чего. Просто переноси это на клиента и всё.
Это уже пройденный этап. Серверные шаблонизаторы убоги и ожидаемо слились. Собтсвенно именно это и послужило причиной популярности ангуляра и реакта.
Здравствуйте, alex_public, Вы писали:
_>>>А какая связь? ) I>>Прямая — веб-технологии вышли из своей ниши и проникают I>>1 десктоп I>>2 мобайл I>>3 кроссплатформенные приложения I>>4 сервер I>>5 и тд
_>Давай разберёмся, как веб-технологии проникают. В виде доступа к сайтам с этих устройств или же в виде применения этих технологий скажем для реализации веб-интерфейсах в приложениях и т.п. Это как бы совсем разные вещи.
Прекрати увиливать. На JS пишутся десктоп прилоежния, мобайл, кроссплатформенные, серверные.
I>>Тем самым ты изобретёшь браузер. _>Да, в какой-то мере. Только этот кастомный браузер будет полностью лишён всех ограничений обычного в контексте данной моей задачи. )
Изобрели примерно 15 лет назад. Не взлетело.
_>Пока-что браузер не способен до конца выполнить роль даже универсального плеера интерфейсов. Я тебе уже приводил примеры с видео и т.п.
Это не важно. Зато он умеет рендерить текст, а вот твой хвалёный QT — нет.
I>>При этом унутренний IPC нужно оптимизировать, оптимизировать, оптимизировать. Реально целая куча приложений уже не сможет влететь изза внутренностей кордовы, то есть, той части, где еще браузера нет.
_>Ну Кордова то пока явно недоделанное решение, с этим никто не спорит. ) Но вдруг вырастет куда надо. )))
Если они откажутся от текущего подхода и начнуть под этим же брендом пилить чтото другое — да, возможно.
Здравствуйте, alex_public, Вы писали:
_>>>Ну а на чём по твоему пишутся например тяжёлые 3D игры под Android/iOS? ) A>>Они пишутся на C# под Unity. Бóльшая часть. _>Эм, ну так Unity — это и есть C++ движок. ))) А C# там только в качестве скриптового языка. И то опционального (одного из трёх предлагаемых).
В таком случае ещё можно вспомнить, на чём написана ОС, под которую делается игра, или микрокод внутри процессора. Когда ты собираешься делать 3D игру под Android/iOS, ты не пишешь вначале Unity на C++/Асм, а потом игру на C# под этот Unity. Ты берёшь готовый Unity, один для всех, и пишешь свою игру сразу на C#. C++ для тебя не существует. Cities: Skylines на PC и Angry Birds 2 на iOS с точки зрения программиста отличаются только разным кодом на C#.
_>C# там только в качестве скриптового языка
Никто ведь не считает C++ скриптовым языком для MFC. C# в Unity не отличается от C# вне Unity. Потоки, указатели, P/Invoke? — сколько хочешь. В случае смерти игрока форматнуть диск или удалить половину реестра? — ради бога, лишь бы были права администратора.
Других языков в Unity считай, что уже нет. Boo умер официально. UnityScript по инерции шевелится, но и ему тоже осталось недолго. Бесконечные дискуссии на оф. форуме на тему C# vs UnityScript прекратились ввиду очевидности ответа для всех участников.
Здравствуйте, alex_public, Вы писали:
I>>Рельсы и есть нишевой фремворк. Сравнивай с лидерами, а не экзотикой.
_>Что за ниша такая у него? ) "веб-разработка"? )))
У него мизерная доля в этой веб-разработке.
I>>Сейчас, например, во всех без исключения фремворках огромные проблемы с многозадачностью. Это слабое место любого фремворка. QT здесь взял готовые решения. С рендерингом и юзеринпутом на той же винде QT взял готовые окна. В браузере таких высокоуровневых концептов еще нет.
_>Хыхы, вот чувствуется, что ты ничего не знаешь, но при этом смело рассуждаешь.
С чем именно ты не согласен ? На счет многозадачности ? Рендеринга ? Юзеринпута ? Окон ?
_>Как раз Qt имеет полностью свою прорисовку (по сути эта библиотека — это универсальная оконная система с набором скинов под все известные платформы), причём частенько более оптимальную, через оригинальная на платформе (может использовать ускорение).
Ога. Надо полагать именно по этому qt регистрирует класс QWidget через который и выполняет рендеринг средствами GDI32 и слушает события чз User32 ?
_>Более того, особенно забавно слушать твои рассуждения о наличие такой поддержки в ОС и отсутствие подобного в браузерах с учётом того, что Qt была портирована и в браузеры (с помощью компилятора C++ в JS emscripten): http://vps2.etotheipiplusone.com:30176/redmine/projects/emscripten-qt/wiki/Demos. Причём работает там намного быстрее самых крутых js фреймворков.
Враньё. Браузер не умеет специально для QT работать быстрее или как то особенно.
_>Если ты взглянешь на многие кроссплатформенные gui библиотеки, то увидишь, что им от платформы необходимо (обычно это абстрагируют в специальный интерфейс, который и реализуют под каждую платформу) исключительно возможность прорисовки на плоскость (аналог canvas в браузере) и возможность реакции на события мышки/клавиатуры. Это имеется в наличие уже очень давно.
Не на плоскость, а в окно. Другого варианта нет, не было, и никогда не будет.
I>>Я уже трижды ответил на твой вопрос. Научись читать, наконец.
_>Да, я уже понял, что неявным ответом у тебя было: "нет, такого не существует".
Был прямой ответ на твой вопрос. Хватит врать !
>Но самое забавно, что весь текст выше (про Qt или его аналоги в мире JS, типа ExtJS) вообще никакого отношения не имеет к этому моему изначальному вопросу. Потому что тут я хочу именно сайт, а не веб-приложение!
Сайты уже вчерашний день. Пару лет назад нормой было сайты шпиговать приложениями, виджетами, расширениями и прочими вещами.
Собственно сейчас видим следующий шаг — функционала становится больше.
Здравствуйте, kr510, Вы писали:
I>>Надо полагать именно по этому около нуля приложений под винду пишется на этом QT ?
K>Откуда данные? K>Из примеров на Qt — Notepad++ Genymotion VirtualBox
Notepad++
"Notepad++ is written in C++ and uses pure Win32 API and STL which ensures a higher execution speed and smaller program size"
Здравствуйте, alex_public, Вы писали:
НС>>Именною И ты пытаешься ею манипулировать, чтобы подогнать факты под свою теорию. А на практике нет никакой четкой границы. _>Какую теорию то? )
Что в JS нет правильных фреймвоков.
_> Я изначально высказал простую мысль, что на рынке не видно общеизвестных инструментов под довольно простую задачку. И как не играйся с терминологией для этой задачки, данного инструмента от этого не появится.
Вывод то какой из этой твоей мысли?
_>>> Я так понимаю, что наличие любой динамики (типа формочки обратной связи) делает для тебя сайт приложением? ) НС>>Сайт делает приложением наличие функционала, характерного для полноценного приложения. Технологии же вторичны. _>Нуу так озвучь критерии. )
Я выделил.
НС>>Осталось еще понять в чем отличие для тебя. _>Что бы не было интерфейса в стиле десктопного GUI (обычно оно такое как раз у SPA).
А что такое "интерфейс в стиле десктопного GUI" и почему он для тебя так важен?
_>>>С чего бы это? Т.е. к примеру чисто статический сайт (на сервере только nginx и всё) с кучей страниц — это у нас теперь тоже SPA называется? ) НС>>Можно реальные примеры таких сайтов? _>Нуу вот http://www.myhdl.org например. )))
Сморю исходники. А там серверные скрипты на питоне, да весь контент в маркдауне, хотя на сервер отдается html. Это у тебя статика такая, да?
JS фреймворк там, кстати, присутствует в полные рост — http://getbootstrap.com/javascript/
Здравствуйте, Ikemefula, Вы писали:
_>>Если мы говорим про API для приложений (окна там, контролы и т.п.), то почему не взять готовые решения из мира нативного GUI? Думаешь в JS в итоге найдут какой-то совершенно другой подход? Глядя на тот же ExtJs очень сомневаюсь... ))) I>Готовые решения — это заюзать 100% готовый функционал, только обложить апишкой, как это сделали qt и mfc те же. I>В браузере ничего готового нет.
Ты продолжаешь писать этот бред даже после того, как я тебе продемонстрировал Qt скомпилированную под браузер? )))
I>Проблема не в выборе контролов. Их то как раз никто и не изобретает. Ext,js уже история, он тупо слился. И кстати говоря, в ём есть все о чем ты плакался — писать код можно практически мышом.
Да, ExtJS и ему подобные (например ещё такой http://dhtmlx.com/docs/products/visualDesigner/live/ фреймворк я видел) решают проблему для построения веб-приложение. И если бы мне надо было запрограммировать что-то вроде контрольной панели сервера, то я бы обязательно воспользоваться чем-то подобным. Но меня больше интересует решение моей задачки с созданием сайта в таком же режиме! Тем более, что в мире серверного веб'а эта задачка давно решена...
_>>Если же мы говорим про API для сайтов, то это опять же всё уже давно готово в мире серверного веб'а. I>В серверном вебе убогая динамика.
Это в каком смысле? )
>>И десятки движков шаблонизаторов. И готовые схемы сайтов с целыми каталогами готовых шаблонов (реализующих дизайн) и много чего. Просто переноси это на клиента и всё. I>Это уже пройденный этап. Серверные шаблонизаторы убоги и ожидаемо слились. Собтсвенно именно это и послужило причиной популярности ангуляра и реакта.
Нууу ОК, так а можно мне хоть какое-то автоматическое решение на базе этой вот современной не убогой технологии? )
