Комментарии 104
Ужас
Почему ужас?
.NET это вообще какой-то другой мир, для них это может и красиво.
Я пишу на .NET Но и для меня это ужас. Ненавижу подобный код.
Хуже только Objective-C
Хуже только Objective-C
Хуже только Objective-C
Вот сейчас сильно обидел.
Без обид, но при виде Objective-C шарписты начинают громко плакать :)
Ну его Apple не просто так выкидывает, заменяя на Swift.
Интересно, как публика оценивает свифт?
Не мертворожденный ли это язык?
Я попробовал, напомнило Паскаль, но прикипел за 5 лет к Обж-Си.
Сижу и думаю, наступать на горло старой песне или подождать?
Не мертворожденный ли это язык?
Я попробовал, напомнило Паскаль, но прикипел за 5 лет к Обж-Си.
Сижу и думаю, наступать на горло старой песне или подождать?
А можно подробнее, какой код вы ненавидете?
Возможно и не ужас, но пример кода, который Вы привели навевает на мысль, что код приложения — каша из кусков шаблонов и логики приправленный макросами, чтобы всем этим управлять. Также сам код примера выглядит очень «грязным» и с наскоку разобраться в нем не очень просто, хотя подобные статьи нацелены на то, чтобы я посмотрел на код и влюбился в него, а затем использовал бы у себя. Если Вы, разработчик (как я понял), пишите такой ужасный код, то боюсь у меня все будет выглядеть еще хуже, так как некоторые нюансы я буду знать явно хуже Вас.
Я могу ошибаться, но вполне вероятно что такая реакция вызвана обилием поясняющих коментариев. Вот тот же код без них: https://gist.github.com/ionoy/1424ef755d04cec34284
Я так понимаю, что пример этот совсем плевый. По крайней мере для этого фреймворка.
Предлагаю изобразить этот же пример (с той же функциональностью) на привычном вам средстве, а мы сравним чей код окажется чище и понятнее.
То что вы в чем-то не можете разобраться может быть следствием вашей неподготовленности, а не грязи в коде. Объясните в двух словах ваши критерии «грозности кода». Лучше с примерами из этого кода.
Предлагаю изобразить этот же пример (с той же функциональностью) на привычном вам средстве, а мы сравним чей код окажется чище и понятнее.
То что вы в чем-то не можете разобраться может быть следствием вашей неподготовленности, а не грязи в коде. Объясните в двух словах ваши критерии «грозности кода». Лучше с примерами из этого кода.
Пишу на C# и Namarle для меня — это язык со сверхвозможностями. Надо просто попробовать =) JetBrains не просто так выкупили всех разработчиков Nemerle и взяли Nitra под свое крыло =)
Nemerle, конечно же =)
НЛО прилетело и опубликовало эту надпись здесь
Нет, они их выкупили для разработки Nitra.
Нет. Мы выпиливаем Nitra — language workbench (т.е. средство для создания своих языков). К разработке ReSharper-а мы непричастны (хотя и сидим в соседних комнатах).
Что-то типа ReactJS с jsx-синтаксисом для C#? Извращение)
Что-то вроде. Только тут компилируемый, функциональный язык с поддержкой макросов, которые в свою очередь позволяют делать чудеса, которые ReactJS даже не снились.
Каких только костылей не придумают.
Учить еще один язык для разработки SPA? Зачем? Ради сомнительной поддержки макросов?
Ради нормального функционального программирования и совсем несомнительной поддержки макросов. Посмотрите на последний пример. В каком фреймворке вы можете обеспечить связь сервера с клиентами + маппинг одним ключевым словом?
Немерле даёт возможности описывать только логику приложения, практически не отвлекаясь на инфраструктурные конструкции. В яваскрипт фреймворках это практически нереально.
Немерле даёт возможности описывать только логику приложения, практически не отвлекаясь на инфраструктурные конструкции. В яваскрипт фреймворках это практически нереально.
Я правильно понимаю, что вот то, что вы сейчас написали про ключевое слово, работает только с ASP.NET MVC?
НЛО прилетело и опубликовало эту надпись здесь
Ну вообще говоря Nemerle сейчас используется в JetBrains. И команда разработки трудоустроена у них же. Пилят генератор компиляторов нового поколения или что-то такое.
Да, наверное стоило об этом написать в статье. Цель данной публикации — не сподвинуть людей использовать NemerleWeb в продакшене, а скорее рассказать о проекте и может быть найти единомышленников. По нашему скромному мнению, макросистема Немерле позволяет делать вещи, которые раньше просто не были доступны в веб разработке, поэтому мы и увлеклись этой затеей. Очень надеемся, что в конце концов из этого можно будет сделать стройный надёжный фреймворк.
НЛО прилетело и опубликовало эту надпись здесь
Немерле позволяет не писать код обслуживающий доменную логику, а сосредоточиться на самой логике. То есть в некотором смысле DSL для Single Page Applications.
Не были доступны трюки наподобие макроса broadcast/signal, который сам генерирует нужный код в зависимости от использования. Не было доступной генерации адаптера к серверу, где ты добавив на сервере метод Save автоматически получаешь на клиенте поле метод _server.Save(). Это всё проверяется на этапе компиляции кстати, с интеллисенсом и прочими прелестями. И это только единичные примеры, всяких мелочей, которые самостоятельно генерируют нужный код там уйма.
А то что представление — это метод внутри модели, так это просто деталь реализации. Если кому-то очень не нравится, можно вынести в отдельный файл. Нарушения принципов MVVM там нет.
Не были доступны трюки наподобие макроса broadcast/signal, который сам генерирует нужный код в зависимости от использования. Не было доступной генерации адаптера к серверу, где ты добавив на сервере метод Save автоматически получаешь на клиенте поле метод _server.Save(). Это всё проверяется на этапе компиляции кстати, с интеллисенсом и прочими прелестями. И это только единичные примеры, всяких мелочей, которые самостоятельно генерируют нужный код там уйма.
А то что представление — это метод внутри модели, так это просто деталь реализации. Если кому-то очень не нравится, можно вынести в отдельный файл. Нарушения принципов MVVM там нет.
Nemerle — это язык, в котором есть только вызов функций, match и макросы. Всё. Даже всякие if, while и прочее — это макросы. Язык изначально заточен под создание любых встроенных DSL.
Миф — это только для тех кто не в теме. Что до конкретного случая, то — да, для конкретного. Но вся мощь расширяемых языков (к которым относится Nemerle) как раз и залючается в том, что на них можно строить решения для конкретных случаев. Этот подход называется LOP (Language Oriented Programming). Вы создаете простые языки (или языковые расширения) решающие конкретные задачи, а макросы позволяют сотворить почти любую магию во время компиляции, автоматически генерируя весь нужный обвязочный код.
Учиться нужно, в первую очередь, для себя. Ведь пока не освоишь что-то, и оценить его невозможно. Тут вот в обсуждении очень много высказываний в стиле персонажа одной известной басни. Не уподобляйтесь им!
А для начала можно и на C# писать. Nemerle его компилировать умеет. Одна беда — ителлисенса нет для C#.
Вот здесь у них есть пример на C#.
А для начала можно и на C# писать. Nemerle его компилировать умеет. Одна беда — ителлисенса нет для C#.
Вот здесь у них есть пример на C#.
да бог с ним зачем.
Оно нормально не работает. С react'ом и рядом не стояло по скорости.
Судя по всему там отрисовка не на requestAnimationFrame, вот от туда и тормоза начинаются(
Оно нормально не работает. С react'ом и рядом не стояло по скорости.
Судя по всему там отрисовка не на requestAnimationFrame, вот от туда и тормоза начинаются(
Просто клацаю и бах, каждый 5-10 клик:
screencloud.net/v/9465
screencloud.net/v/9465
Как предлагается редактировать подобную разметку? Ведь ни один существующий HTML-редактор её не осилит (я не о WYSIWYG, если что).
И вообще, что насчет разделения представления и модели?
И вообще, что насчет разделения представления и модели?
HTML редактор, конечно, не осилит. Но многие шаблонные движки страдают этим. Это не повод отказываться от шаблонных движком.
Стоит так же учесть, что в NemerleWeb уклон сделан на композицию шаблонов. Так что очень больших кусков HTML в коде не должно встречаться. Редактировать такое можно и кодовом редакторе, во всяком случае я проблем не заметил.
Стоит так же учесть, что в NemerleWeb уклон сделан на композицию шаблонов. Так что очень больших кусков HTML в коде не должно встречаться. Редактировать такое можно и кодовом редакторе, во всяком случае я проблем не заметил.
Здесь нет смешения модели и представления. Более того, здесь есть два уровня модели. Модель (что на сервере) и модель представления. Это же MVVM.
В представлении же встречается исключительно код отвечающий за рендеринг и связывание. Без него в интерактивных приложениях никуда.
В представлении же встречается исключительно код отвечающий за рендеринг и связывание. Без него в интерактивных приложениях никуда.
Nemerle классный язык, но опыт GWT ничему не учит, как я посмотрю…
У GWT не было главного — макросов. Они дают возможность делать такие вещи как бесшовная интеграция с SignalR, например.
SignalR у меня лично вызывает отторжение — настолько негативный был с ним опыт, так что для меня это не аргумент:)
Сама по себе идея писать императивный код, который превращается в декларативный (в HTML-разметку), кажется довольно странной. И вставлять в императивный код куски разметки — тоже.
Вот в clojure тоже есть макросы, и даже вроде есть вебовый фреймворк на них, а вот не взлетело. Почему-то ни один из таких фреймворков так и не нашел широкого распространения. Все о них знают, но желающих работать — единицы.
Конечно, заманчиво вместо этого хиленького html и причудливого js писать на мощном языке с выведением типов и макросами, но на деле смешение фронтенда и бэкенда слишком часто оказывается кашей.
Сама по себе идея писать императивный код, который превращается в декларативный (в HTML-разметку), кажется довольно странной. И вставлять в императивный код куски разметки — тоже.
Вот в clojure тоже есть макросы, и даже вроде есть вебовый фреймворк на них, а вот не взлетело. Почему-то ни один из таких фреймворков так и не нашел широкого распространения. Все о них знают, но желающих работать — единицы.
Конечно, заманчиво вместо этого хиленького html и причудливого js писать на мощном языке с выведением типов и макросами, но на деле смешение фронтенда и бэкенда слишком часто оказывается кашей.
Сама по себе идея писать императивный код, который превращается в декларативный (в HTML-разметку), кажется довольно странной. И вставлять в императивный код куски разметки — тоже.
Хм, у нас нет имеративной генерации HTML кода. Всё вполне себе декларативно, как в любом другом шаблонизаторе. Тут есть возможность использовать любые выражения в атрибутах, но это в любой как серверной, так и клиентской технологии можно встретить.
Метод, помеченный макро-атрибутом View по сути методом не является. Его невозможно вызвать и получить вменяемый результат. Фреймворк использует такие методы как отдельные шаблоны.
Хм, у нас нет имеративной генерации HTML кода. Всё вполне себе декларативно, как в любом другом шаблонизаторе. Тут есть возможность использовать любые выражения в атрибутах, но это в любой как серверной, так и клиентской технологии можно встретить.
Метод, помеченный макро-атрибутом View по сути методом не является. Его невозможно вызвать и получить вменяемый результат. Фреймворк использует такие методы как отдельные шаблоны.
Хм, а почему бы тогда не вынести этот код в отдельный файл?
Наверное стоит это сделать в ближайшее время, но я заметил, что удобно разрабатывать когда шаблон находится рядом с кодом. Шаблон должен отражать представление конкретной модели, поэтому если он сильно разрастается, стоит задуматься о том, что модель тоже превращается в God object, и начинает нарушать Signle Responsibility Principle.
Модели можно включать друг в друга, а значит и их шаблоны. Кстати, у модели может быть несколько шаблонов, конкретный шаблон выбирается кодом, который рендерит эту модель.
Модели можно включать друг в друга, а значит и их шаблоны. Кстати, у модели может быть несколько шаблонов, конкретный шаблон выбирается кодом, который рендерит эту модель.
удобно разрабатывать когда шаблон находится рядом с кодомИногда удобно. Но для этого должна быть команда Switch to view/controller в редакторе/IDE. Если приходится часто переключаться между первым и вторым — это звоночек, что у вас слишком сильная связанность.
В идеале, имхо, шаблоны должны быть такими, чтобы их можно было написать, глядя на IDL (JSON Schema, XSD, .proto) того, что в них будет передано.
Связанность зависит только от того, как много данных мы хотим показывать в нашем шаблоне. Впрочем, как и везде.
Но реквест вынести представление в отдельный файл мы слышим не в первый раз, так что наверное стоит этим заняться. Тем более что для этого всего то надо, натравить макрос на отдельный файл вместо метода.
Но реквест вынести представление в отдельный файл мы слышим не в первый раз, так что наверное стоит этим заняться. Тем более что для этого всего то надо, натравить макрос на отдельный файл вместо метода.
Это можно сделать просто поместив его в паршал-класс.
Метод же использован только потому, что у Nemerle имеет отличные средства расширения себя самого, но в нем не очень просто создать DSL хранящий код в отдельном фале (со своим расширением). Хотя это и возможно, но работы много.
Эту проблему должна решить Nitra.
public partial class ReactiveToDo
{
[Html]
public View() : string
{
...
}
}
Метод же использован только потому, что у Nemerle имеет отличные средства расширения себя самого, но в нем не очень просто создать DSL хранящий код в отдельном фале (со своим расширением). Хотя это и возможно, но работы много.
Эту проблему должна решить Nitra.
А в чем заключается опыт GWT?
Тяжеловесно, неудобно, мало желающих разбираться и копаться, ergo, «не взлетит».
А что тогда взлетит?
Django летает, Rails летает, Yii, Kohana, Symfony тоже летают.
Ну так у них и функционал немного другой. В GWT, как я понимаю, можно собрать SPA из компонентов не написав ни строчки js кода. Все как в старых добрых GUI framework'ах. В django такого уровня абстракции нет.
такого уровня абстракции нетзачастую и не надо, вот я к чему веду.
А что такое старые добрые GUI-фреймворки? MFC? Delphi? а что в них доброго, кроме ностальгии?
Qt/GTK и все что рядом. Доброго в них то, что есть виджеты и их можно компоновать. И делать все на одном языке.
В мире SPA виджетов все еще нет. И писать можно только на js. Никакой хаскель в браузере исполняться не будет.
В мире SPA виджетов все еще нет. И писать можно только на js. Никакой хаскель в браузере исполняться не будет.
Если бы дизайн приложений на Qt/GTK был бы так же разнообразен и изменчив, как дизайн веб-приложений, если бы Qt/GTK приложениям тоже надо было бы работать на десятке платформ (а из них половина безбожно устаревшая и неимоверная глючная) без перекомпиляции — там бы тоже никаких виджетов не было бы (точнее, они только начали бы появляться).
99% SPA имеют интерфейс не сильно сложнее того, что может предложить Qt/GTK. Да и что такого можно сделать на js, но нельзя на Qt/GTK?
js не работает на 10 платформ, всего у нас 2-3 интерпретатора, на которые все ориентируются. Мозилла, Хром, ИЕ.
Перекомпиляция тут тоже ни при чем. Гугол в свое время сделал NaCl, но мозилла не поддержала. Поддержала бы и не было бы сейчас никакого js. Вообще.
js не работает на 10 платформ, всего у нас 2-3 интерпретатора, на которые все ориентируются. Мозилла, Хром, ИЕ.
Перекомпиляция тут тоже ни при чем. Гугол в свое время сделал NaCl, но мозилла не поддержала. Поддержала бы и не было бы сейчас никакого js. Вообще.
НЛО прилетело и опубликовало эту надпись здесь
В любом месте тяжеловесно. Пустой проект собирается две минуты — до свиданья. Да и потом, простите, не летает оно ну никак. Неимоверное количество лишней разметки и сгенеренный код производительности не способствуют.
GWT это не только transpiler, это же еще и среда разработки (плагин к Eclipse) и фреймворк. Я не сравниваю это с рельсами и джангой, а противопоставляю.
GWT это не только transpiler, это же еще и среда разработки (плагин к Eclipse) и фреймворк. Я не сравниваю это с рельсами и джангой, а противопоставляю.
Разметки там будет столько сколько вы захотите. Никто не заставляет использовать устаревшие компоненты, основанные на таблицах.
На SSD пустой проект собирается за несколько секунд.
Вы видимо давно работали с GWT. Проблема в нем в том, что гугль его забросил и поддерживать его некому. Те люди, которые его сейчас мейнтейнят, делают это очень неспешно. О новых фичах можно вообще забыть.
На SSD пустой проект собирается за несколько секунд.
Вы видимо давно работали с GWT. Проблема в нем в том, что гугль его забросил и поддерживать его некому. Те люди, которые его сейчас мейнтейнят, делают это очень неспешно. О новых фичах можно вообще забыть.
Так тут-то как раз легковесно.
Ангуляр и НокаутЖС взлетели ведь. Тут тот же принцип (MVVM и биндинг) плюс автоматизация целой кучи работы: автоматическая сериализация данных при передаче между сервером и клиентом, прозрачность серверной части, статическая типизация, интелисенс.
Ангуляр и НокаутЖС взлетели ведь. Тут тот же принцип (MVVM и биндинг) плюс автоматизация целой кучи работы: автоматическая сериализация данных при передаче между сервером и клиентом, прозрачность серверной части, статическая типизация, интелисенс.
Идея забавная, но в ней я вижу несколько фатальных недостатков:
Имхо было бы больше смысла в тулзе, которая позволяет транслировать модель и вьюху, описанные в строго типизированной форме в cshtml/cs, в аналогичные сущности для AngularJS или какого-нибудь другого MVC-фреймворка.
- Код и разметка смешиваются в одном файле. На любом проекте, кроме самого маленького, это станет абсолютно неподдерживаемым.
- Нет подсказок и проверок со стороны среды разработки.
- Нет совместимости с существующими популярными решениями, и как следствие — ограниченная расширяемость.
Имхо было бы больше смысла в тулзе, которая позволяет транслировать модель и вьюху, описанные в строго типизированной форме в cshtml/cs, в аналогичные сущности для AngularJS или какого-нибудь другого MVC-фреймворка.
1. Резметка и код не смешиваются, они просто находятся в одном файле. Принципы MVVM не нарушаются. При желании можно вынести в отдельный файл.
2. Подсказки и интеллисенс есть, в этом фишка проекта.
3. Совместимость есть практически со всеми яваскрипт фреймворками, благодаря Typescript и проекту DefinitelyTyped. Мы, с помощью макроса, парсим определения к фреймворкам и генерируем на лету нужный код. Так что в коде можно использовать типизированное представление практически любой популярной библиотеки.
Мы как раз начали с того, что генерировали код для KnockoutJS, но полёт нашей фантазии был быстро прерван ограничениями нокаута. Та же история с AngularJS, он слишком сильно навязывает совственную архитектуру. Мы же хотим дать разработчику полную свободу.
2. Подсказки и интеллисенс есть, в этом фишка проекта.
3. Совместимость есть практически со всеми яваскрипт фреймворками, благодаря Typescript и проекту DefinitelyTyped. Мы, с помощью макроса, парсим определения к фреймворкам и генерируем на лету нужный код. Так что в коде можно использовать типизированное представление практически любой популярной библиотеки.
Мы как раз начали с того, что генерировали код для KnockoutJS, но полёт нашей фантазии был быстро прерван ограничениями нокаута. Та же история с AngularJS, он слишком сильно навязывает совственную архитектуру. Мы же хотим дать разработчику полную свободу.
Разработчикам типичного SPA «полная свобода» абсолютно не нужна — даже наоборот, для них была бы куда более актуальна совместимость с миллионом готовых модулей для того же AngularJS! Ведь фреймворки как раз для того и создаются, чтобы снимать с разработчика головную боль от необходимости выбора архитектуры и вместо этого предлагать готовое решение.
Я не уверен, что есть смысл использовать NemerleWeb на одной странице с AngularJS, а тем более общаться между ними. Но такая возможность присутствует, так как даже если вы не найдёте нужной типизации в DefinitelyTyped, то всегда можно вставить «сырой» джаваскрипт вот таким образом:
js <# someGlobalObject.DoSomething(); #>;Вы не совсем меня поняли. Я аргументировал в пользу того, что NemerleWeb стоило бы основываться на существующем MVC-фреймворке, а не изобретать собственный биндинг — для потенциальных пользователей в этом было бы больше проку.
У нас по началу такие же мысли были, поэтому первые версии основывались на KnockoutJS. Однако с ним мы постоянно натыкались на неустранимые препятствия, которые в конце концов вынудили написать свой биндинг.
Наверное в плане продвижения проще сделать некую типизированную обёртку над AngularJS, но тогда очень большое количество фишек трансляции было бы просто недоступно.
NemerleWeb — это проект, где мы пытаемся разобраться как можно применять метапрограммирование в веб разработке. Для этой цели нужна максимально мощная трансляция и отсутствие чужих conventions.
Наверное в плане продвижения проще сделать некую типизированную обёртку над AngularJS, но тогда очень большое количество фишек трансляции было бы просто недоступно.
NemerleWeb — это проект, где мы пытаемся разобраться как можно применять метапрограммирование в веб разработке. Для этой цели нужна максимально мощная трансляция и отсутствие чужих conventions.
> 1. Резметка и код не смешиваются, они просто находятся в одном файле. Принципы MVVM не нарушаются. При желании можно вынести в отдельный файл.
Вот вы бы показали вариант с отделённой разметкой — было бы классно и не было б такой негативной реакции, по-моему. Razor же юзают, например, и всем нравится.
Вот вы бы показали вариант с отделённой разметкой — было бы классно и не было б такой негативной реакции, по-моему. Razor же юзают, например, и всем нравится.
Я смотрю со своей колокольни, мне кажется удобным когда шаблон находится рядом, под рукой. Как уже выше отметил kekekeks проще всего выделить шаблон в отдельный файл через partial атрибут.
Если сделать шаблон текстовым, то пропадёт подчёркивание ошибок и интеллисенс. Во всяком случае до тех пор, пока у нас нет работающей Нитры
Если сделать шаблон текстовым, то пропадёт подчёркивание ошибок и интеллисенс. Во всяком случае до тех пор, пока у нас нет работающей Нитры
Жалко здесь нет смайликов, потому что сообщение очень смешное. Покритиковал и предложил сделать то что критиковал (причем его альфа-версию). Видимо критиковать намного проще и интереснее нежели разобраться в предмете критики. :)
Что ж поделать, если от самой практичной (на мой взгляд) идеи решили отказаться в альфа-версии по причине «прерывания полета фантазии»?
У нас был был выбор, либо сделать кастрированый фреймворк с биндингом на Нокауте или полноценный со своим биндингом. В чём профит использования Нокаута в нашем случае, я не понимаю.
Профит в существующей базе пользователей. Представьте, что в следующей итерации вы придумаете какую-нибудь киллер-фичу, но вот незадача — возможности платформы .NET позволят реализовать ее только в кастрированном виде, и вы решите реализовать свою собственную виртуальную машину?
Зачем доводить до абсурда? Ещё раз повтряю: Нокаут, который бы занимался биндингом сидя под нашим фреймворком, никоим образом не дал бы дополнительного профита. Биндинг в любом случае скрыт от программиста. А делать типизированную обёртку над популярным JS фреймворком у нас желания не было. Цель проекта в другом.
Примечание: Откройте страницу в двух вкладках одновременно, чтобы увидеть как данные обновляются автоматически.
Открыл и есть какой-то явный баг. Убрал 5 галок — на второй вкладке все синхронизировалось. затем убираю 6ую и вместе с ней проставляется еще 2, которые я убирал. Затем 6 возвращаю на место и те самые 2 убираются. И так постоянно.
Иногда ставлю галку, она проставляется, влtчет за собой проставление еще каких-то галок, а потом сама снимается.
Код, экшины, шаблоны, и все вперемешку? Я думал это время кануло в небытие.
Даже если это мелкий и кастомный продукт, все равно смена дизайна или UI станет просто нереальным. Кастомизация это не только другие стили в CSS подключить.
Для .NET ведь есть Razor который в умелых руках практически превращает в аналог Node,js с динамической генерацией на стороне сервера, но это в свою очередь убьет в производительности сам .NET.
Трудно представить как в данном подходе производить изменения в проекте… тоже поле провести по всей структуре, а секюрити? Я может что-то упустил? в чем идея данного подхода?
Даже если это мелкий и кастомный продукт, все равно смена дизайна или UI станет просто нереальным. Кастомизация это не только другие стили в CSS подключить.
Для .NET ведь есть Razor который в умелых руках практически превращает в аналог Node,js с динамической генерацией на стороне сервера, но это в свою очередь убьет в производительности сам .NET.
Трудно представить как в данном подходе производить изменения в проекте… тоже поле провести по всей структуре, а секюрити? Я может что-то упустил? в чем идея данного подхода?
Код, экшины, шаблоны, и все вперемешку?
Это MVVM, так что данные и код, действительно, в перемешку. Что касается шаблонов, то я уже отвечал в комментариях, что это деталь реализации. Шаблон связан с кодом ничуть не больше чем в любых других MVC/MVVM фреймворках.
Для .NET ведь есть Razor который в умелых руках практически превращает в аналог Node,js с динамической генерацией на стороне сервера, но это в свою очередь убьет в производительности сам .NET.
Для создания аналога Node.JS недостаточно генерировать нужный HTML код.
Трудно представить как в данном подходе производить изменения в проекте… тоже поле провести по всей структуре, а секюрити?
Не совсем понимаю проблему. Наш подход в плане данных не сильно отличается от остальных.
Это MVVM, так что данные и код, действительно, в перемешку. Что касается шаблонов, то я уже отвечал в комментариях, что это деталь реализации. Шаблон связан с кодом ничуть не больше чем в любых других MVC/MVVM фреймворках.
Для .NET ведь есть Razor который в умелых руках практически превращает в аналог Node,js с динамической генерацией на стороне сервера, но это в свою очередь убьет в производительности сам .NET.
Для создания аналога Node.JS недостаточно генерировать нужный HTML код.
Трудно представить как в данном подходе производить изменения в проекте… тоже поле провести по всей структуре, а секюрити?
Не совсем понимаю проблему. Наш подход в плане данных не сильно отличается от остальных.
Такой код обычно красив только в примерах.
В настоящих приложениях шаг влево, вправо и вся красота сходит на нет под тяжестью наваленных сверху костылей.
В настоящих приложениях шаг влево, вправо и вся красота сходит на нет под тяжестью наваленных сверху костылей.
Хм, похожее я уже видел несколько лет назад в Lift. Только там была Scala.
Ага и оно никому не нравилось, теперь все на Play!, где нет этих извратов
Да, порог вхождения в Lift неприлично высок, но не скажу, что там прям извраты. Для общего развития интересно побаловаться, в продакшн такое тащить не хочется.
Орлы, я вас удивлю. Лифт — это серверная генерилка текста вроде Разора. С Play, но по беглому описанию это тоже самое, но с синтаксисом Разора. К описываемому здесь продукту и его подходу он (и Разор) не имеют никакого отношения.
Изучите на досуге MVVM и поймите, что все шаблоны представленные в этой статье: а) работают на клиенте; б) динамические (перегенерируют HTML при изменении модели представления).
Изучите на досуге MVVM и поймите, что все шаблоны представленные в этой статье: а) работают на клиенте; б) динамические (перегенерируют HTML при изменении модели представления).
Не скажу, что прям удивлён. Похожесть я увидел в плане внешнего вида кода. first-class xml, сниппеты в коде, автоматическая генерация js. Биндинги в лифте не полностью генерятся, формы нужны.
Вы, видимо, разработчик этой вундервафли, раз так резко реагируете.
Вы, видимо, разработчик этой вундервафли, раз так резко реагируете.
В стародавние времена, когда .NET казался манной небесной, на RSDN жил программер-легенда с таким же ником.
Он, действительно, писал какой-то интересный код и агитировал за Nemerle, но легендарным было его ЧСВ, которое зашкаливало все мыслимые пределы. Так что не обращайте внимание, это все равно, что ругать Mithgol'a за его руссизмы.
Он, действительно, писал какой-то интересный код и агитировал за Nemerle, но легендарным было его ЧСВ, которое зашкаливало все мыслимые пределы. Так что не обращайте внимание, это все равно, что ругать Mithgol'a за его руссизмы.
Лифт никакого js автоматически не генерирует. Лифт — это серверная генерилка текста. Он конечно может сгенерировать страницу содержащую js, но это совсем не тоже самое, что сгенерировать js по коду на Скале. Соответственно понятия клиентского биндинга в Лифте нет.
В данном же случае код который пишется на Немерле преобразуется в js во время компиляции. И биндинги делаются на клиентской стороне.
Если этого не понять, то понять написанное в статье невозможно.
В данном же случае код который пишется на Немерле преобразуется в js во время компиляции. И биндинги делаются на клиентской стороне.
Если этого не понять, то понять написанное в статье невозможно.
Простая и понятная серверная генерилка текста/json'на — это то, что нужно, хотя в Play наворочено побольше.
Более сложные веб-проекты уже давно ваяют на client-side фреймворках типа Angular.
Банально удобнее работать, когда код на JS чистый, а не сгенерированный.
Тогда с ним можно работать отдельно от основного приложения, покрывать тестами и не заморачиваться тем, что там на сервере и, как бонус, никакого vendor-lock.
Я, кстати, не поленился заглянуть в вики и почитать про MVVM, потому что давно ничего про него не слышал, с тех самых пор как MS изторг из себя мертворожденный Silverlight:
Забавно, что сам автор осознал, что породил монстра.
Проект, объективно, решает какую-то несуществующую проблему, удачи вам в других начинаниях.
Более сложные веб-проекты уже давно ваяют на client-side фреймворках типа Angular.
Банально удобнее работать, когда код на JS чистый, а не сгенерированный.
Тогда с ним можно работать отдельно от основного приложения, покрывать тестами и не заморачиваться тем, что там на сервере и, как бонус, никакого vendor-lock.
Я, кстати, не поленился заглянуть в вики и почитать про MVVM, потому что давно ничего про него не слышал, с тех самых пор как MS изторг из себя мертворожденный Silverlight:
A criticism of the pattern comes from MVVM creator John Gossman himself,[15] who points out that the overhead in implementing MVVM is «overkill» for simple UI operations. He also states that for larger applications, generalizing the View layer becomes more difficult. Moreover, he illustrates that data binding in very large applications can result in considerable memory consumption.
Забавно, что сам автор осознал, что породил монстра.
Проект, объективно, решает какую-то несуществующую проблему, удачи вам в других начинаниях.
Простая и понятная серверная генерилка текста/json'на — это то, что нужно, хотя в Play наворочено побольше.
Кому и CGI то что нужно. Кто до чего дорос.
Более сложные веб-проекты уже давно ваяют на client-side фреймворках типа Angular.
Вот этот фреймворк и есть аналог Angular-а, только без необходимости вручную связывать его с сервером, вручную генерить джейсон, и склеивать все это в одно приложение. Вместо этого код (и клиентский, и серверный) пишется на Немерле, а компилятор сам преобразует его в js или в серверный код. При этом обеспечивается автоматическая и прозрачная сериализация, контроль ошибок во время компиляции и куча других вкусностей.
Банально удобнее работать, когда код на JS чистый, а не сгенерированный.
Это спорный вопрос. Немерл более мощный язык. В нем есть алгебраические типы, паттерн матчинг, и макросы (с помощью которых можно автоматизировать рутинные задачи). Плюс контроль ошибок во время компиляции (того же биндинга, например) и полная анегиляция болерплэйт-кода за счет макросов.
Я, кстати, не поленился заглянуть в вики и почитать про MVVM, потому что давно ничего про него не слышал
О, это в духе тех кто рассуждает о чужом ЧСВ. Сначала сослаться на AngularJS, а потом сказать, что давно не слышал про MVVM. Но AngularJS и есть реализация MVVM.
Кому и CGI то что нужно. Кто до чего дорос.
Более сложные веб-проекты уже давно ваяют на client-side фреймворках типа Angular.
Вот этот фреймворк и есть аналог Angular-а, только без необходимости вручную связывать его с сервером, вручную генерить джейсон, и склеивать все это в одно приложение. Вместо этого код (и клиентский, и серверный) пишется на Немерле, а компилятор сам преобразует его в js или в серверный код. При этом обеспечивается автоматическая и прозрачная сериализация, контроль ошибок во время компиляции и куча других вкусностей.
Банально удобнее работать, когда код на JS чистый, а не сгенерированный.
Это спорный вопрос. Немерл более мощный язык. В нем есть алгебраические типы, паттерн матчинг, и макросы (с помощью которых можно автоматизировать рутинные задачи). Плюс контроль ошибок во время компиляции (того же биндинга, например) и полная анегиляция болерплэйт-кода за счет макросов.
Я, кстати, не поленился заглянуть в вики и почитать про MVVM, потому что давно ничего про него не слышал
О, это в духе тех кто рассуждает о чужом ЧСВ. Сначала сослаться на AngularJS, а потом сказать, что давно не слышал про MVVM. Но AngularJS и есть реализация MVVM.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
NemerleWeb — Уникальный веб-фреймворк