Да-да, я озвучивал мысль, что, если бы Глонас был один, Квалком, может и не позарился на него, а раз уж потом еще альтернативы ожидаются, то они решили резину не тянуть, а начинать разработку уже сейчас.
Ну, насколько я знаю, из крупных производителей чипов только 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. Когда же они, наконец, поймут, что язык пользователя должен в первую очередь соответствовать настройкам браузера и операционной системы, а уже потом — айпишнику? И когда же, наконец, все эти настройки будут включаться в одном месте для всех сервисов и не будут сбрасываться при неудачном положении звезд, как это сейчас происходит?
Ну почему? — Все зависит от конкретной игры. Сейчас не могу найти, где, но однажды столкнулся с таким сценарием. Есть сайт с игрой. Если зайти на него с десктопного браузера, то загружается игра. Если заходишь с мобильного, то вместо игры пихают ссылку на Андроид Маркет. И насколько я знаю, Андроид-порт тоже использует флэш.
Да, мы на самом деле живем в удивительное время — когда люди, стоявшие у истоков компьютерной революции, еще живы. Относительно недавно умерли Дейкстра или Ула-Юхан Даль — один из изобретателей ООП. Еще живы Алан Кей, Барбара Лисков, Бьярне Страуструп, Дон Кнут или Гай Стил.
Грустно, конечно, но я уверен, что наши внуки потом будут спрашивать у нас — а как это было, когда они все жили?
Если кратко, то 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. Когда же они, наконец, поймут, что язык пользователя должен в первую очередь соответствовать настройкам браузера и операционной системы, а уже потом — айпишнику? И когда же, наконец, все эти настройки будут включаться в одном месте для всех сервисов и не будут сбрасываться при неудачном положении звезд, как это сейчас происходит?
Грустно, конечно, но я уверен, что наши внуки потом будут спрашивать у нас — а как это было, когда они все жили?
Прощай, Дэнис.
С другой стороны, не велосипед (почти) :)
Буду присматриваться, может и попользуюсь.