Credits: Jaxenter
In the 1990s when Java began to appear on the developer scene it met its competition from Microsoft head-on in that it struggled to gain an acceptable place within the international development community. However, over the years Java appears to have arrived at more stable set of infrastructure and development standards than Microsoft appears to offer now. This is the result of both communities taking maturation trajectories that were in a very real sense diametrically opposites of each other. Microsoft, at the time, was offering maturing technologies while Java was the “new kid on the block”. Both communities also offered completely different viewpoints towards their product developments. Microsoft offered products with “ease of use” as the underlying factor allowing developers to quickly create both desktop and web applications far more quickly than competing solutions. This was especially true when compared against the new Java tools. However, Java had its founding basis in the academic and scientific arenas.
One could see this easily with the many Java articles that took apart various interface controls that we in the Microsoft Community took for granted with the exception of third-party control developers.
The Java Community did have a difficult time to get its place as an accepted form of development until it presented an alternative to Microsoft products in the large enterprise development area, which was Microsoft’s weak spot since Microsoft products at the time were targeting division and department level applications. Once Java tools became more usable for developers, the large enterprise arena saw the advantages of Java development with its better-suited enterprise offerings (ie: J2EE, and later, the Spring Framework).
Today, we find a Java Community that appears to be far more stable than that of the Microsoft Community though one would not know it with the subdued reporting around it. Years ago such reporting was quite different as the two communities fought each other for developer supremacy Reading online magazines such as jaxEnter.com today, most of the articles appear to concentrate on existing technologies along with their refinements. The opposite appears to be true for Microsoft, which seemingly approaches product refinement the way the US Pentagon approaches new weapons procurement; both throw out perfectly fine technologies and start over with brand new and completely untested concepts.
In this author’s opinion, and as one who has worked with Microsoft technologies his entire career since leaving the mainframe world around 1989, Microsoft has made some serious mistakes with not only the products they are offering but how their style of developing applications has changed over the years. This appears to have happened most egregiously with the latest CEO of Microsoft, Satya Narayana Nadella, while under Steve Ballmer; Microsoft appeared to be more stable in this regard despite his terrible reputation.
With desktop applications Microsoft has now two types of development offerings, the original “Windows Forms” model and the more current and recommended “Windows Presentation Foundation (WPF)”, the latter being far more difficult in terms of styling and designing sophisticated interfaces. One of the overall concepts behind WPF was to make its development similar to web development and in that regard it has been quite successful. However, the complexities and the rather disjointed documentation have made this style of development difficult for many developers.
Web development is a somewhat different story with Microsoft, and for those who have read my pieces on it, you all know that my opinion on it is rather negative in that it is going in too many directions. Originally designed with the “Web Forms” model, which no doubt had its own set of drawbacks, this model had been exceptionally easy to create rather complex web applications despite the flaws inherent in its internal design. It still is.
Somewhere along the line…
Somewhere along the line some senior technical personnel got it in their heads that suddenly the entire Microsoft Community wanted what the Java Community had in this regard, the MVC pattern; also a possible result of the terrible infighting that has been reported regarding Microsoft product groups. As a software engineer using Microsoft’s products at the time I kept well abreast of the issues facing my developer community. Interestingly enough, I never found any such demand by its members. In fact, when ASP.NET MVC was first announced I instead found a rather substantial negative reaction to it.
Despite this I saw nothing wrong with such a product development. However, there was absolutely no need to turn the entire Community upside down to provide this new paradigm since those developers that did want to use it already had an Open Source alternative provided by the Castle Project’s, “Monorails”. This unique and capable offering provided MVC development for Microsoft’s web development exactly in the same fashion that Microsoft introduced its first version of ASP.NET MVC. In fact, if you did a comparison of the installations you would have found that the solutions created were exact replicas of each other, leading one to wonder if Microsoft’s first introduction of MVC was in fact a forked version of the Castle Project’s, “Monorails”.
Nonetheless, unlike the Java Community that maintained its initial toolsets and used them to successfully enter into the enterprise, Microsoft, though offering quite a range of quality tools did not provide a similar scale of constructs that could be used for all levels of development. It is true nonetheless, that with its introduction of the .NET development environments, which would become Java’s fiercest competitor, Microsoft did offer such distributed computing capabilities such as the Remoting Framework (and then later the “Windows Communication Foundation (WCF)”), which was supposed to be an answer to Java’s more mature J2EE implementation (Java would offer the alternative of the Spring Framework due to J2EE’s initial performance and configuration issues). Despite Remoting’s capabilities which were rather extensive at the time, the psychology of its usage did not reflect a similar strain of thought found in the Java Community. So while the Java Community’s enterprise level tools were all entwined with the ability to develop Java desktop and web applications, Microsoft’s offerings were rather too disparate to offer such a level of psychological cohesiveness.
This was an unfortunate failure on Microsoft’s part since .NET, even in its earliest configuration had a great deal to offer to both developers and organizations looking for modern rapid application development techniques, something the Java Community was not as equipped to offer. Nonetheless, .NET’s ease-of-use development features were as well designed as Java’s more extensive enterprise offerings. They not only offered developers a great way to create applications but also maintained a consistency for third-party companies who wanted to revise their tool offerings.
Over time the two communities began to mirror each other’s capabilities to a certain degree.
With “Windows Forms” and the newer “Windows Presentation Foundation”, Microsoft more than equaled itself with Java’s capacity for development of desktop applications through the use of Java, AWT and other tools. For web applications, Microsoft offered “Internet Information Server” as its standard application server while the Java Community relied on “Apache” and then later “GlassFish”, both excellent servers. For actual web development we had ASP.NET WebForms while Java had it’ “Java Servlets” and its MVC development paradigm; the former offering a one-to-one page process (web page to code-behind) while the latter offered a one-to-many page process (web page to multiple controllers). Over time both became accepted development methodologies for their developer communities. And though many in the Microsoft Community submitted complaints about certain difficulties with “WebForms”, no one to my knowledge was making any recommendations that it should be thrown out with the bath water. Unfortunately, Microsoft has developed a rather bad reputation for discontinuing very solid products. Though it has not announced any plans to discontinue “Web Forms” support, one can easily see that the emphasis is increasingly on the ASP.NET MVC platform. This is also true between the older “Windows Forms” platform and the newer “Windows Presentation Foundation”, though neither has been responsible for the amount of near hysteria that one can find over the use of ASP.NET MVC and its associated tools.
As an example of discontinuing fine products, Microsoft developed the desktop “SQL Server CE” desktop database engine. Coming in at around two megabytes for its footprint, it is a very easy to use engine for SQL Server developers and supported both 32bit and 64bit machines. As major SQL Server development continued, Microsoft decided to discontinue this highly versatile database engine in favor of “LocalDB”, which has around a 14 megabyte footprint on the desktop. Needless to say, this database engine is hardly on anyone’s radar as many have opted for the use of SQLite or Firebird.
With Microsoft continuing with its own refinements for the “Web Forms” and “Windows Presentation Foundation” environments, these models have come a long way and have matured into a very solid form of software development. They are both stable and offer a tremendous amount of flexibility for organizations that need to develop desktop and web applications quickly, efficiently, and with modern styled interfaces. At this juncture, Microsoft more or less offered as stable a platform as that of the Java Community. To be sure both communities offered different styles of development but both styles were mature and could produce whatever applications a business organization may require. And with Microsoft’s increasing focus on their “Data Center” servers, enterprise level development was finding a good home with Microsoft as well.
Nonetheless, with such success in both camps something went wrong on the Microsoft side of things. For the Java Community, which was quite open with their use of Open Source software, it was surprising that the basic tenets of software development never really detoured into the hype and clap-trap that has redefined the Microsoft development community. Much of this detour was a result of the ASP.NET MVC paradigm. And the reasons promoted within the Microsoft Community for MVC over “Web Forms” or WPF over “Windows Forms” are for the most part complete nonsense since all of these development models do exactly the same things; they either create web applications or desktop applications. One could argue that with emergence of mobile computing, ASP.NET MVC was a better solution but so far there has been no evidence of this in terms of Microsoft development.
The problem is that for Microsoft, which is much a marketing company as it is a software vendor, there has never been a recognition for the simple fact that development for business applications has matured to a point that there is little more that can be accomplished in this arena as it regards the development of new tools that will offer something substantially unique that it could actually promote a new form of development style. Unless there is some drastic change in the foundations that our hardware and equipment are created with such a radical change is just not going to happen.
Microsoft simply failed to understand that what they have developed is perfectly fine for developers, which reached an equivalent level of maturity as with the Java Community. And since Microsoft saw things through the lenses of a marketing organization (Why else would they make Steve Ballmer, a salesman, the CEO of the company when Bill Gates left?) they seemed to need the “next new thing” that would possibly get Java developers to convert to the Microsoft product line or encourage youngsters, teenagers, and college students to use their tools. Unfortunately, for all their efforts Microsoft appears to have failed in these veins since I have seen far more developers making comments about how they left the Microsoft Community than the other way around. And possibly this small exodus may have been a result of the growing ambiguity in development choices that Microsoft was offering. As to teaching youngsters to code; I have never heard of something so ridiculous. Like with any technical profession, there first has to be a certain level of talent for it to be of any use. Besides, Microsoft always has hidden agendas and in this case it is to develop a new level of cheap labor, not develop “critical thinking” skills.
All development paradigms are equal
All of the paradigms work efficiently and all have their advantages and disadvantages since in reality, there is no such thing as efficiency in development. For every technique implemented there is a disadvantage that has to be lived with. Thus, development decisions are based primarily on what a developer feels most comfortable with as well as what they know. Despite the technical attributes and the science behind them, for the most part such decisions are quite subjective in nature. And considering that most technical managers could care less with the exception that their technical choices will not get them fired, I doubt that there is any serious concern on their part as to the merits of any particular technique for development.
I enjoy working in VB.NET; so shoot me! I can work in C# just as efficiently and do but I came up from the DBase world in the late 1980s and feel most comfortable with 4th generation like syntax. We did some great things back then with the DBase environments and it’s somewhat of a shame that they were relegated to the dustbins of history.
Today, in the Microsoft Community, we find that we are experiencing with their tools what the Java Community experienced when it first made its emergence in the industry; concentration is on tools, techniques, and gimmicks, instead of quality application development without regard for the tools used.
Nonetheless, mature solid software development tools are not easily disposed of. A good example of this is the longevity of the main 3rd generation languages of Visual Basic, C#, Java, and C++. All of them do everything a developer requires for his or her work and have done so for quite some time; everything else, for all intents and purposes, is mere distraction and fluff. It is true that there are certain languages that have been developed for specific purposes such as Modula III, Prolog, and some more of the recent dynamic languages but for the most part the primary development languages have remained the forces in software engineering for many years once the mainframe saw its demise and will probably remain so for a long time to come.
Microsoft application development — The original and mature style of development
Once Microsoft released “Windows Presentation Foundation” in 2008 it had come to the point where it could promote a single style development for both desktop and web applications. Had they promoted such a unified environment, while refining it to support the emerging mobile environments, our side of the fence would have been far more stable in terms of development issues since our knowledge bases would have had far more depth.
As it regards these environments there are many “technical” advantages for using MVC (web), MVVM (desktop), and the like but in the end none of these advantages provide much in the way of benefit to the majority of organizations who require application development.
For example, many developers support the idea that using such paradigms can make testing far more efficient since developers can use a variety of testing frameworks and test the components separately from each other.
However, there is no evidence in the difference in subsequent quality by using good traditional testing techniques and using the more current ones. In combat fighter aviation there is one axiom that all fighter pilots have learned since the advent of fighter aircraft; it is the pilot behind the stick and not the airplane that makes an engagement a success.
In both styles of testing one has to take time to test properly. Traditional testing may be more of a manual effort but the extra time taken in newer forms of testing (“Test Driven Development (TDD)) will be applied to the additional development of testing code. And bad testing can occur in both testing models.
In fact, with traditional testing it is less acceptable to allow defects into production environments since that is the intent of such Quality Control. However, I cannot count the number of articles I have read where it is now quite common to discuss the allowance of defects into production processes with TDD/Agile since the justification is that it will be found quickly and can be easily rectified through automated deployment processes. Tell that to an end user of such application when something goes annoyingly wrong.
The style of developing applications with Microsoft tools without the MVC and MVVM paradigms is still based upon the single middle-tier module that captures and responds to user requests. In standard “Web Forms” (ASP.NET) this module came to be known as the “Code Behind” and is more or less called the same with the newer “Windows Presentation Foundation” (WPF) desktop applications. Surprisingly, Microsoft didn’t seem to come up with an acronym for this module in this environment but it is more or less the same thing. Thus, in both cases we can look at this type of development from the standpoint shown in the graphic below.
This graphic demonstrates how it has been accomplished historically on most development platforms but Microsoft more or less codified it in their products. There is absolutely nothing wrong with this model on the web as long as you are not continuously passing massive amounts of data back and forth; if so, performance will noticeably suffer.
The attempt to make the web more performance efficient has found developers as well as vendors coming up with techniques to avoid a complete “post-back” of such requests by a user. The result was the introduction of AJAX, which even today is the basis for all such calls to the backend that doesn’t involve a complete submission of the web form. Microsoft AJAX, despite some of its drawbacks, actually works quite nicely and is still being maintained professionally. You simply cannot beat the ease-of-use that the AJAX “UpdatePanel” affords developers.
For desktop applications, this is not as much of concern as the middle-tier module (response\request) for WPF or “Windows Forms” resides on the same machine as the interface and the user working with it.
Nonetheless, for the web, developers kept on pursuing some type of “silver bullet” that would somehow yield maximum performance in their applications. The result was that the pursuit of new tools and frameworks became a guidepost for Microsoft developers in terms of their skills and capabilities. Microsoft foolishly followed suit instead of concentrating on the refinement of their core products. The Java Community, apparently rather satisfied with what they have accomplished has found little need to rush into unknowns like the Microsoft world.
The reality is that on the web, as system engineers wrote years ago, performance is a matter of hardware and configuration and not so much code, though you can do things to make the responsiveness of an application better. In addition, in large scale applications such as are found on the web or very large client-server applications on the desktop, the pursuit of performance is largely an illusion since the overriding concern in both types of applications is “concurrency”, which will exclude the ability to develop maximum performance. What you want is acceptable performance when large numbers of users are accessing the application.
True N-Tiered development
In terms of development, many Microsoft developers continue to make a mess of how they handle the “code behind” modules by loading them down with just about all the necessary processing required for each interface form. The same has been done with “Windows Forms” and WPF development. And undoubtedly this happens just as often with Microsoft’s version of MVC. This type of development causes inherent bottlenecks to the applications since such modules were actually to be used as “dispatchers” to other modules that would handle the actual business logic and backend processes. Thus, the actual construct of this style of development would look as follows…
The process modules in this case then represent what we used to call the middle-tier while the interface and request\response (code-behind) modules represent the frontend tier, with the request\response modules being implemented on an application server in the case of web applications or the same machine in terms of desktop applications.
The process modules were also known as business objects where the data being passed back and forth to the clients would be manipulated through calculations, text transformations, among other types of algorithms. Specific modules that could be shared across the breadth of the process modules were designed to implement specific but more or less generic forms of processing such as database access, security authentication, and common string manipulation functions to name a few…
Finally we have the backend tier, which is comprised of the database.
To many older developers this should be common knowledge while for younger Microsoft professionals this should have been the proper way they were taught to develop high performance applications. Like a “Porsche”, “There is no substitute!”, no matter how you slice or dice it.
True N-Tiered development; The infrastructure is more important than coding
However, even if this coding infrastructure is set up efficiently and cleanly, a heavily accessed site will most likely not yield the performance gains one was hoping for. Even if the application is developed with ASP.NET MVC instead of “Web Forms”, the many controller calls from the router may provide a severe bottleneck given that the routing has been the historical point of contention with MVC since this aspect of the MVC framework has been historically based upon “Reflection”, which is not the speediest process on the planet.
Since I am not a Java developer I do not know how this community circumvents these problems. However, being a community that grew out of a more sophisticated background than we Microsoft developers I would guess that the next recourse is fairly common with large Java applications. However, the Java Community did incorporate servlets that were in a way, mini-services that would process requests and responses on the middle-tier. It was quite ingenious and still works quite nicely.
Back in the 1990s before the rise of popularized manifestos, MVC, JavaScript, and the like, the idea of actual distributed computing was a foundation for true performance in either web or client-server applications. In fact, one of the best developer manuals on this subject was actually written by a chemist turned programmer who developed high-performance web and client-server systems for the State of North Dakota (It may have been South Dakota, I don’t remember.) that had over 1500 clients hitting the central systems at any one time.
This scientist worked out the framework for a hardware\database configuration that even today simply cannot be beat for large scale applications. He took the standards of the day and designed the framework in its entirety, measuring performance benchmarks for each level of the configuration until he had refined each of the levels to an optimal efficiency.
However, with the rise of ever faster micro-processors these foundations were quickly overshadowed due to budgets that would also become defined by the rising outsourcing mania.
And yet, it was these foundations that provided the concepts of distributed computing other than the fact that such systems supported many remote clients.
To return to the above graphic, each of the various levels of processing to process optimally could not rely on a single machine to do so. However, that is what many IT organizations do today. Nonetheless, larger organizations do provide very powerful application servers, which encourage the use of single machine deployments.
Though such deployments may yield satisfactory results, unless the server is very powerful, such as with a mainframe or a set of high-powered UNIX machines, the scalability of such configurations will be finite.
To work with this, developers have turned to focusing on their code as the area where performance bottlenecks can occur. In some cases, increased performance can be accomplished by making coding refinements, but in reality, not all that much. This is because true performance is based upon hardware and not software. Thus, no matter how efficient one makes their code it will only run as fast as the machine it is deployed on can process it. The more clients a machine has, the slower the performance will be as the single machine will have to work increasingly harder to process the work load.
To work with such a limitation, developers began implementing threading operations in some of their applications, which again is mostly based upon the hardware available. An early document suggested a maximum of ten threads per microprocessor with an optimal recommendation of a single thread per micro-processor. With machines that could incorporate multiple microprocessors this seemed like a substantive idea. However, how many organizations provide 32\64 core machines for their applications and how many of those machines are set aside for a single application? I would suggest not many.
The result was that threading found its niche by providing flexibility to the interface, which is what one of its intended purposes always was. And threading does work very well when implemented properly, you just have to be judicious about it.
Within this type of implementation we also have found the rise of asynchronous programming. However, this type of processing only shines when an application has a long running task that can be placed on a background thread since the data is not needed immediately. This style of programming is not really about performance but again about flexibility.
Again getting back to the previous graphic, what we need to get maximum performance out of an application that can be easily scaled is also something that very few organizations will opt for since it takes time to design, test, and has its own expenses to implement. Nonetheless, to do this we start with a basic hardware configuration as shown below…
Before we move on, please take note of the database section in the above graphic. You will see two types of database engines, OLTP for transactional processing and OLAP for query processing. Why do we need two different types of database engines for a single application? For rather small applications we don’t but for applications that need to scale now and possibly in the future this is the standard for setting up the backend tier. OLTP databases are most efficient when used for transactional processing while OLAP databases are optimized for querying. Though OLAP database engines are touted for Business Intelligence systems, the reality of these systems is that such systems are optimized mostly for querying in addition to their numerical functionality.
To ensure that each database system is kept up to date in terms of its data, the OLTP database engine is designed to carry any updates over to its OLAP sibling.
By splitting out database systems in such a manner you can actually increase the performance of the backend by over 50% by allowing each database engine to do what it does best.
Finally, which demonstrates the increased cost of such an implementation, each tier is composed of multiple machines and the number of machines increases as we get closer to the frontend tier (interface). The scientist who worked out the performance benchmarks for each tier in his own designs found that as a process goes further down into the tiers of this infrastructure, the less amount of time it takes for the lower tiers to process. This is because each tier of machines has to actually do less in terms of responding to a user request. As a result, this type of infrastructure would look like the updated graphic below…
This latest graphic then demonstrates the proper configuration for a large scale deployment of a high concurrency application.
Each level of this infrastructure can be linearly scaled out by adding additional hardware components as each level would be made up of machine clusters.
The response to this type of infrastructure by many would be that it is too costly and time consuming to design and implement. And they would be correct. However, this is the proper technique for implementing high-performance systems and there is very little that can enable one to get around this.
The hype today, especially in the Microsoft Community, is that we can build such high performing applications with the use of scripting languages as well as the use of the MVC paradigm with C# or VB.NET. This is simply not true that this is all that is required but it makes for good marketing. Good application development not only requires clean and efficient code but an infrastructure that can provide the power that the code can take advantage of.
Performance-based code is highly overrated
No doubt the majority of Microsoft organizations do not follow the aforementioned standard due to the usual reasons; too much money, too much time needed for the design, both of which I mentioned previously. Companies like to work on the cheap and so the network and hardware people think of ways to combine applications on to existing hardware, which as soon as is done cuts the performance of the heavily used applications significantly. Such combining of applications is fine for low or even some medium use applications but overall, where performance is concerned, such combinations will only hamper the response times.
The last excuse organization people love to use is the “perfect world syndrome”. “Well, in a perfect world we would have this.”. The problem is that no one even tries to get near anything resembling credible infrastructures except for the technically savvy organizations.
The result of this derailing of actual n-tiered development has fostered the idea that applications can be made to perform very efficiently through refinement of code. For the most part this is utter nonsense but in the attempt to produce such performance technical managers have put terrible pressures on their developers to refine their code bases to the nth degree saving only milliseconds in time. This is not to say that you cannot find substantive performance enhancements in refining existing processes but it cannot be done simply through a refinement of existing code bases.
Years ago I worked with someone who thought he was the “gift to object oriented programming” and only he knew how to develop code properly. I am quite sure that everyone reading this piece has experienced a person of this nature at one point (or many) during their careers. There are plenty of these “fools” out there.
This fellow in particular just about cursed me out for a set of database queries I had written and placed as singular selects in a store procedure. This fellow promptly redid my stored procedure combining my queries into a joined set of queries. I accepted his work calmly and out of curiosity proceeded to run the performance benchmarks on the original stored procedure and the updated one that this fellow claimed was the proper way to write what I was doing. I never told him the results thinking he would just waste my time even more by trying to refine his own work. Nonetheless, his work took 35 milliseconds longer than my original code.
In either case, my faster stored procedure or his slightly slower one in the scheme of things would make little difference since Humans cannot interpret time at such levels. Yet, such attention to the coding of developers over the years has become near sacrosanct in many organizations to the detriment of all and everything else involved since for the most part it is a giant waste of time; especially if the infrastructure on which the application will run is not optimized properly. Any student of modern compiler theory and internals will be able to tell you this.
First and foremost, all of the compilers in today’s business world whether they be for the source-code languages or the database systems are extremely well optimized. Even if your code is somewhat inefficient, these compilers will make up for it by providing the best optimal solution for what you are attempting to write. Does this mean you get to write sloppy code? No…
What it means is that the attention to such performance details in your coding is more esoteric in the endeavor than in actually yielding increased performance results. It means that good clean code will work well and will most likely still be optimized by the compiler. Bad code, will work… well badly but probably not as badly as one would expect since the compiler will most likely eliminate some of the issues.
Note that we are talking about working code in both situations here not code that simply is so poorly written it will not work or barely do so.
To the last, I did work on an application that had been completely coded by someone else. The coding was atrocious and many of it completely wasteful. In fact, after having been able to study and work with the application for some time I found that at a minimum at least 50% of the code was unnecessary and could be removed if the application were to be re-written. Though I never had the opportunity to do this, the application, for all its inherently poor design and coding, actually operated reasonably well in terms of user response and processing. And this included a very poorly designed database as well.
No matter what type of application you may design and implement as long as you write your code in a clean and legible manner it will work just fine under low loads of activity. If you refine your code as much as possible towards making it as high performing as possible it will still work to the same degree under low levels of load activity since the optimizations that both you and the compiler make to your work will not be able to be interpreted by Human users. If you apply the implementation to a situation where there is to be expected a high concurrency rate, no matter how well your code is written it will fail to perform properly without the proper infrastructure. It is that simple.
Microsoft developers can do better than JavaScript and all its related tools
Despite these fairly simple engineering axioms, developers have still tried to optimize their applications in various ways that attempt to work around poor infrastructure implementations.
Today, the apparent standard on the web in the Microsoft world is what we used to call the “fat client” where as much as possible is placed within the client area of an application. The thinking is now that JavaScript reigns supreme and that as long as one implements all of the necessary libraries and dependencies on a web page everything will be highly efficient.
It is rather surprising to see developers praise a language that was never designed to do what it is being used for now while at the same time increasingly develop ever more tools that make use of the same language in a way that appears to make the whole sloppy mess in some way extremely recursive from a figurative sense.
JavaScript, like all languages of its type, falls within the domain of what we now call “dynamic” languages, which means that they are completely interpretive. In turn, this means that they are in general, inefficient no matter how fast the JIT compiler may be. Their primary advantage was for quick development times and not quick performance.
The use of such a technique encourages the building of applications that use individual data calls to the server, which will respond in kind. Some of this design came out of the mad rush to eliminate as many calls to the server as possible via post-backs, which entailed the passing of undesired amounts of data.
To some degree this concept made sense. However, it appears to have been lost on Microsoft developers especially that this form of data call was rectified rather early on with “Web Forms” through the use of the “web method”, which works quite nicely. It uses the same type of call within the popular “jQuery” framework (as well as others) that one would use if the call was made to a controller in an MVC application.
So does it matter where the method may be implemented; within a single-page code-behind or an MVC controller, which may be only one of several that will receive requests from a single web page? Most likely not…
It is true that sophisticated developers have made legitimate complaints about the way that Microsoft’s ASP.NET “Web Forms” does its processing against a “one to one” web page and its corresponding code-behind module. However, many of these complaints have been addressed over the years through refinements that Microsoft has made to the “Web Forms” paradigm. And the same has been true of Microsoft’s ASP.NET MVC implementation or there wouldn’t have been so many version releases in the past 6 years. The issue is why did we ever need two divergent development paradigms for the web when the original and more mature model offers nearly identical performance power while being far more flexible to develop with?
The Microsoft community has become erratic when compared to the Java world
While the move from “Windows Forms” to the “Windows Presentation Foundation (WPF)” has made a lot of sense in the way that now both web and desktop applications can now be developed in similar styles, the move from ASP.NET “Web Forms” to ASP.NET MVC has not had a similar level of credibility despite what the pundits may say. In fact, it is this move that has had a terrible effect on Microsoft development stunting the growth of more mature technologies that worked equally as well.
In some respects some of the thinking behind these evolutions has resulted from attempts to break out the tasks involved in application development to separate groups so that one group could design the interface while another would implement and test it. This makes sense but in most real world situations does not often happen in the Microsoft Development Community. Instead, developers tend to be responsible for most aspects of application development. This is why in job postings for Microsoft developers you often see a laundry list of skills requirements for the candidates; a list so long that no one could possibly be well skilled in all of the items. If the Java Community has found the same style of job offerings than it is familiar with this problem.
Nonetheless, one of the results of these changes in the Microsoft development environments has been to take advantage of the now many free software offerings from the Open Source Community to create new tools based upon inefficient language mechanisms not necessarily out of necessity but instead from wanting to try something new. There is nothing wrong with this endeavor but when a company attempts to mold all such activities into an existing development environment such as Visual Studio you land up with 6 gigabyte installations, most of which each developer will hardly use, taking advantage of only that which interests him or her.
Microsoft marketing consistently touts the advantages to creating great applications and modern user experiences with such new and “exciting” tools. However, if you have been in the industry as long as I have, you find that the marketing has become highly redundant by repeating the same mantras that began with the release of Windows 95. Nothing ever really changes…
Don’t get me wrong, Microsoft has some great development environments and tools as does the Java Community. However, there is a limit to what can be effectively done with the development of business applications using current protocols and infrastructures in either case. The Java Community has refined its offerings around scalability from the beginning and has matured in that endeavor. Microsoft on the other hand got off to a good start with its own offerings and could have done much more with these initial environments if they had stuck to refining what were already decent foundations.
However, instead of doing this Microsoft will persist to ensure new offerings in some misguided attempt to remain relevant while making these offerings as bloated as the original ones were claimed to be seeking that multi-pronged “silver bullet” that will not only yield high performing applications but offer efficient development environments that will convince many in the Java Community to convert.
I believe this is a fool’s errand but businesses are often run by people who are perceived to be intelligent but really aren’t. Good developers understand what they need to create good applications and it would behoove Microsoft to stop throwing everything out with the bath water and start again filtering for the community what is necessary, makes sense, and defines what makes for good ease-of-use development environments. This would be a far superior approach than turning their entire section of the industry into a technical nightmare creating a future that is based upon quicksand…
