DSL это достаточно широкое понятие, чтобы его распространить и на JXS, но пользы в этом немного. Как бы там ни было, JSX — не шаблон.

Разница тут в том, что, не смотря на расширение синтаксиса, JSX семантически равнозначен JavaScript. Он имеет достаточно простую рекурсивную структуру (элемент: имя, атрибуты и вложенные элементы), которая консистентно и однозначно соответствует выражениям JavaScript. Результат JSX-выражения идентичен результату JavaScript-выражения. Это значит, что на JSX распространяются все правила языка-хоста: JSX-выражение можно вычислить заранее, можно сохранить, можно передать как параметр или вернуть из функции, можно заменить равносильным JavaScript-выраженим как полностью, так и частично.
Конечно, поддержку расширения синтаксиса нужно ещё добавить в инструменты, но это совсем не то же самое, что добавить поддержку языка со своей собственной семантикой — они вообще скорее всего будут несовместимы.

Семантику шаблона, раз он компилируется в JavaScript, можно свести к семантике JavaScript. Однако это не то же самое что иметь равносильную семантику. Приведение семантики не является явным, что не позволяет судить о шаблоне в терминах языка-хоста. На шаблон не распространяются языковые средства JavaScript. Можно спорить о нужности этих средств, но факта оно не меняет.

Вопрос нужности/достаточности статической типизации в JavaScript неоднозначен, однако отрицать её преимущества смысла нет. В конце концов это хотя бы просто инлайн-документация, которая проверяется компилятором, и которую понимают IDE.

Также у статической типизации есть побочный эффект. Статически типизируемый интерфейс — это явный интерфейс, с явным контрактом.

Ещё важным фактором эффективности статической типизации в JS является дружественность к ней интерфейсов библиотек. Если новые фреймворки будут занимать такую позицию, что поддерживать статическую типизацию ненужно, потому что она неэффективна, то это ведёт к замкнутому кругу.

Кстати говоря, "проблема опечаток" это в своей сути всё та же проблема явных, верифицируемых интерфейсов.

Насчёт того, что Svelte сам по себе статический анализатор. От статического анализатора требуется покрытие значимых сценариев использования и совместимость с экосистемой. Скажем, TypeScript может это обеспечить, насколько это возможно. От Svelte для этого потребуется по крайней мере сопоставимое количество работы, если допустить что это практически реализуемо. Svelte может ограничиться верификацией специфических для себя частей на манер PropTypes, но это только небольшая часть, и остаётся ещё проблема анализа внешнего к фреймворку кода.

Суть callback hell в двух вещах:

1. Они не компонуются. Если для последовательного выполнения можно обойтись пирамидой из замыканий, то для параллельного — ещё хуже если смеси параллельного и последовательного — уже не обойтись без вспомогательных средств.

   
   
2. Осложнена обработка ошибок. try/catch не работают, приходится полагаться на конвенцию по передаче ошибки в аргументах функции. Здесь очень просто что-то может пойти не так, в особенности в сочетании с первым пунктом.

Решением были промисы. Они компонуются с помощью методов и инкапсулируют обработку ошибок, даже try/catch опять работают.

Да, async/await это просто синтаксический сахар поверх Promise, но он позволяет значительно проще работать с последовательным выполнением с циклами и ветвленями, когда количество или последовательность асинхронных операций не заданы статически.

for-await-of ещё интереснее, потому что это новый протокол итерирования. Вот есть в JS синхронный протокол. Это удобно, потому что всё что итерируется, можно использовать в for или вот так [...iter]. Но тут проблема в том, что информация о конце итерирования должна передаваться синхронно. Поэтому нужен новый протокол.

Для простого итерирования по промисам он не обязателен. А вот работа со стримами или генераторами раскрывает его потенциал. Гораздо проще (и надёжнее) пройти по потоку циклом, чем ловить события data, error и end отдельно. Кстати, обработка ошибок в стриме в статье даже не затронута — опять таки, легко ошибиться, если делать вручную, а в случае со стандартными асинхронными конструкциями ошибка не потеряется, а всплывёт к месту вызова.

Так что ад реален, и о спасении души подумать следует :D

Я имел ввиду просто action creator и reducer. Это неуниверсальное решение. Чтобы как можно проще.
Предполагается, что если в конкретном случае логика другая (компановка нескольких запросов или ещё что-то), то тут уже можно подумать об отдельном экшене.

Кстати, в vuex существует разделение на mutations и actions. Первые всегда синхронны и меняют стейт. Вторые могут быть асинхронны, содержат логику приложения и вызывают первые. Вроде как попытка чётче отделить "логику данных" от "логики поведения".

Можно делать на всю группу однотипных операций один набор экшенов, а то что у вас в from и to перенести в пэйлоад.
Вместо промиса передавать url и парметры запроса. Вместо пути для каждого типа экшена — имя/идентификатор ресурса, из которого уже всё выводить по однородной схеме.
Кода будет меньше, и он будет обычным кодом уровня приложения, без дополнительной ответственности, налагаемой на библиотеку. Также должно стать меньше повторения на стороне использования по сравнению с таким хелпером.

Вообще, мне не очень нравится идея генерируемых идентификаторов экшенов. На мой взгляд они — интерфейс стора, "методы", точки жесткости приложения.
За экшеном стоит логика, и если она общая, то и реализовать её можно обобщённо, и пусть управляется данными.

Почему?
Я так понимаю, вы говорите об этом как антипаттерне в общем.
Promise — стандартное значение с чётко определённой семантикой. Его можно принимать и возвращать. Ничем не хуже коллбэка, скорее даже лучше.

Конечно, есть случаи, когда смешение промисов с обычными значениями может вести к нежелаемым последствиям. В первую очередь когда синхронное и асинхронное выполнение дают разные побочные эффекты (это не специфично для промисов).

Вообще тут обнаружил еще крутую штуку — так сказать, кривой, как раз в стиле JS, метод переопределения операторов.

Но ведь это не перегрузка операторов, это неявное приведение типов. Что здесь "кривого"?

Особенно мне в нем нравится аргумент hint.

Если это ирония, то я её не понял. Вы ведь знаете что такое динамическая типизация?

И вовсе Node.js не означает noSQL.

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

В вопросе ценообразования, конечно, вам виднее.
Хотя, если проблема в том, что WebStorm с этим плагином будет уметь всё то же, что и DataGrip, а стоит он меньше, так сделайте DataGrip дешевле для избежания конфликтов :) Этот плагин ведь есть в, скажем, PHPStorm, а стоит он столько же, сколько и DataGrip.

Единственное различие между const и let в том, что const обещает — переприсвоения не произойдёт.

С учётом вышеизложенного, const делает код более читаемым.
То есть назначение const в том, чтобы дать человеку, читающему код, сигнал, что переменная переприсвоена не будет. А let, соответственно, сигнализирует о том, что переменная скорее всего будет переприсвоена, соответственно это что-то вроде счётчика или флага, который далее будет проверен, то есть нужно обратить на это внимание.

А если вы используете иммутабельные структуры, где изменение данных всегда означает изменение ссылки на объект, то вместе с const получаете гарантию полной неизменяемости, и по ссылке, и по значению.