3 ms·

Code-generation has always been a major annoyance for real (ya, I said it) developers using MS tools. It'll be interesting to see if recipes are able to do what

by latch 15y ago

Code-generation has always been a major annoyance for real (ya, I said it) developers using MS tools. It'll be interesting to see if recipes are able to do what decades of similar promises from MS have failed to deliver. The mention of a recipe for an AJAX grid is frightening though...like we are heading back into server-control world. Despite all the talk, MS never really bought into jQuery. Also, I worry when the 2nd feature listed is that the default CSS/theme (which no one uses and is pretty ugly) supports mobile devices. They mention deployment as a theme, but no feature to accompany it. It'll be interesting to see what they manage to do here. It's certainly a major pain point right now. Of course, none of this addresses the primary issues with ASP.NET MVC: it's much, much, slower to develop in than Rails or Django.

codingthebeach 15y ago
ASP.NET MVC is comparable to both Rails and Django in terms of speed, but you have to know what you're doing. Competency is required. But that shouldn't be a problem for a "real" developer such as yourself. ;)
kenjackson 15y ago
Of course, none of this addresses the primary issues with ASP.NET MVC: it's much, much, slower to develop in than Rails or Django. I'd say just the opposite. Things like deployment and things like gems are the big issues. Actually day to day dev work though, I think MVC is probably at least as productive as Rails or Django, if not moreso. But I think its personal taste more than anything else. Code-generation has always been a major annoyance for real (ya, I said it) developers using MS tools. It'll be interesting to see if recipes are able to do what decades of similar promises from MS have failed to deliver. I don't think Recipes are really meant to address codegen. It sounds like a simpler way to build Wizards, not much more than that. MS's solution to general codegen are things such as CCI (http://ccimetadata.codeplex.com/ http://ccimetadata.codeplex.com/).
- spamizbad 15y ago
  I disagree. MVC is quite good, but as both a Django and MVC developer I'm still more productive with Django. Certain niceties of MVC break down once your project falls outside of the mold of a cookie-cutter CRUD app interfacing with a 100% Microsoft ecosystem. People have levied a similar criticism against Django (once you color too far outside the lines, things get hard fast) but with MVC it can creep up on you much faster. MVC shines if you treat it like a lightweight MVC framework and don't get caught up in doing things the "Microsoft" way -- this is massively counter-intuitive to anyone coming from a Python or Ruby background, who prefer to code in an idiomatic way by default. You can take advantage of its powerful routing system, various helper functions, and a decent templating language: Razor - which I hope Microsoft keeps and doesn't replace like it did to the 2 or 3 other templating syntax systems that proceeded it.
  - silverbax88 15y ago
    I find that Django doesn't even come close to MVC. But as to your second point, doing lightweight MVC (not the junk that MS has offered as examples) with Razor is by far the slickest, fastest development environment I've worked with for web.
    - notJim 15y ago
      Razor is a part of MVC...
      - alexro 15y ago
        Not necessarily, have a look at RazorEngine - this is a standalone dll that lets you use Razor anywhere
  - kenjackson 15y ago
    Certain niceties of MVC break down once your project falls outside of the mold of a cookie-cutter CRUD app interfacing with a 100% Microsoft ecosystem. I guess my question would be, what's an example of this. I find MVC with Razor extremely productive. I rarely even think of a framework when I'm using it -- I'm just typing what I'd like to make happen (for the most part). And for me the tooling makes my life much easier. I know this is controversial statement for Django/Rails devs who are pretty much vi/emacs devs, but simple things like being to jump between quickly seeing all defs/uses/implementations of a method/property/class/assembly is extremely useful. But I hacked away on vi for almost 20 years, so I realize its allure.
- profquail 15y ago
  T4 is used more for codegen; or, you can write a code-generator plugin for Visual Studio to handle a specific type of code generation (e.g., where you can expand a file in the solution/project pane and see the 'code-behind'). Most of the codegen for MS tools actually generates code in whatever language your project uses (like C#). CCI is a library for manipulating .NET bytecode, and is much lower-level than you'd normally need (or want) to deal with.
Encosia 15y ago
I don't think it's fair to say Microsoft never bought into jQuery. They've continued moving toward jQuery-centric approaches on both the MVC and WebForms fronts, communicate to developers that it's the preferred approach for client-side development, devote development/testing resources to jQuery and jQuery UI, and threw out their MicrosoftAjax.js based validation for a new approach based entirely on jQuery and the jQuery Validation plugin (and I hear that's coming to WebForms as well). Even the WCF team has reworked their client-side examples and libraries stuff to be based on jQuery and less cumbersome. I believe what they're talking about regarding an "AJAX grid" is the idea of using an HTML helper to render a collection of data that matches up with what the upcoming jQuery UI Grid widget expects. You could still draw a parallel to server-controls there, but it seems harmless. Ultimately, it's the sort of thing we all end up writing ourselves anyway.

by latch 15y ago

codingthebeach 15y ago

ASP.NET MVC is comparable to both Rails and Django in terms of speed, but you have to know what you're doing. Competency is required. But that shouldn't be a problem for a "real" developer such as yourself. ;)

kenjackson 15y ago

Of course, none of this addresses the primary issues with ASP.NET MVC: it's much, much, slower to develop in than Rails or Django. I'd say just the opposite. Things like deployment and things like gems are the big issues. Actually day to day dev work though, I think MVC is probably at least as productive as Rails or Django, if not moreso. But I think its personal taste more than anything else. Code-generation has always been a major annoyance for real (ya, I said it) developers using MS tools. It'll be interesting to see if recipes are able to do what decades of similar promises from MS have failed to deliver. I don't think Recipes are really meant to address codegen. It sounds like a simpler way to build Wizards, not much more than that. MS's solution to general codegen are things such as CCI (http://ccimetadata.codeplex.com/ http://ccimetadata.codeplex.com/).

spamizbad 15y ago
I disagree. MVC is quite good, but as both a Django and MVC developer I'm still more productive with Django. Certain niceties of MVC break down once your project falls outside of the mold of a cookie-cutter CRUD app interfacing with a 100% Microsoft ecosystem. People have levied a similar criticism against Django (once you color too far outside the lines, things get hard fast) but with MVC it can creep up on you much faster. MVC shines if you treat it like a lightweight MVC framework and don't get caught up in doing things the "Microsoft" way -- this is massively counter-intuitive to anyone coming from a Python or Ruby background, who prefer to code in an idiomatic way by default. You can take advantage of its powerful routing system, various helper functions, and a decent templating language: Razor - which I hope Microsoft keeps and doesn't replace like it did to the 2 or 3 other templating syntax systems that proceeded it.
- silverbax88 15y ago
  I find that Django doesn't even come close to MVC. But as to your second point, doing lightweight MVC (not the junk that MS has offered as examples) with Razor is by far the slickest, fastest development environment I've worked with for web.
  - notJim 15y ago
    Razor is a part of MVC...
    - alexro 15y ago
      Not necessarily, have a look at RazorEngine - this is a standalone dll that lets you use Razor anywhere
- kenjackson 15y ago
  Certain niceties of MVC break down once your project falls outside of the mold of a cookie-cutter CRUD app interfacing with a 100% Microsoft ecosystem. I guess my question would be, what's an example of this. I find MVC with Razor extremely productive. I rarely even think of a framework when I'm using it -- I'm just typing what I'd like to make happen (for the most part). And for me the tooling makes my life much easier. I know this is controversial statement for Django/Rails devs who are pretty much vi/emacs devs, but simple things like being to jump between quickly seeing all defs/uses/implementations of a method/property/class/assembly is extremely useful. But I hacked away on vi for almost 20 years, so I realize its allure.
profquail 15y ago
T4 is used more for codegen; or, you can write a code-generator plugin for Visual Studio to handle a specific type of code generation (e.g., where you can expand a file in the solution/project pane and see the 'code-behind'). Most of the codegen for MS tools actually generates code in whatever language your project uses (like C#). CCI is a library for manipulating .NET bytecode, and is much lower-level than you'd normally need (or want) to deal with.

Encosia 15y ago

I don't think it's fair to say Microsoft never bought into jQuery. They've continued moving toward jQuery-centric approaches on both the MVC and WebForms fronts, communicate to developers that it's the preferred approach for client-side development, devote development/testing resources to jQuery and jQuery UI, and threw out their MicrosoftAjax.js based validation for a new approach based entirely on jQuery and the jQuery Validation plugin (and I hear that's coming to WebForms as well). Even the WCF team has reworked their client-side examples and libraries stuff to be based on jQuery and less cumbersome. I believe what they're talking about regarding an "AJAX grid" is the idea of using an HTML helper to render a collection of data that matches up with what the upcoming jQuery UI Grid widget expects. You could still draw a parallel to server-controls there, but it seems harmless. Ultimately, it's the sort of thing we all end up writing ourselves anyway.