Posts tagged .NET

In the 1990’s, C/C++ and Java ruled the enterprise application world while Microsoft’s Visual Basic was a very limited Windows application tool, and we had Borland’s Delphi with its far more powerful architecture providing one of the best native Windows Rapid Application Development (RAD) tools.

Sun took Microsoft to court when Microsoft tried to add proprietary extensions to Java which was owned by Sun and this ended Microsoft’s desire to use Java.

Microsoft then hired one of the architects of Delphi to come up with its own equivalent of Java – and this was the C# language which became the basis of Microsoft’s .NET technology and Windows Performance Framework (WPF) which was the .NET graphical engine for rendering user interfaces on Windows operating systems.

Microsoft then disgarded its Winforms-based development tools such as MS Visual Basic and forced VB users to migrate to VB.NET which would work alongside C# as a programming tool in the MS Visual Studio suite.

This change of direction pushed most developers to .NET, and away from native compiled Windows applications and also away from Java.

Borland responded by creating a .NET version of Delphi which has now evolved to be Delphi Prism but in the process meant it lost its way, and eventually sold Delphi to Embarcadero which is now again leveraging its power and versatility, particularly with its re-vitalised Win32 native application development which will hopefully soon also be able to create native compiled Win64, Linux and MacOS apps, but also with its relationships with RemObjects and the furthered development of Delphi Prism .NET to include ports to MacOS.

In the first decade of this millenium, the vast majority of Windows application development was targeting .NET and if you were not making .NET, companies would think twice about your product.

In 2007, Microsoft released Silverlight – a C#, .NET, WPF technology designed to compete with Adobe Flash and provide a graphical plugin environment for web browser which would run on other major operating systems including MacOS. Developers again rushed to embrace this new technology which has a lot of nice features but also a few downsides.

In late 2010, Microsoft created an uproar amongst the developer community by its apparent lack of ongoing commitment to Silverlight which although provides the richest client experience on Windows browsers, does not run on the multitude of new devices such as Android. Microsoft and Apple now seem to have abandoned .NET and Silverlight and are pursuing HTML5 and javascript technology as  the future of cross-platform web browser applications. Adobe have created their Wallaby conversion tool to allow Flash developers an easier way to migrate their work to HTML5 given that Flash developed websites are locked out of the Apple iOS devices.

see:

• http://www.amazedsaint.com/2010/10/silverlight-vs-html-5-debate-dilemma.html
• http://www.itwriting.com/blog/3127-microsoft-wrestles-with-html5-vs-silverlight-futures.html
• http://team.silverlight.net/announcement/pdc-and-silverlight/
• http://www.itwriting.com/blog/3921-where-is-microsoft-going-with-its-rich-client-api-microsoft-drops-some-clues-as-developers-fret.html
• http://andrewtokeley.net/archive/2010/09/04/when-should-you-use-silverlight.aspx

This leaves many developers wondering about the future of .NET itself when Microsoft does not actually create any major Windows applications using .NET but rather uses native compiled applications for their better performance.

For instance even though Microsoft totally revamped Office apps in 2007, they did not resort to using .NET to architect these.

Likewise, Microsoft Office is not architected with .NET and has a much better user interface than the browser webmail version which demonstrates the limitations of browser-based rich client application development.

If you follow the arguments currently flying around the web, Silverlight and .NET are just not fast enough for major enterprise-wide rich client major applications, and Winforms is still the preferred technology base for such applications.

I know where this leaves me, very happy that I did not change to .NET and abandon Delphi Win32 and its fast natively compiled Windows applications with full access to Windows API’s and memory management, with potential to have native Win64, MacOS compiled apps in the near future.

Furthermore, HTML5 web client solutions need data driven web servers, and these can be created in Delphi 32, Delphi 64, Delphi Prism .NET or Delphi PHP or C++ Builder, depending on your fancy, either with REST/JSON, SOAP/XML, REMObjects or other messaging and with either Azure, Amazon EC2 cloud, DBExpress, ADO, ADO.NET or ASP.NET data technologies, and all with the same RAD Studio programming tool.