Is ASP.NET relevant to modern web development?
ASP.NET has a new version coming out soon. ASP.NET vNext will have a new project file management system (long overdue) and a lot of integration points with modern front-end web development tooling, like Grunt and Bower.
I'm a web developer, and all of the back-end systems I work with are Microsoft based (ASP.NET MVC and Web API, SQL Server, Azure, etc.). I must be super excited about this new stuff coming soon, right?
Nah, not really.
Like most web developers, I spend a lot of time in HTML5 and CSS3 and tons of time in JavaScript. I spend most of my energy getting front-end libraries to work together, making web pages responsive, dealing with cross-browser and cross-device issues, and debugging with browser tools. Over the last several years, MVC, Web API, and even SQL Server have been less a part of my day-to-day coding, so changes and new versions matter less to me.
It seems to me that back-end tooling is becoming a commodity. Here's what I mean. Quick - which cloud provider is the best one? I don't know. Aren't they all about the same? Maybe they have different SLAs, or broader or narrower service offerings, but just to get a web app running with a database, they are all about the same. If one was $5/month cheaper, wouldn't you switch to them? Unless the support or extra services or the hassle of changing cloud providers were worth an extra $5/month to you, you'd switch.
I think of ASP.NET and SQL Server the same way. It's back-end tooling. It involves maybe 10-25% of my coding week. I'm not dissatisfied with the tools. I just don't use them that much. I guess they could get a little better, but that won't make me need to use them more or care more about how they are implemented.
I don't send view models down with my MVC views anymore. I just let MVC serve up a view-model-less view and let JavaScript and AJAX calls go get anything else the page needs. This means the initial page loads fast, but it doesn't fully work until the JavaScript has finished putting everything in its place.
Once you start spending a lot of time in JavaScript and pulling in data with AJAX, and you have to write it that way so the user can interact with the page, then why write it twice with 1) the Razor-template-populated-with-initial-view-model way, and 2) the HTML-template-populated-with-AJAX-data way? Writing the same functionality with two templating languages and two data sources isn't going to get your project done faster or reduce maintenance costs.
Plus, the user gets to see most of the page, just maybe without all the data yet or with empty drop downs while the data is still on its way to the page. I think that gives the user a sense that we're getting you the parts of the page as soon as we can, instead of building everything up on the server as one big ball of templated data while you look at a white, empty browser window.
So why not just dump the whole thing and code HTML, CSS, and JavaScript with any old text editor?
Working with the current Visual Studio project system has been more than just an annoyance; it's been a source of real pain. Looks like the new project/file system may help in vNext.
I can't say that Intellisense is very useful to me these days. It's never really worked right with JavaScript. Maybe that will get a little better, but I've gotten used to it pulling up every JavaScript symbol when I type ".".
The alternative would be HTML files that you double click to open and debug in the browser. It would work, but you'd have to keep you file system and text editor open all the time, and you wouldn't have server-side debugging of your API layer.
I still use MVC and Web API for their security, and I'm glad their namespaces are finally going to be merged in vNext. That means I won't have any more code that filters MVC requests one way and Web API requests another way.
If I was building a new web app today, would I use ASP.NET as the back end? Probably, but it would be the same way I've used it the last 4-5 years: minimal MVC page serving, an API service layer, and a security layer.
The most interesting, highest customer value web development stuff is happening on the front end, and I don't see that changing anytime soon.
I'm a web developer, and all of the back-end systems I work with are Microsoft based (ASP.NET MVC and Web API, SQL Server, Azure, etc.). I must be super excited about this new stuff coming soon, right?
Nah, not really.
Like most web developers, I spend a lot of time in HTML5 and CSS3 and tons of time in JavaScript. I spend most of my energy getting front-end libraries to work together, making web pages responsive, dealing with cross-browser and cross-device issues, and debugging with browser tools. Over the last several years, MVC, Web API, and even SQL Server have been less a part of my day-to-day coding, so changes and new versions matter less to me.
Just another back end?
If you are a front-end web developer, you need your AJAX request to hit a back-end endpoint and give you a response. That kind of framing of the back-end, that it can be encapsulated or black-boxed, also means its implementation could be changed and you wouldn't really care. Why should it matter if the back end is written with node.js, Ruby on Rails, Java, Azure Mobile Services, or ASP.NET? From the front-end web developer perspective, I just want a response. Obviously, it needs to be fast, scalable, robust, secure, and that kind of thing, but all major server-side frameworks have that figured out.It seems to me that back-end tooling is becoming a commodity. Here's what I mean. Quick - which cloud provider is the best one? I don't know. Aren't they all about the same? Maybe they have different SLAs, or broader or narrower service offerings, but just to get a web app running with a database, they are all about the same. If one was $5/month cheaper, wouldn't you switch to them? Unless the support or extra services or the hassle of changing cloud providers were worth an extra $5/month to you, you'd switch.
I think of ASP.NET and SQL Server the same way. It's back-end tooling. It involves maybe 10-25% of my coding week. I'm not dissatisfied with the tools. I just don't use them that much. I guess they could get a little better, but that won't make me need to use them more or care more about how they are implemented.
I don't send view models down with my MVC views anymore. I just let MVC serve up a view-model-less view and let JavaScript and AJAX calls go get anything else the page needs. This means the initial page loads fast, but it doesn't fully work until the JavaScript has finished putting everything in its place.
Once you start spending a lot of time in JavaScript and pulling in data with AJAX, and you have to write it that way so the user can interact with the page, then why write it twice with 1) the Razor-template-populated-with-initial-view-model way, and 2) the HTML-template-populated-with-AJAX-data way? Writing the same functionality with two templating languages and two data sources isn't going to get your project done faster or reduce maintenance costs.
Plus, the user gets to see most of the page, just maybe without all the data yet or with empty drop downs while the data is still on its way to the page. I think that gives the user a sense that we're getting you the parts of the page as soon as we can, instead of building everything up on the server as one big ball of templated data while you look at a white, empty browser window.
So why not just dump the whole thing and code HTML, CSS, and JavaScript with any old text editor?
Where does the Microsoft ecosystem add value in modern web development?
IDE
In spite of its limitations for front-end development, Visual Studio is still a very good IDE. Different colors for keywords and navigation within and across files is very good. But most of the value I get from continuing to use Visual Studio is a result of the Web Essentials extension. It's nice to run JSHint with every save and to get pointers in the IDE about CSS rules, potential browser issues, and unclosed HTML tags. If I switched to Notepad, I'd be giving up some things that really do make my coding day a little brighter.Working with the current Visual Studio project system has been more than just an annoyance; it's been a source of real pain. Looks like the new project/file system may help in vNext.
I can't say that Intellisense is very useful to me these days. It's never really worked right with JavaScript. Maybe that will get a little better, but I've gotten used to it pulling up every JavaScript symbol when I type ".".
Local Web Server
Simple and unobtrusive, IIS Express is a great place to test run your web app, and the integration with Visual Studio is limited but sufficient.The alternative would be HTML files that you double click to open and debug in the browser. It would work, but you'd have to keep you file system and text editor open all the time, and you wouldn't have server-side debugging of your API layer.
Security
Security is probably the main thing that has kept me from dumping ASP.NET and using HTML files instead. I've never worked on a web app where security wasn't important. You need a way to know who's knocking on the server's door, and when that request is bouncing around on the back-end servers, you need to know what group/role that user is in so you can turn features on and off.I still use MVC and Web API for their security, and I'm glad their namespaces are finally going to be merged in vNext. That means I won't have any more code that filters MVC requests one way and Web API requests another way.
API layer
Web API is totally relevant for modern web development. All web apps need a way of interacting with a back end, and Web API sets up as a simple, thin transport layer so you can do whatever back-end stuff you need to do on the server. Content negotiation is nice if you have a public API, but I've only written internal APIs that send/receive JSON.Conclusion
I guess I am looking forward to some of the improvements in ASP.NET vNext.If I was building a new web app today, would I use ASP.NET as the back end? Probably, but it would be the same way I've used it the last 4-5 years: minimal MVC page serving, an API service layer, and a security layer.
The most interesting, highest customer value web development stuff is happening on the front end, and I don't see that changing anytime soon.
Is ASP.NET relevant to modern web development?
Reviewed by Unknown
on
14:03:00
Rating:
No comments: