Как я перестал любить Angular

Вступление


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


На дворе 2017ый год и для каждого нового продукта/проекта встает вопрос выбора фреймворка для разработки. Долгое время я был уверен, что новый Angular 2/4 (далее просто Angular) станет главным трендом enterprise разработки еще на несколько лет вперед и даже не сомневался что буду работать только с ним.


Сегодня я сам отказываюсь использовать его в своем следующем проекте.


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


AngularJS



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


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


Angular



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


Конечно путь к этому был долог и полон Breaking Changes, но на сегодняшний день Angular 4 стабилен и позиционируется как полностью production-ready.


Одна из наиболее крутых вещей, которую дал нам новый Angular — популяризация TypeScript.
Лично я был с ним знаком и работал еще до того, как он стал основным для моего любимого фреймворка, но многие узнали о нем именно благодаря Angular.


TypeScript



Не буду подробно останавливаться на TypeScript, т.к. это тема для отдельной статьи,
да и написано о нем уже больше чем нужно. Но для enterprise разработки TypeScript дает огромное количество преимуществ. Начиная с самой статической типизации и областями видимости и заканчивая поддержкой ES7/8 даже для IE9.


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


Vue



Если вы читаете данную статью, то с вероятностью 95% вы уже знаете что это такое.


Но для тех 5% кто еще не знает — Vue.js это крайне легковесный (но очень богатый по функционалу) фреймворк, вобравший в себя многое хорошее, как из AngularJS, так и из React.


Фактически больше он похож все же на React, но шаблоны практически идентичны AngularJS (HTML + Mustache).


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


Предыстория


Было — большой проект на AngularJS


Последний мой проект, который совсем недавно вышел в production, мы писали на AngularJS 1.5-1.6.


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


Вот пример нашего компонента из данного проекта:


import {Component} from "shared-front/app/decorators";
import FileService, {ContentType, IFile} from "../file.service";
import AlertService from "shared/alert.service";

@Component({
    template: require("./file.component.html"),
    bindings: {
        item: "<",
    },
})
export default class FileComponent {
    public static $inject = ["fileService"];
    public item: IFile;

    constructor(private fileService: FileService, private alertService: AlertService) {
    }

    public isVideo() {
        return this.item.contentKeyType === ContentType.VIDEO;
    }

    public downloadFile() {
        this.fileService.download(this.getFileDownloadUrl()).then(() => {
            this.alertService.success();
        });
    }

    private getFileDownloadUrl() {
        return `url-for-download${this.item.text}`;
    }
}

На мой взгляд выглядит очень даже приятно, не слишком многословно, даже если вы не фанат TS.
К тому же все это замечательно тестируется как Unit-тестами, так и Е2Е.


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


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


Стало — средний проект на Angular


Так мы и поступили, рационально выбрав Angular 2 (позже 4) для нашего нового проекта несколько месяцев назад.


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


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


А вот пример компонента из проекта на 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}`;
    }
}

Возможно чуть чуть более многословно, но гораздо чище.


Плюсы


Angular CLI — единственное реальное преимущество перед AngularJS



Первое, что вы установите при разработке нового Angular 4 приложения это Angular CLI


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


Это то, чего так сильно не хватало в AngularJS, и все решали проблему отсутствия данной тулзы по-своему. Множество различных сидов (стартеров), сотни разных подходов к одному и тому же, в общем анархия. Теперь с этим покончено.


Конечно CLI тоже имеет ряд недостатков в части настроек и конфигурации "под себя", но все же он на голову выше аналогичных утилит для React (create-react-app) или Vue (vue-cli). Хотя второй, благодаря своей гибкости, становится лучше с каждым днем.


Минусы или "За что я перестал любить Angular"


Изначально я не хотел писать очередную хейтерскую статью вроде Angular 2 is terrible (нашелся даже перевод).


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


В целом не совсем разделяю взгяд автора на RxJS, т.к. библиотека невероятно мощная.


An Ajax request is singular, and running methods like Observable.prototype.map when there will only ever be one value in the pipe makes no semantic sense. Promises on the other hand represent a value that has yet to be fulfilled, which is exactly what a HTTP request gives you. I spent hours forcing Observables to behave before giving up using Observable.prototype.toPromise to transform the Observable back to a Promise and simply using Promise.all, which works much better than anything Rx.js offers.

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


Но суровая правда в том, что Object.observe нативно мы все же не увидим:


After much discussion with the parties involved, I plan to withdraw the Object.observe proposal from TC39 (where it currently sits at stage 2 in the ES spec process), and hope to remove support from V8 by the end of the year (the feature is used on 0.0169% of Chrome pageviews, according to chromestatus.com).

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


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


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


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


TypeScript в Angular


Пожалуй самое болезненное разочарование для меня — это то, во что превратили работу с TypeScript'ом в Angular.


Ниже несколько примеров наиболее неудачных решений.


Ужасные API


Одной из основных проблем использования TypeScript в Angular я считаю крайне спорные API.
Сам по себе TypeScript идеально подходит для написания максимально строгого кода, без возможностей случайно сделать шаг не в ту сторону. Фактически он просто создан для того, чтобы писать публичный API, но команда Angular сделала все, чтобы данное преимущество превратилось в недостаток.


Примеры:


HttpParams

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


Например код вида:


let params = new HttpParams();
params.set('param', param);
params.set('anotherParam', anotherParam);
...
this.http.get('test', {params: params});

Не будет добавлять параметры к запросу. Казалось бы почему?
Ведь никаких ошибок, ни TypeScript ни сам Angular не отображает.


Только открыв сам класс в TypeScript можно найти комментарий


This class is immuatable — all mutation operations return a new instance.

Конечно, это совершенно неочевидно.


В вот и вся документация про них:


http
  .post('/api/items/add', body, {
    params: new HttpParams().set('id', '3'),
  })
  .subscribe();

RxJS operator import

Начнем с того, что документация по Angular вообще не имеет толкового разбора и описания Observable и того, как с ними работать.


Нет даже толковых ссылок на документацию по RxJS. И это при том, что Rx является ключевой частью фреймворка, а само создание Observable уже отличается:


// rx.js
Rx.Observable.create();
vs
// Angular
new Observable()

Ну да и черт с ним, здесь я хотел рассказать о Rx + TypeScript + Angular.


Допустим вы хотите использовать некий RxJS оператор, вроде do:


observable.do(event => {...})

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


Вот только, во время выполнения возникнет такая ошибка:


ERROR TypeError: observable.do is not a function

Потому что вы очевидно (потратили кучу времени на поиск проблемы) забыли заимпортировать сам оператор:


import 'rxjs/add/operator/do';

Почему это ломается в рантайме, если у нас есть TypeScript? Не знаю. Но это так.


Router API

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


Events

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


this.router.events.subscribe(event => {
  if(event instanceof NavigationStart) {
    ...
  }
}


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


this.router.navigate(['/some']);
...
this.router.navigate(['/other']);

Почему это плохо?


Потому что команды в данном случае имеют сигнатуру any[]. Для незнакомых с TypeScript — это фактически отключение его фич.


Это при том, что роутинг — наиболее слабо связанная часть в Angular.


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


Но нет, в Angular это преимущество TypeScript не используется никак.


Lazy Load

Этот раздел также мог бы пойти на отдельную статью, но скажу лишь, что в данном случае
игнорируются любые фичи TypeScript и название модуля пишется как строка, в конце через #


{
  path: 'admin',
  loadChildren: 'app/admin/admin.module#AdminModule',
},

Forms API

Для начала — в Angular есть два типа форм: обычные и реактивные.


Само собой, работать с ними нужно по-разному.


Однако лично меня раздражает именно API reactive forms:


// Зачем нужен первый пустой параметр?
// Почему name это массив c валидатором??
this.heroForm = this.fb.group({
  name: ['', Validators.required ],
});

или из документации


// Почему пустое поле это имя??
this.heroForm = this.fb.group({
  name: '', // <--- the FormControl called "name"
});

и так далее


this.complexForm = fb.group({   
  // Почему понадобился compose ?
  // Неужели нельзя без null ??
  'lastName': [null, Validators.compose([Validators.required, Validators.minLength(5), Validators.maxLength(10)])],
  'gender' : [null, Validators.required],
})

А еще — нельзя просто использовать атрибуты типа [disabled] с реактивными формами...


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


__metadata


К сожалению использование горячо любимого мною TypeScript'а в Angular слишком сильно завязано на декораторы.


Декораторы — прекрасная вещь, но к сожалению в рантайме нет самой нужной их части, а именно __metadata.


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


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


Впрочем, мы в нашем AngularJS приложении использовали такие декораторы, например @Component:


export const Component = (options: ng.IComponentOptions = {}) => controller => angular.extend(options, {controller});

Он фактически просто оборачивает наши TypeScript классы в компоненты AngularJS и делает их контроллерами.


Но в Angular, несмотря на экспериментальность фичи, это стало частью ядра фреймворка,
что делает необходимым использование полифила reflect-metadata в совершенно любом случае. Очень спорное решение.


Абстракции


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


Самый яркий пример подобных проблем — это Dependency Injection в Angular.


Сама по себе концепция замечательная, особенно для unit тестирования. Но практика показывает, что большой нужды делать из фронтенда нечто Java-подобное нет. Да, в нашем AngularJS приложении мы очень активно это использовали, но поработав с тестированием Vue компонентов, я серьезно начал сомневаться в пользе DI.


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


constructor(heroService: HeroService) {
  this.heroes = heroService.getHeroes();
}

Но так работает только для TypeScript классов, и если вы хотите добавить константу, необходимо будет использовать @Inject:


constructor(@Inject(APP_CONFIG) config: AppConfig) {
  this.title = config.title;
}

Ах да, сервисы которые вы будете инжектить должны быть проанотированы как @Injectable().


Но не все, а только те, у которых есть свои зависимости, если их нет — можно этот декоратор не указывать.


Consider adding @Injectable() to every service class, even those that don't have dependencies and, therefore, do not technically require it.
Here's why:

Future proofing: No need to remember @Injectable() when you add a dependency later.

Consistency: All services follow the same rules, and you don't have to wonder why a decorator is missing.

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


Еще прекрасная цитата из официальной документации по поводу скобочек:


Always write @Injectable(), not just @Injectable. The application will fail mysteriously if you forget the parentheses.

Короче говоря, создается впечатление, что TypeScript в Angular явно используется не по назначению.


Хотя еще раз подчеркну, что сам по себе язык обычно очень помогает в разработке.


Синтаксис шаблонов


Синтаксис шаблонов — основная претензия к Angular. И по вполне объективным причинам.


Пример не только множества разных директив, но еще и разных вариантов их использования:


<div [ngStyle]="{'color': color, 'font-size': size, 'font-weight': 'bold'}">
  style using ngStyle
</div>

<input [(ngModel)]="color" />

<button (click)="size = size + 1">+</button>

<div [class.required]="isReq">Hello Wordl!</div>  
<div [className]="'blue'">CSS class using property syntax, this text is blue</div>
<div [ngClass]="{'small-text': true, 'red': true}">object of classes</div>
<div [ngClass]="['bold-text', 'green']">array of classes</div>
<div [ngClass]="'italic-text blue'">string of classes</div>

Изначально разработчики позиционировали новый синтакисис шаблонов, как спасение от множества директив.


Обещали, что будет достаточно только [] и ().


Binding Example
Properties <input [value]="firstName">
Events <button (click)="buy($event)">
Two-way <input [(ng-model)]="userName">

К сожалению в реальности директив едва ли не больше чем в AngularJS.



И да, простое правило запоминания синтаксиса two-way binding про банан в коробке
из официальной документации:


Visualize a banana in a box to remember that the parentheses go inside the brackets.

Документация


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


Контрпример — доки Vue. Мало того, что написаны подробно и доходчиво, так еще и на 6 языках, в т.ч. русском.


View encapsulation


Angular позволяет использовать так называемый View encapsulation.


Суть сводится к эмуляции Shadow DOM или использовании нативной его поддержки.


Сам по себе Shadow DOM — прекрасная вещь и действительно потенциально позволяет использовать даже разные CSS фреймворки для разных копмонентов без проблем.
Однако нативная поддержка на сегодняшний день совершенно печальна.


По умолчанию включена эмуляция Shadow DOM.


Вот пример простого CSS для компонента:


.first {
  background-color: red;
}
.first .second {
  background-color: green;
}
.first .second .third {
  background-color: blue;
}

Angular преобразует это в:


.first[_ngcontent-c1] {
  background-color: red;
}
.first[_ngcontent-c1]   .second[_ngcontent-c1] {
  background-color: green;
}
.first[_ngcontent-c1]   .second[_ngcontent-c1]   .third[_ngcontent-c1] {
  background-color: blue;
}

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


Например Vue делает то же самое, но гораздо чище:


.first[data-v-50646cd8] {
  background-color: red;
}
.first .second[data-v-50646cd8] {
  background-color: green;
}
.first .second .third[data-v-50646cd8] {
  background-color: blue;
}

Не говоря уже о том, что в Vue это не дефолтное поведение и включается добавлением простого scoped к стилю.


Так же хотелось бы отметить, что Vue (vue-cli webpack) подобным же образом позволяет указывать SASS/SCSS, тогда как для Angular CLI нужны команды типа ng set defaults.styleExt scss. Не очень понятно зачем все это, если внутри такой же webpack.


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


В частности мы использовали один из наиболее популярных UI фреймворков — PrimeNG, а он иногда использует подобные селекторы:


body .ui-tree .ui-treenode .ui-treenode-content .ui-tree-toggler {
    font-size: 1.1em;
}

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


Что в итоге приводит к необходимости писать нечто подобное:


body :host >>> .ui-tree .ui-treenode .ui-treenode-content .ui-tree-toggler {
  font-size: 2em;
}

Иногда и вовсе приходилось вспомнить великий и ужасный !important.


Безусловно все это связано конкретно с PrimeNG и не является как таковой проблемой фреймворка, но это именно та проблема, которая скорее всего возникнет и у вас при реальной работе с Angular.


К слову о стабильности


В примере выше мы использовали >>> — как и /deep/ это алиас для так называемого shadow-piercing селектора.


Он позволяет как бы "игнорировать" Shadow DOM и для некоторых сторонних компонентов порой просто незаменим.


В одном из относительно свежих релизов Angular создатели фреймворка решили,
в соответствии со стандартом, задепрекейтить /deep/ и >>>.


Никаких ошибок или ворнингов их использование не принесло, они просто перестали работать.
Как выяснилось позже, теперь работает только ::ng-deep — аналог shadow-piercing селектора в Angular вселенной.


Обновление это было отнюдь не мажорной версии (4.2.6 -> 4.3.0), просто в один прекрасный момент наша верстка во многих местах поползла (спасибо и NPM за версии с шапочкой ^).


Конечно, не все наши разработчики ежедневно читают ChangeLog Angular 4, да и за трендами веб разработки не всегда можно уследить. Само собой сначала грешили на собственные стили — пришлось потратить немало времени и нервов для обнаружения столь неприятной особенности.


К тому же скоро и ::ng-deep перестанет работать. Как в таком случае править стили кривых сторонних компонентов, вроде тех же PrimeNG, ума не приложу.


Наш личный вывод: дефолтная настройка — эмуляция Shadow DOM порождает больше проблем чем решает.


Свой HTML парсер


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


Нет смысла холиварить на тему ухода Angular от стандартов, но по мнению многих это довольно странная идея, ведь в том же AngularJS обычного HTML (регистронезависимого) вполне хватало.


С AngularJS нередко бывало такое: добавили вы некий <my-component/> а тест не написали.
Прошло некоторое время и модуль который содержит логику данного компонента был удален/отрефакторен/итд.


Так или иначе — теперь ваш компонент не отображается.


Теперь он сразу определяет неизвестные теги и выдает ошибку если их не знает.


Правда теперь любой сторонний компонент требует либо полного отключения этой проверки,
либо включения CUSTOM_ELEMENTS_SCHEMA которая пропускает любые тэги с -


Сорцы можете оценить самостоятельно


...
const TAG_DEFINITIONS: {[key: string]: HtmlTagDefinition} = {
  'base': new HtmlTagDefinition({isVoid: true}),
  'meta': new HtmlTagDefinition({isVoid: true}),
  'area': new HtmlTagDefinition({isVoid: true}),
  'embed': new HtmlTagDefinition({isVoid: true}),
  'link': new HtmlTagDefinition({isVoid: true}),
  'img': new HtmlTagDefinition({isVoid: true}),
  'input': new HtmlTagDefinition({isVoid: true}),
  'param': new HtmlTagDefinition({isVoid: true}),
  'hr': new HtmlTagDefinition({isVoid: true}),
  'br': new HtmlTagDefinition({isVoid: true}),
  'source': new HtmlTagDefinition({isVoid: true}),
  'track': new HtmlTagDefinition({isVoid: true}),
  'wbr': new HtmlTagDefinition({isVoid: true}),
  'p': new HtmlTagDefinition({
    closedByChildren: [
      'address', 'article', 'aside', 'blockquote', 'div', 'dl',      'fieldset', 'footer', 'form',
      'h1',      'h2',      'h3',    'h4',         'h5',  'h6',      'header',   'hgroup', 'hr',
      'main',    'nav',     'ol',    'p',          'pre', 'section', 'table',    'ul'
    ],
    closedByParent: true
  }),
...
  'td': new HtmlTagDefinition({closedByChildren: ['td', 'th'], closedByParent: true}),
  'th': new HtmlTagDefinition({closedByChildren: ['td', 'th'], closedByParent: true}),
  'col': new HtmlTagDefinition({requiredParents: ['colgroup'], isVoid: true}),
  'svg': new HtmlTagDefinition({implicitNamespacePrefix: 'svg'}),
  'math': new HtmlTagDefinition({implicitNamespacePrefix: 'math'}),
  'li': new HtmlTagDefinition({closedByChildren: ['li'], closedByParent: true}),
  'dt': new HtmlTagDefinition({closedByChildren: ['dt', 'dd']}),
  'dd': new HtmlTagDefinition({closedByChildren: ['dt', 'dd'], closedByParent: true}),
  'rb': new HtmlTagDefinition({closedByChildren: ['rb', 'rt', 'rtc'
  ...

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


Однако это решается прекомпиляцией шаблонов благодаря другому, AOT компилятору.
Нужно всего лишь собирать с флагом --aot, но и здесь не без ложки дегтя, это плохо работает с ng serve и еще больше тормозит и без того небыструю сборку. Видимо поэтому он и не включен по умолчанию (а стоило бы).


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


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


Обратите внимание на элегантные предлагаемые решения проблемы:


don't use default exports :)

Just place both export types and it works

Или нечто подобное описанному здесь (AOT не всегда разбирает замыкания)


Код подобного вида вызывает очень странные ошибки компилятора AOT:


@NgModule({
  providers: [
    {provide: SomeSymbol, useFactor: (i) => i.get('someSymbol'), deps: ['$injector']}
  ]
})
export class MyModule {}

Приходится подстраиваться под компилятор и переписывать код в более примитивном виде:


export factoryForSomeSymbol = (i) => i.get('someSymbol');

@NgModule({
  providers: [
    {provide: SomeSymbol, useFactor: factoryForSomeSymbol, deps: ['$injector']}
  ]
})
export class MyModule {}

Также хотелось бы отметить, что текст ошибок в шаблонах зачастую совершенно неинформативен.


Zone.js


Одна из концептуально очень крутых вещей которые появились в Angular это Zone.js.
Он позволяет отслеживать контекст выполнения для асинхронных задач, но новичков отпугивают огромной длины стактрейсы. Например:


core.es5.js:1020 ERROR Error: Uncaught (in promise): Error: No clusteredNodeId supplied to updateClusteredNode.
Error: No clusteredNodeId supplied to updateClusteredNode.
    at ClusterEngine.updateClusteredNode (vis.js:47364)
    at VisGraphDataService.webpackJsonp.../../../../../src/app/services/vis-graph-data.service.ts.VisGraphDataService.updateNetwork (vis-graph-data.service.ts:84)
    at vis-graph-display.service.ts:63
    at ZoneDelegate.webpackJsonp.../../../../zone.js/dist/zone.js.ZoneDelegate.invoke (zone.js:391)
    at Object.onInvoke (core.es5.js:3890)
    at ZoneDelegate.webpackJsonp.../../../../zone.js/dist/zone.js.ZoneDelegate.invoke (zone.js:390)
    at Zone.webpackJsonp.../../../../zone.js/dist/zone.js.Zone.run (zone.js:141)
    at zone.js:818
    at ZoneDelegate.webpackJsonp.../../../../zone.js/dist/zone.js.ZoneDelegate.invokeTask (zone.js:424)
    at Object.onInvokeTask (core.es5.js:3881)
    at ClusterEngine.updateClusteredNode (vis.js:47364)
    at VisGraphDataService.webpackJsonp.../../../../../src/app/services/vis-graph-data.service.ts.VisGraphDataService.updateNetwork (vis-graph-data.service.ts:84)
    at vis-graph-display.service.ts:63
    at ZoneDelegate.webpackJsonp.../../../../zone.js/dist/zone.js.ZoneDelegate.invoke (zone.js:391)
    at Object.onInvoke (core.es5.js:3890)
    at ZoneDelegate.webpackJsonp.../../../../zone.js/dist/zone.js.ZoneDelegate.invoke (zone.js:390)
    at Zone.webpackJsonp.../../../../zone.js/dist/zone.js.Zone.run (zone.js:141)
    at zone.js:818
    at ZoneDelegate.webpackJsonp.../../../../zone.js/dist/zone.js.ZoneDelegate.invokeTask (zone.js:424)
    at Object.onInvokeTask (core.es5.js:3881)
    at resolvePromise (zone.js:770)
    at zone.js:696
    at zone.js:712
    at ZoneDelegate.webpackJsonp.../../../../zone.js/dist/zone.js.ZoneDelegate.invoke (zone.js:391)
    at Object.onInvoke (core.es5.js:3890)
    at ZoneDelegate.webpackJsonp.../../../../zone.js/dist/zone.js.ZoneDelegate.invoke (zone.js:390)
    at Zone.webpackJsonp.../../../../zone.js/dist/zone.js.Zone.run (zone.js:141)
    at zone.js:818
    at ZoneDelegate.webpackJsonp.../../../../zone.js/dist/zone.js.ZoneDelegate.invokeTask (zone.js:424)
    at Object.onInvokeTask (core.es5.js:3881)

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


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


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


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



UI frameworks


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


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


Вот список основных UI фреймворков для Angular: https://angular.io/resources (раздел UI components).


Рассмотрим наиболее популярные бесплатные варианты.


Angular Material 2



Безусловно, наибольшие надежды я возлагал на Angular Material 2 ввиду того, что разрабатывается он командой Angular и наверняка будет соответствовать всем гайдлайнам.


К сожалению, несмотря на его возраст, набор компонентов крайне мал.


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


Я считаю, что Angular Material 2 подойдет лишь небольшим или, в лучшем случае, средним проектам, т.к. до сих пор нет, например, деревьев. Часто очень нужны компоненты вроде multiple-select, коих тоже нет.


Отдельно стоит сказать про очень скупую документацию и малое количество примеров.


Перспективы развития тоже довольно печальные.


Feature Status
tree In-progress
stepper In-progress, planned Q3 2017
sticky-header In-progress, planned Q3 2017
virtual-repeat Not started, planned Q4 2017
fab speed-dial Not started, not planned
fab toolbar Not started, not planned
bottom-sheet Not started, not planned
bottom-nav Not started, not planned

Bootstrap



По тем же причинам, что и выше не буду останавливаться на Bootstrap фреймворках типа
ng2-bootstrap (получше) и ngx-bootstrap. Они очень даже неплохи, но простейшие вещи можно сделать и обычным CSS, а сложных компонентов тут нет (хотя наверняка многим будет достаточно modal, datepicker и typeahead).


Prime Faces



Это на сегодняшний день наиболее популярый фреймворк содержащий множество сложных компонентов. В том числе гриды и деревья (и даже Tree Table!).


Изначально я вообще довольно скептически относился к PrimeFaces т.к. у меня был давний опыт работы с JSF, и много неприятных воспоминаний. Да и выглядят PrimeNG визуально так же (не очень современно). Но на момент начала нашего проекта достойных альтернатив не было, и все же хочется сказать спасибо разработчикам за то, что в короткие сроки был написан дейтсивтельно широчайший инструментарий.


Однако проблем с этим набором компонентов у нас возникало очень много.


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


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


Clarity



Луч света в темном царстве — это относительно молодая (меньше года от роду) библиотека Clarity от vmware.


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


Фреймворк не просто предоставляет набор UI компонентов, но и CSS гайдлайны.
Эдакий свой bootstrap. Благодаря этому достигается консистентный и крайне приятный/минималистичный вид компонентов.


Гриды очень функциональные и стабильные, а сорцы говорят сами за себя (о боже, комментарии и юнит тесты, а так можно было?).


Однако пока что очень слабые формы, нет datepicker'а и select2-подобного компонента.
Работа над ними идет в данный момент: DatePicker, Select 2.0 (как всегда дизайн на высоте, и хотя с разработкой не торопятся я могу быть уверен, что делают на совесть).


Пожалуй, "Clarity Design System" — единственная причина почему я еще верю в жизнь Angular
(и вообще единственный фреймворк который не стыдно использовать для enterprise разработки). Как никак VMware серьезнейший мейнтейнер и есть надежда на светлое будущее.


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


Но он лишь один


Да, я считаю что для Angular на сегодняшний день есть лишь один достойный UI фреймворк.
О чем это говорит?


Полноценно разрабатывать такие фреймворки для Angular могут лишь серьезнейшие компании вроде той же VMware. Нужен ли вам такой суровый enterprise? Каждый решает сам.


А теперь давайте посмотрим, что происходит с одним из свежих конкурентов.


Vue UI frameworks



Для сравнения мощные уже существующие фреймворки для Vue.js с теми же гридами:


Element (~15k stars), Vue Material (существенно младше Angular Material 2 но уже содержит в разы больше), Vuetify (снова Material и снова множество компонентов), Quasar, также надо отметить популярные чисто китайские фреймворки типа iView и Muse-UI (iView выглядит очень приятно, но документация хромает).


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


Какой вывод мы сделали?


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


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


Достаточно просто развернуть базовый webpack шаблон для vue-cli и оценить скорость работы библиотеки. Несмотря на то, что лично я всегда был сторонником фреймворков all-in-one,
Vue без особых проблем делает почти все то же, что и Angular.


Ну и конечно, множество тех же UI framework'ов также играет свою роль.


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


Но ребята из Microsoft уже вот вот вмержает ее. А потом она появится и в webpack шаблоне.


Почему мы не выбрали React? После AngularJS наша команда гораздо проще вошла в Vue,
ведь все эти v-if, v-model и v-for уже были очень знакомы.


Лично мне во многом, но не во всем, нравится Aurelia но уж больно она малопопулярна,
а в сравнении с взрывным ростом популярности Vue она кажется совсем неизвестной.


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


И поверьте, спустя 4 года работы с Angular, вот так бросить его было очень нелегко.
Но достаточно один раз попробовать Vue...


английская версия поста: https://medium.com/@igogrek/how-i-stopped-loving-angular-c2935f7378c4

Поделиться публикацией

Комментарии 519

    0
    Пробуем Aurelia в одном проекте. Проблема с плагинами, точнее плохой поддержкой typescript определений для плагинов. Документация самой аурелии не все описывает, сейчас уже не вспомню, но проходилось гуглить.
      0
      Вроде и статья более-менее объективная, и разложено хорошо, но блин, сложно серьезно воспринимать человека, который $inject руками прописывает.
        +3

        А что с этим не так? Видимо strictDI включен.

            +3
            Adds Angular 1.x DI annotations to ES5/ES6

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

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

            я тут с пол года назад думал про эти 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. Так что, возможно, невозможность использовать экспорты по умолчанию — это плюс ангулара :)

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

                Для TS в VSCode есть плагин для автоимпорта, вполне себе

                  0

                  Есть и встроенный в TS Server auto-import

                0
                default export по хорошему вообще нужно забанить в jslint/tslint.
                  0

                  Аргументируйте

                    0

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

                      +1

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


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


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


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

                        0

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

                          0

                          Не совсем понял вас, объясните, пожалуйста

                            +1

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


                            export default {
                              foo: 'bar'
                            }

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


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

                              0
                              const foo = 1
                              export default foo

                              Но так еще хуже =)

                  +2

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

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

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


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


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

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

                      К слову — Идера (текущий владелец Delphi), купила Sencha, изготовителя ExtJS, либо будут свою обвязку её делать, либо купять UniGUI. Радует движение в сторону веба.
                        +5

                        Вы забыли упомянуть, что UniGUI стоит от 400 до 900 долларов, в то время как все UI-библиотеки из статьи — опенсорсные и бесплатные

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

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


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

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


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

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

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

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

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


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


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


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

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

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

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

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

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

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


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


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

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

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


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

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


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

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


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

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


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

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


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

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


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

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


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


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


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


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

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

                                        При чем тут IE?


                                        Mixins умеют? Нет.

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


                                        Overrides умеют? Нет.

                                        Все умеют


                                        Hooks умеют? Нет.

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


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

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


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

                                        Все умеют

                                          –2
                                          При чем тут 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

                                            +1

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

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

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


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

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


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

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

                                          +1

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


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


                                          function fooMixin(base) {
                                              return class Foo extends base {
                                                  // ...
                                              }
                                          }
                                          
                                          class Baz extends fooMixin(Bar) {
                                              // ...
                                          }
                                            –1
                                            Какое отношение 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 вклиниваться до/после метода в основном классе, и для этого не нужно бодаться с контекстом и замыканиями. Или про то, как можно вклиниться в процесс создания класса и декорировать его по необходимости. Или про то, как родительский класс может делать всякие хитрые штуки с наследником. Или ещё что-нибудь интересное, там много.


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

                                              +4

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


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


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

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


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


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

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


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

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


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

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


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

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

                                                  Сравните:


                                                  /**
                                                   * @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 раз меньше кода для того же объёма функционала.

                                                    –1
                                                    Сравните:

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


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

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


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

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

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

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


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

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

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

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


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

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

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

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

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

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


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

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


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

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

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

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

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

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

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

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


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

                                                                    Цитирую:


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

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


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


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

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

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

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

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

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


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

                                                          0
                                                          @returns {function(string): boolean}


                                                          JSDoc довольно выразителен, зря вы на него так. Flow более вменяем, конечно, но для него нет ни одного инструмента для генерации документации.
                                                            0
                                                              0
                                                              По вашей же ссылке в самом начале:
                                                              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, и доступна в дев-среде всем желающим).
                                                  0
                                                  Простое: они в IE не работают и никогда не будут

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


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


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


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

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

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

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


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

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


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

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


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


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

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


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

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


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

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


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

                                                      0

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


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

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

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


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

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


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

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

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

                                                            –1

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

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

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

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


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


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


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

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

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

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

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


                                                              • Несовместимое с другими версиями поведение обработчиков 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
                                                              • Периодически ломающиеся обработчики различных событий в нём же
                                                              • И так далее, и тому подобное, список в пять локтей длиной

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

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

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


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


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

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

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

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

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

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

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


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

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


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


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

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


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

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

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

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

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

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


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

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


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


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

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

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

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


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

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

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

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


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

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

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


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

                                                                            0

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


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

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

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

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

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


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


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

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


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

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

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

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

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

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

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

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

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


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

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


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


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

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


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

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

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

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

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

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

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

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

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

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

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

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


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

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


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


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

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


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

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


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


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

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

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

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

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

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

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

                                                              0

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


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

                                                                –1

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


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


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


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

                                                                  +1

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


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

                                                                    –1
                                                                    Как-то вы так лихо перескочили с фразы "большинство проблем решаются с помощью 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-то тоже поддерживать надо, но как это сделать, чтобы не сломать весь мир — это как раз и есть вопрос на миллион.

                                                                    +1

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

                                                                      –1

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


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

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

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

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

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

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

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

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

                                                                0

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

                                                                  –1

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


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


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

                                                                    0

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

                                                                      –2

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


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

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

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

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

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


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


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


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


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

                                                                          +1
                                                                          А моя уверенность строится на многолетнем опыте разработки той самой 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.

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

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

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


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

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


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

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


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

                                                                              –1

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

                                                                                –4

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


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

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

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

                                                                        0
                                                                        Ок, буду иметь в виду, мало ли :)
                                                                +4

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


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


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

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

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


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

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


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

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


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

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

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


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

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


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

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

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

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


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


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

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


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

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


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

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

                                                                        0
                                                                        Я не 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, что сразу ставит на нем жирный минус.

                                                                          0
                                                                          Так или иначе, но возможность переопределить метод у 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" и вся ваша инфраструктура в одночасье превратится в хламчинскую тыкву, вы тут же бросите всё и ломанётесь переделывать ради бытия в тренде? А что? Все побежали и я побежал! ©

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

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


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

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


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

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


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

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

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

                                                                              Из репозитория 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 будет более-менее совместим с текущей экосистемой.

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

                                                                                0

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

                                                                                  0

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


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

                                                                                    +1

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


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


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

                                                                                      –2
                                                                                      Конечно смысла не было. Надо на 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 хвастались, что бывает и больше.

                                                                                        0

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


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

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

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


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


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

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

                                                                                            –2
                                                                                            Меньше слушайте школоту, вы делаете отличные вещи!!!
                                                                                              0
                                                                                              Исходники всех примеров идут вместе с фреймворком, так же как исходники юнит тестов, Jasmine с обвязкой, и т.д

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


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

                                                                                                –2
                                                                                                Можно сколько угодно пинать 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, то вы сами к нам придёте, а для других задач есть другие инструменты.

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

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


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

                                                                        0
                                                                        Вопрос: после покупки Сенчи что-то изменилось? Может слышали про какие-то планы Идеры?
                                                                          0

                                                                          Извините, публично комментировать не могу.

                                                                            0
                                                                            Ок, не вопрос.
                                                                          +1
                                                                          Ну вот видите. И вы способны вести спокойную, аргументированную беседу без хамства.

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

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

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

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

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

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

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

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

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

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


                                                                            На самом деле, если так заострять внимание на классах 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 поддержку вы меня опять улыбаете. Знаете, почему у нас её нет? Потому что качество патчей откровенно дерьмовое, а время на просмотр и оценку тратить нужно гигантское.

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

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

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


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


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


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

                                                                                  0

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


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


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

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

                                                                                    Использованием. Сравним с до-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, и вам станет грустно. Мне грустно.

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

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

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

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

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

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


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

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


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

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


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

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


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

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


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

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


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

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

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


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

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


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

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


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

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

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

                                                                                          Смотря какую реализацию брать за классическую. 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()

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

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

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


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

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


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

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


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

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

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

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


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

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


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


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

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


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

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


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

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