JavaScript-тренды, на которые стоит обратить внимание в 2017-м

https://medium.com/commit-push/the-top-rising-javascript-trends-to-watch-in-2017-86d8e87db3b3#.rlple5h37
  • Перевод
image

Я решил написать этот материал после того, как увидел твит Дэна Абрамова, за который хочу сказать ему огромное спасибо. Дэн задал своим подписчикам вопрос о самых интересных событиях в мире 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.

image

Вот подробный рассказ Андерса Хейлсберга о TypeScript.

Webpack-blocks


Это – хороший способ конфигурирования Webpack. Пожалуй, главный аргумент в его пользу высказал Дэн Абрамов: «Очевидно, Webpack не собирается становиться высокоуровневым инструментом. Поэтому его конфигурирование имеет смысл отдать внешним средствам. Настройки должны быть представлены в виде хорошо спроектированных блоков, а не в форме копирования и вставки фрагментов текстов с параметрами».

Если вы пользуетесь Webpack, у вас есть хорошие шансы найти полезное применение webpack-blocks.

GraphQL


Такое ощущение, что GraphQL заменит REST, особенно в компаниях, которым приходится обрабатывать огромные объёмы данных. Вот пример, который поможет понять – почему это так. Главная мысль: GraphQL эффективен до предела. Полагаю, мы продолжим наблюдать за ростом GraphQL в 2017-м. А о том, заменит ли он REST, поговорим через год.

React Storybook


Это – среда разработки пользовательских интерфейсов для React / React Native. С её помощью можно визуализировать различные состояния компонентов интерфейса и работать над ними в интерактивном режиме.

Взгляните на эту картинку, и сразу поймёте, в чём тут дело.

image

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-м. Полагаю, этот год принесёт нам и нечто совершенно новое. В любом случае, будет интересно.

После того, как этот материал увидел свет, читатели подсказали несколько важных технологий, которые позволили его расширить. Может быть, и вы что-нибудь подскажете?
RUVDS.com 526,02
RUVDS – хостинг VDS/VPS серверов
Поделиться публикацией
Похожие публикации
Комментарии 87
  • –2
    Angular won't die!
    • +9
      Where is Angular?
      • –2
        Первый цветет и пахнет в ентерпрайзе. Второй — фиг его знает.
        • +4
          Ангуляра в подборке не будет, т.к. Даниэль Абрамов — апологет реакта, аудитория на его твиттер подписана соответствующая
          • +1
            Однако vuejs при этом в подборке приутствует
        • +21
          Выглядит так, что основной тренд — уйти от javascript на что-нибудь другое, что конвертируется в js.
          • +1
            Ну основной не основной, но что это тренд — это без сомнения. Причем даже не 2017, а я бы сказал — уже несколько лет как. ClojureScript, ScalaJS, Haskell… это все далеко не вчера началось, и возможно скоро сложнее будет назвать популярный язык, для которого нет js backend, чем такой, у которого он есть.
            • +1
              По-моему просто статья так написана. Особенно весёлый намёк на то, что Rust изобрели чтобы в вебе не писать на JS :)
              Видимо, он виноват в том, что компилится под llvm.
              • +2
                По-моему просто статья так написана

                А ибо группи писал ее — а они слепы и видят только своего кумира.

                Дело в том, что Дан Абрамов — это сейчас что-то вроде короля хипстеров сейчас. И они возносят все, что он говорит) И подменяют понятия, чтобы подогонать их под понятие своей моды. Ну вроде «нравится раст? давайте всем будем говорить, что он написан для замены жс, иначе выпадаем из тренда»

                «Ааа! Дан снова написал, что раньше мы все делали неправильно и сейчас так уже не делают. Надо написать ему в твиттер, что мы срочно перешем наш код на новую парадигму, чтобы быть современными!»

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

                Показывает переменчивые тренды (а где сейчас кофескрипт? или столь трендовый в 2015 Gulp?) узкой группы хистеров, которая кажется широкой из-за того, что очень громкая.
                • 0
                  Даже дополнить нечего :) Самое точное описание происходящего в мире JS разработки.
                  • +1
                    И они возносят все, что он говорит)


                    Я тоже возношу, например он сказал, что мне не нужен Redux и я с ним полностью согласен, его статью по этому поводу даю всем читать, кто пытается меня убедить, что я отстаю от жизни, не используя Redux.
                • 0

                  Добрый день.


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

                  • +1
                    Но никто ведь не избавит от головной боли при использовании этих инструментов, которые должны избавить от боли при написании на чистом javascript :)

                    Мне довольно странно видеть в javascript тренде вещи, которые предлагают не использовать сам js а транспилится в него. Бесспорно, подобные инструменты набирают популярность и имеют право на существование, но я бы назвал это не трендом javasсript, а трендом чего-нить еще.
                  • 0
                    иллюзия выбора как есть — ты можешь писать на чем хочешь, но все равно это будет конвертировано в js. Big brother watching you
                    • 0

                      Можно писать на чем хочешь, но все равно вселенная будет оперировать квантами. Существует ли выбор в принципе?

                      • 0
                        ты можешь писать на чем хочешь, но все равно это будет конвертировано в js

                        или в байт-код, или в ассемблер, или в нули и единицы… Прочь иллюзию выбора — даёшь перфокарты! :-)

                    • 0

                      Стоит добавить к списку ClojureScript, попробовал его работе с использованием обвязки вокруг ReactJS — reagent+re-com+re-frame. Это потрясающе!

                      • +1
                        Clojure восхитительна, полностью поддерживаю, сам в восторге!
                      • +3
                        Выглядит так, как-будто facebook захватил власть во всем мире.
                        • +1
                          Вовремя сделанным функциональным хуком
                        • +3

                          Не знаю, стоит ли относить это к "трендам 2017го" или просто к интересным релизам, но:


                          1) Я бы добавил Angular 4+, ну просто потому что тренд на фреймы пошли именно с него (с ангулара), имхо и это довольно крупная разработка, чтобы просто взять и забыть про него.


                          2) Скорый релиз Tko (Technical Knockout)


                          P.S. Нокаут, хоть и довольно древний и не столь известный, но всё же он является основоположником и aurelia (которая durandal, который использовал knockout), и angular (по крайней мере 2ой версии, которая выросла из durandal), и vue и многих других. Так что хоть и не совсем тренд, но релиз интересный.

                          • +1
                            Нокаут это верная рабочая лошадка в современном мире JS хайп-библиотек со средним сроком жизни в два года. Таким бы был angular 1, если бы не полагался на дико тормозной digest cycle. К счастью, крупный Enterprise с историей существования больше 20 лет это понимает и скептически смотрит на Facebook дары приносящий.

                            П.С. самое забавное, что хорошие паттерны типа Redux и Immutability воплощаются на Knockout даже лучше чем в оригинальном родоначальник Хайфа по ним.
                            • 0
                              Есть еще одна важная фича knockout — в его шаблонах не используются двойные фигурные скобки, в отличие от большинства других js-фреймворков. По этой прините шаблоны и bindings для knockout можно вставлять без экранизации в серверные шаблоны jinja / twig / blade и многие другие.

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

                                У нокаута два шаблонизатора, один дженерик, основнанный на чистом и полностью валидном html и punches https://mbest.github.io/knockout.punches/ (синтаксис которого, насколько я понимаю, основан на mocha), при этом поддержка второго в tko идёт уже "из коробки", хоть и опциональна (ниже ссылка на роадмап, где интеграция завершена), такая своеобразная миграция.


                                Короче, в punches доступна интерполяция через двойные фигурные скобки, потрачено =)

                                • 0
                                  Да, это ошибочное решение более поздних мэйнтайнеров. Изначально этого не было. Хорошо что хотя бы можно отключить.
                                  • 0

                                    По мне — это наоборот довольно профитное решение, т.к. управляющие последовательности интерполяции точно так же конфижатся, никто не мешает заменить, например на "{!" + "!}" ну или ещё что… Но в результате pucnhes на порядок очищает вьюшку от лишнего "хлама". К примеру:


                                    До:


                                    <div data-bind="text: some, attr: { class: any }"></div>

                                    После:


                                    <div class="{{ any }}">{{ some }}</div>
                                    • 0
                                      А теперь поместите это в серверный шаблон к примеру jinja2, и вы увидите зачем нужно не использовать двойные фигурные скобки. Заменить так просто не получится потому что это сломает сторонние компоненты, использующие двойные фигурные скобки. Компактность кода — не самоцель.

                                      https://github.com/ansible/ansible/issues/4638
                                      • 0

                                        Заменить клиентскую интерполяцию, не серверную ;) А у нокаута я не помню плагинчиков, предоставляющих какие-нибудь шаблоны. С другой стороны, с последними релизами, где добавили компоненты и идёт движение к теневому DOM, кто знает...


                                        С другой стороны есть другие решения, пусть и костыльные:
                                        1) Использование raw вставок на сервере, что-то вроде {{ '{{ someVar }}' }}
                                        2) Экранирование (например как это сделано в Laravel Blade): @{{ $some }} (на выходе тоже самое без собаки)
                                        3) Использование компонентов. Тогда вся логика нокаута инкапсулируется внутри компонента и серверная шаблонизация вряд-ли будет на неё влиять (тут смотря как написать этот компонент, через template (тогда будет), в стиле React, вместе с классом (скомпилится внутрь) или через внешний файл (статик html можно отдавать как есть, т.е. не будет)).

                                        • 0
                                          Есть 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 сейчас спрос большой. Может быть на него и надо перейти, только очень много кода переписывать. И лишь бы к тому времени не придумали что-то новое вместо него.
                            • 0
                              За Tko спасибо.
                              Со скоростью они что-нибудь сделали?
                            • 0
                              Использую knockout несколько лет, в том числе binding на классы с возможностью расширения (псевдонаследования прототипами). Очень удобно. Посмотрел расхваливаемый Vue.js, там вместо обычного объекта предлагается делать binding на сам Vue и расширение функциональности очень неудобно сделано из-за этого.

                              При этом о Vue кричат все кому не лень, а knockout как будто-бы и нет.

                              Причем на knockout запросто пишутся большие приложения на es5, без всяких ужасных транспилеров.

                              Такое ощущение что мода и тренды затмевают здравый смысл.

                              Точно также на серверной стороне — предлагают мини-фреймворки на node вместо мощнейших Django / Rails / Spring, в которых функционала много больше.
                              • +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();
                                  }
                                }
                                • 0
                                  Смотрю я на этот код и плачу. У вас комментарии занимают больше чем сам код и содержат при этом не комментарии, а метаданные. Вы пробовали Typescript?
                                  • +1
                                    Приехали, а что не так с jsdoc? Откройте исходники какого-нибудь angular 1.
                                    И не всегда есть возможность взять TS.
                                    • +1
                                      jsdoc был сносен в 2012-ом, поскольку не было альтернатив. Однако, само его наличие это признание необходимости возможности иметь типизацию. Ни один язык, который проектировался с наличием такой возможности изначально, не пошёл по пути вынесения её описания в комментарии. Объявление типа члена всегда неразрывно в них с объявлением самого члена. Их ведь не глупые люди проектировали? И команда Angular ведь не просто так решила перейти на TS с jsdoc.

                                      П.С. за почти 4 года работы с TS я знаю лишь одно реальное препятствие его внедрить — команда ленива и не любит JS как таковой. Но наличие добротного jsdoc-а намекает, что ваша команда явно с отдачей подходит к делу, сомневаюсь, что на внедрение TS у вас ушло бы больше пары дней.
                                      • +1
                                        Ни один язык, который проектировался с наличием такой возможности изначально, не пошёл по пути вынесения её описания в комментарии.

                                        Если я не путаю — тренд пошлёл с javadoc. Аннотации, которые нынче в джаве и появились на волне этого javadoc, как некая формализация этих метаданных.

                                        • 0
                                          В Джаве они используются не для типизации, как в вашем коде, а для документации, это разные вещи)
                                          • 0

                                            Аргумент, соглашусь. Тогда всё можно списать на привычку и желание написать понятный пример для большинства, на почти что классическом JS не используя flow или ts.

                                            • 0
                                              Я сам некоторое время назад пришел к JSDoc и даже использовал его пару лет (еще до тайпскрипта и флоу), но поддержка IDE, к сожалению, у него не самая лучшая. Некоторые мои багрепорты в Idea до сих пор открыты (давно не проверял, каково реальное положение вещей):
                                              https://youtrack.jetbrains.com/issue/WEB-7411
                                              https://youtrack.jetbrains.com/issue/WEB-12679

                                              Серьезно, ТайпСкрипт значительно лучше в этом плане, чем чистый JsDoc, хотя TS не идет ни в какое сравнение с тем, как IDE помогает разрабатывать на C#
                                              • 0

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

                                                • +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, конечно, хороший вариант, особенно для закостенелой команды, но возможностей у него поменьше, чем у TS
                                                  • 0
                                                    Flow с TS пересекаются по возможностям процентов на 95 навскидку. По 5% каждый может то, что не может другой.
                                                    • 0
                                                      VolCh TS>=2.0 заметно опережает Flow.
                                                      А напомните, пожалуйста, чего нет в TS, по сравнению с Flow? Не слежу просто.
                                                      • 0
                                                        А я не слежу особо за TS, где-то год назад сравнивал.
                                      • 0
                                        Однако, само его наличие это признание необходимости возможности иметь типизацию.
                                        Каким образом возможность описания параметров для автоматического формирования подсказок/документации в IDE говорит о необходимости типизации?
                                        И команда Angular ведь не просто так решила перейти на TS с jsdoc.
                                        Как это, перейти с документации на прекомпиляцию? Типы вдруг сами себе описания функционала начинают писать? В TS тот же самый JSDoc используют, если я правильно понимаю, только что упрощённый, потому что описания типов вынесены в синтаксис самого языка.
                                        • 0
                                          Так в данном случае вопрос же не в том, для чего впринципе можно использовать 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 только там, где она нужна, и это будет семантически значительно правильнее. Но вы её все-равно не пишете.
                                    • 0

                                      Мне не нравится писать проект полностью на тайпскрипте, ES'17 + Flow на порядок профитнее, имхо, т.к. типизация опциональна и это всё же JS в конечном итоге, который позволяет творить всё, что придёт в голову с наименьшим сопротивлением (в рамках разумного, конечно).


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


                                      Короче, просто привычка писать хороший код, благо jsdoc автоматом проставляется IDE =)

                                      • +1
                                        Хорошему коду комментарии не нужны ~Дядя Боб.
                              • +2
                                указывает на то, как много разработчиков больше не хотят писать на JS.
                                А они и раньше не хотели. JavaScript не настолько хороший язык, чтобы все хотели писать только на нём — разные люди любят разные языки, но для Web им всем приходится писать на одном.
                                • +5
                                  Кроме того, TypeScript облегчает процесс разработки, указывая на ошибки прямо в процессе ввода текста программы.

                                  Хм, когда изучал Angular, писал на TypeScript в саблайме и ничего он мне не подсказывал. Как вообще язык может что-то подсказывать в момент ввода текста, разве это не функционал IDE?
                                  • 0
                                    Очевидно потому что Sublime не IDE, и без плагинов подсказывать для нового для него языка он не умеет.
                                    • +2
                                      Тогда в тексте неверно указан плюс языка, это фича IDE.
                                      • 0

                                        Я думаю, имелось в виду, что типизация позволяет реализовать дополнительные подсказки в IDE.

                                        • +3
                                          Но сама IDE без получения нотификаций от языка не показала бы подсказки.
                                          • +3
                                            Но и для этого не обязательно менять сам язык, можно, при желании, обходиться JSDoc.
                                            • 0
                                              JSDoc сильно ограничен при сравнении с типизацией typescript. С помощью JSDoc нельзя сделать обобщенные типы, например. Если в двух словах, typescript позволяет очень широко охватить все возможные конструкции кода, что избавит вас от наиболее типичных ошибок, которые могут возникнуть без строгой типизации.
                                              Простой пример: вы удалили функцию из объекта, а она используется по всему коду. Если вы внимательны, то пробежитесь по всем местам (придется еще найти и отфильтровать похожие названия других объектов, может быть). Иначе же в runtime получите ошибку. И хорошо, если сразу после правки. А Typescript сразу укажет на эту ошибку. И это только одна полезность из сотни.
                                              • +1
                                                Не понял как ваш простой пример относится к строгой типизации.
                                                • +1

                                                  А ещё можно взять, написать yarn add babel-plugin-transform-flow-strip-types и дальше продолжать использовать JS.

                                        • +6
                                          Попробуйте VSCode, будете приятно удивлены
                                          • +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.

                                          • +4
                                            React, функциональное программирование, react, react, функциональное программирование, react, функциональное программирование, функциональное программирование ну и наконец — react!

                                            Точно тренды?
                                            • +1

                                              Предложите свой список?

                                              • +4

                                                А в комментариях:
                                                Angular, энтерпрайз, angular, angular, энтерпрайз, angular, энтерпрайз и конечно же angular!


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


                                                Но лично для себя в статье увидел технологии интересные, такие как WebRTC, WebAssembly, QraphQL. Правда и до статьи за ними следил, и буду следить, и действительно интересно посмотреть, что принесет 2017 нам в этом плане.

                                                • 0
                                                  Это очень хорошо иллюстрирует феномен Баадера-Майнхоф, то бишь каждый о своём…
                                              • +2

                                                Автор Inferno переходит работать над React в Facebook, так что не уверен, что у проект в 2017 году полетит без него.

                                                • 0

                                                  Наверно, оно и к лучшему. Может автор Inferno поможет выгрести мусор из их кровавого энтерпрайзного кода.

                                                • 0
                                                  Тренд все тот же последние надцать лет. JavaScript не нравится многим разработчикам, переходящим из других областей программирования, и они пытаются сделать более лучший JavaScript под себя, типа typescript, coffeescript или, из другой оперы, jsx. Либо же притащить свой любимый %lang% и приделать к нему компиляцию в js.
                                                  Trolling mode: куча усилий над языками и компиляторами, вместо того, чтобы приложить усилия к себе и разобраться, наконец, с js, хотя бы в 2016+ версии.
                                                  • +1
                                                    2017 — WebAssembly
                                                    2018 — JS в машинном коде Intel
                                                    2019 — JS в машинном коде ARM
                                                    2021 — Elm, Rust, Go, C++ на всех платформах компилируется в JS
                                                    2025 — async/await/generators — в машинном коде Intel в 64-ядерном процессоре
                                                    2026 — датацентры на новых процессорах в каждом штате
                                                    2027 — нейронные сети захватили управление знергоресурсами североамериканского континента
                                                    2028 — уходящий президент выявил группу хакеров, которая программировала нейронные сети на чистом JS, чтобы контролировать 51% добычи сланцевого газа
                                                    • 0
                                                      вы же понимаете, что webAssembly(не asm.js) это шаг в сторону ухода от js и компиляции в js, и в этом ряду вообще лишний, правда?
                                                    • 0
                                                      Прикольно, почитал про GraphQL.
                                                      Оказалось что схожий подход использовал в Nodejs проектах ещё в 2011 году и всё время придерживался его вместо REST'a.
                                                      Причем за это время накопилось пачка решений, хоть, вероятно и на уже устаревших фреймворках, но успешно решающая задачи.
                                                      Честно говоря все виения ни капли не удивляют, а органично выходят из времени. Достаточно взглянуть на историю почти любого популярного (в прошлом) ЯП и увидеть довольно схожую череду изобретений.
                                                      Это примерно как тебе рассказывают про новомодную nosql БД, а ты знаешь что аналогичный механизм использовался в какой-нибудь технологии ещё в 70 годах прошлого столетия. Я ничего не имею против — наоборот, это круто что находятся подобные применения и решения, просто очень интересно наблюдать.
                                                      • 0
                                                        А ещё мне кажется, что GraphQL сильно похож на OData(который, кстати, появился ещё в 2007 году).
                                                        Но я с GraphQL почти не знаком, так что могу ошибаться.
                                                        • 0
                                                          Такие языки прячут недостатки JS.
                                                      • +1
                                                        Чем вызван такой ажиотаж вокруг языков, которые компилируются в JavaScript? Почему люди не пишут просто на JavaScript? Ведь как не ругай JS, но в итоге код скомпилируется из его базового функционала?
                                                        • 0
                                                          Чем вызван такой ажиотаж вокруг языков, которые компилируются в машинные коды? Почему люди не пишут просто в машинных кодах? Ведь как не ругай машинные коды, но в итоге код скомпилируется из их базового функционала?

                                                          Ответ

                                                          У JavaScript монополия, так сказать, в вебе.

                                                          • 0

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

                                                          • 0
                                                            Не увидел Dart, хотя он вроде как компилируется в JS,
                                                            и общему тренду соответствует, что с ним не так?
                                                          • +1
                                                            Не увидел Apollo, или он относится к GraphQL?
                                                            • +1
                                                              Хм, а мне плевать на тренды :)
                                                              • +4
                                                                Значит тренд 2017 это использовать всё, кроме чистого JS и обычного написания HTML структуры.
                                                                Всё должно компилиться и генеророваться. Попробывал написать на Elm простенький скрипт со вставленным атрибутом в html элемент, который бы в коде не повторялся.

                                                                Ну и что же теперь учить? Всё? Чтото меня тошнит X-(

                                                                Автору за статью спасибо!
                                                                • 0
                                                                  Как и раньше — учить основы — алгоритмы, структуры, методологии и так далее. А зная основу (JS) — уже изучить конкретный инструмент проблем не составит.
                                                                • –4
                                                                  Привет друзья разработчики))) очень-очень интересует вопрос визуализации сайтов… С помощью чего создаются такие эффекты на сайте, пример http://waaark.com/vision/

                                                                  Что же надо выучить ...java...flash… или что??? это для меня загадка уже несколько месяцев, на которую так и не получила ни одного точного ответа((((

                                                                  Очень прошу вашей помощи!!! :)
                                                                  • +1
                                                                    Нарисовано с помощью SVG, анимировано JavaScript-ом (jQuery и TweenMax, в числе прочего).
                                                                  • 0

                                                                    Было бы замечательно увидеть аналогичный обзор в более Angular-образном поле. Typescript увидел, да.

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

                                                                    Самое читаемое