Ну, теоретически есть даж всякие Google Native Client.. Но реально я это не щупал.

Всё придумано до нас.

??????????
Ты реально так думаешь, что все идет так последовательно?
У меня Опера показывает начало страницы, когда окончание страницы еще не загрузилось.

Мне захотелось прояснить вопрос о тормознутости флеша, в чем это выражается?
И второй вопрос, что думаешь насчет WebGL?

Непременно  Предлагаю STCP.


Согласен, что по отдельности вещи хороши. Проблема в том, что их пытаются объединить.


Да, тоже вполне себе! Однако это опять-таки соединение XML + JS - немногим лучше, чем HTML + JS.


Если концепция "сайты как программы" выгорит, то разделение по MVC станет вполне возможным - чуть выше я приводил пример, когда клиент работает с классом, реализующим доступ к БД.


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


В какой-то очень далекой степени...  Если не ошибаюсь, идеология Гугля предполагает т.н. "облачность", сиречь размещение данных, программ и т.д. на удаленном сервере. Мне лично такой подход категорически не нравится и я им не пользуюсь ни в чем и нигде. Однако народу, возможно, понравится.


Так же, как это реализовано в виртуальных машинах. В том же VirtualBox в полный рост есть поддержка 3D-графики. А в qemu так и вообще - проброс железа хоста внутрь гостевой системы. Сохранение файлов можно реализовать специально выделенной, единой для всех страниц виртуальной ФС, откуда их легко будет выгрести.


Главное - в том, что для корректного отображения всей страницы браузер должен скачать ее целиком. Я отвечал на именно такой вопрос, а не разъяснял особенности внутреннего устройства механизма загрузки страниц - ясное дело, что любой нормальный браузер огранизует многопоточную загрузку и пытается как можно быстрее распарсить и отобразить скачанные кусочки. Однако "чуть-чуть - не считается!", как говаривал старина Хоттабыч (не путать с созвучным мастдайным трэш-фильмом!).


В загрузке процессора на 100% и жутких тормозах анимации. Хотя, конечно, Atom 230 (1,6 ГГц) - это даже не смешно, куда мне смотреть Flash с таким старьем!


Идея интересная, но если верить Вике:


то WebGL - не более чем еще один костыль для многострадального HTML.

Мне просто непонятно, почему современные "классические" АПИ (JS апи, базирующиися на DOM и пр.) тебе не угодили. HTML всегда был лучшим (за отсутствием серьёзных альтернатив) языком разметки контента. CSS - один из лучших языков (да, многого не хватает, но лучшии решения существуют, на мой взгляд, лишь как обёртки над цсс) для "оформления". JS - вполне себе хороший/удобный язык. HTML5-ные АПИ нацелены именно на то, чтоб предоставить более продвинутый АПИ для приложений...

Я, конечно, не берусь навязывать своё мнение, но при всей массе минусов, этот набор технологий очень хорош.

Это все вопрос желания "сообщества" делать свою реализацию. Если бы тот же Гугл сделал свою отрытую реализацию .NET (или стал активно поддерживать Mono) и замутил совой Silverlight, то .NET мог бы стать стандартом для WEB.




Формально - это не обязательно. Но смысла использовать WEB приложение и не использовать облачные сервисы - немного.




Жесть, вместо простого браузера ты предлагаешь замутить целую виртуальную машину. А как эта вся фигня будет чувствовать себя на смартфонах где Java тормозит?

Тем, что их слишком много и они плохо состыкованы. Каша в технологиях порождает кашу в головах.


Если верить Вике, стандарты на С# появились 5 лет назад. В то же время запустили проект OpenJDK. Спрашивается: почему за прошедшие 5 лет OpenJDK стала вполне юзабельной, а вариации C# так и остались на уровне, слабо отличимом от "Hello, World!"? Где разработанные по стандартам решения для мобильных платформ? Не иначе это заговор? Нехороший дядя RMS всех запугал?


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


Тогда может быть все же "сайты как программы"? Раз среднему сферическому юзверю в вакууме нужны "облака", пусть радуется с комфортом?


Полагаю, что без проблем - предполагаемые "песочницы" будут достаточно легковесными, т.к. их функционал будет ограничен.

Хорошо, я понял. Спорить не буду особо (мы же ещё не в холиварах?), но моё мнение, что это как раз хорошее разделение обязаностей и хороший стек технологий. Исторические проблемы есть (а как же без них?), но впечатление в целом - очень даже положительное.


Ну, если брать современные мобильные платформы, то из настоящих (поддерживаемых не только энтузиастами) универсальных решений - как раз только вебовые клауд приложения (хотя тут как раз есть проблема с ИЕ, но всё ж).


А зачем? Если речь про дотнет и веб, то МС были б (в своё время) просто нереально рады, если б сильверлайт получил действительно распространение (в сфере "обычных" веб приложений). Этого не случилось и сейчас они пытаются доказать (смотрим все статьи по ие9), что "мы хотим продвигать HTML5 и пр". И, даже более того, если взять прошлые версии ие и 9-ку, то отрыв в пользу "классических решений" действительно очень большой.


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

Можно немного поподробнее раскрыть тему? Скажем, на примере формы отправки комментария в блог. Как тебе представляется вся цепочка действий? Я себе представляю примерно такую карусель:

• код на JS обработчика действия "onclick" кнопки проверяет совпадение контрольного кода (capcha);
• в случае совпадения проводится переадресация на некоторый URL, допустим "server/comment.php?is_code_valid=true";
• браузер выполняет переход на этот URL;
• http-сервер прогоняет скрипт comment.php через интерпретатор PHP;
• код на PHP запрашивает значения переменных $_GET и $_POST (могу ошибаться в названии, PHP юзал очень давно);
• код на PHP получает значение GET-переменной "is_code_valid=true" и принимает решение добавить комментарий в БД на MySQL;
• код на PHP подключается к БД, авторизуется, берет значение POST-переменной "comment_text", содержащей текст комментария, добавляет в БД новую запись и закрывает соединение с БД;
• код на PHP непосредственно генерирует или берет из шаблона HTML-код текста "Ваш комментарий успешно добавлен";
• http-сервер отправляет браузеру HTML, сгенерированный кодом на PHP;
• браузер парсит HTML, накладывает на него CSS и отображает;

А теперь представим, что было бы, используй мы некий язык Х и фреймворк:

• код на Х обработчика действия "onlick" кнопки проверяет совпадение контрольного кода (capcha);
• в случае совпадения, код на Х выполняет следующие действия:
• устанавливает соединение с БД, авторизуется, добавляет в БД новую запись с текстом комментария, взятым из виджета, и закрывает соединение с БД;
• выводит в виджет текст "Ваш комментарий успешно добавлен";

Какой вариант быстрее, проще, прозрачнее и технологичнее?

ИМХО, ситуация как со средствами RAD, которые часто (и заслуженно!) обвиняют в том, что они отучают думать. Т.н. "программист" тупо раскидывает кнопочки по форме, не представляя даже приблизительно, какая прорва кода за всем этим стоит и как это работает хотя бы в первом понимании! Здесь все аналогично. Что делает средний "программист" на PHP в вакууме? Берет какой-нибудь там Symfony, берет RAD типа Aptana Studio и ваяет "Страницу Крутого Вована, главного кореша Крутого Коляна". И, как ни странно, все работает! Я ни в коем разе не осуждаю подобных "программистов" и уж тем более тех, кто зарабатывает на жизнь Web-разработкой, в т.ч. реально толковых PHP'шников! Я лишь хочу подчеркнуть, что бОльшая часть людей даже приблизительно не представляет, какой чудовищный бардак из костылей и подпорок творится "под капотом" тех фреймворков, RAD и прочих средств, которые они используют. Такое вот скверное положение дел и подтолкнуло меня к созданию этой темы.


Это временные меры в безвыходной ситуации. Как только отойдет немного от хвоста, так сразу - обратно на коня и снова шашкой махать. Но Web - однозначно не то, что можно отдать в чьи-то единственные руки и позволить сделать на основе проприетарщины.

если у Вас не жополизный менталитет, то самое главное:
1) чтобы это работало
2) чтобы приносило деньги

г*вно будет и так, и так  © 
 
===

• для Captcha, есть reCaptcha от google
• отправлять на сервер данные можно в json вместе с объектами которые будут использоваться на сервере, парсер json быстро десериализирует и не будет тратить ресурсов на инициализацию объектов и структур на сервере
• отправить обратно на клиент ответ в json (0.0008s)
• соединение можно держать открытым... (максимум 1 соединение)

ЗЫ: если бы это делать для: нового ЯП (допустим), больших нагрузок или как аналог Skype... - то можно понять

Это сообщение отредактировал(а) gcc - 19.1.2011, 03:27

Вот, значит, как теперь называют стремление писать надежный качественный софт?


Т.е., используя JS, можно передать произвольные данные в код на PHP, не перезагружая страницу - я правильно понимаю?

А фреймворк стоит на клиенте. И ему позволенно


Ну вот видишь, ты ни хрена ничего не знаешь.
Но тебе хочется быть гением ...

Что-то я не припомню, чтобы хоть один сайт требовал с меня (клиента) установки фреймворка.


А я где-то называл себя гуру Web-разработки? Это вообще не моя область в IT. Из Web-проектов когда-то очень давно делал только примитивный магазин-галерею и учетную систему диспетчерской службы автопредприятия. Я - обыватель Web'а, каких большинство, и не скрываю этого. Что не мешает мне видеть недостатки существующей организации с позиции юзверя в вакууме. Конструктивной критики в теме очень мало, это в основном попытки отстоять позиции в силу привычности действующего уклада. Почему-то никто до сих пор так и не смог (не взял за труд?) обосновать, что Web - это не свалка костылей и подпорок, а стройная, органичная система костылей и подпорок.


Скорее революционером 

You Asked

and we said...
Все гораздо проще. Кому из OS мира есть дело до полностью проприетарной платформы (WM), чтобы стараться и писать под нее свободный порт фреймворка, который и так уже существует?




You Asked

and we said...

Так что значительный прогресс OpenJDK это заслуга Sun которая открыла исходники JDK. А если интересно посмотреть на разработку с нуля, то это к Apache Harmony и GNU Classpath.





Не мешает, потому что нет реальной конкуренции. Взять те же стандарты, один браузер от одного производителя, занимал лидирующие позиции на рынке браузеров плевал на стандарты и на выпуск новые версии. Но стоило появится реальным конкурентам, которые начали теснить его с рынка, как сразу стали экстренно клепаться новые версии и результаты прохождения всяких тестов стали тоже улучшаться. А все почему - конкуренция. Если бы Mono заняло хотя бы процентов 30% рынка, "оффтопик" бы уже не стал бы так смело вносить изменения в "пончик".





Проблема не в том, что твоя концепция плохая, а в том, что есть проблемы с реализацией.




Сильно сомневаюсь, что реализация такой песочницы будет тривиальной. Одно дело контролировать код который написан на неком p-code и взаимодействует с внешним миром через некое API, а другое дело контролировать native код, который напрямую использует API системы.

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

И ещё момент - не надо думать о том, что произойдёт на сервере. Мы постим форму на клиенте и всё. Что физически делать серверная часть - это его дело. Не надо делать свалку, должно быть разделение ролей.