Comment by skrebbel | Hacker News Reader

Comment by skrebbel | Hacker News Reader

Folks, not much of this is new. Both Entity Framework and ASP.NET MVC were already open source for quite some time [0][1]. All the other repos are nearly empty.

The only real news here is that, indeed, ASP.NET vNext is going to be developed in the open, or at least to some extent. But right now, not a lot of code seems to be released that wasn't already out there (although I did not go through all the repos).

I don't think you should expect to find many current/legacy parts of ASP.NET that aren't open yet: this seems to be mostly for new stuff.

Finally, don't forget that "ASP.NET" doesn't seem to mean a lot (anymore): it's basically Microsoft actively shipping the org chart. Anything that's web related and from MS appears to get tacked "ASP.NET" on front of it. Cause really, what does ASP.NET MVC, basically a pretty uninspired Rails port to C# (and just an open source library like any other), have to do with "active server pages"?

[0] https://aspnet.codeplex.com/wikipage?title=MVC [1] https://entityframework.codeplex.com/

"Uninspired rails port" is a far cry from accurate. I've worked with both rails and asp.net mvc. I started with rails in the 1.x days but also had clients that used .net. I despised web forms for a variety of reasons so I jumped on the mvc bandwagon as soon as the fist community preview was released.

Hack, Connery, Hanselman, & Guthrie openly acknowledge that rails was a source of inspiration in their book http://www.amazon.com/gp/product/0470384611?ie=UTF8&tag=scob... but so was Spring, among others. Above all, I think the .net mvc framework was trying to capture the fasted-paced, fly-by-the-seat-of-your-pants essence of the rails way more than anything else. In doing so, they unearthed a lot of awesome concepts previously unknown to most .net developers like domain-driven design, tdd/bdd, dependency injection, scaffolding; old hats to Java and ruby guys.

The mvc .net team did an amazing job of breaking stride with the asp.net mentality of letting the framework do as much as possible. Yet .net was still very much confined by it's own structure, forcing the mvc framework to remain rigid. They opted for configuration over convention which, in my opinion, was by far the biggest differentiator in rails to the mvc frameworks that preceded it.

> They opted for configuration over convention. . .

I believe you meant "convention over configuration", right?

convention over configuration is the motto on Rails and ASP.Net MVC is actually the opposite so that's why OP says it was the biggest differentiator between the two frameworks.

They also filled it up to the edge with Ruby-like magic all over the place.

ASP.NET MVC is the only place I've ever seen in mainstream compiled languages where the code can break in untraceable ways if you change the name of a method parameter (f.ex. for controller actions). Or where models suddenly don't get data because you forget to add "{get; set;}" to the code somewhere. Absolutely no way to find out why it went wrong. The data just isn't there.

Sure, you can learn this and then not make the mistake again, but the reason I don't use Ruby or Python much anymore is because I've had with with having to spend a full day going through a framework's source code to find out why my bug is a bug. In an ecosystem and language like C#, you expect things to either work or to get a pretty OK error message, preferably at compile time. The more magic, the more time I waste tracing bugs.

What's the point of using a compiled language if half your code is a dynamic viewbag of string keys and liberal JSON parsers that just ignore fields it doesn't expect or can't fill?

It's just Ruby, but then in Visual Studio.

> Sure, you can learn this and then not make the mistake again, but the reason I don't use Ruby or Python much anymore is because I've had with with having to spend a full day going through a framework's source code to find out why my bug is a bug. In an ecosystem and language like C#, you expect things to either work or to get a pretty OK error message, preferably at compile time.

No, that's what you expect. I expect that the traits of frameworks you describe to be features of particular frameworks and to be largely independent of language, except that in languages that don't provide introspection/metaprogramming facilities that enable them, you probably won't find them (probably, because usually there may be elaborate ways of hacking around language limitations to do magic, and then even examining the source code will make the magic less obvious.)

You can easily have magic-free frameworks in Ruby or Python, and easily heavy-magic frameworks in most (mostly) statically-typed compiled languages like C# and friends as long as they have some introspection/metaprogramming facilities (and optional dynamic typing like C# makes this more viable, too.)

If you want to choose a language so as to avoid any need to examine the traits of particular frameworks so that you don't run into a heavy-magic one, you are going to need a much more limited language than C#.

> What's the point of using a compiled language if half your code is a dynamic viewbag of string keys and liberal JSON parsers that just ignore fields it doesn't expect or can't fill?

The point is the other half of the code. (The part that, in Python or Ruby you might be tempted to drop down to a C or Java [for JRuby] extension to do.)

ASP.NET MVC shares a ton of the common infrastructure with ASP.NET webforms. It's true that when there was only webforms, there was no need to distinguish and it was all called "ASP.NET". However, MVC and webforms are now two different patterns one can use to structure applications that run on the large, extensive and shared "ASP.NET" infrastructure.

As are ASP.NET Web API, and several non-Microsoft projects such as Fubu MVC, NancyFx, or MonoRail.

That said, can't blame anyone for once again being confused by Microsoft's ultra-confusing "give everything the same name" approach to branding.

"ASP.NET" is the name of Microsoft's .NET web platform. To answer your rhetorical question, ASP.NET MVC is an MVC framework for Microsoft's .NET web platform. "Microsoft MVC" would not be clearly constrained to web development.

"Microsoft's .NET web platform"

What does that even mean? In this case, a bunch of libraries and a protocol for dispatching HTTP requests to .NET code.

If I use Mono's XSP server, and use it to host a ServiceStack backend, am I using "the ASP.NET platform"? It's 100% non-Microsoft open source. Am I using ASP.net when I host the same backend on IIS instead? Or when I host ASP.NET MVC (which is just a library) on Mono/XSP?

First 4 words of content at https://github.com/mono/xsp are "Mono's ASP.NET hosting server". So yeah, you're using ASP.NET. In the same way that working with Mono is using .NET.

Or maybe not. Perhaps someone means to specify that they're using Mono/XSP as opposed to one of Microsoft's implementations. But then it'll probably be obvious from the context.

"pretty uninspired Rails port to C#" - but at least it lets you switch between dynamic and static typing.

Reply on news.ycombinator.com