Новый fullstack JavaScript framework
 

Добрый день.
Наша команда решила сделать бек-проджект - fullstack JavaScript framework. Я очень хочу обсудить дизайн framework'a.
На данный момент доступна первая версия файла readme на русском языке. Код и перевод на английский буду выкладывать в процессе общения.

https://github.com/softlabe/core

И хде?

Поправил пост. https://github.com/softlabe/core - велкам

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

Правильной логике обработки исключений можно посвятить целую книгу, и есть разыне практики их применения. Например в JAVA распространен принцип - логика на эксепшенах. Но в .NET - нет, в первую очередь из-за проблем производительности. Но в любом случае - обрабатывать исключения надо.
Тут следует уточнить, что я не призываю писать код на обработке исключений - я за адекватную обработку исключений. То есть я против стиля проверки result-code, как в c++, или переменной error, как в Node.js. Я за использование try-catch :)

Основная цель моего фреймверка - компиляция синхронного кода в асинхронный. Я уверен, что писать/отлаживать/сопровождать синхронный код гораздо легче и дешевле, чем на калбеках и на deferred-объектах.Это и будет основной киллер-фичей фреймверка

На самом деле вы ошибаетесь, легче писать асинхронный код, но только в том случае, если вы привыкли иметь дело с javascript. Синхронный код проще в случае когда вы переходите на javascript с другого языка (C/C++/Java). В этом случае я с вами согласен.

Возможно - тут каждому своё. Но когда у вас хотя бы 4 асинхронных метода, а еще асинхронный вызов в цикле и пару условий - это увеличивает объем кода минимум 2,5-3,5 раза. Как следствие - ухудшение читаемости кода, увеличение глупой работы по набору кода, усложнение отладки и прочие проблемы сопровождения кода. А когда такая ситуация встречается постоянно, например при использовании Node.js, то возникают мысль - что что-то тут не так. ИМХО, это основная причина того, что JavaScript не получает такого широкого применения на сервере.

Откройте для себя Promise.
Основная причина отсутствия широкого применения javascript на сервере - отсутствие в JS статической типизации, что усложняет код и делает невозможным его статический анализ. Конечно TypeScript несколько исправляет дело, но это на JS

При использовании promise так же не рабатют привычные конструкции языка(try/catch, for, if), и тогда нужно использовать хелпер-методы, что так же плохо сказывается на читаемости кода. Собственно говоря, моя компиляция основана на использование промисов и использовании хелперов для организации потока выполнения.
Динамическая типизация не мешает на PHP создавать продукты. А увеличить надежность написанного кода лучше при помощи тестов, чем надеятся на статический анализ. ИМХО, единственный плюс статической типизации - лучшая способность к рефакторингу.

Успешное прохождение тестов гарантирует лишь то, что тесты успешно пройдены, в отличие от статической типизации, которая исключает целые классы ошибок. Так и на JS и на Питоне продукты создают, никто не говорит, что это невозможно. Речь о том, что статическая типизация уменьшает вероятность ошибок/опечаток :).

У меня срабатывали try/catch внутри promise.

Я полность с вами соглашусь, что тесты ничего не гарантируют. Но и компиляция, так же точно, не может гарантировать ничего, кроме того, что проект 'собрался'.
Я считаю, что любой код должен читаться как книга, даже ценой возможной неоптимальности решения. С логикой на промисах гораздо приятней работать чем с калбеками. Да, работать с try/catch и другими конструкциями языка можно внутри функции, возвращающей промис. Но этого нельзя делать снаружи этой функции. Это приводит к тому, что код, местами, напоминает код на чистом С, когда вы проверяете result-code после каждой операции. Это отрицательно сказывается на читаемости кода.

По поводу читаемости согласен на все 100%.
К сожалению просто фреймворками тут не помочь.
Основной недостаток таких фреймворков (которые по псевдокоду генерируют JS код) - отладка полученного кода. Либо вы предоставляете отладчик по своему псевдокоду, либо нужно лезть в JS. Во втором случае, рано или поздно (скорее рано) приходит осознание того, что проще написать свой код сразу на JS, чем отлаживать код генерированный кем то.

sourcemaps - должен помочь в отладке. Правда его поддерживают не все IDE, но это вопрос времени

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

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

проэкт заглух?