Monday, October 07, 2013
« Aortic Update 2 | Main | The future of the business desktop »

The short answer to the question of whether the Microsoft .NET Framework (and its related tools and technologies) has a future is of course, don’t be silly.

The reality is that successful technologies take years, usually decades, perhaps longer, to fade away. Most people would be shocked at how much of the world runs on RPG, COBOL, FORTRAN, C, and C++ – all languages that became obsolete decades ago. Software written in these languages runs on mainframes and minicomputers (also obsolete decades ago) as well as more modern hardware in some cases. Of course in reality mainframes and minicomputers are still manufactured, so perhaps they aren’t technically “obsolete” except in our minds.

It is reasonable to assume that .NET (and Java) along with their primary platforms (Windows and Unix/Linux) will follow those older languages into the misty twilight of time. And that such a thing will take years, most likely decades, perhaps longer, to occur.

I think it is critical to understand that point, because if you’ve built and bet your career on .NET or Java it is good to know that nothing is really forcing you to give them up. Although your chosen technology is already losing (or has lost) its trendiness, and will eventually become extremely obscure, it is a pretty safe bet that you’ll always have work. Even better, odds are good that your skills will become sharply more valuable over time as knowledgeable .NET/Java resources become more rare.

Alternately you may choose some trendier alternative; the only seemingly viable candidate being JavaScript or its spawn such as CoffeeScript or TypeScript.

How will this fading of .NET/Java technology relevance occur?

To answer I’ll subdivide the software world into two parts: client devices and servers.

Client Devices

On client devices (PCs, laptops, ultrabooks, tablets, phones, etc.) I feel the need to further split into two parts: consumer apps and business apps. Yes, I know that people seem to think there’s no difference, but as I’ve said before, I think there’s an important economic distinction between the consumer and business apps.

Consumer Apps

Consumer apps are driven by a set of economic factors that make it well worth the investment to build native apps for every platform. In this environment Objective C, Java, and .NET (along with C++) all have a bright future.

Perhaps JavaScript will become a contender here, but that presupposes Apple, Google, and Microsoft work to make that possible by undermining their existing proprietary development tooling. There are some strong economic reasons why none of them would want every app on the planet to run equally on every vendor’s device, so this seems unlikely. That said, for reasons I can’t fathom, Microsoft is doing their best to make sure JavaScript really does work well on Windows 8, so perhaps Apple will follow suit and encourage their developers to abandon Objective C in favor of cross-platform JavaScript?

Google already loves the idea of JavaScript and would clearly prefer if we all just wrote every app in JavaScript for Chrome on Android, iOS, and Windows. The only question in my mind is how they will work advertising into all of our Chrome apps in the future?

My interest doesn’t really lie in the consumer app space, as I think relatively few people are going to get rich building casual games, fart apps, metro transit mapping apps, and so forth. From a commercial perspective there is some money to be made building apps for corporations, such as banking apps, brochure-ware apps, travel apps, etc. But even that is a niche market compared to the business app space.

Business Apps

Business apps (apps for use by a business’s employees) are driven by an important economic factor called a natural monopoly. Businesses want software that is built and maintained as cheaply as possible. Rewriting the same app several times to get a “native experience” on numerous operating systems has never been viable, and I can’t see where IT budgets will be expanding to enable such waste in the near future. In other words, businesses are almost certain to continue to build business apps in a single language for a single client platform. For a couple decades this has been Windows, with only a small number of language/tool combinations considered viable (VB, PowerBuilder, .NET).

But today businesses are confronted with pressure to write apps that work on the iPad as well as Windows (and outside the US on Android). The only two options available are to write the app 3+ times or to find some cross-platform technology, such as JavaScript.

The natural monopoly concept creates some tension here.

A business might insist on supporting just one platform, probably Windows. A couple years ago I thought Microsoft’s Windows 8 strategy was to make it realistic for businesses to choose Windows and .NET as this single platform. Sadly they’ve created a side loading cost model that basically blocks WinRT business app deployment, making Windows far less interesting in terms of being the single platform. The only thing Windows has going for it is Microsoft’s legacy monopoly, which will carry them for years, but (barring business-friendly changes to WinRT licensing) is doomed to erode.

You can probably tell I think Microsoft has royally screwed themselves over with their current Windows 8 business app “strategy”. I’ve been one of the loudest and most consistent voices on this issue for the past couple years, but Microsoft appears oblivious to the problem and has shown no signs of even recognizing the problem much less looking at solutions. I’ve come to the conclusion that they expect .NET on the client to fade away, and for Windows to compete as just one of several platforms that can run JavaScript apps. In other words I’ve come to the conclusion that Microsoft is willingly giving up on any sort of technology lock-in or differentiation of the Windows client in terms of business app development. They want us to write cross-platform JavaScript apps, and they simply hope that businesses and end users will choose Windows for other reasons than because the apps only run on Windows.

Perhaps a business would settle on iOS or Android as the “one client platform”, but that poses serious challenges given that virtually all businesses have massive legacies of Windows apps. The only realistic way to switch clients to iOS or Android is to run all those Windows apps on Citrix servers (or equivalent), and to ensure that the client devices have keyboards and mice so users can actually interact with the legacy Windows apps for the next several years/decades. Android probably has a leg up here because most Android devices have USB ports for keyboards/mice, but really neither iOS nor Android have the peripheral or multi-monitor support necessary to truly replace legacy Windows (Win32/.NET).

This leaves us with the idea that businesses won’t choose one platform in the traditional sense, but rather will choose a more abstract runtime: namely JavaScript running in a browser DOM (real or simulated). Today this is pretty hard because of differences between browsers and between browsers on different platforms. JavaScript libraries such as jquery, angular, and many others seek to abstract away those differences, but there’s no doubt that building a JavaScript client app costs more today than building the same app in .NET or some other more mature/consistent technology.

At the same time, only JavaScript really offers any hope of building a client app codebase that can run on iOS, Android, and Windows tablets, ultrabooks. laptops, and PCs. So though it may be more expensive than just writing a .NET app for Windows, JavaScript might be cheaper than rewriting the app 3+ times for iOS, Android, and Windows. And there’s always hope that JavaScript (or its offspring like CoffeScript or TypeScript) will rapidly mature enough to make this “platform” more cost-effective.

I look at JavaScript today much like Visual Basic 3 in the early 1990s (or C in the late 1980s). It is typeless and primitive compared to modern C#/VB or Java. To overcome this it relies on tons of external components (VB had its component model, JavaScript has myriad open source libraries). These third party components change rapidly and with little or no cross-coordination, meaning that you are lucky if you have a stable development target for a few weeks (as opposed to .NET or Java where you could have a stable target for months or years). As a result a lot of the development practices we’ve learned and mastered over the past 20 years are no longer relevant, and new practices must be devised, refined, and taught.

Also we must recognize that JavaScript apps never go into a pure maintenance mode. Browsers and underlying operating systems, along with the numerous open source libraries you must use, are constantly versioning and changing, so you can never stop updating your app codebase to accommodate this changing landscape. If you do stop, you’ll end up where so many businesses are today: trapped on IE6 and Windows XP because nothing they wrote for IE6 can run on any modern browser. We know that is a doomed strategy, so we therefore know that JavaScript apps will require continual rewrites to keep them functional over time.

What I’m getting at here is that businesses have an extremely ugly choice on the client:

  1. Rewrite and maintain every app 3+ times to be native on Windows, iOS, and Android
  2. Absorb the up-front and ongoing cost of building and maintaining apps in cross-platform JavaScript
  3. Select one platform (almost certainly Windows) on which to write all client apps, and require users to use that platform

I think I’ve listed those in order from most to least expensive, though numbers 1 and 2 could be reversed in some cases. I think in all cases it is far cheaper for businesses to do what Delta recently did and just issue Windows devices to their employees, thus allowing them to write, maintain, and support apps on a single, predictable platform.

The thing is that businesses are run by humans, and humans are often highly irrational. People are foolishly enamored of BYOD (bring your own device), which might feel good, but is ultimately expensive and highly problematic. And executives are often the drivers for alternate platforms because they like their cool new gadgets; oblivious to the reality that supporting their latest tech fad (iPad, Android, whatever) might cost the business many thousands (often easily 100’s of thousands) of dollars each year in software development, maintenance, and support costs.

Of course I work for a software development consulting company. Like all such companies we effectively charge by the hour. So from my perspective I’d really prefer if everyone did decide to write all their apps 3+ times, or write them in cross-platform JavaScript. That’s just more work for us, even if objectively it is pretty damn stupid from the perspective of our customers’ software budgets.

Server Software

Servers are a bit simpler than client devices.

The primary technologies used today on servers are .NET and Java. Though as I pointed out at the start of this post, you shouldn’t discount the amount of COBOL, RPG, FORTRAN, and other legacy languages/tools/platforms that make our world function.

Although JavaScript has a nescient presence on the server via tools like node.js, I don’t think any responsible business decision maker is looking at moving away from existing server platform tools in the foreseeable future.

In other words the current 60/40 split (or 50/50, depending on whose numbers you believe) between .NET and Java on the server isn’t likely to change any time soon.

Personally I am loath to give up the idea of a common technology platform between client and server – something provided by VB in the 1990s and .NET over the past 13 years. So if we really do end up writing all our client software in JavaScript I’ll be a strong advocate for things like node.js on the server.

In the mid-1990s it was pretty common to write “middle tier” software in C++ and “client tier” software in PowerBuilder or VB. Having observed such projects and the attendant complexity of having a middle tier dev team who theoretically coordinated with the client dev team, I can say that this isn’t a desirable model. I can’t support the idea of a middle tier in .NET and a client tier in JavaScript, because I can’t see how team dynamics and inter-personal communication capabilities have changed enough (or at all) over the past 15 years such that we should expect any better outcome now than we got back then.

So from a server software perspective I think .NET and Java have a perfectly fine future, because the server-side JavaScript concept is even less mature than client-side JavaScript.

At the same time, I really hope that (if we move to JavaScript on the client) JavaScript matures rapidly on both client and server, eliminating the need for .NET/Java on the server as well as the client.

Conclusion

In the early 1990s I was a VB expert. In fact, I was one of the world’s leading VB champions through the 1990s. So if we are going to select JavaScript as the “one technology to rule them all” I guess I’m OK with going back to something like that world.

I’m not totally OK with it, because I rather enjoy modern C#/VB and .NET. And yes, I could easily ride out the rest of my career on .NET, there’s no doubt in my mind. But I have never in my career been a legacy platform developer, and I can’t imagine working in a stagnant and increasingly irrelevant technology, so I doubt I’ll make that choice – stable though it might be.

Fwiw, I do still think Microsoft has a chance to make Windows 8, WinRT, and .NET a viable business app development target into the future. But their time is running out, and as I said earlier they seem oblivious to the danger (or are perhaps embracing the loss of Windows as the primary app dev target on the client). I would like to see Microsoft wake up and get a clue, resulting in WinRT and .NET being a viable future for business app dev.

Failing that however, we all need to start putting increasing pressure on vendors (commercial and open source) to mature JavaScript, its related libraries and tools, and its offspring such as TypeScript – on both client and server. The status of JavaScript today is too primitive to replace .NET/Java, and if we’re to go down this road a lot of money and effort needs to be expended rapidly to create a stable, predictable, and productive enterprise-level JavaScript app dev platform.

Tuesday, October 08, 2013 2:38:37 AM (Central Standard Time, UTC-06:00)
You say:

<blockquote>At the same time, only JavaScript really offers any hope of building a client app codebase that can run on iOS, Android, and Windows tablets, ultrabooks. laptops, and PCs.</blockquote>

There are actually a couple of options. For C#, Xamarin which provides C# (Mono) wrappers for the native iOS and Android libraries. And Delphi XE5 can do it too, via a completely different approach based on the Firemonkey cross-platform vector-based GUI framework. Both of them produce true native apps. (See this StackOverflow question for a quick discussion of the differences between how they each targets iOS.)

Granted, neither of the companies behind these platforms are comparable to Microsoft in terms of being able to influence the future, but they have proved that cross-platform development is achievable outside Javascript.
Tuesday, October 08, 2013 2:47:33 AM (Central Standard Time, UTC-06:00)
I think that "1.Rewrite and maintain every app 3+ times to be native on Windows, iOS, and Android" is not exactly accurate.

Today, we have technologies-tools that allows us to not let that happen. For example, Xamarin, with their Xamarin.* toolkits, let developers share (up to 9x% !!) their C# code so to have a very large common code base and just change the UI specific for different devices accordingly.

So, i think the 3. reason combined with the 1. will prevail: Focus on one platform (e.x. Windows) but in a way that will allow you to port much of your code to other platform(s), if that needed in the future.
Tuesday, October 08, 2013 8:53:09 AM (Central Standard Time, UTC-06:00)
Rocky, how is it that "Consumer apps are driven by a set of economic factors that make it well worth the investment to build native apps for every platform" and yet "relatively few people are going to get rich building casual games, fart apps, metro transit mapping apps, and so forth"?
Tuesday, October 08, 2013 11:54:42 AM (Central Standard Time, UTC-06:00)
A provocative question for a provocative post...

Does CSLA.Net have a future?

Let's say .NET is usurped by JavaScript/HTML. What are your latest thoughts about CSLA in a world where HTML/JS takes over as the clear choice for LOB apps? Or are you keeping those thoughts close to the vest?
Chris
Tuesday, October 08, 2013 3:13:50 PM (Central Standard Time, UTC-06:00)
Thanks for pointing out Xamarin. CSLA 4 supports Android via Xamarin, so I'm very familiar with the toolset and its capabilities.

I really like Xamarin a lot.

However, I can't imagine Xamarin doing well over time if Microsoft can't keep .NET viable on its own client devices. Again, I think they _could_ do so if they made WinRT an attractive target for business app development. As I noted in the blog post, I see no movement on Microsoft's part to make this happen.

So yes, if Microsoft can rescue .NET (and by extension WinRT) as a viable client technology then Xamarin (imo) provides a very compelling solution for cross-platform development.
Tuesday, October 08, 2013 3:17:04 PM (Central Standard Time, UTC-06:00)
As to whether CSLA .NET has a future, there are a couple answers to that.

Obviously the future of CSLA ".NET" is closely tied to the future of .NET itself.

But CSLA started as a COM-based framework, which I then rewrote for .NET. Same architecture, different implementation.

It doesn't seem unrealistic to think about a CSLA.JS that would rely on node.js on the server and some set of js libraries on the client. Again, same architecture but different implementation.
Wednesday, October 09, 2013 1:07:56 AM (Central Standard Time, UTC-06:00)
I've written on my blog about the future of Microsoft in the language market, and my personal opinion is the Microsoft'bet on .NET is not having the expected results, but not for Microsoft but for developers. I'm a big fan of Visual Basic 6, and they let VB6 die. The same with ASP Classic, trying to "copy" the competence! Can it happend again with .NET? I think ... maybe! And developers NOW have more options to choose!!

Here you can read the post (in spanish) http://www.manejandodatos.es/2013/09/recelos-a-la-plataforma-net/
Wednesday, October 09, 2013 1:10:53 AM (Central Standard Time, UTC-06:00)
I stopped reading when I reached:

<blockquote>C, and C++ – all languages that became obsolete decades ago</blockquote>

Is this a comedy blog? And CodeProject features this in their newsletter? Messed up!
Wednesday, October 09, 2013 2:19:46 AM (Central Standard Time, UTC-06:00)
Hi Rockford,


Thanks for the post, it cleared my mind about numerous questions i had. But, my question now is how much time do we have to wait until we get a answer from Microsoft ? i mean, how much time we can (have) give to Microsoft until starting a move to JavaScript ( & its offspring ) ?

Thanks again!

Adnane
Adnane
Wednesday, October 09, 2013 3:33:29 AM (Central Standard Time, UTC-06:00)
"... and C++ – all languages that became obsolete decades ago."

You've got to be joking.

I bet most of the apps and OS's you are using right now were written in and being enhanced using C++ and C, e.g. all major browsers, Windows, OSX, Linux, Photoshop, MYSQL and large parts of the systems used by Google and Facebook.

Simon
Wednesday, October 09, 2013 6:52:47 AM (Central Standard Time, UTC-06:00)
I think the concept of an "obsolete language" should not include merely that a language is old.

I have been in the IT world since the late 1970's, when I started at a large corporation, programming in RPG II on an IBM mainframe, and later in COBOL. I have long since moved on in my career to personal computer development using the Microsoft technology stack.

Much of business IT still involves the simple process of gathering data from here and putting over there. In that regard, languages like COBOL and RPG, which have added features since I was using them, can still play a role.

To my mind, a language only becomes obsolete when it can no longer handle the frequent type of requests that are routinely asked of it.

Certainly, for some tasks corporations want to do, COBOL and RPG are not suitable. But there are other tasks that they handle just fine. Abandoning them has costs and benefits for any company, but moving to other platforms just because the language has a long history is not sufficient.
David Brown
Wednesday, October 09, 2013 7:08:49 AM (Central Standard Time, UTC-06:00)
Regarding the idea of "obsolete" languages, I knew that'd raise some hackles when I wrote it, but chose to be a little sensational nonetheless :)

Perhaps the better phrase is "niche", or "dead end", or something like that.

I am a business developer. In the last decade we've only encounter perhaps 2-3 customers who wanted to build anything in C++. Our customers don't build operating systems, compilers, or games. They build the business systems that make the world go round, and they don't build them in C++ (or COBOL or RPG anymore either). They build them in .NET or Java, and increasingly in JavaScript.

So sure, in certain niche areas like operating systems and games C++ remains widely used. And that's wonderful if you get to work in those areas.

For the _vast_ majority of us though I guarantee you that PHP is more widespread than C++, and even that isn't as widely used as .NET or Java.
Wednesday, October 09, 2013 8:00:59 AM (Central Standard Time, UTC-06:00)
.NET is the new COBOL
Scott Walters
Wednesday, October 09, 2013 8:03:02 AM (Central Standard Time, UTC-06:00)
Regarding the idea of "obsolete" languages, I knew that'd raise some hackles when I wrote it, but chose to be a little sensational nonetheless :)

Perhaps the better phrase is "niche", or "not mainstream", or something like that.

I am a business developer. In the last decade we've only encounter perhaps 2-3 customers who wanted to build anything in C++. Our customers don't build operating systems, compilers, or games. They build the business systems that make the world go round, and they don't build them in C++ (or COBOL or RPG anymore either). They build them in .NET or Java, and increasingly in JavaScript.

So sure, in certain niche areas like operating systems and games C++ remains widely used. And that's wonderful if you get to work in those areas.

For the _vast_ majority of us though I guarantee you that PHP is more widespread than C++, and even that isn't as widely used as .NET or Java.
Wednesday, October 09, 2013 8:34:46 AM (Central Standard Time, UTC-06:00)
Calling C and C++ obsolete is like saying Calculus is obsolete. The author of this article obviously does not know the definition of obsolete or understands Turing Completeness.

The .NET framework core components are written in C/C++. All of the underlying COM framework is written in C. The operating system is written in C/C++.

As we see the end of Moore's law, frameworks like Java and .NET will start falling out of favor (with the exception in the Enterprise World) and the reason is simple. We have hit limitations of processor performance, but we can optimize code.

Until languages like Java and any of the .NET langues can perform that the same performance as pure C code (which is unlikely to happen anytime in the foreseable future), C and C++ will always be around and will not be obselete.

I was a former Microsoft Software Engineer and worked on many components of all of those systems are the years.
Byron Goodman
Wednesday, October 09, 2013 9:56:52 AM (Central Standard Time, UTC-06:00)
Saying "The author of this article obviously does not know the definition of obsolete or understands Turing Completeness."
>> indicates that you do not know the author at all. Rocky Lhotka is a renown author and speaker on .NET technologies. He has maintained a highly respected distributed framework, called CSLA.NET, for over a decade. I believe you took that quote out of context. I have been a business developer for over 20 years and I would never build a business app in C or C++ although I started out as a software engineer coding in C. For the most part, it is due to the ROI of building applications with more rapid development languages like C# and vb.net. But, I know you know that since you're a software engineer yourself. C and C++ are not viable options for building business apps that will run on all popular client devices.
Wednesday, October 09, 2013 11:08:50 AM (Central Standard Time, UTC-06:00)
<blockquote>C, and C++ – all languages that became obsolete decades ago</blockquote>

Please tell us what you mean by 'obsolete'... I think we do not agree abou the definition of this word.
Daniel Mendes
Wednesday, October 09, 2013 11:35:06 AM (Central Standard Time, UTC-06:00)
Absolutely spot on!

As a .NET developer since the beginning, I neither fear my
future employment nor look forward to a possible future of
HTMLx/JS. I don't want to lose the power of .NET for a
language like JS, nor do I want to lose true UI frameworks
like XAML or something like Laszlo. FWIW, if all things
.NET were to disappear, I would love to see Java take over.
A coworker of mine switched to .NET from Java with hardly
any struggle, and I'm sure I could go the other way.

I also agree with you completely on the Microsoft stance.
They have a chance to fix this and right the ship. In a world
where companies are facing the issues of which language to
write in to port apps across the various mobile platforms,
Microsoft has a chance to promote .NET. They should embrace
Xamarin and give them a bunch of money! Don't buy them, just
give them whatever they need to make it the de facto choice
for cross-platform development.

Microsoft also needs to make development for Modern/WP8 the
most attractive. No cost of entry for development. The Visual
Studio Express editions need to be much more capable, or
just make larger editions of Visual Studio free. There
should be no cost to register for the App Center, and it
should be exceptionally easy to do. They should also NOT
follow Apple's lead in one key area - they should not take
a cut of apps in the Store. Never before have developer's
had to lose a portion of their software sales. Yes, there's
a cost to the store. And, there's a savings to the developer
to not have to build their own store front. But it should be
very cheap. And, the idea of billing for in-app purchases
is crazy! Corporate side-loading and private marketplace
concepts need to be easy and free.

Taking these steps helps make .NET a great choice for
developers across all client platforms, and solidifies it as
a great choice on the server since that's one technology
stack across client server. It also makes Windows one of the
most desirable platforms to target.
Kevin Finke
Wednesday, October 09, 2013 2:43:47 PM (Central Standard Time, UTC-06:00)
I stopped reading after " C, and C++ – all languages that became obsolete decades ago.".
Obsolet0r
Wednesday, October 09, 2013 8:24:33 PM (Central Standard Time, UTC-06:00)
Mr. Lhotka, I first want to say "thank you." I read your VB Business Objects books way back before finishing college. They changed the way I approached development. They gave me the foundations for the way I architect solutions today. You would be able to see those patterns and concepts espoused in your books in the C# code I write today. I wouldn't be where I am without your books.

So, it's with heavy heart that I must ask you to stop saying these things. In programmer years, I'm an old man. I don't want to learn anything new, and I don't want to read anyone else's books. Leave .Net alone.

Seriously, I do wonder if VB.Net is going away slowly, and it leads me to ask if perhaps that is what is motivating your opinion of .Net. I'm actually pretty impressed at the vibrancy of the C# (and by extension .Net) community. Some others mentioned Xamarin. This goes hand-in-hand with the Mono project. This means that .Net runs on multiple platforms, just not in Microsoft's image. I also see the continued enhancement of the C# (and so far VB.Net) language. I point to things like Link and most recently the async framework. I have a hard time believing that these combinations of improved semantics and compiler wizardry won't have developers flocking to C# at some point.

Considering that the C# language is backed by ECMA standards, can run on multiple platforms, its ability to produce the best performance offered by a high-level language, I could see C# .Net powering the back-end (the business tiers) of applications for decades to come.

One last note. I saw your last post with comments about the ACA. It's worth mentioning the recent troubles with getting the federal exchange website (Healthcare.gov) up and running. I know "everyone" thinks that the correct way to create business applications today, even massive ones with Internet front-ends is with a combination of HTML + Javascript + JSON + XML + various Javascript libraries + Ruby or PHP or some other interpreted, ugly language on the server that isn't as performant or as elegant or as easy to code in as C#. I think "they" are wrong. Things change, but I can see this changing before .Net goes away.
Jon Okie
Wednesday, October 09, 2013 8:46:06 PM (Central Standard Time, UTC-06:00)
Believe me Jon, I take no joy in posts like this one. I am incredibly disappointed in Microsoft's lack of forward-looking strategy for C#/XAML and the related runtime.

At the same time, I owe it to myself, and I think to people who read my writings, to do the best I can to both pressure Microsoft to fix this problem before it is too late, and to lay out some sort of roadmap for where we might go if Microsoft doesn't act.
Thursday, October 10, 2013 4:17:35 AM (Central Standard Time, UTC-06:00)
I can understand the motivation for writing this post and in general agree that JavaScript is becoming very relevant on the client as a cross platform solution.
It depends what you mean by .Net Certain modules of the .Net Framework's days are certainly numbered. Server side .Net still has a bright future E.g. Asp.Net MVC. The .Net crown jewels exist under a type of open source license. There are also many other frameworks based on .Net E.g. ServiceStack.net and NancyFx to create RESTful endpoints.

We are currently developing a mobile client in HTML5 and JQuery Mobile being build with PhoneGap. The backend RESTful services are build with ServiceStack consumed by JQuery Ajax calls from the clients. The point is that we do not find it a problem with using different technologies on the server or client.

I guess sometimes maturity and thence lack of updates can make a technology seem 'not sexy any longer'. ~ Sexy != maturity..


Siegfried Niedinger
Thursday, October 10, 2013 6:51:35 PM (Central Standard Time, UTC-06:00)
It isn't as much of a "Windows first" world as it once was anymore.

"Security blankets" like Xamarin strike me as akin to blacksmiths in denial thinking people will accept and learn to love iron tires on those newfangled automobiles. Moving to markup+script is similar, blacksmiths choosing to settle for filling gas tanks and wiping windows rather than taking up the tools of an auto mechanic.

Non-native has advantages, but it might not work out as people think. Outside the Windows garden people are developing paths to generate apps for Windows from their Android or iOS native app codebase and tools too.
Bob
Thursday, October 10, 2013 10:22:32 PM (Central Standard Time, UTC-06:00)
What C/C++ obsolete??!?!

ahahahah poor Rocky...

Fast recovery buddy, see you around!

- ngm
ngm
Friday, October 11, 2013 1:39:53 AM (Central Standard Time, UTC-06:00)
Fantastic article, my observations of developing on microsoft platforms over the past 20 years are exactly yours, there is an increasingly large sentiment from developers that microsoft is abandoning them and they dont have a clear roadmap for us. It started with microsoft dropping support for windows mobile/CE development after visual studio 2008, and continues with microsoft proceeding with their terrible monochrome user interface after visual studio 2010.

In addition, 90% of consumers I have spoken to HATE the new windows 8 interface on the PC (lack of start button, and lack of "X" close window button), so unfortunately microsoft is alienating their long term loyal customers, and alienating their long term loyal developers in the hopes of attracting some possible future "young" customers who actually dont think microsoft is cool.

Where do microsoft think they are going to get their revenue from ?

This cant end well.
Friday, October 11, 2013 1:44:17 AM (Central Standard Time, UTC-06:00)
who remembers this video:
http://www.youtube.com/watch?v=8To-6VIJZRE
Ironically it actually marked the start of a DECLINE in microsoft's support for software developers.
Friday, October 11, 2013 4:23:06 PM (Central Standard Time, UTC-06:00)
<blockquote>Google already loves the idea of JavaScript and would clearly prefer if we all just wrote every app in JavaScript for Chrome on Android, iOS, and Windows.</blockquote>

Do they? Then why do they try hard to replace JavaScript? Clojure, GWT, Dart, (Portable) Native Client...

Actually I saw several interviews with Google employees like Lars Bak. And what they say is totally contrary to what your are writing. They say JavaScript is ok for small and medium apps, but unmaintainable for large projects. And that is why I think JavaScript won't replace languages like Java or C# for large, complex business applications in the near future. Cause like you said: "Businesses want software that is built and maintained as cheaply as possible." And in my opinion this is not possible with JavaScript.
A JavaScript hater
Friday, October 11, 2013 4:29:03 PM (Central Standard Time, UTC-06:00)
@js-hater, I think it is pretty clear that neither Google nor Microsoft feel raw JavaScript is good enough. This ties in with my comments that the js world has some growing up to do, just like VB3 did back in the day.

Numerous people have called js the "assembly language of the web". I think it is a bit sad that such an ugly, ambiguous, interpreted language is our new assembly language, but perhaps we're stuck.

Fortunately most of us will probably be able to use CoffeeScript, TypeScript, or other much nicer languages that compile into js one way or another.
Saturday, October 12, 2013 1:13:08 AM (Central Standard Time, UTC-06:00)
A lot of platforms are JITting JavaScript now (including WinRT if I am not mistaken). So to a growing extent it is no more interpreted than MSIL.

That doesn't help much aside from removing the one concern.
Bob
Saturday, October 12, 2013 1:27:02 AM (Central Standard Time, UTC-06:00)
I'm not sure why you feel client Java is being thrown under the bus the same way client .Net is unless you're still thinking Windows-centrically.

Android and its Dalvik-flavored Java doesn't present the same high deployment bar as WinRT. This is both a blessing (no high barriers to individuals or LOB developers) and a curse (malware implications come with Android's openness).

All you need to do is abandon Windows as your client OS and there isn't a problem.

How practical this becomes if and when Android evolves into a desktop OS only time will tell. However Android on x86 is far from mythical and vendors are successfully demonstrating multimonitor and Android windowed applications already. Whether that goes anywhere depends on Google's plans.
Bob
Saturday, October 12, 2013 1:59:57 AM (Central Standard Time, UTC-06:00)
> This ties in with my comments that the js world has some
> growing up to do, just like VB3 did back in the day.

Ok, sorry that I read over this. But the difference between JavaScript and VB or other proprietary languages is, that many organizations are invovled in the standardization of JavaScript. That is why its evolution is so slow and why it will never catch up with proprietary languages.


> Fortunately most of us will probably be able to use
> CoffeeScript, TypeScript, or other much nicer languages
> that compile into js one way or another.

I like the idea of Google's Portable Native Client: Write your client-side code in your language of choice and compile it to bitcode, that runs on any browser, that has a bitcode runtime. Actually this seems pretty much the same idea as Java Applets or Silverlight. But I hope that this will be the future of client-side development. The problem is, that the big players like Google, Microsoft, Apple, Mozialle etc. don't grant their competitors succeeding with their technology, even if they make if Open Source. Instead each one of them invents the wheel again. And I fear that for this reason we will be stuck with JavaScript for a long time.
A JavaScript hater
Saturday, October 12, 2013 7:34:24 AM (Central Standard Time, UTC-06:00)
Hi Rocky, thanks for a nice post. I think the biggest roadblock here is Microsoft's current side loading cost model, which strongly discourages business app development on WinRT. If Microsoft rectifies this issue, I think .NET platform will continue to maintain its strength for business app development. Then, it only come down to the second issue of rewriting the same app multiple times across different platforms, in which case Xamarin should be a great helping hand.
William
Sunday, October 13, 2013 2:16:33 AM (Central Standard Time, UTC-06:00)
I have been shocked to know that C and C++ got obsolte decades ago. Exceptioanlly interesting, how embedded soft, drivers, linux and windows kernels should be written? In Javascript? :)))))
Sunday, October 13, 2013 2:42:34 AM (Central Standard Time, UTC-06:00)
First of all I have few ideas, about .Net

There are some things that I like, and some of the things that I don't like.
*Visaul Basic had been impruved and now it looks like programing language, it is vay better than Visual Basic 6 that I have started with.
But somehow people are not so interested in it anymor.
*C++ for .Net had some good points, it was not like something that I need, and some other people I talkd to. I would need some true RAD with C++ sintax, not those what_May_I_Call_That_BLALALALALAAABLBLBBL_Thing.
*And big problem of programing it is API things. Everything should be in ObjectOrijented way, not like functions that habe one name of C++, and to manny from Windows.
Why people don't fix string problems and some other.
Programer wonna develop the app throu the one enviroment, and even sell the app for 1$, and if you sell more of them you end up with uKnowWhatIMean...
Multyprograming is not solved still as it should be..., but now there is a standart and that is a good thing.
DuskoKoscica
Sunday, October 13, 2013 6:11:25 PM (Central Standard Time, UTC-06:00)
I have a dog in this fight (I work for Xamarin), but one of the reasons I *joined* Xamarin was due to a similar thought process, but with a different conclusion.

Languages matter, but so do APIs. The conclusion that the future leads to xplat JS seems to me to rest on a very questionable assumption, which is that there is and will continue to be an acceptably xplat application-level API. If one looks at the history of xplat APIs, one sees the "least-common denominator" problem: its impossible to keep an xplat API in sync with rapidly evolving platform capabilities. While this may be acceptable in many situations, you've also seen resistance *even in LOB applications* to UXs that are out of step with the underlying platform.

Of course there is a large category of LOB applications that can be satisfied with forms and a UX dictated by the company. But there's *clearly* two gaps where "xplat JS" falls short: the native platform gap (3 hours after Apple released iOS 7, Xamarin gave its developers access to iBeacons, barcode recognition, text-to-speech, 3D maps and turn-by-turn directions, and 1700 other new APIs). The other gap is at the "enterprise platform" level: persistence, encryption, logging, security, etc. While there may be JS libraries that speak to these, there is not a unified *xplat platform,* there's not even a set of reasonable defaults comparable to LAMP or RoR/Postgres (which are themselves much smaller than what you get with the BCL or JDK). JS is just not in the same league as the CLR and JVM. Might it *evolve* to be? Sure, but that evolution faces a lot of external pressures -- the proprietary interests of the "xplat JS" vendors and the pressure from AAPL and GOOG (even if you discount MSFT's ability to get back into the fight, which would be foolish).

It *may* be that the Enterprise world breaks for one of the xplat JS vendors. But IMO that will involve the wide-scale embrace of that vendor's SDK, not the triumph of "hey, I can program in JS! Give me a job!" In line with that same train of thought, I think it's *more* likely that, faced with the distasteful necessity of having to learn new APIs, they'll break towards vendors whose language offerings help, not hinder, learning. As you know, there are aspects of the JS type system that are difficult to reconcile with enterprise-size codebases and practices. Or, says Xamarin, use C# -- a language that's either known to your developers or easily approached by your Java devs -- or, if you're interested in one of the most highly-regarded languages "bubbling under the surface", use F#.

I've put my money where my mouth is: I joined Xamarin after 24 years of writing about the software tools industry (former Editor-in-Chief of Computer Language Magazine, founder of Software Development and Game Developer magazines). They're the first company in 20 years to have the potential to do what Borland-in-the-80s did.
Sunday, October 13, 2013 7:18:57 PM (Central Standard Time, UTC-06:00)
@Larry I hope you are right.

I also have a dog (two actually) in this fight: CSLA .NET and Magenic are both very much .NET oriented. Magenic can retrain to js if necessary, but it isn't entirely clear that CSLA would have a home in the js world.

I am _rooting_ for .NET and Xamarin and C# to "win" - remain a dominant platform for business app dev.

I just think this relies largely on Microsoft making it the most viable technology on their own operating systems; something they aren't currently doing with WinRT.

Wednesday, October 16, 2013 3:26:20 AM (Central Standard Time, UTC-06:00)
You all guys still don't understand what Apple is at the core. Apple is winning the mobile (tablets and smartphone), google/samsung are just flooding and fragmenting, and everyone else is just...irrelevant. Yes, Microsoft has timed out. After rebooting its strategy for the 2nd time (win mobile 6.5 dead, wp7 dead), it is still irrelevant: only Nokia makes windows phones, and only Microsoft makes windows tablet. These are *facts*.

So what is Apple? Apple is native Objective-C. Apps are king now, they are better than "a mobile website to be used with Safari". For many reasons (better pouring money is one of them).
Apple won't move from that, it doesn't care cross platform. Nobody cares cross platform. Today, developers make 2 versions (android and ios), both using native tools, and that's over.

So on the mobile I see only iOS (Objective-C) and android (Java).

Today mobile is the *center* of the business. Desktop is "legacy stuff". In fact look at the MSCD (MS certifications): there is no more desktop!! MS has only "windows 8 app store developer" certification.

Still 90% of desktop PC must use desktop software!
And we are left with WPF which is incomplete, unpolished, abandoned. Developer are left in the fog about what is the relevant desktop framework to use. MS failed here, putting 100% on Metro crap.
I have to develop back to WinForm, because WPF is too difficult to master.

.NET + C# has always had a clear advantage over C/C++ in term of PRODUCTIVITY, that still and always matters on the desktop and server for any software that doesn't need "performance".
On mobile, you want native because of the power efficiency.
Javascript on mobile is a joke, cannot even compare to Objective-C.

*Maybe* on the dekstop we will see QT winning if Microsoft will just insist on Metro crapware in the following years.

Apple iOS can communicate with any system, windows legacy, just use standard technologies (http, xml, web services, etc...), no problem at all.

As regards servers, there are tons of alternatives to .NET, not only Java, but also Ruby on rails and PHP (Zend framework).
Elle
Wednesday, October 23, 2013 1:02:08 PM (Central Standard Time, UTC-06:00)
"as I think relatively few people are going to get rich building casual games, fart apps, metro transit mapping apps, and so forth"

Well... I'm a bit more optimistic for the Fart App consumer space. I pretty much have that market cornered and hoping to profit big time!

As for the multiple comments about the C++, C 'obsolete' thing, geeze people. Reminds me long winded arguments/conversations I've had where a few select words or phrases are picked out and the whole topic being conveyed was missed. SEE THE BIG PICTURE. They have a lot of cliches for describing this sort of thing...

As for the wish to have that 'single' technology/language to work across all platforms; I think we would be ambitious to hope this could actually occur. There are attempts made or existing languages/technologies that are squeezed in to work (i.e. JS), but I think the result will not be in whole successful. I just can't see JS in it's current form being the defacto language of choice for say LOB applications. Any attempt at using or creating a '1 size fits all' technology or language will have to be so watered down to meet all requirements across _all_ platforms it might not be strong enough in any 1 way in order to please all. The old 'jack of all trades and master of none' scenario. However my crystal ball is not as good at predictions, so I would be happy to eat crow later.

Since I have been a professional software engineer inclusive of the training that led up to it there has always been that attempt at 'so and so' is going to do everything across all platforms (think about how SOAP web services was going to be the last technology we would ever need to know). The natural diversity that exists to strengthen each languages characteristics will also most always distance it as any medium that will work across all platforms for all needs. Therefore my best guess will be that most businesses will continue to invest in either writing things multiple times and keeping each code base up (or use something like Xamarin to help close that gap) or laying down the law on a particular OS for native OS needs.

And don't forget about the web! A good old fashioned web app still can reach the masses with a familiar server language and client one (i.e. C# and JS). But even browser inconsistencies make this even not work perfectly for _all_ devices and all platforms perfectly.

Hey the old "It's going to be supported on Windows only" is still not out of the question as each scenario has to be evaluated individually. For a brick and mortar business creating internal developed applications to support that business and not selling 'widgets' to the outside world, they can most certainly have the luxury of a single implementation like the Windows desktop. Do we really need a iPoop version of that HR or accounting application? In many, many scenarios that answer is a clear 'No'. The thing is we are caught up in Twitter and other 'store' type apps that make us think about serving 'everyone'. How often do we _really_ need to serve and service _everyone?_ Probably not as much as the current discussion are debating about it.

However, this is all very good conversation and it's important to be aware and discuss these topics regardless of what vacuum we each work in each day.

Very, very nice article Rocky.
Sunday, October 27, 2013 7:27:19 PM (Central Standard Time, UTC-06:00)
A few random thoughts about .NET, h5/js and other such madness:

.NET is definitely not going away, it's a mature platform now and even if Microsoft ends itself someone else will pick up the torch. The .NET Micro Framework gives us a (partial) open-source implementation already, not to mention outfits like Xamarin. C#, like C/C++, will still be used in 2113.

For JavaScript to be taken seriously as a development platform it must exist outside of a browser; I'm not aware of anything that currently does this or anyone who really wants to do this since there's a general agreement amongst non-web developers that JS sucks. From a developer standpoint, what makes .NET and Java so appealing is once you learn it you can apply your skills across the whole of software development, you don't get pigeonholed in a particular field like websites or data analysis.

With that in mind Java holds a lot of potential as a universal platform, but it's been dogged by a fractured developer community and a number of performance and security issues. It could succeed but only if someone steps up and invests some serious resource in making it "just work". It's clear that Oracle doesn't care, and never did beyond their failed bid to extort money from Google, but perhaps someone else does. The core framework is all GPL and Crazy Larry unwittingly created legal precedent to prevent anyone from ever locking it down.

Platform agnosticism is going to be what ultimately determines success. Mobile is a big deal but it won't eat the world and even in mobile there's no clear signs of a universal OS (I predict Samsung forks Android within three years). Current PCs will live for years if not decades because they get the job done. Everyone's fired up about "the cloud" and web development right now, but the NSA scandal is the beginning of the public waking up to the difference between how slick tech companies say the Internet works and how the Internet actually works. The usability and compatibility gap between Windows and Linux continues to narrow, and Valve is about to launch a serious push for Linux gaming. The technology landscape of the future is going to be very, very fragmented and I don't see another Microsoft sweeping in like the early 90s and uniting the warring kingdoms--there are simply too many powerful players with mutually exclusive interests for that to happen again. Thus developers will need to maximize the number of boxes their code can run on.

All of this suggests a bright future for technologies that aren't locked to a particular vendor or platform. Whether that will include .NET remains to be seen, but the worst case would simply be that C# becomes an old warhorse like C++ that isn't sexy but everyone still uses.
Bogus
Comments are closed.