Microsoft — мировой лидер в области ПО и ИТ-услуг
455,30
рейтинг
2 января 2015 в 17:29

Разработка → Тренды JavaScript на 2015 год



Всем привет! Мы как-то задумали сделать легкий вводный курс на тему JavaScript и разработки приложений (он, кстати, скоро будет опубликован): и, пока я собирал материалы к нему, как-то само собой выяснилось, что есть довольно много вещей, которые, так сказать, находятся на переднем крае развития JavaScript. Отсюда родилась идея сделать отдельную обзорную статью в жанре «X трендов на год Y по технологии Z».

Многие из тех, вещей, которые я буду описывать, можно попробовать в той или иной степени уже сегодня (собственно, иначе я бы говорил о космическом будущем, а не о трендах). В этом есть несомненный плюс: если у вас будет свободное время (а на праздниках его обычно много), вам будет чем заняться. Да и, в целом, хорошо начинать новый год с расширения своих горизонтов!


1. ECMAScript 6



Если вы занимаетесь веб-разработкой, вы наверняка на себе прочувствовали все прелести и ограничения JavaScript. Когда Брендан Айк в 1995 году придумывал на скорую руку JavaScript, навряд ли он мог предположить, во что разовьются через 15-20 лет веб-технологии и какие фокусы разработчики будут вытворять, используя его детище.

Сложность современных веб-решений давно требует существенного пересмотра того, как мы эти решения создаем, поэтому не случайно столь большое внимание разработчиками браузеров (в частности) уделяется сегодня следующей версии стандарта JavaScript – ECMAScript 6.

Новый стандарт (который, кстати, в пику несостоявшемуся выпуску ES4 иногда называют как ES6 “Harmony”) несет давно ожидаемые возможности, которые существенно облегчат создание сложных решений: классы, модули, коллекции, итераторы, генераторы, прокси, типизированные массивы, обещания, новые методы и свойства для стандартных объектов и новые синтаксические возможности и еще много чего.

// lib/math.js
export function sum(x, y) {
    return x + y;
}
export var pi = 3.141593;

// app.js
module math from "lib/math";
alert("2π = " + math.sum(math.pi, math.pi));


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

Писать и поддерживать сложные приложения станет сильно проще. Посмотреть, как выглядят новые фишки языка в коде можно в обзоре “Overview of ECMAScript 6 features” от Luke Hoban.

Следить за внедрением поддержки новых возможностей ES6 можно по таблице совместимости с ES6. А попробовать многие возможности уже сейчас можно в свежей сборке Internet Explorer Technical Preview, доступной в рамках программы Windows Insider.

Кстати, в конце 2015 нас ждет большой праздник – 20-летие JavaScript. Фактически, новый стандарт – это попытка сделать JavaScript хорошим языком (хотя некоторые его концепции навряд ли покажутся новичкам более легкими, чем прототипное наследование). А еще есть прогноз, что стандарт ES6 будет утвержден именно в 2015 году. Впрочем, непосредственное внедрение нового стандарта в практику разработки займет не один год.

Что ждать в 2015: новый стандарт ECMAScript 6, реализация в браузерах, адаптация в сообществе и фремворках.



2. Типизированный JavaScript



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

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

Как на зло, оказалось, что работа с файлами и графикой (привет WebGL!) требуют умения работать с типами конкретной размерности, а не единым обобщенным Number, поэтому, кстати, появился отдельный стандарт для типизированных массивов, который теперь станет частью ES6.

В общем, когда за дело взялся Андерс Хейлсберг (Delphi и C# — его детище), появился TypeScript. TS – это надмножество JS, добавляющее в язык статическую типизацию на этапе разработки, а также многие возможности из ES6. Конечно, TS появился не просто так, а в том числе из внутренней потребности Microsoft в удобном создании сложных веб-приложений.

// TypeScript
class Greeter {
    greeting: string;
    constructor(message: string) {
        this.greeting = message;
    }
    greet() {
        return "Hello, " + this.greeting;
    }
}


(Аналогичная потребность созрела и в других компаниях – обратите внимание на новые проекты по типизации от Facebook (Flow) и Google (AtScript). Тут самое место для большой надежды, что в 2015г. мы не получим очередные новые несовместимые технологии.)

Прелесть TypeScript в том, что, пока вы пишите код (особенно если вы делаете это в Visual Studio, но не обязательно), вы получаете возможность удобно описывать сложные структуры данных, а компилятор при этом помогает вам отслеживать, что вы нигде ничего не напутали и правильно работаете с типами.

Еще одно замечательное свойство TS, точнее его компилятора (который, кстати, открыт также, как и сам язык!), состоит в том, что в результате компиляции получается чистый код на JavaScript, причем, примерно такой, какой вы бы и сами написали, следуя современным практикам:

// TypeScript to JavaScript
var Greeter = (function () {
    function Greeter(message) {
        this.greeting = message;
    }
    Greeter.prototype.greet = function () {
        return "Hello, " + this.greeting;
    };
    return Greeter;
})();


Таким образом, на выходе получается код, работающий в современных браузерах на любых операционных системах. К слову, под Node.js тоже можно писать на TypeScript.

Кстати, так как любой код на JS уже является кодом на TS, то естественным образом возникает вопрос, как существующий код использовать типизированным образом? Ответ на этот вопрос находится в большом проекте DefinitelyTyped, в рамках которых уже типизировано большинство самых распространенных библиотек.

В перспективе следующая большая версия TypeScript 2.0 должна стать надмножеством ES6. Попробовать TS в браузере прямо сейчас можно в нашей песочнице.

В целом, если вы пишите код на JavaScript, внедрение в работу TypeScript может стать одной из самых важных ваших инвестиций в 2015 г.

Что ждать в 2015: рост адаптации TypeScript, развитие альтернативных проектов и их взаимное обогащение.



3. Кросс-платформенность



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

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

Стирание границ


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

В контексте Windows и Windows Phone одним из решений в данном направлении является технология WAT (Web Application Template), позволяющая хостить веб-сайты в виде приложений для ОС, доставляемых через магазин приложений. Как результат, сайт «превращается» в приложение: выглядит как нативное приложение (при должной стилизации), ведет себя как нативное приложение (за счет интеграции в ОС) и получает нативные возможности (например, работу с камерой и файловой системой).

Безусловно, это не единственная подвижка в этом направлении: думаю, часть веб-разработчиков с большим опытом помнит проект Mozilla Prism. Из недавней истории – это закрепленные сайты в Windows 7+, из совсем свежей – Яндекс.Браузер, старающийся минимизировать визуальное присутствие браузера.

Несмотря на имеющиеся подвижки, в будущем еще многое предстоит сделать (от облегчения доступа к нативным возможностям до стандартизации соответствующих API, например, в части W3C Manifest for web applications). Это, кстати, может оказаться интересным пространством для технологических инноваций.

Мобильная разработка


Во второй задаче, значительная часть пути уже проделана в таких проектах, как Apache Cordova. За прошедшие пару лет к проекту подключилось множество крупных компаний: сегодня это уже не только Adobe, купивший PhoneGap, но и Microsoft, Intel, IBM, Google и другие.

В определенном смысле, Cordova как раз решает сегодня ту задачу, на которую в мире веб-разработки и веб-стандартов уходит больше времени, чем хотелось бы. А именно: предоставление доступа к нативным возможностям единообразно из JavaScript на разных платформах.

Вы пишите код на HTML/CSS и JS, Cordova упаковывает их в приложение, которое можно распространять через магазины приложений. Важным отличием от предыдущего пункта тут является то, что код такого приложения является локальным, поэтому заведомо обладает большими возможностями. Впрочем, вместе с этим он приобретает и ограничения в смысле обновления только через магазины.

Почему я ожидаю заметного роста в использовании и адаптации Cordova в следующем году? На это есть три важные причины:
  1. Продолжение роста мобильного сегмента и смещения фокуса внимания в сторону приложений (против веб-браузера).
  2. Повышение производительности и возможностей WebView-компонент (стандартный повод говорить, что приложения на JS тормознутые). Это, кстати, критично и для хостинга сайтов.
  3. Появление отличных инструментов, позволяющих удобно разрабатывать, тестировать и собирать приложения под разные платформы. Visual Studio 2015 (Preview) тому отличный пример, но естественно, в этом направлении двигается не только Microsoft.


Интересным моментом в обоих направлениях является то, что если у вас в штате есть JavaScript-разработчик, то в перспективе он может закрывать все основные ниши веб- и мобильной разработки. Да, писать приложения на TypeScript для Apache Cordova и веб-сайтов тоже можно уже сегодня!

Что ждать в 2015: развитие инструментов для кросс-платформенной разработки на JS, продолжение стирания границ между сайтами и приложениями.



4. Native



Естественным развитием предыдущего тренда являются еще один переход, который фактически уже свершился, но пока не набрал критичной массы в умах веб-разработчиков. Речь идет о нативной разработке приложений непосредственно на JavaScript. Кстати, упомянутая ранее Apache Cordova под Windows-платформу уже является нативной.

Для многих разработчиков до сих пор такая мысль режет слух. Нативное – это традиционно на C++, C#, ObjectiveC, Java и т.п., но никак не на JavaScript.

У этого было и историческое подтверждение в мобильных платформах, на которых писать на JavaScript можно было только внутри WebView, который был всего лишь одним из элементов управления в рамках приложения на «настоящем» нативном языке. И это было медленно.

Однако ситуация изменилась: Windows 8 с самого начала, Windows Phone с версии 8.1, Firefox OS, Chrome OS и другие платформы уже сегодня предлагают разработку приложений напрямую на JavaScript с прямыми вызовами нативных функций, обращением к файловой системе, интеграцией с возможностями ОС и т.п.

// File system access on Windows platform from JavaScript
// Get folder
var picturesLibrary = Windows.Storage.KnownFolders.picturesLibrary;
//  Get folder contents
picturesLibrary.getItemsAsync().then(function (items) {
    outputHeader(picturesLibrary.name, items.size);
    items.forEach(function (item) {
        if (item.isOfType(Windows.Storage.StorageItemTypes.folder)) {
            output(id(picturesLibrary.name), item.name + "\\");
        }
        else {
            output(id(picturesLibrary.name), item.fileName);
        }
    });
});


Все это есть уже сегодня. Вопрос в росте доли соответствующих платформ и осознании веб-разработчиками, что у них есть такая возможность (к слову, это очень интересный психологический аспект, который я часто наблюдаю в рамках экосистемы Windows: даже веб-компании, имеющие в штате достаточное количество веб-разработчиков, предпочитают для Windows-приложений нанимать отдельного разработчика на C#/C++, потому что так принято).

Ситуация постепенно меняется. Удивительно, но одним из направлений роста нативной разработки на JavaScript неожиданно становятся умные телевизоры (например, LG с Open webOS), а также игровые консоли (например, Xbox One). Здесь просто нет альтернативы, а рынок и спрос растет!

Наконец, еще одним важным аспектом является, безусловно, повышение скорости исполнения JavaScript: это и вопрос к компиляторам/интерпретаторам, и к типизации в определенных аспектах, и к выделению подмножества языка, которое можно гарантированно выполнять быстрее (asm.js).

Что ждать в 2015: рост умных телевизоров и консолей с разработкой на JavaScript, адаптация веб-разработчиками возможностей нативной разработки на JS на многих современных платформах (но не всех).



5. Device API



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

С самыми базовыми вещами вроде геолокации или ориентации устройства мы уже научились работать, но впереди большая работа по стандартизации и реализации в движках браузеров (например, за IE можно следить на status.modern.ie) большого блока возможностей, доступных в случае нативной разработки, но, как правило, неподвластных в случае разработки для браузера:
  • Вибрация
  • Статус батареи
  • Сенсоры (например, света)
  • Камера и микрофон
  • и др.


Аналогичная задача стоит и с точки зрения ввода информации со стороны пользователя: начиная с сенсорного ввода (привет Pointer и Touch событиям) и заканчивая управлением голосом и жестами (привет в целом идеям NUI и Kinect, в частности).

Кстати, про Kinect, если у вас есть Kinect for Windows, то вместе с SDK вы получаете и возможность работать с сенсором непосредственно в браузера из JavaScript.

Почему это направление будет развиваться в следующем году? Все просто: разработчики браузеров, тесно связанные с лежащими под ними операционными системами, будут пробрасывать в веб-контекст нативные возможности, а общие устремления должны привести к стандартизации подходов.

Кстати, интересный аспект касательно Apache Cordova, которая в каком-то виде уже это делает: выставляемые проектом API для JavaScript также завязываются на соответствующие стандарты по мере их появления.

Что ждать в 2015: развитие API доступа к нативным возможностям устройства из JavaScript, адаптация NUI в JS. Уверен, это затянется на несколько лет.



6. Борьба со сложностью



Борьба со сложностью, точнее стремление упростить создание сложных решений продолжается. Заканчивается 10-летняя эпоха JS-библиотек, упростивших на долгие годы жизнь веб-разработчиков, заполнявших пробелы между браузерами и недостаточную скорость развития веб-стандартов (кстати, в феврале 2015 будет 10 лет Prototype, если помните такой, в июне – script.aculo.us, а в сентябре — MooTools!).

Какие-то из этих библиотек живы до сих пор и активно развиваются, например, jQuery. Многие умерли или были вытеснены конкурентами.

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

Вслед за решениями для создания приложений на базе концепций MVC (Backbone, Knockout, GWT и т.п.) на рынок вышли новые игроки, двигающиеся еще дальше в сторону создания SPA: Ember.js, Angular (Google), React (Facebook).

Во всем этом движении особенно интересными мне представляются два момента:
  • Выход на рынок крупных игроков, которые переосмысливая свой опыт и свою инфраструктуру создают новых решения (Google и FB тут самые явные примеры). Тут стоит отметить не только инженерный опыт, но и потенциальные маркетинговые рычаги, которые могут перестроить рынок.
  • Модульность и перетекание опыта: благодаря открытости одни фреймфорки могут включать в себя части других – взять хотя бы тот же Mustache.


Как это все будет развиваться дальше?

Во-первых, по мере адаптации и накопления опыта нас ждет переосмысление инженерами своих продуктов и решений. Вторая версия Angular тому хороший пример.

Во-вторых, создание сложных решений требует обновления подходов и, когда возможностей простого JavaScript не хватает, на сцену выходят его доработки. Microsoft переписывает WinJS на TypeScript, Google для Angular 2.0 готовит AtScript, Facebook пишет ReactJS на Flow.

В-третьих, это стремление к совместимости и взаимозаменяемости компонент. Например, в случае WinJS 3.0 – это явное стремление достичь совместимости с другими библиотеками для создания SPA. Хотите использовать WinJS с React? Используйте.

Что ждать в 2015: выход новых переработанных версий популярных библиотек, усиление конкуренции крупных игроков, повышение входного порога для создания комплексных фреймворков, новые возможности для нишевых решений на базе ES6.



7. Веб-компоненты



Веб-компоненты – еще один взгляд на борьбу с нарастающей сложностью. Если ES6 и TypeScript работают на уровне языка, а фреймворки на уровне композиции сложных приложений, то веб-компоненты дают взгляд на то, как справляться со сложностью на уровне элементов HTML и, в частности, объектной модели документа (DOM).

Сегодня веб-компоненты состоят из пяти ключевых компонент:
  • Templates и Decorators – определение и применение шаблонов разметки в связке с данными для динамической генерации элементов HTML (фактически речь идет о стандартизации существующих практик).
  • Custom Elements – создание собственных элементов разметки со своими названиями тегами и необходимыми интерфейсами для JS.
  • Shadow DOM – возможность сокрытия части DOM для отдельных элементов разметки (полезно для виджетов), один из побочных эффектов – наоборот открытие DOM для стандартных элементов управления, стилизация которых обычно затруднена.
  • HTML Imports – упаковка шаблонов и собственных элементов и их внедрение в HTML-документы (здесь есть частичное пересечение с модулями в ES6).


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

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

Впрочем, в определенном смысле, веб-компоненты – это темная лошадка, про которую трудно сказать, когда именно и как именно она выстрелит. Сегодня это направление, пожалуй, наиболее активно двигает Google через проект Polymer и поддержку соответствующих черновиков стандартов в рамках Chromium.

И, конечно, борьба со сложностью в одном месте, безусловно, порождает сложность в каком-то другом. 

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



8. Пакеты и сборка



И как финальный штрих упаковки кода мы подходим к системам сборки и доставки JS-кода. Хотя это разные задачи, в некотором смысле, они начинают и завершают работу с кодом, таким образом, формируя цикл (вплоть до того, что управляются в едином решении вроде Component).

Со сборкой все относительно просто: за последние годы на рынке устоялось несколько лидеров, имеющих в своей основе Node.js. Прежде всего, это Grunt, Gulp и, в меньшей степени, Brunch.

Однако, за год появилось (или стало активнее звучать) и несколько амбициозных проектов, за которыми интересно будет понаблюдать в следующем году: Broccoli, Fez, Mimosa. Навряд ли они существенно потеснят устоявшиеся решения, однако могут занять свои ниши. Ключевая проблема любых новых игроков: наличие сообщества вокруг них, либо сильного драйвера (в том числе маркетингового), который позволил бы им вырваться вперед.

Не исключено, что с какими-то интересными решениями вокруг своего стека веб-технологий начнут выходить крупные игроки рынка, как например, делает Яндекс со сборщиком ENB, построенных вокруг BEM-проектов.

Теперь давайте посмотрим на доставку пакетов. Если npm для серверного JavaScript сегодня уже навряд ли кого-то удивишь, то с Bower все только начинается (даже несмотря на то, что Twitter выпустил его с открытым кодом аж в 2012 году!). Кстати, не случайно, в Visual Studio появилась встроенная поддержка не только npm, Grunt и Gulp, но и Bower.

На просторах интернета нас ждет все больше и больше строчек вида:
bower install jquery


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

Наконец, со стороны загрузки пакетов в браузере, помимо упомянутого ранее Browserify, в 2015 году также будет интересно последить за такими решениями, как Duo (вобравшем в себя идеи не только Browserify, но и Component и Go) и jspm (в частности, уже сегодня реализующем модель модулей ES6).

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



9. Графика, особенно трехмерная




Сегодня можно уверенно говорить, что не только HTML5 окончательно стал стандартом, но и такие технологии, как WebGL, достигли достаточной зрелости (как с точки зрения безопасности, так и с точки зрения поддержки браузерами).

Поэтому от отрисовки кубиков и чайников и прочих экспериментов мы постепенно переходим ко все более сложным решениями (как правило, игровым). Яркие примеру тому прошлого года – демо-сайт Assassin’s Creed Pirates и сайт Dino Hunt TV.



Важным сдвигом в этом направлении является появление различных библиотек, упрощающих создание решений на базе WebGL, например, three.js и Babylon.js. Аналогичное движение происходит и в мире инфографики – и d3.js тут ярчайший пример.

Но и этого пока мало: широкая адаптация современных графических возможностей JavaScript все еще ожидает, пока огромная масса веб-разработчиков, обратит на них внимание. Особенно интересными тут представляются несколько категорий:
  • Креативные рекламные промо-сайты: продолжение вытеснения флеша, от видео-фонов и паралакс-сайтов можно уже переходить к чему-то более затягивающему.
  • Игры в социальных сетях: здесь все еще очень большое засилие Flash, но, возможно, если игры в Facebook и VK станут доступными в их мобильных приложениях, то это откроет второе дыхание для игр на HTML/JS.
  • Инфографика и в целом динамичное отображение информации: отчасти эти технологии уже сегодня берут на вооружение новостные сайты.


Кстати, еще пара интересных аспектов:
  • Графическим библиотекам на JS (для Canvas или SVG) предстоит переродиться или кануть в Лету. Связано это с тем, что много из созданного в предыдущие годы, несет в себе заметный груз обратной совместимости, от которого предстоит избавиться, заодно пересмотрев в целом реализацию и возможности библиотек.
  • Развитие инструментов для создания графики и анимации в рамках веб-стека. Традиционно (в смысле наследия от Flash) тут большое внимание стоит уделить продукции Adobe (Edge-семейство) и библиотекам, близким по духу к Flash и ActionScript, например, CreateJS.


Ах да, особенно интересный вопрос на тему графики: рекламный баннеры. Вот уже несколько лет я жду, когда же веб-стандарты придут на смену Flash. Думаю, и в 2015 массового перехода не случится, по крайне мере, до тех пор, пока крупные сети не начнут смену технологий.

Что ждать в 2015: развитие графических библиотек на JS, показательная адаптация новых технологий крупными или заметными игроками рынка (очевидно, это требует определенной решительности и готовности к экспериментам).



10. Игры



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

Тут можно предсказать два предстоящих прорыва.

Во-первых, это развитие игровых движков, позволяющих создавать достаточно сложные решения, в идеале, переносимые между платформами. Другими словами, мало иметь низкоуровневую поддержку 2d и 3d-графики в браузере, нужно также уметь работать со сценами, анимациями, текстурами, светом и камерами, спрайтами, физикой и т.п.

Многие движки уже сегодня активно развиваются в этом направлении, но самый большой прорыв 2015 года – это Unity 5 с возможностью исполнения игры или сцены в браузере без дополнительных плагинов. Все это поверх WebGL и JavaScript (через asm.js).

Это событие будет важно не только потому, что Unity3d – один из самых популярных кросс-платформенных движков сегодня, что потенциально означает перенос в веб многих существующих игрушек, но и потому что это станет знаковым событием для WebGL и в целом графики в браузере.

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

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

JavaScript и веб-стек тут может быть подходящим ответом.

К слову, про игры: показательным аспектом роста интереса к играм в браузере, точнее к расширению их возможностей, росту «хардкордности» являеются, например, появление W3C GamePad API, позволяющего управлять игрой в браузере с геймпада.

Что ждать в 2015: Unity 5 с рендерингом в WebGL, развитие 3d и игровых библиотек, потенциальный прорыв через социальные сети.



11. Серверные технологии



На протяжении всей статьи я уже несколько раз упоминал Node.js и это не последний блок, где мы про него вспомним. Node.js на рынке уже более 5 лет (подумать только!), а кажется, что он все еще в новинку.

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

Активная часть сообщества динамична, поэтому с легкостью переключается на новые языки и платформы, однако одно большое преимущество Node.js, от которого мы никуда не денемся – это по-прежнему тот факт, что в нем используется тот же самый язык, что и во всех браузерах – JavaScript, и вместе с ES6 и проектами по типизации JS платформу ждет некоторая встряска.

Помимо адаптации нового стандарта (как я говорил ранее, писать под Node.js на TypeScript можно уже сегодня), нас ждет какое-то развитие еще одного события, которое случилось под конец прошлого года. У Node.js появился форк – io.js. Куда нас заведет это ответвление, пока никто не знает, но приключение обещает быть интересным. Ждем первых релизов в 2015 г.!

Еще один интересный аспект развития Node.js – это тот факт, что платформа наконец-то начала добираться до корпоративной среды. Причем и речь не только о поддержке в промышленных облаках (вроде Microsoft Azure, в том числе использования внутри выставляемых сервисов), но и реальном применении Node.js такими гигантами, как LinkedIn, Yahoo, Walmart (тут стоит упомянуть, что они среди прочего они сделали интересный серверный движок для Node.js – Hapi).

Что ждать в 2015: адаптацию Node.js в корпоративной среде, адаптацию нового ES6 в самом Node.js. Ну и запастить попкорном и смотреть историю с форком.



12. Интернет вещей




Э-ге-гей! Мы добрались до последней темы на сегодня: интернет вещей, он же IoT. Сама по себе история с IoT не нова и навряд ли стоит ожидать, что в 2015 случится что-то более драматичное, чем случилось в 2014 (а в прошлом году ничего драматичного и радикального не случилось) – просто продолжится постепенное развитие направления по всем возможным фронтам: от встраиваемых устройств, умных домов, машин и прочих крупных объектов до сетей мелких сенсоров и носимых устройств.

Какую роль во всем этом играет JavaScript?

Во-первых, для интернета вещей нужно облако и динамичная обработка множества асинхронных событий. А что умеет это неплохо делать? Правильно, Node.js. Конечно, не только он, но и он тоже. В общем, если вы видите будущее в интернете вещей (в той или иной проекции, потому что абстрактно тут делать нечего) и любите JavaScript, то самое время потратить время на разработку соответствующих решений (главное, чтобы у вас была подходящая задача, хотя можно начать и с контроля температуры за окном).

Во-вторых, я снова про Node.js, уже сегодня есть несколько проектов, предлагающих управлять подсоединенными к компьютеру устройствами через JavaScript-код под Node.js. Интересным большим проектом в этом направлении является Cylon.js, уже сегодня поддерживающий кучу устройств. Но есть и маленькие фокусные, например, noduino.

В-третьих, я снова про него, в нескольких умных головах то и дело появляются идеи запускать на «умных вещах» маленький сервер с Node.js. Ну а дальше JavaScript – и в путь. Например, такую идею продвигает Intel в рамках своих платформ Edison и Galileo.



Наконец, в-четвертых, за год на рынке появилось несколько интересных устройств, которые содержат внутри собственный интерпретатор JavaScript и, фактически позволяют программировать себя используя именно JS. Tessel – самый развитый пример, но есть, например, еще Espruino.

Конечно, навряд ли можно рассчитывать, что JavaScript перевернет мир IoT, но вот что адаптация IoT возможна через JavaScript – теперь это чистая правда.

Что ждать в 2015: JavaScript в контексте разных направлений IoT будет следовать за общей динамикой, самое очевидное направление развития – облачные решения на базе Node.js, но также стоит ожидать и новые экспериментальные проекты на клиентской стороне.



Резюме


Напоследок соберем все вместе:
  1. Новый стандарт ECMAScript 6. Утверждение, реализация в браузерах, адаптация в сообществе и фремворках.
  2. Рост использования TypeScript в реальных проектах, развитие альтернативных проектов и их взаимное обогащение.
  3. Развитие инструментов для кросс-платформенной разработки на JS, продолжение стирания границ между сайтами и приложениями.
  4. Рост умных телевизоров и консолей с разработкой на JavaScript, нативная разработка на JS на многих современных платформах (но не всех).
  5. Развитие API доступа к нативным возможностям устройства из JavaScript, адаптация NUI в JS. (Затянется на несколько лет.)
  6. Новые переработанные версии популярных библиотек, повышение входного порога для создания комплексных фреймворков, нишевые решения на базе ES6.
  7. Адаптацию веб-компонент браузерами, принятие новых технологий разработчиками элементов управления и различных фреймворков.
  8. Принятие менеджеров пакетов и систем сборки для JavaScript в корпоративной и учебной среде, интеграция в популярные инструменты веб-разработки.
  9. Развитие графических библиотек на JS, показательная адаптация новых технологий крупными или заметными игроками рынка (игры и интерактивный контент — основные драйверы).
  10. Unity 5 с рендерингом в WebGL, развитие 3d и игровых библиотек, потенциальный прорыв через социальные сети.
  11. Адаптация Node.js в корпоративной среде, адаптация нового ES6 в самом Node.js. Запасаемся попкорном и смотрим историю с форком io.js.
  12. Облачные решения для IoT на базе Node.js, новые экспериментальные проекты на клиентской стороне.


Смотря на этот список, я думаю, нас ждет веселый 2015 год!
Автор: @kichik
Microsoft
рейтинг 455,30
Microsoft — мировой лидер в области ПО и ИТ-услуг

Комментарии (76)

  • +22
    Тренды JS на 2015 год — стать Action Script 3.0!
    C новым годом! :)
    • +4
      Ага, 2006 год — Adobe отдает в Mozilla Foundation исходники Tamarin для адаптации ES4.
    • –6
      Ну AS, как и JS всё есть реализации ES, так что не удивительно. Лично мне удивительно почему так восхваляют JS. Вот честно, без придирок и не учитывая некоторые тонкости, в целом — JS в нынешнем его проявлении — это прям копия PHP версии ~4, если убрать из пыха доллары, разве нет?
      • 0
        Хей, ребят, выж профессиональные программисты, обоснуйте мнение пожалуйста, вместо минусов. Я, например не вижу разницы, ну так тыкните носом — я переменю свой мнение, ёпрст.
        • +7
          В чем копия-то? Синтаксис что ли похож (хотя даже в нем есть куча отличий помимо бакса) и динамическая типизация?
          Как насчет того, что JS является прототипированным языком и на этом основаны механизмы наследования (ну это если не смотреть в ES6), а PHP реализовано классическое ООП. Те же замыкания, анонимные функции доступны в PHP только с 5.3 версии.
          Скорее всего приведение типов работает иначе.
          Например, внезапно, php не обрабатывается браузерами.
          Думаю таких особенностей много найдется.
          • –1
            Ну это всё вполне очевидные вещи и совершенно верные, но мысль у меня немного иная. Все гуру JS пропагандируют, как один — функциональный подход, т.е. прототипы остаются как бы не у дел немного. Давайте взглянем на исходники популярных библиотек, много ли вы там видели прототипов и более-менее человеческого подхода к разработке фреймворка? Всё, что рекомендуют при разработке на JS — это функции и функции, хотя php-ньюблам за это буквально руки отрывают, хотя в то же время JS позволяет выстроить вполне вменяемый и читаемый класс с нормальным наследованием, протектными, публичными, статическими свойствами, методами инстанса и статик методами класса. Именно этого я не понимаю.

            Неймспейсы? Зачем нам неймспейсы, говорит JS, давайте сделаем костыль в виде AMD и проч. (а это ведь реальный костыль, т.к. сам язык не имеет подобного).
            Передача по ссылке? Зачем нам она, давайте сделаем obseve и будем обходиться без new, просто Object.observe.
            Вместо уже готовых идей из рубей, питона и того же пыха, в виде __get\__set будем использовать Object.defineGetter, а вместо __call\method_missing — создадим Proxy, говорят разработчики языка.

            А потом удивляются, каким образом любое более-менее сложное приложение превращается в лапшу из подобных строчек, но нет, отвечают, это не JS-way. А какой же тогда js-way, если появляются и стремительно развиваются трансляторы и вполне себе полноценные языки, как CoffeeScript, TypeScript, Dart, что-там-ещё?
            • +9
              Ну есть функцииональный подход, есть ооп подход при разработке, хочешь используй то, хочешь это. Кому надо говнокодит, кому надо выстраивают хорошую архитектуру приложения. Хотя в JS эти подходы прекрасно переплетаются.

              Да есть куча фреймворков, где используются ооп подход, тот же dojo, backbone, kineticJS, jQuery, в любом более менее нормальном фреймворке где нужен ооп подход он есть.

              Велкам ту неймеспейс на js:
              var ns1 = {};
              var ns2 = {};

              AMD — это технология позволяющая разбивать приложения на модули и загружать их асинхронно, а не костыль и замена неймпейсам. А, например, requireJS ее реализация вне стандарта языка, так как сам по себе JS достаточно долго развивается, а технология нужна сейчас, в стандарте ES6 модульность таки заложена.

              Что значит нет передачи по ссылке если только так и передаются объекты.
              Обходиться без оператора new, ну я бы поглядел на это.

              Причем тут Object.observe мне вообще не ясно и что в нем плохого. Отличная функция для чека изменения объекта. Может вы хотели использовать вместо нее сеттеры, эт конечно можно, но в некоторых ситуациях обсерв всего объекта куда удобнее, да и позволит сократить код.

              Ну нет в JS особого синтаксиса неявных сеттеров\геттеров, во многих нормальных языках программирования их вообще нету. Хочешь сделать сеттер\геттер сделай их. Тут просто вопрос удобства. Тем более что язык предоставляет возможность реализации и неявного механизма. Так что не понимаю в чем проблема.

              Специально глянул, что за __call\method_missing и приржал (оф документация МАГИЧЕСКИЕ МЕТОДЫ), в который раз убеждился, что ООП в PHP — это недоразумение не для людей как и сам язык, и славлю богов, что в свое время перешел с него на богоподобную в этом плане JAVA.
              >В контексте объекта при вызове недоступных методов вызывается метод __call().
              Я, конечно, понимаю зачем это, но это просто полная ахинея. За все мои 8 лет программирования (как для серверных, так и для клиентских приложений), я ни разу не сталкивался с выше описанной надобностью. Но опять же, js позволяет реализовать это недоразумение при необходимости.

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

              Очевидно, что coffeescript популярен благодаря синтаксису (мне лично не нравится, я олдфаг) и сахару. Typescript вообще ни разу не популярен (само собой он есть в этой статье ибо язык то мсовский) (хотя тайп чекинг хорошая штука, жаль что в es6 нету), как и Dart (вообще недоразумение мертворожденное). Приржал, когда аутсорсил в одной крупной зеленой компании и типы с соседнего проекта сказали, что прототипрование это очень сложно и не понятно, давайте будем использовать Dart.

              Да и вообще зачем вы мне описываете какие-то тонкости языка, если хотели узнать чем PHP отличается от JS. Вы мне предлагаете разрабатывать интерфейсы на PHP или тупо ради холивара (если так то php — ведро с говном, самый плохой язык, на котором я что то делал).
              • –4
                Мог бы очень много возразить по поводу того что хорошо или плохо, но в целом, если пишется на JS прекрасно, то странно почему с PHP такие сложности, всё же в нём несогласованность распространяется только на именование функций, а в JS вообще на всю архитектуру языка, которую, надо отдать должное — последнее время почти успешно выправляют.

                Отвечая на некоторые вопросы:
                1) Передача по ссылке означает возможность когда угодно и что угодно передать по ссылке или по значению. Observe как раз и является таким костылём, который позволяет передавать значение переменной из одного места в другое, используя события подписки.
                2) В питоне это __getattr__, в рубях — method_missing. При чём тут PHP и конкретно его аналог, называемый «магическим методом»? Эта практика применяется не только в этом языке. Очень удобно. Странно, что не приходилось сталкиваться, т.к. например простой ActiveRecord (в частности генерацию AR модели с динамическими свойствами) я просто не представляю как реализовать без мета программирования.
                3) Лично мне Coffee приятен тем, что он (в т.ч. с помощью него) можно исправить многие косяки JS. Уже давно отказался от нативного JS в пользу оного.

                В любом случае, не хотелось бы разводить холиваров, это да. Всю мысль я довольно чётко описал уже выше, в предыдущем посте. В пыхе тоже можно написать $ns1 = (object)[];, но это не будет неймспейсом — это будет просто пустым объектом. В пыхе так же можно динамически добавить свойство в этот объект, но это не будет элементом неймспейса — это будет просто полем этого объекта. Это костыль, который выдают в JS за «хороший подход» за неимением вменяемого. При разработке приложения, объёмом чуть более чем 20к строк кода у меня сложилось более чем чёткое впечатление:

                JS — это феерический набор маркетинга и рекламы, основывающийся на действительно большом количестве разработчиков (за неимением веб клиент-сайд альтернатив), на существующей, действительно крутой кодовой базе (V8 гениален), но как самостоятельный язык — не способный на реализацию мощных и элегантных программ без плевков каждые пять минут… Хотя постойте, может просто я слишком близко познакомился с PHP, Ruby, Python (можно с чем угодно сравнивать, имхо) и уже не могу нормально воспринимать js-way и по этому стараюсь писать не так, как говорят, а так, как считаю будет понятным всем, ну например: pastebin.com/0GYRkVAm =)
                • +1
                     » простой ActiveRecord (в частности генерацию AR модели с
                     » динамическими свойствами) я просто не представляю
                     » как реализовать без мета программирования.

                  Не ради холивара, просто в качестве уточнения. Конкретно для ActiveRecord как раз достаточно механизма типа Java reflection. При инициализации (которая, как известно, и так не самое сильное место руби в плане скорости) заглянуть в таблицы и вызвать define_method на все, что нужно. Я не использую рельсы и давно в код не смотрел, но могу сказать, что если бы я пилил ActiveRecord я бы давно это сделал: вызовы method_missing довольно накладны.

                  Ну а товарищу, который не понимает, зачем нужно метапрограммирование, хочется ответить словами Паули: «Это не вопрос, это утверждение».
                  • +1
                    JS — язык динамический там в принципе не нужен механизм рефлекшена, потому что методы можно изменять, добавлять удалять в рантайме. Собственно так реализовывал AR на JS.
                    В 7 утра просто не гуглил все варианты того, что можно реализовать с помощью этого волшебного метода, опять же человек выше пишет о каких-то тоннах костылей в JS, и восхваляется этим недоразумением, которое используются как костыль вместо нормально рефлекшена. Не понимаю как можно сравнивать его с рефлекшеном в JAVA.
                    А в ES6 еще и будут славные аннотации.
                    • 0
                      А reflection — это и есть рантайм вообще-то.

                      Кроме того, если вы не понимаете, зачем нужен тот, или иной метод — это не значит, что метод лишний. У меня почти не было проектов, в которых я бы не использовал method_missing. Например, для DSL. Это можно сделать и рефлекшеном, и на JS, и на баше. Но method_missing, очевидно, удобнее.
                      • 0
                        Да, с рефлекшеном я затупил (да и в php вполне нормальный рефлекшен как оказалось).

                        Само собой если он существует в языке, то скорее всего зачем-то нужен, другой вопрос в том насколько целесообразно использовать подобные магические методы, просто для упрощения себе жизни (зато вполне может вылезти в неприятную неожиданность для другого). Сама концепция вызова несуществующего в классе метода, кажется предельно странной, даже, например, с целью проксирвания вызова в другой объект. Собственно от того у меня и вызвал этот метод подобную реакцию.
                • +2
                  >всё же в нём несогласованность распространяется только на именование функций
                  PHP — это изначально скриптовый язык, в котором никакого ооп не было и в помине. Нормальное ооп было добавлено в 5й версии (и то что-то слабо мне верится, что в нем сейчас нет проблем). От этого очевидно, что пхп программисты стали использовать нормальные практики построения серверных приложений, использовать шаблоны программирования и т.п. относительно недавно. Собственно это видно даже по исходникам старых движков. На php я работал лет 6-7 назад, после чего я пересел на Java и с удовольствием кидаю какашками в этот язык (да, мб за последние 2-3 года он стал лучше, но почему меня это должно волновать, когда есть божественные Java/python/nodeJs). Лично мое мнение, если знаешь те же JAVA/Scala/Python/JS(NodeJS), то единственной причиной использовать этот недоязык — тебе за это платят, или твои знания в другом языке никому не нужны.

                  >JS вообще на всю архитектуру языка
                  Это ж какая такая несогласованность в архитектуре языка, расскажите пожалуйста? На JS как и на любом другом языке можно писать красивый код, использовать хорошую архитектуру приложений, а можно говнокодить.

                  1) Передача по ссылке означает передачу по ссылке и ничего больше, в js все объекты передаются по ссылке. Object.observe нужен для чека и обработки изменений в объекте, например, в angular реализован свой дерти чек для scope (благодаря этому там не нужны сеттеры и геттеры), и он является основой этого фреймворка. Причем тут передачи по ссылке или значению я не могу понять, developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/observe

                  2) В спеке языка ясно говорится для чего нужен метод __call, все остальное является реализацией костылей из-за отсутствия нормального механизма рефлекшена на основе нестандартного использования этого метода.(http://habrahabr.ru/company/microsoft/blog/247229/#comment_8208127) тут я описал свое мнение по этому поводу.

                  Неймспейсы — это неймспейсы, а модульность — это модульность. В JS некая отдельная реализация разделения пространства имен в принципе не нужна, так как с этим вполне справляются стандартные механизмы. И да — не засорять глобальный скоуп это действительно хороший тон (best practice) программирования на js, а не костыль.

                  Так как в стандарте ES5< попросту не был заложен механизм модульности (просто потому что реальная необходимость разработки больших сложных приложений на js возникла буквально лет 5 назад), он был реализован извне, назвать это костылем, все равно что называть костылем hibernate или реализацию любой другой технологии (тех же шаблонизаторов). (опять же в ES6 все это есть frontender.info/es6-modules/ ).
                  ($ns1 = (object)[], блин тайп кастинг из массива в объект — феерия чудовищности. (я даже специально проверил, такой синтаксис объявления массива работает с версии 5.4 только, это ж просто пипец 20 лет языку и до осознания, того что нужен краткий синтаксис создания массива, только пару лет назад додумались).

                  Ваш js-way — это какой-то ваш манямирок, основанный на каких-то шаблонах разработки фронтенда из прошлого 10летия и попытки перетащить багаж знаний полученных при разработке на великолепном php во вселенную с другими физическими законами. Стеки технологий и архитектур js приложений сейчас шагают семимильными шагами, так что стандартизация языка просто не поспевает за ними. JS это не PHP в который понапихают быстренько непонятно что лишь бы хоть как-то работало.

                  Мне кажется, вы просто не хотите понять что js это не ооп язык, но его архитектура настолько универсальна, что уже 20 лет без особых изменений позволяет реализовывать стек современных технологий, в том числе позволяет использовать и ООП подход при разработке (да, нет полной поддержки инкапсуляции). И что сравнивать его с oop ориентированными языками — это глупое занятие. И думать при разработке js приложений через ооп тоже не совсем верно, а уж тем более через php (динамическое создание методов класса с помощью __call? зачем в js __call если методы\поля можно и так динамически создавать). Но опять же, ES6 — хочешь классический ооп — получай.

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

                  Тоже самое реализовывается и на js pastebin.com/6xYe8hF5, само собой что бы код понять, нужно попытаться хотя бы понять, как работает js, точно так же как и человеку, которому синтаксис кофи не знаком, надо в нем разобраться.
            • 0
              Всё, что рекомендуют при разработке на JS — это функции и функции, хотя php-ньюблам за это буквально руки отрывают

              Есть обычные функции, типа как в php4 или С, и есть функции высшего порядка, как в js. Так вот не поверите, но с помощью последних можно писать очень лаконичный код. Собственно все функциональные языки программирования используют функции как основной способ абстракции.
      • +1
        Даже в посте про JS, кто-то умудрился наехать на PHP. А так комментарий несколько не корректен. Никто не восхваляет JS. Есть ряд вполне объективных причин, почему он популярен.
      • 0
        Ну прям php4? Это ничего что у js из коробки и объекная модель и функции высшего порядка.
    • –4
      Да, в AS3 очень удачно встроена типизация. Но все же AS3 уже прошлый век, нет новых модных штук, нерешенная (вроде бы) проблема с утечкой памяти при использовании. Есть отличный новый язык Dart, но в нем мне не хватает простых объектов из AS3 и JS.
      • +7
        Есть отличный, новый стандарт ES6. Зачем нужен этот мертворожденный Dart мне не ясно до сих пор. Хотя, очевидно, что он не нужен и не взлетит, как тот же GWT, особенно с учетом скорого ES6.
        • +1
          Ларс Бак крупнейший спец по имплементации виртуальных машин и jit-компиляторов, исходя из своих познаний в этой области он хотел сделать идеальный язык, который сразу учитывает JIT и VM тонкости ещё на уровне дизайна языка. То есть в первую очередь скорость работы кода, эффективность сборщика мусора, скорость DOM manipulation.
          • +3
            Я не спорю, что как язык он крутой. Суть в том, что он просто не взлетит ибо вряд ли Mozilla, MS, Apple будут его внедрять в свои платформы, а транслированный в js dart работает медленнее. Ну это, конечно, мое мнение.
            • 0
              Ну даже если DartVM встроят в хром, это уже половина рынка. А вторая половина будет работать на dart2js, который не сильно медленнее js.
        • +1
          Мне кажется тут имеет место быть не только желание просто выпустить новый язык, а еще и исследовательская работа. Даже если язык не взлетит — это опыт, который потом будет и дальше транслироваться в продукт.
        • 0
          Новый стандарт ES6 хорош всем, кроме того, что он пока не реализован в браузерах. Без реализации ES6 и внедрения DartVM в Chrome оба языка — хромоножки, портирующиеся в старый js.

          В самом дарте и его потенциалах ничего плохого я не вижу. Почему он мертворожденный? Он начинает куда как лучше, чем самый первый js. Всего лишь дело времени и будет много проектов на нем, так же как сейчас есть куча проектов на coffee и typescript.
  • 0
    > Удивительно, но одним из направлений роста нативной разработки на JavaScript неожиданно становятся умные телевизоры (например, LG с Open webOS), а также игровые консоли (например, Xbox One). Здесь просто нет альтернативы…

    ну это не совсем так. в смарт ТВ разработка на js относится в сфере 3rd party приложений, но есть ещё NDK для действительно native.
    • 0
      Ну понятно, что и под консоли есть возможность разработки и на «действительно» native. Я скорее про то, что классическая прослойка в виде ограниченного webview постепенно расстворяется.
      • +1
        А вы думаете в смарт ТВ не веб-вью? Фактически там просто браузер во весь экран. Более того, если предыдущие платформы, вроде LG Netcast и Samsung SmartHub довольно сильно расширяли доступный функционал браузера, то современные, такие как LG WebOS и Samsung Tizen по функционалу не далеко ушли от стандартного HTML5. И при этом это все дико тормозит, хуже чем на мобилках в WebView.
  • +11
    Интересно, что в итоге произойдет со всеми языками-надстройками типа typescript, coffeescript и прочими, что появятся. Как будет через пару лет выглядеть вакансия фронтенд-разработчика? На мой взгляд уже сейчас порог вхождения во фронтенд — один из самых высоких в ИТ. Не столько из-за сложности идей, которые скрываются в этом направлении, сколько из-за их количества и кривизны.
    • 0
      Про TypeScript более-менее ближайшая перспектива понятна: перейти в надмножейство ES6. Есть мнение, что подобные надстройки должны собственно стать локомотивом развития языка, или, как минимум, площадкой для экспериментов.
    • 0
      Сильнейшие диктуют условия и с этим приходиться как-то жить и подстраиваться. Сейчас все начали болеть статической типизацией и es6, количество языков и их генераторов растет каждый день, все хотят привнести что-то новое в js и это здорово. Тот же Typescript стал популярен из-за своей легковесности и прозрачной кодогенерации, все соскучились по типам, Хейлсберг и его команда делает правильные вещи. Но все же есть сакральные проблемы: язык отделяется от платформы, время трансформации в «обычный» js растет, отладка кода кастрированная (привет source maps), количество подходов и норм увеличивается и с этим надо считаться. Все забыли что комфорт не только в языке, но и в скорости, и в тулчейне, и в отладке.
      Я вспоминаю свои первые дни в вебе с GWT. Уж до чего тяжелая и сложная платформа, которая работала на ура, с нормальной отладкой и ide, быстрой подменой кода кроссбраузерностью. Сейчас, на мой взгляд, этим требованиям удовлетворяют только Clojurescript и Elm.
      Проблема большого выбора и разроненности сильно бьёт по удобству и комфортности разработки. Я ставлю на монолитные решения поверх js, за ними сила.
      • 0
        Dart целиком и полностью удовлетворяет требованиям которые вы предъявляете. И он реально легкий в освоение и простой в использовании. А отладка там вообще песня.
        • +1
          Dart от Google. Флагманский продукт, что может пойти не так? Наверно то-же самое, что сделало Angular2 никак не совместимым с Angular1… При том, что Angular первый я юзаю 1,5 года, а второй жду, я бы был поосторожней с продуктами Гугла.
  • 0
    Передайте разработчикам Cordova, что вон та затея их была весьма остроумною: складывать компоненты приложения Cordova в папку «cordova_components» (подобно тому, как Bower складывает в «bower_components», а npm складывает в «node_modules») — это важный шаг к логичности и обозримости структуры подкаталогов, а значит, и к простым файлам «.gitignore» также.

    Жаль, что затея та не окончилася ничем существенным.
    • +1
      Обязательно передам.
  • +29
    Одним словом, тренды в 2015 будут такие же, как в 2012.
  • 0
    Кстати, последний релиз Prototype вышел в апреле этого года, т.е. умирать он не спешит :)
    • +9
      С возвращением в прошлое!
    • +1
      В этом году еще не было апреля, на календарь взгляните :)
      • 0
        Аа, я не сразу понял, что имел в виду DenimTornado.

        Конечно же, имелся в виду 2014 год :).
  • –3
    Который год пытаются сделать из js нормальный язык, в то время как давно пора любой нормальный язык засунуть в браузер. Хотя бы по типу NaCl.
  • –2
    Объясните мне, пожалуйста. Почему в браузере не сделать возможность выполнять какой-то байт-код и не дать возможность писать на любом языке который в него умеет компилироваться? А джаваскрипт оставить как скриптовый язык для вызовов на странице. Ведь сейчас уже все понимают, что джаваскрипт не подходит для современных нужд разработки и пытаются делать более подходящие языки, которые компилируются в js.
    • 0
      Native client же об этом.
    • 0
      Вероятно из за того что язык сам по себе это еще не гарантия того, что новые приложения будут разрабатываться быстрее, будут надежнее и т.д. Есть еще экосистема, где много библиотек на все вкусы, есть устоявшиеся паттерны. Так что просто взять и выбрость годы наработок не получиться. А вот сделать нормальный интероп между языками — это задание не из легких.

      Кроме того js не такой уж и страшный зверь как его все выставляют, жить можно, немножко подправить и все будет ок (ES6).
      • 0
        Так что просто взять и выбрость годы наработок не получиться.

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

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

        Конечно не гарантия. Только я ничего не писал ни о гарантиях, ни о зависимости языков от скорости и надежности приложений.

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

        В такой ситуации минимальная интероперабельность всё равно будет, потому что в итоге все они будут компилироваться в одни и те же сущности платформы, а если у них еще будут общие средства для работы с браузером, то этого уже будет достаточно, чтобы использовать наработки друг друга.
  • +13
    Не статья, а сплошной Windiws. Это не тренды, это технологии, используемые в ОС Окошки. Да, хаб очевиден, но слишком пафосный заголовок. Учитывая, что в трендах и линуксы (андроидов десятки миллионов) наверно стоит обратить внимание на веб, как самобытное целое, а не часть виндовс.

    Так же интересны планы по внедрению и реализации asm.js?)

    Почему упущен второй общедоступный движок Unreal Engine, который имеет меньше игр по количеству, но качество игр великолепно покрывает количественную составляющую?) Поддержка webgl и портирования в браузер была выведена в рабочий релиз раньше юнити.

    Говоря о TypeScript упущен его брат CoffeeScript, это потому что он не спонсирован ГК Мелкомягкий?

    Говоря о геймпадах умышленно были опущены замечания, что этому стандарту предстоит эволюционировать?

    Говоря о кроссплатформенности имеется ли в виду так же абстрагирование от операционной системы в целом и поддержка, влияние и развитие интерфейсов взаимодействия с ОС?)
    • –2
      «CoffeeScript» стоит упомянуть, что я пока видел ровно 1 его апологета, а вот на TypeScript переходит уже третья моя команда.

      «Говоря о геймпадах умышленно были опущены замечания, что этому стандарту предстоит эволюционировать?» а какому web стандарту не предстоит?
    • 0
      опа, а че веб это не часть виндовс???? %)
  • +2
    Про WebPack забыли.
  • 0
    Спасибо за статью — это как раз то, о чем я думал последние 2 года, причем независимо от трендов, просто так совпали мысли и выбор перспективных технологий.
  • +6
    В разделе про API можно было бы еще упомянуть WebRTC, понятно, что Microsoft тут пока похвастаться нечем, но тем не менее :)
    • +1
      Microsoft и Apple не будут внедрять WebRTC по тем же причинам, что и WebP и WebM :)
      Например, Microsoft решили вместо WebRTC имплементировать ORTC.
      • 0
        ORTC — это просто API, на низком уровне оно совместимо с WebRTC. Да, веб-разработчикам придется делать всякие shimы и т.д., но главное — совместимость на низком уровне — протоколы передачи данных, аудио/видео-кодеки и т.д.
        • 0
          Так Microsoft вряд ли будет поддерживать VP8.
          • 0
            Это не так важно, оба кодека были приняты как MTI для вендоров браузеров. Кто хочет, чтоб его браузер назывался WebRTC-совестимым дожлен будет реализовать поддержку как VP8, так и H.264
  • –3
    У меня вопрос к kichik
    Поясните пожалуйста почему в перечисляемых вами решениях ни разу не встречается Dart? Ваши тезисы стали бы полнее с его упоминанием:
    1) Новый стандарт ECMAScript 6. Утверждение, реализация в браузерах, адаптация в сообществе и фремворках. — Dart поддерживает все то что ожидается в ECMAScript 6 уже сейчас(из самого вкусного поддержка классов и модулей).
    2) Рост использования TypeScript в реальных проектах, развитие альтернативных проектов и их взаимное обогащение. — Да, рост наверное может получиться, а может не получиться. Как и у всех альтернативных проектов. Рост использования сильно зависит от богатства стандартной библиотеки, активности сообщества разрабатывающего сторонние библиотеки и возможностей простого использования уже существующих JS библиотек.
    3) Развитие инструментов для кросс-платформенной разработки на JS, продолжение стирания границ между сайтами и приложениями. — Да, писать приложения на Dart для Apache Cordova и веб-сайтов тоже можно уже сегодня!
    4) Рост умных телевизоров и консолей с разработкой на JavaScript, нативная разработка на JS на многих современных платформах (но не всех). — Dart транслируется в JS, а отладка на нем намного удобнее

    6) Новые переработанные версии популярных библиотек, повышение входного порога для создания комплексных фреймворков, нишевые решения на базе ES6. — За счет стандартизованных требований к публикуемым модулям в Dart создание новых модулей и фреймворков упрощается, а их качество выше.
    7) Адаптацию веб-компонент браузерами, принятие новых технологий разработчиками элементов управления и различных фреймворков. Polymer.dart — все работает уже сейчас в любом современном браузере
    8) Принятие менеджеров пакетов и систем сборки для JavaScript в корпоративной и учебной среде, интеграция в популярные инструменты веб-разработки. — Darteditor содержит менеджер пакетов и систему сборки из коробки

    11) Адаптация Node.js в корпоративной среде, адаптация нового ES6 в самом Node.js. Запасаемся попкорном и смотрим историю с форком io.js.- Dart позволяет писать серверную часть и отладка ее намного проще чем борьба с коллбэк хеллом в Node.js. Можете поискать как создатель Node.js отзывается о Dart.
    12) Облачные решения для IoT на базе Node.js, новые экспериментальные проекты на клиентской стороне. — На Dart вы можете писать облачные решения для Google Cloud Platform. Т.е. на одном языке вы можете писать для Клиента, Сервера, Облака
    • +4
      Я думаю, если вы напишите статью «X трендов Dart в 2015г.», многим будет интересно почитать.
    • +1
      Требуется больше болда!

      Всем комментариям в стиле «Dart крут! смерть js» хочется задать один вопрос: а есть ли вообще хотя бы один крупный проект на Dart? Кто его действительно использует? Если даже официальная страница дарта написана на классическом js и обфусцирована (либо дарт наконец научился генерировать простой js, а не 40 000 строк для хело ворлд).
      • +1
        Речь не идет о том, что язык программирования X — крут! смерть js
        Суть комментария: смотрите, большинство того, что рассматривается как тренды 2015 года было доступно уже в 2014. Доступно для тех кто не увлекается религиозными войнам, страхами непрогнозируемого будущего и подбирает инструменты для разработки по принципу достаточности их функционала для решения реальных текущих задач.
        Кто использует? — www.dartlang.org/community/who-uses-dart.html
        Ну и реальные выгоды от использования Dart будут от командной работы над проектами несколько отличающимися по сложности от хело ворлд. И если на таких проектах у вас будут проблемы со скоростью загрузки приложения на современных каналах связи — в рамках языка есть функционал отложенной загрузки www.dartlang.org/docs/dart-up-and-running/ch02.html#deferred-loading
        • +1
          Практически все из этих трендов было доступно еще и до дарт, даже еще в прошлом тысячилетии. Взять тот же питон. Разве что он не очень распространен для веб-страниц (впрочем, есть транслятор).

          В данном случае показаны тренды конкретно js. И очень приятно, что язык в последнее время бурно развивается и становится только лучше.
          • –1
            Typescript это тренд конкретно js?
            • +1
              Думаю, что препроцессор для js можно назвать трендом конкретно js. Насколько он правда станет популярным — сложно сказать, и я бы обобщил до вообще всех различных препроцессоров, но суть это не меняет.
    • –1
      «Рост использования сильно зависит от богатства стандартной библиотеки, активности сообщества разрабатывающего сторонние библиотеки и возможностей простого использования уже существующих JS библиотек.»
      — эм, вы вообще представляете себе, что такое TypeScript? Все, что вы описали, это как раз проблемы Dart с его пропихиванием своей виртуальной машины поверх JS. TypeScript это и есть JS — BCL у него нет, сторонних библиотек тоже, потому что он сам JS и работает с либами JS как таковой.

      «Dart транслируется в JS, а отладка на нем намного удобнее»
      — а вы смотрели на пезультат транслитерации? А теперь сравните это с тем, что в TS результат транспиляции зачастую МЕНЬШЕ по объему, чем исходный код (еще до любых минификаций).

      • –2
        Про "… пропихивание виртуальной машины поверх JS" — все несколько не так. Происходит трансляция dart кода в js код после отладки и перед выкладыванием в продакшн. Чтобы этот JS мог работать в любом браузере. И в случае появления Dart VM в браузере трансляция уже не нужна, нативно можно выполнять dart скрипт. И он будет выполнятся примерно на треть быстрее чем транслированный JS. www.dartlang.org/performance/
    • 0
      > Поясните пожалуйста почему в перечисляемых вами решениях ни разу не встречается Dart?

      Вероятно, потому что Dart мертворожденный проект, который никому не нужен даже в Гугле.
  • +1
    Unity 5 с рендерингом в WebGL, развитие 3d и игровых библиотек, потенциальный прорыв через социальные сети.


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

    Маркетиниг у них хороший. В своей области не хуже, чем у Apple в своей. Наступает быстрее, чем успевают авторы средства разработки. Но есть и мнение, что никакого прорыва не будет. Кроме как канализационной трубы, по которой идет поток в мозг от маркетологов.

    Если речь идет о плагине — производительность зависит от плагина.
    Если речь о жизни «без плагинов» — чего вам накосячят в браузере авторы браузера, то там так и останется, какой бы крутой средой разработки не являлся «без плагиновый» движок.

    У меня, например, хороший десктоп (i7 4770, Nvidia GTX 650 ti). В FireFox этот самый WebGL выдает ровно в 2 раза меньший FPS, чем в том же Chrome. А ведь есть еще и другие браузеры, которые имеют большую долю рынка. На мониторе 2560х1440 плагины рубят 3D в разы производительнее, чем этот преславутый WebGL. Кому такой WebGL нужен? Ну донатерам уж точно он не придется по душе.

    Игры в социальных сетях: здесь все еще очень большое засилие Flash, но, возможно, если игры в Facebook и VK станут доступными в их мобильных приложениях, то это откроет второе дыхание для игр на HTML/JS.


    Если компания делает Flash приложение для соц. сети — она не плюнет на годы разработки, чтоб сделать JS мобильное приложение из своей Flash или Unity игры — убожество на JS, которое упрется в Canvas. Они либо на нативе напишут его, чтоб получить производительность, либо портанут тот же браузерный Flash на мобильный Flash через Adobe AIR, чтоб сохранить максимальное количество кода.

    Общался с заграничными компаниями, которые делают игры для соц. сетей. У них нет планов переходить на WebGL в ближайшие 2-3 года, если не случится революции в этом плане. А её не случится. Скорее новый формат взаимодействия появится.

    Развитие инструментов для создания графики и анимации в рамках веб-стека. Традиционно (в смысле наследия от Flash) тут большое внимание стоит уделить продукции Adobe (Edge-семейство) и библиотекам, близким по духу к Flash и ActionScript, например, CreateJS.


    Adobe Flash Professional CC чудесно умеет экспортировать контент в CreateJS. Тем более, что Adobe спонсирует разработку CreateJS как раз из-за того, что теперь из IDE можно контент под CJS собирать. А вот Edge-же работает с html dom.

    Развитие API доступа к нативным возможностям устройства из JavaScript

    С условем, что JS это JIT — будет не более, чем помигать фонариком (подсветка вспышки) и сделать фотографию с разрешения пользователя.

    Рост умных телевизоров и консолей с разработкой на JavaScript

    При росте % телевизоров увеличения мощности их процов, сопоставимой с требованиями современного контента — просто не будет. Соотв. там JS будет на том же уровне, как и сейчас. А торрент клиент на JS не напишешь, ведь.

    Вчера крутил два разных смарт ТВ. Один LG и другой Phillips. На лыжах видео на сайте вообще во флеше запустилось, а в html5 даже не стартануло (не знаю по какой причине). На другом сайте html5 игра тормозила как черепаха.

    У филипса чуток было лучше всё. Но без планшета, который как remote выступает — играть не удалось даже на уровне «получится или нет». В итоге, я просто пошел в Google Play, скачал нормальную игру не на JS и остался более довольным, чем от интимной близости с «высокими технологями» в телевизоре, где есть номинальный логотип html5.

    Будущее

    Я вижу лишь такое будущее у JS, которое ничем не будет отличаться от последних 2х лет.

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

    А потом, вместо адекватной работы — сидеть и наблюдать дикие лаги на планшете, т.к. 100500 фреймворков подключено (первый для определения размера экрана, второй узнает пользователь с мышкой или без, третий узнает версию браузера, четверый загружает эти все фрейморвки, пятный для работы с local store и т.д.). Извольте. Мне такого будущего не надо. Я это имею уже сегодня, вчера и позавчера.

    В 2015 году желаю, чтоб JS стал просто как ActionScript 3.0 или Java. Это так же естественно хотеть, как маленькая девочка мечтает стать женщиной. А станет она вместо этого сельской бабой или куртизанкой — время покажет.
    • 0
      Торрент-клиент таки есть jstorrent.com/, вполне норм работает, хотя с файлами некоторых трекеров и не дружит.
      • 0
        Ну т.е. он завязан на одном браузере одного компонента и никогда не встанет в других виртуальных машинах? Тогда это не более, чем техническое решение для гиков.
        Упрощаю свою мысль — Лада Калина тоже машина и тоже ездит :)
  • +2
    Статья напомнила)

    image

    В хорошем смысле. Сам в 2015 делаю ставку на углубление знаний JS и инфраструктуры.
  • +1
    2. Типизированный JavaScript

    Как раз недавно обсуждали плюсы и минусы статической типизации.
    Есть у меня опасения, что TypeScript, Flow и пр. превратят JS в CSharp.
    Ведь успех и гибкость JS в его:
    а) простоте — всего 7 базовых операторов делают его привлекательным и комфортным для входа новичков, которые втянувшись начинают развиваться, что делает JS самым популярным;
    б) свободе и демократичности — мы можем использовать подходы, наиболее подходящие как проектам, так и их отдельным частям.

    Если обратить фокус на сам вопрос типизации.
    Было бы интересно услышать преимущества статической типизации перед директивами в стиле jsdoc:
    /**
     * @param {object|object[]} recipients - one recipient or collection of them
     * @param {string} message - message body
     * @param {boolean} [system=false] - message type
     */
    var sendMessage = function (recipients, message, system) {
    // ...
    };
    /**
     * @param {...string} parts
     * @example 
     *   var users = activeUsers.map(function (user) {
     *     return user['id'] + ":" + user["login"];
     *   });
     *   sendLog(“activeUsers: ", _users);
     */
    var sendLog = function () {
    // ...
    };
    


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

    В целом, директивы, как элементы изначально направляющие компилятор (вспомним хотя бы C++), а теперь пре-процессоры достаточно давнее и удобное явление.
    К примеру, мы имеем большой проект и использовали jslint:
    /*jslint vars: true*/
    

    Но в какой-то момент решили переключиться на eslint.
    Этот подход не обязывает нас рефакторить весь проект — мы просто меняем директивы в новых модулях и постепенно обновляет прошлые:
    /*eslint eqeqeq:0, curly: 2*/
    

    Тут мы замечаем важное качество — изолированность директив. Они не влияют друг на друга и могут обрабатываться в любом порядке. В то время, перенося контроль типов, как сервисную операцию, в надмножество языка и тем самым меняя язык (как в примере Flow, TypeScript и пр.), мы не можем так свободно и прозрачно их комбинировать и связываем себе руки.
    Например, подход React создал необходимость появления JSX. Но как JSX будет сочетаться с TypeScript? Какой пре-процессор должен сначала пройти по исходному коду? И сочетаемы ли они вообще?

    Мне кажется, было бы полезней развивать и перерабатывать jsdoc и пре-процессоры для его обработки, оставив языку свободу. В современном мире веб-разработки итак хватает проблем с интеграцией решений между собой и об этом я писал в своей недавней статье.
  • +1
    module math from «lib/math»;

    Такое определение модуля выпилено из спецификации в октябре прошлого года.
  • 0
    Тренды какие-то прошлогодние, если честно.
  • 0
    Согласен с комментаторами, которые говорят, что JS всё больше будет походить на ActionScript. Если бы разработчики браузеров просто взяли бы документацию по AS3 и Flash API и реализовали бы их, то можно было бы сэкономить 5-10 лет бессмысленных метаний и велосипедостроения.
    Но увы граждане будут биться головой об стену, а каждое продвижение вперёд выставлять, как эпохальное событие. Помню как пару лет назад мне доказывали, что классы и статичная типизация в JS не нужны. А теперь все с нетерпением ждут ES6.
  • +1
    Компания майкрософт за последние годы подарила индустрии три версии браузера, каждая из которых имеет свои глюки, значительно тормозит и удорожает разработку веб приложений. Ох, не вам писать про тренды js 2015 года.
    • 0
      Понять и простить…
  • 0
    Вот и заканчивается 2015-й год… Что же из прогнозов в статье подтвердилось? И будет ли статья про 2016-й год?
    • 0
      Да, думаю над подведением итогов и новой статьей в праздничные дни.
  • 0
    Тут был спор про Dart, пришлось за год попробовать этот язык в разработке и честно признаться он мне весьма понравился. Есть сомнения, что он станет популярным, но обратить внимание на него все же стоит. Не буду тут расписывать интересные плюсы здесь, пост все же про js, но так вспомнился прошлогодний спор на тему. :)

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка