Comments 86
Видимо, он виноват в том, что компилится под llvm.
По-моему просто статья так написана
А ибо группи писал ее — а они слепы и видят только своего кумира.
Дело в том, что Дан Абрамов — это сейчас что-то вроде короля хипстеров сейчас. И они возносят все, что он говорит) И подменяют понятия, чтобы подогонать их под понятие своей моды. Ну вроде «нравится раст? давайте всем будем говорить, что он написан для замены жс, иначе выпадаем из тренда»
«Ааа! Дан снова написал, что раньше мы все делали неправильно и сейчас так уже не делают. Надо написать ему в твиттер, что мы срочно перешем наш код на новую парадигму, чтобы быть современными!»
Данная статья — из разряда «зайти в барбер-шоп и узнать современные тренды. Конечно вы получите кучу одинаковых ответов вроде клетчатой рубашки, зауженых штанов, антикафе, голос фальцетом и тому подобное.
Показывает переменчивые тренды (а где сейчас кофескрипт? или столь трендовый в 2015 Gulp?) узкой группы хистеров, которая кажется широкой из-за того, что очень громкая.
И они возносят все, что он говорит)
Я тоже возношу, например он сказал, что мне не нужен Redux и я с ним полностью согласен, его статью по этому поводу даю всем читать, кто пытается меня убедить, что я отстаю от жизни, не используя Redux.
Добрый день.
Ну я бы сказал не уйти, а использовать другие инструменты. Ведь на выходе мы получаем все тот же JavaScript. А данные инструменты, библиотеки, фреймворки (добавить свое) помогают избавиться от проблем и головной боли, которая есть при написании на чистом JavaScript.
Мне довольно странно видеть в javascript тренде вещи, которые предлагают не использовать сам js а транспилится в него. Бесспорно, подобные инструменты набирают популярность и имеют право на существование, но я бы назвал это не трендом javasсript, а трендом чего-нить еще.
Стоит добавить к списку ClojureScript, попробовал его работе с использованием обвязки вокруг ReactJS — reagent+re-com+re-frame. Это потрясающе!
Не знаю, стоит ли относить это к "трендам 2017го" или просто к интересным релизам, но:
1) Я бы добавил Angular 4+, ну просто потому что тренд на фреймы пошли именно с него (с ангулара), имхо и это довольно крупная разработка, чтобы просто взять и забыть про него.
2) Скорый релиз Tko (Technical Knockout)
P.S. Нокаут, хоть и довольно древний и не столь известный, но всё же он является основоположником и aurelia (которая durandal, который использовал knockout), и angular (по крайней мере 2ой версии, которая выросла из durandal), и vue и многих других. Так что хоть и не совсем тренд, но релиз интересный.
П.С. самое забавное, что хорошие паттерны типа Redux и Immutability воплощаются на Knockout даже лучше чем в оригинальном родоначальник Хайфа по ним.
Почему авторам других фреймворков не приходит в голову что двойные фигурные скобки конфликтуют с серверными шаблонами — не понятно. Видимо думают только о SPA, забывая что зачастую полезнее гибрид обычного серверного приложения и клиентских компонентов, так сказать «полу-SPA».
У нокаута два шаблонизатора, один дженерик, основнанный на чистом и полностью валидном html и punches https://mbest.github.io/knockout.punches/ (синтаксис которого, насколько я понимаю, основан на mocha), при этом поддержка второго в tko идёт уже "из коробки", хоть и опциональна (ниже ссылка на роадмап, где интеграция завершена), такая своеобразная миграция.
Короче, в punches доступна интерполяция через двойные фигурные скобки, потрачено =)
По мне — это наоборот довольно профитное решение, т.к. управляющие последовательности интерполяции точно так же конфижатся, никто не мешает заменить, например на "{!" + "!}" ну или ещё что… Но в результате pucnhes на порядок очищает вьюшку от лишнего "хлама". К примеру:
До:
<div data-bind="text: some, attr: { class: any }"></div>После:
<div class="{{ any }}">{{ some }}</div>https://github.com/ansible/ansible/issues/4638
Заменить клиентскую интерполяцию, не серверную ;) А у нокаута я не помню плагинчиков, предоставляющих какие-нибудь шаблоны. С другой стороны, с последними релизами, где добавили компоненты и идёт движение к теневому DOM, кто знает...
С другой стороны есть другие решения, пусть и костыльные:
1) Использование raw вставок на сервере, что-то вроде {{ '{{ someVar }}' }}
2) Экранирование (например как это сделано в Laravel Blade): @{{ $some }} (на выходе тоже самое без собаки)
3) Использование компонентов. Тогда вся логика нокаута инкапсулируется внутри компонента и серверная шаблонизация вряд-ли будет на неё влиять (тут смотря как написать этот компонент, через template (тогда будет), в стиле React, вместе с классом (скомпилится внутрь) или через внешний файл (статик html можно отдавать как есть, т.е. не будет)).
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 сейчас спрос большой. Может быть на него и надо перейти, только очень много кода переписывать. И лишь бы к тому времени не придумали что-то новое вместо него.
Со скоростью они что-нибудь сделали?
Т.к. это почти что переписанная с нуля либа (судя по коммитам: https://github.com/knockout/tko), то думаю что наверняка сделали.
При этом о Vue кричат все кому не лень, а knockout как будто-бы и нет.
Причем на knockout запросто пишутся большие приложения на es5, без всяких ужасных транспилеров.
Такое ощущение что мода и тренды затмевают здравый смысл.
Точно также на серверной стороне — предлагают мини-фреймворки на node вместо мощнейших Django / Rails / Spring, в которых функционала много больше.
На 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();
}
}
И не всегда есть возможность взять TS.
П.С. за почти 4 года работы с TS я знаю лишь одно реальное препятствие его внедрить — команда ленива и не любит JS как таковой. Но наличие добротного jsdoc-а намекает, что ваша команда явно с отдачей подходит к делу, сомневаюсь, что на внедрение TS у вас ушло бы больше пары дней.
Ни один язык, который проектировался с наличием такой возможности изначально, не пошёл по пути вынесения её описания в комментарии.
Если я не путаю — тренд пошлёл с javadoc. Аннотации, которые нынче в джаве и появились на волне этого javadoc, как некая формализация этих метаданных.
Аргумент, соглашусь. Тогда всё можно списать на привычку и желание написать понятный пример для большинства, на почти что классическом JS не используя flow или ts.
https://youtrack.jetbrains.com/issue/WEB-7411
https://youtrack.jetbrains.com/issue/WEB-12679
Серьезно, ТайпСкрипт значительно лучше в этом плане, чем чистый JsDoc, хотя TS не идет ни в какое сравнение с тем, как IDE помогает разрабатывать на C#
А если TS сравнивать с flow? Имеет всё же смысл использовать TS? Я как-то пробовал, года два назад, подкупали интерфейсы и аннотации, но оно орало на каждый шаг в сторону, в результате весь код превращается в набор из any any any, плюнул и забил. Сейчас опять хочется, но опять боюсь спотыкаться об обязательные типы, которые заставляют описывать каждый шаг.
Да и TypeScript, на самом деле позволяет больше возможностей. Не вспомню точно, но какие-то проблемы с Flow были. Возможно, нельзя корректно наследоваться от дженерик класса? Вроде такого:
class ApiMessage<TItem> {
item: TItem;
time: number;
code: string;
}
class UserApiMessage extends ApiMessage<User> {}
class TopicApiMessage extends ApiMessage<Topic> {}
Ну то есть Flow, конечно, хороший вариант, особенно для закостенелой команды, но возможностей у него поменьше, чем у TS
Однако, само его наличие это признание необходимости возможности иметь типизацию.Каким образом возможность описания параметров для автоматического формирования подсказок/документации в IDE говорит о необходимости типизации?
И команда Angular ведь не просто так решила перейти на TS с jsdoc.Как это, перейти с документации на прекомпиляцию? Типы вдруг сами себе описания функционала начинают писать? В TS тот же самый 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 только там, где она нужна, и это будет семантически значительно правильнее. Но вы её все-равно не пишете.
Мне не нравится писать проект полностью на тайпскрипте, ES'17 + Flow на порядок профитнее, имхо, т.к. типизация опциональна и это всё же JS в конечном итоге, который позволяет творить всё, что придёт в голову с наименьшим сопротивлением (в рамках разумного, конечно).
Плюс, наличие докблока я считаю как минимум правилами хорошего тона, даже в языках, где типизация есть, т.к. эти метаданные могут содержать не только описание типов и позволяют проще ориентироваться в коде, отделяя визуально структуры (методы и поля) друг от друга.
Короче, просто привычка писать хороший код, благо jsdoc автоматом проставляется IDE =)
указывает на то, как много разработчиков больше не хотят писать на JS.А они и раньше не хотели. JavaScript не настолько хороший язык, чтобы все хотели писать только на нём — разные люди любят разные языки, но для Web им всем приходится писать на одном.
Кроме того, TypeScript облегчает процесс разработки, указывая на ошибки прямо в процессе ввода текста программы.
Хм, когда изучал Angular, писал на TypeScript в саблайме и ничего он мне не подсказывал. Как вообще язык может что-то подсказывать в момент ввода текста, разве это не функционал IDE?
Я думаю, имелось в виду, что типизация позволяет реализовать дополнительные подсказки в IDE.
Простой пример: вы удалили функцию из объекта, а она используется по всему коду. Если вы внимательны, то пробежитесь по всем местам (придется еще найти и отфильтровать похожие названия других объектов, может быть). Иначе же в runtime получите ошибку. И хорошо, если сразу после правки. А Typescript сразу укажет на эту ошибку. И это только одна полезность из сотни.
Как вообще язык может что-то подсказывать в момент ввода текста
Запускается специальный сервер как отдельный процесс, к которому могут коннектиться редакторы. Этот сервер предоставляет 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.
Предложите свой список?
А в комментариях:
Angular, энтерпрайз, angular, angular, энтерпрайз, angular, энтерпрайз и конечно же angular!
А так да, функциональщине уже более полувека, а срачи все не утихают. Автор говорит, что возрождение увидел, а может просто открыл что-то новое для себя недавно и стал адептом, в общем дело каждого.
Но лично для себя в статье увидел технологии интересные, такие как WebRTC, WebAssembly, QraphQL. Правда и до статьи за ними следил, и буду следить, и действительно интересно посмотреть, что принесет 2017 нам в этом плане.
Автор Inferno переходит работать над React в Facebook, так что не уверен, что у проект в 2017 году полетит без него.
Trolling mode: куча усилий над языками и компиляторами, вместо того, чтобы приложить усилия к себе и разобраться, наконец, с js, хотя бы в 2016+ версии.
2018 — JS в машинном коде Intel
2019 — JS в машинном коде ARM
2021 — Elm, Rust, Go, C++ на всех платформах компилируется в JS
2025 — async/await/generators — в машинном коде Intel в 64-ядерном процессоре
2026 — датацентры на новых процессорах в каждом штате
2027 — нейронные сети захватили управление знергоресурсами североамериканского континента
2028 — уходящий президент выявил группу хакеров, которая программировала нейронные сети на чистом JS, чтобы контролировать 51% добычи сланцевого газа
Оказалось что схожий подход использовал в Nodejs проектах ещё в 2011 году и всё время придерживался его вместо REST'a.
Причем за это время накопилось пачка решений, хоть, вероятно и на уже устаревших фреймворках, но успешно решающая задачи.
Честно говоря все виения ни капли не удивляют, а органично выходят из времени. Достаточно взглянуть на историю почти любого популярного (в прошлом) ЯП и увидеть довольно схожую череду изобретений.
Это примерно как тебе рассказывают про новомодную nosql БД, а ты знаешь что аналогичный механизм использовался в какой-нибудь технологии ещё в 70 годах прошлого столетия. Я ничего не имею против — наоборот, это круто что находятся подобные применения и решения, просто очень интересно наблюдать.
Чем вызван такой ажиотаж вокруг языков, которые компилируются в машинные коды? Почему люди не пишут просто в машинных кодах? Ведь как не ругай машинные коды, но в итоге код скомпилируется из их базового функционала?
У JavaScript монополия, так сказать, в вебе.
Уже года два как даже js компилируется в js, потому что разные версии браузеров поддерживают разные возможности и все в этом духе. Да и минификация, да и статический анализ — хватает причин. Ну а раз компилировать все равно, почему бы не повысить себе удобство разработки. Мы перешли на typescript и это выглядело как глоток свободы и до сих пор ненарадуемся (вообще очень нравится рост языка, но еще есть агрехи с интеграцией).
и общему тренду соответствует, что с ним не так?
Всё должно компилиться и генеророваться. Попробывал написать на Elm простенький скрипт со вставленным атрибутом в html элемент, который бы в коде не повторялся.
Ну и что же теперь учить? Всё? Чтото меня тошнит X-(
Автору за статью спасибо!
Что же надо выучить ...java...flash… или что??? это для меня загадка уже несколько месяцев, на которую так и не получила ни одного точного ответа((((
Очень прошу вашей помощи!!! :)
Было бы замечательно увидеть аналогичный обзор в более Angular-образном поле. Typescript увидел, да.
JavaScript-тренды, на которые стоит обратить внимание в 2017-м