Наверное стоит это сделать в ближайшее время, но я заметил, что удобно разрабатывать когда шаблон находится рядом с кодом. Шаблон должен отражать представление конкретной модели, поэтому если он сильно разрастается, стоит задуматься о том, что модель тоже превращается в God object, и начинает нарушать Signle Responsibility Principle.
Модели можно включать друг в друга, а значит и их шаблоны. Кстати, у модели может быть несколько шаблонов, конкретный шаблон выбирается кодом, который рендерит эту модель.
1. Резметка и код не смешиваются, они просто находятся в одном файле. Принципы MVVM не нарушаются. При желании можно вынести в отдельный файл.
2. Подсказки и интеллисенс есть, в этом фишка проекта.
3. Совместимость есть практически со всеми яваскрипт фреймворками, благодаря Typescript и проекту DefinitelyTyped. Мы, с помощью макроса, парсим определения к фреймворкам и генерируем на лету нужный код. Так что в коде можно использовать типизированное представление практически любой популярной библиотеки.
Мы как раз начали с того, что генерировали код для KnockoutJS, но полёт нашей фантазии был быстро прерван ограничениями нокаута. Та же история с AngularJS, он слишком сильно навязывает совственную архитектуру. Мы же хотим дать разработчику полную свободу.
Сама по себе идея писать императивный код, который превращается в декларативный (в HTML-разметку), кажется довольно странной. И вставлять в императивный код куски разметки — тоже.
Хм, у нас нет имеративной генерации HTML кода. Всё вполне себе декларативно, как в любом другом шаблонизаторе. Тут есть возможность использовать любые выражения в атрибутах, но это в любой как серверной, так и клиентской технологии можно встретить.
Метод, помеченный макро-атрибутом View по сути методом не является. Его невозможно вызвать и получить вменяемый результат. Фреймворк использует такие методы как отдельные шаблоны.
Немерле позволяет не писать код обслуживающий доменную логику, а сосредоточиться на самой логике. То есть в некотором смысле DSL для Single Page Applications.
Не были доступны трюки наподобие макроса broadcast/signal, который сам генерирует нужный код в зависимости от использования. Не было доступной генерации адаптера к серверу, где ты добавив на сервере метод Save автоматически получаешь на клиенте поле метод _server.Save(). Это всё проверяется на этапе компиляции кстати, с интеллисенсом и прочими прелестями. И это только единичные примеры, всяких мелочей, которые самостоятельно генерируют нужный код там уйма.
А то что представление — это метод внутри модели, так это просто деталь реализации. Если кому-то очень не нравится, можно вынести в отдельный файл. Нарушения принципов MVVM там нет.
Да, пока только с ASP.NET MVC. Но это не жёсткое ограничение, просто до других серверных технологий пока не дошли руки. Проще говоря, пока не надо было.
HTML редактор, конечно, не осилит. Но многие шаблонные движки страдают этим. Это не повод отказываться от шаблонных движком.
Стоит так же учесть, что в NemerleWeb уклон сделан на композицию шаблонов. Так что очень больших кусков HTML в коде не должно встречаться. Редактировать такое можно и кодовом редакторе, во всяком случае я проблем не заметил.
Перформанс должен быть удовлетворительным для большинства задач, на мобильниках работает нормально. Но вполне вероятно, что оно, действительно, рядом не стояло по скорости с React'ом. Перформанс сейчас пока не на первом месте в приоритете, в основном занимаемся другими задачами,
Да, наверное стоило об этом написать в статье. Цель данной публикации — не сподвинуть людей использовать NemerleWeb в продакшене, а скорее рассказать о проекте и может быть найти единомышленников. По нашему скромному мнению, макросистема Немерле позволяет делать вещи, которые раньше просто не были доступны в веб разработке, поэтому мы и увлеклись этой затеей. Очень надеемся, что в конце концов из этого можно будет сделать стройный надёжный фреймворк.
Ради нормального функционального программирования и совсем несомнительной поддержки макросов. Посмотрите на последний пример. В каком фреймворке вы можете обеспечить связь сервера с клиентами + маппинг одним ключевым словом?
Немерле даёт возможности описывать только логику приложения, практически не отвлекаясь на инфраструктурные конструкции. В яваскрипт фреймворках это практически нереально.
Что-то вроде. Только тут компилируемый, функциональный язык с поддержкой макросов, которые в свою очередь позволяют делать чудеса, которые ReactJS даже не снились.
Мне год назад понадобилось из CSS сделать SCSS, в котором уже все правила будут как надо вложены и удалены, если были лишними. Написал простейший парсер Text -> AST парсер на Немерле PEG. Если интересно, то можете посмотреть, как коротко можно записать весь парсер: bitbucket.org/ionoy/sassoptimize/src/5965ddb5fcbea9692fae3b4a393117651654ff37/Parser.n
Это ни в коем случае не конкурент вашему проекту, там кроме преобразования текста в АСТ ничего нету, но может быть будет любопытно посмотреть.
Тут уже каждый сам выбирает, нужна ли ему дополнительная функциональность. Меня кроме кнопок громкости больше ничего не интересовало, так что K400 подошла лучше. Тем более, что имхо она посимпотичнее выглядит, чем K700.
Модели можно включать друг в друга, а значит и их шаблоны. Кстати, у модели может быть несколько шаблонов, конкретный шаблон выбирается кодом, который рендерит эту модель.
2. Подсказки и интеллисенс есть, в этом фишка проекта.
3. Совместимость есть практически со всеми яваскрипт фреймворками, благодаря Typescript и проекту DefinitelyTyped. Мы, с помощью макроса, парсим определения к фреймворкам и генерируем на лету нужный код. Так что в коде можно использовать типизированное представление практически любой популярной библиотеки.
Мы как раз начали с того, что генерировали код для KnockoutJS, но полёт нашей фантазии был быстро прерван ограничениями нокаута. Та же история с AngularJS, он слишком сильно навязывает совственную архитектуру. Мы же хотим дать разработчику полную свободу.
Хм, у нас нет имеративной генерации HTML кода. Всё вполне себе декларативно, как в любом другом шаблонизаторе. Тут есть возможность использовать любые выражения в атрибутах, но это в любой как серверной, так и клиентской технологии можно встретить.
Метод, помеченный макро-атрибутом View по сути методом не является. Его невозможно вызвать и получить вменяемый результат. Фреймворк использует такие методы как отдельные шаблоны.
Не были доступны трюки наподобие макроса broadcast/signal, который сам генерирует нужный код в зависимости от использования. Не было доступной генерации адаптера к серверу, где ты добавив на сервере метод Save автоматически получаешь на клиенте поле метод _server.Save(). Это всё проверяется на этапе компиляции кстати, с интеллисенсом и прочими прелестями. И это только единичные примеры, всяких мелочей, которые самостоятельно генерируют нужный код там уйма.
А то что представление — это метод внутри модели, так это просто деталь реализации. Если кому-то очень не нравится, можно вынести в отдельный файл. Нарушения принципов MVVM там нет.
Стоит так же учесть, что в NemerleWeb уклон сделан на композицию шаблонов. Так что очень больших кусков HTML в коде не должно встречаться. Редактировать такое можно и кодовом редакторе, во всяком случае я проблем не заметил.
Немерле даёт возможности описывать только логику приложения, практически не отвлекаясь на инфраструктурные конструкции. В яваскрипт фреймворках это практически нереально.
Это ни в коем случае не конкурент вашему проекту, там кроме преобразования текста в АСТ ничего нету, но может быть будет любопытно посмотреть.