Comments 24
А поверх OWIN никак не завести? Гвоздями приколочено к инфраструктуре ASP.NET и IIS?
На IIS ни как не завязано.
Что касается компонентов framework, то:
CQRS можно без проблем и для desktop проектов применять ( был опыт )
IML это синтаксис для построения атрибутов в dom элементы, которому важно только формат возрощаемых данных, а как реализован Action не принципиально ( web api, HttpHandler, WCF )
P.S. Будет интерес, я могу написать статью про интеграцию с OWIN
Что касается компонентов framework, то:
CQRS можно без проблем и для desktop проектов применять ( был опыт )
IML это синтаксис для построения атрибутов в dom элементы, которому важно только формат возрощаемых данных, а как реализован Action не принципиально ( web api, HttpHandler, WCF )
P.S. Будет интерес, я могу написать статью про интеграцию с OWIN
Интересно. У того же Mono большие проблемы с инфраструктурой ASP.NET (если вкратце, то тормозит), приходится пользоваться хостами фреймворков поверх HttpListener, а то и писать что-то своё, чтобы получить нормальную производительность, для интереса можете посмотреть на сравнительные результаты работы NancyFx в mono-fastcgi-server и моего хоста на базе evhttp.
Первая картинка оскорбляет мои религи чувства разработчика.
Против C# ничего не имею, но тот факт, что JS находится в клетке по меньшей мере неполиткорректен, а по большей — логически неверен.
Против C# ничего не имею, но тот факт, что JS находится в клетке по меньшей мере неполиткорректен, а по большей — логически неверен.
В JavaScript, однако, есть вполне объективные недоработки, связанные с тем, что язык, по выражению его автора (Brendan Eich) делался «за 10 бессонных дней и ночей». Поэтому некоторые моменты продуманы плохо, есть и откровенные ошибки (которые признает тот же Brendan)
На самом деле картинка несет ироничный характер и не направленна на оскорбления людей использующих JavaScript ( JS занимает львиную долю кода в incoding framework )
Логика картинки в том, что бы заменить JavaScript при разработки на клиентской стороне с помощью C#, по этому не совсем пойму что не верно.
Первая картинка оскорбляет мои чувства разработчика.
На самом деле картинка несет ироничный характер и не направленна на оскорбления людей использующих JavaScript ( JS занимает львиную долю кода в incoding framework )
по большей — логически неверен.
Логика картинки в том, что бы заменить JavaScript при разработки на клиентской стороне с помощью C#, по этому не совсем пойму что не верно.
Таже песня что и с GWT, фреймоворк для лузеров которые боятся и ненавидят JS.
для лузеров которые боятся и ненавидят JS.
ORM для лузеров, которые боятся и ненавидят SQL
Не совсем ясна связь между SQL и JS. Где последний отвечает ПОО парадигме, легко тестируется, регулярно обновляется. Что то я как-то не замечал этого за SQL. Ну во всяком случае ваша точка зрения ясна, вы ставите клиентские браузерные языки в один ряд с языком запросов к бд.
Не совсем ясна связь между SQL и JS.
IML позволяет использовать C# вместо написания чистого JS, ORM абстрагирует от написания SQL.
Ваша точка зрения тоже понятна, вы даже не смотрели, что я предлагаю, а решили написать вывод обо мне и проекте.
Не вижу особой разницы между вашей идей и GWT, если таковая есть, будьте любезны просветите.
Вас не смущает, что это разные платформы и технологии хотя бы?
Концептуально, в чем отличия?
вы уходите в крайне абстрактные ( концептуальный уровень и т.д. ) вопросы, на которые даже ответить толком нечего.
Я не знаю про GWT и не буду его изучать, потому что это совсем другой стек, который не нужен в моей работе.
P.S. Я рад ответить на вопросы про проект, может какие то замечания по синтаксису, возможностям, но это должна быть конкретика, а не отсылка в то чем я даже занимаюсь.
Я не знаю про GWT и не буду его изучать, потому что это совсем другой стек, который не нужен в моей работе.
P.S. Я рад ответить на вопросы про проект, может какие то замечания по синтаксису, возможностям, но это должна быть конкретика, а не отсылка в то чем я даже занимаюсь.
Ну как хотите, GWT задолго до вас заключал за решетку JS, но последний до сих пор держится а вот о GWT давно уже завял. Мне казалось логичным прощупать конъюнктуру прежде чем браться за разработку. Продуктивность вашего подхода выглядит сомнительно при том что он может быть покрывает 80 процентов простых случаев, а вот в 20 оставшихся процентах придется рвать шерсть на одном месте. Как быть если понадобится использовать кастумный плагин jquery или промизы, пилить напильником?
что он может быть покрывает 80 процентов простых случаев, а вот в 20 оставшихся процентах придется рвать шерсть на одном месте.
Личный опыт использования? Есть сотни способов, как дописать новый функционал.
. Мне казалось логичным прощупать конъюнктуру прежде чем браться за разработку.
Пощупать разработку на других платформах?
Как быть если понадобится использовать кастумный плагин jquery или промизы, пилить напильником?
Extensions — blog.incframework.com/ru/extensions/
Разные вопросы — blog.incframework.com/ru/faq/
Если интересно, то приведу примеры кода, как можно вызывать Jquery plugin, свой метода поверх Selector и многие другие задачи.
P.S. Incoding framework это проверенный в десятках сложный приложений инструмент, конечно у многих разработчиков есть задачи с которыми я не сталкивался, но это относится к любому framework. Мы говорим только об одной части нашего framework, хотя там очень много и других ( Unit Test, cqrs, template и т.д. ), а Вы сразу ставите штамп «велосипед».
Пощупать разработку на других платформах?
Если концепция неудачна на java, python не представляю как она может быть удачна на .net
То что я видел в примерах jquery vs ваш фреймворк, с точки зрения написания современных приложений немного устаревает (я говорю касательно jquery). Использование jquery в виду усложнения логики среднестатистических приложений рассматривается как использование js низкого уровня примерно 5 лет назад. Сегодня гораздо удобнее использовать knockout.js или angular.js вместо излеваний тон js-кода низкого уровня. В связи с этим не вижу никакого позитивизма от использования вашего фреймворка, вы просто переносите спагетти код HTML/js(jquery) на сторону сервера RAZOR/c# dsl, какой от этого выигрыш?
Сегодня гораздо удобнее использовать knockout.js или angular.js вместо излеваний тон js-кода низкого уровня
Согласен, но статья ориентированна на тех, кто понял, что jquery и «скриптовый хардкод» это не удобно и сложно поддерживать и хочет, как то все структурировать. Jquery знают все, а конкретный js framework не каждый.
HTML/js(jquery) на сторону сервера RAZOR/c# dsl, какой от этого выигрыш?
1. Один язык
2. Интеграция с серверной частью ( font end тот же back end )
3. Все плюшки C#
4. Ещё раз, IML это набор возможностей ( уделите не много времени и ознакомитесь www.techdays.ru/videos/7236.html )
Могу добавить, что мне не нравится в использованием скажем angular.js, то что приходиться от части повторять модель серверной стороны ( mvc, mvvm и т.д. ) и писать JavaScript.
Для большего понимания IML стоит посмотреть blog.incframework.com/ru/power-selector/, а так же увидеть интеграцию с MVD blog.incframework.com/ru/model-view-dispatcher/.
P.S. Рад, что вопросы обретают конкретику.
P.S. Рад, что вопросы обретают конкретику.
IML это декларативный язык, который описывает поведение, но не реализацию
IML это C#
Я не совсем понял какая связь между императивным C# и декларативным подходом к программированию.
Второе замечание, как альтернативу JS вы приводите TypeScript, простите за откровенность но кто, нафиг пишет на нем и кому он нафиг нужен? Другое дело Coffescript, Kotlyn, Scala или F# как замена JS, но не об одном из них вы не обмолвились. А они решают все заявленные вами претензии к JS.
Мне кажется подобный вашему велосипед уже пыталась реализовать корпорация добра(GWT), но мне кажется этот проект можно уже достаточно давно сбросить со счетов.
IML это C# — идея в том, что описывать с помощью декларативного синтаксиса клиентские сценарии, а сам синтаксис выполнен на C#
Написать код, который будет работать в браузере можно, только через Coffescript и то по факту будет JavaScript. Все минусы TypeScript, так же относятся и к CoffeScript.
Coffescript, Kotlyn, Scala или F# как замена JS,
Написать код, который будет работать в браузере можно, только через Coffescript и то по факту будет JavaScript. Все минусы TypeScript, так же относятся и к CoffeScript.
Написать код, который будет работать в браузере можно, только через Coffescript и то по факту будет JavaScriptНа в чем проблема, если ваш кода валидный и вы используете sourcemap?
Я предлагаю решение со своими плюсами и минусами, которые описаны в статье.
IML это часть Incoding Framework, который покрывает весь цикл разработки и позволяет интегрировать каждую часть между собой, а вы говорит о языке, который позволяет писать JavaScript иначе, но ни как не связан с asp.net mvc.
Я не отрицаю, что на Coffescript пишут JavaScript приложения, но я предлагаю альтернативный вариант для тех, кому больше нравится C# и декларативный подход с готовым набор возможностей.
IML это часть Incoding Framework, который покрывает весь цикл разработки и позволяет интегрировать каждую часть между собой, а вы говорит о языке, который позволяет писать JavaScript иначе, но ни как не связан с asp.net mvc.
Я не отрицаю, что на Coffescript пишут JavaScript приложения, но я предлагаю альтернативный вариант для тех, кому больше нравится C# и декларативный подход с готовым набор возможностей.
del
Sign up to leave a comment.
Incoding rapid development framework