Языки. На Angular можно писать на JavaScript, на TypeScript, на Dart, на Flow — на чем хотите.
В реалиях варианта, насколько я понимаю, ровно два — Typescript и Dart, на них оно нативно работает. Новичок помрет, раскуривая A на обычном JS (или тем более Flow). То, что это «можно» сделать — ничего не говорит о сложности. По языкам/диалектам, которые нормально поддерживаются, я думаю React далеко впереди. Варианты: JS ES5 (как там у ангуляра?), JS ES6+, Flow (очень странно автор пишет это только ангуляру, хотя инструмент затачивается под React), Typescript, Elm, ClojureScript, ReasonML.
То есть объективно для широкой публики нормально поддерживается в ангуляре только TS (Dart маргинальный), в реакте — обычный JS и JS+Flow, и тот же Typescript (маргинальные Elm, Clojurescript, ReasonML в расчет не берем).
Есть страшное подозрение, что чувство баланса по применению инструментов — а) очень индивидуальное; б) нарабатывается исключительно опытом, когда есть навык и жукверей и условных реактов/ангуляров/etc.
ЗЫ А вообще на такую тему на хабре писать — верный хабра[роскомнадзор]. Загрызут. Такое только на медиуме.
И еще одно — лобовая реализация описанного в ассемблере скорее всего будет эффективнее безумных портянок кода, сгенерированного двойным преобразованием java -> bytecode -> native code. Учим асм?
А можно от последнего подхода сделать еще один шаг и перестать связывать функции и данные в объекты, и перейти к функциональному подходу, если уж так хочется. Тогда this вообще исчезнет как понятие.
А что, имя автора кода как-то гарантирует, что конкретный его код — хороший? Если он не очень знаком с фреймворком, ожидаемо что он может писать криво. Сразу из стартера — общепринято бить по рукам, если data является объектом, а не функцией, возвращающей объект. Впрочем остальное в стартере выглядит опрятно.
Образец на vuejs.org, куда вы ссылаетесь — лохматого года, и явно не Typescript. Вы его портируете, и остальные лохматости оставляете как есть. Причём там есть извиняющая причина (не факт, что браузер свежий), а у вас её нет (т.к. компилятор TS обязателен).
К слову, Эван, при всём к нему уважении, зачастую пишет/выкладывает невменяемый код. С документированием кода во всей Vue.js экосистеме (включая сам фреймворк) очень плохо всё. Как пример, можно смотреть на vuex. И сравнить его с redux. Оцените например как реализован vuex хелпер mapGetters (то, что вчера пришлось смотреть).
Очень хорошо, что кто-то пишет на русском про TS применительно к Vue.js. Но остальное…
Про «строгую» типизацию в TS, где есть any и нет soundness — вам уже сказали.
Построение — мне лично кажется что class MyComponent extends FrameworkName {… } — семантически кривой конструкт. Сравните с:
class MyComponent extends React.Component {… }
Извините, но от кода просто кровь из глаз. Как будто ES6 прошел мимо, к чему такая многословность?
Сам Vue.js очень «волшебный» фреймворк, а вы ему еще магии добавляете. Официальный стайл-гайд требует, чтобы для фреймворка явно описывались типы свойств компонента. У вас — массив. Исправляем, делаем явно — и получаем дубликат описаний, то есть еще хуже.
Вот так вообще писать нельзя, динамически меняющиеся свойства статикой упихиваем в data секцию:
data: function () {
var sortOrders: any = {};
(this.$props as DemoGridProps).columns.forEach(function (key) {
sortOrders[key] = 1
})
return {
sortKey: '',
sortOrders: sortOrders
} as DemoGridData
}
Вопросов больше не имею. Подавляющее большинство JS программистов такой роскоши себе позволить не может. А как только вы сталкиваетесь с JS-зависимостями, весь ваш ООП из Java потенциально идет в топку. См. например печально известный манки-патчинг (про smoosh-гейт слышали из последнего?)
PS Не скажу за GWT, но скажем Vaadin то еще дерьмо.
Небольшое уточнение про фронтенд — язык тут как бы один, Javascript. Но при этом их много — ES5, ES6+, TypeScript, JS+Flow, Dart, Coffescript, ClojureScript, Elm.
А еще традиционного ООП, такого как в C++/Java — в JS ни в ES5-, ни 6+ — нет и не будет.
Для рядового обывателя всё это разбивается обычно о — «где деньги, Зин»? Любой фэйл не бесплатен. Если нет богатого родителя/родственника, то первый-второй становится последним. Или попытки прекращаются на долгие годы.
Я только по части бэкграунда. Мне тоже проще понять генераторный подход. Фишка в том, что он из мира императивных конструкций, откуда большинство программистов пришли. Опять же, человек говорит про свое личное мнение — так что про голословность это вы зря.
По статье — да, я в начале слегка иронизирую над функциональным подходом — хотя бы в силу того, что JS всё-таки скорее императивный язык. Пожалуйста, не обижайтесь.
И концепция, и код трансдьюсеров — не очень просты. Transducers.js тому подтверждение. И про понимание, многие вещи мы понимаем и пытаемся воспринимать интуитивно. Иначе элементарно не хватит внимания на более сложные вещи. Это и есть абстракция, в конце концов.
Спасибо за информативный комментарий. До статьи Рича к стыду своему не добрался, лисп все же мне далек. В обучалках да, нюансы, которые вы описали — потерялись. Моя идея была в том, что экономить память при преобразовании потока можно и более привычным способом.
Как я отметил в конце статьи, это пойдет только если у вас проблемы с потреблением памяти. Это не серебряная пуля. Процессинг данных через map, filter, reduce — декларативный и понятный. Код с compose может быть непривычным, но фактически удобный, гибкий (с for не сравнить), читается легко.
Бенчмарки не делал, самому интересно. Скорее всего сольет вчистую классике на for, на больших объемах должен быть производительнее, чем цепочка методов над array. Может на досуге потестирую, напишу отдельно заметку.
Как тут заметили — это обычно библиотечная функция. А так я реально нашел в инете реализацию. Код как по мне — не самый очевидный, но при некотором навыке нормально читается. Зависит от того, насколько разработчик "утоп" в функциональном дискурсе. Кстати с ООП та же песня — читать все эти фабрики фабрик фабрик легко с некоторым ооп бэкграундом.
Видел это выступление вживую. Ответ на вопрос «почему не Nightwatch» — неубедителен. Классическое проявление NIH-синдрома (not invented here). Изобрели то же самое, но своё.
У вас излишне многословный код для оберток, создавать промисы там, где функции axios уже их возвращают — излишество. Можно написать каждую обертку буквально в две строки:
В реалиях варианта, насколько я понимаю, ровно два — Typescript и Dart, на них оно нативно работает. Новичок помрет, раскуривая A на обычном JS (или тем более Flow). То, что это «можно» сделать — ничего не говорит о сложности. По языкам/диалектам, которые нормально поддерживаются, я думаю React далеко впереди. Варианты: JS ES5 (как там у ангуляра?), JS ES6+, Flow (очень странно автор пишет это только ангуляру, хотя инструмент затачивается под React), Typescript, Elm, ClojureScript, ReasonML.
То есть объективно для широкой публики нормально поддерживается в ангуляре только TS (Dart маргинальный), в реакте — обычный JS и JS+Flow, и тот же Typescript (маргинальные Elm, Clojurescript, ReasonML в расчет не берем).
ЗЫ А вообще на такую тему на хабре писать — верный хабра[роскомнадзор]. Загрызут. Такое только на медиуме.
То есть для ангуляра больше половины айсберга просто вынесено за скобки.
Образец на vuejs.org, куда вы ссылаетесь — лохматого года, и явно не Typescript. Вы его портируете, и остальные лохматости оставляете как есть. Причём там есть извиняющая причина (не факт, что браузер свежий), а у вас её нет (т.к. компилятор TS обязателен).
К слову, Эван, при всём к нему уважении, зачастую пишет/выкладывает невменяемый код. С документированием кода во всей Vue.js экосистеме (включая сам фреймворк) очень плохо всё. Как пример, можно смотреть на vuex. И сравнить его с redux. Оцените например как реализован vuex хелпер mapGetters (то, что вчера пришлось смотреть).
Про «строгую» типизацию в TS, где есть any и нет soundness — вам уже сказали.
Построение — мне лично кажется что class MyComponent extends FrameworkName {… } — семантически кривой конструкт. Сравните с:
class MyComponent extends React.Component {… }
Извините, но от кода просто кровь из глаз. Как будто ES6 прошел мимо, к чему такая многословность?
Сам Vue.js очень «волшебный» фреймворк, а вы ему еще магии добавляете. Официальный стайл-гайд требует, чтобы для фреймворка явно описывались типы свойств компонента. У вас — массив. Исправляем, делаем явно — и получаем дубликат описаний, то есть еще хуже.
Вот так вообще писать нельзя, динамически меняющиеся свойства статикой упихиваем в data секцию:
Для этой цели есть секция computed.
Вопросов больше не имею. Подавляющее большинство JS программистов такой роскоши себе позволить не может. А как только вы сталкиваетесь с JS-зависимостями, весь ваш ООП из Java потенциально идет в топку. См. например печально известный манки-патчинг (про smoosh-гейт слышали из последнего?)
PS Не скажу за GWT, но скажем Vaadin то еще дерьмо.
А еще традиционного ООП, такого как в C++/Java — в JS ни в ES5-, ни 6+ — нет и не будет.
По статье — да, я в начале слегка иронизирую над функциональным подходом — хотя бы в силу того, что JS всё-таки скорее императивный язык. Пожалуйста, не обижайтесь.
И концепция, и код трансдьюсеров — не очень просты. Transducers.js тому подтверждение. И про понимание, многие вещи мы понимаем и пытаемся воспринимать интуитивно. Иначе элементарно не хватит внимания на более сложные вещи. Это и есть абстракция, в конце концов.
Спасибо за информативный комментарий. До статьи Рича к стыду своему не добрался, лисп все же мне далек. В обучалках да, нюансы, которые вы описали — потерялись. Моя идея была в том, что экономить память при преобразовании потока можно и более привычным способом.
Композиция дает модульность обработки. Мне кажется, у вас ирония?
Как я отметил в конце статьи, это пойдет только если у вас проблемы с потреблением памяти. Это не серебряная пуля. Процессинг данных через map, filter, reduce — декларативный и понятный. Код с compose может быть непривычным, но фактически удобный, гибкий (с for не сравнить), читается легко.
Бенчмарки не делал, самому интересно. Скорее всего сольет вчистую классике на for, на больших объемах должен быть производительнее, чем цепочка методов над array. Может на досуге потестирую, напишу отдельно заметку.
Как тут заметили — это обычно библиотечная функция. А так я реально нашел в инете реализацию. Код как по мне — не самый очевидный, но при некотором навыке нормально читается. Зависит от того, насколько разработчик "утоп" в функциональном дискурсе. Кстати с ООП та же песня — читать все эти фабрики фабрик фабрик легко с некоторым ооп бэкграундом.
Пропущено "=" после filterReducer.
И игру слов потеряли (там, где «хаха»).