Блеск и нищета GWT (или почему я не верю в Dart часть 2)

[Dallas]

На 100% согласен с автором.

[Rathil]

Был на конференции в Москве, там был докладчик, один из разработчиков новых стандартов Js, по его словам в новых версиях будет просто МАССА многих фич, таких как появление полноценных классов и перегрузка методов…
JavaScript будет еще долго, это факт.

[DLag]

То что JS развивается это конечно хорошо.
Но тот же V8 от Google использует уже устаревший JavaScript 1.6, при том что с 2009 года стабильным считается 1.8.5.
И поддерживает его только Mozilla Fundation, которая в общем-то его и разрабатывает…
Так что если Google Chrome вытеснит Firefox, то маловероятно что JS продолжит развиваться, потому как судя по появлению Dart он не выгоден Googl-у, и он его развивать скорее всего не будет.

[mraleph]

Уточнение: V8 реализует ECMAScript (международный стандарт ECMA-262 5th edition). То, что называется JavaScript 1.x это исключительно Mozilla'вкий диалект. Браузеры поддерживают именно ECMAScript, а не JavaScript (это связанно с тем, что JavaScript это торговая марка на самом деле). Развитие ECMAScript происходит в рамках комитета TC-39. Следующая редакция ES известна как Harmony. V8 поддерживает часть фич из Harmony (скрыты под флагами, как нестандартные): weak maps, block scope bindings (let), proxies.

[dmandreev]

Вы немного заблуждаетесь. ECMA-262, edition 5 (то, что вы назвали 1.8.5 в случае Mozilla) поддерживают Firefox, Chrome и IE. en.wikipedia.org/wiki/ECMAScript. В комитет по разработке этого стандарта входит еще больше компаний, не только Mozilla. Пропорцию их усилий по развитию стандарта и доведению до ума сложно оценить, но если покопаться на сайте Ecma, некоторые выводы можно сделать, наверное тоже очень неожиданные, судя по тому как вы хороните JS.

[AlexTikhonov]

Если я не ошибаюсь, официальный ответ Google по поводу «1.8» был что-то вроде такой — как только будет утверждена соотвествующая версия ECMAScript с фичами (т.е. генераторы и т.д.), в V8 оно реализованно будет почти сразу.

Отмечу что в последних сборках V8 уже есть флаг "--harmony":
code.google.com/p/v8/source/browse/trunk/ChangeLog
2011-10-13: Version 3.7.0
Added flag --harmony to activate all experimental Harmony features.

Кроме того, Dart все-таки слишном… объектно-ориентированный. Для large-scale проектов это возможно и хорошо, но он уже не «универсальный», что делает его более нишевым.

Не вижу причины не развивать V8 как отдельным универсальным движком.

[Finom]

Слишком это всё долго. В хроме даже давно пресловутый let не работает. Что уж говорить о классах и других кофескриптах.

[olegbarabanov]

Мне нравится JavaScript. Мне нравится его подход к решению задач в браузере. Есть замечательный фреймворк(или библиотека — кто как называет) jQuery. Она при всей своей мощи — не такая огромная. И при этом не запрещает мне использовать нативный JS.
На платформе пишу под C++ + QT + QScript и меня всем этот набор устраивает, причем уже долгое время.
Сейчас вообще тенденция пошла, все в браузер засовывать. А как браузер это будет исполнять — мало кого волнует. С V8 — гугловцы молодцы, респект. Да и вообще пнули в скорость работы всех остальных производителей браузеров. Но вот свалку городить — это уже не есть гуд.
Многие разработчики, помимо классического ООП, нехотят знать ничего. У них устаканилось, что такое объект, что у него есть класс-описание и т.д. И другие вариации они не примут никак. И в силу преимущественного количества языков такого типа — не трудно было догадаться о том, что будут бурные холивары. Еще никто не смог доказать тот факт, что прототипное ООП идеологически правильней классического. Я не собираюсь создавать холивар — я просто прошу трезво оценить ситуацию, и заняться чем-то более серьезным.

Извините что большие посты пишу.

[dikarik]

Лично я в браузере приму что угодно, что даст возможность просто объяснить коммиятору или чекеру, что вот здесь ожидается строка, вот здесь — произвольный объект, вот здесь — массив, а здесь — нечто (объект или запись, буде таковые введут), имеющее числовое поле id (число), поле даты date и строковое name.

И чтобы нетипизированных переменных либо не было вообще, либо они запрещались по всему файлу чем-то вроде «use strict»;

Вот после этого на JS было бы куда как менее противно писать. А классы — это всё шелуха.

[Kaaboeld]

Чем же вам так они сильно мешают эти «нетипизированных переменных либо не было вообще»

[nwalker]

Все проще. Статическая типизация будет только мешать, на самом деле.
Достаточно просто строгой динамической(скажем, как в Python|Ruby), чтобы в 90% случаев, где сейчас возвращается undefined, кидался эксепшн в рантайме. Чтобы не было неявных приведений типов.

Вообще, по-моему, слабую динамическую типизацию нужно запретить.

[Kaaboeld]

Как по мне так типизация должна быть на стороне «программы» она ее код и ее «модели» должны ее формировать, пока пользователь не задаст обратного, не вижу ничего в этом плохого куда больше для вижу минусов в null/nil/0/""/" " & etc чем в том что вдруг откуда не возьмись в строку вместо значения «нет данных» придет 0… Вот автоматическое преобразование второго в первое, пошло бы действительно на пользу.

[dikarik]

Может, мы о разной статической типизации говорим? Мне ближе всего модель из D — где можно сказать int i = myFunc(); — и если myFunc возвращает что-то, что в int преобразовываться не умеет, получим ошибку на этапе компиляции. С другой стороны, там же довольно просто организовывается проверка вроде duck tuping — когда просто декларируется: «auto x = y, и должно компилироваться int t = y.foo(1)». То есть можно наложить произвольное условие на принимаемый тип.

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

[nwalker]

Да я понял идею. Тут сложно сказать, какие будут плюсы и минусы. Честно говоря, я никогда не задумывался о статической типизации в замене JS.

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

[nwalker]

Да я понял идею. Тут сложно сказать, какие будут плюсы и минусы. Честно говоря, я никогда не задумывался о статической типизации в замене JS.

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

[nwalker]

Да я понял идею. Тут сложно сказать, какие будут плюсы и минусы. Честно говоря, я никогда не задумывался о статической типизации в замене JS.

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

[diamant]

А кто вам мешает всё типизировать?
Сделайте себе типы Integer, Boolean, Float, засуньте в них примитивы, валидацию типа в сеттерах и вперёд.

[diamant]

А кто вам мешает всё типизировать?
Сделайте себе типы Integer, Boolean, Float, засуньте в них примитивы, валидацию типа в сеттерах и вперёд.

[jack128]

тим, что это динамическая типизация. хочется проверку в «компил тайм». Для JS — проверка типов должна делаться сразу в момент загрузки файла браузером.

[dikarik]

Тем, что это надо организовывать сеттеры, руками (или тулзой какой) проверять типы… уже есть опыт — если такие вещи делаются не в рамках языка, то они перестают работать в самый неудобный момент — в каких-нибудь нетривиальных/сложных случаях, где проверка типов больше всего и нужна.

[diamant]

Возможно, создатели Dart с этого и начали — прикрутили типизацию, потом проверку типизации, потом автоматическую генерацию всей этой байды, чтобы не писать руками… а когда опомнились, то у них уже была тонна кода, которую они и назвали новым языком прораммирования :)

[diamant]

Возможно, создатели Dart с этого и начали — прикрутили типизацию, потом проверку типизации, потом автоматическую генерацию всей этой байды, чтобы не писать руками… а когда опомнились, то у них уже была тонна кода, которую они и назвали новым языком прораммирования :)

[diamant]

Какая-то фигня с комментариями уже не первый раз: нажимаю «Написать» — никакой реакции, через некоторое время снова нажимаю «Написать» — появляются два комментария.

[Boffo]

Интересно, что вы сейчас используете в замену вебтулкита, ну или вообще, для веб разработки в целом. Другими словами, что в данный момент, по вашему, решает задачу веб-разработки наиболее простым и практичным способом?

[vanxant]

jQuery + PHP + MySQL, как ни странно. Да, местами коряво, да, приходится переписывать одни и те же функции N раз, но по скорости разработки ничего лучше я пока не видел.

[Kaaboeld]

По скорости разработки, python + bigtable/postgre очень рекомендую хотя бы попробовать.

[akzhan]

postgre по скорости разработки не выигрывает, скорее позже.
bigtable вообще не в тему, к разработке не относится.

Я ведь тоже могу кричать — 0MQ, RabitMQ, Rubinius, Memcached.

:)

[Kaaboeld]

Выше приводили связку образующею «платформу» (jQuery + PHP + MySQL), соответственно: python + bigtable это отсылка к платформе google appengine использования которой дает не малый прирост к скорости разработки, ИМХО. python + postgre предложена как альтернатива php + mysql распространенной модели для шаред и впс, например; Postgre для меня показался куда более «стройным» решением и в ряде случаев более быстрым. Соответственно были предложены на «попробовать» две разные платформы, что именно вас не устраивает?

[alist]

GWT очень даже взлетел. Когда его только-только показали, все грезили тем, что я бы назвал AJAX Promise — что можно написать приложение десктопного уровня с помощью веб-технологий, и он будет работать, при этом не требуя никаких телодвижений от администраторов сети — нужно просто разослать по email сотрудникам URL приложения — никаких развертываний, никаких танцев с бубном вокруг каждой клиентской машины. Мы поэтому сейчас и пишем в большинстве своем внутренние приложения на HTML-CSS-JavaScript, что админы — люди ленивые, и продать систему, не требующую установки на каждый компьютер клиента существенно легче.

Но писать на HTML всегда казалось слишком сложно. Вот и начались все эти идеи с компиляцией в JS. GWT был одним из самых первых и самых успешных таких проектов. Когда он появился, все закричали:
— Да вы что — это ж именно то, на чем написали GMail и Google Docs! Значит и мы сможем написать наше энтерпрайз-приложение!
Сам Гугл при этом тактично молчал, пропагандировал GWT на всех конференциях, рассказывал о том, как это все здорово.

Так GWT завоевал свое место в Энтерпрайзах. А потом случился казус: Google открыл свою библиотеку на JS — Google Closure — со словами
— Вообще-то Gmail и Доксы написаны на ДжаваСкрипте.
Все такие:
— Эээ… пардон, а… на GWT тогда что написано???
— Ну, вообще-то, мы на нем Google Wave написали, но он страшно тормозит, поэтому мы его закрываем.

И звук такого разочарования: — Уап-вап-уаааап…

А на самом деле JavaScript — язык весьма толковый. Если на нем написать строк 700 нормального кода, не изобретая особенных велосипедов, а используя современные практики — Underscore JS, JSLint, ES5-Strict, jQuery DOM-Events-Ajax и MVC/MVP-подход, — то писать на нем получается быстрее, проще и удобнее. Потому что пока мой товарищ напишет на Java свой UI на GWT, ему придется насоздавать несколько десятков классов, тысячу раз протанцевать вокруг всех типов, писать длинные методы-простыни из-за того, что в Java тяжело с колбэками; я успею все то же самое набросать в виде читаемой верстки, небольшого CSS и аккуратного скрипта, который я смогу нормально, без танцев с бубном и без постоянного редеплоймента протестировать и отдебажить во всех браузерах. И оно будет работать быстрее — всегда. Я никогда не видел, чтобы GWT-компилятор выдал на выходе код оптимальнее того, что, например, используется в jQuery. Основной тормоз производительности в вэбе — DOM-манипуляции. В jQuery они отточены до блеска, в GWT — отнюдь нет.

Во многом проблемы GWT в Java, а не в самом подходе. Пример того же CoffeeScript показывает, что сам подход «компилируем в JS» вполне имеет право на существование. Даже с учетом того, что строки в результирующем JS отличаются от исходников на CS, соответствие прослеживается очень хорошо. Так что все возможно.

Крики о том, что, мол, JavaScript ни черта не модульный, — полная чушь. Модульность не определяется типами, модульность — это интерфейсы и энкапсуляция. Ни то, ни другое в JavaScript не представляет какой-то сложности — Google Closure или Yahoo UI — яркие примеры успешной модульной архитектуры на JS. В случае с последней можно иметь несколько версий библиотеки и плагинов на одной странице — они не будут наступать друг другу на пятки никоим образом. Это jQuery.noConflict() на стероидах. И это именно тот подход, который Gilad Bracha — один из Дартистов — использует в своем языке Newspeak — там он как раз и разбирался с модульностью в программировании.

Tool support? Откройте Chrome Developer Tools, IE9 Dev Tools, Opera Dragonfly, Firebug — там есть столько всего — пользуйся, не хочу! И откройте JetBrains WebStorm или любую другую их среду, где есть поддержка JavaScript. GWT нервно курит в сторонке.

[bananos]

Аргументы по существу к вашим замечаниям
a) На GWT написан Adwords — основной продукт на котором держится весь бизнес Google, преувеличивать используя историю с закрытием Wave явно не стоит
b) Дебажить в яваскрипте всегда было адски непросто, если вы тут упоминаете IE9 Dev Tools как средство для дебага в IE — это гкхм… мягко говоря, вы им мало пользовались на огромных проектах. Firebug, Chrome dev tools — тут претензий нет, IE dev tools — откровенно унылое говно, может на hello world оно и работает адекватно, но явно не на чем-то большом.

Ок, насчет либ и модульности — все вроде как правильно, решать задачи можно и яваскриптом, очень классно что за последние пару лет появилось на эту тему масса отличных библиотек.

Но вот незадача, представьте себе проект жирного клиента в браузере с командой в 10+ человек, Enterprise уровня, что-то вроде Adwords интерфейса, работающего с разными кастомными API и имеющий очень нехилое Desktop-alike GUI, и нетривиальной бизнес логикой.

И вот перед вами задача, как у ответственного за выбор технологии — на чем это все писать? Да, при этом вы понимаете, что вам и самому-то далеко до уровня хотя бы того же Крокфорда, не то что будущим 10+ членам вашей команды.

По-ходу дела, вы также перелопатили кучу JS библиотек, которые как бы вроде и решают задачу, но каждая — какую-то свою отдельную, и ведь мечтается взять сразу что-то готовое и цельное, чтобы и архитектура правильная (MVP), и коммунити было, и документация вменяемая, и т.п. и т.д.

Вот если взглянуть на GWT немного со сдвигом в бизнес, а не в быстроту манипуляции домом и прочие технические нюансы — какое бы вы решение приняли?

[alist]

С удовольствием отвечу.

а) На GWT написан AdWords — да, и это история успеха. Однако, AdWords — далеко не самый популярный ресурс Google по посещаемости по сравнению с теми же Docs. Согласитесь, гораздо меньше людей размещают в Гугле рекламу, чем редактируют документы. У меня есть строгое подозрение, что если бы GWT действительно давал бы преимущества перед чистым JavaScript, Google за 5 лет его существования провел бы несколько миграций продуктов на него. Пять лет — срок немалый. Даже если мы возьмем 2-3 года на обкатку технологии, все равно уже прошло достаточно времени, чтобы «поверить» в него и выпустить на нем еще что-то. Тот же Buzz или Google+ — почему они не на GWT?

Кроме того, мне неизвестен ни один другой крупный проект, написанный на Гвите. Я верю, что они есть, просто не знаю. Очень бы хотелось услышать о каком-то таком проекте, о том, на какие грабли пришлось наступить, о том, как преодолевались те или иные ограничения.

б) Дебажить в Джаваскрипте действительно не всегда легко, но у меня в связи с этим вопрос — а вообще легко ли дебажить GUI? Вся эта событийная модель, где в секунду действия летит куча эвентов, и выделить среди них тот, который тебе нужен, не всегда возможно. Что касается IE9 — на сегодня это второй удобный для меня тул после Chrome Dev Tools. Обычно мы отлаживаем все до блеска в Хроме, а затем переключаемся на Эксплорер, и там работаем с IE-specific вещами. Да, не всегда достаточно, особенно, если работаешь с VML — тут вообще дело дрянь:( Но в целом, я очень доволен, в сравнении с тем же дебаггером в IE8. Нужно учитывать, что Микрософт в данном случае в роле догоняющего. Хорошо, хоть браузер сделали человеческий.

В случае с 10+ человек вынужден сознаться, что опыта нет. Сейчас у меня в команде 4 человека, считая меня. До этого момента JavaScript знал только я. Ничего, научил — сделал серию заданий, которые нужно было выполнить, все с упором на выбранный стек технологий. Сегодня каждый из них спокойно работает с языком и со всеми его «странностями». Я заметил, что прототипизированное наследование у многих начинающих девелоперов вызывает кучу вопросов, но затем они обнаруживают, что динамическая типизация в сочетании с _.extend() дают желаемый эффект, и успокаиваются. Дальше в основном только восторги: нравятся object literals и callbacks, не нравится три равно в ряд.

Цельного предложения на JS аля GWT на сегодняшний день нет — тут вы правы. Есть большие виджет-библиотеки: YUI, jQuery UI и Google Closure — но они не предоставляют организацию приложения. Так что я решил отталкиваться от MVP. Долго колебался между Backbone и Knockout и остановился на последнем. Не прогадал — Нокаут позволяет описывать взаимодействие UI-компонентов между собой и с сервером через механизм подписки. В демо к нему в основном показываются байндинги, но со временем мы все больше и больше отдачи получаем от механизма подписок. Сейчас data-bind воспринимается как что-то, что приятно иметь, но не самое главное.

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

Второй кирпич в основе современного JavaScript — Underscore. Если вы хоть чуть-чуть знаете, что такое LINQ в .NET, то в данном случае это нечто подобное — я имею в виду, что цель проекта — сделать код декларативным, спрятав все, что не имеет отношение к постановке задачи. Сейчас в нашем проекте практически не осталось циклов — все операции по работе с коллекциями мы производим через функции Underscore. Частично его функциональность пересекается с jQuery, в таких случаях мы отдаем предпочтение Underscore — в нем гораздо меньше магии и отлаживать соответствующие места удобнее. Вообще после выбора Knockout JS и Underscore мы заметили, что применение jQuery фактически свелось к аяксу и т.н. live-эвентам.

Что было бы, сли бы наш проект велся на GWT? Я уверен, что мы бы потратили уйму времени на организацию кода, гораздо больше, чем в случае с JavaScript. Хотя тут играет роль среда разработки. В моем случае голоса в пользу GWT подавались — у кого-то даже был опыт работы с ним. Я просто предложил пройти курс JavaScript и самое сложное задание из него (с редактируемой гридой, автокомпитом, аяксом и т.д.) сделать на нашем стеке и на GWT. Ребята попробовали и сказали GWT нет.

Два года назад я бы сказал: выбирайте YUI, а модули пусть потом вырастают сами, используйте custom events для их связи. Сегодня я говорю: выбирайте некоторый MVP фреймворк и Underscore, а библиотеку виджетов по вкусу — если у вас на странице jQuery и можно обойтись jQuery UI — пользуйтесь на здоровье, иначе — YUI — они не подведут. На GWT я всегда смотрел с опасением, хотя Java я оченнь люблю и пишу на ней много лет.

[bananos]

Насчет

Согласитесь, гораздо меньше людей размещают в Гугле рекламу, чем редактируют документы.
я все-таки позволю себе не согласиться =)

По-поводу вашего опыта использования — очень интересно было бы еще в деталях почитать, особенно про связку Knockout + Underscore, возможно у вас где-то завалялись записи в личном блоге. У меня такого опыта к сожалению не было, и кстати, выбор в пользу GWT делался почти 2.5 года тому назад, когда про такие либы ничего не было слышно. Тогда мы рассматривали вещи типа jQuery UI, YUI Library, SproutCore, Javascript MVC, Cappuccino.

Ну и насчет количества людей занятых в проекте, могу смело сказать что java как база для GWT себя полностью оправдала. У меня теперь не будет болеть голова даже если количество народу увеличить вдвое.

В чем прокол у явасрипта как у набора тулзов и как языка — так это в сложности поддержания дисциплины. А вот как раз java для этого подходит более чем, так как тут тебе весь набор средств — начиная от строгой типизации в самом языке, заканчивая тоннами готовых утилит для контроля за качеством кода.

Спорить хорошо это или плохо — предмет другого разговора, до старта проекта на GWT у меня был за плечами опыт PHP / Javascript(prototype, jquery), Delphi, Pascal(x86) и всякое еще разное по мелочам. Но вот на чем мне уж точно не хотелось писать после PHP (CakePHP) — так это на Яве, страшилки про мегабайты XML файлов конфигураций, сотни иерархий классов с интерфейсами — все это меня откровенно пугало.

Я сторонник концепции convention over configuration, которая кстати сказать, отлично работает в маленьких командах и на динамических языках типа Python/Ruby/JS. То есть при прочих равных, проще договориться между собой и использовать гибкий динамический язык, чем клепать тонны конфигураций и делать средства для контроля кода — но на сложных проектах с кучей людей, увы, другие законы — договориться становится просто физически нереально.

Собственно, перелопатив тонны разных решений, ничего особенно и не оставалось кроме GWT для решения нашей задачи. Какие бы у меня личные предпочтения не были на тему Явы, нужно было решать поставленную задачу подходящим инструментом.

Касательно тест-задания про редактируемый grid — точно могу сказать, что скорость создания своих компонентов(виджетов) в GWT таки будет казаться черепашьей по сравнению с обычным яваскриптом. Но как только этот компонент написан — тут уж re-use идет капитальный. Мы по этой причине вначале очень сильно тормозили, так как нужно было много чего сделать с нуля (из стандартных GWT виджетов мы использовали только несколько, все остальное пришлось делать самим)

В общем, резюмировать могу вот этой замечательной картинкой :)



Да, по ходу дела, наши стейкхолдеры иногда задалбывают неудобными вопросами — зачем нам GWT, которое не очень-то популярно(стоимость программиста сильно выше), разработку точно уж agile не назовешь (dev-mode тормозит, java overhead и все сопутствующие) ну и т.п. в том же духе. В какой-то момент, я решил более ясно изложить нашу позицию и родил опус Why GWT? — там более развернуто расписано почему и когда нужно выбирать GWT.

[9zloy]

В точку. Мы в свое время взяли ExtJS. Гораздо более легковесный, чем GWT, но и с ним было СТОЛЬКО геморроя на UI, что просто финиш. В этом году написали свой фреймворк на Underscore и jQuery. Гораздо лучше все стало. Гораздо проще модифицировать UI. Дизайнер уже не рвет на голове волосы, выискивая класс в дебрях сгенеренного дума.

[xonix]

> Во многом проблемы GWT в Java, а не в самом подходе. Пример того же CoffeeScript показывает, что сам подход «компилируем в JS» вполне имеет право на существование. Даже с учетом того, что строки в результирующем JS отличаются от исходников на CS, соответствие прослеживается очень хорошо. Так что все возможно.

Преимущество GWT — это возможность отладки клиентской логики именно на уровне Java. Та же идея и с Dart. Никакой CoffeeScript этого не позволит, пока не будет создан свой CoffeeScript-runtime, т.е., вероятнее всего — никогда.

[kirushik]

Забавно, в про всякие JUnit в треде вообще никто не в курсе?
В плюс написания всего насквозь на Джаве необходимо дописать в возможности сквозного применения TDD на всех уровнях разработки при помощи одних удобных и мощнецких инструментов (у нас — Mockito+JUnit и автотестирование в Тимсити).
Ну плюс с divной DOM-моделью в ходе развития ветки 2.x надо сказать стало гораздо лучше, чем живописует автор статьи.

Да, если есть ещё в Москве GWTшники непристроенные — идите к нам работать. Печеньки, все дела…

[vanxant]

JUnit — да, рулит. Но в вебе на селениум всё же куда больше нагрузки приходится.

[dikarik]

Что на Java быстро писать не выходит — кто бы спорил. Но это недостатки конкретно Явы (не особо связанные, кстати, с собственно классами). К дарту всё это отношения не имеет.

[xonix]

> Что на Java быстро писать не выходит — кто бы спорил.

Я могу поспорить. При наличии хорошей IDE — очень даже выходит.

[dikarik]

Она (или библиотеки её?) способствует слишком уж большому разбиению на классы, куче (не всегда нужных, в общем-то) уровней абстракции, чрезмерной детализации и т.п. Как-то громоздко оно. Мне пару раз синтаксис обращения ко всяким HashMap в кошмарах снился, кроме шуток. Хорошо что не особо много на ней писать пришлось.

[susanin]

Что кошмарного в map.get(key) и mao.put(key,value)?

[dikarik]

То, что это читается, мягко говоря, неудобно, а использовать это в более сложных выражениях, чем простое присваивание — ещё более неудобно. А вот [] мгновенно выхватываются взглядом, и в выражениях хорошо «сидят». В этом плане синтаксис STL гораздо приятнее.

Впрочем, я вообще сторонник специального синтаксиса — он (в разумных пределах, конечно) позволяет гораздо быстрее читать код.

[xonix]

Может быть Вы еще считаете ассоциативные массивы (котрые и списки и словари в одном) из PHP верхом изящества?
В Java коллекции на все случаи жизни, просто. В разных местах оптимальнее применять свою реализацию коллекции. А в PHP из-за его «универсальных» array эффективность просто зашкаливает.

[dikarik]

Нет уж, спасибо. Хотя будь это просто одной из возможностей — ничего бы против не имел. А вот разные put/get/assign/equals читать крайне неудобно, и выгоды в этом никакой — специальный синтаксис был бы удобнее намного.

Но это скорее пример, хорошо демострирующий «дух» джавы — очень много неудобочитаемого и объемного кода. Начиная с XML-конфигов тех же.

[alist]

Согласен отчасти — все-таки типизация требует времени, причем чем сложнее система типов, тем тяжелее с ней иметь дело. Однако, в клиент-серверных приложениях основной проблемой становится маршаллинг объектов, но тут дело в хорошем сериализаторе. Например, в нашем случае мы взялись за Gson — это JSON-сериализатор и парсер от Google. Умеет, например, такие вещи делать:

Type collectionType = new TypeToken<Collection>(){}.getType();
Collection customers = gson.fromJson(json, collectionType);


Заметьте там anonymous class для типа - очень эффектный способ специализации, но выглядит как черная магия. Это как раз тот случай, когда приходится "воевать" с типами.

Но в случае с UI Java, к сожалению, даже среда разработки выручить не может.

[xonix]

> Но в случае с UI Java, к сожалению, даже среда разработки выручить не может.


Почему? Почти в любой IDE для Java есть свой UI-Designer же.

[dikarik]

Типизация в разумных пределах особого времени не требует — int написать не сложнее, чем var, а написать декларацию структуры — не сложнее, чем проверить, что пришел ассоциативный массив (используемый как структура) со всеми нужными элементами. Просто заигрываться в здоровые иерархии классов не надо. В джаве в этом плане уже довлеет традиция и накопленная кодовая база, но для веба можно делать гораздо проще и при этом отлавливать массу ошибок.

[philpirj]

Хочу лишь заметить, что GWT на своей стезе был далеко не первым, отстав от Echo1 и Vaadin на 4 года, от OpenLaszlo на 3 года, от ZK на год.
И, учитывая ваш комментарий и пост автора, не понимаю, чем GWT лучше.

[aspect]

Ваадин, кстати, сейчас переехал на гвит

[asm0dey]

Я даже не знал, что он был не на )))

[vimvim]

Насчет tools не могу согласиться.
Отладка в GWT это одна из существенных причин его использовать. Фактически отладка GWT приложения
ничем не отличается от отладки обычного Java. А тут доступен весь набор встроенных средств Eclipse или IntelliJ Idea. Никакая среда для JavaScript даже близко ничего подобного не дает.

[9zloy]

Отличный коммент. Подписываюсь и плюсую. GWT вводит совершенно ненужный в данном случае уровень абстракции, который решая одну проблему, порождает другие, отнимающие время. Java не самый лучший язык. ООП не самый лучший способ разработки для веб.

[isden]

Сдается мне, автор статьи весьма поверхностно знаком с GWT.

[vanxant]

Я ж указал в статье — я четыре долбаных года на этом GWT делал один достаточно сложный проект и реализовал десяток мелких. Не фуллтайм, но пару человеко-лет в сумме я на GWT потратил. Так что насчет «поверхностно» вы малость погорячились.
Да, в статье есть некоторые технические неточности, но они допущены сознательно, чтобы не перегружать текст ненужными деталями, которые не влияют на общий смысл.

[isden]

Немного цитат, что сразу бросилось в глаза:

> В автоматически создаваемых элементах интерфейса использовалась махровая табличная верстка. Любой прямоугольный блок генерировал таблицу с одной ячейкой.

Кроме HorizontalPanel / VerticalPanel есть еще 100500 компонентов, а если этого мало — можно написать свои, на любой вкус.

> Сверстать свой HTML и скормить его GWT на практике оказалось также не очень-то просто.

Про UiBinder вы, наверное, тоже не слышали.

> В теории GWT поддерживает JSNI — что-то а-ля ассемблерных вставок в Си, только с Javascript в роли ассемблера. Но работает это только в одну сторону. То есть вызвать какую-то внешнюю js-библиотеку из GWT вы можете без проблем. А вот наоборот…

Вы про это — code.google.com/webtoolkit/doc/latest/DevGuideCodingBasicsJSNI.html#methods-fields?

[vanxant]

Да-да, про JNI это оно самое. Вы на практике пытались это заставить работать? Ну вот хотя бы, как я уже говорил, повесить онклик на картинку, которую перехватит GWT? Я пытался (и делал). В документации, прямо скажем, далеко не всё указано.
Про панели — мне что, надо было перечислить всю библиотеку? Основные (HorizontalPanel, VerticalPanel, FlexTable, Grid) — верстают таблично. То что с них выходит в итоге это жесткая жесть. UI Binder при этом ну совсем никак не помогает. «Можете написать свои» это бугога.

[dbmaster]

Использовал на практике как раз похожую ситуацию. Работало как часы. Возможно вы просто не сделали DOM.sinkEvents.

[Bas1l]

Я не работал с GWT, но, мне кажется, ваш комментарий намекает на то, почему разработка может быть медленной: нужно не забыть использовать dom.sinkEvents (и откуда-то узнать об этом). И будет еще миллион мест, где нужно вызвать/настроить/объявить/изменить какую-нибудь мелочь.

Связка js/html/css, помимо single responsibility и modularity подкупает своей прозрачностью.

[dbmaster]

Обычно подключать слушатели напрямую в DOM элементу — это как раз нестандартное использование GWT, для этого есть соответствующие события в самом GWT. В целом технология достаточно объемная и прежде чем ее использовать, лучше читать мануалы, иначе можно сталкиваться с проблемами, которые кажутся неразрешимыми. Сама возможность писать код на Java никак не отменяет необходимость знания JS и CSS. Также необходимо понимание, как это все работает на связке, и только когда будет выигрыш от GWT.

[btd]

По моему это дело опыта, а не прозрачности чего бы то ни было.

[Bas1l]

Я не спорю, но идея в том, что при прочих равных для создания сайта на хорошей технологии надо полгода опыта, а на плохой--3 года.

Например, ASP.NET и ASP.NET MVC. ASP.NET--полный отстой, и, к примеру, даже с тремя годами опыта вам понадобится 2 месяца, чтоб сделать сайтик. А с ASP.NET MVC человеку с месяцем опыта понадобится 1 месяц, чтоб сделать тот же сайтик.

Потому что в ASP.NET MVC лучшая архитектура (более прозрачная, меньше скрытых зависимостей, меньшая связность компонент и тп), и он лучше соответствует парадигме веба. Фраза «Возможно вы просто не сделали DOM.sinkEvents» намекает на те же проблемы, что есть в ASP.NET; но не на 100%))

[isden]

> Вы на практике пытались это заставить работать?

Ну того что мне смогло потребоваться JSNI вполне смогло сделать.

> повесить онклик на картинку, которую перехватит GWT

Т.е. у вас есть где-то картинка, на onClick на которую вам нужно перехватить? И хандлер в JSNI-методе не срабатывал? Или в чем была проблема?

> Основные (HorizontalPanel, VerticalPanel, FlexTable, Grid) — верстают таблично

Почему вы думаете что это основные? Основные — это SimplePanel например, состоящая из 1-го div'а.
Другое дело, что проще и быстрее использовать Grid/etc.

> UI Binder при этом ну совсем никак не помогает.

Поверьте мне, это вполне удобная и полезная штука. На личном опыте ощутил.

> «Можете написать свои» это бугога.

Да какие «бугога», это не так уж и сложно.

[vanxant]

Проблема с JNI в том, что имена ваших переменных, функций и классов в обфуксированном коде меняются при каждой компиляции. Внешний Javascript, который не прошел через компилятор, не может использовать выражения вида [e-mail]::myInstanceField — они, естественно, никуда не ведут. Вам приходится выполнять линковку вручную, то есть сначала вызывать javascript-функцию с callback-ом на себя, а потом этот callback eval-ить с нужными параметрами. И в документации (опять же, не знаю как сейчас) на этот счет тишина.

[isden]

А, вот теперь понятно. А если попробовать внутри JSNI метода определить JS функцию (которую и вызывать извне) и в ней сделать вызов [e-mail]::myInstanceField?

[vanxant]

Вот кстати не знаю, разрешит ли компилятор сделать такой финт ушами. Не пробовал.

[akzhan]

Такая простота — уже провал.

[i_home]

А просто в GWT коде сделать что нибудь типа:
public static native void defineBridgeMethod()/*-{
$wnd.functionName = function() {
return @com.corp.gwt.module.AppClass::myFunction()();
}
}-*/
а потом просто в скрипте вызвать functionName()
Или я чегото не понял и вы именно это имели ввиду говоря про вызовы callback-ов, тогда не очень понятно в чем тут сложность.

[i_home]

Пока писал успели добавить кучу комментов :(

[vanxant]

Ну примерно к этому и сводится, только не все такие методы могут быть static

[dbmaster]

Да и ник автора соответствует.

[vanxant]

Ну не всем же называться мастерами:)

[Cher]

Возникла такая же мысль.
>>В классическом же ООП будет отдельный класс, но это полбеды; главное — будет рефакторинг с выделением интерфейса
>>и написанием кучи кода, который вообще ничего не делает, а просто поддерживает структуру классов. А всё из-за
>>статической типизации, которая не позволяет просто так использовать вместо «просто кнопки» «кнопку с перламутром».
Когда начинаешь учить Java может случиться enterprise головного мозга. Важно понять что никто не заставляет использовать интерфейсы и наследование везде и всюду. На java тоже можно все делать просто и быстро.

[solver]

Всегда удивляли люди которые лепили интерфейс на каждый класс, утверждая что это истинный java-стайл…

[abarmot]

GWT превосходен! Мало какой фреймворк или технология поразили меня сильнее.
Убежден, что не существует более красивых изящных и продуктивных способов создания веб-приложений.

>> HTML как таковой не использовался.

Про UI-Binding почитайте плз…

>> Нет такой функции — изменить стиль, и не будет, делайте всё CSS-классами.

widget.getElement().getStyle().setProperty("fontSize", "1.2em");


>> Если вам нужно сделать табличку 2х3, вам нужно описать модель, контейнер...

Видимо речь шла о CellTable. Используйте обычный Grid или FlexTable

[vanxant]

Да-да, я знаю про getStyle(). Её тихо и без помпы добавили в 2.0, где она не работала в ИЕ, а нормально работать она начала где-то к 2.2 — как раз когда мы переписывали проект на jQuery. Спасибо, Великий Гугл!
Вы, кстати, не находите, что такой подход — типа вашего getStyle или моего любимого

grid.getCellFormatter().setWidth(0, 0, "45%");

выглядит как-то немного длинновато по сравнению с реализацией того же на js или css? Не многовато-ли синтаксического мусора для таких простых действий? Подобных строк ведь в коде больше половины… Вот про это я и говорю — вроде всё работает, но без GWT получается в разы быстрее.
Я знаю про Grid и FlexTable. Про UI-Binding не слышал, если вы про UI Bind, то это бред. Давайте добавим еще и XML, из которого будет генерироваться java-код, который скомпилируется в javascript, который породит html. Гениальное решение, ящитаю.

[vanxant]

Парсер лох, следует читать «если вы про UI Binder»

[isden]

> Подобных строк ведь в коде больше половины

Четкое следование паттерну MVC/MVP, выделение view в отдельный класс + UiBinder творят чудеса.

[vanxant]

Да-да, а ещё люди придумали CSS и HTML, как раз для описания UI и внешнего вида, которые для этого намного лучше подходят и которые кушаются прямо браузером, без промежуточных компиляторов.

[isden]

И что же мешает использовать HTML/CSS практически в чистом виде в шаблонах UiBinder?

[poltora]

И css не сразу появилось, и концентрироваться на html моложе 5-ой версии все уже чурачатся.

Консерватизм — не самая лучшая черта. А уже для профессии — губительна.

[9zloy]

widget.getElement().getStyle().setProperty(«fontSize», «1.2em»);

постыдились бы людям такой код показывать…

[dbmaster]

Скажу пару слов в защиту GWT. Сам по себе GWT отличный инструмент, но его нужно использовать по назначению. У него достаточно узкая ниша – тяжелые веб-приложения. Именно тогда код, скомпилированный GWT, будет производительнее написанного вручную. Также остаются все плюшки Java разработки: привычные инструменты для статического анализа, покрытия кода, юнит-тестирования, документирования. Но, как и любой инструмент, GWT нужно правильно применять – приложение с хорошей архитектурой будет работать совсем не медленнее аналогичного, написанного на чистом JavaScript. А решение проблем, описанных автором, давно уже есть в мануалах, например, интерфейс можно описывать в виде xml разметки – UiBinder, использовать Cell Widgets, или использовать готовые библиотеки, например GXT.

[skyogre]

А почему автор берёт в пример приложения вроде интернет магазинов. Я вот сижу, пишу учётную систему в вебе (да-да, та что с малым кол-вом классов и большим кол-вом объектов) и думаю, как бы мне впихнуть представления автора в собственные реалии? Нынешний подход из сборной солянки всяких технологий или использования фреймворков вроде RoR хорошо работает для разработки сайтов, интернет магазинов и подобных приложений. Однако становится дурно когда ты фигачишь какую-нибудь финансовую систему с кучей форм, все на одно лицо, в которой везде должны быть одинаковые виджеты. В таких системах о вёрстке вообще речи не должно идти, иначе проект никогда не закончится. Функционал здесь как правило важнее рюшечек и супер удобства.

[vanxant]

Думаю фанаты Apple с вами не согласятся на счет рюшечек.
Почему, кстати, только интернет-магазины? Ну вот есть у вас столь любимый бюрократами отчет. Пару десятков колонок, тысченка строк, подытоги, пара сводных графиков. Кнопки сохранить и распечатать. Юзер кликает по ячейкам, в них на лету встраиваются input-ы, он там чего-то правит.
В каком месте тут нужны классы? Ячейки и строки? Бросьте, это примитивные типы для хранения данных, бизнес-логики в них почти нет. Ну конечно можно создать под них классы, но не обязательно. Основная логика принадлежит объекту «таблица», которая должна пересчитывать подытоги, сообщать графикам что пора перерисоваться и т.п. Таблица здесь в единственном экземпляре, все остальные объекты тоже.

[skyogre]

Потому что у наших бюрократов семь пятниц на неделе и отчёты меняются каждую неделю. А чтобы быстро и дёшево нафигачить очередной отчёт, нужно чтобы виджеты для редактирования и отображения по дефолту генерились из типа данных в колонке. Я не желаю каждый раз свёрстывать страницу для нового тупого отчёта. Я хочу просто прописать, что вот запрос должен отображаться в таком-то гриде. И тем более я не желаю прописывать валидацию на серверной стороне для бесконечных форм, если все поля можно просто разнести по типам.

Согласно статье автоматизация таких вещей в GWT реализована не лучшим образом. Но я имею массу положительного опыта в использовании такого подхода для учётных систем в вебе.

[vanxant]

Вот вы знаете, ваши слова звучат разумно (ну кроме валидации на сервере, она обязана быть), но по факту подкрутить javascript оказывается быстрее, чем «прописать что запрос должен отображаться в таком-то виде». Ну как-то вот так вот оно получается.

[Kaaboeld]

«В таких системах о вёрстке вообще речи не должно идти, иначе проект никогда не закончится. Функционал здесь как правило важнее рюшечек и супер удобства.»
Пусть пользуются консолью баш наше все…
</сарказм>
Пробовали предложить подобный им интерфейс в поддержку вашей логике?

[Bektimirov]

Про Grid, точнее Cell Widgets, чистая правда. Очень Ориентированное Программирование. Попробовал один раз на свою голову, потом забивал костыль за костылем, чтобы элементарно повесить обработчик на ячейку. Касательно поста могу сказать, что GWT очень хорошо подходит для портирования десктоп приложений в веб, как вариант. Другой случай: есть толковые спецы, которые пишут на Java N лет и вдаваться в кросбраузерную верстку и остальные нюансы им не хочется, да и время не позволяет, а хочется написать полноценное веб-приложение здесь и сейчас.

[Foror]

>Весь вопрос в том, какая парадигма позволяет быстрее решить конкретную задачу.
Соглашусь

>Java, и с ним весь классический ООП
>Это подходит всяким бизнес-приложениям
Подохит, а еще это подходит множеству других задач, или вы думаете enterprise это и есть вся java?

>В вебе всё не так.
Ого, а как?

>На одной странице у вас есть всего одна форма входа, одна корзина, один текущий пользователь
Ого, значит веб это у нас только интернет магазины? Фигасе…

Ну и дальше в таком же духе. «Специалисты» на хабре негодуют :)

[eliah_lakhin]

Это одна из лучших статей на Хабре за последнее время. Большое спасибо!

Полностью разделяю вашу позицию по этому вопросу.

Еще я был бы очень рад услышать вашу точку зрения о том, как можно было бы решить проблему с зоопарком из JS/CSS/PHP/etc более изящно, чем это пытается сделать Google.

[vanxant]

JS на сервере. Не обязательно node.js, но что-то в духе. Потом возможно хранилище, которое будет быстро перелопачивать JSON и давать интерфейс на подобие jQuery.

[knekrasov]

1) А чем JS на сервере принципиально лучше любого другого языка?
2) Один из плюсов того же GWT как раз в том, чтобы не хранить дерево объектов View на сервере (как в JSF) и соответственно не дергать его (сервер) на каждый чих.
3) Могу ошибаться, но пока парадигма NodeJS выглядит так, что сервер должен быть тупой (минимум бизнес-логики), но надежный. Далеко не все веб-сервисы и приложения укладываются в эти рамки.

[vanxant]

1) дублирование кода

[bubuq]

А как быть с эстетическим протестом против JS? Не в смысле, что дарт лучше, но всё же что-то неправильное есть в языке, если без гирлянды библиотек типа jQuery и underscore писать почти невозможно?

[vanxant]

На чистом Java, С++ или C# вообще без библиотек вы даже hello world не скомпилируете. И что, это плохие языки?
То, что новые фишки сначала обкатываются в сторонних библиотеках — это нормально. Тот же boost в С++. Уж лучше так, чем лепить в стандартную либу непонятно что, а потом половину этой либы объявлять deprecated как в Java.

[bubuq]

Во-первых, да, Ява это плохой язык, а С++ не очень хороший. Во-вторых, всё же stdio это стандартная библиотека, часть системы. Стандартная библиотека JS это браузер. В-третьих, я не согласен с такой аналогией. Речь не идёт о новых фишках. Речь идёт о непосредственном поле применения языка — работе с ДОМом. Очень тяжело, практически невозможно понять, почему мне надо писать

document.getelementById('#bubuka')

для столь фундаментальной и базовой операции. Библиотечные костыли

$('#bubuka')

костылями и остаются из-за позавчерашнего синтаксиса. Должно быть просто #bubuka, или как-то столь же просто, ДОМ должен быть одним из базовых типов данных. В версии jQuery мы имеем шесть мусорных символов, что, конечно, прогресс по сравнению с тремя десятками без неё, но в идеале должно быть не больше двух. ИМО.

[vanxant]

Ну если вам нужен именно getElementById, определите себе $=function(e){return document.getElementById(e)} и радуйтесь. Вариант с #e действительно был бы удобнее, но увы, увы.
Но всё же объект jQuery устроен немного:) сложнее, и вот такие трюки как $(".myclass td span") определить #-подобной семантикой довольно сложно.

[weirdan]

Стандартная библиотека JS это браузер.

Сомнительное утверждение. Контр-примеры: mongo dbshell, node.js, views в CouchDB, скриптинг в OpenOffice, Adobe Creative Suite, PDF, кишки Mozillы — тут HTML DOM, как правило, вообще не нужен.

Что не отменяет изрядную громоздкость самого DOMа — ну так на то он и отдельная спецификация, его можно развивать отдельно, а можно и полностью заменить другим интерфейсом. Тут уж все карты у разработчиков броузеров на руках.

[printf]

Достаточно перестать относиться к стеку веб-технологий как к проблеме. В этом и заключается unix way: для каждой задачи свой инструмент. Для копирования файлов — программа cp, для удаления — rm. Для стилей в веб-странице — CSS, для поведения — JS.

[philpirj]

С некоторого времени веб перестал быть просто страницами, и пользователи ждут десктопо-подобного поведения, реализовать которое можно разными путями, но с использованием текущего стека веб-технологий достаточно неадекватно. И получается, что либо SQL БД у нас теперь на клиенте, либо каждый чих, включая onmouseover отправляется на сервер. GWT, как и остальные, пытается скрыть всё внутреннее уродство, но мы то о нём знаем.
Делал красиво десктопо-подобные приложения на HTML+JS+CSS+whatever на серверной стороне, и довольно сильно запарился без отсутствующего на тот момент .live в jQuery как минимум, а как максимум нежеланием некоторых браузеров делать eval тэгу script, который добавлялся в какой-то новый элемент AJAX запросом. Да, это было красиво, но повторять такой опыт я бы вряд ли захотел.

[vanxant]

Для ситуации «есть десктопное приложение на Java, есть толпа кодеров, которые ничего кроме Java не знают, и нужно сделать веб-версию» — да, безусловно, GWT рулит без вариантов.
Но статья не о трудностях больших компаний, нанявших толпу Java-кодеров.

[SirWiz]

Всё это вещи, на мой взгляд, спорные. Особенно, применение глаголов прошедшего времени.
Бесспорная проблема у GWT одна: он безумно, катастрофически, убийственно, до слёз долго компилируется. И так же медленно работает в hosted mode.
Что делать то? Делать то что? Какой супер-компьютер брать?

[Cher]

а вам часто его надо компилировать? В хостед моде (который теперь девелопер моде) он на лету ваши изменения транслирует в виртуальную машину в которой крутится JS при отладке и отдается браузеру через плагин. Что-то более быстрое для разработки придумать сложно. Ну а когда время деплоить на сервер, да, придется потратить пару минут.

[SirWiz]

Один браузер + одна локаль + ещё драфт компилэйшн + ssd винчестер — всё равно не спасают. Может, i3 на ноутбуке уже убогим стал и надо i7 брать. Но как-то я н десктопах c i5 особого счастья тоже не видел.

[SirWiz]

Вы собеседника читаете? И так же медленно работает в hosted mode — я сказал. А графики вообще в хостед моуд не работают. Но ООП обертка для ofc2 так убого написана, что json я стал ручками собирать и тестировать под apache httpd. Вот там да, что-то более быстрое, чем httpd придумать сложно :-) В конечном итоге не совсем ручками, с помощью GWT-ных классов JSONValue и моих расширений над ними, а флэшку запихнул в свое расширение FlashComponent, а charts из инхеритов выкинул, но всё равно под хостед моуд это не работает.

[vanxant]

Насчет прошедшего времени — всё-таки я сильно сомневаюсь в светлом будущем GWT после выхода Dart. Всё же держать несколько принципиально разных решений для одного и того же достаточно дорого. Вряд ли GWT быстро закроют, но он и раньше развивался очень неспешно, а уж сейчас-то…

[asm0dey]

А может GWT будет компилиться в дарт?

[bananos]

Кстати, верно подмечено — у нас сейчас 3 приложения, суммарно время компиляции составляет в районе получаса. При этом мы поддерживаем только Gecko/IE8/Webkit (то есть еще и не все пермутации компилируем)

Для регулярных билдов решаем супер-компьютером High-Memory Quadruple Extra Large Instance, удается сократить время до 20минут.

Ну а на машинах рядовых девелоперов получается существенное ускорение если пересесть на SSD, докинуть памяти хотя бы до 8гб, и сидеть на чем-то вроде core i5

[SirWiz]

SSD поставил, на первое время отлегло. Всё, кроме GWT, залетало :-) Памяти ему, вроде, не особо требуется. И компилируется оно в один поток. Одна пермутация, по крайней мере. Т.е., супер-пупер многоядерность сама по себе не поможет.

[bananos]

Увеличивать количество localWorkers пробовали?

[SirWiz]

Да. Одна пермутация — один поток. По вашей ссылке картинка есть, которая показывает, что при одной пермутации увелечиние LocalWorkers никакого эффекта не оказывает.

[bananos]

Все равно стоит поиграться, нам помогло

[konsoletyper]

GWT — это не средство для написания веб-приложений. Это фреймворк для написания RIA. Но не всё есть RIA. И сводить веб к ним — это кощунство. Так вот, GWT только для RIA и предназначен. Он не способен описыват серверную логику, генерацию HTML и т.п. JavaScript в общем случае — это не средство написания RIA. JavaScript позволяет сделать более интерактивным и удобным то, что обычным HTML+CSS сделать таковыми не получается. Скажем, в том же вики-движке можно с помощью JS сделать валидацию форм, кнопки для редактора вики-разметки, более удобный загрузчик картинок. Но это никак не отменяет базового функционала сайта — валидация всё равно делается и на сервере, вики-разметку так же парсит сервер, пусть она даже и набита в обычном text area, а файлы загрузить можно через простой input type=«file». При этом сохраняется главное, на мой взгляд, преимущество веба — за каждой страницей остаётся её адрес. GWT на такое не способен, т.к. в принципе для этого не предназначался. Как я понимаю, Dart выступает заменой JS в его различных сферах применения, а не только как алтернатива GWT.

C другой стороны, проблема дублирования остаётся. Лично у меня появилась идея, как можно её избежать. Ряд действий (валидация, отправка и обновление форм, парсинг вики-разметки при предпросмотре) всё равно делаются сервером. Но на стороне браузера такие вещи обычно оказываются более удобными. Не хотелось бы дублировать код, написанный на Java, ещё и на JS. Идея состоит в том, чтобы автоматически получать JS-версию кода, уже написанного на Java. Для этого можно написать декомпилятор байткода Java в Javascript. Вот каковы варианты использования такой штуки:

1. Валидация форм. Валидацию выполняет контроллер. Если вынести валидацию в отдельный метод контроллера, то этот метод можно преобразовать в JS, который то же самое делал бы на стороне браузера и выдавал бы alert'ы. Это вместо генерирования той же самой страницы, но с сообщениями об ошибках ввода.
2. Частичная перерисовка страниц при отправке формы. Логику генерации разметки так же можно перенести на сторону браузера. Когда пользователь нажимает кнопку отправки формы, очень часто пользователю в ответ выдаётся та же страница по тому же шаблону. Вместо этого браузер мог бы передавать веб-серверу только новые параметры шаблона в ajax-запросе и автоматом перерисовывать часть страницы.

При этом тот же самый функционал остаётся и с выключенным JS. Если же нужно написать что-то более динамическое, работающее именно на клиенте, разработчик может взять в руки JS или GWT — что ему нравится.

Я уже сделал кое-какие наработки в этом направлении. У меня есть свой фреймворк, и в репозитории я выделил ветку, в которой работаю над декомпилятором байт-кода — уже есть первые успехи (почти правильно переписанный на JS метод java.util.ArrayList.indexOf в качестве примера). В перспективе хочется добиться генерации качественного читабельного JS, чтобы не столкнуться с проблемой текучих абстракций, которая присуща GWT.

[ttim]

Посмотрите в торону Fantom.

[forgotten]

Блин, чувак, я хотел быть в лучшем за 24 часа (.

[vanxant]

Извини, друг, не хотел обидеть:)

[asm0dey]

Во-первых, кроме GWT емть не менее интересный Vaadin, который красив и не генерит бешеного HTML. Он просто тратит ваш трафик.

Во-вторых, для подвешивания событий есть GWT-обертка вокруг jQuery (GQuery, ЕМНИП).

В-третьих, GWT для RIA и приложений, которые иначе были бы написаны на swing/swt/jambi.

Я закончил, спасибо.

[webus]

GWT справляется со своей задачей вполне. Использую Vaadin, в корне которого крутится GWT для RIA приложений идеальный вариант. А по поводу Dart… да пусть он будет. Выстрелит или нет покажет время. Я недавно читал статью в одном журнале, там сравнивали Go, Vala, D. Дак вот D превосходит Go и Vala по многим параметрам, но о нем не говорят. А все почему? Потому что нет рекламы, маркетинга, грамотной подачи технологии. Так же и Dart. Утихнет рекламная шумиха, и настанет жесткая проверка временем.

[Cher]

Еще 2 копейки по поводу того что GWT не взлетел. Как минимум в одной ооочень крупной соцсети рунета взлетел, и довольно успешно

[Luminal]

2 Cher: так и скажем — Одноклассники ;-)

[Cher]

не секрет видимо )

[osypchuk]

если кому мало мощности JS/Jquery рекомендую www.knockoutjs.com. Я с сентября с ним работаю, мне очень понравилось и я использую и буду использовать это в реальных проектах.
Плюсы:
— принципиально лучше user experience
— более структурированный js код в результате, который легче поддерживать
— переход общения клиент сервер на обмен данными(json) а не полями

К сожалению, в изучении не самая простая штука. Но если в что-то упретесь — всегда есть форум.
PS: МОжет написать статью о нем на хаббре? Хотя в принципе есть замечательное вводное видео…

[Infernal]

Напишите, очень интересно почитать будет.

[alist]

Вообще-то уже неоднократно фреймворк описывался на Хабре, в том числе мной.

[osypchuk]

:) посмотрю
«Чукча — не читатель, Чукча — писатель.»

[lega]

Почему не backbone.js? Рассматриваю оба фреймворка, не знаю в каком направлении пойти, но пока backbone перевешивает. А на оба не хочется терять время.

[osypchuk]

Я не использовал backbone, так что аргументировано ответить не могу. Могу посоветовать посмотреть примеры и сравнить код, который пишется на knockout и backbone и для себя решить, что понятнее и больше соответствует складу ума.

Вот похожие примеры:
http://documentcloud.github.com/backbone/examples/todos/index.html
js код к нему — http://documentcloud.github.com/backbone/examples/todos/todos.js

и knockoutjs:
knockoutjs.com/examples/betterList.html

[alist]

Я выбрал Нокаут, но вам могу сказать, что что бы вы не выбрали, в любом случае останетесь в выигрыше.

Если кратко, то Knockout за счет data-bind-атрибутов даст вам упрощенную работу с UI-элементами. Большинство обработчиков событий, которые связанны с UI, в Бэкбоне придется писать ручками, а в Нокауте — нет. Зато Backbone делает больше работы на бэкэенде, в плане связи с сервером.

Так что выбирайте — что для вас важнее — помощь с интерфейсом или с аяксом. В нашем проекте число различных запросов в коде совсем небольшое, а UI — очень сложный. И мы используем KO, так как он позволяет нам сократить объемы кода в большей степени, чем Backbone.

[sky_lord]

Автор, я твой фанат! Вот за это тебе особенное спасибо: "… весь классический ООП, зиждется на идее разделения классов и собственно объектов — экземпляров класса. Это подходит всяким бизнес-приложениям, которым нужно обрабатывать миллионы строк накладных, платежей, остатков на складах и так далее. Классов там относительно мало, а вот объектов — много. В вебе всё не так." и так далее. Читал и горючими слезами обливался, т.к. ты кратко и емко формализовал то, что мучает меня в последнее время. Плюсик тебе в карму и остальные части тела! И запрос на дружбу тебе сейчас отправлю. :-)

[Luminal]

Прочитав статью и комментарии я не увидел ничего про поддержку написанного приложения.

Главное отличие enterprise решений от не-enterprise в том, что в первом случае приложения задумываются не просто как "написал, показал колиенту, срубил денег, отвалил".
Здесь необходимо рассматривать вопрос не о том как быстро написать приложение, а о том, как удобнее его потом будет поддерживать.
Да ещё и с постоянно меняющейся командой разработчиков.

У Java (и GWT как её части) тут большой положительный «опыт».
Это — enterprise технология по самой задумке.
И как бы там ни ругали Jav-у и java програмеров за их чрезвычайную приверженность к паттернам, — всё равно — когда я смотрю на java-код (паттерн), то я понимаю, что именно тут программист хотел сказать.

И когда попадается на глаза (да даже и своё! чё греха таить?!) какой-то разброс PHP-шных зарезервированных слов, гордо именуемый Скриптом, то обычно хватаешься за голову — такое поддерживать через полгода будет просто нереально.
Но просто написать — конечно! В разы быстрее. (на том же PHP)

Короче, хотел сказать — Лучше день потерять (много «лишнего» java-кода на GWT), а потом за 5 минут долететь (лёгкая поддержка кода, написанного «как пишут большие дяди»).

[vanxant]

Понимаете, Javascript не то чтобы прям развился, просто широкие массы его наконец-то поняли. Да, 99% того, что на нём пишут — это быдлокод, но это в любом языке так. Ну может на PHP процент чуть выше, в С++ чуть ниже, но сути это не меняет.
На Javascript можно и нужно писать хорошо поддерживаемый код. Ну да, в Javascript определение полей и функций класса перенесено в конструктор, поэтому на первый взгляд классов как таковых как бы и нет. И что? Это как-то мешает писать хороший поддерживаемый код? Исключительно дело привычки.

[xonix]

> Это как-то мешает писать хороший поддерживаемый код?

Имхо, мешает сама природа JS. Динамическая типизация вкупе с прототипным наследованием приводит к тому, что, смотря на функцию типа такой

funсtion my_cool_function(obj1, obj2) {
 if (do_smth(obj1)) {
   return obj2;
 } else {
   return smth_else(obj2);
 }
} 

я мало того что не могу сказать, что за объекты obj1 и obj2, так даже если начну отлаживать, то увижу объекты obj1 и obj2 просто как набор полей и значений, без малейшего намека на то, что за сущности стоят за объектами. В этом смысле даже PHP удобнее. Ситуация осложняется тем, что в разные времена obj1 и obj2 могут принимать совершенно разные типы а так-же против нас работает слабая типизация (это когда можно невозбранно складываешь яблоки с апельсинами числа со строками или чего похуже).

[vanxant]

Да, про числа со строками это пожалуй главный косяк javascript-а номер 2. Номер 1 — автоматическая расстановка; в конце текстовых строк.
Вообще в js косяков хватает, но их хватает в любом языке. В тех же плюсах есть очень заковыристые способы прострелить себе ногу, не смотря на всю типизацию.

[xonix]

> Вообще в js косяков хватает, но их хватает в любом языке.

Именно. Весь вопрос в их количественном измерении.

wtfjs.com/

[TheShock]

wtfjs — это пример дибилизма разработчиков, которые не хотят даже посмотреть в сторону документации:

— Оу я сегодня красила ногти в розовый цвет и программировал на JavaScript и хотел разбить строку из 6 символов на строки по два символа. Я нашла метод split, который переводится как «делить», я написала '123456'.split('2'), а оно мне выводит глупость какую-то! Этот JavaScript такооой слоооожный и тупооооой

Там есть откровенный бред:

Math.min() < Math.max(); // false

А чего оно вообще должно иметь другое значение? Вообще-то оно ведят себя строго согласно документации.

",,," == new Array(4); // true

0 == "0" // true, wtf!

var foo = [0];
console.log(foo == !foo);
console.log(foo == foo);

Эта фигня и фразы типа «Is it time to have a „maybe“ operator? :-P» меня вообще убивают. Оператор нестрогого сравнения — очень гибкая штука и он старается подстроится под программиста. Это просто инструмент, имеющий свои правила и люди, которые его критикуют — просто мудаки. Если вам нужно строгое сравнение — есть оператор "===". В чём проблема его использовать всегда и никогда не использовать "=="? В том, что нельзя будет сказать "Этот JavaScript такооой слоооожный и тупооооой"?

Its still hilarious. Now, check this out:

    3..toString();
    // "3"

Это что за хрень? Чего тут вообще неочевидного? Во что ещё должна приводится (3.0).toString()?

Я уж молчу про остальной бред типа:

 3 > 2 > 1 // false

parseInt('06'); // 6
parseInt('08'); // 0

NaN === NaN // false

Не позорьтесь — не давайте больше ссылку на этот сайт с высерами бреда и непрофессионализма.

[xonix]

Вопрос восприятия. Вы это воспринимаете как тупость разработчиков-неосиляторов, а многие, включая меня — как противоречивость, неоправданная переуложненность и WTF-нутость спецификации.

Вы кстати выбрали оттуда самые очевидные приколы, но там достаточно и настоящего WTF-a. Чего только стоит нетранзитивность и несимметричность ==. Вот в языке есть вредное в программировании больших систем (к ним можно отнести все современные JS-фреймворки) автоматическое приведение типов. И именно из-за него в языке есть и == и ===. Что стоит программисту по ошибке написать == вместо === и в одном случае из 100 будет баг. Кстати, это один из тех «врожденных пороков», которые, по мнению Google не исправимы эволюционным путем, для чего и городят с нуля новый язык Dart.

Почему-то Java, Python прекрасно обходятся без этих возможностей, а WTF-нутости в них заметно меньше.

> Не позорьтесь — не давайте больше ссылку на этот сайт с высерами бреда и непрофессионализма.

Не вижу ничего позорного. С моей точки зрения — отличный, познавательный, местами смешной сайт, вполне оправдывающий своё название, и иллюстрирующий, что JS в WTF-нутости (т.е. именно в WTF-нутости своей спецификации, к которой Вы аппелируете) местами даст фору тому-же Perl'у.
Заглянув в профиль, понимаю, что задел за живое, откуда и такая эмоциональная Ваша реакция. Но, поверьте, я тоже знаком с JS не по наслышке.

[TheShock]

На самом деле просто нужно понять, что "==" — это не тот же "==", что и в Java, вот и всё. Ситуация точно та же, что и с «3 > 2 > 1». Почему то считают, что JS должен себя вести как другие языки. А я вот долго программировал на Делфи и хочу, скажем, чтобы значение переменной присваивалось при помощи :=

var a := 123; // SyntaxError

Ой, какой плохой язык, у него оператор := работает неправильно, надо срочно запостить на wtfjs. Что стоит программисту по ошибке написать == вместо = и в одном случае из 100 будет баг.

Это глупо, не находите? Оператор критикуют не за его недостатки, а за то, что он не такой, как в Java, всё.

Пожалуйста, покажите настоящий wtf код с того сайта и обсудим его, потому что я ничего стоящего так и не нашёл. Там половина приколов — одинаковые приколы про "==", треть от оставшихся — приколы из-за стандарта «IEEE 754».

[xonix]

> Что стоит программисту по ошибке написать == вместо = и в одном случае из 100 будет баг.
Нифига, в этом случае баг будет воспроизводиться гораздо чаще. И хорошему компилятору в таком случае не мешало бы выдать warning.

> Там половина приколов — одинаковые приколы про "=="
Угу, они явно показывают, что неявное приведение типов — зло.

> Пожалуйста, покажите настоящий wtf код с того сайта и обсудим его
И Вы меня убедите, что JS все-таки хорош и удобен? Вряд ли получится…

[TheShock]

Неявное приведение типов, как и любой инструмент — зло в неумелых руках.
Нет, не буду убеждать. Мне просто интересно там увидеть реальный wtf код, а не фигню.

[xonix]

> Мне просто интересно там увидеть реальный wtf код, а не фигню.

Все примеры сайта wtfjs являются реальным wtf-ом, если под wtf-ом понимать несоотвествие принципу наименьшего удивления.

[TheShock]

«Принцип наименьшего удивления» не имеет единицы измерений и способа определения их значения, потому не больше, чем философские рассуждения. Меня вот в Java, например, может удивить, почему new Integer(500) != new Integer(500), а в языке с перезагрузкой операторов — наоборот. Всё зависит от того, то взять за точку отсчёта. И для JS почему-то берут Java.

[xonix]

В Java'е как раз очень просто, достаточно запомнить одно правило:

"==" сравнивает объекты по ссылке, .equals() — по содержанию.
Примитивные типы также сравниваются по "==".

Применяя эту логику для JS пытаемся написать правило

"===" сравнивает объекты по ссылке, "==" — по содержанию".

И получаем вагон приколов на wtfjs, когда нам надо в каждом конкретном случае напрягать мозг и думать что именно нам применить — == или === и не пролезет ли что то лишнее если оставим ==.

[Panya]

В JS тоже все просто, хочешь строгое сравнение используй ===, хочешь нестрогое (с приведением типов по правилам, описанным в спецификации) используй ==. Где wtf? На приведенном сайте есть совсем запредельные по своей тупости примеры, типа:

var a = {};
a == {} // false

var a = [];
a == [] // false

А что, простите, автор хотел получить сравнивая два разных объекта?

[TheShock]

Применяя эту логику для JS пытаемся написать правило

А вы не применяйте логику Java на JS, я об этом всю ветку стараюсь сказать.

[xonix]

Я лишь продемонстрировал Вам что

«Принцип наименьшего удивления» таки имеет единицы измерений и способы определения их значения.

Там где в Яве достаточно запомнить одно кондовое правило, в JS надо в голове иметь всю спецификацию описывающую == и ===.

[TheShock]

А почему я не могу в джаве передать метод в качестве параметра? Как-то так:

uiWidget.onclick( element.run );

Или, хотя-бы, так:

uiWidget.onclick( element.run.bind( element ) );

В javascript это сделать достаточно просто (необходимо лишь помнить про корректный this), а в Java надо в голове иметь всю спецификацию описывающую событийную модель

final element // bla-bla
button.addEventListener(
  new MouseAdapter() { 
    public void onClick() {
       element.run();
    }
  }
)

Тут надо и про final помнить и кучу кода писать. Так кто более wtf?

Ещё раз говорю — "==" ничего не имеет общего с "==" из Java.
"==" это "===" в Java.
".equals()" это ".equals()" в Java.

Например, LibCanvas:

var p1 = new Point( 5, 8 );
var p2 = new Point( 5, 8 );

p1 ==  p2; // false
p1 === p2; // false
p1.equals( p2 ); // true

"==" — это синтаксический сахар JS, которого в Java просто нету. Отсюда и все ваши WTF

[xonix]

> а в Java надо в голове иметь всю спецификацию описывающую событийную модель

Никакой спецификации событийной модели в языке нету, это Вам не C# с его делегатами. В Java — обычные старые классы и их композиция.

> про final помнить

Не надо помнить совершенно. Если забудете — компилятор всяко не скомпилит и укажет на ошибку.

> и кучу кода писать

Не проблема, при хорошей IDE, которая пишет за вас 80% кода. Более того, для JS умная IDE (в той же степени как для явы) как раз не возможна из-за природы языка.

> "==" — это синтаксический сахар JS, которого в Java просто нету. Отсюда и все ваши WTF

Ну я примерно то же и пытался сказать. Только вижу в этом не плюс (дополнительный синтаксический сахар) а минус (вредная возможность неявного приведения типов и все неочевидности, с этим связанные).

[TheShock]

Не умеете пользоваться сахаром — не пользуйтесь. Мне (и не только мне) он — очень удобен. Дополнительный сахар — это хорошо. Даже не смотря на то, что её нету в Java.

[xonix]

> Не умеете пользоваться сахаром — ...

Скорее не «не умею» а «не хочу».

>… — не пользуйтесь.

С радостью бы, да, к сожалению, не выходит, именно из-за:

> Мне (и не только мне) он — очень удобен. Дополнительный сахар — это хорошо.

Миллионы людей им уже пользуются и от этого не уйти. Многим нравится синтаксический сахар Perl. Он им просто нравится. Им нравится проявлять творчество и рождать шедевры типа таких

www.cpan.org/misc/japh
ru.wikipedia.org/wiki/JAPH.

А какая радость дорабатывать и поддерживать проекты, в которые сии гении излили чуточку своего божественного творчества, аж дух захватывает от избытка положительных эмоций, и чувства уважения к авторам сих прекрасных строк, ставших возможными благодаря уникальным по своему удобству дополнительным возможностям, заложенным в язык.

Но самый прикол-то в том, что они-то как раз не виноваты. Они просто используют инструмент. Виноват именно язык, в котором не заложено достаточно дисциплины для написания более сурового, надежного и удобного в доработке кода.

Потому Google и хочет выкинуть JS и начать с чистого листа.

[dikarik]

Именно. система типов — это, кроме всего прочего, ещё и документация.

[nicity]

Дарт имеет большие шансы заменить GWT

[aspect]

Истину вам говорю: в день великомученника Стефана, Земля налетит на небесную ось!

[remal]

Данная статья — классический пример непонимания автором используемой технологии. И то как ее заплюсовали лишь говорит о том, насколько народ не в теме.

На GWT можно писать простенькие «скрипты». Правда вопрос — зачем? Но там на сложность генерируемого DOM наплевать. Объемы не те.

В остальном же GWT — для сложных RIA приложений. И требуется хорошее понимание соответствующих паттернов иначе набыдлокодить очень-очень легко. Вам надо вешать onclick через JSNI? — Это не GWT-way. Вам надо генерить кучу своего HTML? — Возможно, и тут вы просто неправильно используете эту библиотеку.

Минусов в GWT хватает. И сложность разработки на нем очень высока (не надо заниматься самообманом). Но ничего из приведенного в статье, фактически, не является минусами GWT. Ну или, как минимум, в данных версиях *уже* не является. Более подробно расписали выше. И хотя мне есть что добавить, смысла в этом не вижу.

[vanxant]

Да что ж вы все к onclick-у привязались то. Это простейший пример, чтобы объяснить суть проблемы связи с внешним js. Ну пусть этот клик будет брошен не статическим HTML-элементом, а скажем Google Maps-ами или еще каким-нибудь сторонним js API, аналогов которому в GWT нет. Что, писать свои карты, потому как гугловские по плохим паттернам сделаны? Бред же.

И оставьте уже эту ерунду про RIA. Если для helloworld нужно написать 100 строк кода, то в большом приложении будет полный завал. Ну не бывает по-другому. Как выше заметили, в Java есть плюшки, действительно помогающие в больших проектах, тот же JUnit и внешние тулзы для контроля качества кода, но к GWT они никаким боком не относятся.

[remal]

Есть официальные (в смысле сделанные ребятами из Гугла) google maps api для GWT (правда карты там версии 2). Все прекрасно работает. И код там вполне себе нормальный без диких извратов.

Я и сам писал обертку для гугловых карт. Правда бросил, ибо долго. Но ничего сложно в ее написании нет. Тупо время надо потратить. Причем на тупой копипаст.

Hello world можно написать быстро и просто. Не надо тут. 1 xml + 1 класс. Причем все это при желании генерится соответствующими визардами в IDE.

А по поводу RIA — это далеко не ерунда. Не просто так в GWT применяется не MVC, а MVP. Поднять каркас сложного приложения на GWT без опыта долго. Надо курить кучу мануалов, всяких best practice'ов, смотреть видео с конференций и т.п. Именно поэтому я и написал, что использование GWT не является простым и не надо его воспринимать как простой фреймворк. Но подняв этот самый грамотно настроенный каркас, приложение пишется сравнительно быстро и просто. При этом все хорошо отлаживается и тестируется.

И да, если попытаться построить приложение на основе hello world'a, получится хрень. Сам я с такой проблемой сталкивался и приходилось долго и нужно все рефакторить, а то и переписывать с нуля.

GWT построено вокруг определенных шаблонов. Как с точки зрения кода, так и мышления. Если вы «в теме», то все будет норм. Хотя, понятное дело, GWT серебренной пулей не является. Если вы пытаетесь писать «по-своему», то, возможно, столкнетесь с кучей неудобств. Но это совершенно нормальная ситуация для любого сложного фреймворка.

Исходя из тех аргументов, что вы приводите, лично мне видится, что вы, не изучив толком технологию, попытались сразу написать серьезный проект. И столкнулись с трудностями изучения. Хотя, насколько я понимаю, дело было 5 и более лет назад и тогда GWT мог быть куда хуже. Но мне с трудом верится, например, что тогда были проблемы с тем же вызовом Java из JS через JSNI. Или что так геморно повесить обработчик события.

ЗЫ: И, да, JUnit вполне относится к GWT. Может, вы просто не умеете его готовить?

 

Сейчас лично мне *сейчас* совершенно пофиг на Dart. Влетит, не влетит — я, что, — Ванга? Пусть в Гугле доделают его до внятного состояния, пусть потом он пройдет испытание несколькими серьезными проектами вне Гугла. А только потом можно говорить имеет этот язык какие-либо перспективы или нет.

У Гугла есть ресурсы, чтобы написать свой язык и продвигать его. Отлично. Даже если их попытки провалятся, из этого можно будет сделать полезные выводы. Как в плане стратегии, так и в плане языка — почерпнуть что-то интересное для реализации во фреймворках, к примеру.

Собственно на данный момент, имхо, на этом все разговоры про Dart, пока вы не написали на нем ни одного проекта, можно закончить.

Это по поводу языка. По поводу же ваших статей. Что этой, что «части 1». В обоих аргументация нулевая. В первой части человек явно какой-то фанатик, который не способен воспринимать чужую точку зрения, а в этой — незнание технологии и, следовательно, ошибочный вывод.

[vanxant]

Да, мне действительно пришлось пять лет назад писать сразу серьезный проект на GWT, и да тогда действительно под GWT не было очень многих плюшек (и кстати сейчас тоже очень и очень многого нет). Проект в итоге трижды серьезно рефакторился, практически переписывался с нуля под свежие версии GWT, с добавлением новых фишек и технологий. Да, GWT развивался, но слишком медленно, многие серьезные баги висят годами, очень и очень многого там нет.
Понимаете, я ведь не с улицы пришел, до GWT я участвовал в больших и очень больших проектах в том числе на Java и методологией, паттернами и прочим в целом очень даже владел. Ну знаете, если библиотека нормально принимает только свою родную реализацию MVP, которую допилили-то буквально совсем недавно, а со всеми остальными получается очень медленная скорость разработки — ну извините, это плохая, негодная технология.
В итоге я пришел к выводу, что дело тут не в MVP/MVC и даже не в GWT, а в классической ООП парадигме как таковой. Она не очень применима в веб-приложениях, особенно в больших. Вот и всё.
Я очень хотел бы услышать тут разработчиков ну пусть не AdWords-а, но хотя бы Одноклассников или там Evernote, вот к их словам я бы прислушался.
А так ваши комментарии это зашкаливающее ЧСВ и слепая вера в Святые Паттерны, не более.

[poltora]

Хороший камент, подписываюсь под каждым абзацем.

Вдогонку оппонентам — gwt/java/OOP/паттерны — эти фреймворки/технологии/платформы/парадигмы/идеологии требуют больший уровень для входа в тему.

Смотрите правде в глаза — если нехватает знаний — учитесь.
Нехватает ума для учебы — смиритесь и занимайтесь кодингом на быдлоязыках.

Но поливать грязью то, в чем не разобрались, или не захотели, или не смогли — не нужно. Это лишь выдает ваш уровень стремления к саморазвитию как профессионала (о боже, вы ж еще и деньги за это получаете).

[poltora]

походу у кого-то баттхёрт от моих каментов.

[poltora]

И оставьте уже эту ерунду про RIA. Если для helloworld нужно написать 100 строк кода, то в большом приложении будет полный завал. Ну не бывает по-другому.

Вы заблуждаетесь настолько глубоко, что даже заблуждаетесь насчет глубины своего заблуждения.

Ну нельзя измерять возможности и область применения инструментов по одному синтетическому примеру «хеловорлда».

Да один факт, что его используют в качестве измерения уже говорит об отсутвии опыта измерителя — о том, что его самый большой проект не далеко ушел от хеловорлда. (я, конечно, тут немного утрирую насчет опыта, но не очень сильно).

Это как крики, что лучшая IDE — это блокнот/vim.
Сразу видно об уровнях «проектов» таких блокнотеров/vim-еров.

Так и в случае с хеловорлодом.

Вы пойдите еще к разработчикам системы безопасности АЭС и скажите, что ваша разработка на [язык+технологии] говно, потому как хеловорлд занимает неприлично много строк, по сравнению с вашим любимым [быдло-языке].

[poltora]

что-то цитирование не сработало…
первый абзац — цитата.

[vanxant]

На моём любимом «быдло-языке» Си (никто правда до вас не называл его «быдло») хелловорлд занимает одну строку.
И я абсолютно уверен, что именно на нём (ну максимум на плюсах) написаны системы безопасности АЭС и прочие важные штуки. Просто потому, что Java и прочие managed-языки не годятся для систем реального времени. Точка.

[poltora]

согласен, насчет реального времени, хотя споры не утихают и есть движения насчет этого.

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

но возьмем более реальный пример — банкинг или трейдинг.

[poltora]

и я не приравнивал Си к быдло языкам :)
из контекста вших каментов нельзя было сделать вывод, какой ваш любимый язык.

[siasia]

Не могу понять, почему все так любят обливать грязью новые непонятные им технологии. Мне, например, очень хотелось бы порядка в Javascript'е. И Dart на мой взгляд неплохая замена тому же Coffeescript'у. Но как бы я не ненавидел Javascript с его спагетти обратного вызова, я не пойду и не буду писать статьи с тоннами ненависти. Вопрос: зачем?

[vanxant]

Люди хотят грязи (с) :)

[9mm]

Слишком много далеко идущих обобщений, все равно что утверждать: 'затея Ferrari выпустить машину красного цвета кажется безумной — АвтоВАЗ тоже выпускал машины красного цвета и мы все знаем что из этого получилось.'.

Во-первых, странным выглядит сравнение нового языка и старого фреймворка, только на том основании что этот фреймворк тоже использовал один (но, sic! Промежуточный) язык.
Цель дарта, в первую очередь, создать быстрый и удобный в коллективной разработке язык для браузера. Задача оправдана, потому что js a) медленный (и не может быть не медленным) б) не удобен в коллективной разработке (потому что нет никакой возможности указать другим программистам как использовать твой код).Поддерживка северной версии это бонус который удешевляет разработку (с меньшей вероятностью придется искать программиста знающего язык X). Обращаю внимание — это бонус, а не стремление пересадить всех на один язык — если вы понимаете что для вашей задачи на сервере лучше использовать ruby никто не запретит его использовать.

Еще одно замечание насчет скорости: выше более или менее справедливо замечали что самое тормозное это все равно работа с Dom-деревом. Это так потому что никто не осмеливается писать вещи которые будут тормозить и без дом'а. Например модный сейчас canvas ограничен только своим API, т.е. Вы можете менять его содержимое попиксельно, но никто в зравом уме делать этого не будет — медленно.

[vanxant]

Я не думаю, что какой-либо мифический язык, будь он хоть трижды типизирован, способен радикально улучшить обход DOM дерева, а как вы сами сказали, в вебе это основное.
Поэтому все рассуждения про «быструю замену JS», которая бы быстро выполнялась, это ерунда.

Вопрос в скорости разработки больших веб-приложений. Но вот тут, раз уж скорость исполнения некритична, утиная типизация имеет преимущество. Статическая типизация требует написания большого количества технического кода — объявлений классов, интерфейсов, абстракций и прочего, прочего, но позволяет отловить не так уж много ошибок. Если вы попытаетесь передать в функцию аргумент не того типа, что в Dart, что в Javascript вы скорее всего получите ошибку и всё сразу обнаружите. А вот если у вас есть две переменных одного типа, a и b, и вы вместо a случайно передали b, то никакая типизация отловить эту ошибку вам не поможет. А вот кода для статической типизации придется понаписать намного больше.

[9mm]

Утиная и статическая типизации это не антонимы. Язык может поддерживать и статическую и утиную типизации (например go). Я говорил о статической типизации в противовес динамической. Безусловно в языке для веба должен быть тип 'variant' который может хранить что угодно, но в большинстве случаев удобнее понимать с каким типом мы оперируем, чтобы фрукты на слово 'х@у' не умножать.

По поводу скорости я писал выше. Помниться здесь прискакивала статья про порфирование эмулятора x86 на js, там как раз использовалось расширение js — typed array, без которого не то чтобы невозможно было такое написать, но это просто не работало бы с приемлемой скоростью.

[dikarik]

Обход DOM-дерева — это основное в «эффектах на страничке», но никак не в полноценных приложениях, которые бы заменили десктопные. А как раз там javascript и неудобен — когда нужно держать и обрабатывать (кодом, который писали разные люди!) какие-то сложные модели данных, выполнять «тяжелую» алгоритмику. Мои любимые примеры — шифрование и обработка графики, которую запросто можно выводить на canvas, но вот сделать фотошопообразные обработки на JS — нет уж, спасибо.

[vanxant]

Фотошоп на js в браузере? Нет, спасибо.
А вот во всяких социальных и «офисных» приложениях основное как раз DOM. Тяжелые алгоритмы там если и есть, то они всё равно крутятся на сервере.

[dikarik]

Спасибо или не спасибо — а тренд именно таков, и гугл совершенно закономерно к этому готовится.

[vanxant]

Фотошоп на js в браузере? Нет, спасибо.
А вот во всяких социальных и «офисных» приложениях основное как раз DOM. Тяжелые алгоритмы там если и есть, то они всё равно крутятся на сервере.

[vanxant]

Фотошоп на js в браузере? Нет, спасибо.
А вот во всяких социальных и «офисных» приложениях основное как раз DOM. Тяжелые алгоритмы там если и есть, то они всё равно крутятся на сервере.

[JaoDa]

JS очень дешев в быстрой разработке, но неимоверно дорог в дальнейшей поддержке и маштабировании.

[supermega]

Я был на конференции от гугла про оптимизацию javascript Google Chrome. Там говорили, что в процессе оптимизации они делают фейковые классы, в которые преобразовывают javascript-код. Я забыл как именно это помогает ускорению, но это есть по факту.
Что касается преимуществ объектной модели javascript перед другими: я в целом согласен, но есть одно но. Простому программисту трудно писать код в таком стиле, с классами тупо ПРОЩЕ разобраться. А как показывает практика более простые для понимания языки вытесняют более сложные. Например, php вытеснил perl из веба.

[127]

groups.google.com/a/dartlang.org/group/misc/browse_thread/thread/61e61c455902ae7b/72ab4db3ad02bd1b#72ab4db3ad02bd1b

[Lokken]

Кстати, в Windows 8 Javascript станет одним из официально-поддерживаемых языков разработки приложений в новом стиле Metro. Очевидно, что Microsoft видит будущее за JS и уж точно не будет способствовать продвижению альтернативных языков, вроде Dart.

[crocodile2u]

Хозяйке на заметку: типизация в Дарт — это всего лишь фишка в помощь разработчику. Даже если вместо ожидаемого Integer в переменной будет что угодно другое — все продолжит работать (правда временами, очевидно, неизвестно, к чему эта работа приведет).

[Begetan]

Вот за это автору отдельное спасибо:

Я четыре года писал на GWT, и я могу уверенно сказать, что для веба утиная типизация лучше статической. И влияет оно только на скорость компиляции, а не на скорость исполнения кода.

Изучая различные web подделки я раньше не мог понять одну вещь — зачем люди делают, обертки, кучу классов внутри которых куча методов вида:

 function add_element( $e )
        {
                $this->elements[] = $e;
        }

        function set_x_legend( $x )
        {
                $this->x_legend = $x;
        }

        function set_y_legend( $y )
        {
                $this->y_legend = $y;
        }

        function set_bg_colour( $colour )
        {
                $this->bg_colour = $colour;
        }

Потом эти методы мучительно инициализируются конструкциями вида:

$chart->add_element( $line_out );
$chart->add_element( $line_in );
$chart->set_x_axis( $x );
$chart->set_y_axis( $y );

Почему нельзя тупо сделать?
$chart_settings = array(array("$line_out","$line_in"), $x,$y,… bla bla");

Или еще тупей просто подключить библиотеку и вызывать просто функцию с просто аргументами?

Думал я об этом и чувствовал себя недалеким быдлокодером, который просто еще не понимает великой идеи мировой революции :)

И тут впервые сказано — оказывается ИНОГДА можно употреблять процедурный подход! За эту смелую, яркую и сверкающую удивительной новизной идею готов аплодировать стоя как настоящий быдлокодер!

[remal]

Не просто так есть термин «ООП головного мозга». Если вы пишите API, которым будут пользоваться другие разработчики, соизвольте писать наиболее качественный код. Если вам надо написать маленький скриптик, то нафиг не надо плодить кучу кода. Голова на плечах всегда должна оставаться…

[vanxant]

Не понимаю, к чему ваш комментарий.
В вебе вместо 20 функций set_param_1, set_option_2 вы, благодаря утиной типизации, имеете единый вызов do_what_i_say ( { param1: blabla, option2: «bloblo» } )

[remal]

Причем тут какая-либо типизация? Написать такую функцию вам никогда ничего не мешает. Но далеко не всегда это будет оправдано и лучше стандартных setter'ов.

[vanxant]

В GWT (ок, в Java и других языках со строго статической типизацией) вы такую функцию не сделаете.

[remal]

Вы перед тем как неправду писать, лучше бы выучили обсуждаемую Java. Заодно бы и по-другому стали смотреть на привычные с точки зрения PHP/JS проблемы.

[vanxant]

Ну-ну. Попробуйте написать на Java аналог функции $ из Jquery. Не по имплементации — просто по параметрам и их вариантам.

[aspect]

Что-то мне подсказывает, что такая перегруженность не от хорошей жизни.

[vanxant]

Дело привычки и парадигмы программирования, не более того.
Объект google maps ничуть не проще, но это никого не смущает.

[aspect]

Я не говорю, что это плохо. В Жабе можно написать функцию, которая будет принимать строку селектора; и будет точно такой же километровый свич с пятью уровнями вложенности. Но зачем, если под рукой типы и перегрузка?

[xonix]

А в чем проблема с этим? Overloading методов же есть.

[remal]

И что в этом сложного-то? Нет, серьезно? Более того, я в кишки jquery заглядывал. По сути, код даже и отличаться будет очень-очень мало. И уж, поверье, документировать его и использовать будет намного проще.

 

Я могу сходу назвать только одну область, где проигрывают языки со статической типизацией — обработка JSON. И то, если забыть о том, что JSON полученный из внешних источников может отличаться от ожидаемого. Если поднапрячься, еще пару областей, думаю, можно будет придумать. Все. Во всех остальных моментах статическая типизация выигрывает. Ибо:
— Код становится чище и лучше
— Очень многие ошибки отлавливаются на этапе компиляции (!!!)
— Упрощается поддержка
— Намного проще рефакторить и тем более используя средства IDE
— Производительность (хотя в данном обсуждении это не важно)

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

Хватит быть быдлокодером, знающим только 1 язык. Начните изучать новое. Хотя бы для себя. В конце-концов, это сильно повышает квалификацию. А то как-то странно выглядит, когда человек совершенно не знающий темы обсуждения, пытается что-то доказывать.

 

Ниже вы пишите «если нормально освоить базу, вы будете писать хороший код на любом языке, но основы объектной модели языка знать всё же нужно». Это не так. В абсолютном большинстве случаев в современном программировании важен опыт работы и знание платформы/фреймворков. Ибо теория без практики — ничто.

Да, и плюс той же Java в том, что, используя ее, намного проще увидеть проблемные места в коде. Там где в PHP или в том же JS руки почти на автомате делают глобальную переменную (например), в Java 10 раз подумаешь как организовать зависимость классов, чтобы на быдлокод похоже не было. Не знаю почему так. Да и не задумывался. Но сам язык, тенденции написания на нем, фреймворки и т.п. заставляют думать над собственным кодом.

[aspect]

для JSON есть уже упомянутый GSON, который прекрасно парсит POJO -> JSON и с некоторымы ограничениями на коллекции в обратную сторону

[vanxant]

Я пишу программы вот уже 18 лет как, и за это время достаточно навидался таких вот «труЪ хакеров», которые 2+2 не знают как правильно сложить, но нахватались модных в этом сезоне практик и суют их везде где можно. Да, знание библиотек и фреймворков безусловно важно, но понимания сути алгоритмов оно не заменит.

Впрочем, не хочу дальше кормить троллей.

«Я уверен, что парадигма ООП методологически неверна. Именно поэтому в ООП так популярен рефакторинг – из-за ущербности парадигмы вы просто обречены на переписывание программы, уже в тот самый момент, когда только задумали её спроектировать в ООП-стиле».

Предыдущий абзац написал Александр Степанов, отец стандартной библиотеки C++ и концепции обобщенного программирования. На этом разрешите откланяться.

[remal]

А по сути вам есть что ответить?

Можете заодно описать альтернативы ООП. В современном мире, безусловно. Мне вот очень интересно что бы ответил Александр на довод, что популярность рефакторинга обусловлена прежде всего изменяющимися условиями задачи и тем, что люди несовершенны и все ошибаются.

Я тоже в программировании далеко не год, не два и даже не пять. И тоже успел поведать много кого и много чего. И что, вместо обсуждения по сути будем сравнивать кто что повидал?

[vanxant]

Не лень писать-то было? За такой java-класс в реальном проекте заклюют:)

[vimvim]

ля начала я думаю что нужно четко понять что же представляет из себя GWT.
— Java -> JavaScript компилятор
— JRE emulation library
— GWT library

То есть использование UI компонентов из стандартной бибилиотеки не является обязательным.

Хочу привести один из ярких примеров использования GWT — AngryBirds
( chrome.google.com/webstore/detail/aknpkdffaafgjchaibgeefbgmgeghloj )

Да, тот AngryBirds который есть в Google Chrome Store создан именно с использованием GWT.
Можете попробовать поставить его ( он бесплатен ) и оценить интерфейс и скорость работы.

Вот тут есть подробнее про его портирование ( code.google.com/webtoolkit/casestudies/index.html )

Теперь насчет проблем о которых вы говорите.

Махровая табличная верстка
Никто не заставляет использовать стандартные
визуальные компоненты включенные в бибилиотеку. Достаточно легко реализовать свои компоненты
которые будут создавать DOM элементы в соотвествии с нужной логикой и используя нужную верстку.

Медленная работа готового GWT проекта
Целиком зависит только от архитектуры приложения.
У нас есть достаточно большой проект который вполне шустро работает.

Использование собственного сверстанного HTML
Легко. Более того Вы можете использовать для мелких компонентов например
jQuery plugins а более серьезную логику вынести в Java. И при этом обеспечить нормальное взаимодействие
JavaScript и Java классов. И все это без использование готовых UI компонентов из GWT бибилиотеки.

У нас например в проекте используется ExtJS. То есть всеми визуальными компонентами управляет
нативный JavaScript а вся комплексная логика реализована в GWT. И все это прекрасно работает
и самое главное обеспечивает легкую поддержку и расширение функционала.

Вот пример того как это выглядит:
boldendeavours.com/gwt-user-interface-demo.html

ООП и JavaScript
Основа ООП это в первую очередь понятие объекта как сущности которая владеет своими данными
и методами.

И использование динамической типизации не означает что язык не ООП. Например, никому не
придет в голову сказать что Python не является ООП языком.

А в JavaScript таки есть классы только названы они прототипы и ведут себя
местами не так как привычно, но суть от этого не меняется.

Теперь то что касается веба.
Да, у Вас может быть только одна форма конкретного типа на странице, но как ни странно
у этой формы могут быть данные и методы для работы с ними. Например валидация полей, реакция
на изменение значений ( какие-то поля показать/скрыть,… ), дополнительные функции инициализации,…
То есть эту форму вообщем-то очень логично представлять себе как единый объект а не как
десяток JavaScript функций и переменных раскиданных по всему коду.

И вернемся к Вашему примеру насчет кнопки «бабло».
Допустим у Вас создается кнопка «СуперБабло» ( это та которая с перламутровыми )
из прототипа кнопки «бабло». И все работает замечательно.
А теперь представим что через полгода в проект пришел Вася и сделал из кнопки «бабло»
checkbox. И все будет прекрасно до момента тестирования когда выяснится
что «СуперБабло» работать перестало.
При разработке на GWT Вася сразу заметит что от «бабла» зависит «СуперБабло» и
задумается так ли ему нужен этоn checkbox.

Таким образом мы переходим к следующему пункту.

Удобство утиной типизации
Да, удобно на этапе создания пртотипа или на начальном этапе разработки. Дальше хуже.
Вы пробовали например отлаживать большое JavaScript приложение? Нет, не пару функций для
формы а скажем строк на 5000.

Первые выявляемые ошибки — опечатки в именах функций/переменных, несоотвествия в вызовах и пр…
При программировании на GWT эти ошибки будут выявлены и исправлены еще до начала отладки.

Поддержка и расширение большого JavaScript проекта это вообще отдельная тема ( см выше пример про «бабло» )

GWT это однозначно серьезный и полезный продукт. Но у него достаточно высок порог вхождения.
Я не думаю что он найдет широкое применение при разработке простых вебсайтов,
но когда речь заходит о комплексном UI работающем в браузере — тут GWT нет равных альтернатив.

[vanxant]

В любом языке есть много способов отстрелить себе ногу. Особенно если к коду пустили ламера Васю, который даже не удосужился проверить зависимости перед рефакторингом.
Да, некоторый процент самоубийственных действий статическая типизация действительно позволяет отловить. Но она же требует от программистов написания огромного количества кода, который ничего не делает. Описания классов, интерфейсы, IoC и прочая лабуда — все это требует времени, и немалого. Конкретно для веба это не оправданно.
В чем прелесть веб-приложений — они (пока что) заставляют серьезно задуматься над интерфейсом и вообще над набором функционала. Монстры типа MS Word, в котором рядовые пользователи используют 3% функций, остались на десктопе. И это здорово.

[vimvim]

Дело в том что то время и усилия которые экономятся на создании «лабуды» с лихвой растрачивается на этапе анализа зависимостей при любом изменении и на этапе тестирования/отладки.
И причем с ростом проекта сэкономленное время очень быстро перестанет окупаться.

[vanxant]

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

[vimvim]

Хмм, ну как-то Вы совсем уж не хорошо про Фаулера…
А какие книги можете порекоммендовать Вы? Учитывая что Вы негативно относитесь к применению ООП
при веб разработке было бы очень интересно узнать каким методологиям Вы отдаете предпочтение.

[vanxant]

Не хотел никого задеть, но Фаулер действительно «бродячий консультант» — в штатах это очень уважаемая профессия. Он ходит по разным фирмам, у которых завалы с софтверными проектами, и объясняет им почему они лузеры и как перестать ими быть.

Для прочистки мозгов от ООП-пелены можно полистать:
1. для начала доклад инженеров тети Сони Pitfalls of OOP (GCAP 09) — там небольшая презентация,
2. затем попытаться осилить Александреску «Современное проектирование»,
3. затем Alexander Stepanov, Paul McJones «Elements of Programming». Степанов — это автор стандартной библиотеки Си++, в которой классическое ООП практически не используется, и ярый противник этого самого ООП. При желании с ним можно даже пообщаться, например не так давно он читал лекции в Яндексе.

На втором этапе нужно изучить классическую Computer Science. Это в первую очередь Кнут с его «Искусством программирования», затем Кормен, Лейзерсон, Ривест, Штайн «Алгоритмы: построение и анализ», плюс любой толковый учебник по реляционной алгебре.

Если нормально освоить базу, вы будете писать хороший код на любом языке, но основы объектной модели языка знать всё же нужно. Для js на сегодня это, разумеется, Флэнаган — «Javascript. Подробное руководство».

[ttim]

А в javascript вы не пишете документацию к функциям с набором входных параметров и их типами?
Вот пусть лучше такие вещи будут в самом коде.

[Kaaboeld]

Проект, один js более 14000 строк не считая, библиотек, периодические делается рефакторинг чем постоянно уменьшаем количество кода и субъективно улучшаем его качество… Проблемы с отладкой, есть, но они на «настолько значительны» чтобы отказаться от js->jquery в пользу того же gwt который рассматривался на первом этапе как один из вариантов для клиентского приложения. Сейчас оптимизируем подходы к коллективной разработке, да она в js далека от совершенства…

[TheShock]

Angry Birds работает быстро за счёт кучи специфического для Chrome кода и полного отсутствия кроссбраузерности.

[aspect]

>А всё из-за статической типизации, которая не позволяет просто так использовать вместо «просто кнопки» «кнопку с перламутром».

И давно?

class PearlButton extends Button{
…
}

можно еще проще:

Button x = new Button(){
…
};

[vanxant]

Наследующиеся друг от друга конкретные классы? Ну-ну. Почитайте литературу.

[vimvim]

Я думаю что во втором случае автор имел в виду использование анонимного класса с кустомизацией его поведения. Вполне себе нормальное решение.

[aspect]

1. И что такого?
2. Что же мне почитать, о ненавистник энтерпрайза?
to vimvim: Второй пример, кстати, я впервые увидел в Ваадине, для небольшой кастомизации поведения по месту.

[vanxant]

Мне как «о ненавистнику энтерпрайза» конечно не пристало учить юных подаванов чужой веры основам их же религии, но всё же: в случае наследования конкретных классов возможны очень плохо отлавливаемые ошибки, связанные с потерей данных при неявном приведении к базовому типу где-нибудь в сторонних функциях, которые про класс-потомок вообще не слышали.
Про почитать ответил vimvim-у выше.

[aspect]

Ты сказал «нельзя использовать вместо одного другое», тут выясняется, что это можно, но неправильно. Ок, выше иерархией есть abstract ButtonBase.
А вообще хочется примера, что-то мне подсказывает что он будет противоречить второй и третьей букве в SOLID.

[vanxant]

Проблемы возникнут, если где-то почему-то потребуется сделать копию объекта. Ну вот бывают такие алгоритмы, в которых без копии никак. Именно поэтому принцип Лисков как раз и запрещает в большинстве случаев наследовать конкретные классы.

[aspect]

Что мешает переопределить метод clone если мы вдруг поняли что нам нужно клонировать объект, а не просто привести ссылку к родидельскому типу и/или скопировать ссылку на объект?

[Ganesh]

В первой части говорилось о каком-то мифическом рефакторинге JSа в современных IDE. Который на деле достаточно скуден и крив, даже в WebStorm, про eclipse вообще можно не говорить. Про автодополнение тоже можно не говорить, оно если и есть то предлагает выбор не для конкретной ситуации, а из всего найденного скопа данных.
Тут так вообще сравнивается жопа с пальцем — целый язык и фрэймворк. Я не верю в С++, потому что GWT гавно.

[alist]

Автокомплит призван решить две задачи.

1. Защита от опечаток.
2. Знакомство с API — посмотреть, что умеет тот или иной объект.

Для первой задачи в целом может хватать простого поиска токенов по файлу, или по файлам проекта. Причем, такой автокомплит есть даже в обычных текстовых редакторах вроде Notepad++ или SublimeText. Работает на ура и в случае с JavaScript позволяет избавляться от TypeError-ошибок. По своему опыту могу сказать, что без автодополнения риск опечататься выше, а дебаг таких ошибок бывает нетривиальным. Но с другой стороны, простое деревянное автодополнение по токенам хватает за глаза.

Что дает IDE, так это именно семантическую контекстную автоподстановку. Такая подстановка преследует и цель 1, и цель 2. Тут вы правы, даже WebStorm не отрабатывает на 100%, поэтому не всегда можно получить представление о возможностях того или иного объекта. С другой стороны, это дело наживное — со временем часто используемые вызовы запоминаются. Тут особенно важное значение имеет наличие документации или каких-то других источников, из которых я смог бы узнать о свойствах и методах объекта.

На опыте своего проекта, который уже перевалил за несколько тысяч строк своего кода и тянет за собой с десяток внешних библиотек, могу сказать, что как и во многом другом, здесь работает правило 20/80. 80% эффекта можно добиться с помощью простой автоподстановки по токенам. Также со временем этот процент растет, т.к. разработчик постепенно знакомится с предоставленным ему API. Так что тут не все так плохо, как вам кажется.

Рефакторинг, да, совершенно не автоматизирован — все, что можно получить автоматически — это простое переименование. Что-то посерьезнее, вроде переноса методов из одного скоупа в другой или смена сигнатуры вызова, приходится делать руками. Не могу сказать, что это так уж сложно.

Начнем с того, что Java — не самый удобный язык для рефакторинга. Банальный пример: чтобы переименовать класс, требуется изменить имя файла, а также пробежаться по всем местам, где используется этот класс. Такой сценарий напрочь в JavaScript отсутствует — нет классов и нет строгой привязки компонентов к файлам. Переименование методов и полей достигается через Find/Replace. Что-то посерьезнее требует такой же механической работы.

С одной стороны — жутко неудобно, а с другой — дисциплинирует. На Java я могу немного покопипастить и решить, что пока можно оставить и так. Затем я что-то рефакторю и IDE автоматически применяет изменения ко всем копиям фрагмента кода. В Джаваскрипте же мне придется делать это руками, поэтому я почем зря копипастить не буду — мне же потом лишнюю работу делать. У нас на клиентской стороне код никогда не повторяется — чуть что-то одинаковое — сразу выносим в отдельные функции или объекты.

[asm0dey]

Я благодаря автокомплиту пишу, наверное, в два раза быстрее. Пара первых букв — таб. Пара первых букв — таб. Сниппет — контол+пробел.

[alist]

А я вам говорю, что есть два вида автокомплита — и тот, который работает по токенам, на практике тоже работает весьма неплохо. Думаете, я в блокноте Ctrl+Пробелом не пользуюсь? То же самое — буква-буква-бах! буква-буква-бах! Сниплеты во всех уважающих себя редакторах тоже есть:

fu — Ctrl-Space -> function -> tab -> тело функции с курсором на параметрах.

[asm0dey]

Я вообще-то на джаве пишу. И ни разу не видел хорошего автокомплита, основанного на токенах.
Как можно подхватить токены из библиотек, например?

[vajadhava]

GWT не тру, Dart делают те же парни — значит Dart не тру?

Сравнение аналогией по команде, концепции. После прочтения прямо таки хочется подобным образом сравнивать например Win95 и Win7 по тем же параметрам :)
Не находите что это все же два разных продукта, да и выпущены они в совершенно разные по меркам IT эпохи? Может быть все же что-то за это время изменилось?

По тексту не нашел минусов конкретно Dart-а, поэтому так и не понял почему вы поставили на нем жирный крест.