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