Комментарии 519
Пробуем Aurelia в одном проекте. Проблема с плагинами, точнее плохой поддержкой typescript определений для плагинов. Документация самой аурелии не все описывает, сейчас уже не вспомню, но проходилось гуглить.
Вроде и статья более-менее объективная, и разложено хорошо, но блин, сложно серьезно воспринимать человека, который $inject руками прописывает.
Adds Angular 1.x DI annotations to ES5/ES6

Здесь рассматривается Angular 2/4. Но, опять же, это вкусовщина. Кому-то нравится использовать стандартный синтаксис без взяких дополнительных приблуд, которые так же нужно изучать (каждому приходящему новому разработчику). По-моему это нормально. Меньше зависимостей — меньше проблем для большого проекта.
Считаю это как раз хорошим паттерном, пусть и error prone, но зато чище со стороны TypeScript'а. И больше инкапсуляции.
Если же сравнивать со всякими ng-min и ng-annotate — в крупных проектах всегда есть места где они работают неверно и приводят к трудно-диагностируемым проблемам. Давно отказался от подобного.
Поддерживаю, приписывать $inject руками это хорошая практика, в отличие от использования всяких ng-annotate подобных поделок. Еще лучше прописывать в $inject импортированные имена (по карйней мере для своих/внутренних сущностей), исключает необходимость копипастить название сущностей.
А как автоматом $inject в таком случае прописывается habrahabr.ru/company/ncloudtech/blog/321584/#comment_10243970?

Мое мнение что приписывать $inject автоматом это плохая практика, получается ты в каждом месте должен называть аргументы допустим сервисов одинаково верно — это копипаст. В случае выше название сервиса импортируется явным образом, и следовательно ошибки в написании быть не может.
например нельзя использовать экспорты по умолчанию

я тут с пол года назад думал про эти default и понял, что они не нужны. Import в javascript вообще спроектирован отвратительно, даже не трогая default, например, вот хочу я что-то заимпортировать из какого-то модуля, я пишу import, скобочки, и вот тут в скобочках я должен написать, что хочу, но при этом ни одна IDE мне не подскажет, что есть в модуле потому-что путь к модулю ещё просто не написан. Я должен либо наугад вспоминать, что там импортируется, либо пропускать скобочки, писать from 'путь', а дальше альтом перемещаться назад, а потом снова вперёд. Мелочь конечно, но когда она повторяется 30 раз за день, это начинает напрягать. Понятно, что можно сделать простейший сниппет решающий проблему, но всё же я считаю, что язык должен позволять полностью последовательное написание кода с автодополнением без необходимости прыгать туда-сюда. Например, в dart так:


import 'dart:ui' show Offset, PointerDeviceKind;

Default тоже ужасен, например, есть у меня в модуле export default class EventEmitter ..., и теперь даже если я написал путь к модулю, IDE опять же не предлагает мне EventEmitter потому-что якобы я должен придумать это имя. Но зачем? В 99.9% придуманное имя совпадает с импортируемым. В тоже время если бы default не было, то автодополнение нормально сработало бы по первым Ev (скобочки написать не проблема или добавить их в сниппет).
Ещё часто бывает, что неочевидно был default при экспорте или нет, приходится либо пробовать методом тыка (и иногда ошибаться), либо открывать код модуля.


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

Честно говоря никогда руками не пишу import руками, всегда делаю автоимпорт через Alt+Enter. IDE — Idea/WebStorm, в более свежих версиях стало очень удобно работать. Последний vscode не тыкал давно, но расстраивает, что там подобного нет.
default export по хорошему вообще нужно забанить в jslint/tslint.

Так выше ж уже привели аргументы. ИМХО дефолтные импорты/экспорты — худшее, что могло случиться с модульной системой JS.

Простите, я крайне редко пишу импорты руками, обычно их вставляет IDE, потому мне сложно понять тот аргумент.


Может они плохи для редакс-приложений, где куча всего экспортится и нету основного импорта, но для подхода один файл — один класс они вполне ничего.


Все проблемы с ИДЕ, которые еще есть — должны решаться, я думаю, в самих ИДЕ.


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

Полностью согласен, пользуюсь исключительно автоимпортом. Однако он не может сопоставить имя импорта (которого еще нет) имени файла, потому как не понятно, что от куда должно импортироваться.

Ну вот есть файл foo.js с содержимым вида


export default {
  foo: 'bar'
}

А в другом мы пишем… а что мы пишем? Не понятно. Только руками в начале файла — import Foo from 'foo';


Было бы export const Foo = ..., то при упоминании Foo в коде, IDE/editor подсказали бы что к чему

es6-модули это вообще классный пример как в tc39 работа идет — хотели как лучше, получилось как обычно

Попробуйте расширение TypeScript Hero для vscode. Он избавит вас от необходимости вручную писать импорты в большинстве случаев. Или TypeScript Importer, но у него меньше функционал.
Но несмотря на подобную поддержку со стороны IDE у меня тоже есть претензия к языку, правда в моем случае именно к Type Script. Поскольку тип у него идет после имени переменной (что, видимо, типично для языков с необязательной типизацией), то часто по сути приходится одно и то же слово набирать два раза. Первый раз с маленькой буквы для имени переменной, и второй раз с большой — для имени типа. Например, myFunc(control: Control) {}. Для vscode не нашел расширений, решающих эту проблему.

Спасибо за хорошую статью, очень полезный опыт!


По моему мнению, с Angular2 так вышло, потому что его разработчики не пытались завоевать пользователей, что все пользователи AngularJS придут к ним сами.


В то время как Vue и другим фреймворкам приходится бороться за пользователя, и когда они это делают, их API становятся проще и удобнее, а документация — понятнее.

Мы у себя после некоторых раздумий начали использовать UniGUI.
Плюсы:
Фактически связанный фронтэнд + бекэнд в одном приложении.
Ультра-быстрый дизайн форм и написания приложения.
Удобная отладка с нормальной средой.
Хороший саппорт, оперативно исправляют вопросы и, вообще, помогают.
Вылизанная, безглючная, либа фронт-энда и связка с ней (ExtJS).
Множество примеров.
Почти сотня десктоп компонент + около 50ти мобильных.
Постоянное развитие библиотеки.
Рекомендую.

К слову — Идера (текущий владелец Delphi), купила Sencha, изготовителя ExtJS, либо будут свою обвязку её делать, либо купять UniGUI. Радует движение в сторону веба.
Да, они стоят от двух недель до месяца зарплаты среднего программиста JS, зато существенно и постоянно экономят время и деньги после покупки, которые всё равно будут уплачены.
Для начала — оно не полностью опенсорсное.
А покупка сенчей сейчас кажется скорее минусом, нежели плюсом. Считаю, что времена тотального господства ExtJS в enterprise сегменте медленно подходят к концу, а последняя версия библиотеки — монструозный атавизм (ведь по-прежнему все свое — классы, разметка, билд системы и т.д). И да, я много работал с ним и знаком с их прекраснейшими и супер-функциональными компонентами.
Покупка конкретно для UniGUI не ухудшает его положение. Как сказал Фаршад (основной разработчик либы) OEM соглашение подписано на годы вперед и с лицензиями проблем нет и не будет.
монструозный атавизм (ведь по-прежнему все свое — классы, разметка, билд системы и т.д)

Своя система классов, на порядок более богатая, существенно более вменяемая, чем ES6, а главное, работающая — это, безусловно, атавизм. Нынче в моде псевдо-недофичи, которые бабушки из TC39 писями на воде виляют, приговаривают: то ли примем, то ли нет, транспилятор на обед, вот те grunt, а вот webpack, не сойти б с ума никак.


И да, я много работал с ним и знаком с их прекраснейшими и супер-функциональными компонентами.

Наверное, недостаточно знакомы. Я вот сколько ни смотрю на все эти ангуляры и реакты, так грустно становится, туфта на постном масле. :( Виджеты если и есть, то до того убогие, аж оторопь берёт. На grids без кровавых слёз не взглянешь. В Clarity Dataview чуть потыкал, с десяток багов нашёл. Они вообще тестируют эти поделки хоть как-нибудь?


Вот не флейма ради, а просвещенья для, где вы берёте годный grid с поддержкой редактирования данных, валидации ввода и data binding для Vue или Angular?

А ES6 классы не работают? Вообще очень печально, если вы не можете понять чем хороши все эти новые недо-фичи в сравнении с весьма спорными и давно устаревшими подходами в Ext.
Про усталость JavaScript'а написано многое, но это не делает webpack менее крутым.

Ну хотите верьте, хотите нет — работал с Ext не один год. Безусловно такой библиотеки контролов нет и не будет ни для одной из описанных библиотек/фреймворков.
Ну так зато они не стоят *тысяч долларов*, а бесплатны и опенсорсны.

А полноценные гриды в серьезных компаниях чаще пишутся либо самостоятельно. Нам в нашем проект Clarity хватило.
Странно, что всегда разговор заходит о 'тысячах долларов'. Как будто программисты бесплатные :) Программисты, на длительном промежутке времени, стоят сильно дороже инструментов разработки. Ну если только у вас не рабы за еду работают, конечно :)

UniGUI это не инструмент разработки, а UI-библиотека. Подписываясь на ее покупку, вы отдаете себя на милость выпускающей компании.


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


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


Да и на рынке труда найти ангулярщика в команду намного проще, чем UniGUI-шника.

То есть — в случае Унигуя мы отдаёмся на милость, а в случае ангуляра — нет? С логикой как-то сложно.

Angular не дает вам никаких компонентов. Съехать с ангуляра на другой фреймворк намного проще. Шансов поменять UniGUI на что-нибудь другое без переписывания с нуля вообще никаких.

Тогда, простите, смысл Англуляра? Пилить всё самому и с нуля? :) Или нанимать кого-то (опять же) за деньги, терять время. Сделаешь — и с него же, я так понимаю, тоже никуда не уйти? Или можно сделать какой-то промежуточный слой и перенести на другой фреймворк?

«Шансов поменять UniGUI на что-нибудь другое без переписывания с нуля вообще никаких.»

Формы поменять только. В коде изменения минимальны. Мы как раз — наоборот — с вин-гуя переписали порядка 50ти форм на уни-гуй. Месяца 1.5 где-то работы.

Кажется, вы живете совсем в другой вселенной. Где веб-приложения пишутся не на веб-технологиях, а на их эмуляции через javascript.


Это, безусловно, очень интересно, но не для людей, комфортно чувствующих себя в Javascript.


Предлагаю на этом дискуссию и закончить.

Эмуляция веб-технологии через javascript — сильно, очень сильно :)
Нужно понимать простую вещь: веб технологии бывают разные. Очень разные.
Ладно, закончим так закончим.

да, опечатался. Имелось в виду


Где веб-приложения пишутся не на нативных веб-технологиях, а эмуляции декстопных API через javascript.
А ES6 классы не работают?

Кое-как работают, там, где они есть. В IE11 есть? Ой, нет. А что умеют? Ой, почти ничего не умеют. Mixins умеют? Нет. Overrides умеют? Нет. Hooks умеют? Нет. Dependency resolution умеют? Нет. Господи, ну хоть статические свойства классов-то умеют? Неа, всё ручками. Пилите, Шура, пилите...


Вообще очень печально, если вы не можете понять чем хороши все эти новые недо-фичи в сравнении с весьма спорными и давно устаревшими подходами в Ext.

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


но это не делает webpack менее крутым.

Чем конкретно крут webpack? По пунктам, если не трудно; бонусные баллы за объективное сравнение с другими решениями. Подозреваю, что дальше "webpack крут, потому что его Angular же использует!" вы не уйдёте.


Ну хотите верьте, хотите нет — работал с Ext не один год. Безусловно такой библиотеки контролов нет и не будет ни для одной из описанных библиотек/фреймворков.

Да чего ж не верить? Верю. Печально, что кроме библиотеки виджетов вы ничего не заметили или не оценили.


Ну так зато они не стоят тысяч долларов, а бесплатны и опенсорсны.

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


А полноценные гриды в серьезных компаниях чаще пишутся либо самостоятельно. Нам в нашем проект Clarity хватило.

У нас с вами очень разные понятия о полноценности таких интересных компонентов, как grids. И об уровне допустимого качества, очевидно, тоже. И даже, рискну предположить, "сёрьезность" компаний мы воспринимаем весьма по-разному; хотя, на мой взгляд, тут дело скорее в задачах, нежели в компаниях.


Я бы мог много разных примеров из опыта привести, скажем про одного несолидного немецкого производителя люксовых авто, которому приспичило запихнуть навигацию/просмотр/редактирование базы из ~9 млрд парт-номеров запчастей в один TreeGrid. С "бесконечной" прокруткой, страничной подкачкой по запросу и прочими весёлыми штуками. Ну, вот дураки там сидят, не осилили сами-то запилить.


Или про один забавный и крайне несолидный НИИ в Швейцарии, который там коллайдеры всякие гоняет туда-сюда, а данных-то с них 100500 терабайт или что-то такое. Визуализировать надо, для обработки и анализа. Тоже идиоты, ха-ха, да плёвое ж дело самим-то налабать.


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


Мог бы рассказать, но зачем? У вас уже всё солидно, Clarity хватает со всеми багами, значит всем остальным тоже должно хватать.

В IE11 есть? Ой, нет.

При чем тут IE?


Mixins умеют? Нет.

Миксины много кто не умеет. Да и можно достичь подобия через анонимные классы и HOF


Overrides умеют? Нет.

Все умеют


Hooks умеют? Нет.

Какие еще хуки?


Dependency resolution умеют? Нет.

Какой еще resolution в динамическом языке?


Господи, ну хоть статические свойства классов-то умеют? Неа, всё ручками.

Все умеют

При чем тут IE?

Вообще ни при чём, кроме того, что многие организации до сих пор Windows 7 используют и IE11. И модернизироваться не собираются. А некоторые даже за поддержку Windows XP и IE8 платят, дураки несолидные.


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


Миксины много кто не умеет. Да и можно достичь подобия через анонимные классы и HOF

Мне всё равно, кто что не умеет. Я отвечал на вопрос: а чем таким плохая, негодная, архаичная классовая система Ext JS может быть лучше модной, годной, молодёжной ES6. Спрашивали? Отвечаем.


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


Все умеют

Условные тоже, и декларативно? Приведите примеры, если не сложно.


Какие еще хуки?

Да простые, типа таких: onBeforeClassCreated, onClassExtended, etc. Чем они могут оказаться полезны, объяснить или сами догадаетесь?


Какой еще resolution в динамическом языке?

Да вот такой, простой. Класс Foo зависит от класса Bar, и использует Qux. При загрузке класс Foo не создаётся, пока не загрузятся Bar и Qux, со всеми своими зависимостями.


И в динамическом языке, ага. Работает уже лет 8 как. И инструментарием поддерживается для сборки. А вы дальше там простыни import-ов ручками пишите, удачи.


Все умеют

Статические свойства классов. Вы давайте, приводите примеры в ES6, не стесняйтесь. Я-то свои слова подкрепить могу в любой момент, зря что ли этот кусок перелопачивал и тестами закрывал. :P

Забавно, у вас так бомбит, что вы скатываетесь в обыкновенное плоское хамство. Вы такой тут опытный эксперт, а все кругом плебеи, голова не жмет? :)
Я вам тут ничего не продаю и ничего доказывать не собираюсь, научитесь для начала манерам, а потом будем (пытаться) строить диалог.
Если же все-таки нужно, гуглите, не стесняйтесь — объяснить как это делается или сами догадаетесь?: Р

Забавно, у вас так бомбит, что вы скатываетесь в обыкновенное плоское хамство.

Да зачем же скатываетесь, и не выкатывался даже. Это разве не общепринятый в местных пенатах тон? :)


Вы такой тут опытный эксперт, а все кругом плебеи, голова не жмет? :)

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


Я вам тут ничего не продаю и ничего доказывать не собираюсь

Взаимно. На том и закончим беседу, если не возражаете. :) Про гугля не переживайте, разберусь как-нибудь. :)

Какое отношение IE имеет к ES6 классам?


Кстати, держите миксины:


function fooMixin(base) {
    return class Foo extends base {
        // ...
    }
}

class Baz extends fooMixin(Bar) {
    // ...
}
Какое отношение IE имеет к ES6 классам?

Простое: они в IE не работают и никогда не будут. А используется этот браузер ещё много где, и использоваться будет ой как долго. Ну, вот реальность жизни такая. Если вы хотите писать ES6 код, то вам придётся использовать инструментарий для переваривания этого кода в ES5.


Классовая система Ext JS появилась задолго до ES6, и работает во всех браузерах. Работает хорошо, протестирована неплохо и сюрпризов не преподносит уже давно.


А вот теперь внимание, вопрос: если всё равно нужно использовать какой-то инструментарий, и он уже есть свой, то имеет ли смысл кидаться впопыхах заменять его на чей-то чужой, просто ради "совместимости с будущим"?


Вот товарищ выше утверждает, что очевидно надо. Потому что журавль в небе очевидно лучше синицы в руках, это же JavaScript ZOMG.


Кстати, держите миксины:

Спасибо за пример, выглядит забавно. Наследуем от функции, которая возвращает функцию-конструктор.


Теперь ответный пример:


Ext.define('FooMixin', {
    extend: 'Ext.Mixin',
    mixinConfig: {
        id: 'foo'
    },
    ...
});

Ext.define('BarMixin', {
    extend: 'Ext.Mixin',
    mixinConfig: {
        id: 'bar'
    },
    ...
});

Ext.define('Baz', {
    extends: 'Quux',
    mixins: [
        'foo',
        'bar',
        ...
    ],
    ...
});

Что лучше читается? А если 10 таких mixin? А если все эти классы не пихать в один файл, а разбить для читаемости на отдельные? Мне-то всё равно, загрузчик зависимости отследит и подкачает в нужной последовательности.


Но это ещё полбеды, я могу про overrides рассказать и как оно с mixins сочетается. Или как можно в mixin вклиниваться до/после метода в основном классе, и для этого не нужно бодаться с контекстом и замыканиями. Или про то, как можно вклиниться в процесс создания класса и декорировать его по необходимости. Или про то, как родительский класс может делать всякие хитрые штуки с наследником. Или ещё что-нибудь интересное, там много.


Но вот беда, вся эта полезность ужасно архаична, сомнительна и немодна. Зато работает хорошо. Пичалька.

ExtJS уже перестал требовать обмазываться километровыми JSDoc-ами со всех сторон? Я и сам писал раньше свою классовую модель с умными примесями, которые позволяли примешивать конфликтующие примеси, но требовали выбирать реализацию при использовании. Но преимущества TS — решают.


Вы описываете, безусловно, приятные мелочи, но..


  1. Это именно мелочи. Ну то есть и без них не чувствуешь себя калекой.
  2. Это не стандарт. Даже плохой стандарт лучше его отсутствия. Выражается это в богатстве инструментария, простоте изучения, переноса кода между проектами пр.
ExtJS уже перестал требовать обмазываться километровыми JSDoc-ами со всех сторон?

Нет, не перестал и вряд ли перестанет. Любая сложная система требует изучения и использования документации, это как бы данность. Когда-нибудь пробовали писать нативное Win32 приложение? DVD с MSDN под руками держать не приходилось? Или томик Advanced Unix Programming вместе с батареей манов, если вы с другой стороны баррикад?


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


Я и сам писал раньше свою классовую модель с умными примесями,

Я вам страшную штуку скажу: я тоже писал. Да ладно, чего греха таить, все писали. Ничего страшного, пройдёт, главное не забыть потом руки помыть.


Это именно мелочи. Ну то есть и без них не чувствуешь себя калекой.

Конечно мелочи, ерунда какая. Всего-то полмиллиона строк кода в фреймворке надо будет переписать и протестировать, чтобы перестать чувствовать себя калекой.


Это не стандарт. Даже плохой стандарт лучше его отсутствия. Выражается это в богатстве инструментария, простоте изучения, переноса кода между проектами пр.

Вот именно такие аргументы вы и излагайте вашим клиентам, когда решите сломать поддержку старого API чуть более, чем полностью, ради абстрактных будущих стандартов, которые ещё и не везде работают.


А чтобы не сломать и поддерживать смесь старого с новым, надо малость мозгами пошевелить. Шевелят активно, но тема чуточку непростая и для решения проблем нужно время. Работающий инструментарий планируют в следующей версии.

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

Сравните:


/**
 * @param {string} bar
 * @param {Function} fn
 * @return {Function}
 */
function makeMoreFunctions(bar, fn) {
    /**
     * @param {Object} baz
     * @return {string}
     */
    return function(baz) {
        fn();
        /**
         * @return {string}
         */
        return function() {
            return bar;
        };
    };
}

function makeMoreFunctions( bar : string , fn : ()=> void ) {
    return ( baz : {} )=> {
        fn();
        return () => bar;
    };
}

Всего-то полмиллиона строк кода в фреймворке надо будет переписать и протестировать

Горбатого могила исправит. И горбатость ExtJS далеко не в классовой модели. Более вменяемая архитектура потребовала бы в 10 раз меньше кода для того же объёма функционала.

Сравните:

Обожаю смотреть, когда сперва обсирают, скажем, Perl за слишком высокую плотность и нечитабельность кода, а потом с умным видом то же самое делают в JavaScript. Пусть даже и разные люди. Браво, автор! Жжи ещё!


Более вменяемая архитектура потребовала бы в 10 раз меньше кода для того же объёма функционала.

Товарищ, верь: взойдёт звезда
над питерским болото-лесом,
и на могиле Экстжееса
напишут $mol-а письмена.


Ларри, сцуко, прав был на 110%: laziness, impatience and hubris.

> Perl за слишком высокую плотность и нечитабельность кода, а потом с умным видом то же самое делают в JavaScript.

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

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


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

> Почему-то вам даже не приходит в голову, что кому-то может представляться всё с точностью до наоборот.

Речь об объективных, измеряемых факторах, а не о том, что кому-то представляется.

Какие критерии и методики измерения вы использовали для определения полезности той или иной плотности кода? Поделитесь, будьте добры.


Особенно интересно про снижение количества синтаксического мусора и и семантической нагрузки в коде, при повышении плотности.

> Особенно интересно про снижение количества синтаксического мусора и и семантической нагрузки в коде, при повышении плотности.

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

Если есть конструкция, которая инкапсулирует в себе несущественные детали поведения — кода становится меньше, плотность возрастает, а семантическая нагрузка падает. Пример: замена классического цикла for на map. В данном случае из кода пропадает информация о о счетчике, и о логике построения коллекции. По-этому collection.map(x => ...) вместо for — это хорошее, годное упрощение.
Речь об объективных, измеряемых факторах

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

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


По-этому collection.map(x => ...) вместо for — это хорошее, годное упрощение.

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


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

> Ещё раз: поделитесь методикой измерений и результатами исследований.

Разобрать текст на токены и посчитать их количество.

> Цикл for() и операция map() семантически не эквивалентны, скорее даже ортогональны: процедурный подход против функционального. Цикл for() можно прервать заранее, можно изменять значение счётчика внутри цикла, и т.д.

Мы говорим о семантике конкретного кода, который заменяется на конкретный код, а не о семантике конструкций в общем. Если вы написали for с итерацией по списку, который дает тот же результат исполнения, что и map — то семантика двух вариантов кода эквивалентна, и for содержит несущественные для выполнения детали. Если в же у вас там какая-то особенная логика внутри — то, конечно, семантика неэквивалентна и поменять одно на другое нельзя — будет просто разный результат исполнения.

> И да, не надо пытаться продать мне функциональный подход.

Я вам ничего не продаю.
Разобрать текст на токены и посчитать их количество.

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


Мы говорим о семантике конкретного кода, который заменяется на конкретный код, а не о семантике конструкций в общем.

Цитирую:


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

Сперва вы делаете магические пассы руками и рассуждаете о семантической нагрузке конструкций в общем, потом оказывается, что речь уже идёт о конкретных примерах кода. Так всё же, А или Б сидели на трубе?


Давайте уже сойдёмся на том, что никаких доказательств у вас скорее всего нет, и вы пытаетесь притянуть за уши аргументы в пользу своих предпочтений. Я ничего не имею против ваших предпочтений, даже более того, склонен многие из них разделить, но принимать их как истину без веских доказательств не намереваюсь.


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

> Методика озвучена, давайте теперь результаты исследований.

Исследований чего?

> Сперва вы делаете магические пассы руками и рассуждаете о семантической нагрузке конструкций в общем

Нет, не рассуждаю. Вы как-то неверно поняли. Или я плохо сформулировал. Естественно, всегда оценивать надо конкретный код, то есть конструкцию в данном контексте, а не в общем, саму по себе.

Дело даже не столько в том, что код с JSDoc занимает в 5 раз больше места, сколько в том, что JSDoc не обладает описательной мощностью. Чего только стоит @return {Function}. Фактически JSDoc — это кривая статическая типизация для динамического языка. Сейчас есть более вменяемые инструменты статической типизации в виде Flow и TypeScript. Это не значит, что нужно всё бросать и срочно переписывать миллион строк говнокода (да-да, мне приходилось погружаться в это чудо с головой). Но эта вот технологическая устарелось уже даже не на сегодняшний, а на вчерашний день, — причина по которой толковые разработчики не горят желанием выбирать его для будущих проектов.


Вы бы не сарказмировали, а почитали/посмотрели этот доклад, хотя бы: Объектное Реактивное Программирование
Там описывается техника, реально позволяющая писать в 10 раз меньше кода, чем в том же ExtJS. Реактивное Программирование даёт хороший буст к производительности программиста и уменьшению багоёмкости производимого им кода.

@returns {function(string): boolean}


JSDoc довольно выразителен, зря вы на него так. Flow более вменяем, конечно, но для него нет ни одного инструмента для генерации документации.
По вашей же ссылке в самом начале:
You can use any Google Closure Compiler type expression, as well as several other formats that are specific to JSDoc.

И далее посмотрите Function Type и Function Return Type в списке аннотаций Closure Compiler.

JSDoc3 много в себе содержит того, чего нет в официальной документации. И подобная запись замечательно парсится самим jsdoc, можете попробовать сгенерить AST через опцию -X.

Более того, WebStorm и PyCharm замечательно использует jsdoc для генерации документации на лету по хоткеям Ctrl+Q, позволяя перемещаться между типами (если это не примитивные типы, а где-то в другом месте проекта объявленные через typedef).

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

Это называется "не поддерживается", а не "не работает". И, вообще-то, давно уже существуют способы обойти это ограничение.


Вот скажите, а у ваших веб-приложений бакэнды есть? И если есть — на чем они написаны?


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


Что лучше читается?

К чему привык — то и читается лучше, это не показатель. Но вот поддержка со стороны IDE у классов ES6 — лучше.

Это называется "не поддерживается", а не "не работает".

Цитируя любимого домовёнка: а всё одно, всё едино! Если не поддерживается, то по определению не работает. И не будет.


И, вообще-то, давно уже существуют способы обойти это ограничение.

Конечно существуют. Один из них мы как раз и используем, а именно, собственную систему классов, написанную на чистом JavaScript и обратно совместимую вплоть до чёрти куда.


Вот скажите, а у ваших веб-приложений бакэнды есть? И если есть — на чем они написаны?

Есть и на всём, что угодно. Есть на Java и Scala и C#, и на ColdFusion и на PHP, и на всех скриптовых языках, и даже на Go мимо пролетало.


У каждого клиента свои предпочтения по тараканам в голове, я стараюсь не судить людей. /s


Если на PHP или каком-нибудь Perl — то вопросов больше нет.

Ой как я люблю вот такие вот обобщения. Какой-нибудь там PHP или Perl, или там Python или Ruby, несолидные такие штуки, негодные. Круто как, одним махом — эх! Половину индустрии под одну гребёнку и в мусор. Размах!


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

Про считается нормальным — это вы вон тем, вышесметённым в мусор расскажите. А потом вас догонят извращенцы, которые на серверной стороне JavaScript пользуют, им тоже расскажите. Потом и я могу свои пять копеек вставить, если желание не отпадёт.


К чему привык — то и читается лучше, это не показатель. Но вот поддержка со стороны IDE у классов ES6 — лучше.

А у меня в носу козявки больше, бе-бе-бе. Аргумент примерно такого же плана.


Лично мне IDE вообще до одного места. Я бОльшую часть времени всё равно у браузера в отладчике живу, ну и в консоль одним глазом посматриваю.

Перестаньте читать между строк то, чего там не написано.


PHP я упомянул как пример интерпретируемого языка, которому не нужна стадия компиляции.

Перестаньте читать между строк то, чего там не написано.

Не имею такой привычки. Зато сарказм иногда через край капает, прошу прощения, если невзначай обидел. В намерения не входило. :)


PHP я упомянул как пример интерпретируемого языка, которому не нужна стадия компиляции.

Про PHP я не в курсе, не эксперт. Когда-то пришлось несколько месяцев ковырять исходники vBulletin, обе руки отвалились креститься наотмашь — закодировался, завязал и больше не пробовал, тьфу*3.


А вот как минимум про Perl и Python вы глубоко ошибаетесь: это языки динамические, но стадию компиляции они проходят ещё как. Ruby тоже, если мне склероз не изменяет.

Не имею такой привычки. Зато сарказм иногда через край капает, прошу прощения, если невзначай обидел. В намерения не входило. :)

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

Спасибо за спонтанный сеанс психоанализа, премного благодарен. Куда чек прислать? :)

> Лично мне IDE вообще до одного места. Я бОльшую часть времени всё равно у браузера в отладчике живу, ну и в консоль одним глазом посматриваю.

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

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


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


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


Хотя вот иногда и без IDE трудно. Приблуда, которая тесты через WebDriver гоняет, написана на Java, и надо и её тоже переворошить, чтобы результаты стабильнее возвращались. Глаза в кучу...

Лично мне IDE вообще до одного места. Я бОльшую часть времени всё равно у браузера в отладчике живу, ну и в консоль одним глазом посматриваю.

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

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

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


  • Несовместимое с другими версиями поведение обработчиков onreadystatechange элементов <script> в IE10
  • Нестандартное поведение querySelector на XML объектах в Chrome, и проблемы с selectSingleNode на оных же в IE8-9
  • Нестандартное поведение элемента <input type="file"> в IE/Edge
  • Проблемы с фокусированием элементов <input type="text"> и <textarea> в IE всех версий
  • Проблемы с flexbox в IE11 и определённых версиях Safari
  • Нестандартное поведение клавиатурных событий в определённых версиях мобильного Safari
  • Проблемы с некорректной обработкой атрибута aria-owns в Firefox
  • Проблемы с некорректным фокусированием родительских элементов на mousedown в Firefox же
  • Проблемы с некорректной обработкой табуляции на <input type="radio"> в нём же, болезном
  • Несопоставимо с жизнью медленная обработка синхронного setTimeout/clearTimeout в Chrome
  • Периодически ломающиеся обработчики различных событий в нём же
  • И так далее, и тому подобное, список в пять локтей длиной

Я достал блокнотик, высунул от усердия язык и с нетерпением жажду потока ценных указаний.

В случае специфических проблем с производительностью без профилировщика обычно, конечно же, никуда, но вот для чего вам в вышеприведенных примерах отладчик нужен — ума не приложу. Конкретно с вашими примерами я не встречался, но вещи, связанные с особенностями конкретного браузера, конечно, вызывали иногда проблемы. Но никогда не приходилось использовать для решения этих проблем отладчик. Собственно, я вообще не использую отладчик. Зато использую ИДЕ :)
В случае специфических проблем с производительностью без профилировщика обычно, конечно же, никуда, но вот для чего вам в вышеприведенных примерах отладчик нужен — ума не приложу.

Понюхал старик Ромуальдыч свою портянку и аж заколдобился… Ну вот, что я могу вам на это сказать? Видимо, вы какой-то особенный гигант мысли, способный по полутора симптомам и двум строчкам кода вникнуть, решить и пойти дальше. Завидую и преклоняюсь, преклоняюсь и завидую.


У меня вот, бывает, дни уходят, да какие дни — недели иногда. Как в том случае, когда невинная вроде на вид JavaScript конструкция роняла процесс IE7 с segmentation fault. Там тоже в отладчике пришлось пожить, только уже в Visual Studio. Да и ничего, потужился малость и нашёл баг в mshtml.dll, и способ обхода тоже.


Конкретно с вашими примерами я не встречался, но вещи, связанные с особенностями конкретного браузера, конечно, вызывали иногда проблемы. Но никогда не приходилось использовать для решения этих проблем отладчик. Собственно, я вообще не использую отладчик. Зато использую ИДЕ :)

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

> Видимо, вы какой-то особенный

Да нет, не использовать отладчик — вполне обычная практика.

> В случае клиентов Sencha это как раз я и ещё несколько таких же болезных.

Ну у вас же есть исходники? Зачем тогда отладчик? Обычно, почти всегда гораздо быстрее просмотреть код, чтобы найти ошибку, чем дебажить. Другое дело, если код откровенно плох.
Да нет, не использовать отладчик — вполне обычная практика.

Не использовать отладчик в браузере или не использовать отладчик вообще? В первом случае практика обычная в вашем случае и не применимая в моём; второй случай был бы слишком прискорбным, чтобы о нём думать.


Ну у вас же есть исходники? Зачем тогда отладчик?

Исходники чего, браузеров? Я уже который раз пытаюсь объяснить, что большая часть моего времени уходит на борьбу с браузерами и их различнейшими косяками. Одна и та же HTML/CSS разметка может вести себя по-разному в IE, Safari и Firefox. Один и тот же JavaScript код может вести себя по-разному в Chrome и Edge.


В какие исходники вы будете смотреть, когда из-за невинного вроде бы изменения конфигурации тестовой системы у вас начинают наглухо зависать тесты в IE11?


Обычно, почти всегда гораздо быстрее просмотреть код, чтобы найти ошибку, чем дебажить. Другое дело, если код откровенно плох.

При прокрутке строк в компоненте Tree с определённой конфигурацией, если прокручивать примерно по 10 строк, то на 20 или 30 строке случается "прыжок" обратно на 10 строк, после чего прокрутка срабатывает нормально.


Это описание из реального тикета, который меня попросили посмотреть сегодня. Читайте код, пронзайте силой мысли. Отладчик не использовать. Удачной охоты, время пошло.

> Не использовать отладчик в браузере или не использовать отладчик вообще?

Никто не говорит о неиспользовании в принципе, это уже будет какое-то религиозное убеждение. Речь о том, что реальная потребность в его использовании возникает крайней редко.

> Исходники чего, браузеров?

Так вы про отладку чего, самого браузера, в опкодах? Я-то думал вы про js, уточняйте тогда хоть.
Речь о том, что реальная потребность в его использовании возникает крайней редко.

Вы мне про Фому, я вам про Ерёму. У вас такая потребность возникает редко, у меня часто. Просто примите как данность, ладно?


Так вы про отладку чего, самого браузера, в опкодах? Я-то думал вы про js, уточняйте тогда хоть.

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


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


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

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

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

Гм. Отладчик JavaScript в браузере чем поможет? Ну не знаю, пошагово инструкции пройти или там переменные посмотреть. Прерывание поставить, посмотреть что происходит и откуда что приходит. В DOM заглянуть. Обычная отладка, в общем.


Что именно тут может быть непонятным?

> Что именно тут может быть непонятным?

Как это поможет вам понять в чем проблема, если код выполняться будет одинаково? Проблема ведь не в отлаживаемом коде будет.

Иногда код исполняется одинаково, иногда нет. Чаще всего проблемы не в исполнении JavaScript кода как такового, а в других частях браузера: DOM объектах, XML объектах, обработчиках событий, и т.д. Все эти объекты нативные, спецификацией JavaScript не закрыты и отданы на откуп производителям браузеров, иногда возникает разница в поведении. Ну, и баги тоже бывают, куда без них. Отладчик JavaScript как раз и помогает увидеть, как определённые вещи делаются в определённом браузере, и сравнить поведение с другими.


Одна из основных задач фреймворка — обеспечение одинаковой работы пользовательского кода во всех поддерживаемых браузерах. Не могу сказать, что мы справляемся с этой задачей на 100%, но стремимся, поэтому так или иначе нужно все эти проблемы обходить в JavaScript и CSS, других вариантов нет.

Читайте код, пронзайте силой мысли. Отладчик не использовать. Удачной охоты, время пошло.

Код-то отдайте :-)


PS на всякий случай поясняю — это шутка, в незнакомом проекте я за такой поиск бага не возьмусь. Вот в знакомом — другое дело.

Спасибо что пояснили, а то я уже полез за ссылками. :)


Впрочем, код и правда весь доступен для просмотра, вместе с тестами и прочей обвязкой, так что если будет интерес покопать весьма нетривиальные проблемы, заходите. ;)

К счастью с IE давно не работаю, но все проблемы, которые вы описали выглядят как «один раз разобрался, написал абстракцию и забыл до конца жизни».

Несопоставимо с жизнью медленная обработка синхронного setTimeout/clearTimeout в Chrome

А вот про это поподробнее, пожалуйста.
К счастью с IE давно не работаю, но все проблемы, которые вы описали выглядят как «один раз разобрался, написал абстракцию и забыл до конца жизни».

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


Или вы думаете, что по всем этим проблемам где-то многотомная документация написана?


Несопоставимо с жизнью медленная обработка синхронного setTimeout/clearTimeout в Chrome
А вот про это поподробнее, пожалуйста.

Это был такой забавный косяк в нашей реализации Jasmine, вылезший во время очередного раунда профилировки: перед входом в функцию-тело it() ставили таймер на случай, если что-то пойдёт не так, после выхода из функции таймер сбрасывали и шли дальше по очереди. В 99%+ случаев функция отрабатывала синхронно и таймер не пригождался; Chrome, как выяснилось, такой подход не любит и пара setTimeout/clearTimeout сжирала заметную долю собственного времени Jasmine. После того, как я переписал этот кусок, очередь стала пробегать на ~50% быстрее — но только в Chrome, в других браузерах эффект был далеко не так выражен.


Специально даю контекст, чтобы было понятно: проблема весьма специфична и встречается только в случаях, когда вы делаете миллионы вызовов пары setTimeout/clearTimeout в пределах одного цикла событий.

Я хотел бы заметить, что отладчик и профилировщик — слегка разные вещи.

Или вы думаете, что по всем этим проблемам где-то многотомная документация написана?

Уверен, что автора Сенчи встречаются с очень интересными проблемами, о которых ранее никто даже не догадывался и больше никогда не узнает.

Но не забывайте, что пользователи Сенчи уже не столкнутся с этими проблемами, а следовательно им помощь IDE — крайне уместна.

Выше я сказал правду — мне уже несколько лет не приходилось серьезно залипать в отладчике. Так, гляну иногда, какие именно данные пришли или куда стек ошибки ведет, но обычно IDE за меня все решает. Раньше, когда хуже понимал код — пользовался отладчиком чаще. Еще раньше, когда еще хуже понимал код — вообще алертами отлаживал. Правда, firebug тогда еще не появился))

А теперь маленький ньюанс: надо всего лишь разобраться и написать абстракцию.

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

Я бОльшую часть времени всё равно у браузера в отладчике живу


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

Я никогда не утверждал, что IDE не будет полезна вам. Я всего лишь утверждал, что IDE не так полезна мне, как может показаться вам с вашей точки зрения.


Ну вот, просто ради мысленного эксперимента допустите, что у нас с вами совершенно разные задачи?


Так, гляну иногда, какие именно данные пришли или куда стек ошибки ведет, но обычно IDE за меня все решает.

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


Я вот сейчас игру на Юнити пишу, так отладчик даже не настраивал — в нем еще ни разу не было необходимости

Это больше говорит о низком качестве вашего QA. Либо о высоком качестве QA этого самого Unity, чем бы оно ни было.

Ну вот, просто ради мысленного эксперимента допустите, что у нас с вами совершенно разные задачи?

Ваша проблема в том, что вы потеряли контекст. Изначально была речь о том, что интерфейс фреймворка был бы значительно удобнее для конечных пользователей, если бы использовались ес6-классы. Вам, конечно, может и все-равно, вы ведь в отладчике работаете, а пользователи — в IDE. Грустно, что вы так далеки от своих пользователей.

Тем более, я повыше уже признал, что, возможно, лично вы, как разработчик фреймворка, сидите в отладчике значительно чаще, чем любой другой жс-разработчик. Но я все-равно не верю, что вы сидите там БОЛЬШУЮ часть времени.

Это больше говорит о низком качестве вашего QA. Либо о высоком качестве QA этого самого Unity, чем бы оно ни было.

Жаль, что вам не приходит в голову идея, что я просто могу писать хороший код.

Ваша IDE умеет запускать код в десятке различных браузеров, ослеживать разницу поведения и решать, в каком случае и как эту разницу обойти?

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

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

Может, конечно, дело в том, что мы не поддерживаем IE.
Изначально была речь о том, что интерфейс фреймворка был бы значительно удобнее для конечных пользователей, если бы использовались ес6-классы.

Согласен, но эта идея была построена на неверной посылке: подразумевалось, что ES6 классы имеют поддержку IDE, а классы Ext JS её не имеют. Это не совсем так, существуют плагины Sencha для популярных IDE. Не могу сказать, насколько они хороши или плохи, т.к. сам ими не пользуюсь.


Вам, конечно, может и все-равно, вы ведь в отладчике работаете, а пользователи — в IDE. Грустно, что вы так далеки от своих пользователей.

К сожалению, это факт — работа разработчика фреймворка мало пересекается с работой собственно пользователей этого фреймворка. Я пытаюсь этот разрыв сокращать, периодически работая над какими-то персональными проектами на базе Ext JS; dogfooding очень помогает лучше понять болевые точки пользователей. :)


Про IDE я в курсе, большинство моих коллег тоже ими пользуются — если не ошибаюсь, в основном JetBrains. Но они тоже больше заняты разработкой нового кода, чем поддержкой/улучшением существующего.


Но я все-равно не верю, что вы сидите там БОЛЬШУЮ часть времени.

Я не считаю, сколько времени трачу на написание кода и сколько на отладку/поиск проблем, но по ощущениям отладка и правда занимает бОльшую часть времени. По крайней мере последнюю пару лет, раньше я действительно больше занимался разработкой и меньше улучшениями.


Жаль, что вам не приходит в голову идея, что я просто могу писать хороший код.

Как человеку, съевшему три собаки на отладке и тестировании кода, такая мысль прийти мне в голову не может в принципе. :)


Хорошего кода не бывает, бывает код приемлемый по качеству.


Может, конечно, дело в том, что мы не поддерживаем IE.

И в этом тоже, но скорее дело в специфике ваших приложений. Если вам не нужно работать с клавиатурой, фокусом и соблюдать требования по доступности, то это снимает изрядную долю проблем. Наш фреймворк должен всё это обеспечивать, и ситуация усложняется многократно.

Посмотрел бы я на вас на работу с WebGL, канвасами и воркерами без отладки :)
Я как бы много лет работал с ВебГЛ, канвасами и прочим. Конечно, иногда приходилось пользоваться отладчиком, но явно не «бОльшую часть времени всё равно у браузера в отладчике живу».

Тем более, чем больше работал — тем меньше необходимости в отладчике было
Вы хотите сказать, что без отладки сядете, и запилите без отладки что-то наподобие такого (UniGUI + WebGL)?
image
image
image
image
Вы хотите сказать, что без отладки сядете, и запилите без отладки что-то наподобие такого (UniGUI + WebGL)?

Иногда приходилось бы пользоваться отладчиком, конечно. Но редко. И уж явно не «большую часть времени».

Я, обычно, очень хорошо представляю в голове поток своей программы, особенно хорошо типизированной. Зачем в таком случае постоянно висеть в отладчике?
Скажу лишь, что в данном случае большинство проблем описанных вами как раз решаются использованием TypeScript. И будут классы, хоть в IE8.

Ваша преданность делу Microsoft достойна уважения, но предположительные причины оной восхитительно сомнительны и чрезмерной весомостью не располагают. Засим позвольте откланяться и не задерживать вас более от дел солидных своей непредусмотрительно бессмысленной светскою беседой.

Вам бы книги писать.


А по делу, то вам IE поддерживать надо, то не надо? Или инструмент расово неверный и религия не позволяет?

Писать бы, да времени нет. Вот работать надо, а я тут всякую фигню строчу. :)


А по делу, IE нам поддерживать надо и поддерживаем. Даже распоследняя версия фреймворка работает в IE8 и тесты проходят (большей частью). Потому что клиенты требуют, а кто платит $$, тот и прав.


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


Просто ради понимания моей перспективы, представьте что всё наборот, я работаю в Microsoft и жить не могу без TypeScript. Теперь продайте мне ES6 + Flow.

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


А вот вы пишите, TS не упал. И я знаю, что вы таки знаете толк в велосипедах :) не пробовали типизацию внедрять какую-нибудь? все-таки на динамике библиотечный код так себе пишется...

Как-то вы так лихо перескочили с фразы "большинство проблем решаются с помощью TS" на "всем TS, я создал, кто не в TS, тот лох".

Ага, ну давайте в риторику тоже поиграем. :) С самого начала:


  1. Товарищ MooooM размашисто, сплеча обзывает небезызвестный фреймворк "монструозным архаизмом". Годный революционный тон, что характерно, без какой-либо аргументации (даёшь отмечание столетия!)
  2. Я выступаю и слегка язвительно парирую тем, что монструозный атавизм, на минуточку, работает и таки вполне неплохо себя чувствует. И давно уж.
  3. Товарищ MooooM невинно изумляется крамольной мысли о том, что кому-то может не хватать блистательных возможностей сиятельного ES6.
  4. Я на пальцах объясняю, что таки нет, не хватает, и таки да, вот по пунктам.
  5. Товарищ MooooM делает разворот на 180 и начинает уповать уже на TypeScript, хотя и несколько менее размашисто, чем в п.1.
  6. Я позволяю себе вежливо усомниться в весомости аргументов в пользу оного TypeScript, из которых я до сих пор слышал только дифирамбы Майкрософту и титанам мысли, решившим уже за нас, сирых и убогих, ну просто все-все-все проблемы, только нужно расписаться вот здесь. Да, кровью, а вы не в курсе что ли?

Так что нет уж, пардоньте. Это не я прыгаю. :) Я просто пытаюсь отбиваться от товарищей, назойливо тыкающих в лицо разными Авторитетными Решениями.


TS вполне себе годный инструмент (хоть это и MS) и со своими задачами справляется ну просто на ура.

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


Никто никому ничего не продает и уж тем более не гонит на святую сенчу :)

Да богов побойтесь, Сенча ни разу не святая и Ext JS полный говна кусок. Никакого другого мнения вы от меня никогда не услышите. :)


Тут только это, маленький ньюанс… (с) Всё остальное ещё хуже. Я проверял. :(


А вот вы пишите, TS не упал. И я знаю, что вы таки знаете толк в велосипедах :) не пробовали типизацию внедрять какую-нибудь? все-таки на динамике библиотечный код так себе пишется...

Не совсем понимаю спектр вопроса. Лично я пробовал, или команда Ext JS? Лично я начинал когда-то с нацистско-типизированного Паскаля, проходил огонь C и медные трубы C++, так что с идеалами статической типизации в некотором роде знаком. Правда, потом открыл для себя свет исуса прелести полностью динамической типизации, переметнулся на тёмную сторону и взад больше не смотрел. Остальные товарищи по команде тоже пороху нюхали изрядно; начальник наш вообще эксперт по Java, большой поклонник C# и адепт Microsoft по самое не балуйся.


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


Да чего далеко за примерами ходить, ребята из соседнего отдела уже года три как периодически порываются выкинуть нафиг YUI compressor и заменить его на хвалёный Google Closure compiler. Баги лезут как зелёные черти после пол-литры, аж в глазах рябит. Это мы как бы только о минификации/оптимизации ES5 говорим, да? ES6-то тоже поддерживать надо, но как это сделать, чтобы не сломать весь мир — это как раз и есть вопрос на миллион.

Я extjs в последний раз видел в третьей версии (и с тех пор больше видеть не хочу :-), но по тому, что помню, es201x + flow вполне беспроблемно туда ложится.

Я вам ничего продавать не собираюсь, просто ради исторической справедливости отмечу, что Ext JS 3 и Ext JS 6.5 (последний) — это вещи настолько разные, что похожи только названием.


Поэтому ваши впечатления, хоть и вполне заслуженные, от нынешнего состояния дел весьма оторваны.

где вы берёте годный grid с поддержкой редактирования данных, валидации ввода и data binding

Есть мнение, что грид не должен всего этого уметь. Берёте грид, помещаете в него поля ввода и всё.

Очень-очень многое можно сделать с нуля. Только зачем в десятитысячный раз делать велосипед, если всё есть готовое и из коробки? Хоть и платное. Один фиг пока программеры с нуля сделают и тестировщики оттестируют то выйдет, как минимум, не дешевле.

Ну если готовое из коробки работает ровно как вам нужно — это замечательно. Но зачастую требования немного другие и допиливание такого "швейцарского ножа" под себя сравнимо по трудоёмкости с написание велосипеда.

Но зачастую требования немного другие и допиливание такого «швейцарского ножа» под себя сравнимо по трудоёмкости с написание велосипеда.

Вот! В том числе поэтому бывает сильно дешевле и быстрее купить платное и пинать саппорт (что мы с унигуем и делаем :) ) Чем возится самим с допиливанием с нуля хоть до какого-то рабочего состояния.
Есть мнение, что грид не должен всего этого уметь. Берёте грид, помещаете в него поля ввода и всё.

При всём заочном уважении, есть мнение, что мсье не знает, о чём говорит. От слова "чуть более, чем полностью". И всё.

Мисье, представьте себе, тоже разрабатывал. Так более аргументированно вы не можете ответить?

Могу, конечно. Зачем? Ваш категоричный тон и авторитетные пассы руками два сообщения назад говорят о том, что вы очевидно уверены в своём глубочайшем знании предмета и полной непогрешимости. Т.е. слушать и обмениваться опытом не горите желанием.


А членами меряться мне недосуг, извините.


Хотя если я всё же ошибся и вам действительно интересно, то могу объяснить, почему нельзя просто взять и поместить поля ввода в grid, и всё. С подробностями и путями решения проблем.

Мне, разумеется, интересно. Иначе бы не спрашивал. Моя уверенность строится не на самомнении или религии, а на анализе различных архитектур. Собственно, несколько ключевых особенностей $mol взято напрямую у ExtJS, но при этом решены основные родовые травмы подобных фреймворков. Поэтому, я думаю, $mol мог бы вам понравиться, когда нарастит побольше мяса из стандартных компонент.

Ох, господи. Ну хорошо, давайте меряться тогда уж.


Моя уверенность строится не на самомнении или религии, а на анализе различных архитектур.

А моя уверенность строится на многолетнем опыте разработки той самой Ext JS, включая практически всю поддержку accessibility: управление фокусированием, поддержку клавиатурной навигации, ARIA, экранных читалок и дисплеев Брайля, и проч. Во всех компонентах, в т.ч. grids, trees, и всём остальном. Фактически в двух разных фреймворках, которые нынче сливаются в один. Которые для поддержки этой accessibility мне пришлось очень глубоко переделывать, иначе ни черта не работало, т.к. изначально всё проектировалось для тыкания мышками или пальчиками.


И суммируя этот многолетний опыт каждодневного бития башкой в бетонную стену, я вам говорю: нельзя просто взять и поместить поля ввода в grid, и всё.


Достаточно? Дальше уже давайте конструктивно.


Так вот, начнём с design pattern. Мы с вами уважаем стандарты, поэтому возьмём за основу WAI-ARIA 1.1 Grid, даже конкретно вот эту секцию: Keyboard interaction, раздел про редактирование данных. Суммируя по-быстрому, нам нужно, чтобы:


  • Enter или F2 на ячейке включало редактирование
  • Enter в режиме редактирования подтверждал изменения
  • Esc в режиме редактирования отменял изменения
  • Tab и Shift-tab перепрыгивали к следующему/предыдущему полю редактирования, не покидая режим редактирования и сохраняя изменения при покидании ячейки

Если вы просто добавите поля ввода в ячейки grid, при этом не озаботившись обработкой событий и состояний, то grid не будет в курсе ни о начале редактирования, ни о конце. Навигация с помощью Tab тоже будет работать только до конца строки с ячейками, и только если не дай бог где-то на странице не случился элемент с tabIndex > 0. Если случился, то пиши пропало — фокус улетел и состояние сломано. Если даже ничего не пропало, то по стандарту рекомендуется заворачивать навигацию с последней ячейки последней строки на первую ячейку первой строки.


Всё это требует от grid быть в курсе, что такое редактирование данных в нём же, и даже более того: активно управлять процессом.


Далее можно упомянуть такие дружественные к разработчику штуки, как возможность определять тип виджета для редактирования ячейки (text input, text area, combo, etc), и картинка усложняется. Далее мы можем вспомнить о том, что данные нужно не просто редактировать в памяти, а ещё неплохо было бы оповещать какие-нибудь сторонние объекты о том, что редактирование записи состоялось. Для этого как минимум нужно понимать, когда у нас редактирование смещается с одной строки на другую, а ещё лучше, иметь возможность организовать транзакционный подход с атомарным подтверждением или отменой изменений. Это тоже чуточку выходит за рамки понимания отдельного поля ввода, даже очень умного. Далее мы можем вспомнить о случаях, когда набор данных не влазит в экран и нужна прокрутка по горизонтали или, ещё хуже, по вертикали с динамической подкачкой данных с сервера. И чтобы табуляция по полям редактирования работала и в этом случае тоже. И что юзеры имеют привычку начать редактировать ячейку, а потом кликнуть мышкой в другую часть страницы и фокус улетает, а это надо отрабатывать без потерь.


И это даже без учёта специфичных браузерных приколов, типа отсутствия нормальных фокусных событий в Firefox (до недавнего времени) или идиотской отработки mousedown на scrollbar в IE. И тем более без учёта возможности использовать в качестве редактора какого-нибудь HtmlEditor на базе iframe, а там с фокусными событиями отдельный многоцветный коленкор. Или вот какой-нибудь клиент решит засунуть в grid что-нибудь типа <input type="file"> и вы с ним на%@#тесь и напляшетесь в IE/Edge, потому что оно на голову больное. Или ещё 100500 таких же козырных, но вполне оправданных случаев (потому что клиенты $$ платят).


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


Поэтому, я думаю, $mol мог бы вам понравиться, когда нарастит побольше мяса из стандартных компонент.

Безумству храбрых… Но вам всё же проще будет, браузеры с тех пор чуточку попрямее стали. :)

Вот, vintage, берётся, в том числе это всё, за 600$ зеленых повторить на $mol :)

Я помню, когда сам был пионером, мы в таких случаях говорили: флаг тебе в руки и барабан на шею. :)


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


Собственно, именно так и получилось с Ext JS. Автор библиотеки дорастил её до версии 3, продал инвесторам за кучу денег. Инвесторы наняли зайчиков, те наобещали с три короба с высокой сцены и поскакали лабать версию 4. До основанья всё разрушили, а затем внезапно выяснилось, что свой, новый, мир построить в сроки не удаётся. Потому что, как известно, п##деть это не мешки ворочать.


А дальше история: Ext JS 4.0 вышла печальным говна куском, а зайчикам надоело морщить лоб и они ускакали на более зелёные полянки, срывать аплодисменты восторженных фанатов.


Вот с тех пор и подчищаем, пытаемся выполнить ещё тогдашние обещания. На мой взгляд даже неплохо получилось, но хайпаровоз уже давно уехал. :)

А моя уверенность строится на многолетнем опыте разработки той самой Ext JS

А кроме него что пробовали?


Фактически в двух разных фреймворках, которые нынче сливаются в один.

Это что за фреймворки?


Которые для поддержки этой accessibility мне пришлось очень глубоко переделывать

Эх, вашу бы самоотдачу, да нормальному фреймворку..


Мы с вами уважаем стандарты, поэтому возьмём за основу WAI-ARIA 1.1 Grid, даже конкретно вот эту секцию: Keyboard interaction

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


Enter или F2 на ячейке включало редактирование
Enter в режиме редактирования подтверждал изменения
Esc в режиме редактирования отменял изменения

Я бы сделал, что при фокусе сразу включается редактирование.


Tab и Shift-tab перепрыгивали к следующему/предыдущему полю редактирования, не покидая режим редактирования и сохраняя изменения при покидании ячейки

Это стандартное поведение, работающее и вне гридов. Хотя оно и не очень удобное. Мне нравится подход Оперы, где ctrl+стрелка переносят фокус на ближайший контрол в соответствующем направлении.


Далее можно упомянуть такие дружественные к разработчику штуки, как возможность определять тип виджета для редактирования ячейки (text input, text area, combo, etc)

Какие виджеты помечтил — такие и будут. Может хоть несколько виджетов в одну ячейку помечтить и всё будет работать, так как логика эта не будет привязаня ко гриду.


неплохо было бы оповещать какие-нибудь сторонние объекты о том, что редактирование записи состоялось.

Для этого есть реактивное программирование, которое в ExtJS не завезли.


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

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


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

Обычный ленивый рендеринг, реализованный в гриде.


отсутствия нормальных фокусных событий в Firefox

Да там небольшой воркэраунд с useCapture нужен и всё.


идиотской отработки mousedown на scrollbar в IE.

Речь про перенос фокуса? Ну это не страшно.


И тем более без учёта возможности использовать в качестве редактора какого-нибудь HtmlEditor на базе iframe

Да нафиг оно такое надо :-) У нас будет нормальный встраиваемый богатый редактор.


Или вот какой-нибудь клиент решит засунуть в grid что-нибудь типа и вы с ним на%@#тесь и напляшетесь в IE/Edge, потому что оно на голову больное.

Что там с ним не так?


Вот берёте все эти конфликтующие требования, смешиваете, помещаете в горшочек и поливаете-удобряете несколько лет

Единоразовая задача на не более чем месяц.


а на выходе как раз получается что-нибудь типа Ext JS grid.

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

А кроме него что пробовали?

Мы тут с вами в испанскую инквизицию играем, я посмотрю? Нет, $mol не пробовал.


Эх, вашу бы самоотдачу, да нормальному фреймворку..

Это легко. Контора возьмёт $350 в час или около того, но вы обращайтесь напрямую, сделаю небольшую скидку. :)


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

Как удобно! Чёрт, а я-то, старый дурак, и не догадался! Столько времени впустую потратил!


Далее мне даже цитировать лениво, а дискутировать тем более. С вами всё понятно, приходите когда всё вышеописанное реализуете, протестируете и продадите на -нцать миллионов долларов тупым кровавым ынтерпрайзам. Плёвое дело должно быть, с вашим-то гением и напористостью.

Попробуйте :-) Там много оригинальных решений, которые можно было бы стащить в ExtJS. А то и вообще так понравится, что подкините Сенче идею запилить ExtTS1 на новых шустрых, компактных и гибких рельсах. Сейчас $mol разрабатывают полтора землекопа в свободное от остальных задач время. Вливание хотя бы миллиона на маркетинг и наращивание функционала было бы очень кстати.

Молодой человек, вы всё ещё здесь? Не тратьте своё драгоценное время на обсуждение монструозных атавизмов, лучше взгляните в окно — там выстроилась очередь из инвесторов, все жаждут занести свои неправедно нажитые доллары к вам в маркетинг и функционал.


Если поторопитесь, то ещё успеете на вечернюю электричку в Долину; когда приедете, заходите в гости, я вам грамоту вручу. У меня тут специально заготовлена, для Героев Стартапа Второй Степени. Первая пока закончилась, но это всё равно для тех, кто уже на IPO вышел — через недельку обещали дослать тираж, даже с вашими темпами не должны опоздать.

Может вы найдёте более полезный способ самоутверждения, чем хамство незнакомым вам людям?

Вопрос разрабатывавшему: вы, если что, возьметесь запилить за 600 бакинских на ангуляре аналог унигуевских дбгридов, дб деревьев и чартов (хотя бы)? Нужен фронт + бэк. Язык бэка на выбор.

На Ангуляре — нет. А на $mol — вполне. Как раз за вчера сделал кроссплатформенное приложение, которое берёт OLAP куб, строит по ним табличку/графики с возможностью фильтрации по размерностям из этого куба.

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


То же самое и со стилями. Как только потребуется перекрасить стандартные синие окошки во что-либо другое, начинается ад. Об этом я даже в 2011 году написал статью.


После того, как я познакомился с Grunt, Webpack и современным фронтенд-стеком в целом, обратно меня уже никакими рассказами про "на порядок более богатые" классы не заманить.

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

Но ведь, что интересно, удавалось же? Я помню, как примерно в те же года пытался разобраться в Dojo. Вот уж где спагетти было жестокое. После него Ext JS 4 при всей своей лютой, бешеной глючности казался всё же глотком свежего воздуха.


Об этом я даже в 2011 году написал статью.

С тех пор чуток воды утекло. Вы считаете нормальным сравнивать фреймворк 6-летней давности с современными решениями?


После того, как я познакомился с Grunt, Webpack и современным фронтенд-стеком в целом, обратно меня уже никакими рассказами про "на порядок более богатые" классы не заманить.

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


Сейчас как раз пытаюсь потихоньку выбрать, на чём делать новый личный проект. Ext JS использовать очень не хочется по личным причинам, но всё остальное даже рядом не валялось. Хоть всё бросай и начинай свой фреймворк, с блекджеком и прочими штуками...

Но ведь, что интересно, удавалось же?

Манкипатчингом можно и в JS заниматься, но я не считаю это поводом для гордости. В современных UI-либах (в крайнем проекте использовал react-toolbox) просто нет необходимости где-то там патчить.


С тех пор чуток воды утекло. Вы считаете нормальным сравнивать фреймворк 6-летней давности с современными решениями?

Я слежу периодически за обновлениями компании Sencha. Вот у них и React-компоненты появились, тренд понятно куда ведет.


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

Это Sencha CMD хороший инструмент? Вы серьезно?

Манкипатчингом можно и в JS заниматься, но я не считаю это поводом для гордости.

Я не monkey patching имел в виду, а читабельность кода. Когда что-то не получается или не знаешь, как сделать, весьма ценно бывает залезть в исходники фреймворка и посмотреть, как сделано то или это. Частенько и находишь, какую настройку подвинтить.


Ext JS далеко не идеален, но даже в 2011 читался существенно лучше, чем многие конкуренты по цеху. А с тех пор чуть-чуть улучшился. :)


В современных UI-либах (в крайнем проекте использовал react-toolbox) просто нет необходимости где-то там патчить.

Багов в них тоже нет, чтобы не было необходимости патчить?


Я слежу периодически за обновлениями компании Sencha. Вот у них и React-компоненты появились, тренд понятно куда ведет.

Это как раз попытка выехать на тренде и заработать денег.


Это Sencha CMD хороший инструмент? Вы серьезно?

Я Ext JS имел в виду. Сам не большой фанат Cmd, но этот инструмент тоже легко недооценить. С первого взгляда это кривая и архаичная поделка для склеивания JavaScript файлов, но на самом деле Cmd умеет очень много разных интересных штук. Например, запускать тестовые сессии через WebDriver, с параллелизацией, очерёдностью, сбором статистики, свистелкам и перделками. ~500,000 юнит-тестов за полчаса, и так на каждый pull request. Просто для справки. :)

Я не monkey patching имел в виду, а читабельность кода.

Так или иначе, но возможность переопределить метод у Ext.panel.Panel чтобы show делал совсем не show называется манкипатчингом, каким бы читаемым он не был.


Багов в них тоже нет, чтобы не было необходимости патчить?

Можно прислать pull-request с фиксом и получить новый релиз в течение 1-2 недель, а не ждать релиза ExtJS раз в квартал. Кстати, а как правильно обновлять версии ExtJS? Из npm его не скачать, в package.json не прописать.


но на самом деле Cmd умеет очень много разных интересных штук

ничего такого, что нельзя сделать на классическом стеке с Webpack, Mocha, Jest и т.п.


Но Sencha Cmd нельзя поставить командой npm install sencha-cmd, что сразу ставит на нем жирный минус.

Так или иначе, но возможность переопределить метод у Ext.panel.Panel чтобы show делал совсем не show называется манкипатчингом, каким бы читаемым он не был.

Переопределение существующих классов это monkey patching, не спорю. Но вместо этого вы можете создать свой класс Foo.panel.Panel, унаследовать его от Ext.panel.Panel и переопределить метод show в своём классе. А это уже классическое ООП.


Можно прислать pull-request с фиксом и получить новый релиз в течение 1-2 недель,

Правда? https://github.com/angular/angular: 1,699 issues, 249 pull requests. Дальше смотреть лениво.


Кстати, а как правильно обновлять версии ExtJS?

Cmd и это тоже за вас умеет.


ничего такого, что нельзя сделать на классическом стеке с Webpack, Mocha, Jest и т.п.

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


Скажем, Mocha я глубоко не копал, а вот Jasmine пришлось переписать практически с нуля. Дважды. Первый раз, чтобы убить титанически мохнатых багов, которые Pivotal фиксить отказались, а второй раз, чтобы стало бегать в разы быстрее. Это к вопросу о качестве модно-хайповых решений.


Но Sencha Cmd нельзя поставить командой npm install sencha-cmd, что сразу ставит на нем жирный минус.

Конечно, всё должно быть модно-молодёжное на npm и Node.js. Если не на Node.js, то автоматически хлам и говно.


Внимание, вопрос: когда завтра появится какой-нибудь "Node killer" и вся ваша инфраструктура в одночасье превратится в хламчинскую тыкву, вы тут же бросите всё и ломанётесь переделывать ради бытия в тренде? А что? Все побежали и я побежал! ©

Кстати, а как правильно обновлять версии ExtJS?
Cmd и это тоже за вас умеет.

А откуда он качает новую версию? В любом случае получается какой-то велосипед вместо NPM.


а вот Jasmine пришлось переписать практически с нуля. Дважды. Первый раз, чтобы убить титанически мохнатых багов, которые Pivotal фиксить отказались

Ссылки сможете показать? Очень интересно посмотреть, без сарказма.


Конечно, всё должно быть модно-молодёжное на npm и Node.js. Если не на Node.js, то автоматически хлам и говно.

Если вы пишете на Javascript, то писать сборку не на Node.js будет странно. То же самое и с NPM, стандартный репозиторий пакетов, логично использовать именно его, а не свой велосипед.


Внимание, вопрос: когда завтра появится какой-нибудь "Node killer"

Node.js это рантайм. Он по определению подчиняется стандартам языка. Поэтому гипотетический Node killer будет более-менее совместим с текущей экосистемой.

А откуда он качает новую версию?

Из репозитория Sencha, конечно.


В любом случае получается какой-то велосипед вместо NPM.

Безусловно. Как вы представляете себе распространение коммерческих продуктов через NPM?


Ссылки сможете показать? Очень интересно посмотреть, без сарказма.

Если интересно и без сарказма, то могу не только показать, но и многое рассказать. Мы на базе Jasmine сделали мощнейший QA инструмент, и кроме собственно юнит- и интеграционных тестов проверяем код на утечки памяти, таймеров, Ajax запросов и т.д. Гайки зажимаем, насколько можем дотянуться. Давно уже подумываю статью про это дело написать, но со временем совсем швах.


К сожалению, в публичной версии Ext JS этой сборки Jasmine пока нет, но есть в коммерческой. Пробную версию Ext JS можно взять здесь: https://www.sencha.com/products/extjs/evaluate/. Можете ввести какой-нибудь левый, но работающий, e-mail адрес, и потом скачать по ссылке. А дальше открывайте ext/test/lib/jasmine.js.


Если вы пишете на Javascript, то писать сборку не на Node.js будет странно.

Абсолютно ничего странного, если вы пишете на JavaScript только клиентскую сторону. А с серверной стороны у вас могут быть какие угодно инструменты, и Node/NPM как раз будут казаться ортогональными и неестественными.


Поэтому гипотетический Node killer будет более-менее совместим с текущей экосистемой.

Это до тех пор, пока какой-нибудь очередной амбициозный пионер не решит заделаться потрясателем ослов основ. А случается это с завидной регулярностью; как говорят буддисты, единственное постоянство — это изменения.

Вы говорите, что нашли баги, которые Pivotal фиксить отказались. А ссылки на баг-репорт с ответом про won't fix показать можете?

Вот один, самый зверский. Если мне память не изменяет, то проблема была в некорректной отработке выхода из waitsFor по таймауту, что приводило к неисполнению блоков afterEach. Ну, и понятным последствиям для всех последующих тестов.


Там ещё много чего было, но смысла открывать PR уже не было.

Конечно смысла не было. Надо на Jasmine 2 обновляться, а не пинать труп 1й версии.


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


Может быть, ExtJS там и неплохо смотрится, таких больших проектов я не видел, к счастью

Конечно смысла не было. Надо на Jasmine 2 обновляться, а не пинать труп 1й версии.

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


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


Если найдёте, поделитесь пожалуйста. Я не нашёл. Проще было переписать Jasmine, чтобы добавить поддержку их нового API, не теряя старого. Ну и багов вычистить заодно.


Насколько я понял, у вас какая-то странная жутко энтерпрайзная система с очень большим и старым проектом.

Наш проект это Ext JS. :) Большой, старый. Сам фреймворк ещё ничего по сравнению с приложениями, которые на нём построены.


20000 тестов это большая цифра, интересно, как это вообще разрабатывается, и сколько человек это делают.

20k тестов было 3 года назад, текущая цифра ~66,500. Всё это добро прогоняется в 10+ браузерах, что даёт в сумме ~500,000 тестов за каждый прогон PR; в ночных сборках больше. Разрабатывается руками и головой, ничего принципиально нового. В основной команде 10 человек, включая меня.


Может быть, ExtJS там и неплохо смотрится, таких больших проектов я не видел, к счастью

Самый большой, что я видел своими глазами, состоит из примерно ~5,000,000 строк и компилируется в скрипт примерно 30 mb объёмом. Ничего, работает даже в IE8.


Ребята из services хвастались, что бывает и больше.

Если вы работаете над самим ExtJS то ваша позиция становится понятнее.


Полистал официальный сайт, нашел примеры: http://examples.sencha.com/extjs/6.5.1/examples
А где можно посмотреть их исходники? Вдруг 6я версия действительно стала лучше.

Если вы работаете над самим ExtJS то ваша позиция становится понятнее.

А вот мне не очень понятно, почему моя позиция становится понятнее. Если бы я работал не над фреймворком, а над странной жутко энтерпрайзной системой, что именно изменилось бы? Переписывать 20 тысяч тестов на несовместимое API внезапно стало бы проще? Вопросы обратной совместимости и нежелания отдельных вендоров поддерживать свои продукты стали бы менее острыми?


Любой софт стоит денег, а бесплатный ещё бОльших. Linux is free if your time costs nothing. ©


А где можно посмотреть их исходники?

Исходники всех примеров идут вместе с фреймворком, так же как исходники юнит тестов, Jasmine с обвязкой, и т.д. Я выше давал ссылку на страницу, где можно скачать пробную версию. К сожалению, более прямых ссылок у меня нет.

Исходники всех примеров идут вместе с фреймворком, так же как исходники юнит тестов, Jasmine с обвязкой, и т.д

Можно сколько угодно пинать NPM модность и молодежность, но это реально удобный способ получения библиотек и кода.


Если бы ExtJS (GPL версия) была бы доступна в NPM, а примеры кода — на Github, то куча вопросов бы сразу отпала. Я бы ответил себе на них самостоятельно. А так — ExtJS выглядит типичная энтерпрайз система, с намеренно завышенным порогом вхождения, чтобы непосвященные не догадались, что здесь вообще происходит. Желание копаться в бесконечных ссылках на официальном сайте пропадает окончательно.

Можно сколько угодно пинать NPM модность и молодежность, но это реально удобный способ получения библиотек и кода.

Это удобный вам способ. Java разработчики смотрят на вас недоумённо, у них есть Maven и кому нужно что-то ещё? C# разработчики смотрят на вас исподлобья, у них есть NuGet Gallery. У Python есть PyPI, у Perl есть CPAN, у Ruby есть RubyForge, и так далее ad nauseam.


Вы делаете вполне понятную ошибку, которая называется "своя рубашка ближе к телу". Ошибка же состоит в нежелании выглянуть из своего окопа и посмотреть на него под другим углом.


А так — ExtJS выглядит типичная энтерпрайз система,

Ext JS и есть типично энтерпрайз система, никаких сюрпризов.


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

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


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


Другое дело, что всем не угодишь и сложный продукт невозможно сделать простым для всех. Тут надо соблюдать баланс между необходимой простотой вхождения и достаточной демонстрацией возможностей, чтобы заинтересовать потенциального покупателя. Ресурсы тоже небесконечные, зачем тратить время и деньги компании на капризных непокупателей, которые попинают шины и уйдут, т.к. покупать и не собирались?


На эту тему вспоминается забавный диалог, который я видел в каком-то бложике. Автор решил попробовать IBM Informix IDS, скачал пробную версию, набил шишек и обиженно насупился: мол, кроваво-энтерпрайзная система стоимостью $60k за лицензию, а нормальный инсталлятор сделать не могут! Какие-то ещё конфиги надо создавать да переменные среды настраивать, ерунда какая!


На что был интересный комментарий в духе: если компания рассматривает покупку софта стоимостью $60,000 за лицензию, то наверное они могут себе позволить почитать README?


Желание копаться в бесконечных ссылках на официальном сайте пропадает окончательно.

Я думал, вам интересно посмотреть детали нашей реализации Jasmine? Ради этого можно и покопаться, а пользоваться Ext JS я вас не призывал и не буду. Если вам надо строить сложные Line of Business приложения для web, то вы сами к нам придёте, а для других задач есть другие инструменты.

Спасибо. Я уже посмотрел ваш профиль на гитхабе и понял, что вы работаете в Sencha.
Что объясняет все написанное далее в ветке дискуссии.

Мне кажется, вы сейчас неправильные выводы сделали, поместив меня в коробочку "фанат Ext JS, потому что работает в Sencha".


Нет, не фанат, я работаю в Sencha не за идею, а за хорошие деньги. И защищал не Ext JS, а прагматичный подход к выбору инструментария для разработки: если отбросить хайп и шелуху, а смотреть на выгоду и затраты от использования той или иной системы, то картинка перестаёт быть простой и чёрно-белой. ES6 хорошо, доморощенная классовая система плохо. Так? С моей точки зрения, не совсем и не всегда. Тем более, что никто не отказывался поддерживать ES6, но сделать это, не сломав многомиллионный существующий код, не так-то просто.

Вопрос: после покупки Сенчи что-то изменилось? Может слышали про какие-то планы Идеры?
Ну вот видите. И вы способны вести спокойную, аргументированную беседу без хамства.

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

Чем Ext действительно всегда был лучше других — богатая библиотека очень мощных компонентов, такой же нет и не будет ни у одного фреймворка. Но в реальности, даже самым навороченным CRM оттуда кроме основных гридов/деревьев и форм особо ничего больше и не нужно. А купить можно только все целиком. И дорого.

Про тулсет уже писали. Не считаю Sencha CMD хорошей вещью, по той простой причине, что как и все в ExtJS она сделала только для ExtJS.

Собственно тут и есть основной его недостаток — все самописное. Собственные классы были киллер-фичей в далекие времена бесплатного ExtJS 3. Сейчас же большая часть подобных ExtJS решений доступны в вебе и так. ES6 в Хроме есть даже нативно.

И TypeScript — да это превосходный (хоть и не идеальный) язык. Он не раз спасал нашу команду от ночей поиска странных ошибок. Он значительно снизил количество необходимых юнит тестов. И да, там есть классы, со статическими полями и тд.

Спорить о том, что ExtJS делает больше — бессмысленно, это очевидно так. В реальности же, при написании приложения на ExtJS вы пишете ExtJS, а не JS.
Все постоянно ругают Angular за то что вы должны его изучать, чтобы разрабатывать на нем (вс Реакт где вы пишете JS). Но в этом плане ExtJS — это вообще практически свой язык.

Это проблема по множеству причин: найм новых сотрудников, опыт текущих разработчиков, нулевая портативность кода, отсутствие шаренных репозиториев, невозможность использования любых «недо-фич» современного JS вроде Rollup, и тд.

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

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

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


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

Классы ES6 это, в сущности, тонкая обёртка над существующим прототипным ООП в JavaScript. Классовая система Ext JS это реализация классического ООП а-ля Java на базе прототипного, со многими расширениями и дополнениями. Если прототипное ООП вам по душе и вы его понимаете, то вполне возможно, что классы ES6 будут вам достаточны. Если же ваш опыт уходит корнями в более классические системы, то ES6 будет вызывать скорее недоумение своей бедностью и отсутствием даже базовых вещей. Вам, как адепту TypeScript, такая дихотомия должна быть понятна.


Чем Ext действительно всегда был лучше других — богатая библиотека очень мощных компонентов, такой же нет и не будет ни у одного фреймворка.

Далеко не только компонентов. Механизмы обработки данных, data binding, MVC/MVVM, транспортные механизмы, RPC, и т.д.


Но в реальности, даже самым навороченным CRM оттуда кроме основных гридов/деревьев и форм особо ничего больше и не нужно. А купить можно только все целиком. И дорого.

В вашей реальности, может быть — это просто означает, что у вас нет задач, для которых Ext JS подходит лучше всего. В реальности наших клиентов всё чуточку наоборот. Насчёт дороговизны я даже спорить не буду, $1k за разработчика это дорого? Даже не смешно.


Про тулсет уже писали. Не считаю Sencha CMD хорошей вещью, по той простой причине, что как и все в ExtJS она сделала только для ExtJS.

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


Собственно тут и есть основной его недостаток — все самописное.

Это же и основное достоинство, с какой стороны посмотреть. Ещё раз: вам шашечки или ехать? Если вам нужно в краткие сроки создать приложение, которое будет содержать сотни экранов для манипуляции данными, то наличие всех нужных инструментов из коробки будет преимуществом — за ними не надо бегать по всему интернету.


Собственные классы были киллер-фичей в далекие времена бесплатного ExtJS 3. Сейчас же большая часть подобных ExtJS решений доступны в вебе и так.

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


ES6 в Хроме есть даже нативно.

В Chrome есть. В Safari есть с последней версии, которая ещё далеко не у всех. В IE11 нет, а этот браузер является стандартом для гигантского количества организаций по всему миру, и будет ещё долго. У нас есть очень крупные клиенты, которые до сих пор используют IE7. И да, платят кучу денег за исправление проблем в Ext JS 4.x, которая поддерживает IE6+.


И TypeScript — да это превосходный (хоть и не идеальный) язык. Он не раз спасал нашу команду от ночей поиска странных ошибок. Он значительно снизил количество необходимых юнит тестов. И да, там есть классы, со статическими полями и тд.

Про юнит-тесты вы меня уже второй раз улыбаете. Извините, но если статическая типизация помогает избавиться от части юнит-тестов, то вы пишете неправильные тесты.


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


Ещё раз, с другого угла: Angular могли себе позволить делать что угодно и перешли на TypeScript, потому что им наплевать на пользователей фреймворка. С высокой колокольни. Команде Angular зарплату платит Google, а не пользователи. Google с их ресурсами вообще всё равно, взлетит Angular или утонет, с их точки зрения это мелочь в складке кармана.


У нас ситуация обратная: Ext JS это коммерческий продукт, и при этом основной продукт компании. Мы не можем делать резкие телодвижения, т.к. это приведёт к потере денег. Когда появился TypeScript, мы проводили опросы среди клиентов, и интерес оказался низким. На этом история закончилась.


Спорить о том, что ExtJS делает больше — бессмысленно, это очевидно так. В реальности же, при написании приложения на ExtJS вы пишете ExtJS, а не JS.
Все постоянно ругают Angular за то что вы должны его изучать, чтобы разрабатывать на нем (вс Реакт где вы пишете JS). Но в этом плане ExtJS — это вообще практически свой язык.

Извините, но тут я категорически не согласен. Да, у Ext JS есть своя классовая система, и именно она является основанием для всего остального. С ней вполне легко работать, и долгого изучения она не требует. В остальном же весь код это чистый ES5 JavaScript. У нас даже поддержки транспиляторов до недавних пор не было, за отсутствием необходимости. Никаких DSL у нас нет и не было, кроме шаблонизатора конечно же.


Другое дело, что разработка на Ext JS со стороны может выглядеть, как использование своего собственного языка — просто потому, что основная разработка сводится к соединению и конфигурированию компонентов. Ну так именно это и является достоинством: коробка с кучей кубиков, которые вы складываете, как вам надо.


Это проблема по множеству причин: найм новых сотрудников, опыт текущих разработчиков, нулевая портативность кода, отсутствие шаренных репозиториев, невозможность использования любых «недо-фич» современного JS вроде Rollup, и тд.

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


Под портативностью кода вы имеете в виду запуск на других платформах? Cordova и Electron поддерживаются из коробки. Про Rollup не в курсе, дискутировать не могу.


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

Насчёт стилизации позволю себе не согласиться — куча тем, в т.ч. страшно модная Material, чем вас не устраивает? Плюс практически все темы можно конфигурировать как угодно, всё на SASS.


По поводу мобильной разработки тоже дискутировать не буду, мне эта тема мало интересна.


Ну и конечно привязка к исключительно платным компонентам и невозможность их опенсорсно поддерживать, лично в нашем случае, делает невозможным использование ExtJS.

В вашем случае невозможность использования Ext JS проистекает из отсутствия задач, которые этот фреймворк решает. Я не собираюсь вам его продавать, даже наоборот, порекомендую не связываться, т.к. шишек набьёте, а толку будет мало.


Про open source поддержку вы меня опять улыбаете. Знаете, почему у нас её нет? Потому что качество патчей откровенно дерьмовое, а время на просмотр и оценку тратить нужно гигантское.

Если прототипное ООП вам по душе и вы его понимаете, то вполне возможно, что классы ES6 будут вам достаточны

Расскажите мне, пожалуйста, чем отличаются для программиста классические классы и прототипные? Вот в ТайпСкрипте — обертка над прототипа, а в Джаве — классические. Какая разница для программиста?

Я недостаточно хорошо знаю TypeScript и Java, чтобы сравнивать их напрямую. Насколько я понимаю, TypeScript реализует систему классов, более классическую и близкую к Java (точнее, к C#), чем ES6 и тем более до-ES6 JavaScript.


Вполне допускаю, что программисту, привыкшему к классическому ООП, TypeScript может прийтись по душе. В этом и есть основной смысл TypeScript, разве не так?


Другое дело, что TypeScript требует погружения по самую маковку и других вариантов нет. Если вам этот вариант нравится, вперёд. Многих он не устраивает по разным причинам, а использовать классовую систему TypeScript без самого TypeScript несколько затруднительно.


Что касается разницы классического ООП и прототипного, то тут уж я не буду читать вам лекцию, извините. Такие азы должны сами понимать.

ТС на самом деле ближе к Джаве, чем к ДоДиез, но еще он ближе к Го (правда, Он сильнее похож на Го, чем на Джаву)


Я разбираюсь в азах и даже немного больше и тем не менее интересно чем для программиста оно все будет отличаться? Статическая против утиной типизации? Наличием модификаторов доступа? Возможностью изменять прототип?


Первых два реализуются и в жсдок с ес6, а последний используется крайне редко. Вы вот говорите, что в ЕксЖС классах ближе к классическому. Чем ближе? И чем они отличаются для программиста кроме внутренней механики?

Вы вот говорите, что в ЕксЖС классах ближе к классическому. Чем ближе? И чем они отличаются для программиста кроме внутренней механики?

Использованием. Сравним с до-ES6 прототипным ООП: классы Ext JS можно наследовать, расширять с помощью интерфейсов (mixins), изменять с помощью overrides, у них есть конструктор и деструктор, статические свойства и методы класса, наследуемые статические свойства и методы, поддержка singletons, система конфигурирования с агрегированием наследованной конфигурации, интроспекцией и автоматическими getter/setter/applier/updater, возможности вклиниться в процесс создания класса на различных этапах через hooks, и ещё многие другие возможности, которые я навскидку просто не вспомню.


Отслеживание и загрузку зависимостей обеспечивает динамический загрузчик, который работает из коробки как в dev, так и в prod режимах. Зависимости отслеживаются не только явные (прописанные в коде), но и неявные (используемые) тоже, при использовании сборщика. Инструментарий дошёл уже до того, что в последних версиях зависимости прописывать явно уже нет необходимости, всё само определяется. Это несколько удобнее для прикладника, чем поддержка простыней import {}, даже если они генерируются автоматически.


Экземпляры объектов можно создавать как через стандартный оператор new, так и с помощью различных вспомогательных методов, с динамической подгрузкой. Это даёт возможность не зашивать названия классов в коде, а использовать объекты JSON с конфигурацией виджетов и чего угодно, которые скармливаются методу-конструктору и на выходе получается полное дерево UI виджетов со своими ViewModel и ViewConstructor, подписанными на нужные события и пр.


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


Экземпляры объектов тоже можно патчить через override(), бывает полезно для решения определённых задач. В методах можно вызывать родительский метод просто через this.callParent() и это поддерживается и в mixins, и в overrides, и вообще везде. Т.е. вам как прикладнику не нужно думать о том, что именно за метод будет вызван и из какого класса, mixin, или override.


Честно говоря, я уже устал писать, а перечислил только малую часть того, что умеет фреймворк и что может пригодиться прикладным программистам именно для разработки приложений. Ещё раз повторюсь: эта классовая система была создана задолго до ES6, где-то в 2010 или 2011, и кода на её основе написано очень много. Теперь попробуйте сравнить все эти возможности с ES6, стандартизованным в 2015, и вам станет грустно. Мне грустно.

Ну вы мне перечислили скорее фичи ЕксЖС в сравнении с ЕС5, а не разницу в прототипном и классическом подходах.

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

Да, в ес6 большинства названных фич еще нету, но вот уже в ес7, куда можно скомпилировать с бабеля уже есть практически все и даже больше.

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

Но, мне кажется, вы должны понимать, что это придется сделать в среднесрочной перспективе. У вас есть план на эту тему?
Ну вы мне перечислили скорее фичи ЕксЖС в сравнении с ЕС5, а не разницу в прототипном и классическом подходах.

Я перечислил фичи классовой системы Ext JS, которые напрочь отсутствуют в ES5 и которые как раз и являются отличием от прототипного ООП, вообще не имевшего понятия классов в ES5.


Я в своей классовой системе тоже делал миксины и callParent, а потом полностью отказался от миксинов,

У нас mixins используются в основном для кросс-использования между Classic и Modern toolkits. Которые по факту два отдельных фреймворка, бывшие Ext JS и Sencha Touch соответственно. Совершенно разные жизненные циклы компонентов и разные подходы к манипуляции DOM, но многие части кода достаточно похожи, чтобы использовать там и здесь. Поэтому без mixins никуда.


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

Для нас это не проблема, т.к. callParent используется только в dev режиме. В боевой сборке всё это подменяется на прямые вызовы методов в нужных объектах, так что никаких дополнительных расходов нет.


Да, в ес6 большинства названных фич еще нету, но вот уже в ес7, куда можно скомпилировать с бабеля уже есть практически все и даже больше.

Сравните: у нас всё это есть и уже давно, в ES7 только-только появляется и не всё, и когда оно будет в реальных браузерах… Кто знает. Закладываться на чужой транспилятор как основной инструмент обеспечения совместимости очень стрёмно, если говорить честно, особенно для коммерческой организации.


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

Отлично, спасибо огромное. :) Получается, что я достиг своей цели и показал, что "монструозные атавизмы" имеют под собой веские основания.


Но, мне кажется, вы должны понимать, что это придется сделать в среднесрочной перспективе. У вас есть план на эту тему?

Есть. Точнее, был. Новые владельцы компании уволили всю инженерную команду, кроме пары человек, и что будет дальше, непонятно. Скорее всего, ничего хорошего.


Всё вышенаписанное можно считать бесполезной грустью и ностальгией. ;(

и ещё многие другие возможности, которые я навскидку просто не вспомню.

Вы перечислили гораздо больше возможностей, чем есть в "классическом ооп", где никаких примесей, АОП и динамической подгрузки нет. ES6 — вполне "классический ооп".


Инструментарий дошёл уже до того, что в последних версиях зависимости прописывать явно уже нет необходимости, всё само определяется.

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


Это даёт возможность не зашивать названия классов в коде, а использовать объекты JSON с конфигурацией виджетов и чего угодно, которые скармливаются методу-конструктору и на выходе получается полное дерево UI виджетов

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


В методах можно вызывать родительский метод просто через this.callParent()

Надо ли говорить, что подобный хак сказывается на производительности не лучшим образом? Уж лучше нативный super.myMethod()

Вы перечислили гораздо больше возможностей, чем есть в "классическом ооп", где никаких примесей, АОП и динамической подгрузки нет.

Смотря какую реализацию брать за классическую. Mixins подобны интерфейсам, они есть уже давно в Java и C#, да везде на самом деле. Monkey patching активно используется, скажем, в Ruby. Динамическая загрузка пакетов/классов есть много где.


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

Это пока у вас бандлы не перевалят за мегабайт. В Ext JS на сей момент уже 2100+ классов, полная сборка classic toolkit весит 10 мб, modern toolkit уже 4 мб.


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

Про SAPUI5 не скажу, а в Ext JS можно вместо xtype использовать xclass и указывать именно тот класс, который вам и нужен. Работает точно так же динамически.


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

Никак не сказывается. В боевой сборке все вызовы callParent заменяются на прямые вызовы методов на нужных объектах, вызовы Ext.define() заменяются на более прямолинейный и быстрые механизмы и т.д. Очень удобно иметь динамический callParent() при разработке, но в боевой сборке это всё уже не нужно.


Уж лучше нативный super.myMethod()

Там, где он есть нативно, лучше. А там, где нет? Всё равно эмулировать так или иначе.

Mixins подобны интерфейсам

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


Это пока у вас бандлы не перевалят за мегабайт.

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


можно вместо xtype использовать xclass и указывать именно тот класс, который вам и нужен.

Замечательно, что это исправили, но было бы лучше, чтобы таких проблем и не создавали.


В боевой сборке все вызовы callParent заменяются на прямые вызовы методов на нужных объектах, вызовы Ext.define() заменяются на более прямолинейный и быстрые механизмы и т.д.

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

Интерфейсы не тянут с собой реализацию.

Я сказал "подобны", а не эквивалентны. Честно, нет вообще никакого желания тут с вами копья ломать по поводу терминологии и кто чего старается избегать. Сколько людей, столько и мнений.


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

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


Ну, или вот ребятам из системного отдела Microsft попробуйте рассказать про компактный код. Они вас внимательно выслушают.


Замечательно, что это исправили, но было бы лучше, чтобы таких проблем и не создавали.

Это не проблема, а фича. Точнее, две. И xtype, и xclass поддерживались с давних времён; если вам было недосуг почитать документацию или открыть тикет в поддержке, то это не наши проблемы.


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

На практике — нет, не било ни разу. Потому что:


  1. Мы говорим о боевой сборке, в которой нет и не может быть динамических зависимостей. Всё дерево вычисляется перед сборкой и является иммутабельным
  2. Замена кода сводится к банальному выкусыванию callParent и ссылкам на уже вычисленные методы в уже вычисленных зависимостях, см. п. 1
  3. Всё это очень, очень хорошо закрыто тестами.

А теперь лирическое отступление: вся эта ситуация отличается от ES6/ES7 и транспиляторов примерно чем? А хотя бы тем, что мы не зависим от чесания левой пятки у неизвестных людей, которые могут к чёрту сломать Babel или NPM в любой момент с катастрофическими для нас последствиями.

Почему бы тогда не сделать для своих клиентов свою реализацию транспилятора ES6+?

«Реализация» классов в TypeScript и ES6 совпадает, все отличие TypeScript — в добавлении типизации.

Спасибо, буду знать. В общем как я и думал, TypeScript по факту это просто амулет для адептов секты статической типизации, им без неё депрессивно и одиноко. :)

Меня уже настараживает рост количества статей на тему "почему я перешел с angular2 на vue.js
Действительно все так плохо? Я нахожусь в процессе изучения angular. Уже написал свое первое приложение. При написании столкнулся с большинством из описанных в недостатков. Меня давно посетила мысль — "стоит ли продолжение изучения". Angular позиционирует себя как фреймфорк но он так и не дал мне слоя для Экшенов. Пришлось внедрять ngrx… так стоит ли все таки продолжать писать на нем? Кто защитит angular?

Именно для подобных людей я и писал данную статью! Поверьте, подобные статьи появляются не просто так. Надеюсь моя аргументация убедит вас хотя бы попробовать Vue.js
Что скажете по этому аргументу:
Angular позиционирует себя как кросплатформенный. Для манипуляции с домом рекомендуется использовать Renderer для поддержки различных устройств.

Vue.js поддерживает кросплатформенность?
Да, посмотрите на Weex. Собственно его и разрабатывают одни из основных мейнтейнеров — Alibaba.
А вот бы еще Vue с React'ом сравнить. Мы после первой версии ng 1.5 ушли на React. К React'у тоже много вопросов, наиболее больные: обратная совместимость и обилие реализаций flux. С готовыми компонентами там тоже не сказать, что прям супер. Иногда подумываю, что не смотря на все минусы ExtJs3, по количеству качественных UI-компонентов он оставляет позади многие современные и модные JS-фреймворки.

Про имхо пишут только хорошее. То ли еще не успели много написать и волну хейта ждать через год, то ли китайцы такие молодцы решительно не понятно, а вкладываться в изучение еще одного фреймворка нет уже моральных сил.
У Vue.js очень понравились однофайловые компоненты. Грубо говоря, в React можно добиться того же эффекта через CSS-in-JS, но подход с разделением компоненты на html + js + css кажется более естественным. Анимации делаются гораздо проще, чем в React. Ну и в целом остается впечатление, что пользоваться vue проще.
Из недостатков — слабая поддержка IDE (в моем случае WebStorm), не хватает подсказок автодополнения.

Анимации — да, ахиллесова пята реакта. А разделение js и html "как во Vue" можно делать используя stateless functional components (там просто jsx) вместе с recompose. В итоге везде получаются чистые функции, благодаря чему очень легко декомпозировать/композировать и до неприличия просто покрывать юнит-тестами.

С ngrx/store и ngrx/effects на Angular писать очень приятно. Более-менее сложное/крупное приложение даже боюсь себе представить без них.

тогда я не понимаю почему angular обзывают фреймворком, когда на самом деле это библиотека.

Воспользуюсь моментом и задам вам вопрос по angular-у :)

Могли бы вы мне прояснить как правильно реализовать консистентность компоненты при роутах. Суть в том что компонента каждый раз пересоздаётся при переходе на нее через роутер. Я полагаю что хранить все состояние компоненты в store решает проблему. Правильно ли дублировать все данные компоненты в сторе?

В частности проблема проявляется при валидации формы на стороне клиента.
С валидацией на стороне сервера все хорошо, данные пришли в стор — компонента нарисовала ошибки.
Но как быть с клиентской валидацией, ведь там используется reactive forms?
т. е. найденные ошибки не сохраняются в store, тем самым при последующем показе компоненты (ну например я сделаю переход по истории назад и вперед) — ошибки исчезнут, так как компонента заново пересоздалась и все данные пропали.

неужели нужно и клиентскую валидацию перенести в слой effects?

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

Где заканчивается набор библиотек и начинается фреймворк — это хороший вопрос. Фреймворк может быть монолитным или модульным. Модульный — это и есть набор библиотек по сути. Я думаю, что тут два критерия:


  • наличие штатного процесса bootstrap-а приложения (это вообще такое заметное внешнее отличие фреймворка от библиотеки);
  • согласованность интерфейсов библиотек, таким образом, что в комплекте получается бОльшая ценность.

Можно считать ngrx опциональным модулем Angular :-) Если со временем его примут в основные репозитории, это будет совсем не удивительно, а даже закономерно.


В сторе — да, все состояние, но не "вьюшное", а уровня model. И селекторов не жалеть, много — не мало :-)


При этом store не отменяет стандартную "ангуляровскую" иерархию input-output. Это все комбинируется. В мире react есть термины "presentation component" и "container component". В angular имеет смысл делать точно так же. Presentation components про store не знают, там input-output.


С формами — надо подумать :-). Вообще может быть плюс-минус два варианта UI. Первое — когда форма редактирует "рабочую копию" (грубо говоря, клон), и есть кнопки типа "сохранить"/"отменить" — тогда по submit-у делается action со всеми изменениями, и потеря изменений при навигации воспринимается естественно. В этом случае проблем нет (и от меня обычно хотели именно такой логики UI). Второй вариант — когда редактируется-валидируется все на лету, тогда, конечно, состояние валидности тоже должно быть в сторе — ведь тогда наверняка есть другие компоненты, которые селектят редактируемое значение, и невалидное им не нужно.


В эффекты сваливать это точно не надо, в эффекты валятся, мм, сайд-эффекты :) Вот хорошая картинка:
https://codesequence.github.io/ngrx-workshop/assets/player/KeynoteDHTMLPlayer.html#58


В идеале, эффект — это цепочка rxjs-операций, на входе один action, на выходе — другой. При хорошем знании rxjs получается в эту логику уложить что угодно. У меня начало хорошо получаться где-то через два месяца :-)


Ну и раз уж зашла речь про роутер, не могу не упомянуть ngrx/router-store и RouterStateSnapshot.

спасибо.
можно еще ликбеза :)
никак не могу понять логику которая скрывается за тем что в redux разделили экшены и редьюсеры. ведь редьюсер можно представить как метод экшена.
в чем соль этого?
> в чем соль этого?

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

Соль в том, что action — это DTO и его можно сериализовать и, к примеру, передать на другую вкладку. Или вовсе на другой компьютер через бакэнд.

Экземпляры классов тоже можно сериализовывать/десериализовывать.

Но стандартных сериализаторов с такими возможностями — нет. В этом плане "родной" синтаксис JSON сослужил экосистеме плохую службу.

Redux — это такой упрощенный Flux, а Flux — это такой упрощенный CQRS, "спроецированный" на фронтенд. Почитайте про CQRS и получите ответы на все вопросы. ;)

Самое поразительное тут то, что разработчики Flux, по их собственному признанию, понятия не имели про CQRS, но пришли к ровно такому же дизайну (только с другими названиями). Great minds think alike :-)

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

Да это я скорее в шутку, с таким же успехом можно вспомнить, у кого мысли сходятся :-) Впрочем, не думаю, что в FB программисты занимаются маркетингом.

> разработчики Flux, по их собственному признанию, понятия не имели про CQRS

Многое говорит о разработчиках Flux.
Можно юзать reuse strategy.
Но, она помечена как експерементальная (хотя об этом в доке ничего не сказано) и мы при внедрении столкнулись к жуткой утечке памяти (может быть косяк был и наш, но неизвестн ов чем).
medium.com/@juliapassynkova/angular-2-component-reuse-strategy-9f3ddfab23f5
medium.com/@juliapassynkova/angular-2-component-reuse-strategy-9f3ddfab23f5

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


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

Да, всё так печально с Angular 4. Начинал несколько месяцев назад тестовый проект на Angular 4 для изучения сего фреймворка. До этого был вполне приятный опыт с Angular 1.5.x. Но теперь же, за что ни возьмёшься — одна боль. Документация — боль.
Но где-то месяц назад вскользь посмотрел vue.js и желание возвращаться к Angular 4 отпало.

Так что, видимо, не на пустом месте у многих людей возникают аналогичные мысли и чувства на счёт перехода на vue.js
По какой-то причине команда Angular решила сделать класс HttpParams иммутабельным.

А это не только в angular-е, сейчас вообще модно везде пихать иммутабельные объекты… Делается же оно для того чтобы избежать трудновоспроизводимых ошибок в сложном софте (кто-то где-то поменял то что не должен и у нас всё умерло).


RxJS operator import

Так а angular то тут причем? (самое забавное что некоторые операторы лежат в других файлах...)


Navigation

То что написано это цветочки, самая засада в том что похоже вообще нету именованных роутов, соответственно если есть /object/:id/comments, то везде придется писать this.router.navigate(['other', id, 'comments']);, как потом это поддерживать — загадка (или как-то можно?)


Вообще писать про документацию Angular даже нет смысла

А чем дока то не нравится? Она сейчас в виде допиливая реального приложения, вполне неплохо имхо, особенно для начинающих. Думаете абстрактные примеры были бы лучше? Ну а перевод вообще хз зачем нужен — (1) там все очень просто, (2) перевод всегда отстают от оригинала (а у них там постоянно что-то меняется). И кстати на SO обычно всё уже есть (удивительно, но оно даже не сильно путается с angular js).


Совершенно не ясно зачем делать именно так.

А какая разница какой css? SCSS кстати включается один раз и навсегда — всего то надо указать соответствующую опцию для cli при создании проекта (а если использовать scss то можно импортировать чужие стили и возможно это бы решило проблему с приоритетами).

похоже вообще нету именованных роутов

Тут я даже больше скажу. В альфа версии ангуляра были именованные роуты. И в документации даже была рекомендация пользоваться ими. И на примере объяснялось, почему это так удобно. Когда я обновлял ангуляр в своем проекте до стабильной версии, я был удивлен, с какой стати именованные роуты выпилили. Такой непоследовательности в разработке я искренне не понимаю.

Дисклеймер: данная статья строго субъективна...

Вот никак не понимаю в чём польза субъективных статей? Критика должна быть объективной, а не субъективной.
Про синтаксис шаблонов вообще не понял в чём ваша претензия.
Обещали, что будет достаточно только [] и ().… К сожалению в реальности директив едва ли не больше чем в AngularJS.

И что Вы предлагаете? Выкинуть эти директивы или что?
Вот если подобное убрать, то получится добротная статья. А так пустая трата времени.
К примеру, есть два варианта:
*ngIf="!isHidden"
или
[style.display]="isHidden ? 'none' : 'block'"

У вас есть выбор. Не вижу здесь противоречия — «Обещали, что будет достаточно только [] и ()». Обещание выполнено, если автор его привел дословно. Использовать ngIf вас никто не заставляет. Но с директивой код выглядит приятнее.

У меня немного другой посыл был: если выкинуть директивы, то и ангуляр уже не нужен.

Опять я должен додумывать. Но я понял о чём Вы. В этом случае тоже надо привести примеры «как должно быть», возможно, из других JS-фреймворков. Тогда критика будет конструктивной.
А как будет, если внутри не просто «hi!», а целый шаблон с переменными? Вложенные скобочки?
{!isHidden && (
  <ul>
    {items.map((item, i) => (
      <li key={i}>{item}</li>
    )}
  </ul>
)}

Вопрос не в синтаксисе (дело привычки), а в том, что можно и без директив интерфейс компоновать

Основная идея Ангуляр — это расширение возможностей HTML, сделать HTML динамическим.
HTML is great for declaring static documents, but it falters when we try to use it for declaring dynamic views in web-applications. AngularJS lets you extend HTML vocabulary for your application.

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

По-моему вы критикуете именно синтаксис. Или вам не нравится название «директива»?

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


Мне не нравится, что я добавляю примеси компоненту снаружи этого компонента. Я его натурально патчу добавлением какой-то неведомой ерунды через *directive. Я нарушаю инкапсуляцию компонента, тогда как все возможные примеси должны быть объявлены внутри компонента, и это нормально. Ненормальны все эти костыли с директивами, появившиеся (а изначально в первых RC ng2 их не было) из-за того, что местные компоненты не могли оборачивать другие без дополнительных dom-нод. Вот и портировали директивы из ng1.

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

Это как это? Примесь по определению должна быть внешней. Максимум — можно требовать, чтобы она применялась только в классам, реализующим определенны нинтерфейс. А «примеси, объявленные внутри компонента» — это уже явно не примеси, может, имелось виду что-то другое?

Возможно, трейты больше подойдут?


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

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

С таким подходом и НОС убрать придется :)
> HOC порождает новый компонент, директива — нет

Это на самом деле лишь условность, пронаблюдать которую можно исключительно в определенных граничных условиях из-за особенностей реализации change detection :)

А так вобщем-то никто не запрещает интерпретировать применение директивы как создание новой компоненты.

А, вы опять про свои "HOC" в ангуляре, я не их имел в виду :)


Проблема в том, что порядок "применения" HOC (которые настоящие HOC, в Реакте) вы выбираете явно путем композиции, а директивы мешаются в общую кучку. И я кстати не знаю (честно) как разрешается в ng2 порядок применения директив. Вот в ng1 это сделано реально отвратительно, прям как z-index'ы.

> И я кстати не знаю (честно) как разрешается в ng2 порядок применения директив.

Он решается тем способом, что в случае применения неструктурных директив напортачить затруднительно (то есть их применение «почти» коммутативно, или на это следует рассчитывать при их написании), а структурные директивы применяются только по одной к ноде.

Да нет, примеси — это именно что изнутри. А снаружи — это плагины.

Примесь — эта функция, которая класс приняла и другой класс вернула. Где тут «изнутри»?
> Вы сейчас описали не примесь, а декоратор.

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

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

Яркий пример примеси:


enum common_fields = "int row; int col;";

class Person {
    mixin( common_fields );
    string name;
}

Сама по себе примесь разумеется внешняя сущность. Но примешивает её сама сущность (функция, класс, модуль), а не тот, кто эту сущность использует.

Это лишь одна из реализаций, причем наверняка еще и в языке со статической типизацией.

> Но примешивает её сама сущность (функция, класс, модуль), а не тот, кто эту сущность использует.

Вы слишком большое внимание уделяете синтаксису (то, что строчка с миксином внутри определения класса), смотрите на семантику (да, к слову, в большинстве вариантов реализации миксин применяется на готовый класс явно, то есть и синтаксически «снаружи»). В вашем случае — миксин не внутри класса, к которому вы его применили. Он внутри класса-результата. А класс, к которому применен миксин — это class _Anonymous { string name; }

Думаю вам стоит отдохнуть и перечитать мой комментарий ещё раз :-)

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

+100, и мало того: HTML вообще категорически не подходит для создания приложений. Это язык разметки документов, и сколько бы ни тужились W3C, таковым он и останется. Даже WebComponents ситуацию сильно не облегчат, это кривой костыль.


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


Но постойте, где-то я это уже видел...

Пардон, при чём тут GWT? Я говорил о написании приложений на чистом JavaScript, а не Java.

Да я понимаю, просто чуть дальше подумал. Кроме HTML у нас ничего нет. Только JS, ворочающий HTML под капотом, который вы "где-то уже видели" :)

Кроме HTML у нас есть DOM API, которое никто не мешает использовать напрямую. Генерации HTML можно избежать практически на 100%.


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


Насчёт "не приживаются" как бы могу поспорить. Коммерческие решения, приносящие многомиллионные выручки каждый год, чуточку противоречат гладкой картине мироустройства.

DOM API

угу, такое же неповоротливое легаси, не знаю даже что хуже


можете просто писать код JavaScript, который просто исполняется в браузере напрямую, в том же виде, в каком вы его написали

Могу, но не пишу, ибо я не мазахист и предпочитаю хоть какие-то абстракции.


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

Ну вот вы и описали этот необходимый слой.


Насчёт "не приживаются" как бы могу поспорить.

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

угу, такое же неповоротливое легаси, не знаю даже что хуже

А вы пробовали его по-настоящему вдумчиво курить? Я пробовал, и оно не такое плохое, как кажется на первый взгляд. Тем более, когда выбора нет. /s


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

Так за чем дело стало? :)


Насчет "не приживаются" я имел в виду DX, а не продажи.

Не знаком с термином. Что означает DX?


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

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

Тем более, когда выбора нет.

Когда выбора нет, все кажется неплохим


Так за чем дело стало?

По-разному, есть проекты на реакте, есть на разных ангулярах.


DX

Developer Experience. Это как UX, только DX.

Когда выбора нет, все кажется неплохим

Это кому как. Я предпочитаю не вставать в позу, а использовать существующие инструменты. И каждый раз внезапно выясняется, что всё не так уж плохо, и если не рыдать крокодильими слезами, а работу работать, то она таки работается.


По-разному, есть проекты на реакте, есть на разных ангулярах.

Реакт это каким образом слой абстракции над DOM? Оно же просто за шкирку берёт и мордой в свой псевдо-XML салат тыкает всю дорогу, причём ещё и в оторванный от HTML. Худшее, что можно придумать: не HTML, не DOM, и не абстракция никакая, а лютая, бешеная смесь кода с тегами. PHP, дубль два.


Ангуляр в этом плане гораздо лучше смотрится, при всех своих болячках. Оно если и не абстрагируется от HTML, то хотя бы сильно не отрывается.

Ради интереса: вы какие-нибудь фреймворки использовали в продакшн кроме Ext JS и UniGUI?


Реакт это каким образом слой абстракции над DOM? Оно же просто за шкирку берёт и мордой в свой псевдо-XML салат тыкает всю дорогу, причём ещё и в оторванный от HTML.

А что по-вашему тогда абстракция? А React Native тоже browser DOM использует? А серверный рендеринг?

Ради интереса: вы какие-нибудь фреймворки использовали в продакшн кроме Ext JS и UniGUI?

Нет, сам не использовал, не было необходимости. Участвовал в проектах миграции с Angular 1 на Ext JS, но в роли консультанта больше, т.к. из потрохов одного вендора в потроха другого смотреть обычно некогда. Мы больше идеи тырим. :)


Про UniGUI тоже не в курсе, по крайней мере пока.


А что по-вашему тогда абстракция?

Достаточная абстракция, в данном случае, позволяла бы писать код, не зная особенностей HTML и/или DOM. Позволяет ли вам React не знать, как будет выглядеть HTML разметка? Не думать об особенностях веб среды, а сконцентрироваться на вашем приложении?


Если ответ "да", значит абстракция достаточная. На мой испорченный вкус и имея возможность сравнить с другими решениями, абстракция в React намазана тонким слоем на HTML и трещит по швам.


А React Native тоже browser DOM использует?

React Native это безусловно пример глубокой абстракции, т.к. методы разработки веб-приложений перекладываются на совершенно инородную среду. Другое дело, что сама идея вгоняет меня в оторопь: возьмите всё самое плохое, что с таким трудом долгие годы выкорчёвывало PHP, со звоном ляпните это в HTML/JavaScript и потом самозабвенно пихайте густой струёй в чуждую среду, игнорируя громкий треск лопающихся по швам конвенций и лучших практик.


Был бы верующим, крестился бы до синяков.


А серверный рендеринг?

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

> Достаточная абстракция, в данном случае, позволяла бы писать код, не зная особенностей HTML и/или DOM. Позволяет ли вам React не знать, как будет выглядеть HTML разметка? Не думать об особенностях веб среды, а сконцентрироваться на вашем приложении?

Вы какбы не совсем понимаете, как оно устроено. Что в реакте, что в ангуляре, о разметке как раз вы и не думаете, потому что там разметки нет. Там есть декларативное описание интерфейса (которое выбрали намеренно «под html», так же как это делается и в современных гуитулкитах вроде какого-нибудь javafx), но это не html, он не работает как html и даже генерит оно в результате не html (в реакте — вдом, в ангуляре — вью, в обоих случаях — это js-объекты на js) :)
А выводом всего это на экран (в виде реального дом, в виде хтмл в случае server-side рендеринга, в случае нативных интерфейсов для мобилок/десктопа, или если угодно, для рисования розовых единорогов) — занимается конкретно слой рендера. Поменяли рендер — и никакого хтмл не осталось и в помине, при этом jsx/шаблоны у вас останутся.
Вы какбы не совсем понимаете, как оно устроено.

Скорее всего, совсем не понимаю. Спасибо за объяснения, может быть поможет сдвинуться с мёртвой точки.


Что в реакте, что в ангуляре, о разметке как раз вы и не думаете, потому что там разметки нет.

Подождите, давайте с самого начала тогда. Реакт немного в сторонку отодвинем, давайте возьмём за пример Ангуляр: с ним я хотя бы чуть-чуть знаком.


Вот пример из документации: https://docs.angularjs.org/guide/templates, в котором чёрным по белому говорится про HTML разметку, расширенную (augmented) директивами Angular.


Даже если я вообще совсем ничего не понимаю, и вся эта конструкция из примера не имеет отношения к разметке HTML, то каким образом она является абстракцией от HTML, если подобна ему чуть более, чем полностью? "Если оно выглядит как утка, ходит как утка, и крякает, как утка — я назову его уткой" ©


но это не html, он не работает как html и даже генерит оно в результате не html (в реакте — вдом, в ангуляре — вью, в обоих случаях — это js-объекты на js) :)

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


Речь идёт о том, есть ли у вас возможность не мыслить в терминах кучки DOM элементов и скриптов, или такой возможности нет. Я в упор не вижу, каким образом Angular позволит оторваться от веб-разработки, если первое, с чего начинается приложение, это тег <html>, пусть и с дополнительными атрибутами.


Поменяли рендер — и никакого хтмл не осталось и в помине, при этом jsx/шаблоны у вас останутся.

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

> Вот пример из документации: docs.angularjs.org/guide/templates, в котором чёрным по белому говорится про HTML разметку, расширенную (augmented) директивами Angular.

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

> Вот в таком случае абстракция как раз и будет, но не в случае с web приложениями.

Так она и есть, что значит «будет»? И почему не в случае с веб-приложениями?

> web приложения в современном виде не являются образчиком вменяемого подхода к разработке приложений в общем смысле

Пока что лучшего подхода для разработки УИ не придумали, хотя делалось много разных попыток. За неимением гербовой — приходится писать на простой.
Тут возникла терминологическая путаница, возможно, я сам виноват, что не уточнил. Когда в 2017 упоминают ангуляр, то обычно имеется ввиду второй (четвертый, пятый, ну и так далее) ангуляр, который совсем другой фреймворк.

Хорошо, давайте посмотрим на современный Angular. В обзоре архитектуры опять же написано английским по серому (выделение моё):


Angular is a framework for building client applications in HTML and either JavaScript or a language like TypeScript that compiles to JavaScript.

The framework consists of several libraries, some of them core and some optional.

You write Angular applications by composing HTML templates with Angularized markup, writing component classes to manage those templates, adding application logic in services, and boxing components and services in modules.

Angular 2/4/whatever может и другой фреймворк, но предназначен он для разработки веб-приложений и HTML упоминается в самом начале. О каких высоких абстракциях мы тут можем разговаривать?


Так она и есть, что значит «будет»? И почему не в случае с веб-приложениями?

"Будет" это просто оборот речи. Имелось в виду, что Angular и ему подобные фреймворки/библиотеки изначально ориентированы на разработку веб-приложений и создавались именно для этого. Никаких особенно высоких абстракций для веб-приложений они не дают, поскольку вы всё равно должны быть в курсе, что разрабатываете именно веб-приложение. Трансформация же веб-приложения в нативно-мобильное даёт на выходе что-то иное, не то, что было на входе, и уже будет являться достаточной абстракцией, хоть и очень странной.


Пока что лучшего подхода для разработки УИ не придумали, хотя делалось много разных попыток. За неимением гербовой — приходится писать на простой.

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


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


Советские ботинки тоже хорошие, если других не видел. ©

> Angular 2/4/whatever может и другой фреймворк, но предназначен он для разработки веб-приложений и HTML упоминается в самом начале.

Ну упоминается, и что? В самом фреймворке то ни html нет, ни dom (если не учитывать слой самого рендера, реализацию которого пользователь фреймворка не видит).

> Никаких особенно высоких абстракций для веб-приложений они не дают, поскольку вы всё равно должны быть в курсе, что разрабатываете именно веб-приложение.

Нет, не должны. Зачем? Разработчику вообще не нужно знать, где и как будет работать его приложение. Он описал УИ, описал его логику, а кто и как там будет ее запускать — на сервере, клиенте, с домом или без, нативно или нет — не важно. От этих деталей фреймворк нас абстрагирует.

> Трансформация же веб-приложения в нативно-мобильное даёт на выходе что-то иное, не то, что было на входе

Так и в веб-случае у вас на выходе совсем не то.

> Доставка контента с помощью веб-технологий даёт неоспоримые преимущества, но прямизна разработки как UI, так и прочих компонент приложения в эти преимущества не входит.

Конечно же входит. Именно по-этому практически все современные гуи-тулкиты мимикрируют под html/css. Можно сколько угодно называть подобный подход кривыми костылями — но лучше до сих пор никто не придумал.
От этих деталей фреймворк нас абстрагирует.

Вашими бы устами… Впрочем, дальше дискутировать мне уже лень и времени жалко. Цитируя любимую фразу моего босса: Let's agree to disagree.


Именно по-этому практически все современные гуи-тулкиты мимикрируют под html/css. Можно сколько угодно называть подобный подход кривыми костылями — но лучше до сих пор никто не придумал.

Вы совершаете очень модную ошибку, принимая популярное за хорошее.

Речь идёт о том, есть ли у вас возможность не мыслить в терминах кучки DOM элементов и скриптов, или такой возможности нет.

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

Т.е.разработчик-прикладник не должен создавать строить дерево на основе «div»-ов, li, ng-if и ng-repeat, а взять некий готовый компонент «acme-tree», воткнуть его директиву в компонент «acme-panel», которая воткнута в компонент «acme-app», прописать свойства, подисаться на события — и не должен волноваться, какой конечный HTML/JS/CSS сгенерится в результате. В идеале, нативные HTML элементы (или даже вовсе не HTML) должны встречаться только в терминальных компонентах.

А вот тот, кто делает эти «acme-tree», «acme-panel» и т.п. вполне себе могут волноваться о деталях рендеринга, о доступности и т.п.

Т.е. да, Angular-приложение действительно начинается с html/body/ng-app, но при наличии развитой библиотеки компонент весь HTML на этом и должен закончиться. Angular сам по себе не предоставляет полную библиотеку высокоуровневых компонент (панели, гриды, деревья, навигация и т.п.), достаточной для написания любого приложения, он даёт некий базовый набор (формы, роутинг, базовые сервисы) и API для создания/расширения библиотек компонентов.
> Речь идёт о том, есть ли у вас возможность не мыслить в терминах кучки DOM элементов и скриптов, или такой возможности нет.

Ну так она и есть. У вас же нету ни дома, ни скриптов. Как вы можете мыслить тем, чего нет?

> но при наличии развитой библиотеки компонент

Мы зачем-то все в одну кучу мешаете. Задача ангуляра — абстрагироваться от манипуляций с домом, html и прочим. Он это делает. А библиотеку компонентов предоставлять — задача библиотек компонентов.

> и не должен волноваться, какой конечный HTML/JS/CSS сгенерится в результате.

Так он и не волнуется :)
Мне кажется то ли я не на тот коммент ответил, то ли вы. Я отвечал nohuhu, и как раз о том, что Angular позволяет абстрагироваться от DOM и позволяет меньше волноваться о рендеринге.
Ах, ок. Я подумал, ваш тезис состоит в том, что раз ангуляр библиотеки компонент не предоставляет — то и абстрагироваться не дает.
Предполагается, что разработчику конечного пользовательского приложения следует мыслить в терминах компонентов. Мышление в терминах HTML, скриптов и стилей следует отдать разработчикам компонентов.

Что интересно, именно то, что вы описываете, и делает Ext JS...


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

… и не делает ни один из конкурентов.


он даёт некий базовый набор (формы, роутинг, базовые сервисы) и API для создания/расширения библиотек компонентов.

К сожалению, это малая часть того, что реально нужно для построения большого приложения. Основное мясо находится далеко не в роутинге и базовых сервисах. Можно сколько угодно говорить об абстракциях в низкоуровневых библиотеках навроде Angular или React, но сути это не меняет: компоненты вам всё равно придётся либо где-то искать, либо делать самим. А дальше желаю удачи абстрагироваться от HTML и всего остального.


Нет, конечно же это не проблема, кто мог такую ересь подумать. Любая же серьёзная организация способна запилить свой собственный grid.

Вопрос не в синтаксисе (дело привычки), а в том, что можно и без директив интерфейс компоновать

Нужно! Именованные скобки (они же теги) должны быть частью выражения.

А в чем, собственно, разница? *ngIf же не базовая директива, она реализована поверх фреймворка, а не вшита в него.

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

Очень доставляли подобные шаблоны в Spacebars. Точнее там их юзал в связке с Jade (на тот момент еще), в нем все эти циклы, условия, интерполяция переменных, подстановка компонентов и т. д. вообще выглядели нативно, что мне казалось проявлением чего-то божественного. Типа не может же быть такого, что прочитав 2 страницы документации по jade и еще немного по Blaze, потратив от силы пару часов, можно начинать делать интерфейс, разбивая все на компоненты, и все без боли и страданий, и сразу получая работающий код, с хорошей декомпозицией, и делая все максимально наивным способом.


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

Хочу дополнить по поводу библиотек, основанных на bootstrap, в частности, ngx-bootstrap (она же ng2-bootstrap), ng2-select, от valor-software. Увы и ах, хотя и самые распространенные, с продуманностью и глючностью у них есть проблемы, особенно у select2, который выглядит довольно заброшенным. Но бог с ним, с select2, даже modal в виде сервиса появился только этим летом, и то без resolve (без передачи параметров в конструктор). Некоторые глючные стили теперь “вморожены“ и не фиксятся без !important..


Как альтернатива для bootstrap, еще появилась (imho) более вменяемая ng-bootstrap, от тех людей кто писал angular-ui для angular-js, но там только ещё не выпущенный bootstrap4, и тоже альфа-беты.


За инфу про VMware спасибо!

Эм, в ngx-bootstrap сервис NgbModal был с давних времен, а resolve не нужен — инпуты проставляются через modalRef.componentInstance

С ручными импортами в rxjs — это проблема неработающего в случае с прототипами/объектами/псевдо-неймспейсами tree shaking, по сути временная. Когда-нибудь ее решат, и можно будет импортировать весь Rx, не беспокоясь о размере билда. Конечно, было бы хорошо уметь ругаться на этапе компиляции — но если до такого умения дошли, то можно и tree shaking сразу сделать.

C претензиями к Roter, HttpClient и Forms я соглашусь, но к плюсам ангуляра можно отнести относительную модульность и как результат возможность не использовать эти модули, что мы благополучно и делаем на нашем проекте — у нас свой роутер, свой http клиент и свои Dynamic Forms. Причины почему, так вышло были разные и я не агитирую поступать так же, но, тем не менее, возможность заменить не базовые модули ангуляра есть, если стандартные чем-то не устраивают.
Раньше я тоже считал, что модульность Angular — большой плюс для Lazy Loading'а. Но задумайтесь — весь минифицированный Vue.js весит 60Кб. Спрашивается, а стоит ли весь этот boilerplate с модулями того?
Я имел в виду, что с архитектурной точки зрения основа Ангуляра не привязана к отдельным его модулям и он не принуждает их использовать. Ничто не мешает делать запросы через, например, jQuery или fetch.

Не смотрели ли вы в сторону $mol, который целиком и полностью написан на TypeScript?


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

CLI нужен, лишь когда приходится писать много типового кода. В $mol, чтобы создать компонент нужно всего-лишь создать файл, написать в нём строчку кода и всё.


В целом не совсем разделяю взгяд автора на RxJS, т.к. библиотека невероятно мощная.

Но и невероятно неэффективная.


Но суровая правда в том, что Object.observe нативно мы все же не увидим

Какое отношение имеет RxJS к Object.observe?


Потому что вы очевидно (потратили кучу времени на поиск проблемы) забыли заимпортировать сам оператор

В $mol такой проблемы в принципе нет, так как зависимости подключаются автоматически по факту их использования.


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

Зачем вообще какой-то там роутер, если можно просто прочитать реактивное значение?


pages() {
    return [
        this.Menu() ,
        ... this.$.$mol_state_arg.value( 'order' ) ? [ this.Order() ] : [] ,
    ]
}

в Angular есть два типа форм: обычные и реактивные.

В $mol всё реактивное и кастомизируемое. У компонент есть свойства, в которые он может писать и из которых читать. В простейшем случае:


value( next = '' ) { return next } 

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


Без метаданных декораторы тоже можно использовать — во время компиляции, но толку в таком случае от них не очень много.

От той metadata, что генерирует TS пользы не особо много: никаких интерфейсов, только ссылка на класс. А вот сами по себе декораторы позволяют уменьшить копипаст.


Dependency Injection в Angular. Сама по себе концепция замечательная, особенно для unit тестирования.

В динамически типизированном языке польза для юнит тестирования сомнительна, ведь и так можно налету изменить что угодно. Мы остановились на более практичном компромисе — контексте. Например, в компоненте может быть написано:


this.$.alert( 'Hello!' )

Где $ — по умолчанию — глобальный контекст. Но любой компонент в дереве рендеринга может изменить контекст для всех вложенных в него на любую глубину компонент:


@ $mol_mem()
context_sub( ) {
    const context = this.context()
    const subContext : $mol_view_context = Object.create( context )
    subContext.alert = ( message ; string )=> this.$.$my_dialogs.alert( message )
    return subContext
}

Всё, теперь вложенные компоненты, ничего не зная ни про какой DI, не системный алерт вызывают, а тот, который задали мы, а TS, разумеется, проверяет соответствие сигнатур. Аналогично можно не только функции дёргать/переопределять, но и любые другие сущности: переменные, классы, объекты.


А вот пример компонента из проекта на Angular:

Заголовок спойлера
import {Component} from '@angular/core';

import FileService, {ContentType, IFile} from "../file.service";
import AlertService from "shared/alert.service";

@Component({
  selector: 'app-file',
  templateUrl: './file.component.html',
  styleUrls: ['./file.component.scss']
})
export class FileComponent {

    Input() item: IFile;

    constructor(private fileService: FileService, private alertService: AlertService) {
    }

    public isVideo() {
        return this.item.contentKeyType === ContentType.VIDEO;
    }

    public downloadFile() {
        this.fileService.download(this.getFileDownloadUrl()).subscribe(() => {
            this.alertService.success();
        });
    }

    private getFileDownloadUrl() {
        return `url-for-download${this.item.text}`;
    }
}

На $mol было бы куда лаконичнее:


Заголовок спойлера
namespace $.$$ {

    export class $my_file_loader extends $.$my_file_loader {

        item() {
            return null as $my_file
        }

        is_video() {
            return this.item().contentKeyType === $my_file_type.VIDEO
        }

        @ $mol_mem()
        downloadFile() {
            this.$.$my_files.download( this.download_url() )
            this.$.$my_alerts.success()
        }

        private download_url() {
            return `url-for-download${ this.item().text() }`;
        }
    }

}

Но лучше упростить апи:


namespace $.$$ {

    export class $my_file extends $.$my_file {

        is_video() {
            return this.file.is_video();
        }

        @ $mol_mem()
        download() {
            this.file().download()
            this.$.$my_alerts().success();
        }

    }

}

Синтаксис шаблонов — основная претензия к Angular. И по вполне объективным причинам.

В $mol вообще нет шаблонов как таковых. Есть только: компоненты, декларативное описание их взаимосвязей (условно это можно считать шаблонами без логики) и скрипты с логикой (TypeScript). Шаблоны — слишком низкоуровневые штуки, которые только мешают построению приложения из компонент.


доки Vue. Мало того, что написаны подробно и доходчиво, так еще и на 6 языках, в т.ч. русском.

В $mol нет таких развесистых док, да ещё и на 6 языках. Зато исходные коды простые, понятные и содержат кучу реальных примеров использования. Например, тот же грид не пытается уметь всё на свете от фильтрации до паджинации, а предоставляет минимально необходимых интерфейс, чтобы как угодно его кастомизировать. То есть тут на лицо филисофия юникс — каждый компонент делает только свою задачу, но делает её хорошо и легко стыкуется с другими компонентами.


body .ui-tree .ui-treenode .ui-treenode-content .ui-tree-toggler

В $mol атрибуты, к которым привязываются стили, генерятся автоматом, с учётом контекста. Что позволяет переопределять стили любого элемента стороннего компонента, как бы глубоко в компонентной иерархии он там ни находился, при этом сохраняя одну и ту же специфичность и избегая конфликтов имён. Например: [my_app_menu_head_close_path] {} — это стиль для пути в svg-иконке, которая является кнопкой закрытия в шапке страницы, которая является панелью меню в нашем приложении.


Наличие двух различно работающих компиляторов само по себе довольно опасно звучит,
и на деле постоянно приводит к проблемам.

По той же причине в $mol нет рантайм компилятора и пофайловой загрузки скриптов. Даже во время разработки собираются продакшен бандлы, чтобы разработчик видел ровно то, что он получит на проде.


Да, я понимаю, что выбирать фреймворк по наличиую UI компонентов в корне неверно

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


довольно скудное количество готовых наборов UI компонентов

Важно не количество, а качество. Куда лучше, если сообщество сконцентрировано на улучшении одной стандартной библиотеки, чем фрагментированно на кучу ui-наборов.


библиотека Clarity от vmware. Набор компонентов впечатляет, документация крайне приятная, да и выглядят здорово. Как никак VMware серьезнейший мейнтейнер и есть надежда на светлое будущее.

Касательно $mol — уже видел ваши комментарии про него ранее, но боюсь размеры community слишком малы, чтобы избрать его для серьезного enterprise приложения. А pet проекты и на Vue делаются супер быстро (опять же размеры community и простота/быстродействие).

А про упавший билд Clarity — спасибо за юнит тесты, которые действительно что-то проверяют (уверен, что пофиксят в ближайшее время).
А pet проекты и на Vue делаются супер быстро

На $mol ещё быстрее.


размеры community

Какая польза от размера комьюнити? Большой выбор велосипедов? Большой выбор экспертов на SO?


простота/быстродействие

$mol ещё проще, модульнее и с глубокой поддержкой ленивого рендеринга.


упавший билд Clarity — спасибо за юнит тесты, которые действительно что-то проверяют

Не просто упавший билд, а сломанная мастер ветка со всеми вытекающими.

Какая польза от размера комьюнити? Большой выбор велосипедов? Большой выбор экспертов на SO?

Хотя бы, чтобы можно было задать вопрос, и на него ответили адекватно, а не:


— Рискну предположить, что заодно и без автокомплита и перехода к определению по Cmd+Click.
— Да нет, всё работает благодаря тайпскрипту.
— А тайпскрипт как работает без импортов/экспортов?
— Как положено он работает.

А какой более адекватный ответ тут может быть? Вы делаете необоснованные предположения — вам отвечают, что вы не правы. Проверить можете сами, если не верите.

А причём тут правильность или неправильность? Второй комментатор спросил о том, как отсутствие импорта позволяет IDE перейти к месту определения сущности, вы объяснить не потрудились. Видите, вы и мне предложили бросить всё, развернуть ваш фреймворк и проверить.

А как думаете IDE справлялись с ES5, где никаких импортов не было? Сканировали весь проект и всё.

А как думаете IDE справлялись с ES5, где никаких импортов не было? Сканировали весь проект и всё.

По личному опыту знаю, что очень плохо справлялись. И даже с ES6 плохо справляются в сложном проекте.

А c TypeScript отлично и единообразно справляются благодаря Language Services.

Language Services тоже может корректно отрезолвить класс, не импортированный явно?

Да вы с комментариями про $mol уже стали прямо-таки локальным мемом

$ вероятно сигнализирует о глобальных планах экспансии продукта, но пока его за trees не видно :))))

Что хочу сказать после того, как команда довела до релиза средненького размера проект (SPA, ~40k sloc ): выбором angular довольны.


Batteries included в широком смысле слова — от инфраструктуры (ng-cli великолепен) до заданной структуры проекта и навязываемой декомпозиции. Сторонних модулей уже (местами) достаточно много.


Typescript и aot сильно снижают количество регресионных факапов. Спорно (а мне спорить лень), но за годы знакомства с typescript'ом у меня все сильнее растет удивление, что кто-то еще пишет на голом js.


А главное — практически ни разу ни у кого из команды не возникло чувства "я сражаюсь с фреймворком". Не возникло чувство, что он ограничивает; что есть вещи, которые на vanilla.js были бы проще.


В плане UI еще в статье забыли @angular-mdl — местами сырая, но очень приятная библиотека.


Основные минусы (ну куда же без них?):


  • О документации проще сказать что ее не существует. То, что есть — плевок в лицо.
  • Более отвратительной системы роутинга я еще не встречал. Надеюсь, ее сожгут и сделают заново.
  • За организованный репозиторий модулей отдал бы левую ногу

В целом: для больших SPA пока что иных вариантов не видим. А для мелочи (особенно fire-and-forget мелочи) vue уже очень сильно начитает тащить своим минимальным размером

А в чем проблема роутинга? Только начал разбирать angular и хочеться узнать про эту проблему подробнее?
Скорее всего mjr27 имеет в виду params и queryParams, которые Observable. С другой стороны, они позволяют при смене роута на тот же компонент, но с другими params, обновлять его, не пересоздавая.
Кроме того, нет нормальных именованных роутов и тупая сигнатура Router#navigate
> Кроме того, нет нормальных именованных роутов

А что подразумевается под «нормальными именованными роутами»?
Назначение путям имен, например orders => '/items/:xx'. Типк как сделано в ui-router например, или vue-router. Чтобы например можно было поменять путь, не меняя код везде, где этот путь используется. То есть, чтобы можно было например изменить'/items/:xx' на '/foo/orders:xx' не делая поиск-замену по всему проекту.
> Назначение путям имен, например orders => '/items/:xx'.

const paths = {
    path: "my/patch",
    anotherPatch: "another/patch",
    oneMorePatch: "one/more/patch",
}

const appRoutes: Routes = [
    { path: paths.path, component: MyComponent },
    { path: paths.anotherPatch, component: AnotherComponent },
...
];

так? или что еще должно быть?

Вот такое должно быть. Без этого грустно


const appRoutes: Routes = [
    { path: "language/:lang/category/:category/item/:item", component: MyComponent , name: "itemView" },
];

// ...

const url: string = this.router.reverse("itemView",  {lang: this.lang, category: this.categoryId, item: item});

А в идеале даже


/* Привет из django */
 {path: "language/(?P<lang>\s{2,3})/category/(?P<category>\w+)/item/(?P<item>\d+)", component: MyComponent , name: "itemView" }
Ну это все пишется за полчаса. Потому и убрали. Нужен такой функционал достаточно редко, а реализуется — элементарно, причем в том виде, в котором будет нужен в данном конкретном случае.
Ну это все пишется за полчаса

Явно не за полчаса + странный аргумент для "batteries included" фреймворка.


Нужен такой функционал достаточно редко

Необоснованное предположение. Нам такой функционал был не нужен достаточно редко; обработка валидности входных параметров в контроллере же (как предполагается самим фреймворком) — явное смешивание полномочий.


В том виде, в котором будет нужен в данном конкретном случае

В самом общем случае урл выглядит как "...[var1:format]...[var2:format]...[var3:format]..." Зачем было искусственно это ограничивать — я так и не понял

> Явно не за полчаса + странный аргумент для «batteries included» фреймворка.

«batteries included» никогда не означало наличие редко нужного функционала, вопрос реализации которого — сотня строк кода.

> обработка валидности входных параметров в контроллере же (как предполагается самим фреймворком) — явное смешивание полномочий.

Это правильно, валидность надо проверять в роутере. В ангуляре специально для этого есть canActivate гварды. При этом проверять можно не только формат синтаксиса, а выполнение любых условий. Например, роут foo/:id при несуществующем в базе айдишнике столь же невалиден, сколь и роут с неправильным синтаксисом.

> В самом общем случае урл выглядит как "...[var1:format]...[var2:format]...[var3:format]..." Зачем было искусственно это ограничивать — я так и не понял

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