A lot of people are freaking out about the apparent decline of .NET client technologies such as WPF and Silverlight. I’m one of those people. How can one, in good conscience, advocate new development in WPF or Silverlight (or Windows Forms)?
Well I can advocate it, I do advocate it, and I’m sleeping well at night.
A recent comment to one of my post on WinRT provoked an outsized reaction that has become this post. Here’s that comment:
Given that most people who are skilled in HTML5+JS write applications that are cross-browser and cross-OS every day; why would they ever consider writing for a single OS?
This fellow managed to capture in a few words the current mood and madness. My rant follows:
Who are you kidding?
First, hardly anyone is skilled in HTML 5. Period. That’s just wrong on the facts.
Secondly, most people “who are skilled in HTML + JavaScript” – cross-browser or otherwise - do not have a clue how to write a business application in JavaScript.
Most people who write apps that emit HTML do not write much JavaScript; they exploit controls that rely on JavaScript and they may write a little decorative JavaScript but that's the extent of their experience.
How do I know that? I've been hanging out where the experts in JavaScript hang ... and the recurring verities are (a) most people write horrible JavaScript (hence the need for Crockford's "JavaScript - The Good Parts"), the apps are almost unmaintainable when they do, and (c) the appropriate design and implementation patterns for JavaScript are in flux.
This is a fascinating and creative time in the evolution of JavaScript programming. New frameworks are popping up left and right. Lots of lectures and discussions about how to do it right. That's all healthy.
But the sheer wildness and variety of competing and overlapping toolkits/frameworks/guidance reveals the immaturity of the JavaScript environment as a business application development platform.
Get real about business application development
Let me be crystal clear about what I mean when I talk about a "business application" … because I want to confine my remarks to just this one kind of app. I take a completely different position on the appropriate development and delivery platform for other kinds of applications. This post is about business applications only.
[Warning: I will delete every comment that attempts to refute my argument by reference to any other kind of application. I will be especially dismissive of counter-claims which only make sense with regard to consumer facing, social networking, content broadcasting apps. You are simply not paying attention if you respond in that way and I will not waste my time or my reader(s) time with your inappropriate reply.]
Here is what I mean by a “business application”:
- It is a "sovereign app". That one app will dominate a user's attention for hours at a time, day after day.
- The user is paid to use the app. The person who pays him/her requires that user to get work done with the app as quickly and efficiently as possible.
- It is data-centric. The user consumes a large volume and variety of data. More importantly, the user routinely adds and updates that data in all of its variety.
- Therefore, the app must be highly responsive and immersive in order to maximize user productivity. It must present data and accept user input at top speed. Every moment spent waiting or wondering or searching around or flipping pages is wasted user time and wasted business owner money.
In my experience, the only apps that hit the required standard of user efficiency are apps that execute predominantly on the client. I don't care if its written in Windows Forms, WPF, Silverlight, Java, or in JavaScript ... it has to execute on the client and make only the minimally necessary trips to the server.
This is the context for answering your question. Why would I write for one OS?
If I'm writing a business app, in all likelihood there is only one OS that matters: Windows. Windows just happens to own 95% of my targeted user base (my estimate) ... today and for the near term.
[Note: The OS-on-a-PC figures are imperfect but the consensus is that Windows has no less than 88% share of all PCs which includes home PCs. Home PCs don’t matter for this analysis.]
Don't bother telling me about mobile. Don't bother giving me statistics on web traffic by OS (where Windows gets 86% of 2011 web traffic, btw). Don't tell me your vision for the future. This discussion is about business apps today and they run on PCs ... period.
If the time & cost of developing and maintaining business apps in HTML/JS were anywhere close to the marks of a .NET client platform I'd say "go HTML/JS".
But they aren't. Not close. Not soon to be close. And that fact is nowhere in dispute, not even among the most ardent HTML/JS fans.
So, as a business person, I've got a decision to make. The economics of today tell me "build it in .NET" because I can do it cheaply, effectively, with great quality using readily available resources, mature tools and experienced developers.
Of course, as a business man, I'll be concerned about the future and the long-term viability of my application. I’m perturbed that the app I am building today will be seen in 3 years as pinned to a legacy technology. That's a tough pill ... and it's why there is so much consternation. No one wants the “legacy” sign hanging around his neck.
But it’s not like everyone is going to forget how to write in .NET. Support won’t vanish. I will be able to find technology and people to keep the application alive in ten or fifteen years. I’ve got time to amortize my development costs and prepare for the inevitable transition(s) down the road.
The alternative - writing a business app in HTML/JS today – makes no economic sense. It doesn’t give me more reach because there are virtually no targeted users that I can’t reach today and for years to come. They are running Windows.
For sure the application will take 2 to 3 times as long to build in HTML/JS. I don’t have – nor can I find - the developers with the skills and experience for building an app like mine. The tools and frameworks they need don’t quite exist yet; the current prototypes are re-released with breaking changes every couple of months. My developers will be following half-baked implementation regimes, borrowed from other platforms (… oh, like .NET), that are as yet unproven for JavaScript business apps.
Yes … I could trust my critical business application development to HTML+JavaScript … if I’m a nutter.
Summary
Let me net it out for you:
- A tiny % of today's developers are capable of writing an HTML/JS business application.
- There are almost no examples of such apps today and almost no place to go to learn how to make them.
- For most business apps there is only one OS that matter: Windows
- The economics of developing a business app that runs on Windows are vastly superior to the economics of developing a business app in HTML/JS.
All that can change. All that will change. But not this year, not next year, and maybe not in 2013 either.
If you have the luxury of screwing around, have fun in HTML/JS. I know that I have that luxury and I am, indeed, having fun.
If you must write a business app for delivery in the next 12 months, do it in a .NET client technology.
Update 11/12
A discussion of this post has emerged on a G+ thread that you may find entertaining or even illuminating.
45 comments:
One nitpick. Stating something like
"most people who are X...." is not inconsistent with the claim
"hardly anyone is skilled in X..."
Both can be true at the same time.
Which means the following sentence should probably be removed.
"First, hardly anyone is skilled in HTML 5 . Period. That’s just wrong on the facts."
With due respect, I disagree. "Hardly anyone" means "rare". I was highlighting the "5" in "HTML5". People who are skilled in "5" are rare (relative to the population) if for no other reason than the "5" hasn't been around that long.
"Most" means at least "more than half" and is intended to get you thinking "80%?" or "90%?". The other 20-10% are not rare; they are fewer than most. :D
When you bank on a specific proprietary technology you can bank on something else: one day soon it will be obsolete and irrelevant. Take a look at history: visual basic, access databases, and asp :) how many poor souls are trudging through their work using software built in these lacking tools. Years ago, I remember watching a major carrier's employees get brand new dell laptops only to wipe windows 2000 off so they could install win 95 and continue using their in-house apps... they looked pretty sad.
How is it that there are only two choices- .net vs HTML/JS? What about Java, C, C++, etc? By your definition of a business app, the ultimate would probably be MS Office... which is not written in .net
I have to agree with Anonymous #1, languages don't die, they become zombies and suck on poor developers brains. XAML apps won't die, just like there are still Foxpro apps actively being developed. They are business apps and often it doesn't make business sense to redo them in whatever the latest and greatest language is. The only problem is when developers of x become so scarce and cost so much it then starts making sense to rewrite the app.
I don't understand why do many developers are getting their panties in a twist over x language is going away. BS, it isn't going away. And if you can't learn a new language then maybe you should not be a developer.
It seems to me that the part that bothers you the most about programming in HTML5 (yes javascript, css, and html) is the diversity and variety.
You are correct that component toolkits lower the skill level required to write application code. Javascript's toolkits and libraries are diverse and, many times, unpolished (welcome to open source - see Java libs).
Without the aid of drag and drop toolkits, most so called programmers find themselves lost. So, yes, it takes someone that understands programming and the platform they are programming against.
The question is, do you not blame the state of corporate software on the fact that these programmers don't understand those things? My experience is that the blessed toolkit with visual tools leads to a proliferation of bad architecture and bad code. Have you seen something different?
I've built some business apps in Php and Asp.Net a few years, after that I went with Silverlight. What can I say - Silverlight is a far better tool for the job. We have over 1 million lines of code in the current app. It's not a simple forms/grids apps, it has complex custom controls to manipulate the data. I can say it would have been impossible to do that and maintain it in Html/JS.
Can you elaborate on some of the business functions that can only be done in .NET? Please refrain from saying something along the lines of connecting to Outlook or some other Microsoft specific technology.
As for the claim that "hardly anyone is skilled in HTML5," you're saying that as if HTML5 is a completely new language, rather than an evolution of existing standards with additional functionality. I guess the only validity in this statement is the fact that the HTML5 spec hasn't been finalized yet. Therefore it's possible to say that you can't know something that doesn't entirely exist; however, this is just semantics and a rather weak argument.
It does seem like you are making some unsubstantiated claims. Your entire post feels more like narrow opinion rather than fact. I’ll give you the speed of development in .NET, due to the drag and drop nature. That being said, as @LES has pointed out, the design of such applications can leave a lot to be desired and often result in poorly designed products which is part of the problem with many of the corporate systems that were built on .NET.
I agree with everything said about building "Business App".
The issue is, MSFT doesn't understand their strength/advantage/opportunity on this space.
The best part, MSFT goes (so called) open standards, silent on Silverlight and google goes 'DART'. Now what!!!
Probably the only people who create true business (to business) apps in Javascript are Google, and they use Java to do this with.
For everyone else HTML5 and JS is just a bit of UI gloss
The discussion about Html5 always leaves out the job market. It isn't there yet. Or at least not on the radar. There are tons of ASP.Net jobs still. Some MVC, some web forms (oh yeah). In my geography Silverlight never made it on the radar of recruiting agencies in the 3+ years I've been working with it. They don't know what RIA is in this neck of the woods. But the point I would like to make in this context of the job market is this. Project managers, hiring managers, and technical decision makers are all hearing the hype about HTML5 and they are acting now on that hype. Even though I agree Windows is the most widely adopted platform for business applications, those people are making changes to their projects and organizations to adopt some form of Html5 strategy. Developers don't get to decide what the market will do and will have to accept jobs doing work that less technical middle managers and CFOs decide to do. Developers are at the mercy of the job market, not the other way around. That said, I'm hoping to be building business applications using Silverlight and soon Xaml for Windows 8. At the same time I am experimenting with patterns and tools for developing applications that are scalable, maintainable, testable, and performant in jQuery and Html5.
Is this aimed at managers or developers? If managers, then yup, agreed. If devs, nope, disagree. JS is coming and if you have a chance to do a big ass app in JS because your manager didn't read this article than god damn yes, do it. everything you need is there and ready for prime time - it's just not as drag and drop as .net controls.
And, in the spirit of making your boss happy, no matter what this article rightly states: mobile matters to management even if the business case doesn't exist. You will be a hero and you'll be ready for 2013. Read the crockford book and then just do it.
To everyone who thinks I said HTML/JS are bad ... please read me again.
To everyone who thinks I said you can't write an HTML/JS business app ... please read again.
I am enormously encouraged by the activity, excitement, invention, and future of JavaScript.
I am not the least bit afraid of JavaScript ... or of any s/w techology. Drag-n-drop development has its proper place ... and it's idiotic to deny that ... but I've never made a living doing it. If you knew a thing about me or my history you would know all this. So let's dispense with the insults and phony psychological presumptions, 'k?
My case for Business Apps in .NET is purely about prudence. Is now the time for a company to bet the farm on their ability to build a business app in HTML/JS?
I say no. The ecosystem is not ready. You can't be as productive ... yet. There aren't enough experienced Single-Page-App JS developers to go around ... yet. The appropriate patterns and practices for building large, multi-screen, data-centric apps in client-side JS are just not mature ... yet.
Meanwhile, if you target Windows machines, you can do a great job with a XAML-based platform. I mean a GREAT JOB. And do so economically.
Not a one of you has made the case that the XAML-based app will fail the business in any way. The best you can do is say that it will be obsolete some day. You can never go wrong with that prediction.
If you have $500,000 of your own money to spend on what is today a 300 screen bus. app and you have to deliver something of comparable capability in six months that will run on a PC ... you don't do it in HTML/JS.
Of course if I have $500,000 of YOUR money, I might take it spend and it on an HTML/JS adventure (or on ice cream for the kids). Because I LOVE playing with technology on someone else's nickle.
@Les - Let me get this straight. If I program in the .NET environment, I'm a doofus condemned to produce bad design, bad architecture, and bad code quickly with drag-n-drop.
But if I write it in HTML/JS, I'm a friggin' genius who carefully analyzes the business requirements, communicates effectively with management and the team, architects the app to meet present and future demands, designs a gorgeous UX, write automated tests to ensure quality and long term maintainability ... all at the cost of a slightly longer initial schedule.
Wow. I didn't know that a technology could be so transformative.
@anon #1 - If you think HTML5 is simply an evolutionary step than I don't think you get what's going on. If you program in HTML5 as you do in HTML4, fine.
But to make productive use of canvas, animations, offline storage, etc. takes the kind of skill and experience that few can claim. The "5" in "HTML5" means something.
If it doesn't mean anything to you, than you're programming in HTML4 ... with a few enrichments. I've got no problem with that. Just say so. But know the difference.
Had a good laugh at what you have to say. Sounds super one sided and closed minded to me. Also, you sound like an MS evangelist ragging on anything other than from the oh holy MS. Then I read your bio "Ward is a Microsoft MVP and the V.P. of Technology at IdeaBlade (www.ideablade.com), makers of the "DevForce" .NET application development product." Need not say anymore. Good thing I only ready a few sentences.
Well we will have a more robust and unbiased conversation over here on G+ https://plus.google.com/u/0/118303283951449952966/posts/iQG1JWqENZX?hl=en
Yeah, the last anonymous post nailed it. Your really bias and closed-minded and because you have tunnel-vision you don't know enough about the surrounding landscape to refute it.
-- "But to make productive use of canvas, animations, offline storage, etc. takes the kind of skill and experience that few can claim. The "5" in "HTML5" means something."
Okay, but that is why we have frameworks and such (.NET calls them libraries) so you can harness features without knowing the ins-and-outs and so you're not recreating the wheel.
> For sure the application will take 2 to 3 times as long to build in HTML/JS.
I don't think that's necessarily true. While there are less developers with skills in that area and the frameworks perhaps less mature, if you do know the language, you may find it very productive, and in particular, more productive than if you did it using some other technology.
The author Ward is 100% right. I will offer a series of explanations of why non-.NET platforms made headway. First, most developers do not write serious business apps. The vast majority are literally enhanced web pages for mom-and-pop small businesses. Second, these developers probably never coded much in a team--and perhaps never even took CSci courses in university. Third, these developers hate Microsoft for various political reasons. Fourth, Google, Adobe and others, rivals of Microsoft, are pushing non-.NET platforms. Fifth, many built for speed apps like the London Stock Exchange project were built in C# but switched because of the (slightly) faster raw speeds a less failsafe language like C/C++ (traditional) offers--same goes for embedded systems designers. Sixth, due to the famous "Redmond divide" between Outlook and Visual Studio at Microsoft, unfortunately Microsoft itself has contributed to perception that Silverlight is dead. Add these reasons and others together, and it explains the present reality that .NET is dying. But Ward Bell is spot on, period.
Hi Ward, your article tastes like honey to me! I hate JavaScript - and i seriously think, that it is not made for real world business applications - at least - I would't use it to create REAL business applications. Storytelling from the marketing department...
I agree with Ward. If it is MY business I am going to use LightSwitch. The reason is that if it is MY business and I am burning through MY money then I want the 98%+ savings in development.
I also agree with the people who posted about the job market. My landlord could care less about Silverlight vs HTML5.
You will find me in my cubicle during the day programming a lot of JavaScript...
I am posting this because I have wrote - WinFoms, WPF and Silverlight apps. Period. ;)
I am not sure about your point on "minimal trips to server". Because as you said LOBs are data centric - so they must access database = server round trips. Unless you are suggesting local storage.
Also as simple thing as event handling should be thought well before writing LOB in any of client app in .net - this answer your claim on - "hence the need for Crockford's "JavaScript - The Good Parts"
Finally no one has heard bad XAML project because they have already invested so much in it - they can't afford it to say "it failed".
There is no easy way to write business applications in. Net or Html5/JS. Regardless of the technology must continually improve, when to start, if not now
One of the problems with developers today is that they are often not very seasoned in the industry. I don't mean they aren't smart, what I mean is that they haven't been around long enough to understand that there will always be yet another tool or technique, and that there never is a "one size fits all". This is why the ecosystem is so diverse, and for anyone who believes that a single technology will rule them all just hasn't been around long enough to have experienced the cycle this industry goes through. I've seen the waves of structured design, rapid application development, object oriented, client server, web, and the the list goes on and on. The point is that this industry is about change. If you can't take the experience you have from one platform and learn to apply it to another, then you really aren't prepared to be successful in the long term.
The second problem to me is that many developers haven't gained the wisdom and experience to understand that developing software is less about tool set as it is about how to properly gather requirements, understand user needs, design delightful experiences, and many other factors that have little to do with the tools that you end up using. Our tools are light years ahead of what we had even 20 years ago, yet I still see developers struggling to deliver great software. Not because of tools, but because the biggest challenges in software aren't technical, they are human. But most new developers want to take the tools they are most familiar with and apply them to everything, not understanding that to a user the technology you used to build an application isn't relevant, they don't care. Users do care about the experience, capabilities, and costs involved.
As for the anonymous post that claims that "when you bank on a specific proprietary technology..." you become obsolete. I'd have to disagree as I have developed now for almost 30 years with many proprietary technologies and am still completely relevant in the market. The difference is that I can apply my learning forward to the next wave. I'm currently employed in a great position with a solid 6 figure salary, work with pretty exciting technology on a daily basis (phone apps recently), and continually have offers for new opportunities. But that is less because of the technologies I've used but the proven success I have in using them. You'll find that a smart employer, and I personally prefer to work for smart employers, are looking for people who can adapt and be successful with any technology, not just one. So if you think that because you've chosen open technologies you will be relevant longer, let's swap stories in about a decade and see how well it worked out for you.
This html5+js IS NOT cross platform! it's tied to the WinRT API.
The problem with all this "shift" for me is that it is the first time I have a feeling I am pushed to inferior (yet, maybe) technology from the technology that fits my development's needs perfectly. I just see gaps where I do not have them now. I see advantages too but there are not so many to justify that shift.
It's like I am pushed from all my languages I use in .NET back to VB6 with an argument that it is a most abundant language in the world. (It's incorrect comparison, strictly speaking, but same emotions)
On the bright sight - I know, from the previous experience, that this will never happen. Trend will change exactly the moment HTML5 will succeed:)
What's going on here is not about HTML5/JS. MSFT could care less about it other than this vast # of JS developers could turn into potential Win8 buyers. What's really going on is that Windows team wants to kill SilverLight. They wanna do it really bad. As if it were not bad enough, Office team wants to terminate it as well.
Win8's attitude toward HTML/JS is nothing but a classic Embrace, Extend & Lock-in tactic. If you could get those JS people love Metro then you could sell lots of Win8 and Win8 tablets so there MSFT goes to show HTML/JS folks love - embrace - while tying their HTML/JS support to a proprietary WinRT - extend - that way these JS guys could get stuck with Win8 from now on - lockin. It might not be the smartest strategy but it would not hurt much trying either.
The real story is the public execution of SilverLight. Windows and Office teams could not sleep well knowing SL is out there. Not only SL does not make money on its own it threatens both Windows and Office teams if it keeps getting better and becoming a real rich internet platform. People might not need to buy Windows any more with SL. Google could re-write their current laughable Google Apps in SL to finally hurt Office team's market share.
ABSOLUTELY UNACCEPTABLE TO THE WINDOWS AND OFFICE TEAM!!! CANNOT ALLOW THAT TO HAPPEN!!!
This is MSFT. You know what's gonna happen when you mess with those two teams. The rest is history.
This comment "Embrace, Extend & Lock-in tactic" nails it, speaking to the fact technology is now more of a market moniker than it was 10,20 years ago. As long as both consumers and developers buy in the hype of html5/js it sells, which is really what matters to the "business" decision, not truly a developer's yet heavily influenced by developer community. The concerns of .net community is more related to career and less about the right tool to create solution. LOB will continue to be developed in .net knowingly UX is driven by the consumer demands and soon by business too will enjoy most of future proof progress in html5/js than SL or .net. That is a fact and history just kept on repeating itself for anyone hang around long enough such as those who used to be a VB programmer had to move on to CLR 10 years ago. For that matter, VB6 LOB did last for a few years until recent time. So Microsoft is simply pulling the same trick again and you'd have no choice but carry on, unless of course one learnt from history and willingly spent own time (or business time) for self-training of anything outside of Microsoft's domain so prepared. The current game in town is mobile, html5, even mighty Microsoft has to watch it. Both Windows shell and office are moving towards it is the proof, so will be LOB soon or later.
Just stress the point, a worth read of how the future LOB will be shaped, http://www.thephoenixprinciple.com/blog/2011/11/how-best-practices-kill-productivity-innovation-and-growth.html that explains why Microsoft has to make such a dramatic turn while there is no immediate threat from anywhere, much less to LOB, but the clock is ticking.
@Arcadia
"..VB programmer had to move on to CLR 10".
Totally not the same. VB.NET promised better technology and everyone understood that. The problem was MS did not provide the way to migrate, or backward compatibility and that made a lot of devs cry.
Currently we are pushed to the technology that it is not better. It's on par at best. In future. Maybe.
It has only one advantage - it's cross-platform (provided you use right subset) which is not much of advantage for business development.
I've worked with silverlight very little, some client resizing of images before upload and that's it...didn't have oportunity to code business application, I am asp.net mvc guy...So I have half statement half question...
When your team code silverlight application I suppose "the heavy lifting" in terms of complex business validation, tests, business logic, all done on server and in app you have manipulations with data through silverlight controls...we now have js controls for this and that and it works fairly nice and good...could you explain it to me/us here, what is in client side developments with c# knows as silverlight so advanced comparing to js tools/frameworks?
thank you :)
A lot of "statements" since I last checked in here. I don't feel the need to comment on them one way or the other at this point.
But MARKO asks a question and it is an interesting one, reflecting the experience of someone whose career is all server-side app programming and no-or-little client-side programming.
The Silverlight programmer tries to do the "heavy lifting" Marko describes ON THE CLIENT, not on the server. Trips to the server communicate mostly requests for data and requests to save (change-set of entities attached). The volume of traffic is governed mostly by these kinds of requests.
It is also true that the server should revalidate save requests and all other commands. But that's it. And these activities do not interfere with the user's experience.
In Silverlight, presentation, navigation, application state and workflow is all handled client-side in plug-in hosted in a Web page. From a web perspective, there is only ONE PAGE; this is a "Single Page Application" (SPA).
Most MVC apps don't work this way. They serve pages back to the client based on requests. Yes, you can ajax-ify to minimize page churing. But that tends to be more the exception, especially in apps with many pages (let's say, >30). Such apps cannot compete with SL for UX responsiveness nor ability to survive connection disruptions.
If your entire experience is with apps that serve pages, it is difficult to explain how much different and better SL is. How do I compare a car to a horse if you've never seen a car? You think you have the same capabilities with JS UI controls. But (a) you don't and (b) it's not really about the controls! It's the programming model that makes SL superior for LOB apps.
Let me be clear. I am saying SL is superior to a comparatively stateless HTML app that serves pages to the browser.
BUT ... and the following point is incredibly important ... there is a relatively new breed of HTML/JS app that competes well with SL on UX responsiveness and ability to work in partially connected scenarios: the HTML/JS SPA!
H5JS SPAs look very promising to me. They can handle rich state management, validation, presentation, etc. on the client with no less efficiency than an SL app. They can minimize server trips as an SL app would do. They can go offline and even launch offline if the browser supports the requisite local storage.
This kind of HTML/JS app is suitable for LOB app development. I think the eco-system around it needs to mature ... but it is coming.
"...there is a relatively new breed of HTML/JS app that competes well with SL on UX responsiveness and ability to work in partially connected scenarios: the HTML/JS SPA"
Ward, could you please provide an example?
I am very interested in this scenario myself, and what comes to my mind is some sort of knockout/backbone client with server provides data/metadata in json.
I would really like to see a real-world example of that approach
Have you guys ever heard of C++ Builder? THAT was a tool to design massive LOB in no time. The .net IDE is still a big joke when it comes to RAD. C++ Builder was full C++, had a quick compiler/linker and a very slim runtime. It had tons of extensions available... but it was not from MSFT.
However, MSFT had WTL, which allowed to create close to API, native Win32 apps and MSFT used it internally a lot but never promoted it in public much.
I recently looked at XAML and as a C++ programmer I will probably go with HTML5+JS any time before my eyes start to bleed from XAML+C#. Take the namespace madness which clutters up the whole markup. The non CSS styling...
Data binding is dead simple in WinJS and in one year, when Windows 8 hits the streets, we will see how much WinJS business apps there will be.
.Net really very powerful and protected language. And easy to use any hardware.
Yes, JavaScript is still in an immature state right now where there are a small portion of people that _know_ exactly how to write good JS and there are a large amount of people that just sprinkle jQuery.
Not to mention that the language itself has more warts than any other languages out there.
It is growing however, to the right direction nonetheless. Therefore, it is _maturing_ (who would've thought eh?)
Having said that, there are tons of crappy .NET developers as well. I don't see a lot of .NET developers that write automation test. Plenty Windows based shops are still living in the past where they would hire tons of QA to do manual testing (that doesn't scale).
The sad part of this ecosystem is that the QA skills aren't increasing either. The whole thing held everybody back. Very sad.
Here's another problem with .NET ecosystems: too many friggin frameworks that MS try to push to the developers' throat.
I met enough developers that keep pushing the latest greatest frameworks from Microsoft (WF, .NET Remoting then WCF, WinForms, Silverlight, WPF, etc) to know that Microsoft .NET is just as immature as JS.
It took them a long time to bow down and start preaching best practices in regards on writing testable application. Even after that, they still provide less optimal support when it comes to automation test (MSTests relies heavily on internal of .NET). Makes you wonder why MS hires tons of SDET (Software Design Engineer in Test) to test their systems.
In 2010, MS (or someone else) releases NuGet. That is very very sad. Maven was out there long time ago and solve plenty problems that .NET ecosystem is still lacking.
Ok, enough of these whole comparisons stuff.
I've been watching BUILD videos lately and it's a bit strange to see that most of them are pushing this Metro Style Apps in JS/HTML.
You know what Gretzky says? "skate where the puck's going, not where it's been"
Last but not least, I have not met a user that loves to use LOB app. Never ever ever.
Most of them don't want Web Apps. They don't want WPF apps. They don't want Silverlight with immerse experience.
They want console apps like this: http://www.codeproject.com/KB/dialog/FFCA/FFCA01.png
Why? keyboard shortcuts. No mouse.
as far as i know HTML5 to search engines will pay more attention to HTML5, therefore there a lots of internet marketing used it.
Ward .. always on the button .. well done.
Quite simply if HTML5 'cut it' then there would be no need for iPhone apps or Android apps. But it only 'cuts it' in some arenas .. so other more sophistcated solutions are required .. enter iPhone apps, Android apps and 'hey presto' Silverlight.
I have had a 30 year career developing Microsoft solutions for the business world. We need .Net and Silverlight.
I have been using HTML and Javascript on an IBM ISeries using CGIDev2, running Apache for almost a decade to create business applications. They meet all your criteria, plus are actively debuggable, access services running on the the ISeries which are also actively debugable. Since HTML 5 is just HTML on steroids (new tags), I don't see anything wrong with developing the front end in HTML5 + Javascript and the back end in anything you like, be it RPGLE, Cobol, C, Java or a .net language.
It's actually kind of fun seeing all the Microsoft people backpeddling. I've been working on an IBM ISeries for over 10 years, using RPGLE programs to generate HTML and Javascript (utilizaing CGIDEV2), post it to an Apache server and listen for a response and process accordingly. It gives the user a wonderful and fast experience. Now that HTML5 is out, I can't wait to use the new features.
Great post ! I so appreciate this site. This is the information I was looking for.
For now, I think Ward pretty much has a handle on it. If you are writing a business application today .NET is a solid choice. (I would say that JAVA is also a reasonable choice in some areas of the country.)
The thing that gets me about the whole HTML5 + JS hype is the way everyone likes to ignore the back end. They act like it doesn't exist. And without some shift beyond HTML5, these apps will continue to require a back end written in something else. (Well perhaps one could use NodeJS.)
As for the being upset at the (alleged) demise of .NET. Get over it. First, it hasn't happened and won't happen in the next couple of years. Second, it will eventually happen so pay attention as new stuff comes out. If you have a career in IT and plan to stay in the game, you will learn new stuff at fast clip. Compare .NET 4.0 to .NET 2.0. Huge changes, and more is already in preview stage.
Post a Comment