Здравствуйте, tumblerrr, Вы писали:

M>>Визуально тормозит. Вот я вижу и мне неприятно. А на javascript не тормозит.
T>У нас клиенты, на планшетах через GPRS работают, и их все устраивает. Я этих тормозов не замечаю, более 500 клиентов использующих ваадин, тоже.

А планшет — другой сценарий . Я вот на клавиатуре набираю вслепую и достаточно быстро. Соответственно, я все время вижу монитор и реакции адаптировались под быструю обратную связь. Поэтому "фильтрация по списку" выглядит так: "ставим фокус на поле ввода, набираем символ, набираем символ, набираем символ, набираем символ, ждем, отфильтровалось!". Эту паузу между "я перестал набирать" и "пришли результаты" я прекрасно ощущаю. На планшетах скорость ввода ниже, экран закрывается частично виртуальной клавиатурой да и сам планшет в среднем работает медленнее, чем PC.

T>В общем я вас понял.
T>Вам нужна клиентская технология, вы пишете ее в JS. Попробовали серверный vaadin, и написали как все там плохо.
Мне нужна не клиентская технология. Технологию я как раз могу выбирать под необходимую платформу. Вот в данном случае платформа — приложения, работающие в браузере. Есть ряд физических ограничений, вызванных платформой (асинхронность обмена, возможность задержек, ошибок, разных настроек клиентских приложений (разные шрифты, размеры экрана, зум)). Соответственно, у меня ряд требований к приложению на этой платформе. В основном — возможность корректно работать с нужными ограничениями (ошибками связи, задержками и т.п.). Часть моих претензий к ваадину состоит в том, что он плохо учитывает особенности платформы. И эта причина — первая, по которой я бы его не взял. Вторая — архитектурная. Frameworks — зло, я достаточно легко и быстро нахожу задачи, которые из них выбиваются, а мне нужны. Был бы ваадин распилен на полтора-два десятка библиотек, у него еще какие-то шансы могли бы быть.

Если бы при своих подходах он работал хорошо, он имел бы смысл. Хотя "серверные технологии" вообще по определению плохо работают в веб. Может быть, их можно придумать и довести до нормального состояния, но никому это не нужно.

T>Только один вопрос, вы в курсе, что разные технологии для разного предназначены и имеют разный порог вхождения?
Угу. Но я не уверен, что порог вхождения в vaadin будет ниже, чем аналогичный порог вхождения в javascript + ajax. В html'е не такое и большое API. В UI-библиотечках стандартных — тоже не слишком большое и обычно хорошо разделено на рзаличные модули. В качестве языка можно какой-нибудь tscript взять типизированный. А еще ваадин периодически вызывает дикое удивление (property.setReadOnly, таблицы), что с низким порогом вхождения плохо увязывается.

T>Может все таки попробуете гвозди забивать, шурупы закручивать, а не наоборот?
Пробовал. Ваадин позволяет гвозди только под прямым углом забивать. А мне часто нужно под небольшим наклоном У меня много различных соединений и далеко не все квадратное.

T>Если вам так нужен клиентский код, да ради бога, пишите в своем JS.
Мне без разницы до тех пор, пока учитываются особенности платформы.

T>Говорить, что трактор проблемный транспорт, я на нем по трассе смог разогнаться до 200км/ч это как странно.
Ну если у трактора заявляется, что он предназначен для езды по трассам... А для ниши "простенькие админки" у меня тоже аналоги есть. Там могут банальные странички без ajax вообще быть.

T>Для вас написать компонент для vaadin, это просто неподъемная задача и проще написать свой vaadin на JS с шахматами и поэтессами.
Ну да. Только там не ваадин. У моих компонентов почему-то все гораздо проще и по API, и по взаимодействию. Им не нужно реализовывать методы для всего подряд, включая layout, обмен состояниями и т.п. Но главное даже не это. В отличие от ваадина, у меня гора cut-points, по которым я могу заменять одни компоненты на другие. Могу заменить сетевой транспорт (добавить повторы, ручной load balancing и прочее). Могут реализацию некоторых компонентов заменить. И т.п. А в ваадине это все гвоздями прибито с двух сторон. Ну да, мне приходится на новый проект вытаскивать пачку библиотек и допиливать шаблонный конфиг до нужного проекта. Небольшая плата за гибкость.

T>Отладить его под все браузеры, написать все компоненты и т.д. Это ваш выбор.
А в случае ваадиновского компонента разве не так? Его не нужно отлаживать под все браузеры? А еще ваадин дает дополнительные ограничения (нужно уложиться в его протокол, а протокол только через setAttribute и я не могу передать произвольную фигню). А еще нельзя повторно использовать части его клиентских компонентов. Нет уж, лучше я ограничу набор поддерживаемых браузеров (внутренний продукт же!) и отлажусь под них.

T>Если продолжать аналогии, то да, я конечно понимаю, что купить земли во франции, посадить там религиозно верный виноград и получить в итоге свое самое крутое на свете вино, это тоже подход, и он дает на выходе именно то, что хотели. Но вот большинству достаточно придти в ресторан и выпить хорошего, качественного вина.
Да нет, меня хорошее вино устраивает. Но планка достаточно высокая, конечно. На улице и в ларьках такого не продают. И даже на "техническое" вино (добавляется в процессе готовки) далеко не все пойдет.

T>Писать на JS+еще куча технологий, энтерпайзные проекты, это просто ад. В котором мы варились не один год. Плавали, знаем, спасибо не надо. Куча разных технологий и подходов, толпа даромоедов, очень долгий процесс отладки всего этого барахла.
Угу. Было отсутствие архитекторов и политической воли рулить зоопраком технологий. Пришел vendor lock-in и жуткая негибкость, которая и поборола этот зоопарк. Вероятно, теперь у вас одна технология не потому, что ваадин крут и решает все проблемы. А только потому, что ничего другого прикрутить уже не получается Хотя да, какое-никакое, а решение.

T>После перехода на ваадин, я прототип текущей системы сделал за несколько дней. И это "с нуля", т.е. ваадин первый раз открыл.
T>После него всякие ExtJS и иже с ним, вспоминаем как страшный сон.
А кто такое ExtJS? Что-то большое и компонентное? Не взлетит подобное в web. Вот не взлетит и все. Нужно что-то гораздо более легковесное. Layouts можно взять в общем виде из GWT и т.п. и перенести их в API (создавать будут DIV'ы). А вот для компонентов ничего глобального не нужно. Тот же button от div'а не сильно отличается — дополнительным обработчиком, обычно.

T>Да, для публичных массовых сайтов vaadin мало подходит, это да. Но для своей ниши он просто шикарен и закрывает 99% потребностей.
А ниша какая? И почему они о ней на своей главной странице не пишут. Вот сейчас вижу: "Vaadin is a Java framework for building modern web applications that look great, perform well and make you and you users happy." По выделенным пунктам он у меня не прошел. Кстати, это все ручками набирать пришлось. Копирование он почему-то не поддерживает. И не понятно, с чем конкурировать. JSP/JSF тот же его конкуренты или нет? Только не говорите про сервер/клиент сайд. Нужно говорить про приложения в браузере.