Comments 51
Интересно, надо будет потрогать. Хотя, если честно, мне больше нравится когда мухи и котлеты отдельно, т.е. XML/XHTML для описания интерфейса, и Java для кода.
Классный фреймфорк, сам на нем начинал писать проекты, но, как правило, потом переписывал фронтенд на HTML+JS, упершись в реализацию. Без знания GWT иногда бывает ооой как сложно, дефолтных компонентов маловато. Просто хочу предостеречь этим комментом от моих ошибок.
почему ж он тогда такой классный, что вы в некоторый момент переписывали UI без его использования?
Потому что, как я написал, упирался в реализацию. Не хватало стандартных компонентов, а что бы написать компонент по Vaadin, нужны знания GWT, коих нет. Вот и переписывал.
Ну и плюс, здесь уже писали, он медлителен. Вся логика хранится и исполняется на сервере, с клиентом синхронизируется лишь представление. Это значит, что после каждого клика идет запрос к серверу и ожидание ответа. Еще очень медленным является рендеринг компонентов, если это какая-то комплексная страница, и на ней куча Layout'ов.
То есть, делать на нем весь фронтенд — ни разу не замечательно, как поступал я.
То есть, делать на нем весь фронтенд — ни разу не замечательно, как поступал я.
Посмотрите все-таки более детально GWT, знание никогда не лишнее
Все собираюсь, да никак. А тогда нужно было реализовать компонент Google Maps для Vaadin, функционала того, который у них в Directory, не хватало. И, полазив по интернетам, я понял, что лучше переписать UI теперь уже без Vaadin'а, чем вникать во все эти синхронизации состояний и callback'и. Кстати, тогда проект переехал на Java-фреймворк Play.
Мы используем GWT Maps для внедрения gmaps-виджетов. К сожалению, эта библиотека поддерживает GMaps API v2. Нам пока хватает. Имея некоторую сноровку с GWT JSNI можно реализовать свой облегченный GWT виджет, который будет «оборачивать» только нужный вам в проекте функционал
Машинно-генерируемый клиентский код (HTML + JS) наверняка будет хуже кода, написанного тысячей индийских мартышек (сплошь с сертификатами MS, Zend, ..., ага) в полнолуние в тёмной-тёмной высокогорной пещере.
GWT не генерирует код. GWT настоящий компилятор, который занимается оптимизацией кода:
В том числе отбрасывает написанный на Java код но не используемый ни в одном вызове. Плюс к этому тулкит компилирует отдельный скрипт для каждого бразуера, когда большинство рукописных скриптов использует конструкции: if (isIE)… в одном и том же скрипте, что отрицательно сказывается на размерах скрипта.
В том числе отбрасывает написанный на Java код но не используемый ни в одном вызове. Плюс к этому тулкит компилирует отдельный скрипт для каждого бразуера, когда большинство рукописных скриптов использует конструкции: if (isIE)… в одном и том же скрипте, что отрицательно сказывается на размерах скрипта.
Неторопливый он уж очень…
Интересно читать статью с позиции C# разработчика. Дико смотрится анонимный делегат buttonClick совместно с указанием модификатора доступа.
> А Vaadin уже сам разруливает, какие запросы послать с сервера на клиент и обратно, чтобы этот код вызвался, когда пользователь нажмёт кнопку.
В таких фреймворках для меня, главным показателем юзабельности всегда была простота внесения изменений в логику работы контролов, так как очень часто появляются задачи выходящие за пределы стандартных сценариев. К примеру, библиотека контролов ASP.NET'а на мой взгляд с трудом поддается кастомизации, и чаще всего проще сделать свой контрол чем откастомизировать существующий.
> А Vaadin уже сам разруливает, какие запросы послать с сервера на клиент и обратно, чтобы этот код вызвался, когда пользователь нажмёт кнопку.
В таких фреймворках для меня, главным показателем юзабельности всегда была простота внесения изменений в логику работы контролов, так как очень часто появляются задачи выходящие за пределы стандартных сценариев. К примеру, библиотека контролов ASP.NET'а на мой взгляд с трудом поддается кастомизации, и чаще всего проще сделать свой контрол чем откастомизировать существующий.
Анонимный объект, реализующий данный интерфейс. В интерфейсе паблик на методе, значит и тут паблик.
У вас какие-то странные знания C#
>> Дико смотрится анонимный делегат buttonClick совместно с указанием модификатора доступа.
Обычный анонимный класс, который реализует интерфейс. Что дикого?
>>В таких фреймворках для меня, главным показателем юзабельности всегда была простота внесения изменений в логику работы контролов
и
>> библиотека контролов ASP.NET'а на мой взгляд с трудом поддается кастомизации
+
>> с позиции C# разработчика
Что вы еще кроме ASP такого юзали?
>> Дико смотрится анонимный делегат buttonClick совместно с указанием модификатора доступа.
Обычный анонимный класс, который реализует интерфейс. Что дикого?
>>В таких фреймворках для меня, главным показателем юзабельности всегда была простота внесения изменений в логику работы контролов
и
>> библиотека контролов ASP.NET'а на мой взгляд с трудом поддается кастомизации
+
>> с позиции C# разработчика
Что вы еще кроме ASP такого юзали?
> У вас какие-то странные знания C#
> Обычный анонимный класс, который реализует интерфейс. Что дикого?
обоснуйте, никаких «обычных анонимных классов» в c# нет, если вы конечно не имеет ввиду анонимные типы, но для них не предусмотрена возможность описывать методы.
> и
> +
> Что вы еще кроме ASP такого юзали?
заметьте я говорю про библиотеку контролов ASP.NET'а, а сравнивал я с другими библиотеками контролов. От минималистичных открытых решений до гигантов вроде telerik. Да и того же майкрософта помимо Web Form есть еще библиотеки контролов разработанные для MS Ajax или SharePoint.
> Обычный анонимный класс, который реализует интерфейс. Что дикого?
обоснуйте, никаких «обычных анонимных классов» в c# нет, если вы конечно не имеет ввиду анонимные типы, но для них не предусмотрена возможность описывать методы.
> и
> +
> Что вы еще кроме ASP такого юзали?
заметьте я говорю про библиотеку контролов ASP.NET'а, а сравнивал я с другими библиотеками контролов. От минималистичных открытых решений до гигантов вроде telerik. Да и того же майкрософта помимо Web Form есть еще библиотеки контролов разработанные для MS Ajax или SharePoint.
> Кстати, Vaadin на самом деле использует GWT, так что его можно даже считать надстройкой над GWT, которая решает проблемы общения с сервером.
Все-таки GWT-приложение и приложение Vaadin используют принципиально разный подход:
1. GWT-приложение — это полноценное клиентское приложение, запускаемое в браузере. Оно даже может жить своей жизнью, вообще не обращаясь к серверу.
2. Приложение Vaadin строится по другим принципам. Клиентский GWT-код — это по сути терминал в браузере. Само клиентское приложение «крутится» на сервере. Все компоненты при написании приложения на Vaadin — серверные, для них есть соответствующие GWT-контролы. При этом любой клик, навигация, и т.д. выполняются на стороне сервера. Клиент предельно глуп, он только передает события на сервер и получает оттуда необходимые данные.
У каждого из подходов есть свои преимущества. Написание приложений на Vaadin предельно просто (не зря в статье приводится сравнение со Swing, я бы еще добавил Qt). В то же время, Vaadin требовательнее к ресурсам сервера, больше нагрузка на сетевой трафик.
Для построения многопользовательских систем, когда в онлайне одновременно тысячи пользователей, он малоприменим, т.к. каждая пользовательская сессия, включая всю логику и данные клиента, хранится на сервере (т.е. объем оперативной памяти, занимаемой сервером, напрямую зависит от количества подключенных пользователей).
Зато Vaadin удобен для построения админок и т.п., когда одновременно работающих пользователей немного, зато приложение строится быстро и просто.
Все-таки GWT-приложение и приложение Vaadin используют принципиально разный подход:
1. GWT-приложение — это полноценное клиентское приложение, запускаемое в браузере. Оно даже может жить своей жизнью, вообще не обращаясь к серверу.
2. Приложение Vaadin строится по другим принципам. Клиентский GWT-код — это по сути терминал в браузере. Само клиентское приложение «крутится» на сервере. Все компоненты при написании приложения на Vaadin — серверные, для них есть соответствующие GWT-контролы. При этом любой клик, навигация, и т.д. выполняются на стороне сервера. Клиент предельно глуп, он только передает события на сервер и получает оттуда необходимые данные.
У каждого из подходов есть свои преимущества. Написание приложений на Vaadin предельно просто (не зря в статье приводится сравнение со Swing, я бы еще добавил Qt). В то же время, Vaadin требовательнее к ресурсам сервера, больше нагрузка на сетевой трафик.
Для построения многопользовательских систем, когда в онлайне одновременно тысячи пользователей, он малоприменим, т.к. каждая пользовательская сессия, включая всю логику и данные клиента, хранится на сервере (т.е. объем оперативной памяти, занимаемой сервером, напрямую зависит от количества подключенных пользователей).
Зато Vaadin удобен для построения админок и т.п., когда одновременно работающих пользователей немного, зато приложение строится быстро и просто.
Посмотрел HTML код сайтов на фреймворке — там нет HTML, поисковики это индексировать не будут.
Vaadin в основном используется как инструмент для построения RIA приложения, которое будет работать внутри организации / филиала и т.д. Не для сайтов
Да, столкнулись с данной проблемой, но она лечится, просто надо отдавать поисковому роботу заранее подготовленный для него текстовый файл см. www.google.ru/search?ie=UTF-8&hl=ru&q=http%3A%2F%2Fguimachine.ru%2F сравните данные кэша Google и реального сайта.
Примеры подобраны крайне неудачно, не для этих целей Vaadin нужно использовать на мой взгляд.
Простите, но мне он показался немного убогим. Ужасная работа с таблицами, непредсказуемое расположение елементов при добавлении в контейнер и т.д. После недели использования переписал клиентскую часть на HTML+JS.
На GWT поизящней получается.
Просто вы привыкли html-like программированию.
Вы какой layout использовали что у вас появление элементов было непредсказуемым?
Меня после нескольких лет со SWING, vaadin только порадовал.
Теперь я могу сделать тонкого вебклиента не изучая кучу новых языков и технологий…
Вы какой layout использовали что у вас появление элементов было непредсказуемым?
Меня после нескольких лет со SWING, vaadin только порадовал.
Теперь я могу сделать тонкого вебклиента не изучая кучу новых языков и технологий…
наоборот, я до этого практически не использовал веб-стандарты. Был и Flex и GWT со SmartGwt…
Тогда совсем странно… а долго были Flex и GWT со SmartGwt?
Просто у нескольких прогеров работающих со мной вообще никаких проблем не было… после свинга все просто и понятно…
Просто у нескольких прогеров работающих со мной вообще никаких проблем не было… после свинга все просто и понятно…
Поясню мысль.
Фраза " непредсказуемое расположение елементов при добавлении в контейнер" говорит о том, что у вас нет опыта работы с лайоутами… или же вы просто «забыли» про них когда работали с vaadin.
Фраза " непредсказуемое расположение елементов при добавлении в контейнер" говорит о том, что у вас нет опыта работы с лайоутами… или же вы просто «забыли» про них когда работали с vaadin.
SmartGwt месяца три. После него Vaadin выглядит совсем несерьезно, при этом я, конечно, понимаю, что у них немного разные концепции. Vaadin то понятен, но по возможностям он уступает.
Одно время стоял выбор между Vaadin и SmartGWT для интерфейса к системе. Выбор пал в пользу последнего ввиду очень кастомизируемых гридов. Да и, как уже говорилось, правильно, когда котлеты отдельно от мух (то есть как GWT). В фреймворках типа Swing, Eclipse RCP, QT рекомендуют использовать для этой цели паттерн MVC. Но на практике его никто не использует — вся модель и операции почти всегда замешаны с визуальными компонентами. То же самое будет происходить и при программировании на Vaadin. GWT же заставляет пользователя изначально отделять мясо от костей.
Кроме того хранить Client View на сервере немного расточительно. И почти каждый пользовательский клик пересылается на сервер, чтобы синхронизировать состояние. А в 99% случаев эти операции с интерфейсом не несут никакой смысловой нагрузки для бизнес логики сервера. Так что подход GWT мне кажется более правильным: клиенту клиентово, а серверу серверово ))
Как еще одна альтернатива есть фреймворк RichFaces с большим набором полезных компонентов. Однако у него та же проблема — View State для каждой страницы хранится на сервере, и при большом числе пользователей начинаются проблемы с памятью, если сессии не свопить в базу.
Кроме того хранить Client View на сервере немного расточительно. И почти каждый пользовательский клик пересылается на сервер, чтобы синхронизировать состояние. А в 99% случаев эти операции с интерфейсом не несут никакой смысловой нагрузки для бизнес логики сервера. Так что подход GWT мне кажется более правильным: клиенту клиентово, а серверу серверово ))
Как еще одна альтернатива есть фреймворк RichFaces с большим набором полезных компонентов. Однако у него та же проблема — View State для каждой страницы хранится на сервере, и при большом числе пользователей начинаются проблемы с памятью, если сессии не свопить в базу.
Перед тем, как начать работать с GWT делали примерно год проект с применением JSF/RichFaces. Хотелось плевать. После перехода на новый проект GWT оказался глотком чистого воздуха. Реально на UI происходит много вещей, о которых серверу ну никак не положено знать. Vaadin такого не предоставляет.
Еще один плюс из того, что GWT не завязан жестко на сервер — применение разных технологий на сервер-сайде, не обязательно Java. Вот на текущем проекте мы без проблем работаем с сервер-сайдом, написанном на Python
Еще один плюс из того, что GWT не завязан жестко на сервер — применение разных технологий на сервер-сайде, не обязательно Java. Вот на текущем проекте мы без проблем работаем с сервер-сайдом, написанном на Python
Вот людям не лень велосипеды с квадратными колёсами изобретать…
-Появился новый web-фреймворк на Java
-??!!!
-Чем Vaadin отличается от других Java web фреймворков?
-????!!!
-Если вкратце, Vaadin позволяет писать веб-приложение в стиле Swing!
-FUUUUUUUUUUUUUUUUUUUUUUUU
:)
-??!!!
-Чем Vaadin отличается от других Java web фреймворков?
-????!!!
-Если вкратце, Vaadin позволяет писать веб-приложение в стиле Swing!
-FUUUUUUUUUUUUUUUUUUUUUUUU
:)
— Проявился один товарищ на хабре
— ??!!!
— Чем он отличается от других хабравчан?
— ????!!!
— Если вкраце, то он из этих… ну ты знаешь… которые «Не читал, но осуждаю»!
-FUUUUUUUUUUUUUUUUUUUUUUUU
:)
— ??!!!
— Чем он отличается от других хабравчан?
— ????!!!
— Если вкраце, то он из этих… ну ты знаешь… которые «Не читал, но осуждаю»!
-FUUUUUUUUUUUUUUUUUUUUUUUU
:)
Тоже верно:) Но акцентировать то, что можно писать web-приложение в стиле свинг это очень плохая реклама:)
Товарищи критикующие vaadin за тормознутость, логику на сервере и т.д.
Vaaadin не для сайтов (в общем понимании это слова) разрабатывался.
Поэтому вам и не нравится что «шестеренка крутится».
Он предназначен для интранет порталов. Там где сети по 100 мбит и все происходит быстро.
Одно из его преимуществ это повышенная секьюрность как раз за счет того что все приложение на сервере. Убирает массу головной боли по защите клиента от ковыряния.
Если у вас много логики должно работать на клиенте, то он вам просто не подходит. Для этого есть другие инструменты.
Хотя например у нас разработана система учета (по виду напоминает 1С) на нем и все отлично работает. Да и не только у нас… очень многие его именно для учетных внутренних систем используют.
Vaaadin не для сайтов (в общем понимании это слова) разрабатывался.
Поэтому вам и не нравится что «шестеренка крутится».
Он предназначен для интранет порталов. Там где сети по 100 мбит и все происходит быстро.
Одно из его преимуществ это повышенная секьюрность как раз за счет того что все приложение на сервере. Убирает массу головной боли по защите клиента от ковыряния.
Если у вас много логики должно работать на клиенте, то он вам просто не подходит. Для этого есть другие инструменты.
Хотя например у нас разработана система учета (по виду напоминает 1С) на нем и все отлично работает. Да и не только у нас… очень многие его именно для учетных внутренних систем используют.
Есть подозрение что очень утомляет постоянная компиляция(или даже перезапуск сервера) при изменении UI, поправьте если ошибаюсь.
Вообще сама идея решать все задачи одним инструментом(все на java) кажется мне порочной.
Есть класс программистов, которые не хотят(не любят/не умеют) верстать или писать JS хотя бы на элементарном уровне, так вот они и выдумывают подобные фреймворки. В результате мы все становимся свидетелями такого убожества, которое представлено в примерах по ссылкам.
Я считаю, что если вы разрабатываете веб-приложения, вы обязаны знать и понимать HTTP, HTML, JS, CSS и все остальное что пишете у себя в резюме. Никакой фреймворк не заменит этих знаний.
Вообще сама идея решать все задачи одним инструментом(все на java) кажется мне порочной.
Есть класс программистов, которые не хотят(не любят/не умеют) верстать или писать JS хотя бы на элементарном уровне, так вот они и выдумывают подобные фреймворки. В результате мы все становимся свидетелями такого убожества, которое представлено в примерах по ссылкам.
Я считаю, что если вы разрабатываете веб-приложения, вы обязаны знать и понимать HTTP, HTML, JS, CSS и все остальное что пишете у себя в резюме. Никакой фреймворк не заменит этих знаний.
В целом все верно.
но дьявол как всегда кроется в деталях…
В примерах выше представлено убожество только потому, что люди применяли неправильные инструменты… ну не нужен на обычном веб сайте vaadin… ну нафиг не уперся… Там есть удобные и проверенные инструменты JS и т.д.
«Есть подозрение что очень утомляет постоянная компиляция»… Вот такие заявления меня всегда умиляли… что значит «постоянная» ??? Неужели вы думаете, что фреймворк заставляет вас делать это каждые 10 секунд? Ну бред же… схема работы такая же привычная как на джаве…
По поводу знаний «HTML, JS, CSS и все остальное», то оно надо лишь проф веб девелоперам для которых очередной сайт — всего лишь очередной… и есть куча наработок…
Но мы живем в реальном мире… и есть задачи в которых это отходит на второй план.
Нам нужна была вебморда для информациооной системы. На vaadin я сделал ее за 1 месяц… незная ничего про «HTML, JS, CSS и все остальное»…
Все отлично работает… производительность всех устраивает… итог — задача выполнена. Я пошел дальше разрабатывать на Java не тратя время на прочие технологии…
В общем цель подобных фреймворков не сделать мир во всем мире… и они нисколько не являются панацеей от всех бед… они просто уменьшают время разработки и упрощают сам процесс разработки в определенных случаях…
Например в случае разработки корпоративных информационных систем это почти мана небесная… я сделал интерфейс почти 1 в 1 как в 1С, благодаря чему народ не пришлось переучивать… и сделал все в короткие сроки…
А если микроскопом забивать гвозди и говорить что микроскоп это говно… то да… микроскоп говно…
но дьявол как всегда кроется в деталях…
В примерах выше представлено убожество только потому, что люди применяли неправильные инструменты… ну не нужен на обычном веб сайте vaadin… ну нафиг не уперся… Там есть удобные и проверенные инструменты JS и т.д.
«Есть подозрение что очень утомляет постоянная компиляция»… Вот такие заявления меня всегда умиляли… что значит «постоянная» ??? Неужели вы думаете, что фреймворк заставляет вас делать это каждые 10 секунд? Ну бред же… схема работы такая же привычная как на джаве…
По поводу знаний «HTML, JS, CSS и все остальное», то оно надо лишь проф веб девелоперам для которых очередной сайт — всего лишь очередной… и есть куча наработок…
Но мы живем в реальном мире… и есть задачи в которых это отходит на второй план.
Нам нужна была вебморда для информациооной системы. На vaadin я сделал ее за 1 месяц… незная ничего про «HTML, JS, CSS и все остальное»…
Все отлично работает… производительность всех устраивает… итог — задача выполнена. Я пошел дальше разрабатывать на Java не тратя время на прочие технологии…
В общем цель подобных фреймворков не сделать мир во всем мире… и они нисколько не являются панацеей от всех бед… они просто уменьшают время разработки и упрощают сам процесс разработки в определенных случаях…
Например в случае разработки корпоративных информационных систем это почти мана небесная… я сделал интерфейс почти 1 в 1 как в 1С, благодаря чему народ не пришлось переучивать… и сделал все в короткие сроки…
А если микроскопом забивать гвозди и говорить что микроскоп это говно… то да… микроскоп говно…
Кстати, Vaadin можно вообще использовать для написания десктопных приложений. Компонентов в нем больше, чем в свинге и функциональность у них лучше, куча сторонних плагинов. Все, что должна делать апликация — это запустить embedded сервер и открыть окно с браузером на локальный порт.
Vaaaaaaaadin на фиг не нужен, если вам надо всю логику сунуть на сервер. Хотя бы потому, что вся бизнесс-логика и без него ВСЕГДА работает на сервере. Это только в последнее время стали популярны всякие аяксы. Которые всё-равно зависят от сервера примерно на 100%.
Людям не нравится, потому что вадин — это лютый бред. Бессмысленный и беспощадный. Созданный людьми, которые ничего не смыслят в вебе. Также как Borland когда-то пыталась сунуть на рыной VLC For PHP — полнейшая наркомания не совместимая с жизнью.
Людям не нравится, потому что вадин — это лютый бред. Бессмысленный и беспощадный. Созданный людьми, которые ничего не смыслят в вебе. Также как Borland когда-то пыталась сунуть на рыной VLC For PHP — полнейшая наркомания не совместимая с жизнью.
Про компиляцию.
Сейчас я компилирую(перезапускаю сервер) только когда меняю контроллер или сервис. Вьюхи (JSP) можно менять на лету, ничего не перезапуская. В случае создания UI на java, я так понимаю нужно будет перезапускать чаще.
В этом отношении мне очень нравится django, там вообще очень редко надо что-то останавливать/запускать.
По поводу знаний.
Конечно это относится только к веб-разработчикам. С другой стороны очень недальновидно для любого разработчика избегать это направление, сегодня очевидно что будущее за веб-приложениями, причем на тех технологиях что существуют сейчас.
Если нужно срочно сделать приложение, а знаний нет, тогда я согласен, можно попробовать фреймворк типа Vaadin.
Если есть время, лучше потратить его на изучение основ веб-приложений.
Сейчас я компилирую(перезапускаю сервер) только когда меняю контроллер или сервис. Вьюхи (JSP) можно менять на лету, ничего не перезапуская. В случае создания UI на java, я так понимаю нужно будет перезапускать чаще.
В этом отношении мне очень нравится django, там вообще очень редко надо что-то останавливать/запускать.
По поводу знаний.
Конечно это относится только к веб-разработчикам. С другой стороны очень недальновидно для любого разработчика избегать это направление, сегодня очевидно что будущее за веб-приложениями, причем на тех технологиях что существуют сейчас.
Если нужно срочно сделать приложение, а знаний нет, тогда я согласен, можно попробовать фреймворк типа Vaadin.
Если есть время, лучше потратить его на изучение основ веб-приложений.
Ну я вообще перезапускаю серваки очень редко… только во время обновлений… а на тестовом сервере пофиг перезапускать или нет…
А теперь вопрос. Сколько времени понадобиться на создание приложения а-ля 1С: Склад
1. На чистых веб технологиях (html, js и т.д.)
2. На фреймворках типа vaadin
Насколько «юзабелен» будет интерфейс в 1-ом случае?
На ваадине у меня все управляется с клавиатуры… т.е. есть «шоткаты» и ввод товара возможен без мышки…
Сравнили? А теперь главный вопрос… А нафига все это если обоими способами получаем одинаковый результат?
Главное что делает ваадин — это самая муторная часть работы… организация сериализации объектов… перенос их с клиента на сервер и обратно… готовые удобные компоненты перекрывающие 99% потребностей… и прочее прочее…
Опять же… java стек технологий мне очень нравится… Я сейчас активно ковыряю Scala и черт возьми все что есть в джаве могу использовать легко…
В общем еще раз скажу, что ваадин и начинал и продолжает разрабатываться как фреймворк для бизнес приложений… и в этом направлении он очень удобен…
Я немного лукавил по поводу веб технологий… я неплохо знаком с Python, Django, html, css… сделал несколько проектов на них и мне они очень нравятся…
Но вот я в упор не понимаю зачем мне тратить на них время если во многих (моих… да и не только моих… судя по тому, что ваадин упорно пилят) проектах он банально удобнее и на нем быстрее написать? Опять же для бизнеса это удобно что все построено на одном стеке технологий…
В общем ваадин это не только скорость разработки… Он прекрасно позволяет где надо заюзать html с css… и js кстати тоже…
Ваадин очень удобен для своих задач и отрабатывает себя на все 100%… если он вам не подходит… ну значит это не ваше…
Вон ща придут рубисты и скажут, что вообще все говно кроме руби… )))
Кстати, на sql.ru проскакивала информация, что его в банках активно используют для своих интранет систем в несколько тысяч пользователей…
А теперь вопрос. Сколько времени понадобиться на создание приложения а-ля 1С: Склад
1. На чистых веб технологиях (html, js и т.д.)
2. На фреймворках типа vaadin
Насколько «юзабелен» будет интерфейс в 1-ом случае?
На ваадине у меня все управляется с клавиатуры… т.е. есть «шоткаты» и ввод товара возможен без мышки…
Сравнили? А теперь главный вопрос… А нафига все это если обоими способами получаем одинаковый результат?
Главное что делает ваадин — это самая муторная часть работы… организация сериализации объектов… перенос их с клиента на сервер и обратно… готовые удобные компоненты перекрывающие 99% потребностей… и прочее прочее…
Опять же… java стек технологий мне очень нравится… Я сейчас активно ковыряю Scala и черт возьми все что есть в джаве могу использовать легко…
В общем еще раз скажу, что ваадин и начинал и продолжает разрабатываться как фреймворк для бизнес приложений… и в этом направлении он очень удобен…
Я немного лукавил по поводу веб технологий… я неплохо знаком с Python, Django, html, css… сделал несколько проектов на них и мне они очень нравятся…
Но вот я в упор не понимаю зачем мне тратить на них время если во многих (моих… да и не только моих… судя по тому, что ваадин упорно пилят) проектах он банально удобнее и на нем быстрее написать? Опять же для бизнеса это удобно что все построено на одном стеке технологий…
В общем ваадин это не только скорость разработки… Он прекрасно позволяет где надо заюзать html с css… и js кстати тоже…
Ваадин очень удобен для своих задач и отрабатывает себя на все 100%… если он вам не подходит… ну значит это не ваше…
Вон ща придут рубисты и скажут, что вообще все говно кроме руби… )))
Кстати, на sql.ru проскакивала информация, что его в банках активно используют для своих интранет систем в несколько тысяч пользователей…
Sign up to leave a comment.
Изучая Vaadin