Если "гибкость", это децентрализованное состояние с неконтролируемой типами мутацией, тогда просто отлично, что этого нет

Такую гибкость мы уже проходили в мейнстримовом ООП

"Компоненты" - тоже из этой же оперы

Гибкость в моем понимании - это композируемость. А единый стейт для всех страниц, таскаемый со страницы на страницу - это монолит.

Композируемость решается библиотеками. Я вот для себя порешал

(/me нагло намекает на своё поделие https://github.com/astynax/tea-combine)

Послушайте, я прекрасно понимаю, что при помощи библиотек в любом turing-complete языке можно решить любую проблему. Но лично я не очень люблю танцев с бубнами. К моему сожалению, я попробовал Haskell и знаю, как легко любое перечисление сделать инстансом класса типов Ord. Не знал бы этого - не огорчался бы тому, что в Elm'е это нужно делать при помощи сторонних библиотек. Но я знаю и поэтому огорчаюсь ))

Я не защищаю Elm в плане скудности языка. Но TEA - нормальная здоровая архитектура. Особенно - реализованная на нормальном языке :)

Ругать архитектуру фреймворка за то, что в языке нельзя сделать пользовательский тип ключом словаря - неконструктивно

Elm - не полный по Тьюрингу

И вообще поднадоело уже это повсеместное взывание к "на любом Тьюринг-полном..." :)

Хорошая архитектура, согласен. Мне тоже нравится много чем. Но вот негибкостью не очень нравится - я люблю иметь варианты. Была бы она рекомендуемым паттерном проектирования, не исключающим использования других паттернов - было бы отлично.

Elm - не язык общего назначения. Но в своей нише - далеко не самый плохой. Лучше, чем Reason, например. И экосистема у языка нормальная, а главное - она есть. Многим языкам до такой инфраструктуры расти и расти. И пакетов для Elm много для такого нишевого языка. Поэтому и занял свою нишу

А мне немного поднадоело постоянная отсылка к тому, что "да, сам язык этого не позволяет, но есть библиотека" )). Напоминает бородатые шутки про jQuery )) https://ru.stackoverflow.com/questions/515499/%D0%A1%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5-%D1%87%D0%B8%D1%81%D0%B5%D0%BB-%D0%BD%D0%B0-jquery

У Elm свой подход к работе с пакетами, настоящий semver, полная изоляция от фронтендового тулинга (до поры до времени), фреймворк готовый и используемый всеми, куча либ для самого разного (в области GUI-строения).

А у PureScript всё ещё нет нормального самостоятельного тулчейна, не требующего возни с написанием конфигов для JS-оперденей. Да, паразитирование на существующем тулинге, это волевое решение, но неприятно от этого не меньше.

У GHCJS вообще всё плохо - есть только компилер и десяток либ. Ни о каком покрытии Web Platform говорить не приходится.

Зато да, enum можно сделать ключом словаря

Ситуация ровно как с Go - самый популярный, это самый простой. Только в случае с Elm даже "самый популярный" всё ещё не выбился из маргинальной песочницы (Go тоже в абсолютном соотношении далёк от мейнстрима).

а ты ожидаешь что выбьется?

В следующем релизе в Elm вкрутят dead code elimination и отпиливание рантайма от собственно кода. Работы в сторону полного покрытия web platform (что бы они под этим не подразумевали) ведутся. Этого многие ждут. С релизом пользователей прибавится, даже не смотря на уход тех, кому нужны кортежи длиннее двух элементов

Проще говоря, Elm делает всё, чтобы прийти к успеху. Например ухудшает себя в сторону большей простоты

ничего там не прибавится