Will ASP.NET MVC ever go away?

[Zenith]

I liked classic ASP. I tolerated webforms because I could work around its deficiencies. I can't make heads or tails of anything written in MVC.

It seems to take the "worst" aspect of classic ASP ("oh me, oh my, code in my tags, so confusing"), combine it with heavy dependence on JavaScript, and set it adrift in a model where there's no link between folders/files in the browser and folders/files on the server.

When people say it's so much easier to test, what are they testing? I've never seen anybody test the MVC apps that I've been exposed to. In the classical model, you could unit test the DLL functions and click through some of the UI. How do you even start automated testing of something so tied to the front-end? Same goes for webforms if you were relying on the event model to do everything. My suspicion is that many apps are so devoid of features these days because it really is harder to add or test them under this model.

I posted this in the trolleybus garage because MVC is practically suffocating everything else so odds are high that criticism of it could trigger an explosion...

[boomzilla]

@Zenith said in Will ASP.NET MVC ever go away?:

I posted this in the trolleybus garage because MVC is practically suffocating everything else so odds are high that criticism of it could trigger an explosion...

Sorry, this is too sidebar to stay in the garage.

[MrL]

@Zenith said in Will ASP.NET MVC ever go away?:

When people say it's so much easier to test, what are they testing? I've never seen anybody test the MVC apps that I've been exposed to. In the classical model, you could unit test the DLL functions and click through some of the UI. How do you even start automated testing of something so tied to the front-end? Same goes for webforms if you were relying on the event model to do everything. My suspicion is that many apps are so devoid of features these days because it really is harder to add or test them under this model.

You can just call the controller methods from tests.

[MrL]

And besides, I don't really care about mvc being 'more testable'. For me it's a lot easier to write in. It's web environment - request, response. It doesn't try to pretend it's desktop and as a result doesn't have that sick abomination known as 'page life cycle'.

[Groaner]

@Zenith said in Will ASP.NET MVC ever go away?:

When people say it's so much easier to test, what are they testing? I've never seen anybody test the MVC apps that I've been exposed to.

Shh, not so loud. Can't tarnish the Emperor's new birthday suit even though this industry has always been about rushing out a good-enough release and rarely, if ever, about testing things.

[Groaner]

@MrL said in Will ASP.NET MVC ever go away?:

And besides, I don't really care about mvc being 'more testable'. For me it's a lot easier to write in. It's web environment - request, response. It doesn't try to pretend it's desktop and as a result doesn't have that sick abomination known as 'page life cycle'.

What's so bad about it? Init comes before Load, and containers before their contents. The only part where it gets tricky is dynamically adding controls during a callback.

Any non-trivial application requires state and HTTP is stateless, so that state has to be built on top one way or another.

[MrL]

@Groaner said in Will ASP.NET MVC ever go away?:

@MrL said in Will ASP.NET MVC ever go away?:

And besides, I don't really care about mvc being 'more testable'. For me it's a lot easier to write in. It's web environment - request, response. It doesn't try to pretend it's desktop and as a result doesn't have that sick abomination known as 'page life cycle'.

What's so bad about it? Init comes before Load, and containers before their contents. The only part where it gets tricky is dynamically adding controls during a callback.

OnPreInit, OnInitComplete, OnPreLoad, OnLoad, OnLoadComplete, OnPreRender, OnPreRenderComplete, OnUnload, plus friends. I still have nightmares.

Any non-trivial application requires state and HTTP is stateless, so that state has to be built on top one way or another.

State is ok. In mvc you get it whole from the beginning of controller method. In asp it's chopped to pieces, which are tossed to different places. Like a trans hooker after unfortunate visit to our friend's basement.

[Unperverted Vixen]

@Zenith said in Will ASP.NET MVC ever go away?:

I liked classic ASP. I tolerated webforms because I could work around its deficiencies. I can't make heads or tails of anything written in MVC.

It seems to take the "worst" aspect of classic ASP ("oh me, oh my, code in my tags, so confusing"), combine it with heavy dependence on JavaScript, and set it adrift in a model where there's no link between folders/files in the browser and folders/files on the server.

Note that Web Forms wasn't free of code-in-tags either! ASP.NET Core Tag Helpers get rid of most of that. About the only thing code should be used for now is simple if/else statements (e.g., show/hide this section based on model data).

ASP.NET MVC (in any of its flavors) has no dependence on JavaScript. However, it's a lot easier to use MVC as a JavaScript datasource than it is to use Web Forms, so a site heavily using JavaScript made picking MVC a no-brainer.

Personally I like that there's no link between the URL and folders/files on the server; but if you really want that link, Microsoft reintroduced it in ASP.NET Core 2.2 with Razor Pages.

[Zenith]

@Groaner The way web apps try to pretend they're desktop apps, I don't understand the pushback against the way Microsoft realized it with the page lifecycle. From a functional standpoint, though, the constant round trips full of viewstate noise were an endless stream of problems. If you didn't wind up there, you had an app that was trivial to do without webforms altogether. Catch-22 really.

What I don't understand is why MVC is the only way now. I can do a classic ASP (or PHP) app that does everything through requests and responses. I don't see the benefit of hiding code behind controllers hidden behind internal routing tables. It's completely backwards from the established page model where the starting point is obvious. Is the Windows version as weird? No classes deriving from CWnd/Form, just some black box router linking together XAML snippets?

FWIW, I couldn't get a handle on ServiceBus either for lack of a Main() entry point.

[_P_]

It seems to take the "worst" aspect of classic ASP ("oh me, oh my, code in my tags, so confusing"), combine it with heavy dependence on JavaScript

Web pages at 201x require JS, news at 11.

and set it adrift in a model where there's no link between folders/files in the browser and folders/files on the server.

@Zenith said in Will ASP.NET MVC ever go away?:

I can do a classic ASP (or PHP) app that does everything through requests and responses. I don't see the benefit of hiding code behind controllers hidden behind internal routing tables. It's completely backwards from the established page model where the starting point is obvious.

Web URL is not file system path, and it does/should not have to correspond to a file system model. Are you living in the 80s or something?

If anything this is an improvement to the file system model: now you can have a more flexible, descriptive, memorable and user-friendly URL (why should I care and memorize .aspx, .htm or whatever?). Now it can be more memorable (think of gyfcat or something). It sounds like you're claiming versatility is bad.

When people say it's so much easier to test, what are they testing? I've never seen anybody test the MVC apps that I've been exposed to. In the classical model, you could unit test the DLL functions and click through some of the UI. How do you even start automated testing of something so tied to the front-end?

Actual, Real, Scientific client-back end interaction, with something like Selenium? "Unit test the DLL functions and click through some of the UI" is not unit testing; what you've done is you're pretending you've done unit tests. And why should anyone click through UI manually? Do you have any idea how big applications can be and how many function flows can exist? Even mobile apps can be very big. Should we assign you as the dedicated manual UI tester? Or would you like to do test automaton? I hope you're not suggesting us to use AutoHotKey for this purpose!

You can't really claim you've done integration tests on your app if you're just calling the methods, just like you can't say you've tested a vending machine by running some internal circuit thingy. And how do you test your client-side JS this way? Again, that's signs showing you're living in the 80s.

@MrL said in Will ASP.NET MVC ever go away?:

You can just call the controller methods from tests.

No, no, no. This messes up with the ControllerContext and the entire OWIN pipeline if you're using something like OpenID integration to allow logging in through third-party services like GitHub. And then it's only uphill from there. And then you'll hit a big brick wall known as HttpContext, and several more afterwards. It's not as easy as you might think, period.

Unit-testing for user-interfacing and interaction apps, especially web apps, is unrealistic and does not represent how it is actually used. So don't unit test things that can't be unit tested, and use something sensible like Selenium here. Instead you should really only unit test pure back-end stuff, like database operations and permission control (aka things that don't involve front-end and rendering).

One very good thing about MVC is that you can explicitly control which view to render, and the page front-end aka presentation is decoupled from your back-end code for the most part (so you can do something like, I dunno, dump the data out in a test view?). With ASP (and MVVM too?) your presentation is tightly coupled to your code, and it's a pain in the butt to switch views.

@Groaner said in Will ASP.NET MVC ever go away?:

Any non-trivial application requires state and HTTP is stateless, so that state has to be built on top one way or another.

This. You wouldn't believe how much state the server has too keep nowadays. Or you can keep everything in cookies client-side, but that's a Very Bad Idea, and would be utterly unacceptable security-wise nowadays. I hope @Zenith wouldn't suggest us to store plaintext passwords in database because "we can recover forgotten passwords that way" either!

[Zenith]

@_P_ said in Will ASP.NET MVC ever go away?:

It seems to take the "worst" aspect of classic ASP ("oh me, oh my, code in my tags, so confusing"), combine it with heavy dependence on JavaScript

Web pages at 201x require JS, news at 11.

I said "heavy dependence." The last MVC app I was paid to support had 49% of its code in JavaScript (with another 49% in SQL). The client-side templating was disgusting, like Smarty on steroids. Just loved every field in the database being text because JavaScript typing is such unadulterated diarrhea.

@_P_ said in Will ASP.NET MVC ever go away?:

Web URL is not file system path, and it does/should not have to correspond to a file system model. Are you living in the 80s or something?

I wish! The 1980s were great.

@_P_ said in Will ASP.NET MVC ever go away?:

If anything this is an improvement to the file system model: now you can have a more flexible, descriptive, memorable and user-friendly URL (why should I care and memorize .aspx, .htm or whatever?). Now it can be more memorable (think of gyfcat or something). It sounds like you're claiming versatility is bad.

It sounds like you're saying you can't name your directories flexibly, descriptively, or memorably. It also sounds like you're afraid of file extensions for some reason. Come on, there are like six of them in use for webpages. Nothing's stopping you from removing them and setting up a handler to funnel them through the ASP/PHP module.

I'd prefer having somebody e-mail a browser screenshot (ye olde photograph of a printout on a wooden table) and knowing exactly where to go and fix the issue quickly over having to search through the rats nest of useless boilerplate files strewn all across TFS.

@_P_ said in Will ASP.NET MVC ever go away?:

Actual, Real, Scientific client-back end interaction, with something like Selenium?

Isn't Selenium just simulating clicks all over the UI?

@_P_ said in Will ASP.NET MVC ever go away?:

"Unit test the DLL functions and click through some of the UI" is not unit testing; what you've done is you're pretending you've done unit tests.

No, it's literally the definition of unit testing. It's not as useful on megabytes of minified JavaScript spaghetti but that doesn't mean calling functions and testing the output isn't unit testing.

@_P_ said in Will ASP.NET MVC ever go away?:

And why should anyone click through UI manually?

One, I asked how you even test a UI. Two, Indians paid per user click bring this activity close to violating the Geneva conventions on torture but they made their bed so they can lie in it now. Three, it's a major failure for your app to be such a wreck that you have to test the entire UI on every deployment.

@_P_ said in Will ASP.NET MVC ever go away?:

Do you have any idea how big applications can be and how many function flows can exist? Even mobile apps can be very big. Should we assign you as the dedicated manual UI tester? Or would you like to do test automaton? I hope you're not suggesting us to use AutoHotKey for this purpose!

Sometimes they're big because you're disorganized and stuffing the codebase with copy pasta and boilerplate you'll never use. Jesus Christ, if I had a nickel for every interface that had exactly one implementer, I could buy my own island. It's easy to slap on a band-aid like CA Squared or whatever but it's never a substitute for proper design.

@_P_ said in Will ASP.NET MVC ever go away?:

With ASP (and MVVM too?) your presentation is tightly coupled to your code, and it's a pain in the butt to switch views.

This is just all over the place. One, putting your logic in JavaScript is tightly coupling code to the presentation (HTML browsers). Two, there's nothing in classic ASP or PHP preventing you from putting the real logic code in a DLL/include and just using the UI to feed it. Three, this is exactly what I said about useless boilerplate. Almost nobody changes/reuses views any more than they inherit multiple classes from an interface or support more than one database type.

@_P_ said in Will ASP.NET MVC ever go away?:

I hope @Zenith wouldn't suggest us to store plaintext passwords in database because "we can recover forgotten passwords that way" either!

Fuck you. I'd never work for Facebook.

[Dragoon]

@_P_ said in Will ASP.NET MVC ever go away?:

MVVM

I have only used MVVM with C# and XAML, but it can be pretty decoupled and switching views was in general not that bad.

[_P_]

@Zenith said in Will ASP.NET MVC ever go away?:

Just loved every field in the database being text because JavaScript typing is such unadulterated diarrhea.

How does that relate to the discussion? You should've instead opened your post with this, then perhaps we'll all have a better day in the end.

It sounds like you're saying you can't name your directories flexibly, descriptively, or memorably. It also sounds like you're afraid of file extensions for some reason. Come on, there are like six of them in use for webpages. Nothing's stopping you from removing them and setting up a handler to funnel them through the ASP/PHP module.

I didn't say you can't, but setting it up correctly and without security vulnerabilities is hard. I'd love to listen to how you reproduce the URL of this post on discourse in ASP/PHP: https://what.thedailywtf.com/topic/:topic_id/:topic_title_slug/:optional_post_number.

Also do you have any idea how typical users work? Why'd you want users to suffer through the intelligible Tr0ub4dor when they can have something nice like correcthorsebatterystaple? Do you really expect we should interface with all those viewthread.php?topicID=shit&page=2 or whatever? What are you, a haxx0r?

I'd prefer having somebody e-mail a browser screenshot (ye olde photograph of a printout on a wooden table) and knowing exactly where to go and fix the issue quickly over having to search through the rats nest of useless boilerplate files strewn all across TFS.

That's more of a lack of logging more than anything.

No, it's literally the definition of unit testing. It's not as useful on megabytes of minified JavaScript spaghetti but that doesn't mean calling functions and testing the output isn't unit testing.

You're not addressing my question at all. Where are you doing your UI tests? Do you even test your UI besides doing it manually? By the definition of unit tests, you're not testing the right thing (calling DLL functions is far away from how the app is actually used) and your test coverage is low (because you don't test your UI in your automated tests).

Isn't Selenium just simulating clicks all over the UI?

No, it can also read, traverse and interact with the UI and its elements inside the code if you have the correct drivers. "Simulating clicks all over the UI" is more of an AutoHotKey thing, which you definitely sound like one of them.

Also it's still infinitely better than doing it manually, you know right?

@Zenith said in Will ASP.NET MVC ever go away?:

One, I asked how you even test a UI. Two, Indians paid per user click bring this activity close to violating the Geneva conventions on torture but they made their bed so they can lie in it now. Three, it's a major failure for your app to be such a wreck that you have to test the entire UI on every deployment.

1. Selenium? It sounds like you're just denying the fact that Selenium is an UI testing tool. Should I also deny the fact that JS is a programming language, and claim that it's a "scripting language that simulating programmings all over the CPU"?
2. Automated UI tests run much faster than your indians, practically cost no money, and can be distributed to as many CI servers as I wanted. It's especially useful for mobile apps where you need to test all the function flows in the same app in 20 android versions in 100 models that the app has to support. Now tell you you're going to hire 2000 indians to do this for you? Oh, and don't even mention stress tests (does the app leak memory after doing the same action thousands of times?). I've heard that Japanese QA teams does this a lot. Are you going to tell the Indians to do this for you?
3. What? So you're saying you don't run your tests on every deployment? Do you even CI, or unit tests? Alternatively, why are you writing such a wreck of a codebase, that you have to test the code on every deployment? Actually, you shouldn't write any tests, everyone knows that the haxxor chads in the 60s don't need no stinking tests, and their code always compile successful and run without bugs first try! Git gud scrub what a wimp

@Zenith said in Will ASP.NET MVC ever go away?:

Sometimes they're big because you're disorganized and stuffing the codebase with copy pasta and boilerplate you'll never use

What about the other times? Are you just going to pretend they don't exist?

@Zenith said in Will ASP.NET MVC ever go away?:

One, putting your logic in JavaScript is tightly coupling code to the presentation (HTML browsers). Two, there's nothing in classic ASP or PHP preventing you from putting the real logic code in a DLL/include and just using the UI to feed it. Three, this is exactly what I said about useless boilerplate. Almost nobody changes/reuses views any more than they inherit multiple classes from an interface or support more than one database type.

1. Guess what, client-side code is part of the presentation, just like CSS. That is, unless you define presentation as strictly pure HTML browsers without JS, but by that definition pretty much every site will break on you. Try noscripting this site entirely and see how Discourse breaks! How refreshing it is to live in the 80s where the internet barely works!
2. Why are you putting code intended for client-side in server-side? Now you're coupling client-code code to server-side code, and it's even worse. TDWTF has no lack of such horror.
3. Nobody's responsible for your horrible use of views, and your horrible use of views does not mean views are horrible in general. View (and especially partial views) are very frequently reused, especially in mobile apps.

@Zenith said in Will ASP.NET MVC ever go away?:

Fuck you. I'd never work for Facebook.

Open your eyes, sheeple.

[Groaner]

@MrL said in Will ASP.NET MVC ever go away?:

OnPreInit, OnInitComplete, OnPreLoad, OnLoad, OnLoadComplete, OnPreRender, OnPreRenderComplete, OnUnload, plus friends. I still have nightmares.

Even if 95% of the time, you only need to use OnInit/Page_Init, OnLoad/Page_Load and OnDataBind/Bound? That those events exist doesn't mean the developer is forced to use them all.

And if you're using Telerik/DevExpress controls, then you get extra ones like OnHtmlRowPrepared and OnRenderBrick. In spite of all this complexity, those of us on such a stack are somehow able to get by.

State is ok. In mvc you get it whole from the beginning of controller method. In asp it's chopped to pieces, which are tossed to different places. Like a trans hooker after unfortunate visit to our friend's basement.

Separation of concerns. Code that executes in response to a specific button click doesn't necessarily need to be aware of the rest of the system. Same deal with code that passes parameter values to a data source before databinding.

[TimeBandit]

@_P_ said in Will ASP.NET MVC ever go away?:

do you have any idea how typical users work?

They don't

[Groaner]

@Zenith said in Will ASP.NET MVC ever go away?:

@Groaner The way web apps try to pretend they're desktop apps, I don't understand the pushback against the way Microsoft realized it with the page lifecycle. From a functional standpoint, though, the constant round trips full of viewstate noise were an endless stream of problems. If you didn't wind up there, you had an app that was trivial to do without webforms altogether. Catch-22 really.

Compare Webforms to Winforms and you'll notice a lot of similarities. I very much like having individual button click events as opposed to the old message pump method where all messages have to be processed and dispatched, which seems like a good analogy to funneling all UI code through a whole request/response.

And it's always possible to disable viewstate if viewstate is a bottleneck, but that's akin to implementing reliable UDP in lieu of using TCP. I have yet in my career to encounter a problem where viewstate was causing problems. For 99% of cases, it seems like the usual FUD that a SQL database is too slow for production use, so everyone should use a NoSQL store instead.

What I don't understand is why MVC is the only way now.

It is? I thought a couple years ago, Microsoft capitulated and said ASP.NET is comprised of Webforms, MVC and everything under the umbrella?

[Groaner]

@Zenith said in Will ASP.NET MVC ever go away?:

Fuck you. I'd never work for Facebook.

They sure like pumping out ads about what it's like to work there. I'm not really sold on it, or seeing much gain apart from the salary bump, which would quickly be consumed by $4000/month SF Bay Area rent. In exchange, I'd get to work on a webapp where people virtue-signal and get angry at each other all day? No thanks, @morbiuswilters' gig as a UAV missile programmer/pilot sounds more palatable.

[Groaner]

@_P_ said in Will ASP.NET MVC ever go away?:

Open your eyes, sheeple.

That reminds me, I'm getting annoyed with this new "integration" fad wherein you're forced to give your credentials to some other site so webapp A can dataminecollect your relevant information from webapp B. When I was closing the house last year, the mortgage processor insisted on hooking up with my bank account login (necessitating a password change after the process was complete).

Now, in their defense, closing a house usually entails the borrower stripping down to prove s/he's not a deadbeat, but this idea has spread. I'm looking at you, Blooom. I would love your advice on my 401k, but I don't trust you with the password to it.

[uschwarz]

@MrL said in Will ASP.NET MVC ever go away?:

OnPreInit, OnInitComplete, OnPreLoad, OnLoad, OnLoadComplete, OnPreRender, OnPreRenderComplete, OnUnload, plus friends. I still have nightmares.

systemd, is that you?

[Zerosquare]

@_P_ said in Will ASP.NET MVC ever go away?:

Also do you have any idea how typical users work? Why'd you want users to suffer through the intelligible Tr0ub4dor when they can have something nice like correcthorsebatterystaple? Do you really expect we should interface with all those viewthread.php?topicID=shit&page=2 or whatever? What are you, a haxx0r?

Typical users don't read URLs, and don't interact with them. They type the name of the site they want to go in the search box. To share a link, they click on the "Share on Facebook" button. And they will happily enter their login credentials even if the URL is http://facebook-google-apple-microsoft.scams-r-us.ru/

Nice URLs are... nice, sure, but definitely not a priority for non-technical users.

[Zenith]

@_P_ said in Will ASP.NET MVC ever go away?:

Also do you have any idea how typical users work? Why'd you want users to suffer through the intelligible Tr0ub4dor when they can have something nice like correcthorsebatterystaple? Do you really expect we should interface with all those viewthread.php?topicID=shit&page=2 or whatever? What are you, a haxx0r?

I do know they work. If they want to refer to a message board post, they save a bookmark. Many programs parse a URL as a clickable link and, if not, they cut and paste it into the URL bar. Ain't nobody got URLs past the domain name memorized and, on mobile, ain't nobody got the patience the type out something like "https://what.thedailywtf.com/topic/:topic_id/:topic_title_slug/:optional_post_number" and that's when they don't just go to Google or another search engine.

And seriously, how is your example with the topic ID presented as a directory any easier to remember than the topic ID as a parameter? You still have to remember an auto-incremented integer. Only now, instead of in a named parameter that's always after the extension, you have to guess where in the path it goes.

@_P_ said in Will ASP.NET MVC ever go away?:

That's more of a lack of logging more than anything.

How is that related at all? Does the logging tell me the path in TFS?

@_P_ said in Will ASP.NET MVC ever go away?:

Guess what, client-side code is part of the presentation, just like CSS. That is, unless you define presentation as strictly pure HTML browsers without JS, but by that definition pretty much every site will break on you. Try noscripting this site entirely and see how Discourse breaks! How refreshing it is to live in the 80s where the internet barely works!

Didn't you just complain about mixing code with presentation? How do you determine what sort of code mixing is clean and unclean?

@_P_ said in Will ASP.NET MVC ever go away?:

Why are you putting code intended for client-side in server-side? Now you're coupling client-code code to server-side code, and it's even worse. TDWTF has no lack of such horror.

Who said I was? I put basic validation in JavaScript, primarily to save a round trip. Then the server side looks like this:

Integer_1 = convert(garbage_HTML_everything_is_a_string_1);
Integer_N = convert(garbage_HTML_everything_is_a_string_N);
if (DLL.function_with_actual_validation(Integer_1, Integer_N, custom_stack_trace) == false)
{
  print(custom_stack_trace);
}
else
{
  redirect();
}

So tightly coupled! Because I called a DLL from the aspx file? And the phase inducer had its polarity reversed by a barion sweep...

@_P_ said in Will ASP.NET MVC ever go away?:

Nobody's responsible for your horrible use of views, and your horrible use of views does not mean views are horrible in general. View (and especially partial views) are very frequently reused, especially in mobile apps.

Does that mean that nobody misuses views? That's ironic after your "open your eyes, sheeple" link.

[Zenith]

@Groaner said in Will ASP.NET MVC ever go away?:

Compare Webforms to Winforms and you'll notice a lot of similarities. I very much like having individual button click events as opposed to the old message pump method where all messages have to be processed and dispatched, which seems like a good analogy to funneling all UI code through a whole request/response.

I like the message pump approach for web apps. When you aren't doing a postback for every single click, key press, or focus change, the number of message types to process is really small. That's the trap webforms people often fall into, forgetting that these events all require a round trip. It's the other extreme from doing all of your complex logic and validation in barely-typed client-side JavaScript.

@Groaner said in Will ASP.NET MVC ever go away?:

And it's always possible to disable viewstate if viewstate is a bottleneck, but that's akin to implementing reliable UDP in lieu of using TCP. I have yet in my career to encounter a problem where viewstate was causing problems. For 99% of cases, it seems like the usual FUD that a SQL database is too slow for production use, so everyone should use a NoSQL store instead.

Here's one. I once worked for a micromanager that wanted 10+ mostly unrelated tables on the same page, 9+ hidden behind tabs at any given time, and demanded all events handled server side. Every filter or sort forced a postback that carried megabytes of data in the viewstate. Then she cried that it was so slow to use. The same page using JavaScript and XSLT to filter and sort is slow once (because it's loading 10+ fucking recordsets). But then by the time you're doing that, you've already bypassed the datagrid control completely.

@Groaner said in Will ASP.NET MVC ever go away?:

It is? I thought a couple years ago, Microsoft capitulated and said ASP.NET is comprised of Webforms, MVC and everything under the umbrella?

Judging by every job posting demanding MVC and only MVC (plus 60 "indispensable" JavaScript libraries), yes. If you interview with some of these fools, they're convinced everything else is going away tomorrow. They're churning out cookie cutter garbage because what can't be shoehorned into the model can't be done at all in their view. Absolutely wonderful situation when they're porting a non-MVC app for the sake of porting it and years later have something that does a third as much with triple the resources. Users just love spending more effort to do less work while being beat over the head to do more with less.

[MrL]

@Groaner said in Will ASP.NET MVC ever go away?:

Even if 95% of the time, you only need to use OnInit/Page_Init, OnLoad/Page_Load and OnDataBind/Bound?

What do you mean by 'only'? It's complexity for complexity sake.

That those events exist doesn't mean the developer is forced to use them all.

Depends on what you do. I was.

In spite of all this complexity, those of us on such a stack are somehow able to get by.

Sure, I survived too. Meaning not literally died. But I got away from it as soon as I could.

Separation of concerns. Code that executes in response to a specific button click doesn't necessarily need to be aware of the rest of the system.

But when it needs, you're fucked. Instead of just accessing data you need, you have to move parts of your code to different handlers. Do it multiple times, for different user actions, and you end up with unholy mess, code dealing with every thing is everywhere.

@_P_ said in Will ASP.NET MVC ever go away?:

No, no, no.

Yes.

This messes up with the ControllerContext and the entire OWIN pipeline

We don't use OWIN.

if you're using something like OpenID integration to allow logging in through third-party services like GitHub.

We don't.

And then you'll hit a big brick wall known as HttpContext, and several more afterwards. It's not as easy as you might think, period.

Faking HttpContext is literally one line of code in our tests. No further problems.

Unit-testing for user-interfacing and interaction apps, especially web apps, is unrealistic and does not represent how it is actually used. So don't unit test things that can't be unit tested, and use something sensible like Selenium here.

Automated UI testing doesn't work for us. Tried it, ditched it. Human testers however, work very well.
Besides, we don't deal with UI at all (and thank gods for that), our controllers have to return data according to specs and this is what we care about. UI is done by other team.

[Groaner]

@Zenith said in Will ASP.NET MVC ever go away?:

I like the message pump approach for web apps. When you aren't doing a postback for every single click, key press, or focus change, the number of message types to process is really small. That's the trap webforms people often fall into, forgetting that these events all require a round trip. It's the other extreme from doing all of your complex logic and validation in barely-typed client-side JavaScript.

A roundtrip is mandatory, a full-page postback is not. This is why asp:UpdatePanel and AJAX exist. Telerik, DevExpress et al. have controls that even encapsulate most of it for you, so you have searchable, sortable gridviews with no postbacks.

Here's one. I once worked for a micromanager that wanted 10+ mostly unrelated tables on the same page

Ah, the "dashboard."

9+ hidden behind tabs at any given time

When was this? Sounds like a great opportunity to put each into an UpdatePanel.

and demanded all events handled server side.

What does that mean - no callbacks? No Javascript? I can think of many ways to interpret that "requirement."

Every filter or sort forced a postback that carried megabytes of data in the viewstate.

Any decent third-party gridview control should not postback under those conditions. Such controls have been on the market since at least 2008.

Then she cried that it was so slow to use.

"Well, you said you wanted everything handled on the server and dictated the implementation I was permitted to use. We can make this faster, but it entails relaxing your requirements."

The same page using JavaScript and XSLT to filter and sort is slow once (because it's loading 10+ fucking recordsets). But then by the time you're doing that, you've already bypassed the datagrid control completely.

Again, when was this? XSLT is making me think circa 2005, in which case you'd have an excuse.

Judging by every job posting demanding MVC and only MVC (plus 60 "indispensable" JavaScript libraries), yes. If you interview with some of these fools, they're convinced everything else is going away tomorrow.

The industry has been full of fad-chasing idiots for at least the span of my entire career, and perhaps longer than my lifetime. I don't see this changing anytime soon, particularly since the herd thinks things like Javascript and GitHub are quality items.

They're churning out cookie cutter garbage because what can't be shoehorned into the model can't be done at all in their view. Absolutely wonderful situation when they're porting a non-MVC app for the sake of porting it and years later have something that does a third as much with triple the resources. Users just love spending more effort to do less work while being beat over the head to do more with less.

It's not entirely a loss. Just think of how much material is being generated for this site!

[Groaner]

@MrL said in Will ASP.NET MVC ever go away?:

What do you mean by 'only'? It's complexity for complexity sake.

I'd rather have events I rarely need than not have them and have to go far out of my way (and outside of the API designer's intentions) to make them happen.

Depends on what you do. I was.

Then you have my sympathies for having to deal with pages doing things much more complex than binding to some data source and allowing CRUD over said data.

Sure, I survived too. Meaning not literally died. But I got away from it as soon as I could.

Whatever floats your boat.

But when it needs, you're fucked. Instead of just accessing data you need, you have to move parts of your code to different handlers. Do it multiple times, for different user actions, and you end up with unholy mess, code dealing with every thing is everywhere.

Complexity of the codebase generally reflects that of the requirements. Would you prefer having a gigantic switch statement to dispatch any and all possible events a form could receive?

[MrL]

@Groaner said in Will ASP.NET MVC ever go away?:

Then you have my sympathies for having to deal with pages doing things much more complex than binding to some data source and allowing CRUD over said data.

Binding to data source and CRUD is cool and funny everywhere. But it's rarely what I'm dealing with.
Or should I say 'dealt with' - I'm off the frontend shitfest. Praise the deity.

Whatever floats your boat.

Sure, if you like asp, have fun with it.

Complexity of the codebase generally reflects that of the requirements. Would you prefer having a gigantic switch statement to dispatch any and all possible events a form could receive?

In mvc I have a separate method for every event. Nice and clean (with some code repetition perhaps, but at least separation is in place).

[Zenith]

@Groaner said in Will ASP.NET MVC ever go away?:

When was this? Sounds like a great opportunity to put each into an UpdatePanel.

Looks like UpdatePanel was introduced in 3.5. I think they were on 4.0 but I was coming from an environment that only supported 2.0 (and bailed on webforms). My original take, after having separate pages and XSLT shot down, was to use iframes, which would've been functionally equivalent. I might've tried UpdatePanels and run into issues but I could've just as well been ignorant of them too. In my defense, this was a shop using what I call "jagged user controls" (a block of HTML that doesn't form a complete container like "tr td input /td") all over so it wasn't like I had any help.

What does that mean - no callbacks? No Javascript? I can think of many ways to interpret that "requirement."

It means thou shalt use web controls for everything. If I used JavaScript to hide/highlight elements or do cursory validation, I got my hands smacked. Forget XSLT or AJAX. Hell, I wasn't even allowed to use DLLs or static functions there.

Any decent third-party gridview control should not postback under those conditions. Such controls have been on the market since at least 2008.

If you're allowed to use them. It had to be stock ASP.NET there.

I did use DevExpress a few years later somewhere else. It was visually pleasant but I do remember running into issues that were easier with raw HTML tables.

<rant>On a tangent, funding for tools has been very inconsistent even within the same organization. I started my career being denied pretty much anything I asked for so I got used to writing my own tools. Subsequent jobs, they would spend untold amounts of money on junk and force dependence on it. That was fun when the specification demanded a feature that the chosen tool didn't support. You're stuck between being barked at about deadlines and being barked at for wasting time on workarounds. Even places where I had to write my own tools, those idiots went out and bought libraries after I left. I mean, I don't agree that Office automation is the terror it's made out to be, but it was the only tool I had. Why, years after the requirement was fulfilled and working without issues, did somebody go out and buy Aspose? Because some dummy in CIO Monthly is peddling one-app-per-server apportionment again and Office is seven by itself?</rant>

"Well, you said you wanted everything handled on the server and dictated the implementation I was permitted to use. We can make this faster, but it entails relaxing your requirements."

This was the manager that insisted I was making unbreakable text (from a Java stack trace stored in a database column) scroll or stretch its container on purpose (some of the weirder CSS white-space options weren't around yet and we were on IE8 or IE9 anyway). Naturally, she didn't see the connection between forcing everything into this model and the dramatic drop in performance. Nor did she have an alternative. This was really common behavior for her. Everything I ever did, she "knew somebody" that could do it faster or better with less code but never actually delivered these miracles. Couldn't lose face though so she'd send me on wild goose chases (until I had enough and found another job).

I remember she looked at my XSLT code, which I'd knocked down to four or five lines per table (the nuts and bolts were in 200-line library so these lines you could see were just hooking up containers and column formats), declared it "too confusing," and insisted on 200 lines per table in the page aspx.cs files. She had a real hissy fit about not having codebehind too. Couldn't put it in the aspx file, couldn't put it in the bin folder, couldn't put anything in a DLL.

Again, when was this? XSLT is making me think circa 2005, in which case you'd have an excuse.

Sadly, this was 2013. The XSLT code I was using was from 2004, though it had been updated for cross-compatibility and the deprecation of "data islands." My laptop at the time still had a floppy disk drive though.

It's not entirely a loss. Just think of how much material is being generated for this site!

You're telling me. If I could track down some old disks, I'd have some great submissions for the site. Problem is, some of the WTFs are less about stupid code than stupid decisions that produced stupid code.

[Unperverted Vixen]

@Zenith said in Will ASP.NET MVC ever go away?:

I mean, I don't agree that Office automation is the terror it's made out to be, but it was the only tool I had. Why, years after the requirement was fulfilled and working without issues, did somebody go out and buy Aspose? Because some dummy in CIO Monthly is peddling one-app-per-server apportionment again and Office is seven by itself?

Because the Microsoft license auditors came by and said "you need an Office license per user if you're going to use Office automation"? I know that's why we switched.

[Zenith]

@Unperverted-Vixen Trust me, there's no shortage of Office licenses in that organization.

They're really bad at managing licenses though. Did you ever have a younger sibling or cousin that broke all of their toys and couldn't understand why you wouldn't let them anywhere near your stuff? Same deal, except with CDs and license keys. You could give them a copy every year and when it came time to reinstall for some reason they had "no record" of it. Had to turn one desktop app used by four people into a web app because they "lost" (stole and over-allocated) our DB2 driver licenses. Application inventory to these people is burying spreadsheets and forgetting where they are like retarded squirrels.

[Groaner]

@MrL said in Will ASP.NET MVC ever go away?:

Sure, if you like asp, have fun with it.

I don't. If I had my way, I'd be working on a pet project in C++. But there's not much money in that direction, and most of it goes to early twentysomethings who work twice as many hours as I do at half the salary, and get laid off as soon as the project ships. At the same time, I am glad about how little Javascript I encounter on a day-to-day basis.

In mvc I have a separate method for every event. Nice and clean (with some code repetition perhaps, but at least separation is in place).

How is that significantly different from the soup of events, at either the control level or the page level, that one has access to with Webforms?

[MrL]

@Groaner said in Will ASP.NET MVC ever go away?:

How is that significantly different from the soup of events, at either the control level or the page level, that one has access to with Webforms?

WebForms events are not defined by me, they are page/control events. So with more complex scenarios you have to check what event actually occured and needs to be handled

OnSomething()
	if(event1)
		partially handle event1
	if(event2)
		partially handle event2
	if(event3)
		handle event3

OnSomethingElse()
	if(event1)
		partially handle event1
	if(event2)
		partially handle event2
	//no event3 because reasons

	//this happens only here
	if(event4)
		handle event4

And so on, parts of logic scattered everywhere, in nice readable if trees.

In mvc it's

HandleEvent1()
	do stuff

HandleEvent2()
	do stuff

HandleEvent2()
	do stuff

[Parody]

@Zenith said in Will ASP.NET MVC ever go away?:

They're really bad at managing licenses though. Did you ever have a younger sibling or cousin that broke all of their toys and couldn't understand why you wouldn't let them anywhere near your stuff? Same deal, except with CDs and license keys.

Heh. Many, many years ago one of my work-study jobs was technical adviser to the college newspaper. They told me they had purchased multiple licenses for Version 5 of an application but no amount of searching turned up more than one license and the documentation relating to that purchase. My advice was to continue using Version 4 of the application as we had plenty of licenses for that until they could properly purchase more Version 5 licenses.

Their solution was to install Version 5 on all the machines and then disconnect them from the AppleTalk network so the application wouldn't see any other installs running. Sure, that prevented them from printing or copying the individual articles to their main computer for assembly, but they had to have Version 5!

Eventually they relented, deciding that having to switch wires around or quit applications all the time in order to get their work done wasn't worth the hassle. Regardless, I was fired for "incompetence". Yeah.

This was also the job where I got a call at 3 in the morning from a girl who had "lost all her icons", a problem solved by scrolling the Finder window so they were all visible again.

[Groaner]

@Zenith said in Will ASP.NET MVC ever go away?:

In my defense, this was a shop using what I call "jagged user controls" (a block of HTML that doesn't form a complete container like "tr td input /td") all over so it wasn't like I had any help.

Those are always fun. The company I'm at has a library of homebrew controls from the .NET 1.1/2.0 days which were predictably buggy. We generally replace them with Devexpress stuff as we update the relevant pages, and our customer generally appreciates this.

It means thou shalt use web controls for everything. If I used JavaScript to hide/highlight elements or do cursory validation, I got my hands smacked. Forget XSLT or AJAX. Hell, I wasn't even allowed to use DLLs or static functions there.

So even an onclick confirm("Are you sure you want to delete this widget?"); is verboten, making the user suffer multiple postbacks? What awful UX.

If you're allowed to use them. It had to be stock ASP.NET there.

Annoying, but not too hard to do with UpdatePanel, if you don't mind rolling a bit of custom code. "Stock ASP.NET only" tends to entail a lot of custom code for some reason. I guess some companies want to get into the Web controls business and out of the widget frobnicating business?

I did use DevExpress a few years later somewhere else. It was visually pleasant but I do remember running into issues that were easier with raw HTML tables.

The early versions were kind of limited and buggy, as is to be expected, but they've gotten progressively better over the years.

This was the manager that insisted I was making unbreakable text (from a Java stack trace stored in a database column) scroll or stretch its container on purpose (some of the weirder CSS white-space options weren't around yet and we were on IE8 or IE9 anyway). Naturally, she didn't see the connection between forcing everything into this model and the dramatic drop in performance. Nor did she have an alternative. This was really common behavior for her. Everything I ever did, she "knew somebody" that could do it faster or better with less code but never actually delivered these miracles. Couldn't lose face though so she'd send me on wild goose chases (until I had enough and found another job).

For the kids following along, the way to handle a micromanager is to engage in upward management. If they want to be involved at every step, appraise them of the technical concerns and make clear what the tradeoffs are. At best, they will take the hint, back off, and stop second-guessing the "expert" they hired to get the job done. At worst, their control freak urges are sated, the developer can wash his/her hands of the matter and enjoy a modicum of peace.

This one, however, seems like a sufficiently advanced case where jumping ship was the correct decision. It's often easier to replace an employer than to change an employer.

I remember she looked at my XSLT code, which I'd knocked down to four or five lines per table (the nuts and bolts were in 200-line library so these lines you could see were just hooking up containers and column formats), declared it "too confusing," and insisted on 200 lines per table in the page aspx.cs files. She had a real hissy fit about not having codebehind too. Couldn't put it in the aspx file, couldn't put it in the bin folder, couldn't put anything in a DLL.

That reminds me. The company hired a game developer for one of our side projects several years ago, and he was shocked that we had hundreds of source code files in our project when in his view, all that was needed were a handful. Not everyone likes wading through files 10+kLoC long, or merging changes between five people on the same file.

Problem is, some of the WTFs are less about stupid code than stupid decisions that produced stupid code.

Both are fair game, as I see it.

[Zerosquare]

@Parody said in Will ASP.NET MVC ever go away?:

I got a call at 3 in the morning from a girl who had "lost all her icons", a problem solved by scrolling the Finder window so they were all visible again hanging up, getting a new unlisted phone number and not giving it out to anyone from work.

There, FTFY.

[Parody]

@Zerosquare said in Will ASP.NET MVC ever go away?:

@Parody said in Will ASP.NET MVC ever go away?:

I got a call at 3 in the morning from a girl who had "lost all her icons", a problem solved by scrolling the Finder window so they were all visible again hanging up, getting a new unlisted phone number and not giving it out to anyone from work.

There, FTFY.

Not really an option; I lived on campus, so my name, picture, and phone number were in the college phone booklet and my phone number was assigned by the college.

Unplugging the phone would have worked, I suppose, but I might miss out on some actually fun activities.

[HardwareGeek]

@Parody How many actually fun activities have ever resulted from 3AM phone calls? And how many computer geeks get those kind of phone calls?

[Parody]

@HardwareGeek said in Will ASP.NET MVC ever go away?:

@Parody How many actually fun activities have ever resulted from 3AM phone calls? And how many computer geeks get those kind of phone calls?

More than the number of call-outs I got from the newspaper job. ;)

[Tsaukpaetra]

@Zenith said in Will ASP.NET MVC ever go away?:

Here's one. I once worked for a micromanager that wanted 10+ mostly unrelated tables on the same page, 9+ hidden behind tabs at any given time, and demanded all events handled server side. Every filter or sort forced a postback that carried megabytes of data in the viewstate. Then she cried that it was so slow to use. The same page using JavaScript and XSLT to filter and sort is slow once (because it's loading 10+ fucking recordsets). But then by the time you're doing that, you've already bypassed the datagrid control completely.

BEHOLD! The slow!

It's the online (internal) character editor, looks like this:

Each of those you-can't-tell-they're-tabs-because-I-never-finished-the-upgrade-to-Bootstrap-3-tabs is backed by 1-2 tables, except the starting tab, which is the original MVC viewmodel associated with the character and loads essentially instantly after the first round-trip to the DB (well, if you consider half a second instant, gotta process the template for the main menu and those dropdowns, and the owner selector which lists every single user in the database...).

I suppose I'm not MVC-ing well?

[Zenith]

@Groaner said in Will ASP.NET MVC ever go away?:

This one, however, seems like a sufficiently advanced case where jumping ship was the correct decision. It's often easier to replace an employer than to change an employer.

You have no idea. Towards the end, I would unplug my phone so she'd stop calling me every 3 minutes. When I left, my exit interview was entirely about what a micromanager she was. I see the job come up every 4-6 months. Recruiters call me, I ask if she's still there (I already know the answer), and the response is usually "oh, so you know about her." I've seen alot of the bad jobs I've had keep coming up but this is the only one where everybody knows exactly who's causing the turnover.

@Tsaukpaetra said in Will ASP.NET MVC ever go away?:

BEHOLD! The slow!
I suppose I'm not MVC-ing well?

I expect they're short recordsets being returned, the WHERE clause contains no XML parsing, you're not requerying/refiltering/resorting all of them on every postback, and the machine it's running on is newer than 2007 vintage.

[sockpuppet7]

@Groaner said in Will ASP.NET MVC ever go away?:

Annoying, but not too hard to do with UpdatePanel, if you don't mind rolling a bit of custom code.

I had many annoying bugs with nested updatepanels not updating as they should

[Tsaukpaetra]

@Zenith said in Will ASP.NET MVC ever go away?:

I expect they're short recordsets being returned, the WHERE clause contains no XML parsing, you're not requerying/refiltering/resorting all of them on every postback, and the machine it's running on is newer than 2007 vintage.

How short is short? And why would you try sending long sets to the client?
Parsing should generally not be done in SQL. I already had enough problems joining by a column by a possibly-there sub-json value, and it's the slowest part of any query that uses it.
Yes, by nature of semi-stateless the query/filter/sort gets done on every request. Why do you ask?
It's running on Azure. Near as I can tell that means a shared environment with half a 2.4 GHz core i3-numbers.

I know! All your problems would go away if you moved to the cloud!

[dkf]

@Groaner said in Will ASP.NET MVC ever go away?:

The company hired a game developer for one of our side projects several years ago, and he was shocked that we had hundreds of source code files in our project when in his view, all that was needed were a handful. Not everyone likes wading through files 10+kLoC long, or merging changes between five people on the same file.

We used to have a game dev as a student. He excelled at producing smartass code with loads of microoptimizations in it, but he was shoddy at watching out for whether the algorithms were high-level efficient (he wasn't quite at the level of doing hand assembly to produce the world's fastest bubble sort… but he sometimes came close; the algorithms in question are quite a bit more complex). He also missed on some absolute obvious performance tricks he could do, but didn't because they didn't fit with his philosophy of how Python ought to be used, and wasn't good enough at tracking whether his code was really doing what he thought (a real problem when running on some types of hardware platform, especially ours where the messaging fabric is not 100% reliable).

It's the sort of thing that makes me highly suspicious of the claims of any game developer to actually be good and not just a sleep-deprived hack.

[Zerosquare]

@dkf said in Will ASP.NET MVC ever go away?:

It's the sort of thing that makes me highly suspicious of the claims of any game developer to actually be good and not just a sleep-deprived hack.

You shouldn't. There sure are people with more flash than substance in game programming, sure, but it's the same everywhere else. On the other hand, there are also truly talented people making awesome stuff.

Contrast this with web dev, where the leading edge is pretty much "doing something that was already done 10 or 20 years ago, except more poorly and on a much more powerful machine, and claiming it's revolutionary".

[CodeJunkie]

@Zerosquare said in Will ASP.NET MVC ever go away?:

@dkf said in Will ASP.NET MVC ever go away?:

It's the sort of thing that makes me highly suspicious of the claims of any game developer to actually be good and not just a sleep-deprived hack.

You shouldn't. There sure are people with more flash than substance in game programming, sure, but it's the same everywhere else. On the other hand, there are also truly talented people making awesome stuff.

Contrast this with web dev, where the leading edge is pretty much "doing something that was already done 10 or 20 years ago, except more poorly and on a much more powerful machine, and claiming it's revolutionary".

And runs worse than on a machine from 10 to 20 years ago.

[TimeBandit]

@CodeJunkie said in Will ASP.NET MVC ever go away?:

And runs worse than on a machine from 10 to 20 years ago.

That's the revolutionary part

[Zenith]

@Parody I went to school right before every kid had a cellphone (in fact, I had a calling card!) so I get how unplugging the phone line might've been a hindrance.

@CodeJunkie said in Will ASP.NET MVC ever go away?

And runs worse than on a machine from 10 to 20 years ago.

I watched a NeXT demo by Steve Jobs once and it was a real eye opener. That system was doing OLE on super soldier serum at lightning speed. Machine specs are hundreds if not thousands of times higher now and I still experience scroll and focus lag more often than not.

[dkf]

@TimeBandit said in Will ASP.NET MVC ever go away?:

@CodeJunkie said in Will ASP.NET MVC ever go away?:

And runs worse than on a machine from 10 to 20 years ago.

That's the revolutionary part

Code churn involves revolution…

[Captain]

@Parody What school was this?

[Parody]

@Captain said in Will ASP.NET MVC ever go away?:

@Parody What school was this?

One where you could say "I'm a student at a small Midwestern college...". ;)

[Captain]

@Parody Ah, it just smelled like a story I heard at a small PNW college that used MacOS 9.1. :-)