Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 23
Тип раб и господин — это так называемый тонкий клиент
Тип номер 3 — это так называемый толстый клиент
Тип номер 3 — это так называемый толстый клиент
что за чушь?
все 3 типа относятся к тонким клиентам, поскольку не требует установки на компьютер.
толстые клиенты — всегда требуются установки себя на компьютер пользователя.
все 3 типа относятся к тонким клиентам, поскольку не требует установки на компьютер.
толстые клиенты — всегда требуются установки себя на компьютер пользователя.
Если я не ошибаюсь, то тут разделение идёт не на основе необходимости установки на компьютер, а по принципу, где идёт обработка информации. В толстом вся логика реализована в клиенте, сервер по сути используется для хранения инфомармации. Если например вы пишите в форме «2+2» нажимаете кнопку "=", то подсчёт может осуществляться либо на клиенте, либо отправляться на сервер, откуда придёт результат. В первом случае это толстый клиент, во втором это тонкий. Я конечно понимаю, что примерчик малость убогий, но надеюсь суть отражает:)
Автор пытается рассмотреть эту концепцию с точки зрения браузерных приложений, когда как она едина для всех клиент-серверных приложений.
Выбор типа клиента для разработчика обуславливается многими факторами, такими как размер дистрибутива, задачи, которые отрабатывает приложение и т.д.
Единственную тенденцию, которую я могу выделить — это то, что развитие клиентских технологий, таких как Silverlight, дают возможность создавать толстые клиенте, когда от этого есть выигрыш, но опять таки тут всё зависит от задач, которые стоят перед приложением.
Автор пытается рассмотреть эту концепцию с точки зрения браузерных приложений, когда как она едина для всех клиент-серверных приложений.
Выбор типа клиента для разработчика обуславливается многими факторами, такими как размер дистрибутива, задачи, которые отрабатывает приложение и т.д.
Единственную тенденцию, которую я могу выделить — это то, что развитие клиентских технологий, таких как Silverlight, дают возможность создавать толстые клиенте, когда от этого есть выигрыш, но опять таки тут всё зависит от задач, которые стоят перед приложением.
вся валидация на клиенте— это опасно — на сервере надо дублировать.
А каков смысл поста?
Вытелить типы веб-приложений и обозначить тенденции их развития. Я думал, что из моего топика это станет ясно.
Как оказалось все движется к GoogleGears приложениям.
Как оказалось все движется к GoogleGears приложениям.
может оно и движется в подобном направлении, но Вы к сожалению( а может и к счастью) — абсолютно не понимаете сам путь, через что и как и почему это так происходит. =)
Раз уж Вы начали, то поясните не понятливому почему же идет такое движение..? =)
тенденции отсутствуют как таковые. для тенденций необходим эффект толпы. тенденции — есть результат деятельности а не цель.
в данном случае политика развития тех или иных отраслей в вебе крупными компаниями расписана на ближайшие пару лет. а также продуманы общие концепции будущих систем.
и то что происходит касательного текущего разговора — это план, а не тенденции.
в данном случае политика развития тех или иных отраслей в вебе крупными компаниями расписана на ближайшие пару лет. а также продуманы общие концепции будущих систем.
и то что происходит касательного текущего разговора — это план, а не тенденции.
Проценты — это соотношение чего к чему? Например, как определить, что «клиент — 70%, сервер — 30%»? По скорости? Объемам памяти? В чем смысл подобных сравнений между клиентом и сервером?
Пост слабоват — посмотрите презентации: www.slideshare.net/Stephan.Schmidt/berlinjar-web-future-without-web-frameworks-presentation?type=powerpoint
Что касается самой идеи:
1 это не для всех сайтов — всяким блогам и корпоративным сайтом это не упёрлось, что очевидно.
2 перемещая логику в клиент на JS нам её приходится дублировать на сервере, пока что не делать этого могут себе позволить разве что Java-программисты(GWT). В остальном стоит ожидать роста server-side js или flex/silverlight.
Что касается самой идеи:
1 это не для всех сайтов — всяким блогам и корпоративным сайтом это не упёрлось, что очевидно.
2 перемещая логику в клиент на JS нам её приходится дублировать на сервере, пока что не делать этого могут себе позволить разве что Java-программисты(GWT). В остальном стоит ожидать роста server-side js или flex/silverlight.
эмммм…
а вы уверены что у Gmail всего 30% кода на сервере? С чего такие цифры?
А куда делась логика хранения, отправки, обработки, синхронизации Etc почты?
или это и есть те самые 30%?
а вы уверены что у Gmail всего 30% кода на сервере? С чего такие цифры?
А куда делась логика хранения, отправки, обработки, синхронизации Etc почты?
или это и есть те самые 30%?
именно.
сравнивать в процентах между собой кол-во кода серверного и клиентского — абсолютно лишено всякого смысла.
можно сравнивать только с теми же показателями на предыдущем этапе.
сравнивать в процентах между собой кол-во кода серверного и клиентского — абсолютно лишено всякого смысла.
можно сравнивать только с теми же показателями на предыдущем этапе.
Согласен, что насерврах с Гугла серверного кода гораздо больше, чем клиентского и правда я выбрал не удачное сравнение. Признаю.
я понял вашу мысль.
вы имели ввиду серверный код, который непосредственно работает с UI.
Да?
вы имели ввиду серверный код, который непосредственно работает с UI.
Да?
Вы правильно меня поняли. Я учел только интерфейсы: клиент — клиентский браузер — сервер
Я не учел, отчнее забыл учесть, много факторов тот же кэш, вес самих серверных библиотек. Хотя если писать все самому с нуля не прибегая к увесистым серверным фрэймворкам и кэшированию, то ситуация думаю так и сложится.
Мне нужно было сравнивать объем кода клиентского кода по сравнению с «эталонным» объемом.
Без вопросов, что проект написанный на ZF будет всегда попадать под 1 категорию, если учитывать только объем кода, конечно если вы не будете писать 14 Мб клиентских скриптов :)
Я не учел, отчнее забыл учесть, много факторов тот же кэш, вес самих серверных библиотек. Хотя если писать все самому с нуля не прибегая к увесистым серверным фрэймворкам и кэшированию, то ситуация думаю так и сложится.
Мне нужно было сравнивать объем кода клиентского кода по сравнению с «эталонным» объемом.
Без вопросов, что проект написанный на ZF будет всегда попадать под 1 категорию, если учитывать только объем кода, конечно если вы не будете писать 14 Мб клиентских скриптов :)
Я считаю, что все сайты останутся на 2 этапе (типе) из-за ограниченных возможностей по индексации javascript-генерируемого контента, хотя гугл вроде бы и это учел =)
А UGC индескировать не надо, не?
Я считаю, что все сайты останутся на 2 этапе (типе) из-за ограниченных возможностей по индексации javascript-генерируемого контента, хотя гугл вроде бы и это учел =)На сколько я знаю, только гугл умеет это делать. Пока крупные поисковики не научатся на 3 этап мало контентных сайтов будет переходить.
Серьезно? Или я вас неправильно понял, или они сами говорят, что Javascript content не индексируется
Мне кажется что введение индексирования javascript генерируемого контента серъёзный шаг для поисковых систем, поскольку в их масштабах это сильное увиличение нагрузок на сервера, потому что нужно выполнять javascript код
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Логики веб-приложений и развитие веба