интересно как автор решает следуюшие проблемы:
— модульность, так как при таком подходе наши классы ограничены лексическим контекстом и одним файлом. Как обстоит дело с миксинами к таким классам?
— производительность, так как мы не используем мощь прототипов для создания классов. Что будет если понадобится создать очень много экземпляров?
Если есть ошибка — пользователь будет недоволен в любом случае. И, как я понимаю, обращение пользователя с вопросом про данные помогло вам найти и устранить ошибку не хуже, тем если бы ему выводилось что-то вроде «General failure».
Если есть время — конечно лучше создать отдельные сообщения для ошибок, я с этим не спорю, и в JavaScript это нисколько не сложнее. Скажем в C++ вы будете использовать try catch, а в JavaScript проверете все выводимые значения на NaN и Infinity при рендеринге.
Да, это популярное мнение. Не хочу вступать в холивар, просто небольшой контраргумент: то что вы написали хорошо в релизе для разработчиков и тестировшиков, в продакшн-коде часто лучше всё-таки умолчать об ошибке. Пусть вы её быстро увидите, а так же её увидит приличная доля ваших пользователей, это ударит по репутации сервиса и менеджменту будет не важно какими благими намерениями вы руководствовались. При графике релизов раз в неделю или две, что сейчас всё более популярно, сложно гарантировать абсолютно стабильный код. Однако лучше если в службу поддержки придёт 2 обращения, чем 200. В любом случае ошибка будет исправлена, если нет — значит она не так критична. Этот подход хорошо подходит к разработке интерфейсов, если вы работаете с финансами или сложной математикой — возможно ваш подход более оправдан, хотя в JavaScript для таких случаев тоже можно вставить дополнительные проверки.
В том проекте логика тоже была на сервере и писалась на Java, но пользовательский интерфейс был довольно сложным, поэтому на клиенте тоже было чем заняться.
Для тестирования JavaScript могу посоветовать jsTestDriver, Selenium, Mocha или Jasmine, в зависимости от задач. Первый, например, имеет хорошую интеграцию с WebStorm и браузерами, позволяет запусткать юнит-тесты для компонентов интерфейса в один клик. Selenium позволяет писать поведенческие тесты практически любой сложности.
— модульность, так как при таком подходе наши классы ограничены лексическим контекстом и одним файлом. Как обстоит дело с миксинами к таким классам?
— производительность, так как мы не используем мощь прототипов для создания классов. Что будет если понадобится создать очень много экземпляров?
Для тестирования JavaScript могу посоветовать jsTestDriver, Selenium, Mocha или Jasmine, в зависимости от задач. Первый, например, имеет хорошую интеграцию с WebStorm и браузерами, позволяет запусткать юнит-тесты для компонентов интерфейса в один клик. Selenium позволяет писать поведенческие тесты практически любой сложности.