ASP.NET vNext: an Overview
New software enhancements that embrace a more agile approach have been appearing in response to rapid changes in the software world. This speed of early adoption is nowhere more prevalent than in the software development community. The movement away from proprietary software began a decade ago and have not slowed down since. Open source clients and decoupled architecture are where everything is headed so there are some important things that the next wave of developers are going to have to learn that previous ones may not have had to.
Any framework of value today will be scalable accommodating future upgrades, patterns, and updates quickly and seamlessly. This will lead to an increased speed in release cycles for any new frameworks which means developers will have to be on top of their game at all times. These frequent updates will, over time, produce an environment that will reduce impact any existing applications by necessity. In the past framework release cycles were extremely infrequent which meant new software applications and packages had a difficult time growing because the developers knew that they could not push the envelope as the framework with stagnant.
Ad to this the fact that applications must now run on many different platforms and you got what appears to be a short-term mess. This is somewhat reduced by the fact that open source software can be worked on by any number of developers at the time, and any fixes or improvements or modules that are created to be integrated into any existing framework. This makes an impossible task not only possible, but fairly efficient.
Over the years ASP.net has matured as a platform. It has evolved from web forms into ASP.net Web API. This is a good thing because the world of development has changed as much or more over the same amount of time and the core framework of this technology must be upgraded. These upgrades must occur frequently and seamlessly.
In ASP.net different framework assemblies encapsulate much of its functionality. Any updates this functionality regardless of size means an entirely new version of the assembly must be shipped. This is inefficient and is not the type of agile ASP.net development we need today. Couple this with the fact that an entire assembly must be used if a developer wants to use only a single class. This would increase namespaces orders of magnitude beyond what they need to be. This can be seen in something like System.web. It contains interfaces and classes that allow for browser and server communications, but it can also provide cookie manipulation, file transfer, and other web forms functionality. And all of this must be installed if you want to use one simple class.
Of course other assemblies contain a great deal of functionality. We can't call all of them unnecessarily enormous especially if they're extremely useful. As it stands now to peers that we have an all or nothing app I'm very good area today roach, either we have an agile useful assembly that does very little warning enormous monolithic assembly that does way too much. This is an oversimplification but it is also very common.