ЕвгенийВстрока if ("development" !== 'production') встречается 112?
Почему не заменить просто на true? :)

Потому что true не говорит не о чём, а эта строка говорит. По-моему очевидней некуда.

ЕвгенийВЭто ведь константное выражение, скорее всего ноги растут из автогенерации кода...

Bingo!

ЕвгенийВПосмотри как нибудь на досуге Vanilla JS !

А как же православный ассемблер?

ЕвгенийВКонкретно в Mithril нет строгой типизации, а значит контроля детских ошибок, например можно написать return m("diw", [ и в лучшем случае получим ошибку времени выполнения, в худшем тег diw, который браузер проигнорирует.

Какое же это имеет отношение к типизации? Это вообще-то просто синтаксис, и проблему выявит простейшие тесты.

Строгая типизация, это когда что-то куда-то надо передать, и это что-то должно отвечать определённым требования (типу).

ЕвгенийВУ меня такого нет, например хочу тег bdo - вызываю функцию bdo, которая вернет HTMLPhraseElement, у которого в отличии от HTMLElement есть пара дополнительных свойств

Ну тогда HTML сам по себе уже является самодостаточным языком, и не стоило так напрягаться. Хочешь тег bdo? Пишешь <bdo...> и у него также есть свои дополнительные свойства. А правильный редактор кода тебе и ошибку покажет и подскажет.

В чём профит-то? У virtual dom библиотек фишка в том, что ты фигачишь некоторое количество отлаженных компонент, а потом из них строишь прикладной UI. Это работает очень быстро. Какие там могут быть проблемы, если ты не пихаешь логику в UI и не пишешь её как монолитный компонент -- ведь в таком случае тебя никакая супер-мега-типизация с блекджеком и шлюхами не спасёт, это заведомо труп.

ЕвгенийВА почему бы не запихнуть логику относящаюся к UI в UI?

Потому что в UI не должно быть логики. Если не придерживаться этой стратегии разработки, то и «типизированные UI» тебе не особо поможет. Ничего не поможет, это заведомо плохой путь по дорожке, выложенной граблями.

На стороне клиента я размещаю логику отдельно от UI: если у меня меняется состояние модели, я в модели знать не знаю, как меняется вид UI, из каких элементов вообще состоит UI, какого он цвета и как он выглядит.

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

Если я сегодня буду в логике UI возиться с элементами HTML (не важно, типизировано или нет), то это деградация. Пришли к тому, от чего долго и упорно уходили.

AntonariyЭтот напряг ради генерации разметки в скрипте. Чтобы уйти от этой порнографии - innerHTML = "<div>".

Так ушли уже. Про virtual dom уже вроде как сказали. Если проблема в том, что типа можно написать так: m("diw"... — ну это абсолютно нормально, так как компоненты инкапсулируют внутри себя VDOM, он отлаживается и больше не трогается. Это не прикладной код, нет нужды в «типизированном» чекинге, никакой. Бред какой-то. Проблема высосана из мизинца левой ноги.

ЕвгенийВhVosttПотому что в UI не должно быть логики.
Что по твоему есть UI?

Внешний вид: элементы управления и визуализация данных — то, что видит и с чем взаимодействует пользователь.

В современных веб приложениях, которые иногда называют SPA, существует буквальное разделение на фронт (всё, что происходит на клиенте) и бек (всё, что происходит на сервере). В свою очередь на фронте существует формальное разделение: клиентская логика приложения и пользовательский интерфейс (UI) — это вполне себе самостоятельные части, которые могут существовать независимо, не смотря на то, что исполняются они в одном контексте (браузер).

Таким образом логику можно писать и тестировать независимо от интерфейса, без малейшего понятия о манипуляциях с DOM, грубо говоря логике должно быть абсолютно параллельно как ты там кнопку нарисовал: одним button, или сложным комплексом вложенных друг в друга div, или вообще это клякса, нарисованная на канвасе, может это вообще не кнопка, а жест мышью/пальцем.

И в тоже самое время UI можно писать в отрыве от логики и тестировать, не ожидая, когда бекендщики постараются, чтобы предоставить тебе рабочий API с необходимыми для прогона тестов данными. В UI нет логики, кроме логики анимации и поведения самого интерфейса: упираем мышь в левый край — выезжает меню, уводим — меню скрывается, и т.п. Чтобы замонстрячить такое поведение, надо ОДИН раз написать компонент, отладить его, и заниматься другими делами. Написание таких компонентов — это НЕ прикладной код, он не может быть им по определению. Поэтому так называемая «теговая типизация» бесполезна, и поэтому её нет в мейнстримах. Догадайся почему так, может она задаром никому не упала?

Класть клиентскую логику на теги — это не просто прошлый век, это тупиковый путь для разработчика, деградация. Много пота и программерской крови было пролито на клавиатуры, но похоже ещё будет поломано не мало копий. Ээээх...