Комментарии 12
Спасибо, как раз хотел поразбираться с этим всем.
Не очень только понятно, зачем вы делаете свой EventPublisherBase, если есть прекрасный Backbone.Events?
Не очень только понятно, зачем вы делаете свой EventPublisherBase, если есть прекрасный Backbone.Events?
0
На самом деле бэкбон скорее всего будет использоваться, но строго как реализация. Примеси в стиле Js крайне плохо вписываются в классический ООП. Грубо говоря, мне надо объявить интерфейс, сделать фейковую его реализацию, а потом в рантайме примешивать реализацию. Это напрочь убивает все преимущества классического ООП и статической типизации в TS. На мой взгляд должна существовать некая обертка, позволяющая контролировать типы параметров событий и т.п. на уровне кода. Более развернуто постараюсь ответить на этот вопрос в продолжении статьи, как только хватит времени ее дописать.
0
Примеси в стиле Js крайне плохо вписываются в классический ООП.
напрочь убивает все преимущества классического ООП и статической типизации в TS
Ну вот вся суть как раз в том, что JS — не классический ООП. И как по мне, в погоне за статической типизацией и «преимуществами классического ООП» (а они точно здесь преимущества?) зачастую теряется экспрессия фич самого языка. Это другой язык — почему все вечно пытаются сделать из него «полноценное ООП»?
0
На мой взгляд, во-первых, js это полноценный ООП язык. У него свой уникальный подход, но наличия наследования, полиморфизма и инкапсуляции это не отменяет.
Во-вторых, почему я хочу классическое ООП? Ровно из-за одного — статического анализа кода. Я хочу видеть ошибки еще до запуска приложения. Это на порядки экономит время разработки. В моей практике .net разработчика бывали ситуации, когда код, который писался по несколько дней, запускался и работал с первого раза и без ошибок. Если нет ошибок в алгоритме, то остаются только описки, которые и должен ловить компилятор. Поэтому я сразу и влюбился в TS. Динамические языки хороши, пока вы не пишете приложения, в которых формы не имеют по несколько тысяч строк кода. По моей практике получается, что +-500 строк на JS это предел объема, когда код еще читабелен. На языках с классами и статической типизацией эта цифра где-то на порядок выше. Для меня это важно.
Во-вторых, почему я хочу классическое ООП? Ровно из-за одного — статического анализа кода. Я хочу видеть ошибки еще до запуска приложения. Это на порядки экономит время разработки. В моей практике .net разработчика бывали ситуации, когда код, который писался по несколько дней, запускался и работал с первого раза и без ошибок. Если нет ошибок в алгоритме, то остаются только описки, которые и должен ловить компилятор. Поэтому я сразу и влюбился в TS. Динамические языки хороши, пока вы не пишете приложения, в которых формы не имеют по несколько тысяч строк кода. По моей практике получается, что +-500 строк на JS это предел объема, когда код еще читабелен. На языках с классами и статической типизацией эта цифра где-то на порядок выше. Для меня это важно.
0
>>> в которых формы не имеют по несколько тысяч строк кода
Может быть дело в этом?
Может быть дело в этом?
0
В каком смысле? Для каждого сценария свой инструмент. В «ванильном» виде JS очень слабо применим для реальных приложений, в которых объем кода исчисляется десятками тысяч строк. Для элементарного UI на пару десятков полей напротив нет смысла изобретать велосипед.
0
Да не важно количество — важно качество. Не спорю с тем, что для каждой задачи свой инструмент, но говорить, что тот или иной язык слабо применим для той же задачи, которую он решает, но если задача в большем масштабе — слишком уж спорный аргумент. Архитектура — наше все. Правильно спроектированное приложение — залог успеха. Не компилятор помогает писать хороший софт.
0
Сам работал на 90% только с .NET 6 или 7 лет подряд, пока окончательно не перешел на альтернативные платформы, в частности, node.js. И чувствую себя прекрасно без статической типизации.
По сути, так и есть, но существуют особенности языка, которые можно использовать себе во благо. Или которые не получится использовать, если смотреть на язык, как на «классическое ООП».
И как это связано? JSHint/JSLint/Closure compiler, не?
Это прям реально, реально проблема архитектуры, но никак не динамических языков, и JS в частности.
во-первых, js это полноценный ООП язык
По сути, так и есть, но существуют особенности языка, которые можно использовать себе во благо. Или которые не получится использовать, если смотреть на язык, как на «классическое ООП».
Во-вторых, почему я хочу классическое ООП? Ровно из-за одного — статического анализа кода.
И как это связано? JSHint/JSLint/Closure compiler, не?
Динамические языки хороши, пока вы не пишете приложения, в которых формы не имеют по несколько тысяч строк кода.
Это прям реально, реально проблема архитектуры, но никак не динамических языков, и JS в частности.
0
Инструмент зависит от задачи. В конкретно моей, из которой выросла статья, типизация реально помогает. М/б вам просто везет, что у вас нет рефакторинга из-за регулярных изменений требований.
Безусловно, нюансы есть. Более того, я искренне люблю JS и не имею никаких предпочтений между ним и C#. Для каждой задачи свой инструмент. Поэтому вдвойне люблю TS, т.к. он их прекрасно сочетает.
Не холивора ради, но как любое из этих средств проверит соответствие типов? Если трезво подойти к проблеме статического анализа, то ни одна утилита не может проверить то, что не знает. Например, типы или обязательность параметров в функциях. Ну, или никогда не сможет проверить на 100%. Безусловно, все перечисленное вами ПО работает, но это только половина дела. вторую делает TS, вводя типы и т.д.
Проблема конкретно JS в том, что конкретно на нем большие листинги нечитаемы. Молчу про сплошные костыли с модульностью и т.п. Многое можно нивелировать архитектурой, стандартами кодирования и т.п., но в любом случае мы получим либо слабочитаемый листинг, либо тучу комментариев. Естественно, тут я немного преувеличиваю, но в реальном мире действительно хороший код на JS попадается исчезающе редко. Иначе — написать неудобочитаемый код на JS в разы легче чем на любом статически типизированном языке.
По сути, так и есть, но существуют особенности языка, которые можно использовать себе во благо. Или которые не получится использовать, если смотреть на язык, как на «классическое ООП».
Безусловно, нюансы есть. Более того, я искренне люблю JS и не имею никаких предпочтений между ним и C#. Для каждой задачи свой инструмент. Поэтому вдвойне люблю TS, т.к. он их прекрасно сочетает.
И как это связано? JSHint/JSLint/Closure compiler, не?
Не холивора ради, но как любое из этих средств проверит соответствие типов? Если трезво подойти к проблеме статического анализа, то ни одна утилита не может проверить то, что не знает. Например, типы или обязательность параметров в функциях. Ну, или никогда не сможет проверить на 100%. Безусловно, все перечисленное вами ПО работает, но это только половина дела. вторую делает TS, вводя типы и т.д.
Это прям реально, реально проблема архитектуры, но никак не динамических языков, и JS в частности.
Проблема конкретно JS в том, что конкретно на нем большие листинги нечитаемы. Молчу про сплошные костыли с модульностью и т.п. Многое можно нивелировать архитектурой, стандартами кодирования и т.п., но в любом случае мы получим либо слабочитаемый листинг, либо тучу комментариев. Естественно, тут я немного преувеличиваю, но в реальном мире действительно хороший код на JS попадается исчезающе редко. Иначе — написать неудобочитаемый код на JS в разы легче чем на любом статически типизированном языке.
0
Почему не стали использовать knockout?
0
Мне он не нравится. Честно. Больше никаких причин. Статья получилась как бы потоком мыслей. Я не ставил себе цели детальное сравнение фреймворков. Есть мысль в будущем заняться сравнением с точки зрения совместимости фреймворков с классическим ООП typescript. Бэкбон, честно говоря, далеко не идеально сочетается из-за тотального использования примесей.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Построение масштабируемых приложений на TypeScript. Часть 1 — Асинхронная загрузка модулей