Конечно. Продажи падают, акционеры уходят с акций этой компании, капитализация резко падает. и если крупные акционеры решат продать компанию (капитализация еще ведь может сильнее упасть) тогда они потеряют эти деньги. Вот в этом и заключается смысл таких больших потерь, также как и роста многомиллиардных состояний. Публичное размещение — IPO.
> то что было год назад и довольно сносно, можно посмотреть на сайте i-may.ru
> C чего вы взяли, что я решаю частную задачу? Когда я начинал делать
> в моих планах было тоже сделать библиотеку, которая бы могла
> перевести любой сайт на ajax. И это вполне себе получилось.
Посмотрел, там не фреймворк совершенно, а просто набор функций для работы с HTML request, кэшем и историей + еще намешана «работа» с DOM до кучи, на кашу похоже. Делается это за один вечер. До возможностей которые предоставляет fullajax и близко не дотягивает.
> Последние исходники я никому не даю
Не понятен смысл этой фразы так как JS код легко восстановить.
> И это вполне себе получилось. На радостях я начал переводить свои
> старые джумловские сайты на аякс и удивлялся как это легко и просто.
> Начал свой суббизнес «перевод сайтов на ajax», сделал сайт, выдвинул его в топ.
Так где можно посмотреть вашу расчудесную библиотеку, где этот сайт?
Зрелищнее. Машинки двигаются быстро (некоторые модели под 60 км в час двигаются), появляется соревновательная составляющая. Неважно чем управлять, важно чтобы был дух соревнования тогда будет интерес.
1. Любители РУ моделей и гонок (почти 100%)
2. Любители просто РУ моделей (какая то часть)
3. Любители гонок (какая то часть)
4. Те кто зарабатывают на тотализаторах
5. Простые болельщики (которые смогут стать участниками)
Плюсы:
1. Можно не просто посмотреть но и поучаствовать
2. Физические законы реального мира
3. Модели легко достать (или принимать самодельные разработки от сообщества).
4. Удаленное управление из любой точки мира
Минусы:
1. Амортизация (из-за того что нужно поддерживать в надлежащем состоянии модели и трассы)
2. Играть смогут фиксированное число людей, другие наблюдать (решить можно несколькими разными трассами, болшим числом машин)
3. Аккумуляторы тоже не вечны
Монетизация (при условии что стреляет):
1. Аренда моделей
2. Тотализаторы
3. Реклама на моделях и трассах
4. Еще что то
С машинами хорошо (да и прототип быстрее разработать, их купить в любом магазине можно не дорого) понятно куда развивать, в тоже русло что и гонки на больших машинах.
Идея была похожая управление радио управляемыми машинами (с камерами), разные раллийные трассы с тотализатором, и т.д. Все удаленно через сайт, но трассы настоящие, например в специально оборудованном ангаре, ну и трансляция с разных точек в онлайн.
Более серьезно это уже самолеты, вертолеты на радиоуправлении с камерами, но это уже затратнее т.к. их легко повредить. Хотя если за управление брать от 5-10% стоимости модели с каждого игрока то можно постепенно набрать суммы для амортизации.
да ладно вам про запросы. Точечные запросы как раз выгоднее делать (в целях снижения нагрузки тоже), а логику работы интерфейса на клиенте.
Если вы клепаете сайты для фирм с 5-10 статичными страницами и 2-3 формами для отправки сообщений, то конечно вам это все не нужно.
А по поводу производительности — все просто. Любой сайт чья логика полностью находится на сервере легче задосить (имеются ввиду сайты чья логика это не до 1000 строк кода, а от 1000), чем если сервер предлагает множество точечных серверных методов, которые оперируют небольшими порциями данных отдаваемых клиенту по требованию. Клиент получает данные и уже JS или Flash и т.д. отображает их (например, с помощью клиентского шаблонизатора) — такой подход позволит снизить потребление траффика, уменьшит нагрузки на сервер и позволит создавать более интерактивные веб-приложения. Не говоря уже о том что такой подход более четко отделяет представление данных от самих данных.
> АСИНХРОННУЮ ПОДГРУЗКУ КАРТИНОК ПО НЕКОТОРОМУ
> ДЕЙСТВИЮ ПОЛЬЗОВАТЕЛЯ БЕЗ ПЕРЕЗАГРУЗКИ ВСЕЙ СТРАНИЦЫ
Так картинки всегда грузятся асинхронно после какого то действия пользователя, получается любой сайт содержащий тег IMG использует технологию AJAX. С большой натяжкой загрузку картинок через тег IMG можно отнести к этой технологии.
Ну если бы вы сами читали о нем то знали бы плюсы (не я писал их кстати, это вам вики править надо :)
Экономия трафика
Использование AJAX позволяет значительно сократить трафик при работе с
веб-приложением благодаря тому, что часто вместо загрузки всей страницы достаточно загрузить только изменившуюся часть, иногда довольно небольшую.
Уменьшение нагрузки на сервер
AJAX позволяет несколько снизить нагрузку на сервер. К примеру, на странице работы с почтой, когда вы отмечаете прочитанные письма, серверу достаточно внести изменения в базу данных и отправить клиентскому скрипту сообщение об успешном выполнении операции без необходимости повторно создавать страницу и передавать её клиенту.
Ускорение реакции интерфейса
Поскольку нужно загрузить только изменившуюся часть, то пользователь видит результат своих действий быстрее.
> чем сложнее система — тем оне менее надежна
ну это тогда надо снова нам в палке копалке возвращаться в то время были примитивные системы
> Вот тот же самй Мапс, аякс там он просто необходим. Как бы вы сделали
> его другому? перезагрузка всей страницы производилась бы каждые 1
> секунду пока пользователь двигается по карте. Вот тут айакс и помог.
Это говорит о том что вы в теме веб разработки не разбираетесь или разработчик с небольшим стажем, но зато других учить можете. Так вот перемещение/изменение масштаба карты там нет никакого AJAX это чистой воды DHTML. Куда уж вам понять выгоды использовании загрузки данных через XHR по требованию. Изучите основы хотя бы.
У вас какой опыт разработки веб-приложений? Есть какие то исследования, наработки по своей инициативе, проекты более менее успешные в своей целевой аудитории? Просто воспринимать всерьез ваши комментарии никто не будет.
Человек сделал клиентскую библиотеку которой пользуются разработчики, им она интересна не только в практических целях, но и для самообразования (например, я для себя подчерпнул интересные решения из этой библиотеки и пользуюсь ими).
> Вы попросту непраилньо построили модель ресурса, а других причин удобства формирования > на стороне клиент я не вижу.
При XHR загружается не ВСЯ страница, а только нужные блоки, а еще лучше только данные. Неужели непонятно что быстрее загрузить только те элементы которые нужно отрендерить, чем на сервере заного создать весь код страницы и передать его на отрисовку браузеру.
А если глобальнее?
XHR это уменьшении времени отклика сайта, снижение траффика, снижение нагрузки на сервер и клиент, дата центры кушают меньше электричества, меньше теплового излучения в атмосферу, лучше экологическая обстановка мире, никто не стреляет в Ираке чтобы получить больше нефти, потому что N ому дата центру нужно много энергии, потому что миллионы Вась из Урюпинска не понимают преимущества XHR и все генерят на серверах. Используй XHR — сделай мир лучше.
Самый перспективный тренд — это выстраивание программной (веб-сервисы) платформы вокруг социальных сетей. И открытие API платформы для внешних разработчиков. Главное чтобы сама соц. сеть постепенно выродилась в такую платформу, и сама страница профиля просто стала следствием этой платформы (отдельным приложением).
Проекты такого плана как daas, paas это следующий виток в развитии Хостинга. По сути дата центры занимались низкоуровневым обслуживанием (железо), теперь наращивается высокоуровневое обслуживание (базы данных как сервис, платформы как сервис. Если бы это не имела смысла то сегодня не было бы этого: Microsoft Azure Platform, Google App Engine, Amazon WS, Zoho, Caspio, Salesforce, AppJet.
А расширение подобных проектов как FathomDB это горизонтальное масштабирование, когда есть отличный сервис и только увеличивается число серверов.
> C чего вы взяли, что я решаю частную задачу? Когда я начинал делать
> в моих планах было тоже сделать библиотеку, которая бы могла
> перевести любой сайт на ajax. И это вполне себе получилось.
Посмотрел, там не фреймворк совершенно, а просто набор функций для работы с HTML request, кэшем и историей + еще намешана «работа» с DOM до кучи, на кашу похоже. Делается это за один вечер. До возможностей которые предоставляет fullajax и близко не дотягивает.
> Последние исходники я никому не даю
Не понятен смысл этой фразы так как JS код легко восстановить.
> старые джумловские сайты на аякс и удивлялся как это легко и просто.
> Начал свой суббизнес «перевод сайтов на ajax», сделал сайт, выдвинул его в топ.
Так где можно посмотреть вашу расчудесную библиотеку, где этот сайт?
1. Любители РУ моделей и гонок (почти 100%)
2. Любители просто РУ моделей (какая то часть)
3. Любители гонок (какая то часть)
4. Те кто зарабатывают на тотализаторах
5. Простые болельщики (которые смогут стать участниками)
Плюсы:
1. Можно не просто посмотреть но и поучаствовать
2. Физические законы реального мира
3. Модели легко достать (или принимать самодельные разработки от сообщества).
4. Удаленное управление из любой точки мира
Минусы:
1. Амортизация (из-за того что нужно поддерживать в надлежащем состоянии модели и трассы)
2. Играть смогут фиксированное число людей, другие наблюдать (решить можно несколькими разными трассами, болшим числом машин)
3. Аккумуляторы тоже не вечны
Монетизация (при условии что стреляет):
1. Аренда моделей
2. Тотализаторы
3. Реклама на моделях и трассах
4. Еще что то
Более серьезно это уже самолеты, вертолеты на радиоуправлении с камерами, но это уже затратнее т.к. их легко повредить. Хотя если за управление брать от 5-10% стоимости модели с каждого игрока то можно постепенно набрать суммы для амортизации.
Если вы клепаете сайты для фирм с 5-10 статичными страницами и 2-3 формами для отправки сообщений, то конечно вам это все не нужно.
А по поводу производительности — все просто. Любой сайт чья логика полностью находится на сервере легче задосить (имеются ввиду сайты чья логика это не до 1000 строк кода, а от 1000), чем если сервер предлагает множество точечных серверных методов, которые оперируют небольшими порциями данных отдаваемых клиенту по требованию. Клиент получает данные и уже JS или Flash и т.д. отображает их (например, с помощью клиентского шаблонизатора) — такой подход позволит снизить потребление траффика, уменьшит нагрузки на сервер и позволит создавать более интерактивные веб-приложения. Не говоря уже о том что такой подход более четко отделяет представление данных от самих данных.
> ДЕЙСТВИЮ ПОЛЬЗОВАТЕЛЯ БЕЗ ПЕРЕЗАГРУЗКИ ВСЕЙ СТРАНИЦЫ
Так картинки всегда грузятся асинхронно после какого то действия пользователя, получается любой сайт содержащий тег IMG использует технологию AJAX. С большой натяжкой загрузку картинок через тег IMG можно отнести к этой технологии.
Ну если бы вы сами читали о нем то знали бы плюсы (не я писал их кстати, это вам вики править надо :)
Экономия трафика
Использование AJAX позволяет значительно сократить трафик при работе с
веб-приложением благодаря тому, что часто вместо загрузки всей страницы достаточно загрузить только изменившуюся часть, иногда довольно небольшую.
Уменьшение нагрузки на сервер
AJAX позволяет несколько снизить нагрузку на сервер. К примеру, на странице работы с почтой, когда вы отмечаете прочитанные письма, серверу достаточно внести изменения в базу данных и отправить клиентскому скрипту сообщение об успешном выполнении операции без необходимости повторно создавать страницу и передавать её клиенту.
Ускорение реакции интерфейса
Поскольку нужно загрузить только изменившуюся часть, то пользователь видит результат своих действий быстрее.
P.S. мне WireShark хватает
ну это тогда надо снова нам в палке копалке возвращаться в то время были примитивные системы
> Вот тот же самй Мапс, аякс там он просто необходим. Как бы вы сделали
> его другому? перезагрузка всей страницы производилась бы каждые 1
> секунду пока пользователь двигается по карте. Вот тут айакс и помог.
Это говорит о том что вы в теме веб разработки не разбираетесь или разработчик с небольшим стажем, но зато других учить можете. Так вот перемещение/изменение масштаба карты там нет никакого AJAX это чистой воды DHTML. Куда уж вам понять выгоды использовании загрузки данных через XHR по требованию. Изучите основы хотя бы.
У вас какой опыт разработки веб-приложений? Есть какие то исследования, наработки по своей инициативе, проекты более менее успешные в своей целевой аудитории? Просто воспринимать всерьез ваши комментарии никто не будет.
Человек сделал клиентскую библиотеку которой пользуются разработчики, им она интересна не только в практических целях, но и для самообразования (например, я для себя подчерпнул интересные решения из этой библиотеки и пользуюсь ими).
> Вы попросту непраилньо построили модель ресурса, а других причин удобства формирования > на стороне клиент я не вижу.
Вот яркий пример где формирование идет на клиенте: www.google.com/finance
Zoho.com — формирование интерфейса НА кленте
Zimbra.com — просто рассадник AJAX — все на клиенте
Google продукты:
GoogleMaps — формирование идет на клиенте
Google Docs, Spreadsheet — на КЛИЕНТЕ
iGoogle (Gadget API в основе) — на… к л и е н т е
> у которых там кучу джаваскрипта
Перечислять можно на самом деле долго. И все эти продукты используют миллионы людей.
Ну а Вы чем полезны?
www.google.com/finance
А если глобальнее?
XHR это уменьшении времени отклика сайта, снижение траффика, снижение нагрузки на сервер и клиент, дата центры кушают меньше электричества, меньше теплового излучения в атмосферу, лучше экологическая обстановка мире, никто не стреляет в Ираке чтобы получить больше нефти, потому что N ому дата центру нужно много энергии, потому что миллионы Вась из Урюпинска не понимают преимущества XHR и все генерят на серверах. Используй XHR — сделай мир лучше.
А ниже пример на Javascript, хотя можно на любом языке работать с сервисом.
hivext.ru/index.php/Javascript.Объекты
А расширение подобных проектов как FathomDB это горизонтальное масштабирование, когда есть отличный сервис и только увеличивается число серверов.