Я решил написать этот материал после того, как увидел твит Дэна Абрамова, за который хочу сказать ему огромное спасибо. Дэн задал своим подписчикам вопрос о самых интересных событиях в мире JavaScript, которые достойны внимания широкой общественности.
Любители JS на вопрос откликнулись, под твитом собралась целая гора ответов. Каждый говорил о том, на что, по его мнению, стоит обратить внимание в 2017-м году. В результате получилась весьма занимательная подборка, из которой я выбрал всё лучшее и добавил пояснения.
Сразу хотелось бы сказать вот что. Судя по тому, что средства функционального программирования видны в моём материале, что называется, невооружённым глазом, время, когда ФП было уделом немногих, бегающих за переменчивой модой, прошло. Теперь это выглядит вполне себе серьёзным трендом.
Вот технологии, отмеченные JavaScript-сообществом как наиболее перспективные. Я расположил их в порядке убывания популярности.
WebAssembly
Эх, с чего бы начать объяснять особенности технологии WebAssembly? Её сокращённое название, «wasm», выглядит почти как «asm», а это – намёк на то, что перед нами – нечто низкоуровневое. На самом деле – так оно и есть. Эта технология нацелена на упрощение разработки на любом языке (радуйтесь, любители функционального и реактивного программирования!) и компиляцию кода для веба.
Технология WebAssembly пришлась по душе многим. Дело в том, что уйма разработчиков всё ещё находится в весьма неоднозначных взаимоотношениях с JS, отдавая безусловное предпочтение другим языкам, код, написанный на которых, можно преобразовать в JavaScript. Ниже – масса подтверждений этой идеи.
В любом случае, JS движется вперёд семимильными шагами, и никто не ждёт, что это скоро прекратится.
WebAssembly – разработка сравнительно молодая. Сейчас она находится в фазе ознакомительной версии, до релиза ещё далеко. Таким образом, уверен, что за её развитием стоит понаблюдать, так как она способна очень серьёзно повлиять на будущее JS.
Подробности о WebAssembly можно почитать в материале Эрика Эллиотта.
Elm
Множество разработчиков буквально влюбилось в Elm в 2016-м. Это – доступный всем желающим язык функционального программирования.
Вот выдержки из «Введения в Elm», раскрывающие основные особенности языка:
- Нет ошибок времени выполнения, null, сообщений в духе «undefined is not a function».
- Удобные сообщения об ошибках, которые помогают быстрее расширять программы.
- Хорошо спроектированный код, который остаётся таковым по мере роста приложения.
- Автоматический семантический контроль версий для всех пакетов Elm.
Elm – это отличные инструменты, скомбинированные с чистым, простым и компактным кодом.
Конечно, Elm компилируется в JS, что и привлекло к нему внимание JavaScript-разработчиков.
Vue.js
В прошлом году было очень интересно наблюдать за тем, как росла популярность Vue.js. Эта библиотека, несомненно, будет заметным игроком и в 2017-м.
Я, кстати, благодаря Эвану Ю, бесстрашному создателю Vue.js и лидеру сообщества, вдохновился в прошлом году идеями Open Source.
Vue – это конкурент React, поэтому совершенно естественно то, что в 2017-м нас ждут бесконечные споры о том, что лучше: React, Vue, или Elm (вот здесь народ уже обсуждает эту тему). В итоге всё решит то, какое сообщество предложит лучшую поддержку больших проектов. Полагаю, Эван Ю знает, что надо делать.
Недавно вышла версия Vue 2.0, она стала быстрее и меньше, что делает эту библиотеку ещё привлекательнее.
Кстати, вот пара ответов на вопрос о том, почему некоторые компании перешли на Vue.
Babili (babel-minify)
Babili вышел в августе 2016. Это – минификатор, умеющий работать с ES6+, основанный на инфраструктуре Babel.
Зачем ещё один минификатор?
Вот отличный рассказ Генри Жу о причинах появления Babili. Полагаю, важно обратить внимание на следующую его часть: «Babili может принимать на вход конструкции ES2015+, в то время, как существующие минификаторы обычно ограничены ES5. Они требуют, чтобы код был транскомпилирован в поддерживаемый ими вариант языка перед минификацией. Это становится бесполезным, если учесть, что программисты уже создают рабочие проекты на ES2015. Babili, кроме того, гибок, и имеет модульную структуру (фактически, это набор предустановок Babel, что означает поддержку плагинов), его можно использовать как пресет или как инструмент командной строки. Кроме того, Babili сможет выполнять оптимизации кода, специфичные для ES2015+».
OCaml
Сам по себе OCaml не особенно связан с JS, но для того, чтобы осознать важность двух следующих трендов в нашем списке, вам нужно будет знать о том, что такое OCaml.
Если вы наблюдаете за возрождением функционального программирования, идущим последние несколько лет, вы могли слышать о Haskell. OCaml быстро становится популярнее, чем Haskell, преимущественно из-за того, что существует несколько отличных компиляторов из OCaml в JS.
Разработчики Facebook, например, являются большими фанатами OCaml, так как он помог им создать Hack, Flow и Infer.
BuckleScript
BuckleScript – это компилятор для OCaml, созданный командой разработчиков Bloomberg (да, это тот самый Bloomberg). Вот что об этом рассказывает Дуэйн Джонсон: «BuckleScript, или, для краткости, bsc, это сравнительно новый JavaScript-компилятор для OCaml. Другими словами, вы можете использовать функциональный, типизированный язык OCaml для компиляции кода на нём в JavaScript. Замечательно здесь то, что код, производимый BuckleScript, вполне читаем (то есть, если вы знакомы с JS, код этот можно понять, его легче будет отлаживать), а также – то, что BuckleScript связан с экосистемой npm. В итоге вы получаете лучшее из двух миров: мощный, функциональный, типизированный язык, увязанный с замечательными современными библиотеками для веб-разработки».
ReasonML
Reason – это язык, построенный на базе OCaml, обладающий невероятно дружелюбным синтаксисом, глубокой интеграцией редактора и отличными средствами сборки. Его создала та же команда из Facebook, которая приложила руку к React.
Вот отличный краткий рассказ Шона Гроува о Reason.
PureScript
Очевидно, вы уже догадались, что PureScript – это ещё один строго типизированный эффективный язык программирования, который компилируется в JavaScript.
Он особенно популярен среди любителей Haskell. Можете считать его конкурентом Elm. Вот, что предлагает нам PureScript:
- Отсутствие тяжёлой среды исполнения кода.
- Применение стратегии строгих (а не ленивых) вычислений, похожей на применяемую в JavaScript.
- Поддержка литерального способа описания объектов JavaScript
- Система типов, которая, пожалуй, мощнее и удобнее, чем в Haskell.
- Предельно простой интерфейс внешних функций, который облегчает взаимодействие с JS-библиотеками.
TypeScript
TypeScript – это надстройка над JavaScript, которая призвана улучшить качество и понятность кода. Кроме того, TypeScript облегчает процесс разработки, указывая на ошибки прямо в процессе ввода текста программы. И, кстати, редактор Atom поддерживает TypeScript.
Вот подробный рассказ Андерса Хейлсберга о TypeScript.
Webpack-blocks
Это – хороший способ конфигурирования Webpack. Пожалуй, главный аргумент в его пользу высказал Дэн Абрамов: «Очевидно, Webpack не собирается становиться высокоуровневым инструментом. Поэтому его конфигурирование имеет смысл отдать внешним средствам. Настройки должны быть представлены в виде хорошо спроектированных блоков, а не в форме копирования и вставки фрагментов текстов с параметрами».
Если вы пользуетесь Webpack, у вас есть хорошие шансы найти полезное применение webpack-blocks.
GraphQL
Такое ощущение, что GraphQL заменит REST, особенно в компаниях, которым приходится обрабатывать огромные объёмы данных. Вот пример, который поможет понять – почему это так. Главная мысль: GraphQL эффективен до предела. Полагаю, мы продолжим наблюдать за ростом GraphQL в 2017-м. А о том, заменит ли он REST, поговорим через год.
React Storybook
Это – среда разработки пользовательских интерфейсов для React / React Native. С её помощью можно визуализировать различные состояния компонентов интерфейса и работать над ними в интерактивном режиме.
Взгляните на эту картинку, и сразу поймёте, в чём тут дело.
React Storybook можно найти здесь.
jQuery 3.0
Прадедушка jQuery всё ещё с нами! Команда разработчиков выпустила более компактную и быструю версию в июне 2016-го, но многие, увлечённые чем-то вроде освоения React, вероятно, об этом и не слышали.
Pixi.js
Если вы занимаетесь разработкой фантастически прекрасных 2D-интерфейсов или игр, использующих WebGL, Pixi.js станет для вас настоящей находкой. Взгляните на галерею проектов, сделанных с помощью этой библиотеки. Даже если ничего серьёзного вы создавать не планируете, взгляните на это прямо сейчас.
Preact
Preact.js — быстрая альтернатива React размером всего 3 Кб с тем же самым ES6 API.
Inferno
Inferno – альтернатива Preact. Это – быстрая библиотека, похожая на React, занимающая всего 8 Кб, предназначенная для создания высокопроизводительных пользовательских интерфейсов как на стороне клиента, так и на сервере. Она предоставляет разработчику больше встроенных дополнительных возможностей, чем Preact.
Rust
Rust – ещё один быстрый язык, который, с помощью emscripten, компилируется в JavaScript. Пожалуй, такое разнообразие языков вполне однозначно указывает на то, как много разработчиков больше не хотят писать на JS.
Custom Elements v1
Технология Custom Elements (вместе с Shadow DOM) испытывала проблемы с адаптацией (преимущественно из-за сложности восприятия её концепций), но она вполне может продолжить развитие в 2017-м.
Основным направлением улучшений будет поддержка браузеров, которая, как можно видеть здесь, растёт. Я думаю, что это отличный способ дать больше возможностей разработчикам, в то же время сокращая объём кода.
Вот материалы Smashing Magazine и Google, которые помогут разобраться с тем, как использовать Custom Elements.
WebRTC
Сложно поверить в то, что WebRTC уже пять лет. Facebook, Slack, Snapchat и WhatsApp применяют его в своих системах. Рост популярности WebRTC неизбежен, им будут пользоваться всё больше и больше компаний, которые предлагают пользователям аудио- и видеосвязь.
Будем надеяться, что инновации со стороны команды проекта WebRTC принесут в него лишь улучшения.
Next.js
Next.js – это маленький фреймворк, построенный на основе React, Webpack и Babel. Он упрощает создание и развёртывание React-приложений, сборка которых производится на серверной стороне.
Команда разработчиков из ZEIT, которая этим проектом занимается, весьма активна в сообществе React. Полагаю, на Next.js стоит, по меньшей мере, обратить внимание.
Итоги
Как видите, уже сейчас подобрался внушительный список JS-проектов, за которыми стоит понаблюдать в 2017-м. Полагаю, этот год принесёт нам и нечто совершенно новое. В любом случае, будет интересно.
После того, как этот материал увидел свет, читатели подсказали несколько важных технологий, которые позволили его расширить. Может быть, и вы что-нибудь подскажете?
Комментарии (87)
kernel72
09.01.2017 15:06+21Выглядит так, что основной тренд — уйти от javascript на что-нибудь другое, что конвертируется в js.
sshikov
09.01.2017 21:28+1Ну основной не основной, но что это тренд — это без сомнения. Причем даже не 2017, а я бы сказал — уже несколько лет как. ClojureScript, ScalaJS, Haskell… это все далеко не вчера началось, и возможно скоро сложнее будет назвать популярный язык, для которого нет js backend, чем такой, у которого он есть.
EviGL
09.01.2017 23:34+1По-моему просто статья так написана. Особенно весёлый намёк на то, что Rust изобрели чтобы в вебе не писать на JS :)
Видимо, он виноват в том, что компилится под llvm.
TheShock
10.01.2017 15:29+2По-моему просто статья так написана
А ибо группи писал ее — а они слепы и видят только своего кумира.
Дело в том, что Дан Абрамов — это сейчас что-то вроде короля хипстеров сейчас. И они возносят все, что он говорит) И подменяют понятия, чтобы подогонать их под понятие своей моды. Ну вроде «нравится раст? давайте всем будем говорить, что он написан для замены жс, иначе выпадаем из тренда»
«Ааа! Дан снова написал, что раньше мы все делали неправильно и сейчас так уже не делают. Надо написать ему в твиттер, что мы срочно перешем наш код на новую парадигму, чтобы быть современными!»
Данная статья — из разряда «зайти в барбер-шоп и узнать современные тренды. Конечно вы получите кучу одинаковых ответов вроде клетчатой рубашки, зауженых штанов, антикафе, голос фальцетом и тому подобное.
Показывает переменчивые тренды (а где сейчас кофескрипт? или столь трендовый в 2015 Gulp?) узкой группы хистеров, которая кажется широкой из-за того, что очень громкая.
GarretUA
16.01.2017 02:09Даже дополнить нечего :) Самое точное описание происходящего в мире JS разработки.
VolCh
16.01.2017 10:35+1И они возносят все, что он говорит)
Я тоже возношу, например он сказал, что мне не нужен Redux и я с ним полностью согласен, его статью по этому поводу даю всем читать, кто пытается меня убедить, что я отстаю от жизни, не используя Redux.
var_bin
10.01.2017 12:17Добрый день.
Ну я бы сказал не уйти, а использовать другие инструменты. Ведь на выходе мы получаем все тот же JavaScript. А данные инструменты, библиотеки, фреймворки (добавить свое) помогают избавиться от проблем и головной боли, которая есть при написании на чистом JavaScript.
kernel72
10.01.2017 13:37+1Но никто ведь не избавит от головной боли при использовании этих инструментов, которые должны избавить от боли при написании на чистом javascript :)
Мне довольно странно видеть в javascript тренде вещи, которые предлагают не использовать сам js а транспилится в него. Бесспорно, подобные инструменты набирают популярность и имеют право на существование, но я бы назвал это не трендом javasсript, а трендом чего-нить еще.
Kenya
11.01.2017 16:12иллюзия выбора как есть — ты можешь писать на чем хочешь, но все равно это будет конвертировано в js. Big brother watching you
movl
11.01.2017 18:18Можно писать на чем хочешь, но все равно вселенная будет оперировать квантами. Существует ли выбор в принципе?
Source
11.01.2017 23:40ты можешь писать на чем хочешь, но все равно это будет конвертировано в js
или в байт-код, или в ассемблер, или в нули и единицы… Прочь иллюзию выбора — даёшь перфокарты! :-)
SerafimArts
09.01.2017 15:24+3Не знаю, стоит ли относить это к "трендам 2017го" или просто к интересным релизам, но:
1) Я бы добавил Angular 4+, ну просто потому что тренд на фреймы пошли именно с него (с ангулара), имхо и это довольно крупная разработка, чтобы просто взять и забыть про него.
2) Скорый релиз Tko (Technical Knockout)
P.S. Нокаут, хоть и довольно древний и не столь известный, но всё же он является основоположником и aurelia (которая durandal, который использовал knockout), и angular (по крайней мере 2ой версии, которая выросла из durandal), и vue и многих других. Так что хоть и не совсем тренд, но релиз интересный.
KIVan
09.01.2017 17:24+1Нокаут это верная рабочая лошадка в современном мире JS хайп-библиотек со средним сроком жизни в два года. Таким бы был angular 1, если бы не полагался на дико тормозной digest cycle. К счастью, крупный Enterprise с историей существования больше 20 лет это понимает и скептически смотрит на Facebook дары приносящий.
П.С. самое забавное, что хорошие паттерны типа Redux и Immutability воплощаются на Knockout даже лучше чем в оригинальном родоначальник Хайфа по ним.questpc
10.01.2017 11:16Есть еще одна важная фича knockout — в его шаблонах не используются двойные фигурные скобки, в отличие от большинства других js-фреймворков. По этой прините шаблоны и bindings для knockout можно вставлять без экранизации в серверные шаблоны jinja / twig / blade и многие другие.
Почему авторам других фреймворков не приходит в голову что двойные фигурные скобки конфликтуют с серверными шаблонами — не понятно. Видимо думают только о SPA, забывая что зачастую полезнее гибрид обычного серверного приложения и клиентских компонентов, так сказать «полу-SPA».SerafimArts
10.01.2017 11:39У нокаута два шаблонизатора, один дженерик, основнанный на чистом и полностью валидном html и punches https://mbest.github.io/knockout.punches/ (синтаксис которого, насколько я понимаю, основан на mocha), при этом поддержка второго в tko идёт уже "из коробки", хоть и опциональна (ниже ссылка на роадмап, где интеграция завершена), такая своеобразная миграция.
Короче, в punches доступна интерполяция через двойные фигурные скобки, потрачено =)
questpc
10.01.2017 12:01Да, это ошибочное решение более поздних мэйнтайнеров. Изначально этого не было. Хорошо что хотя бы можно отключить.
SerafimArts
10.01.2017 12:31По мне — это наоборот довольно профитное решение, т.к. управляющие последовательности интерполяции точно так же конфижатся, никто не мешает заменить, например на "{!" + "!}" ну или ещё что… Но в результате pucnhes на порядок очищает вьюшку от лишнего "хлама". К примеру:
До:
<div data-bind="text: some, attr: { class: any }"></div>
После:
<div class="{{ any }}">{{ some }}</div>questpc
10.01.2017 12:40А теперь поместите это в серверный шаблон к примеру jinja2, и вы увидите зачем нужно не использовать двойные фигурные скобки. Заменить так просто не получится потому что это сломает сторонние компоненты, использующие двойные фигурные скобки. Компактность кода — не самоцель.
https://github.com/ansible/ansible/issues/4638SerafimArts
10.01.2017 13:21Заменить клиентскую интерполяцию, не серверную ;) А у нокаута я не помню плагинчиков, предоставляющих какие-нибудь шаблоны. С другой стороны, с последними релизами, где добавили компоненты и идёт движение к теневому DOM, кто знает...
С другой стороны есть другие решения, пусть и костыльные:
1) Использование raw вставок на сервере, что-то вроде{{ '{{ someVar }}' }}
2) Экранирование (например как это сделано в Laravel Blade):@{{ $some }}(на выходе тоже самое без собаки)
3) Использование компонентов. Тогда вся логика нокаута инкапсулируется внутри компонента и серверная шаблонизация вряд-ли будет на неё влиять (тут смотря как написать этот компонент, через template (тогда будет), в стиле React, вместе с классом (скомпилится внутрь) или через внешний файл (статик html можно отдавать как есть, т.е. не будет)).questpc
10.01.2017 13:29Есть binding: if, foreach, template. Это и есть шаблоны. В последних версиях еще есть компоненты.
http://knockoutjs.com/documentation/if-binding.html
http://knockoutjs.com/documentation/foreach-binding.html
http://knockoutjs.com/documentation/component-overview.html
http://knockoutjs.com/documentation/template-binding.html
Сандерсон умнейший человек что весь синтаксис сделал на html без семантически чуждых вставок. Жаль что их теперь добавили.
Да, на react сейчас спрос большой. Может быть на него и надо перейти, только очень много кода переписывать. И лишь бы к тому времени не придумали что-то новое вместо него.
vanxant
09.01.2017 23:12За Tko спасибо.
Со скоростью они что-нибудь сделали?SerafimArts
10.01.2017 01:15Т.к. это почти что переписанная с нуля либа (судя по коммитам: https://github.com/knockout/tko), то думаю что наверняка сделали.
questpc
10.01.2017 11:14Использую knockout несколько лет, в том числе binding на классы с возможностью расширения (псевдонаследования прототипами). Очень удобно. Посмотрел расхваливаемый Vue.js, там вместо обычного объекта предлагается делать binding на сам Vue и расширение функциональности очень неудобно сделано из-за этого.
При этом о Vue кричат все кому не лень, а knockout как будто-бы и нет.
Причем на knockout запросто пишутся большие приложения на es5, без всяких ужасных транспилеров.
Такое ощущение что мода и тренды затмевают здравый смысл.
Точно также на серверной стороне — предлагают мини-фреймворки на node вместо мощнейших Django / Rails / Spring, в которых функционала много больше.SerafimArts
10.01.2017 11:47+1На es6+ (es2017) или coffee на нокауте на порядок круче выходит, к примеру простенький, но довольно практичный пример (почти копипаста из продакшен кода):
class SearchViewModel { /** * @type {KnockoutObservable<T>} */ searchText = ko.observable('') .extend({ throttle: 500 }); /** * @type {KnockoutObservableArray<T>} */ results = ko.observableArray([]); /** * @constructor */ constructor() { this.searchText.subscribe(newText => this._search(newText).then(r => this.results(r))); } /** * @param {string} query * @private * @return {Promise} */ async _search(query) { let response = await fetch(`...?q=${encodeUriComponent(query)}`); return response.json(); } }KIVan
11.01.2017 17:44Смотрю я на этот код и плачу. У вас комментарии занимают больше чем сам код и содержат при этом не комментарии, а метаданные. Вы пробовали Typescript?
raveclassic
11.01.2017 18:00+1Приехали, а что не так с jsdoc? Откройте исходники какого-нибудь angular 1.
И не всегда есть возможность взять TS.KIVan
11.01.2017 23:08+1jsdoc был сносен в 2012-ом, поскольку не было альтернатив. Однако, само его наличие это признание необходимости возможности иметь типизацию. Ни один язык, который проектировался с наличием такой возможности изначально, не пошёл по пути вынесения её описания в комментарии. Объявление типа члена всегда неразрывно в них с объявлением самого члена. Их ведь не глупые люди проектировали? И команда Angular ведь не просто так решила перейти на TS с jsdoc.
П.С. за почти 4 года работы с TS я знаю лишь одно реальное препятствие его внедрить — команда ленива и не любит JS как таковой. Но наличие добротного jsdoc-а намекает, что ваша команда явно с отдачей подходит к делу, сомневаюсь, что на внедрение TS у вас ушло бы больше пары дней.SerafimArts
11.01.2017 23:39+1Ни один язык, который проектировался с наличием такой возможности изначально, не пошёл по пути вынесения её описания в комментарии.
Если я не путаю — тренд пошлёл с javadoc. Аннотации, которые нынче в джаве и появились на волне этого javadoc, как некая формализация этих метаданных.
TheShock
12.01.2017 02:39В Джаве они используются не для типизации, как в вашем коде, а для документации, это разные вещи)
SerafimArts
12.01.2017 03:03Аргумент, соглашусь. Тогда всё можно списать на привычку и желание написать понятный пример для большинства, на почти что классическом JS не используя flow или ts.
TheShock
12.01.2017 03:25Я сам некоторое время назад пришел к JSDoc и даже использовал его пару лет (еще до тайпскрипта и флоу), но поддержка IDE, к сожалению, у него не самая лучшая. Некоторые мои багрепорты в Idea до сих пор открыты (давно не проверял, каково реальное положение вещей):
https://youtrack.jetbrains.com/issue/WEB-7411
https://youtrack.jetbrains.com/issue/WEB-12679
Серьезно, ТайпСкрипт значительно лучше в этом плане, чем чистый JsDoc, хотя TS не идет ни в какое сравнение с тем, как IDE помогает разрабатывать на C#SerafimArts
12.01.2017 03:46А если TS сравнивать с flow? Имеет всё же смысл использовать TS? Я как-то пробовал, года два назад, подкупали интерфейсы и аннотации, но оно орало на каждый шаг в сторону, в результате весь код превращается в набор из any any any, плюнул и забил. Сейчас опять хочется, но опять боюсь спотыкаться об обязательные типы, которые заставляют описывать каждый шаг.
TheShock
12.01.2017 05:01+1Ну Flow — тоже хороший, приятнее чем анотации, но для полноценной разработки, конечно, в итоге стоит стремиться к полному покрытию типами) Мне, если честно, всегда хватало существующих .d.ts и не приходилось пользоваться any.
Да и TypeScript, на самом деле позволяет больше возможностей. Не вспомню точно, но какие-то проблемы с Flow были. Возможно, нельзя корректно наследоваться от дженерик класса? Вроде такого:
class ApiMessage<TItem> { item: TItem; time: number; code: string; } class UserApiMessage extends ApiMessage<User> {} class TopicApiMessage extends ApiMessage<Topic> {}
Ну то есть Flow, конечно, хороший вариант, особенно для закостенелой команды, но возможностей у него поменьше, чем у TSVolCh
12.01.2017 15:53Flow с TS пересекаются по возможностям процентов на 95 навскидку. По 5% каждый может то, что не может другой.
raveclassic
12.01.2017 16:26VolCh TS>=2.0 заметно опережает Flow.
А напомните, пожалуйста, чего нет в TS, по сравнению с Flow? Не слежу просто.
Chamie
12.01.2017 00:54Однако, само его наличие это признание необходимости возможности иметь типизацию.
Каким образом возможность описания параметров для автоматического формирования подсказок/документации в IDE говорит о необходимости типизации?
И команда Angular ведь не просто так решила перейти на TS с jsdoc.
Как это, перейти с документации на прекомпиляцию? Типы вдруг сами себе описания функционала начинают писать? В TS тот же самый JSDoc используют, если я правильно понимаю, только что упрощённый, потому что описания типов вынесены в синтаксис самого языка.TheShock
12.01.2017 02:36Так в данном случае вопрос же не в том, для чего впринципе можно использовать JSDoc, а в том, для чего он использован в коде выше, а там на 100% типизация и ничего более. Его можно заменить на ТайпСкрипт без потери смысла. Тут есть ВСЕ те же данные, что и описаны в JSDoc в оригинальном коде:
class SearchViewModel { searchText: KnockoutObservable<T> = ko.observable('') .extend({ throttle: 500 }); results: KnockoutObservableArray<T> = ko.observableArray([]); constructor() { this.searchText.subscribe( newText => this._search(newText).then(r => this.results(r)) ); } private async search(string query): Promise { let response = await fetch(`...?q=${encodeUriComponent(query)}`); return response.json(); } }
А для текстовой документации можно заюзать TypeDoc только там, где она нужна, и это будет семантически значительно правильнее. Но вы её все-равно не пишете.
SerafimArts
11.01.2017 18:12Мне не нравится писать проект полностью на тайпскрипте, ES'17 + Flow на порядок профитнее, имхо, т.к. типизация опциональна и это всё же JS в конечном итоге, который позволяет творить всё, что придёт в голову с наименьшим сопротивлением (в рамках разумного, конечно).
Плюс, наличие докблока я считаю как минимум правилами хорошего тона, даже в языках, где типизация есть, т.к. эти метаданные могут содержать не только описание типов и позволяют проще ориентироваться в коде, отделяя визуально структуры (методы и поля) друг от друга.
Короче, просто привычка писать хороший код, благо jsdoc автоматом проставляется IDE =)
Chamie
09.01.2017 15:40+2указывает на то, как много разработчиков больше не хотят писать на JS.
А они и раньше не хотели. JavaScript не настолько хороший язык, чтобы все хотели писать только на нём — разные люди любят разные языки, но для Web им всем приходится писать на одном.
tmin10
09.01.2017 15:42+5Кроме того, TypeScript облегчает процесс разработки, указывая на ошибки прямо в процессе ввода текста программы.
Хм, когда изучал Angular, писал на TypeScript в саблайме и ничего он мне не подсказывал. Как вообще язык может что-то подсказывать в момент ввода текста, разве это не функционал IDE?
MNB
09.01.2017 15:52Очевидно потому что Sublime не IDE, и без плагинов подсказывать для нового для него языка он не умеет.
tmin10
09.01.2017 16:02+2Тогда в тексте неверно указан плюс языка, это фича IDE.
Source
09.01.2017 16:30Я думаю, имелось в виду, что типизация позволяет реализовать дополнительные подсказки в IDE.
sankooo
09.01.2017 17:08+3Но сама IDE без получения нотификаций от языка не показала бы подсказки.
Chamie
09.01.2017 17:12+3Но и для этого не обязательно менять сам язык, можно, при желании, обходиться JSDoc.
gooddaytoday
10.01.2017 12:48JSDoc сильно ограничен при сравнении с типизацией typescript. С помощью JSDoc нельзя сделать обобщенные типы, например. Если в двух словах, typescript позволяет очень широко охватить все возможные конструкции кода, что избавит вас от наиболее типичных ошибок, которые могут возникнуть без строгой типизации.
Простой пример: вы удалили функцию из объекта, а она используется по всему коду. Если вы внимательны, то пробежитесь по всем местам (придется еще найти и отфильтровать похожие названия других объектов, может быть). Иначе же в runtime получите ошибку. И хорошо, если сразу после правки. А Typescript сразу укажет на эту ошибку. И это только одна полезность из сотни.SerafimArts
10.01.2017 13:32+1А ещё можно взять, написать
yarn add babel-plugin-transform-flow-strip-typesи дальше продолжать использовать JS.
bromzh
09.01.2017 18:21+3Как вообще язык может что-то подсказывать в момент ввода текста
Запускается специальный сервер как отдельный процесс, к которому могут коннектиться редакторы. Этот сервер предоставляет API для получения всякой полезной информации, например, список доступных дополнений для текущей позиции курсора.
https://github.com/Microsoft/TypeScript/wiki/Using-the-Language-Service-API
https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API
Короче, средствами языка сделали API, который используют редакторы.
Для сублайма поддержка всего этого добра пока так себе, попробуйте Atom / VS Code.
DenimTornado
09.01.2017 17:07+4React, функциональное программирование, react, react, функциональное программирование, react, функциональное программирование, функциональное программирование ну и наконец — react!
Точно тренды?movl
09.01.2017 18:17+4А в комментариях:
Angular, энтерпрайз, angular, angular, энтерпрайз, angular, энтерпрайз и конечно же angular!
А так да, функциональщине уже более полувека, а срачи все не утихают. Автор говорит, что возрождение увидел, а может просто открыл что-то новое для себя недавно и стал адептом, в общем дело каждого.
Но лично для себя в статье увидел технологии интересные, такие как WebRTC, WebAssembly, QraphQL. Правда и до статьи за ними следил, и буду следить, и действительно интересно посмотреть, что принесет 2017 нам в этом плане.
DenimTornado
09.01.2017 18:18Это очень хорошо иллюстрирует феномен Баадера-Майнхоф, то бишь каждый о своём…
justboris
09.01.2017 18:15+2Автор Inferno переходит работать над React в Facebook, так что не уверен, что у проект в 2017 году полетит без него.
MrCheater
09.01.2017 18:42Наверно, оно и к лучшему. Может автор Inferno поможет выгрести мусор из их кровавого энтерпрайзного кода.
vanxant
09.01.2017 23:24Тренд все тот же последние надцать лет. JavaScript не нравится многим разработчикам, переходящим из других областей программирования, и они пытаются сделать более лучший JavaScript под себя, типа typescript, coffeescript или, из другой оперы, jsx. Либо же притащить свой любимый %lang% и приделать к нему компиляцию в js.
Trolling mode: куча усилий над языками и компиляторами, вместо того, чтобы приложить усилия к себе и разобраться, наконец, с js, хотя бы в 2016+ версии.
spmbt
10.01.2017 02:15+12017 — WebAssembly
2018 — JS в машинном коде Intel
2019 — JS в машинном коде ARM
2021 — Elm, Rust, Go, C++ на всех платформах компилируется в JS
2025 — async/await/generators — в машинном коде Intel в 64-ядерном процессоре
2026 — датацентры на новых процессорах в каждом штате
2027 — нейронные сети захватили управление знергоресурсами североамериканского континента
2028 — уходящий президент выявил группу хакеров, которая программировала нейронные сети на чистом JS, чтобы контролировать 51% добычи сланцевого газаBeyondtheclouds
10.01.2017 10:40вы же понимаете, что webAssembly(не asm.js) это шаг в сторону ухода от js и компиляции в js, и в этом ряду вообще лишний, правда?
Zav
10.01.2017 04:14Прикольно, почитал про GraphQL.
Оказалось что схожий подход использовал в Nodejs проектах ещё в 2011 году и всё время придерживался его вместо REST'a.
Причем за это время накопилось пачка решений, хоть, вероятно и на уже устаревших фреймворках, но успешно решающая задачи.
Честно говоря все виения ни капли не удивляют, а органично выходят из времени. Достаточно взглянуть на историю почти любого популярного (в прошлом) ЯП и увидеть довольно схожую череду изобретений.
Это примерно как тебе рассказывают про новомодную nosql БД, а ты знаешь что аналогичный механизм использовался в какой-нибудь технологии ещё в 70 годах прошлого столетия. Я ничего не имею против — наоборот, это круто что находятся подобные применения и решения, просто очень интересно наблюдать.
keslo
10.01.2017 09:03+1Чем вызван такой ажиотаж вокруг языков, которые компилируются в JavaScript? Почему люди не пишут просто на JavaScript? Ведь как не ругай JS, но в итоге код скомпилируется из его базового функционала?
movl
10.01.2017 09:40Чем вызван такой ажиотаж вокруг языков, которые компилируются в машинные коды? Почему люди не пишут просто в машинных кодах? Ведь как не ругай машинные коды, но в итоге код скомпилируется из их базового функционала?
ОтветУ JavaScript монополия, так сказать, в вебе.
kahi4
10.01.2017 11:29Уже года два как даже js компилируется в js, потому что разные версии браузеров поддерживают разные возможности и все в этом духе. Да и минификация, да и статический анализ — хватает причин. Ну а раз компилировать все равно, почему бы не повысить себе удобство разработки. Мы перешли на typescript и это выглядело как глоток свободы и до сих пор ненарадуемся (вообще очень нравится рост языка, но еще есть агрехи с интеграцией).
Mexis
10.01.2017 14:02+4Значит тренд 2017 это использовать всё, кроме чистого JS и обычного написания HTML структуры.
Всё должно компилиться и генеророваться. Попробывал написать на Elm простенький скрипт со вставленным атрибутом в html элемент, который бы в коде не повторялся.
Ну и что же теперь учить? Всё? Чтото меня тошнит X-(
Автору за статью спасибо!Zav
11.01.2017 17:05Как и раньше — учить основы — алгоритмы, структуры, методологии и так далее. А зная основу (JS) — уже изучить конкретный инструмент проблем не составит.
Pavel_White
11.01.2017 16:02-4Может я не в тему но не надо минусить, нашел очень четкий хостинг, есть бесплатный тариф, но только для доменов 3-его уровня. В общем, кому надо заходите http://api.hostinger.ru/redir/16374708
anna_mela
11.01.2017 18:11-4Привет друзья разработчики))) очень-очень интересует вопрос визуализации сайтов… С помощью чего создаются такие эффекты на сайте, пример http://waaark.com/vision/
Что же надо выучить ...java...flash… или что??? это для меня загадка уже несколько месяцев, на которую так и не получила ни одного точного ответа((((
Очень прошу вашей помощи!!! :)semeni4
12.01.2017 15:55+1Нарисовано с помощью SVG, анимировано JavaScript-ом (jQuery и TweenMax, в числе прочего).
ObsSpace
12.01.2017 15:55Было бы замечательно увидеть аналогичный обзор в более Angular-образном поле. Typescript увидел, да.
jbubsk
Angular won't die!