Pull to refresh

Comments 12

Спасибо, как раз хотел поразбираться с этим всем.

Не очень только понятно, зачем вы делаете свой EventPublisherBase, если есть прекрасный Backbone.Events?
На самом деле бэкбон скорее всего будет использоваться, но строго как реализация. Примеси в стиле Js крайне плохо вписываются в классический ООП. Грубо говоря, мне надо объявить интерфейс, сделать фейковую его реализацию, а потом в рантайме примешивать реализацию. Это напрочь убивает все преимущества классического ООП и статической типизации в TS. На мой взгляд должна существовать некая обертка, позволяющая контролировать типы параметров событий и т.п. на уровне кода. Более развернуто постараюсь ответить на этот вопрос в продолжении статьи, как только хватит времени ее дописать.
Примеси в стиле Js крайне плохо вписываются в классический ООП.
напрочь убивает все преимущества классического ООП и статической типизации в TS


Ну вот вся суть как раз в том, что JS — не классический ООП. И как по мне, в погоне за статической типизацией и «преимуществами классического ООП» (а они точно здесь преимущества?) зачастую теряется экспрессия фич самого языка. Это другой язык — почему все вечно пытаются сделать из него «полноценное ООП»?
На мой взгляд, во-первых, js это полноценный ООП язык. У него свой уникальный подход, но наличия наследования, полиморфизма и инкапсуляции это не отменяет.

Во-вторых, почему я хочу классическое ООП? Ровно из-за одного — статического анализа кода. Я хочу видеть ошибки еще до запуска приложения. Это на порядки экономит время разработки. В моей практике .net разработчика бывали ситуации, когда код, который писался по несколько дней, запускался и работал с первого раза и без ошибок. Если нет ошибок в алгоритме, то остаются только описки, которые и должен ловить компилятор. Поэтому я сразу и влюбился в TS. Динамические языки хороши, пока вы не пишете приложения, в которых формы не имеют по несколько тысяч строк кода. По моей практике получается, что +-500 строк на JS это предел объема, когда код еще читабелен. На языках с классами и статической типизацией эта цифра где-то на порядок выше. Для меня это важно.
>>> в которых формы не имеют по несколько тысяч строк кода

Может быть дело в этом?
В каком смысле? Для каждого сценария свой инструмент. В «ванильном» виде JS очень слабо применим для реальных приложений, в которых объем кода исчисляется десятками тысяч строк. Для элементарного UI на пару десятков полей напротив нет смысла изобретать велосипед.

Да не важно количество — важно качество. Не спорю с тем, что для каждой задачи свой инструмент, но говорить, что тот или иной язык слабо применим для той же задачи, которую он решает, но если задача в большем масштабе — слишком уж спорный аргумент. Архитектура — наше все. Правильно спроектированное приложение — залог успеха. Не компилятор помогает писать хороший софт.
Вы никоим образом не опровергаете того, что JS не был спроектирован для написания больших приложений и ошибки его проектирования мы сейчас вынуждены решать, подставляя различные костыли :)
Сам работал на 90% только с .NET 6 или 7 лет подряд, пока окончательно не перешел на альтернативные платформы, в частности, node.js. И чувствую себя прекрасно без статической типизации.

во-первых, js это полноценный ООП язык

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

Во-вторых, почему я хочу классическое ООП? Ровно из-за одного — статического анализа кода.

И как это связано? JSHint/JSLint/Closure compiler, не?

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

Это прям реально, реально проблема архитектуры, но никак не динамических языков, и JS в частности.
Инструмент зависит от задачи. В конкретно моей, из которой выросла статья, типизация реально помогает. М/б вам просто везет, что у вас нет рефакторинга из-за регулярных изменений требований.

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


Безусловно, нюансы есть. Более того, я искренне люблю JS и не имею никаких предпочтений между ним и C#. Для каждой задачи свой инструмент. Поэтому вдвойне люблю TS, т.к. он их прекрасно сочетает.

И как это связано? JSHint/JSLint/Closure compiler, не?


Не холивора ради, но как любое из этих средств проверит соответствие типов? Если трезво подойти к проблеме статического анализа, то ни одна утилита не может проверить то, что не знает. Например, типы или обязательность параметров в функциях. Ну, или никогда не сможет проверить на 100%. Безусловно, все перечисленное вами ПО работает, но это только половина дела. вторую делает TS, вводя типы и т.д.

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


Проблема конкретно JS в том, что конкретно на нем большие листинги нечитаемы. Молчу про сплошные костыли с модульностью и т.п. Многое можно нивелировать архитектурой, стандартами кодирования и т.п., но в любом случае мы получим либо слабочитаемый листинг, либо тучу комментариев. Естественно, тут я немного преувеличиваю, но в реальном мире действительно хороший код на JS попадается исчезающе редко. Иначе — написать неудобочитаемый код на JS в разы легче чем на любом статически типизированном языке.
Почему не стали использовать knockout?
Мне он не нравится. Честно. Больше никаких причин. Статья получилась как бы потоком мыслей. Я не ставил себе цели детальное сравнение фреймворков. Есть мысль в будущем заняться сравнением с точки зрения совместимости фреймворков с классическим ООП typescript. Бэкбон, честно говоря, далеко не идеально сочетается из-за тотального использования примесей.
Only those users with full accounts are able to leave comments. Log in, please.