Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 13
Конкретно у меня первая загрузка 3МБ
Так и хочется воскликнуть: НИ ХРЕНА СЕБЕ!
Поясню: я конечно понимаю, что сейчас вроде как везде широкополосный интернет, но давайте вспомним про мобильный интернет в России…
Ну, у нас не сайт, а рабочее место, реализованное в виде «тонкого клиента». Т.е., это не главная страничка портала, а полнофункциональное приложение с большим количеством функций. 3-мегабайтовый скрипт, сгенерированный GWT, грузится один раз после очередного обновления промышленного сервера (обычно, не чаще одного раза в месяц) и кешируется браузером. 3МБ раз в месяц — совсем немного, а дальше ходят только чистые данные. Так что мобильный интернет — не наша специфика.
Про Code Splitting вы не слышали?
Спасибо, слышал. Но не вижу никакого смысла его применения конкретно в нашем проекте. Еще раз повторю — пользователю загружается 3МБ JavaScript раз в месяц, это немного даже для возможностей сетей десятилетней давности. Специально спросил сейчас у специалиста поддержки, он сказал что пользователи не жалуются на то, что после обновления первый вход в систему длится дольше. А заниматься преждевременной оптимизацией — плохая практика.
про jsf о какой версии такие ваши впечатления?
по мне так вобще отличная штука начиная с версии 2, читабельность, разбивка на шаблоны, навигация, доступ к бинам и тд…
можно любой html шаблон разрезать и натянуть какими нужно кусками, аякс, частичный рендеринг…
только скорости под нагрузками можно добавить это да
по мне так вобще отличная штука начиная с версии 2, читабельность, разбивка на шаблоны, навигация, доступ к бинам и тд…
можно любой html шаблон разрезать и натянуть какими нужно кусками, аякс, частичный рендеринг…
только скорости под нагрузками можно добавить это да
О спецификации версии 1.2. Я слышал о том, что в версии 2 многое стало лучше, но вещь это достаточно свежая и сталкиваться на практике не приходилось. Если попаду на новый проект с тонким клиентом, обязательно рассмотрю JSF 2 как вариант реализации клиентской части.
PS Насчет "любой html шаблон разрезать и натянуть какими нужно кусками, аякс, частичный рендеринг" — это у нас и в 1.2 работало, реализация RichFaces.
PS Насчет "любой html шаблон разрезать и натянуть какими нужно кусками, аякс, частичный рендеринг" — это у нас и в 1.2 работало, реализация RichFaces.
Не очень понятен смысл написания собственных инструментов для тестирования. Тот же JMeter, настроенный как прокси, может записать все запросы из браузера. Всего делов-то: выкинуть ненужное, залупить (от loop) этот запрос, настроить сохранение ошибок, да задать правила построения уродских графиков.
Поддерживаю, но лишь отчасти. На самом деле разработанный модуль тестирования немного сложнее, чем я написал (т.к. статья была не об этом). Модуль осуществляет логин пользователей, подгруженных из базы либо текстового файла, и последующую передачу запросов с персональным куки (JSESSIONID) для каждого пользователя. При этом, вытащенные из FireBug запросы отправляются не в исходном виде, а с подменой некоторых частей персонально для каждого робо-пользователя (специфика бизнес-логики).
Возможно, есть готовые инструменты, которые могут все это осуществить, но я разработчик, а не специалист по автоматизированному тестированию, и, к сожалению, не разбираюсь в них.
Возможно, есть готовые инструменты, которые могут все это осуществить, но я разработчик, а не специалист по автоматизированному тестированию, и, к сожалению, не разбираюсь в них.
Я тоже разработчик, но очень рад что наткнулся на JMeter. Разумеется, там также можно сделать X потоков с разными JSESSIONID.
Кроме того, можно например инкрементить некий счётчик, и использовать его в переменных (например, если надо залогинить юзеров user1..user100 с паролем user). Но вот если данные совсем непредсказуемые, то да — с этим хуже.
Самые крутые JMeter'овцы QA-шники вроде бы умеют парсить ответ веб-сервера регэкспом и заносить совпадения в переменные, это я не умею.
Кроме того, можно например инкрементить некий счётчик, и использовать его в переменных (например, если надо залогинить юзеров user1..user100 с паролем user). Но вот если данные совсем непредсказуемые, то да — с этим хуже.
Самые крутые JMeter'овцы QA-шники вроде бы умеют парсить ответ веб-сервера регэкспом и заносить совпадения в переменные, это я не умею.
А ведь данных на странице обычно гораздо больше: заголовки, меню, различные блоки и т.д. Фактически, достаточно насыщенная данными и функционалом страница обычно весит не менее 100-200 кБ. GWT же для отображения такой же страницы заберет с сервера 1 кБ данных и всё.
На дворе 2006 год? И к тому же, давайте сравнивать котлеты с котлетами (тонкие клиенты или SPA), а не с олдскульной полной загрузкой HTML на каждый чих): XHR был ещё в IE5 в 1999 году; 2006 год — во всех популярных на тот момент браузерах.
Хотя я понимаю, почему вы используете GWT — веб-приложением занимаются явисты. Переход на стэк HTML5 — это новый отдел фронтендеров и соответственно другой бюджет отдела разработки. Возможно текущие задачи GWT решает (хоть и не лучшим способом). Но вы должны понимать, что вы отстаёте и чем дольше будете сидеть на нём, тем сложнее будет переход на современный стэк создания SPA, а это быстрая и комфортная работа с любого девайса, где есть браузер.
Если есть желание уже начать переходить, попробуйте начать писать клиент на Angular.js + HTML5 (на ангуляре пишутся большие корпоративные SPA — десятки тысяч SLOC).
Ну во-первых, краткое упоминание пары технологий в статье ни в коем случае не преследовали целью полноценного сравнения. Я сразу открестился от этого, написав, что это "чтобы немного “окунуться” в рассматриваемую тему".
Во-вторых, технологий и фреймворков много, и, по большому счету, все они «в среднем по больнице» схожи в удобстве работы и возможностях. Не вижу никакого смысла менять шило на мыло.
В-третьих, я абсолютно не согласен с Вашим мнением по поводу того, как плохо GWT решает мои задачи, хотя бы потому, что Вы не знаете, что это за задачи, и потому, что никак не аргументировали свое мнение. Лично мне кажется, что все работает отлично, и пользователи не жалуются.
В-четвертых, «чтобы купить что-то хорошее, надо сначала продать что-то хорошее». Какие бы экономные технологии вы бы не использовали, вы не сможете выполнить сколь-нибудь сложную логику на клиенте, не заставив его перед этим что-то загрузить. У меня пользователь целый день сидит на своем рабочем месте и переходит по страницам. Как бы вы не экономили на частичном обновлении страниц, за день в любом случае набежит не один мегабайт метаданных, описывающих интерфейс.
Во-вторых, технологий и фреймворков много, и, по большому счету, все они «в среднем по больнице» схожи в удобстве работы и возможностях. Не вижу никакого смысла менять шило на мыло.
В-третьих, я абсолютно не согласен с Вашим мнением по поводу того, как плохо GWT решает мои задачи, хотя бы потому, что Вы не знаете, что это за задачи, и потому, что никак не аргументировали свое мнение. Лично мне кажется, что все работает отлично, и пользователи не жалуются.
В-четвертых, «чтобы купить что-то хорошее, надо сначала продать что-то хорошее». Какие бы экономные технологии вы бы не использовали, вы не сможете выполнить сколь-нибудь сложную логику на клиенте, не заставив его перед этим что-то загрузить. У меня пользователь целый день сидит на своем рабочем месте и переходит по страницам. Как бы вы не экономили на частичном обновлении страниц, за день в любом случае набежит не один мегабайт метаданных, описывающих интерфейс.
Вы посвятили второй абзац сравнению GWT + AJAX со способом получения готовых страниц (или кусков html-кода), полностью генерируемых на сервере, который (в контексте SPA) использовался со времён веб 1.0, в то время как AJAX, JSON, client-side templating, routing уже давно доступны + сегодняшний стэк HTML5. Не было бы этого некорректного сравнения — не было бы и моего комментария.
Во-вторых, я не писал «плохо решает». GWT пока всех полностью устраивает? — вот и отлично. Возможно скоро поменяются бизнес-процессы и люди захотят работать мобильно, с помощью планшетов или мобильных, а там свои нюансы и, я думаю, вы не станете отрицать, что стэк HTML5 там куда как актуальнее. Вот тогда и начнётся работа по оптимизации.
Во-вторых, я не писал «плохо решает». GWT пока всех полностью устраивает? — вот и отлично. Возможно скоро поменяются бизнес-процессы и люди захотят работать мобильно, с помощью планшетов или мобильных, а там свои нюансы и, я думаю, вы не станете отрицать, что стэк HTML5 там куда как актуальнее. Вот тогда и начнётся работа по оптимизации.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
GWT – подглядываем в передаваемые данные