Pull to refresh

Comments 23

Тип раб и господин — это так называемый тонкий клиент
Тип номер 3 — это так называемый толстый клиент
что за чушь?
все 3 типа относятся к тонким клиентам, поскольку не требует установки на компьютер.

толстые клиенты — всегда требуются установки себя на компьютер пользователя.
Если я не ошибаюсь, то тут разделение идёт не на основе необходимости установки на компьютер, а по принципу, где идёт обработка информации. В толстом вся логика реализована в клиенте, сервер по сути используется для хранения инфомармации. Если например вы пишите в форме «2+2» нажимаете кнопку "=", то подсчёт может осуществляться либо на клиенте, либо отправляться на сервер, откуда придёт результат. В первом случае это толстый клиент, во втором это тонкий. Я конечно понимаю, что примерчик малость убогий, но надеюсь суть отражает:)
Автор пытается рассмотреть эту концепцию с точки зрения браузерных приложений, когда как она едина для всех клиент-серверных приложений.
Выбор типа клиента для разработчика обуславливается многими факторами, такими как размер дистрибутива, задачи, которые отрабатывает приложение и т.д.
Единственную тенденцию, которую я могу выделить — это то, что развитие клиентских технологий, таких как Silverlight, дают возможность создавать толстые клиенте, когда от этого есть выигрыш, но опять таки тут всё зависит от задач, которые стоят перед приложением.
я прекрасно понимаю, что говорит автор. и я совершенно точно указал что мне не понравилось. =)
и Flex/Silverlight отнюдь не толстые клиенты.

Тонкие клиенты отличаются мобильностью, толстые ставятся на! один! компьютер. И характеризуются они не местом выполнения различных функций.
вся валидация на клиенте
— это опасно — на сервере надо дублировать.
автор просто показал 50% знания вопроса и 0% понимания вопроса.
никто в здравом уме не отменит валидацию на стороне сервера.
Вытелить типы веб-приложений и обозначить тенденции их развития. Я думал, что из моего топика это станет ясно.
Как оказалось все движется к 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.
эмммм…

а вы уверены что у Gmail всего 30% кода на сервере? С чего такие цифры?
А куда делась логика хранения, отправки, обработки, синхронизации Etc почты?
или это и есть те самые 30%?
именно.

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

вы имели ввиду серверный код, который непосредственно работает с UI.

Да?
Вы правильно меня поняли. Я учел только интерфейсы: клиент — клиентский браузер — сервер
Я не учел, отчнее забыл учесть, много факторов тот же кэш, вес самих серверных библиотек. Хотя если писать все самому с нуля не прибегая к увесистым серверным фрэймворкам и кэшированию, то ситуация думаю так и сложится.
Мне нужно было сравнивать объем кода клиентского кода по сравнению с «эталонным» объемом.

Без вопросов, что проект написанный на ZF будет всегда попадать под 1 категорию, если учитывать только объем кода, конечно если вы не будете писать 14 Мб клиентских скриптов :)

Я считаю, что все сайты останутся на 2 этапе (типе) из-за ограниченных возможностей по индексации javascript-генерируемого контента, хотя гугл вроде бы и это учел =)

А UGC индескировать не надо, не?
Я считаю, что все сайты останутся на 2 этапе (типе) из-за ограниченных возможностей по индексации javascript-генерируемого контента, хотя гугл вроде бы и это учел =)
На сколько я знаю, только гугл умеет это делать. Пока крупные поисковики не научатся на 3 этап мало контентных сайтов будет переходить.
Против фактов не поидешь. Наверняка разработки уже вовсю идут.
Значит переход на ступень номер 3 откладывается на неопределенное время (на 2,5 уже перешли).
Мне кажется что введение индексирования javascript генерируемого контента серъёзный шаг для поисковых систем, поскольку в их масштабах это сильное увиличение нагрузок на сервера, потому что нужно выполнять javascript код
Sign up to leave a comment.

Articles