Да-да, я озвучивал мысль, что, если бы Глонас был один, Квалком, может и не позарился на него, а раз уж потом еще альтернативы ожидаются, то они решили резину не тянуть, а начинать разработку уже сейчас.
Ну, насколько я знаю, из крупных производителей чипов только Qualcomm заявил о своем намерении включить поддержку Глонас. Насколько я понимаю, в самом Глонасе для них интереса особого нет, но кроме нашей системы навигации в скором времени заработают еще европейская Galileo, китайский Компас, и, возможно, индийская система навигации. Поэтому Квалкомовцы делают заряд на будущее, готовясь к тому, что придется поддерживать не одну систему, а пять.
Я выбрал Нокаут, но вам могу сказать, что что бы вы не выбрали, в любом случае останетесь в выигрыше.
Если кратко, то Knockout за счет data-bind-атрибутов даст вам упрощенную работу с UI-элементами. Большинство обработчиков событий, которые связанны с UI, в Бэкбоне придется писать ручками, а в Нокауте — нет. Зато Backbone делает больше работы на бэкэенде, в плане связи с сервером.
Так что выбирайте — что для вас важнее — помощь с интерфейсом или с аяксом. В нашем проекте число различных запросов в коде совсем небольшое, а UI — очень сложный. И мы используем KO, так как он позволяет нам сократить объемы кода в большей степени, чем Backbone.
Согласен отчасти — все-таки типизация требует времени, причем чем сложнее система типов, тем тяжелее с ней иметь дело. Однако, в клиент-серверных приложениях основной проблемой становится маршаллинг объектов, но тут дело в хорошем сериализаторе. Например, в нашем случае мы взялись за Gson — это JSON-сериализатор и парсер от Google. Умеет, например, такие вещи делать:
Type collectionType = new TypeToken<Collection>(){}.getType();
Collection customers = gson.fromJson(json, collectionType);
Заметьте там anonymous class для типа - очень эффектный способ специализации, но выглядит как черная магия. Это как раз тот случай, когда приходится "воевать" с типами.
Но в случае с UI Java, к сожалению, даже среда разработки выручить не может.
а) На 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 я оченнь люблю и пишу на ней много лет.
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 нервно курит в сторонке.
Аналогично, полностью согласен. Кроме того, то, как организован сайт для ML курса, мне нравится гораздо больше. Есть отдельно Видео, Тесты и Программерские задания, но при этом есть еще и общий план прогресса по курсу, где отлично видно, что, например, я видео посмотрел, а на тест еще не ответил. А вот на сайте AI есть просто одна кнопка Watch. Ну смотрю, на ответы отвечаю, а где есть ли какие-то еще задания? Я вот просто не нашел.
Еще с ML-class постоянно приходят уведомления на почту — мол, добавили материал — обязательно зайдите-посмотрите. От AI-class вообще ни одного письма не пришло.
С учетом того, что материал в ML на деле оказывается гораздо интереснее, чем в AI, и гораздо ближе к тому, что нам на проекте придется заниматься через полгода, я вообще раздумываю, не забить ли мне на AI. Времени уходит много, а толку мало. Вот за базы данных не взялся, а теперь жалею немного.
У моего оператора нет 3g, только edge. Поэтому обычно я использую Opera Mini, но если страница по каким-то причинам не работает, открываю в Dolphin Mini. Доволен страшно.
Я не XProger, но скажу, что несмотря на все гонения на Флэш, стоит относиться к нему взвешенно.
Пройдет пара-тройка лет и стандартом баннеров станет HTML5 — уже сейчас возможностей вполне хватает, чтобы сделать на нем эффективную анимацию. Такие баннеры не будут подвержены флэш-блокам, будут загружаться на всех мобильных платформах и планшетах. Тогда-то люди обратят внимание, что они все так же, как и Flash, едят батарею и тормозят работу браузера. При этом вырезать такие баннеры простым отключением плагина не удастся. И мне кажется, что в это момент ко многим придет понимание того, что всеобщие нападки на флэш — не более чем охота на ведьм, — а настоящий враг — неумелые разработчики баннеров.
История циклична. Давным давно все девелоперы следили за расходом ресурсов — компьютеры пользователей не были достаточно мощными. Затем наступила эра мощных десктопов, когда можно было писать приложения на любом скриптовом языке — производительности хватало. С ростом же популярности мобильных платформ стали возрождаться C++, Objective-C, т.к. производительнность приложения снова стала иметь весомое значение. Сегодня мобильный процессор во многом похож на десктоп — два ядра по полтора гигагерца в топовых моделях. Однако же появился новый ограничивающий фактор — энергопотребление. Сегодня мы стараемся писать эффективный код, чтобы не стать тем приложением, о котором пользователи будут писать в отзывах «жрет батарею».
Я очень надеюсь, что в какой-то момент быстрая и эффективная реклама тоже станет в цене. А пока все ругают флэш, хотя надо бы ругать плохих баннерописателей.
Flash — эффективная платформа. Adobe удалось собрать удивительно мощный мультимедиа комбайн и упаковать его в несколько мегабайт кода, который работает буквально на всем. С одной стороны — универсальность и кроссплатформенность, с другой — широкие возможности, с третьей — производительность. В общем случае Flash — быстр. Да, виртуальная машина не настолько быстра, как тот же v8, но зато Flash не теряет скорости на операциях с визуальными компонентами, тогда как любая операция с DOM становится узким местом для HTML5-разработчиков.
У Flash есть будущее. Другое дело, что теперь у него есть серьезные конкуренты: HTML5 и Silverlight (он в принципе тоже еще может взлететь, во всяком случае, в энтерпрайз-проектах он используется широко). Отрадно видеть, что конкуренция идет флэшу на пользу — в последние пару лет платформа развивается очень стремительно.
1. Какого черта они вносят код в свои сервисы, который намеренно не пускает пользователей с неодобренными браузерами?
2. Когда же они, наконец, поймут, что язык пользователя должен в первую очередь соответствовать настройкам браузера и операционной системы, а уже потом — айпишнику? И когда же, наконец, все эти настройки будут включаться в одном месте для всех сервисов и не будут сбрасываться при неудачном положении звезд, как это сейчас происходит?
Ну почему? — Все зависит от конкретной игры. Сейчас не могу найти, где, но однажды столкнулся с таким сценарием. Есть сайт с игрой. Если зайти на него с десктопного браузера, то загружается игра. Если заходишь с мобильного, то вместо игры пихают ссылку на Андроид Маркет. И насколько я знаю, Андроид-порт тоже использует флэш.
Да, мы на самом деле живем в удивительное время — когда люди, стоявшие у истоков компьютерной революции, еще живы. Относительно недавно умерли Дейкстра или Ула-Юхан Даль — один из изобретателей ООП. Еще живы Алан Кей, Барбара Лисков, Бьярне Страуструп, Дон Кнут или Гай Стил.
Грустно, конечно, но я уверен, что наши внуки потом будут спрашивать у нас — а как это было, когда они все жили?
Да, сам Стивен Колборн пишет, что вполне вероятно, что юридический отдел компании затеял дело без ведома руководства Astrolabe Inc., мол, подобная практика весьма распространена в США.
Слычай несколько осложняется тем, что с одной стороны, факты не могут являться объектом копирайта, а с другой стороны, базы данных — могут.
Если кратко, то Knockout за счет data-bind-атрибутов даст вам упрощенную работу с UI-элементами. Большинство обработчиков событий, которые связанны с UI, в Бэкбоне придется писать ручками, а в Нокауте — нет. Зато Backbone делает больше работы на бэкэенде, в плане связи с сервером.
Так что выбирайте — что для вас важнее — помощь с интерфейсом или с аяксом. В нашем проекте число различных запросов в коде совсем небольшое, а UI — очень сложный. И мы используем KO, так как он позволяет нам сократить объемы кода в большей степени, чем Backbone.
Type collectionType = new TypeToken<Collection>(){}.getType();
Collection customers = gson.fromJson(json, collectionType);
Заметьте там anonymous class для типа - очень эффектный способ специализации, но выглядит как черная магия. Это как раз тот случай, когда приходится "воевать" с типами.
Но в случае с UI Java, к сожалению, даже среда разработки выручить не может.
а) На 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 я оченнь люблю и пишу на ней много лет.
Но писать на 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 нервно курит в сторонке.
Еще с ML-class постоянно приходят уведомления на почту — мол, добавили материал — обязательно зайдите-посмотрите. От AI-class вообще ни одного письма не пришло.
С учетом того, что материал в ML на деле оказывается гораздо интереснее, чем в AI, и гораздо ближе к тому, что нам на проекте придется заниматься через полгода, я вообще раздумываю, не забить ли мне на AI. Времени уходит много, а толку мало. Вот за базы данных не взялся, а теперь жалею немного.
Пройдет пара-тройка лет и стандартом баннеров станет HTML5 — уже сейчас возможностей вполне хватает, чтобы сделать на нем эффективную анимацию. Такие баннеры не будут подвержены флэш-блокам, будут загружаться на всех мобильных платформах и планшетах. Тогда-то люди обратят внимание, что они все так же, как и Flash, едят батарею и тормозят работу браузера. При этом вырезать такие баннеры простым отключением плагина не удастся. И мне кажется, что в это момент ко многим придет понимание того, что всеобщие нападки на флэш — не более чем охота на ведьм, — а настоящий враг — неумелые разработчики баннеров.
История циклична. Давным давно все девелоперы следили за расходом ресурсов — компьютеры пользователей не были достаточно мощными. Затем наступила эра мощных десктопов, когда можно было писать приложения на любом скриптовом языке — производительности хватало. С ростом же популярности мобильных платформ стали возрождаться C++, Objective-C, т.к. производительнность приложения снова стала иметь весомое значение. Сегодня мобильный процессор во многом похож на десктоп — два ядра по полтора гигагерца в топовых моделях. Однако же появился новый ограничивающий фактор — энергопотребление. Сегодня мы стараемся писать эффективный код, чтобы не стать тем приложением, о котором пользователи будут писать в отзывах «жрет батарею».
Я очень надеюсь, что в какой-то момент быстрая и эффективная реклама тоже станет в цене. А пока все ругают флэш, хотя надо бы ругать плохих баннерописателей.
Flash — эффективная платформа. Adobe удалось собрать удивительно мощный мультимедиа комбайн и упаковать его в несколько мегабайт кода, который работает буквально на всем. С одной стороны — универсальность и кроссплатформенность, с другой — широкие возможности, с третьей — производительность. В общем случае Flash — быстр. Да, виртуальная машина не настолько быстра, как тот же v8, но зато Flash не теряет скорости на операциях с визуальными компонентами, тогда как любая операция с DOM становится узким местом для HTML5-разработчиков.
У Flash есть будущее. Другое дело, что теперь у него есть серьезные конкуренты: HTML5 и Silverlight (он в принципе тоже еще может взлететь, во всяком случае, в энтерпрайз-проектах он используется широко). Отрадно видеть, что конкуренция идет флэшу на пользу — в последние пару лет платформа развивается очень стремительно.
1. Какого черта они вносят код в свои сервисы, который намеренно не пускает пользователей с неодобренными браузерами?
2. Когда же они, наконец, поймут, что язык пользователя должен в первую очередь соответствовать настройкам браузера и операционной системы, а уже потом — айпишнику? И когда же, наконец, все эти настройки будут включаться в одном месте для всех сервисов и не будут сбрасываться при неудачном положении звезд, как это сейчас происходит?
Грустно, конечно, но я уверен, что наши внуки потом будут спрашивать у нас — а как это было, когда они все жили?
Прощай, Дэнис.
С другой стороны, не велосипед (почти) :)
Буду присматриваться, может и попользуюсь.
Слычай несколько осложняется тем, что с одной стороны, факты не могут являться объектом копирайта, а с другой стороны, базы данных — могут.