Why I Moved Away From Microsoft ASP.NET(ryanbennett.com)
ryanbennett.com
Why I Moved Away From Microsoft ASP.NET
http://www.ryanbennett.com/general/why-i-moved-away-from-microsoft-asp-net/
27 comments
This is a well worn path. HN user creates a blog post with minimal substance that has a criticism of Microsoft in the title. Then self posts it to HN.
Click bait, glory hunting.
Click bait, glory hunting.
The only thing I took from this article is that ASP.NET is expensive. The rest could apply to any other platform.
> The vast majority of .NET projects involve working with giant, monolithic, boring, poorly written, legacy “enterprise” products. These products always seem to be 4-8 years old and 2-3 major platform releases behind the current .NET framework
To be fair this can be said for pretty much any project written in pretty much any language or framework.
To be fair this can be said for pretty much any project written in pretty much any language or framework.
Couldn't agree more. If you want to develop in cutting edge technologies for your weeks-old startup then code away and enjoy living on the edge (with all of it's pros and cons). But almost everything else (not just enterprise) lags behind and for good (many) reason(s).
I work for clients and while I'm tempted to offer new technologies, I'm aware that this client will be using this tool for years, most likely as-is. Stability, maintainability and long term investment is many time more important than gee-whiz tech.
I work for clients and while I'm tempted to offer new technologies, I'm aware that this client will be using this tool for years, most likely as-is. Stability, maintainability and long term investment is many time more important than gee-whiz tech.
Stability, maintainability and long term investment is many time more important than gee-whiz tech.
I'll add one more: Googlibility. I don't like to use bleeding edge technology because when I google error messages I get nothing back.
I'll add one more: Googlibility. I don't like to use bleeding edge technology because when I google error messages I get nothing back.
There's a difference between using a brand-new Node.JS framework that's barely out of alpha and using Rails/Django/etc which whilst fairly new are proven to be stable and reliable, and are in use at big organisations.
I agree, however there is no defining line for the non-tech savvy that determines what is bleeding edge, and what isn't. Is Ruby going to be around in 5 years? If Ruby is around, will I be able to hire developers easily and for a reasonable price? These are concerns that drive businesses for whom tech is a necessity but not the core of their business.
So the business owner relies on the tech provider who hopefully isn't in a full on romance with the newest framework/language just because it's new.
So the business owner relies on the tech provider who hopefully isn't in a full on romance with the newest framework/language just because it's new.
Is Ruby going to be around in 5 years?
Ruby (the language) and rails (the web-framework) are not the latest fads to come out. Rails hit 1.0 in 2005, a.k.a. almost 8 years ago, ruby is much older.
Although there can be good reasons to choose something new, I agree with your overall sentiment. But we seem to have extremely different views on what constitutes "new"(node might qualify :)
Ruby (the language) and rails (the web-framework) are not the latest fads to come out. Rails hit 1.0 in 2005, a.k.a. almost 8 years ago, ruby is much older.
Although there can be good reasons to choose something new, I agree with your overall sentiment. But we seem to have extremely different views on what constitutes "new"(node might qualify :)
I wasn't specifically using Ruby as an example of new/unstable tech. My point was that your average business owner doesn't know Ruby from ASP from Perl. It becomes the job of the tech provider to implement technology that not only serves the need now, but also the need years down the road.
So often the line is when the business owner has spent enough money to feel more comfortable with their technology choice.
Re-read what josefresco said - because this is the reality.
"Boring" is pretty safe when it comes to quality and maintainability.
I completely agree with you. One could interpret that line as a "scalable", "proven" and "stable" technology framework.
People should focus on integration between components - the argument between language and frameworks died many years ago.
People should focus on integration between components - the argument between language and frameworks died many years ago.
It's also called job security - there's a lot of old crap to clean up no matter what the language.
I miss C# something rotten. It's such a great language, and I miss being able to use stuff like LINQ every day. But the community just isn't here - everyone is working on huge-scale corporate projects, and comparatively few are working on great stuff like Nancy.fx (a lightweight web MVC framework).
That said, I bought a license for MonoTouch, and I'm hoping that I'll be able to use C# for cool stuff in the future. Just with as little of the ASP.NET stuff as possible.
That said, I bought a license for MonoTouch, and I'm hoping that I'll be able to use C# for cool stuff in the future. Just with as little of the ASP.NET stuff as possible.
this is the same thing in almost any community. You have a handful of people who are dedicated to the open source movement of the language and the reset just sit by the sidelines.
There's nothing wrong with this though. Not everyone has spare time in their lives to dedicate to open source.
There's nothing wrong with this though. Not everyone has spare time in their lives to dedicate to open source.
I think it's different when the language has open source roots. A ton of ASP.NET libraries are paid products, and support for them comes at a premium. You don't see that anywhere near as much in Ruby or Node.
A few years ago, I participated on a interview for a job (in a startup) which requires some skills in ASP.NET.
When I started talking to company owner and I said to him that I knew PHP (and ASP.NET too, of course), he started to say that ASP.NET is better
because it's paid, expensive and it has a great support from Microsoft... That's all he said about it.
Later on, I discovered that almost 7/10 of big companies' IT managers think the same, that's why ASP.NET still has its audience.
The same goes on with Oracle.
They're not wrong, though. It's all about priorities. With an MS product you do get good support, and someone to shout at if something is not behaving as expected. With open source tech you can submit a patch to fix it yourself.
I've always been a little skeptical of the value of commercial support with proprietary development tools relative to community support with established, popular open source development tools. Is the average time between discovering a problem and identifying a good solution shorter? It would be hard to design a good study for this, but every programmer I've talked to with professional experience in both types of environment has told me that paid support was not an advantage for them.
You sometimes get good support. I've spent too much time on the phone to then (as a gold partner) and got sod all back on most occasions. If you're lucky you get a workaround but most of the time it's denial.
Which was exactly the sentiment of my manager in previous org: "You can use open source as long as they have commercial support".
> Why I Moved Away From Microsoft ASP.NET
Because its almost 2014?
Because its almost 2014?
That's the common reason people* move to/away from various technologies.
* under 25
* under 25
And it's one of the top three reasons for people over 25.
While it's fun to make fun of a 25 year's seemingly rash decisions, sometimes those youngsters' rush to embrace a new language or tech actually does move business forward where before it would not have.
Cached version: http://webcache.googleusercontent.com/search?q=cache:http://...
Hmm, a few visitors and Ryan's blog has crashed. What non-Microsoft tools & hosting do you think he used?
It's hosted with Wordpress on Linode so you are correctly spotting a huge dose of irony.
Irony Indeed! Never see traffic like this usually.
I run Wordpress on an Amazon micro instance and have easily handled enormous runs without the server breaking a sweat or failing to serve a request.
http://wordpress.org/plugins/w3-total-cache/
The simplest thing in the world.
http://wordpress.org/plugins/w3-total-cache/
The simplest thing in the world.
It's kinda what I get for running Wordpress on Linode. I'll have to checkout AWS.
X-Powered-By:PHP/5.3.2-1ubuntu4.19
.NET certainly gets the brunt of the "it's not hip" posts. Yea, there's a lotta junk programs, because they make it easy for people to use in an enterprise. There's also a lot of junk java, etc.
That's why you play around on the side with all the new stuff. Using ASP.NET MVC lets you write much leaner html, without the need for all those controls, et al. They're releasing a lot of cool tools if you follow the blogs, and you can now just as easily create a clean bootstrapped page as you would in other offerings.
That's why you play around on the side with all the new stuff. Using ASP.NET MVC lets you write much leaner html, without the need for all those controls, et al. They're releasing a lot of cool tools if you follow the blogs, and you can now just as easily create a clean bootstrapped page as you would in other offerings.
One of the first tasks the new CEO will have when Ballmer leaves is the job of convincing Enterprise customers that Microsoft is still here to fill their needs.
That said, the conclusions the author came to may very well be true for classic "Web Forms" projects, and though he noted MVC... i don't feel like he gave it the proper time it deserves. In fact, I find almost the opposite of his sentiments to be true. MVC is a refined platform, and the .NET framework is a joy to work with (personal opinion). Poorly written frameworks exist in any language, but there's also a lot of GREAT code written in .net too.
The platform is expensive, and that sucks... but we sell the product for 100k a pop... so frankly neither our customers or ourselves care about the cost. Developing quickly, and with the best quality possible is more important.
That said, the conclusions the author came to may very well be true for classic "Web Forms" projects, and though he noted MVC... i don't feel like he gave it the proper time it deserves. In fact, I find almost the opposite of his sentiments to be true. MVC is a refined platform, and the .NET framework is a joy to work with (personal opinion). Poorly written frameworks exist in any language, but there's also a lot of GREAT code written in .net too.
The platform is expensive, and that sucks... but we sell the product for 100k a pop... so frankly neither our customers or ourselves care about the cost. Developing quickly, and with the best quality possible is more important.
One of the first tasks the new CEO will have when Ballmer leaves is the job of convincing Enterprise customers that Microsoft is still here to fill their needs
I don't think that Enterprise customers are the problem- they already use MS all the time. It's the small to medium size companies that aren't using it - and as they become larger companies it will become a problem for MS.
I don't think that Enterprise customers are the problem- they already use MS all the time. It's the small to medium size companies that aren't using it - and as they become larger companies it will become a problem for MS.
> they already use MS all the time
Exactly, we've been the bread and butter for Microsoft for a long time. Yet with Windows 8, we're starting to feel like that's just not true... at least that's the sentiment when I talk to some of my colleagues. For instance We built our main product using WPF, today WPF is all but discontinued. XAML is bigger then ever, but only if you want to make a windows store app.
If I leave .NET it's not going to be because some hipster writes an article about python, and how .NET is written by children writing kludge. I know that's not true. It'll be because Microsoft stopped doing the things that made me keep using them.
Exactly, we've been the bread and butter for Microsoft for a long time. Yet with Windows 8, we're starting to feel like that's just not true... at least that's the sentiment when I talk to some of my colleagues. For instance We built our main product using WPF, today WPF is all but discontinued. XAML is bigger then ever, but only if you want to make a windows store app.
If I leave .NET it's not going to be because some hipster writes an article about python, and how .NET is written by children writing kludge. I know that's not true. It'll be because Microsoft stopped doing the things that made me keep using them.
"today WPF is all but discontinued"
This is an interesting claim - WPF is still the main UI framework for writing Desktop apps, right? I don't know of any replacement framework that is preferred by MS for authoring desktop apps (I never use any WinStore apps on my Windows 8 devices).
This is an interesting claim - WPF is still the main UI framework for writing Desktop apps, right? I don't know of any replacement framework that is preferred by MS for authoring desktop apps (I never use any WinStore apps on my Windows 8 devices).
I went to BUILD in June, and attended an overview of what's new in XAML. After the talk, I went up to the guy, and I was like "Wow there's a lot of cool things going on in XAML, how much of this do we get in WPF?" His reply was basically, all of the visual studio enhancements will come to me. However the new controls etc will not. He said WPF is in maintenance mode only for now.
It seems understandable - they have limited resources and have a lot of work to do on their new WinPhone and WinStore platforms.
So, not a flurry of cutting-edge development, but very much not deprecated either.
So, not a flurry of cutting-edge development, but very much not deprecated either.
There hasn't been a significant upgrade to WPF in years. Microsoft's stance seems to be that "desktop apps" should not be a thing any more - there weren't any WPF sessions at Build, for example.
The last update to WPF was a year ago when .NET 4.5 was released. The current trajectory has major releases about every two years, or whenever there is a major update to .NET itself since it's built-in. Given that Visual Studio itself is now built around many WPF libraries, I don't necessarily see it being deprecated anytime soon (I mean, you can still develop and deploy WinForms-based software even though there aren't any new features on the roadmap). But only time will tell.
Which is why they have BizSpark. They need to do a better job pushing/selling it. And yes, I understand many here on HN get that it's an attempt to lock in the business at a high long term cost for a short term (and I assume many HNers would say marginally small) gain.
EDIT: Was finally able to get the page to load... I see the author alluded to this: "Yes, BizSpark is a great program for giving free Microsoft stuff to startups. It’s like a drug dealer giving free samples to get you hooked on their expensive and now compulsory wares."
EDIT: Was finally able to get the page to load... I see the author alluded to this: "Yes, BizSpark is a great program for giving free Microsoft stuff to startups. It’s like a drug dealer giving free samples to get you hooked on their expensive and now compulsory wares."
If you can even get them to give you the free hit. They seem to have 4 simple requirements met, but I've been turned down for the program even though I'm just a guy developing a single web app product on .NET who started a month ago and have no income yet. I've reapplied but I'm not sure it's worth it. I may end up porting it to Rails or attempting to get it to run on Mono.
While ASP.NET MVC is a huge improvement, my experience in .NET over 12-13 years has shown that most enterprise-class organizations built monolithic Web Forms apps 5-6 years ago. Upgrading these apps - especially to ASP.NET MVC - are cost prohibitive from both a licensing cost perspective and and labor perspective. When work with prospective clients today, it's almost always a situation where A) the client wants to shoehorn their favorite JavaScript MVC framework their WebForms app or B) They have functionality that is part MVC, part WebForms, and they are stuck in a corner. either way, it's always a monster mess that enterprises generally decide costs too much to clean up.
Jeff Atwood talks about moving from .NET to Ruby for Discourse in 'Why Ruby?'
http://www.codinghorror.com/blog/2013/03/why-ruby.html
Boiled down to the licensing of the requirements to run the stack, and the whole open-sourceness of it all.
http://www.codinghorror.com/blog/2013/03/why-ruby.html
Boiled down to the licensing of the requirements to run the stack, and the whole open-sourceness of it all.
I would love to run mono in production, it's just so slow and buggy that this isn't possible.
The simple fact is that server is not a priority for xamarin; mobile is. And this is probably a valid optimization.
BizSpark helps though, as far as licensing issues goes.
The simple fact is that server is not a priority for xamarin; mobile is. And this is probably a valid optimization.
BizSpark helps though, as far as licensing issues goes.
> I would love to run mono in production, it's just so slow and buggy that this isn't possible.
Is that the general opinion? I've never seen a consensus on mono for MVC.
Is that the general opinion? I've never seen a consensus on mono for MVC.
ASP.NET is a great tool. If you were to walk into a gig that has a large amount of apps running VS, IIS and SQL Server, its no way you'd even suggest full blown open source. If things were reversed and all they had was Django, Apache and MySQL then of course you'd be a unwise to suggest moving to ASP.NET. I think as programmers we forget we must constantly use the information presented to make the best decision on which tool to use.
IMHO - Your article should read more like your customer base has changed, thus your tools have changed.
IMHO - Your article should read more like your customer base has changed, thus your tools have changed.
I'm coming from a classic ASP background as well, and jumped straight to MVC (skipping Web Form entirely).
Only later when I did some WPF project, when Web Forms made some sense. I think the whole toolset is basically trying to lure / accommodate the old Win Forms developer to switch to the web (and in this sense, it's a great success).
These days, I'm trying to run even leaner by using ServiceStack.Razor, as most of the stuff I do is service-oriented SPAs.
Only later when I did some WPF project, when Web Forms made some sense. I think the whole toolset is basically trying to lure / accommodate the old Win Forms developer to switch to the web (and in this sense, it's a great success).
These days, I'm trying to run even leaner by using ServiceStack.Razor, as most of the stuff I do is service-oriented SPAs.
> I think the whole (webforms) toolset is basically trying to lure / accommodate the old Win Forms developer to switch to the web
Correct, that was the driver behind webforms. Don't forget that the first version of ASP came out in 1996. Bill Gates' "Internet Tidal Wave" memo was in May 1995.
At the time, Microsoft wanted a way to VB programmers onto the web, and still using familiar, easy tools. And staying inside the Microsoft mothership, of course. ASP grew into ASP.NET Webforms. (.Net 1.0 launched in 2002)
If one was familiar with VB or .Net and winforms, ASP and webforms wasn't too much of a leap. But the abstraction was slow and leaky to work with, and the rendered html contained huge hidden state fields and other oddities. So a new generation of devs who grew up with the web generally greeted it with "WTF!". That's where ASP MVC comes in.
IMHO the wheel has turned far since then; On windows 8, JavaScript is a language for developing desktop apps, so that web developers can try their hand at desktop - the reverse of the situation that Webforms set out to address.
Correct, that was the driver behind webforms. Don't forget that the first version of ASP came out in 1996. Bill Gates' "Internet Tidal Wave" memo was in May 1995.
At the time, Microsoft wanted a way to VB programmers onto the web, and still using familiar, easy tools. And staying inside the Microsoft mothership, of course. ASP grew into ASP.NET Webforms. (.Net 1.0 launched in 2002)
If one was familiar with VB or .Net and winforms, ASP and webforms wasn't too much of a leap. But the abstraction was slow and leaky to work with, and the rendered html contained huge hidden state fields and other oddities. So a new generation of devs who grew up with the web generally greeted it with "WTF!". That's where ASP MVC comes in.
IMHO the wheel has turned far since then; On windows 8, JavaScript is a language for developing desktop apps, so that web developers can try their hand at desktop - the reverse of the situation that Webforms set out to address.
I moved to C# from Java back in 2001 for the RAD projects I had (still using C++ a lot when necessary though.) C# was a great language and it was faster than Java back then. But for the last couple of years all my RAD projects are now in JavaScript and it wouldn't go back.
JavaScript frees me up, where as with C# I feel like I am in a straightjacket where I am forced to write a lot of boilerplate code just to do something quick (a simple Main requires a class to exist!)
JavaScript frees me up, where as with C# I feel like I am in a straightjacket where I am forced to write a lot of boilerplate code just to do something quick (a simple Main requires a class to exist!)
It's the right tool for the right job. C# is second to none for server side work and JavaScript is great for the client side stuff. Node makes it interesting but i'd imagine the [server side] debugging support is a while from being at the level C# offers.
Substitute C# with Java and your statement is correct ;)
i think the "server down" message on your website right now probably speaks as loudly to the topic at hand as any comment here.
More importantly I feel like this story has been told already a hundred times.
Im more compelled by the reasons people either stick with or move to ASP.NET. I would agree that for a great many use cases there are potentially better and less costly tools than this stack, and as a .Net contractor by trade I'm (privately) one of its biggest critics. But big (non-tech) businesses love Microsoft (rightly or wrongly), and as a result, in my local market i can provide for my family a lot better by staying put.
I appreciate the benefits of being at the cutting edge, but I feel there are hidden costs for some that aren't obvious.
More importantly I feel like this story has been told already a hundred times.
Im more compelled by the reasons people either stick with or move to ASP.NET. I would agree that for a great many use cases there are potentially better and less costly tools than this stack, and as a .Net contractor by trade I'm (privately) one of its biggest critics. But big (non-tech) businesses love Microsoft (rightly or wrongly), and as a result, in my local market i can provide for my family a lot better by staying put.
I appreciate the benefits of being at the cutting edge, but I feel there are hidden costs for some that aren't obvious.
Tried reading this but the site was down... ironically. I've been developing the .NET stack for 10 years now and would have to say straight ASP.NET is the easiest way to add the most horrible amount of bloat to your pages and bring about horrible performance.
My gut feel is that it was made to allow application developers to build intranet sites without having to worry about the stateless nature of HTTP. The result was a woeful viewstate that got slugged between the server and client, plus all the woeful bloated libraries that came along with it.
I moved to MVC as soon as it was released and have never looked back. My new project ( www.entomic.com ) is in MVC4 with AngularJS, Coffeescript and Scss and it's absolute gravy. Need to expose some DB objects to the client? Two clicks and I have a full set of REST apis for it. Add to that the LINQ javascript library and the whole thing's a cinch.
My gut feel is that it was made to allow application developers to build intranet sites without having to worry about the stateless nature of HTTP. The result was a woeful viewstate that got slugged between the server and client, plus all the woeful bloated libraries that came along with it.
I moved to MVC as soon as it was released and have never looked back. My new project ( www.entomic.com ) is in MVC4 with AngularJS, Coffeescript and Scss and it's absolute gravy. Need to expose some DB objects to the client? Two clicks and I have a full set of REST apis for it. Add to that the LINQ javascript library and the whole thing's a cinch.
I'm with you. I think it's funny how people put down a technology (ASP.NET) that was released in January of 2002 because it's not up to snuff with 2013 web development tools.
I also made the switch to ASP.NET MVC and can't imagine ever going back to ASP.NET. The unbelievable clean HTML you get, full control over rendering and rapid development is just phenomenal.
Most of the anti-Microsoft comments I see on HN are of the "but VB6 is terrible!" and "ASP.NET stinks!" variety from people that stopped looking at Microsoft development tools over a decade ago and are still comparing those old tools to their modern competitors.
I also made the switch to ASP.NET MVC and can't imagine ever going back to ASP.NET. The unbelievable clean HTML you get, full control over rendering and rapid development is just phenomenal.
Most of the anti-Microsoft comments I see on HN are of the "but VB6 is terrible!" and "ASP.NET stinks!" variety from people that stopped looking at Microsoft development tools over a decade ago and are still comparing those old tools to their modern competitors.
Sorry signed up to say this - been lurking a while but this one infuriated me terribly.
The only reason ASP.Net MVC looks good is because you were a WebForms user before. If you've come from other tech, it's still a stinking pile of crap.
1. The API is totally broken and consists of tonnes of barely testable wrappers (HttpResponseWrapper etc).
2. The attribute model is a pain in the arse. How do you test filters based on attributes effectively?
3. Razor is horrible. I mean really horrible. The semantic difference between inline C# code and JS/HTML is so weak that you end up having to hint the view engine as to what is what. Not only that, the Layout system it uses basically stuffs RAM full of string buffers. If you have a complicated page and thousands of users (like we do), memory goes sky high. Please give me something like Jinja2.
4. The ASP.Net pipeline isn't thread safe at all. It's scary actually. You can't guarantee one module won't set global thread state on another thread. This only happens under heavy load. That is one absolute fucker to debug.
5. MS11-100 broke absolutely fucking everything from downloading Excel files in IE8 and below over SSL, knackering caching etc. This is the norm. Stuff just does this all the time. One day it works, next it doesn't.
Now I could spend all day writing this list but I'll surmise it as the whole .Net (web stack) is a stinking shit crock which pains me every day I have to use it.
I LONG for the days someone will hire me based on other skillsets but the market is saturated with people who thought it was a great idea and are stuck with it now.
(For ref the .net desktop / WPF stuff is wonderful in comparison, apart from Visual Studio which crashes on me so often it's just ugh..).
The only reason ASP.Net MVC looks good is because you were a WebForms user before. If you've come from other tech, it's still a stinking pile of crap.
1. The API is totally broken and consists of tonnes of barely testable wrappers (HttpResponseWrapper etc).
2. The attribute model is a pain in the arse. How do you test filters based on attributes effectively?
3. Razor is horrible. I mean really horrible. The semantic difference between inline C# code and JS/HTML is so weak that you end up having to hint the view engine as to what is what. Not only that, the Layout system it uses basically stuffs RAM full of string buffers. If you have a complicated page and thousands of users (like we do), memory goes sky high. Please give me something like Jinja2.
4. The ASP.Net pipeline isn't thread safe at all. It's scary actually. You can't guarantee one module won't set global thread state on another thread. This only happens under heavy load. That is one absolute fucker to debug.
5. MS11-100 broke absolutely fucking everything from downloading Excel files in IE8 and below over SSL, knackering caching etc. This is the norm. Stuff just does this all the time. One day it works, next it doesn't.
Now I could spend all day writing this list but I'll surmise it as the whole .Net (web stack) is a stinking shit crock which pains me every day I have to use it.
I LONG for the days someone will hire me based on other skillsets but the market is saturated with people who thought it was a great idea and are stuck with it now.
(For ref the .net desktop / WPF stuff is wonderful in comparison, apart from Visual Studio which crashes on me so often it's just ugh..).
I like to think of myself as a polyglot programmer and I can't help but disagree with your statement that ASP.NET MVC only looks good because Webforms is so horrible.
1. I am not sure why you have problems testing the wrapper classes. I can't say I've encountered issues unit testing my controllers or other MVC specific components.
2. You test the attributes themselves as you would test any other class. Eg you test that OnActionExecuting etc yield the correct results. On your controller, you just need to test for the presence of the attribute, since you already know that it works as advertised.
3. I cannot comment on your claim about the Layout system, but I have absolutely no idea what you mean with the 'having to hint the view engine'. You need to tell it which parts are inline code, and those parts should be C#. Razor has no interest in your JavaScript code.
4 and 5, again, can't comment on these since I haven't encountered them, even though I worked on a number of sites that had moments of extreme high load. In addition, I have found that the number of 'stuff that just breaks' is minor compared to what I've seen in other frameworks. Sometimes things go wrong, but it really is not as dire as you portray it.
My 2 cents, YMMV.
1. I am not sure why you have problems testing the wrapper classes. I can't say I've encountered issues unit testing my controllers or other MVC specific components.
2. You test the attributes themselves as you would test any other class. Eg you test that OnActionExecuting etc yield the correct results. On your controller, you just need to test for the presence of the attribute, since you already know that it works as advertised.
3. I cannot comment on your claim about the Layout system, but I have absolutely no idea what you mean with the 'having to hint the view engine'. You need to tell it which parts are inline code, and those parts should be C#. Razor has no interest in your JavaScript code.
4 and 5, again, can't comment on these since I haven't encountered them, even though I worked on a number of sites that had moments of extreme high load. In addition, I have found that the number of 'stuff that just breaks' is minor compared to what I've seen in other frameworks. Sometimes things go wrong, but it really is not as dire as you portray it.
My 2 cents, YMMV.
I much prefer working in .NET MVC4 than I did trying the same pattern in Java with JSP/Servlet/Spring. Things seem to just work.
As for 1, I haven't really had to write tests around these wrappers yet.
I can't really comment on 2 as we don't use but a couple of pretty simple ones that ARE easily testable.
I'm also really not sure what you mean with 3. If by "hint" you mean use @ as your denotation for C# code, then yeah, I guess you do. I also don't see how it's much different from Rails templates, and in fact I think the syntax is far more readable than rails templates (disclosure: I've not used Rails extensively or professionally) and a marked improvement over JSP/ASP Classic.
4. We've got >20k users who access the site multiple times a day and we've not seen anything indicating thread corruption. Not saying you're wrong, but I'm really not entirely sure what you're talking about, perhaps you could elaborate?
5. I can't really comment on this one either, but I can say for a fact that we currently have users downloading excel files over SSL in IE8 and greater.
As for 1, I haven't really had to write tests around these wrappers yet.
I can't really comment on 2 as we don't use but a couple of pretty simple ones that ARE easily testable.
I'm also really not sure what you mean with 3. If by "hint" you mean use @ as your denotation for C# code, then yeah, I guess you do. I also don't see how it's much different from Rails templates, and in fact I think the syntax is far more readable than rails templates (disclosure: I've not used Rails extensively or professionally) and a marked improvement over JSP/ASP Classic.
4. We've got >20k users who access the site multiple times a day and we've not seen anything indicating thread corruption. Not saying you're wrong, but I'm really not entirely sure what you're talking about, perhaps you could elaborate?
5. I can't really comment on this one either, but I can say for a fact that we currently have users downloading excel files over SSL in IE8 and greater.
Maybe you should update your Java skill? Servlet/JSP vs MVC4? Try SpringMVC and JAX-RS.
I've ben going back and forth between Java and C# in the not-so-distant past and I felt that C# ecosystem is just too limited.
I've ben going back and forth between Java and C# in the not-so-distant past and I felt that C# ecosystem is just too limited.
I mentioned Spring. It's been a couple of years, but doesn't Spring's MVC pattern use JSP for the view templates?
JSP is just a tiny part of the whole stack no? You're free to develop single-page app using whatever your choice of JS frameworks.
I believe any Spring view plumbering can process several java-based templating languages (Velocity, JSP, JSF, etc).
You did mentioned Spring but in the same breadth with Servlet+JSP which makes me wonder if you're just using Spring-core and not the more modern stuff.
Keep in mind that there's now "flow" based solution in .NET world. "Flow", while it is not the best choice for the whole presentation stack, has it values for developing wizard-like/shopping cart section of your app.
I believe any Spring view plumbering can process several java-based templating languages (Velocity, JSP, JSF, etc).
You did mentioned Spring but in the same breadth with Servlet+JSP which makes me wonder if you're just using Spring-core and not the more modern stuff.
Keep in mind that there's now "flow" based solution in .NET world. "Flow", while it is not the best choice for the whole presentation stack, has it values for developing wizard-like/shopping cart section of your app.
I think your issues are the reason there are other alternative frameworks that have come out; and there are a lot of them. Use one of the alternative .NET web frameworks if you don't like MVC proper.
I'm not a fan a Razor either. It's code-centric instead of html-centric. Again, use an alternative view engine like Spark. I think a better recommendation is DON'T PUT LOGIC INTO YOUR VIEWS. You will rarely run into issues if you follow that.
Any issues I've found I have also found fixes for relatively easily. If you run into something that is a framework bug that you can't fix, call up MS and they will issue you a patch that fixes the problem you're having. MS has great support, so don't be afraid to use it.
I'm not a fan a Razor either. It's code-centric instead of html-centric. Again, use an alternative view engine like Spark. I think a better recommendation is DON'T PUT LOGIC INTO YOUR VIEWS. You will rarely run into issues if you follow that.
Any issues I've found I have also found fixes for relatively easily. If you run into something that is a framework bug that you can't fix, call up MS and they will issue you a patch that fixes the problem you're having. MS has great support, so don't be afraid to use it.
What extensions are you using with Visual Studio? Found vanilla to be really stable, but certain extensions result in some random crashes. But not terribly often.
None whatsoever. We killed R# and VisualSVN. Do without the former and use TSVN for the latter.
We have 34 projects loaded in the solution so it hits VS's limited 32-bit process restrictions pretty quickly causing the debugger to break miserably. When this fails it's a restart job.
We have 34 projects loaded in the solution so it hits VS's limited 32-bit process restrictions pretty quickly causing the debugger to break miserably. When this fails it's a restart job.
What do you need 34 assemblies for? Seriously?
Our product is very non-trivial! That's just one deployable endpoint. We have 131 projects in total.
some of our application silos are more complicated than other companies entire businesses are. One subsystem has 450,000 LOC in just c# alone and the domain model has 122 classes.
Stuff gets complicated in some sectors...
some of our application silos are more complicated than other companies entire businesses are. One subsystem has 450,000 LOC in just c# alone and the domain model has 122 classes.
Stuff gets complicated in some sectors...
I understand the complexity issue, and how large corps deal with that stuff... There are other ways you can chunk that stuff up though. Maybe you don't have a choice.
I don't think you can fault Visual Studio for not handling that many projects well.
I don't think you can fault Visual Studio for not handling that many projects well.
Agree but we don't have much of a choice. The cost and risk associated with cleaning it up is actually more expensive than leaving it.
Visual Studio would do fine if it was a 64-bit binary. The memory ceiling of 32-bit processes is the problem. People have been calling for 64-bit Visual Studio for a long time.
That is their fault.
Visual Studio would do fine if it was a 64-bit binary. The memory ceiling of 32-bit processes is the problem. People have been calling for 64-bit Visual Studio for a long time.
That is their fault.
Yes, 64 bit would be nice. There are a lot of complexities that go along with that though. No plugins would work. There is a reason that browsers aren't 64 bit and flash will never be updated to 64 bit.
It's possible, just a ton of work, and everyone will have to come along. This was a huge issue with Vista. MS introduces a new way of doing thing, and all the software vendors don't update their drivers to work with it, and now it's MS's fault for having a crappy OS. They will need to make the transition at some point, and the sooner the better IMO.
So I agree with you, but someone on your project should have started refactoring before it got out of hand. Yeah, hindsight is 20/20, and this happens to most projects at corporations. The business doesn't want to pay for something that doesn't make them money. What they never realize is how much money it will save them down the road. One team I was on built in 1/4 of our sprint time dedicated to refactoring things. It was just a part of the business cost so they didn't have to know or worry about it. It worked pretty well for the most part.
It's possible, just a ton of work, and everyone will have to come along. This was a huge issue with Vista. MS introduces a new way of doing thing, and all the software vendors don't update their drivers to work with it, and now it's MS's fault for having a crappy OS. They will need to make the transition at some point, and the sooner the better IMO.
So I agree with you, but someone on your project should have started refactoring before it got out of hand. Yeah, hindsight is 20/20, and this happens to most projects at corporations. The business doesn't want to pay for something that doesn't make them money. What they never realize is how much money it will save them down the road. One team I was on built in 1/4 of our sprint time dedicated to refactoring things. It was just a part of the business cost so they didn't have to know or worry about it. It worked pretty well for the most part.
[deleted]
Ditto on Razor. It's like 2002 php. Except you can't really create reusable partials because of static typing. Sure, you can just make everything dynamic, but then the top of your view turns into:
@{
/* A bunch of repetitive object creation and casting */
}
Object creation and casting in side your views? Maybe you are just putting too much logic in your view. Use interfaces as your model for partial views and reuse becomes a no brainier.
Sorry, signed up to say that you sound like an angry young developer. It sounds like you're angry that you're being "forced" to use a tool you have no idea how to use. I use many different development frameworks and have even used Visual Studio. It's not my main development environment but even I know enough not to load 34 projects into a single solution. Ever hear of compiling some of them and referencing the binaries? What a cluster your code must be.
You assume too much - disappointing. I was in the .NET world for 12-13 years and worked for MS at one point. I was hardly being 'forced' to use it - instead I was regularly brought in to come in and fix / re-architect others' awful messes.
We both know it's not right to load 34 projects into a solution. It's not something I'd ever do, but it's done by many. I saw it commonly in my clients. My last .NET project I took on about 18 months ago, my client had a Classic ASP/2.0/3.5 chimaera with 50+ solutions, each with up to 40 projects in each. DataSets calling SQL Server stored procs for a data layer. The build process took almost an hour.
It's common unfortunately. Big enterprise, old platform, cluster of code. I stopped using .NET because those enterprises have no desire to fix it.
We both know it's not right to load 34 projects into a solution. It's not something I'd ever do, but it's done by many. I saw it commonly in my clients. My last .NET project I took on about 18 months ago, my client had a Classic ASP/2.0/3.5 chimaera with 50+ solutions, each with up to 40 projects in each. DataSets calling SQL Server stored procs for a data layer. The build process took almost an hour.
It's common unfortunately. Big enterprise, old platform, cluster of code. I stopped using .NET because those enterprises have no desire to fix it.
Which is what I'm stuck with (I'm not junior staff either btw - been doing this lark for 26 years). We don't load all the projects at once.
This is actually the debugger failing to load all the symbols into the vshost process because of the memory ceiling being 3.5Gb for 32-bit processes rather than the IDE failing itself. Unfortunately due to poor isolation in VS, it takes out IIS Express and VS IDE.
Release binaries don't blow it but debug ones with pdbs do. This is a shit when your project is large with long dependency chains.
This is actually the debugger failing to load all the symbols into the vshost process because of the memory ceiling being 3.5Gb for 32-bit processes rather than the IDE failing itself. Unfortunately due to poor isolation in VS, it takes out IIS Express and VS IDE.
Release binaries don't blow it but debug ones with pdbs do. This is a shit when your project is large with long dependency chains.
To clarify - I'm not putting down a technology from 2002 per se. I'm putting down the fact that, in my experience, the vast majority of organizations are using that technology originating in 2002. Organizations generally have not seen ROI from the stack that promises "the best TCO" and are leery of upgrading the platform because that break even point has never occurred.
I think it's funny how people put down a technology (ASP.NET) that was released in January of 2002
Because it is still overwhelmingly used today. MS themselves admit that MVC is a tiny proportion of ASP.NET deployments.
Because it is still overwhelmingly used today. MS themselves admit that MVC is a tiny proportion of ASP.NET deployments.
> Tried reading this but the site was down... ironically.
I googled the title and grabbed Google's cache (in text-only form, the real deal wouldn't load for me).
http://webcache.googleusercontent.com/search?q=cache:U8pNBnR...
I googled the title and grabbed Google's cache (in text-only form, the real deal wouldn't load for me).
http://webcache.googleusercontent.com/search?q=cache:U8pNBnR...
For some strange reason that strongly reminds me from Apache Tomcat & Hibernate.
MVC4 with AngularJS
Why combine a server-side MVC with a client-side MVC?
Honestly the ASP.NET MVC advocacy doesn't make sense to me. It is a solution that half brings .NET developers into the modern era. Using it purely as a service layer is that project essentially trying to maintain relevance in the face of irrelevance.
Why combine a server-side MVC with a client-side MVC?
Honestly the ASP.NET MVC advocacy doesn't make sense to me. It is a solution that half brings .NET developers into the modern era. Using it purely as a service layer is that project essentially trying to maintain relevance in the face of irrelevance.
Yep, half-way sounds about right. By default ASP.NET doesn't allow you to GET json, have to override that.
Also the routing is not RESTful at all and doesn't handle nesting very well, so you have to find a 3rd party routing library or role your own.
Also the routing is not RESTful at all and doesn't handle nesting very well, so you have to find a 3rd party routing library or role your own.
The reason it doesn't allow you to do JSON GET requests is because of the possibility of hijacking. http://haacked.com/archive/2009/06/24/json-hijacking.aspx Not allowing this by default is a good thing. It will make developers look up the reason it's not working, and hopefully not return an array from the get request. They could have done a runtime exception only if an array was returned, but that's a matter of opinion.
Why combine? Because the server side infrastructure is a lot more flexible with MVC (than WebForms) and follows how HTML is supposed to work.
If you're developing an API or service, use WebAPI instead. It solves most of the issues people have with MVC. MVC is still simple and easy to use to create services with, and I'd still recommend it to people.
If you're developing an API or service, use WebAPI instead. It solves most of the issues people have with MVC. MVC is still simple and easy to use to create services with, and I'd still recommend it to people.
His thoughts on ASP.NET WebForms are just; it's a piece of crap trying to make websites have state and you should stay away from it as far as possible.
I am a .NET developer like the poster, also been with the framework since the first beta (doing not just web, but also windows development), and I've had my share of frustrations with ASP.NET WebForms as well, but I quickly noticed that I could use Generic handlers (.ashx) to have a stateless experience, unlike the normal pages, which allowed me to add AJAX Handlers that did not suffer all the drawbacks. I just made simple HTML, added my own Ajax Requests (before jQuery) and had a blazing fast web app without all the fake 'state' that ASP.NET WebForms added.
Once MVC came around the corner, you basically get the Generic Hander + a way to properly structure your code. Once the Razor view engine came to be, there was also a way to maintain proper templates.
All in all, ASP.NET MVC has been great; you get all your .NET code for the back end, just HTML5, CSS3 and JavaScript on the front end, and no more fake 'state'.
I am a .NET developer like the poster, also been with the framework since the first beta (doing not just web, but also windows development), and I've had my share of frustrations with ASP.NET WebForms as well, but I quickly noticed that I could use Generic handlers (.ashx) to have a stateless experience, unlike the normal pages, which allowed me to add AJAX Handlers that did not suffer all the drawbacks. I just made simple HTML, added my own Ajax Requests (before jQuery) and had a blazing fast web app without all the fake 'state' that ASP.NET WebForms added.
Once MVC came around the corner, you basically get the Generic Hander + a way to properly structure your code. Once the Razor view engine came to be, there was also a way to maintain proper templates.
All in all, ASP.NET MVC has been great; you get all your .NET code for the back end, just HTML5, CSS3 and JavaScript on the front end, and no more fake 'state'.
Was accessing a very slow HMO site yesterday. Peeked at the source and most of the wait was for the 800K ViewState string. Wasn't that hard to decrypt either. I think that is the source of most anti-ASP.Net sentiment.
The ViewState should be encrypted with the MachineKey[1] of the server and shouldn't allow you to decrypt it if they store sensitive data in it, but at least one control needs to request for the encryption or have the encryption set to always [2]
[1] http://msdn.microsoft.com/en-us/library/w8h3skw9(v=vs.85).as...
[2] http://msdn.microsoft.com/en-us/library/aa479501.aspx
[1] http://msdn.microsoft.com/en-us/library/w8h3skw9(v=vs.85).as...
[2] http://msdn.microsoft.com/en-us/library/aa479501.aspx
The first outsourcing disaster I experienced was view state related. Back in 2003, a membership management app I inherited managed to hang of view state. Each page would throw 2.5Mb across a LAN. It sucked. It also had numerous bad patterns like UI driven SELECT N+1 hell. This is the norm for your average cheap custom build asp.net app.
We rewrote the entire thing in php (nice php!!) in three days and it's still used to this day without modification (even managed to get through a couple of security audits unmodified).
We rewrote the entire thing in php (nice php!!) in three days and it's still used to this day without modification (even managed to get through a couple of security audits unmodified).
Strange post, now when ASP.NET looks better than ever: MVC, WebAPI, ServiceStack, Nancy and all other micro frameworks, SignalR, OWIN/Katana middleware, whole SPA story, decent ORM (EF v5/6), small ORMs like Massive, Dapper, SimpleData ...
Which means that author really doesn't know whats going on in .net web ecosystem, works in big old company that still uses Cobol, or has just have a head stuck in the sand.
Sure, big companies still uses WebForms, but what should they to after investing years and years into developing application? Rewrite everything every few years when some new shinny toy comes out?
Sure, big companies still uses WebForms, but what should they to after investing years and years into developing application? Rewrite everything every few years when some new shinny toy comes out?
While I've been out of the .NET game for a year or so, I'm aware of the ecosystem. There's a lot of great libraries out there, that make the experience considerably better.
Companies on the Microsoft stack tend to be extremely conservative. I hardly ever see anyone using these ORMs - I see LINQ-to-SQL or EF, or just as often, inline SQL using DataSets in codebehinds.
I don't think that companies should immediately jump on the next great technology, however there are plenty of companies sitting around on WebForms based on .NET 2.0 (2005) and .NET 3.5 (2007), and a few still on .NET 1.1 (2003). The only reason these companies have not moved onto ASP.NET MVC (or anything else) is because of the sheer cost of doing so. With that comes all of the negatives discussed in the post.
Companies on the Microsoft stack tend to be extremely conservative. I hardly ever see anyone using these ORMs - I see LINQ-to-SQL or EF, or just as often, inline SQL using DataSets in codebehinds.
I don't think that companies should immediately jump on the next great technology, however there are plenty of companies sitting around on WebForms based on .NET 2.0 (2005) and .NET 3.5 (2007), and a few still on .NET 1.1 (2003). The only reason these companies have not moved onto ASP.NET MVC (or anything else) is because of the sheer cost of doing so. With that comes all of the negatives discussed in the post.
C#, Linq, MVC, Web Api, reasons I still use the platform. I did web forms for a few years and there is no way I would be using it today. Thankfully MVC came around.
The modern Microsoft stack is pretty good. MVC + Razor, Entity Framework + Linq. It compares very well to modern web stacks like rails, or django and then some. And then you get use tools around MSSQL like any business intelligence tools.
The VS MVC templates in vs 2013, come with bootstrap preinstalled which shows the general direction they're going in now.
The VS MVC templates in vs 2013, come with bootstrap preinstalled which shows the general direction they're going in now.
Most of the time the top article goes down. However there is always gooogle cache: http://webcache.googleusercontent.com/search?q=cache:U8pNBnR...
The only decent argument against anything in the Microsoft stack, in my opinion, is the licensing costs. You pretty much need to develop on Windows using Visual Studio. And for ASP.NET you pretty much need to deploy to IIS on Windows Server. Though at scale the OS and MSDN licensing costs can be just a drop in the bucket. That is until you decide to use SQL Server on the backend. It's a great product but the licensing costs can make you go broke. If I started a new product or company and used .NET and needed an relational database I would seriously consider PostgreSQL.
It's a good thing that we can use ORM libraries to implement different database backends ;)
In all seriousness, it really depends on a lot of things. We've pretty much crossed Oracle from the list because it's just way too expensive, but it's mainly the availability of experts and the ecosystem around SQL Server that makes it an 'easy' choice for most shops in my area.
In all seriousness, it really depends on a lot of things. We've pretty much crossed Oracle from the list because it's just way too expensive, but it's mainly the availability of experts and the ecosystem around SQL Server that makes it an 'easy' choice for most shops in my area.
I'm a .NET developer by day, and I'm definitely a fan. C# is a great language, I've worked on many fun projects, and I've even worked in a .NET startup environment. Many of my experiences do not echo that of the author. Perhaps I'm lucky, but a legacy project for me is a project running .NET 2 and an older CMS version, and compared to Java I'd still pick it. I've used .NET in a number of agencies too, and I'd preferred using it to using PHP. We've even taken a number of failed WordPress projects and have taken them over to Umbraco, and the clients couldn't be happier.
That being said, I consciously made a decision a few years ago to force myself to develop with different tools for personal projets. While I think ASP.NET is a great platform, I've worked in enough .NET shops to see that many .NET devs tend to "just" write C#. They're more than happy to dedicate their entire career to Microsoft, and to disregard any progress made on other platforms.
The biggest blocker for me is using Windows to develop applications. I'm also a big fan of Python, but I'd be lying if I said that I haven't struggled with the transition to using Linux to develop. The terminal is just so powerful, and even though Powershell has made Windows a much better platform to script on, I really don't think it can ever match the terminal. Perhaps I'm alone in this, but I would like to be comfortable with the knowledge that if I lost my job, .NET were to stagnate/fall apart, or if I were offered a great job using Python, that I'd be fully capable of putting my .NET hat down and moving into a mid-level role writing Python on a Linux-based environment.
My problem with .NET isn't really a problem. It's a worry that the the Windows platform could alienate me from progress made elsewhere.
That being said, I consciously made a decision a few years ago to force myself to develop with different tools for personal projets. While I think ASP.NET is a great platform, I've worked in enough .NET shops to see that many .NET devs tend to "just" write C#. They're more than happy to dedicate their entire career to Microsoft, and to disregard any progress made on other platforms.
The biggest blocker for me is using Windows to develop applications. I'm also a big fan of Python, but I'd be lying if I said that I haven't struggled with the transition to using Linux to develop. The terminal is just so powerful, and even though Powershell has made Windows a much better platform to script on, I really don't think it can ever match the terminal. Perhaps I'm alone in this, but I would like to be comfortable with the knowledge that if I lost my job, .NET were to stagnate/fall apart, or if I were offered a great job using Python, that I'd be fully capable of putting my .NET hat down and moving into a mid-level role writing Python on a Linux-based environment.
My problem with .NET isn't really a problem. It's a worry that the the Windows platform could alienate me from progress made elsewhere.
ASP.NET MVC is fairly solid but the problem is not so much the framework but having to run on Windows. Managing windows server is a horrible experience compared to Linux. The automation tooling for Linux is just far better.
Managing windows server isn't that horrible if you have a decent grasp of PowerShell. Most people can't be bothered learning how to manage Windows (or Unix) servers properly, much in the same way they don't spend time learning Javascript properly.
I think if you would look around for alternatives for WebForms around the day it came out it was better than most things at the time. Java had a few horrible frameworks as well and PHP was still in it's phase of stuffing markup, database and logic in one ginormous SQL injection friendly file. The thing that was flawed about it that it was meant to work like a desktop app in WinForms style, yet the HTTP protocol isn't stateful so as soon as you would start to nest controls and route clicks, you were up for some pretty messy wiring up during different phases of loading the page.
I had an introductory course of one hour on Microsoft MVC and the next day I created and deployed a small website from scratch with it. I always basically tell people that are still on WebForms that they don't need to learn something new when they switch to MVC, they just need to forget a lot of the crap they needed to know to work on WebForms. Every day still on WebForms is a wasted day.
The writer seems to have moved from strong typed languages to loosely typed languages. It's pretty unclear to me why he quit using Django and went for JavaScript instead, but the path is pretty clear. I used and use a lot of programming languages and frameworks and I pick whatever seems the most appropriate for the job.
- WordPress for dead easy websites only doing basic stuff - PHP/SLIM/MySQL for very simple webservices - Django whenever I want to do a lot of custom views - Microsoft MVC for larger web projects with a lot of business rules
Statically typed code works better in an IDE as it is easier to predict what code will do (this is one of the reasons Visual Studio with ReSharper is so effective in compile time and pre compile time error checking and refactoring).
I am not sure if I want to maintain all those Node.JS / Ruby / flavor of the month frameworks in eight years either.....probably we will curse it by then too.
I had an introductory course of one hour on Microsoft MVC and the next day I created and deployed a small website from scratch with it. I always basically tell people that are still on WebForms that they don't need to learn something new when they switch to MVC, they just need to forget a lot of the crap they needed to know to work on WebForms. Every day still on WebForms is a wasted day.
The writer seems to have moved from strong typed languages to loosely typed languages. It's pretty unclear to me why he quit using Django and went for JavaScript instead, but the path is pretty clear. I used and use a lot of programming languages and frameworks and I pick whatever seems the most appropriate for the job.
- WordPress for dead easy websites only doing basic stuff - PHP/SLIM/MySQL for very simple webservices - Django whenever I want to do a lot of custom views - Microsoft MVC for larger web projects with a lot of business rules
Statically typed code works better in an IDE as it is easier to predict what code will do (this is one of the reasons Visual Studio with ReSharper is so effective in compile time and pre compile time error checking and refactoring).
I am not sure if I want to maintain all those Node.JS / Ruby / flavor of the month frameworks in eight years either.....probably we will curse it by then too.
ASP.NET WebForms was a tragedy of a grand scale. Its bloatedness and obfuscation of the web was truly horrific.
I can say this because I am a WebForm veteran.
I used it from beta in my 2nd job & even back then I found it incredibly obtuse and uninuitive, especially because I understood the stateless nature of the web and it just kinda flew in the face of that ( probably to appease VB programmers coming to the web ).
Like many people, I was also looking to get rid of all the bloat, fortunately now ASP.NET MVC and WebAPI are proper development solutions that play nicely with the web.
In fact there's alot to admire about the new ASP.NET and how it embraces the web.
My web latest app stack is now a Single Page App of HTML/CSS/JS talking to Restful Services (ASP.NET Web API), just beautiful to work with!
Like many people, I was also looking to get rid of all the bloat, fortunately now ASP.NET MVC and WebAPI are proper development solutions that play nicely with the web.
In fact there's alot to admire about the new ASP.NET and how it embraces the web.
My web latest app stack is now a Single Page App of HTML/CSS/JS talking to Restful Services (ASP.NET Web API), just beautiful to work with!
ASP.NET is a decade+ old technology. It made lots of sense when it came out (state management across postbacks, flexible caching, full base class library, completely extensible object model). combined with early ajax frameworks, we did some great things with it back then (like in browser live stock trading apps before GMail was out) with relative ease..
now there are lots of alternatives.. this is equivalent to writing a post about "why i got off windows 98"..
now there are lots of alternatives.. this is equivalent to writing a post about "why i got off windows 98"..
http://www.hanselman.com/blog/VisualStudio2013RCForWebDevelo...