Why Microsoft has made developers horrified about coding for Windows 8(arstechnica.com)
arstechnica.com
Why Microsoft has made developers horrified about coding for Windows 8
http://arstechnica.com/microsoft/news/2011/06/html5-centric-windows-8-leaves-microsoft-developers-horrified.ars
31 comments
I read that a couple days ago and here are the two most interesting posts...
Microsoft's own immersive html application is just a thin layer over native code
http://forums.mydigitallife.info/threads/26404-Windows-8-(79...
.NET Ahead-Of-Time compiler is probably coming
http://forums.mydigitallife.info/threads/26404-Windows-8-(79...
[EDIT]
And for those worried Silverlight developers, scan that thread for DirectUI.
Microsoft's own immersive html application is just a thin layer over native code
http://forums.mydigitallife.info/threads/26404-Windows-8-(79...
.NET Ahead-Of-Time compiler is probably coming
http://forums.mydigitallife.info/threads/26404-Windows-8-(79...
[EDIT]
And for those worried Silverlight developers, scan that thread for DirectUI.
Is this what the "IE is native" PR claims are about? That HTML DOM and CSS are going to map directly onto the window system instead of a virtual window (or whatever it is called) in the browser engine?
Microsoft earlier explained that "native" means "not cross-platform".
Er, no, they didn't. They mean fully (or significantly more fully) hardware accelerated, and they've said that many times - hence all the benchmarks of 2D canvas in IE9 vs Chrome.
Personally I think IE9 is a shitty browser - no 3D context for canvasses, gradients, history, or 3D transforms. But you don't need to represent MS to prove that.
Personally I think IE9 is a shitty browser - no 3D context for canvasses, gradients, history, or 3D transforms. But you don't need to represent MS to prove that.
It reminds me of the old joke: Microsoft knows about cross platform code, as some of their stuff runs on WinXP and Vista
http://www.winrumors.com/silverlight-isnt-dead-its-the-heart...
There is another article too in relation to this. Also, Mary Jo Foley and others have posted 'information' about Jupiter and whatnot.
It seems people are quickly taking advantage of this 'outrage' on the internets for some 'good' news stories.
There is another article too in relation to this. Also, Mary Jo Foley and others have posted 'information' about Jupiter and whatnot.
It seems people are quickly taking advantage of this 'outrage' on the internets for some 'good' news stories.
Looks to me that it's not so much that "the CLR will become first class" as they've broken down the CLR and .NET into little pieces (GC = SLR/Redhawk, type system/metadata = WinRT/WinTypes.dll, XAML = Jupiter/DirectUI, C# = the new AOT compiler, if it exists), and are using each one individually where appropriate.
I'm not horrified and I don't know any Windows developers that are (although I'm sure there are some out there). This is being blown way out of proportion, I believe.
Edit: I especially like the assertion that WPF is not fast. Evidently the author has never done much with the 3d transform functionality in WPF -- you can do insanely performant graphically-intensive apps using it. The fact that most developers don't understand how the API works doesn't mean the API doesn't kick ass. I'm not a fan of XAML, but everything else about WPF is really, really nice.
Edit: I especially like the assertion that WPF is not fast. Evidently the author has never done much with the 3d transform functionality in WPF -- you can do insanely performant graphically-intensive apps using it. The fact that most developers don't understand how the API works doesn't mean the API doesn't kick ass. I'm not a fan of XAML, but everything else about WPF is really, really nice.
> The fact that most developers don't understand how the API works
This signals a usability fail in my mind.
This signals a usability fail in my mind.
They made it very easy to get things up and going, and easy to optimize if you understand that graphics and WPF work. Most people don't, which is why most OpenGL and D3D apps that haven't been heavily optimized over time are very slow; graphics are hard, even without the extra burden of understanding how your GUI layer functions. It's easy to shoot yourself in the foot with WPF, but it also makes it easy for people to design really efficient apps if they take the time to learn how it differs from other GUI toolkits.
I see it more like sometimes shit is just hard to do well, taking time and effort to learn, and some developers don't put in the required work to reap the rewards.
I did find the official WPF docs and examples rather simplistic. Most of the advanced stuff I luckily stumbled upon on forums or blog posts. Perhaps developers don't have enough information to build upon the simple examples.
I believe most, if not all, of MSDN now supports user-contributed content alongside the API refs.
Thus, it would serve your fellow developers if you were to annotate the lacking documentation with (1) example code or (2) pointers to the blog postings that you found.
Thus, it would serve your fellow developers if you were to annotate the lacking documentation with (1) example code or (2) pointers to the blog postings that you found.
Nah the API just uses a different pattern from the "classic" WinForm development that most developers are used to.
A simple to medium complexity WPF app will be slower than its Winforms or Win32 counter part. It will use a lot more memory too. There may be ways around this but why can't MS optimize it instead of forcing every developer to jump through the same hoops?
Higher than "simple to medium" scale/complexity situations are probably their priority when it comes to optimisation, on the basis that most smaller scale/complexity apps won't experience the difference and those that do can be tweaked by the programmer. A major factor to consider when optimising anything particularly something as generic as a large framework is that an optimisation for small scale situations can have a detrimental effect on larger ones (and vice-versa, though as problems are more noticeable on larger scales of size or complexity optimising for that at the expense of the smaller situations is the better over-all choice in many cases).
Exactly. Bubble-sort is really fast for more-or-less pre-sorted data. But it's terrible in the worst case.
> why can't MS optimize
They can. They just prefer to make every Windows developer jump through hoops, as it's so much more cost-effective.
They can. They just prefer to make every Windows developer jump through hoops, as it's so much more cost-effective.
Hey look, it's this guy. Troll of every Microsoft thread.
This strikes me as a particularly un-HN-like comment. Accusatory tone is not a valued conversational technique here.
Be mindful of not slipping into the more emotional tone that some have observed nipping at the edges of the HN community.
(I don't mean to sound as if I'm speaking from a position of moral superiority, nor expertise with regard to the topic at hand. Just an observation and suggestion.)
P.S. For the record, I did not downvote anything. That is coming from elsewhere.
Be mindful of not slipping into the more emotional tone that some have observed nipping at the edges of the HN community.
(I don't mean to sound as if I'm speaking from a position of moral superiority, nor expertise with regard to the topic at hand. Just an observation and suggestion.)
P.S. For the record, I did not downvote anything. That is coming from elsewhere.
I can hardly afford the time it would take to do that.
Besides that, I think my assessment of the situation is solid. It is much more cost-effective to make your developers (who will follow you, as they have huge investments on your platform already and wouldn't be willing or able to switch) move the direction you want than move in the direction they want. In their position, being able to do whatever is convenient for them regardless of how inconvenient it is to their users, I'd do exactly the same.
It's a delicate act of balancing your inconvenience of moving along with your vendor and your cost of migrating to another. As long as the second half is kept high enough, they can do a lot of inconvenience on the first.
Besides that, I think my assessment of the situation is solid. It is much more cost-effective to make your developers (who will follow you, as they have huge investments on your platform already and wouldn't be willing or able to switch) move the direction you want than move in the direction they want. In their position, being able to do whatever is convenient for them regardless of how inconvenient it is to their users, I'd do exactly the same.
It's a delicate act of balancing your inconvenience of moving along with your vendor and your cost of migrating to another. As long as the second half is kept high enough, they can do a lot of inconvenience on the first.
I think people are going on the assertion that every-day apps written with WPF (i.e. Visual Studio 2010) are a step back from their old GDI-based ancestors with respect to performance.
I mean we've had to buy a shit load of graphics cards to get acceptable performance on our (definitely not shoddy) kit.
I mean we've had to buy a shit load of graphics cards to get acceptable performance on our (definitely not shoddy) kit.
I think a lot of developers are simply getting tired of MS cranking out half baked technologies and abandoning them after a while. If you want to write a desktop app there simply is no obvious platform of choice. You have Winforms (abandoned), WPF (slow, future unclear, do fonts render OK now?), MFC (has been out of date for 10 years), Win32 (hard to use), Silverlight (direction changes every 3 months). They all have different problems MS doesn't seem to interested addressing.
I wish MS would make a decision to bet everything on one platform (I don't care which), stick to it and make it really good.
I wish MS would make a decision to bet everything on one platform (I don't care which), stick to it and make it really good.
I agree with you about their ridiculous amounts of API churn. I think it happens for (IMHO) two main reasons:
1. MS wanted to keep Windows APIs growing quickly to keep anyone from making a compatible platform. I can't imagine how many $B a year it costs to maintain that. This is probably less of a goal than it used to be, as the baseline Windows install is now so many GB that it's an impediment for the nimble VMs and ultra-portable clients that are the future.
2. MS seems to pitch to (and staff from) a young audience, folks in school and moving to the workplace as application software developers. This crowd has a natural turnover period of only a few years.
But one thing they really are quite good at is supporting stuff for a long time. You can today build an app with .Net framework 2.0 with VS 2005 and it will install and run about as well as it ever did. For native code compatibility typically goes all the way back to Win95 apps. When old apps don't work it's usually a result of unambiguous security or stability improvements made to the OS. Even then Windows often provides virtualized registry and filesystem areas that trick the apps into working.
1. MS wanted to keep Windows APIs growing quickly to keep anyone from making a compatible platform. I can't imagine how many $B a year it costs to maintain that. This is probably less of a goal than it used to be, as the baseline Windows install is now so many GB that it's an impediment for the nimble VMs and ultra-portable clients that are the future.
2. MS seems to pitch to (and staff from) a young audience, folks in school and moving to the workplace as application software developers. This crowd has a natural turnover period of only a few years.
But one thing they really are quite good at is supporting stuff for a long time. You can today build an app with .Net framework 2.0 with VS 2005 and it will install and run about as well as it ever did. For native code compatibility typically goes all the way back to Win95 apps. When old apps don't work it's usually a result of unambiguous security or stability improvements made to the OS. Even then Windows often provides virtualized registry and filesystem areas that trick the apps into working.
At this point you know it is a non-issue because Arstechnica is covering it about six weeks too late[1].
I have talked to many different developers and every one of them that is developing in C# and .NET are not worried at all. Main reason? This stuff is not really going to fly well within the corporate world, corporations still need their custom built applications (using older source bases most of the time), they still need to use all of their productivity apps, and they don't think the office team is suddenly going to re-write Word, PowerPoint, and Excel for a touch based graphical user interface.
All the noise I've heard so far are just the news sites blowing it out of proportion. Frankly it is getting annoying seeing it pop up every couple of days.
[1] (I really don't care what the actual timeframe is)
I have talked to many different developers and every one of them that is developing in C# and .NET are not worried at all. Main reason? This stuff is not really going to fly well within the corporate world, corporations still need their custom built applications (using older source bases most of the time), they still need to use all of their productivity apps, and they don't think the office team is suddenly going to re-write Word, PowerPoint, and Excel for a touch based graphical user interface.
All the noise I've heard so far are just the news sites blowing it out of proportion. Frankly it is getting annoying seeing it pop up every couple of days.
[1] (I really don't care what the actual timeframe is)
I think you're right. But the consequence of that is, of course, that the touch driven "immersive" part is only going to be skin deep. Which in turn means that Windows 8 is going to fail spectacularly on tablets, for the exact same reasons every previous Windows tablet failed.
MSFT has to realise that eventually for the good of the company they WILL have to do something to cut part of their love-child windows out of something. They are unwilling to sacrifice Windows, even a small part of it, for the greater good. That is why MSFT will once again release a product that is not fit for tablet PC's.
consumer != corporate
But all corporate employees are also consumers, and the last ten or so years of consumer-oriented web and native application development has raised everyone's expectations about how software can look and behave. The corporate IT shops are not immune from the demands that these expectations create.
For example, a significant proportion of them are now having to work out how to support Apple's devices for corporate network access, email, document sharing and delivering apps for internal users and consumers, and all because corporate executives are also consumers.
For example, a significant proportion of them are now having to work out how to support Apple's devices for corporate network access, email, document sharing and delivering apps for internal users and consumers, and all because corporate executives are also consumers.
Don't underestimate this. Over the last five years I worked in corporate IT I heard more and more request for "iPhone" versions of our apps and saw more and more emphasis put on making things look good, with Apple's design aesthetic defining "good". Microsoft ignores this growing tide at its peril.
The gap between consumer and corporate is getting smaller every day. This trend is only going to continue, so betting on something appealing only to enterprise, not consumers, is a self-defeating strategy.
Enterprise will always be different than the consumer market until the nature of the enterprise decentralizes.
The key driving distinction between enterprise and consumer is that in the enterprise the person using the software had almost no say in its purchase and thus has almost no say in its development. Consumer software works well when you use it, enterprise software looks good when you see it in a powerpoint presentation next to a feature checkbox, or hear about it on a golf course. Since no one making the purchasing decision will ever actually use it, you're pretty much guaranteed sales. Especially if you can pair it with expensive training that is necessary because your software is designed so poorly.
Having features is generally how you get through an RFP the purpose of an RFP is to CYA. Thus if you have the RFP approved by management and the proposal meets the RFP you're guaranteed a sale if no one else can check the boxes. If you ever get approved for an RFP you should immediately apply to become the vendor of record / preferred vendor for everything in that space guaranteeing more sales of your atrocious software.
Never design software that works in the enterprise as you'll lose out on massive support / training revenue. The worse your software is the better it will sell. Hopefully you can figure out how to sell software that doesn't actually do ANYTHING until they hire programmers to customize it. (I'm looking at you CRM vendors)
Once you've been through a couple of these things you'll understand how it works and how crappy software is incentivized by the RFP system.
You should also have an RFP template ready that contains all the features your software has so that lazy employees from megacorp can submit it for approval. Your sales people should be all too ready to help the employee out with this task so that they have a very professional and tailored RFP. Now that they don't have anything to do that day you should take them out for a beer to celebrate how fast they submitted the RFP to management. Management will remember them as the guy who gets stuff done so quickly and professionally, they'll move up quickly.
The key driving distinction between enterprise and consumer is that in the enterprise the person using the software had almost no say in its purchase and thus has almost no say in its development. Consumer software works well when you use it, enterprise software looks good when you see it in a powerpoint presentation next to a feature checkbox, or hear about it on a golf course. Since no one making the purchasing decision will ever actually use it, you're pretty much guaranteed sales. Especially if you can pair it with expensive training that is necessary because your software is designed so poorly.
Having features is generally how you get through an RFP the purpose of an RFP is to CYA. Thus if you have the RFP approved by management and the proposal meets the RFP you're guaranteed a sale if no one else can check the boxes. If you ever get approved for an RFP you should immediately apply to become the vendor of record / preferred vendor for everything in that space guaranteeing more sales of your atrocious software.
Never design software that works in the enterprise as you'll lose out on massive support / training revenue. The worse your software is the better it will sell. Hopefully you can figure out how to sell software that doesn't actually do ANYTHING until they hire programmers to customize it. (I'm looking at you CRM vendors)
Once you've been through a couple of these things you'll understand how it works and how crappy software is incentivized by the RFP system.
You should also have an RFP template ready that contains all the features your software has so that lazy employees from megacorp can submit it for approval. Your sales people should be all too ready to help the employee out with this task so that they have a very professional and tailored RFP. Now that they don't have anything to do that day you should take them out for a beer to celebrate how fast they submitted the RFP to management. Management will remember them as the guy who gets stuff done so quickly and professionally, they'll move up quickly.
Pardon my french, but this a shallow phrase. Typically enterprise UIs has dozens of input controls, not because the Developers suck but because they need a lot more input than the google search page, a media player or something like that. Touch Interfaces will always suck in those cases, and HTML5 is still far away from handling those beasts in an elegant way.
I would argue that the gap is getting bigger.
Tablets, no-desktop households, webapps: all of these are key consumer devices. Speed, flexibility are key
Enterprises are stuck on the desktop workstations with local apps. Managability of the apps by IT is key.
Tablets, no-desktop households, webapps: all of these are key consumer devices. Speed, flexibility are key
Enterprises are stuck on the desktop workstations with local apps. Managability of the apps by IT is key.
what I actually meant with my perhaps too self-satisfied pithy post was that whether or not an immersive Office is ready or will be ready for Win8 release, I'm sure they will have a suite of consumer-oriented apps similar to the built in WP7/smart phone apps (or Windows Live Essentials): music, photos, maps, search, social networking, messaging, games. They'll probably fund internal and external development of other key apps as well, again like WP7.
I think Windows 8 powered tablets are going to suck just as much for corporate as for consumers.
None of the Windows developers I work with or know in the community are not even concerned about this. Corporate and independent development in the .NET community are conservative and unlikely to jump on the latest thing from Redmond. They have been there, done that and got the free t-shirts for numerous hyped technologies. Most folks still haven't upgraded to VS 2010 or SQL Server 2008R2 yet. There's no point when the money in Windows development doesn't demand the latest and greatest fad. The smart ones wait and see what works, choosing to skip crap like Vista for Windows 7 and concentrate on the good stuff like C#.
As for Peter Bright, (as long time Arstechnica reader and forum participant), I have observed that his articles are designed to get page views. Arstechnica does this by blasting Microsoft and fawning on Apple. As a cynic this doesn't bother me, I can filter the noise and realize that Peter and Conde Nast have bills to pay.
As for Peter Bright, (as long time Arstechnica reader and forum participant), I have observed that his articles are designed to get page views. Arstechnica does this by blasting Microsoft and fawning on Apple. As a cynic this doesn't bother me, I can filter the noise and realize that Peter and Conde Nast have bills to pay.
Totally agree. As a technical lead I tend to stay atleast one major release behind the lastest. However, you should try 2008R2. Its pretty darn good. :)
As someone who has been recently actually doing Windows development using HTML and Javascript I have a couple of observations.
#1 Since I'm the only one in the thread who actually knows what they're talking about, naturally this will get downvoted to oblivion. Farewell sweet karma, I barely knew thee. :D
#2 In order to actually get anything done you have to 'bust out' into the Windows APIs anyway. See here for a prime example:
http://msdn.microsoft.com/en-us/library/aew9yb99(v=vs.85).as...
#3 For budgeting/political reasons I won't go into, I can say that this is possible with only the use of notepad. Speaking programmer to programmer, I strongly advise you to get better tooling than that. Really. This thing is an absolute pig to code and debug by hand.
#4 The horror is entirely justified. This is how bad it is... it actually makes those retarded Java enterprise projects, where you have to cobble together 14 different frameworks that are fundamentally incompatible, look good.
#1 Since I'm the only one in the thread who actually knows what they're talking about, naturally this will get downvoted to oblivion. Farewell sweet karma, I barely knew thee. :D
#2 In order to actually get anything done you have to 'bust out' into the Windows APIs anyway. See here for a prime example:
http://msdn.microsoft.com/en-us/library/aew9yb99(v=vs.85).as...
#3 For budgeting/political reasons I won't go into, I can say that this is possible with only the use of notepad. Speaking programmer to programmer, I strongly advise you to get better tooling than that. Really. This thing is an absolute pig to code and debug by hand.
#4 The horror is entirely justified. This is how bad it is... it actually makes those retarded Java enterprise projects, where you have to cobble together 14 different frameworks that are fundamentally incompatible, look good.
Since I'm the only one in the thread who actually knows
what they're talking about, naturally this will get
downvoted to oblivion. Farewell sweet karma, I barely
knew thee. :D
On general principle I downvote meta discussions about karma/upvotes/whatever shiny beads and shells the site in question is using as faux currency. I wouldn't expect anything different from anyone else.
I've been doing web application development with HTML+CSS+JS for many years, most on Unix but recently fully embedded in the .NET world. I can tell you from my experience that as good as VS and the .NET framework can be, they're way behind when it comes to web application development for cross-platform clients. (And by cross-platform I mean browsers other than IE.)
For years most of my time has been spent developing through a terminal, with Vim as my editor and the world of Gnu command-line tools as my toolset. My primary development language was a scripting language, and my code-run-test iterative cycle took seconds. Now that I'm developing on .NET, it can take 20-30 seconds to restart my application to test a change I just made, not counting getting back to the part of the app I was working on. That's using the built-in IIS server; once I deploy to a real one I've got another round of testing and coding to do because they don't work the same way.
I was much more productive in the old environment. I'm happy to see Microsoft moving towards making HTML5+JS a full-fledged member of their development system; it means that their tools are going to get much better at developing web applications, and maybe I'll be able to reach my old productivity level again.
PS: I don't get the wailing about WPF getting replaced. WPF replaced WinForms, which replaced Win32, which replaced Win16, and I'm sure I'm missing some of the intermediates. The same kind of succession has occurred in most other parts of the Windows development stack. Microsoft has a long history of deprecating APIs and replacing them with completely different and incompatible APIs. All of these WPF developers, who I assume are simply too young to remember the earlier shifts, should be grateful that the new API has a fully backward-compatible history going back to the mid 90's and can carry them forward to any platform they might need to work on in the future.
For years most of my time has been spent developing through a terminal, with Vim as my editor and the world of Gnu command-line tools as my toolset. My primary development language was a scripting language, and my code-run-test iterative cycle took seconds. Now that I'm developing on .NET, it can take 20-30 seconds to restart my application to test a change I just made, not counting getting back to the part of the app I was working on. That's using the built-in IIS server; once I deploy to a real one I've got another round of testing and coding to do because they don't work the same way.
I was much more productive in the old environment. I'm happy to see Microsoft moving towards making HTML5+JS a full-fledged member of their development system; it means that their tools are going to get much better at developing web applications, and maybe I'll be able to reach my old productivity level again.
PS: I don't get the wailing about WPF getting replaced. WPF replaced WinForms, which replaced Win32, which replaced Win16, and I'm sure I'm missing some of the intermediates. The same kind of succession has occurred in most other parts of the Windows development stack. Microsoft has a long history of deprecating APIs and replacing them with completely different and incompatible APIs. All of these WPF developers, who I assume are simply too young to remember the earlier shifts, should be grateful that the new API has a fully backward-compatible history going back to the mid 90's and can carry them forward to any platform they might need to work on in the future.
Winforms did not replace Win32 and WPF did not replace Winforms. That's the problem.
The older libraries may still be around, but they're not the recommended choice anymore and they don't support everything you can do with the newer libraries. It'll be the same with HTML5 and Windows 8: you'll need to switch to develop apps for the new UI, but old apps will still work.
It's all about the tooling.
> #2 In order to actually get anything done you have to 'bust out' into the Windows APIs anyway.
I remember this being the case when we did VB6 application programming. We were constantly "shelling" to Win32. I'm surprised it is still so like that.
Our favorite call was Win32 LockWindowUpdate.
I remember this being the case when we did VB6 application programming. We were constantly "shelling" to Win32. I'm surprised it is still so like that.
Our favorite call was Win32 LockWindowUpdate.
tl;dr: Based on a comment by Microsoft VP, Julie Larson-Green, that a certain weather application they recently made was done using a platform based on HTML 5 and JS, ars technica's Peter Bright somehow comes to a conclusion that this means that HTML 5 is now going to be Microsoft's preferred development platform, and then goes into a long rant on how disastrous this will be for all the Windows developers because it will make all their current knowledge useless and will force them to use a suboptimal technology to develop their applications. At the end of the article he concludes that, yeah, that's not actually going to happen, because Microsoft isn't stupid.
> Peter Bright somehow comes to a conclusion that this means that HTML 5 is now going to be Microsoft's preferred development platform
Actually, unless my memory fails me, it was that Microsoft video showing the tiled interface of Windows 8 that did that - it kind of implied HTML5 was the tool of choice (or, at least, the glue) for tiled and that tiled was the future. The thread kenjackson pointed out tells another story, but we can blame Microsoft for some confusion here.
Actually, unless my memory fails me, it was that Microsoft video showing the tiled interface of Windows 8 that did that - it kind of implied HTML5 was the tool of choice (or, at least, the glue) for tiled and that tiled was the future. The thread kenjackson pointed out tells another story, but we can blame Microsoft for some confusion here.
The video the article links to has Julie Larson-Green going over the tiled interface. Different video from the one you are referring to I believe, but it covers almost the same exact material in a very similar manner.
Here's the link used in the article: http://allthingsd.com/20110601/microsofts-windows-8-demo-fro...
Here's the link used in the article: http://allthingsd.com/20110601/microsofts-windows-8-demo-fro...
> .. but we can blame Microsoft for some confusion here.
Well, Microsoft may not have explained everything at once (Who does?) but that doesn't explicitly mean they forced people to overreact.
Well, Microsoft may not have explained everything at once (Who does?) but that doesn't explicitly mean they forced people to overreact.
That's one of the many things I like in open source - there are no secrets, no big surprises and nobody ever forces you anything.
There is still dislike and complaints about new directions (Unity, Gnome3, KDE4, etc.).
Yes, but none of that was a surprise (we knew about Unity, Gnome and KDE 4 long before any of that hit the distros), we could influence the decisions (arguing in favor of other directions) and, if enough people disagree with the the leaders, they can always make a viable fork.
You can't force an open-source developer to work on something he/she doesn't like and agree.
You can't force an open-source developer to work on something he/she doesn't like and agree.
You wouldn't say that if you were a professional QT developer right now. :-)
"But one aspect of the demonstration has the legions of Windows developers deeply concerned, and with good reason: they were told that all their experience, all their knowledge, and every program they have written in the past would be useless on Windows 8."
I stopped reading there. It's amazing that spreading unfounded trash like this can be called news. All this is is an attempt to twist and stretch the truth in hopes of provoking a reaction and attention -- simply pathetic.
I stopped reading there. It's amazing that spreading unfounded trash like this can be called news. All this is is an attempt to twist and stretch the truth in hopes of provoking a reaction and attention -- simply pathetic.
Why the media has made Microsoft developers horrified about their random speculation.
On the upside, you can now become a Microsoft Certified JavaScript developer (I suppose).
Who knows, all those poor Microserfs might feel liberated in the end, when they get to use a technology that has not been designed to fuel the consulting business - needlessly complex and bloated, that is.
Who knows, all those poor Microserfs might feel liberated in the end, when they get to use a technology that has not been designed to fuel the consulting business - needlessly complex and bloated, that is.
This article seems to be making the assumption that the Windows 8 api will be vanilla HTML5/JS. My impression from the presentation was that they might be using HTML as the layout format and JS as the language but that there would be a lot of non-standard widgets and APIs exposed to both layers.
If so, it's too early to dismiss the technology as "inadequate".
If so, it's too early to dismiss the technology as "inadequate".
I was quite sure that would be the case, as Microoft would never allow such an easy way to port Windows apps to other environments. Whatever glue is tied in HTLM/JS environment, it'll run deep into the Windows APIs in such a way no HTML5/JS app will be easily ported to, say, Google's ChromeOS.
Chrome has plenty of its own APIs too.
Sure, but to a lesser degree than for Microsoft, it's not in Google's best interest to have ChromeOS apps ported to other platforms.
Anyone else notice that within a year, you'll be able to write cross platform html5+js apps that run Black Berry, Windows 8, WebOS, Android and iOS?
If this becomes the standard, like I suspect it will, one of the biggest losers will be companies that run big app stores.
If this becomes the standard, like I suspect it will, one of the biggest losers will be companies that run big app stores.
It's not HTML+JS, it's HTML + JS + vendor-specific bindings + vendor-specific packaging & signature.
At best you'll be dealing with another fat abstraction layer with same kind of annoying small incompatibilities that plague(d) web browsers.
At best you'll be dealing with another fat abstraction layer with same kind of annoying small incompatibilities that plague(d) web browsers.
And yet web browsers support a far larger world of applications than .NET has. Consider that every website is essentially an independently-developed HTML-based application; do you think there are more of them than there are .NET-based applications?
Those small incompatibilities may be annoying, but they're a small price to pay for the otherwise easy development and broad reach of the HTML+JS+etc platform.
Those small incompatibilities may be annoying, but they're a small price to pay for the otherwise easy development and broad reach of the HTML+JS+etc platform.
They can be quite different.
For instance, HP WebOS uses additional attributes to turn DIVs into Buttons.
I've no idea what MS is going to come up with.
For instance, HP WebOS uses additional attributes to turn DIVs into Buttons.
I've no idea what MS is going to come up with.
I believe that abstraction layer is currently called PhoneGap.
The greater the diversity in the market, the more appealing HTML5 becomes. It's bad enough supporting two platforms but 3-4 is going to push a lot of shops to the browser. Unfortunately, both Apple and Microsoft have significant incentives to make sure the browser experience is always inferior to a native app.
Further to the other comments on this thread, the articles comments re "HTML5 remains true to its text mark-up heritage; its structure and semantics are still geared towards creating structured text documents, not application user interfaces"
can't possibly be true, or we wouldn't have the vast number of very usable web-apps we have today.
Corporations should be (and are) embracing the capabilities of web technologies for building internal tools quickly and enabling quick changes.
Corporations should be (and are) embracing the capabilities of web technologies for building internal tools quickly and enabling quick changes.
Stop whining ; it's one of few actual smart moves coming out of MS in years. And my MS developer friends are not complaining; it makes their life easier because now they can easily switch, get more jobs and do stuff that's actually 'cool' again (yep, programming for Win is very not cool in most every corner of the world while building hip stuff in HTML5 is); it makes nice money but things you have to do for 30+ years, 8 hours/day should not be about money alone.
It's not whining, the article perfectly sums it up:
it means discarding rich, capable frameworks and the powerful, enormously popular Visual Studio development environment, in favor of a far more primitive, rudimentary system with substantially inferior tools
Seriously, try xaml and VS compared with [insert vim, emacs, etc] + html5.
They're light years apart in terms of capabilities.
On the other hand, I'd think it's far too early to worry, apart from MS have now gone all clam, which is worrying. They're fanning the flames themselves
It doesn't really affect me, but I can understand why a lot of developers would be anxious.
They don't want to use a clearly inferior technology and quite frankly a crappy language like JS.
it means discarding rich, capable frameworks and the powerful, enormously popular Visual Studio development environment, in favor of a far more primitive, rudimentary system with substantially inferior tools
Seriously, try xaml and VS compared with [insert vim, emacs, etc] + html5.
They're light years apart in terms of capabilities.
On the other hand, I'd think it's far too early to worry, apart from MS have now gone all clam, which is worrying. They're fanning the flames themselves
It doesn't really affect me, but I can understand why a lot of developers would be anxious.
They don't want to use a clearly inferior technology and quite frankly a crappy language like JS.
Seriously, try xaml and VS compared with [insert vim, emacs, etc] + html5.
Why would you deliberately handicap yourself on the HTML side? Ext JS + Ext Designer + IDE with automatic linting and auto-completion. That's one possible way to build rich web apps.
Why would you deliberately handicap yourself on the HTML side? Ext JS + Ext Designer + IDE with automatic linting and auto-completion. That's one possible way to build rich web apps.
I doubt this is going to be an issue in the long run, because I don't expect this next iteration of Microsoft's "tablets that are really notebooks running a mix of tablet apps and standard Windows applications" is going to be any more successful than its predecessors. Assuming this sees the light of day, it will be at least a year before Win8 tablets are available - just in time to compete with the iPad 3 and Android 4.x+.
The same idea that made Palm developers jump for joy makes Microsoft developers "horrified"? Yeah, sure.
What developers are horrified by this? I thought for your enterprise apps that you can continue to use the Windows 7 skin. For developers of the new Windows 8 platform I think this is a great opportunity for developers to get content into the hands of traditional users in a new way.
MS has lost a lot of trust when they killed off VFP and then VB6. People with large codebases had to migrate and it means loss of competitive advantage making new code do old things.
Most VB6 shops I know took the kool aid and went VB.Net or C#. It would take a whole lot lot of disappointment for them to move away from Microsoft.
People didn't have to migrate though. I know we still have some internal VB6 apps floating around that work fine and do the job they were made to do. Of course they are on the 'upgrade to .net eventually' list, but so far there has been no rush.
Once MS stops development of VB6, the deathclock on its runtime has effectively started. The VB6 runtime may in the future only run on XP emulation. The situation is even more dire with the IDE. The support has effectively run out and if the next release of Windows doesn't support it, you are on your own trying to keep the environment going on an old machine.
I'm really, really excited about this direction for Windows 8. I could see myself jumping on the bandwagon if they handle the API correctly.
Back when WPF/WCF and Silverlight was being pushed, I was initially cautious. I gave the technologies a few tries and ended up not liking them. I didn't like WPF because it seemed like an over-engineered version of SVG. I didn't like WCF because I was used to Remoting and didn't need another layer on top to learn. I didn't drink the Silverlight cool-aid because I knew javascript would get faster and Silverlight would eventually get overtaken by more open options. My guess is many microsoft devs felt the same way and didn't adopt these technologies because if they did, these technologies probably would have made it into Windows 8.
If Microsoft wants to destroy itself then it should focus only on HTML5/Javascript. Corporations are all about speed and efficiency and to compare .Net vs HTML5/Javascript is insane.
I've been programming in .Net for years now, but recently as I got new projects I figured to use them in HTML5/Javascript instead. But after countless of hours research it turns out .Net is by far the most efficient and only option in terms of speed and most direct relation to the hardware, which was important for my projects. They both play a part and neither should be ruled out. Using HTML5/Jquery for web projects and .Net for projects which requires quick access to local resources. Two different worlds. If I were Microsoft I would focus fuse those two worlds together. And if they can add 1+1 this is their intent.
The developers and corporations will continue to use whatever means to maximize profit with the most efficient way for their app. And the corporations in whole is who steer the direction of the consumer market in the end. Not one or two companies. Corporations use .Net not because Microsoft tells them to do so, but because it is most the efficient.
From a consumer point of view it might not be so easy to understand how these things works, as all you see in media is Microsoft that and Apple that and then one might think that's all there is to it.
I've been programming in .Net for years now, but recently as I got new projects I figured to use them in HTML5/Javascript instead. But after countless of hours research it turns out .Net is by far the most efficient and only option in terms of speed and most direct relation to the hardware, which was important for my projects. They both play a part and neither should be ruled out. Using HTML5/Jquery for web projects and .Net for projects which requires quick access to local resources. Two different worlds. If I were Microsoft I would focus fuse those two worlds together. And if they can add 1+1 this is their intent.
The developers and corporations will continue to use whatever means to maximize profit with the most efficient way for their app. And the corporations in whole is who steer the direction of the consumer market in the end. Not one or two companies. Corporations use .Net not because Microsoft tells them to do so, but because it is most the efficient.
From a consumer point of view it might not be so easy to understand how these things works, as all you see in media is Microsoft that and Apple that and then one might think that's all there is to it.
No one is horrified. HTML/CSS are great for some user interfaces but it's always going to be behind WPF.
I think it's just marketing BS from Microsoft, to be honest.
I think it's just marketing BS from Microsoft, to be honest.
I may simply be missing something but I think HTML and Javascript make a lot of sense for basic applications. I've never quite understood why someone would want to jump into Silverlight for an application that simply handles data input and retrieval. I also know that Silverlight has capabilities that HTML doesn't but it's also got some deficiencies that IMO are glaring.
There is a lot to be said for what you are comfortable with using but at the end of the day HTML is a truly cross compatible technology that is becoming more and more capable every day. This could also bring in a lot of potential "developers" if the cost of entry is lowered.
I also understand that you don't want the technologies that you invested in to become extinct overnight but I simply can't imagine that happening.
There is a lot to be said for what you are comfortable with using but at the end of the day HTML is a truly cross compatible technology that is becoming more and more capable every day. This could also bring in a lot of potential "developers" if the cost of entry is lowered.
I also understand that you don't want the technologies that you invested in to become extinct overnight but I simply can't imagine that happening.
Putting aside the fact that no one from Microsoft has actually stated that they are throwing away the other apis, it is a +1 for open, community driven technologies. OSX dev's take note.
Windows 8 is giving developers one more option: In tablet mode you can write the UI part of the application (the widget) in HTML5 and JS.
Author's profile: (Microsoft Contributor) "Peter Bright dropped out of university (after about five minutes) to work as a software developer writing C++ and C#."
After reading that article I propose that he must have also spent another 5 minutes programming before deciding on his new career path of writing sensational crap.
Author's profile: (Microsoft Contributor) "Peter Bright dropped out of university (after about five minutes) to work as a software developer writing C++ and C#."
After reading that article I propose that he must have also spent another 5 minutes programming before deciding on his new career path of writing sensational crap.
I know Peter personally, and he is one of the more well-educated, intelligent, and astonishingly competent developers I know.
Nice flamebait, though.
Nice flamebait, though.
I read the article one more time, it does seem to be much more lucid now. I'll attribute my bad interpretation of it on the fact I read it very late last night - when it seemed to me he was saying that HTML5+JS was replacing .NET and WPF.
He still makes some absurd claims though:
"... they were told that all their experience, all their knowledge, and every program they have written in the past would be useless on Windows 8"
Flamebait. FUD. Just look at the comments there.
He still makes some absurd claims though:
"... they were told that all their experience, all their knowledge, and every program they have written in the past would be useless on Windows 8"
Flamebait. FUD. Just look at the comments there.
I was a Win32/COM/MFC developer at the time Microsoft announced .Net. The joke at the MS Dev Conference at the time was that everybody in the room just had their salary drop 20%.
Perhaps the only reason a shift in Win app development tooling isn't such a big deal today is simply that MS does not have the clout that they did back then. Windows 8? Seriously, it's many years off before anybody (including MS) going to try to make a profit on a shrinkwrapped app that doesn't run on Windows XP.
But there are nevertheless a great many developers who've hitched their wagon to MS as a career path. They're understandably antsy as they watch all the hot demand go for iPhone/Android/tablet development. This would explain a lot of the angst I think.
Perhaps the only reason a shift in Win app development tooling isn't such a big deal today is simply that MS does not have the clout that they did back then. Windows 8? Seriously, it's many years off before anybody (including MS) going to try to make a profit on a shrinkwrapped app that doesn't run on Windows XP.
But there are nevertheless a great many developers who've hitched their wagon to MS as a career path. They're understandably antsy as they watch all the hot demand go for iPhone/Android/tablet development. This would explain a lot of the angst I think.
He was saying, I think, that that was the public perception. I'm pretty confident, though I obviously don't speak for him, that that's not his own opinion. At the end of the article, he seems to make that clear.
This seems the most likely option in my opinion. A lot of panic and scaremongering based off a few snippets.
I imagine we'll see other ways to build into the tablet UI apart from html5/js.
I imagine we'll see other ways to build into the tablet UI apart from html5/js.
Read the article to the end. It says almost exactly this.
I seriously doubt a lot of the legacy development stories in .NET are ending. But those are brownfield development stories of apps that were on the drawing board years ago.
I am looking forward - and I just dont think Microsoft has its act together or even beleives its "Developers, Developers, Developers" mantra any more.
I am looking forward - and I just dont think Microsoft has its act together or even beleives its "Developers, Developers, Developers" mantra any more.
It occurs to me that all this stuff is primarily for tablets, and tablets mostly use ARM chips. Microsoft have said Windows 8 will run on ARM, but it will take a lot of work to make the .NET CLR run on ARM. If I read anything into this its that there probably isn't an ARM version of .NET coming.
[deleted]
Just create a .NET library that generates HTML and JS, you know like GWT and leave it be. If not Microsoft, someone will probably create one, there is no reason for all this rage.
If nothing else the article should be titled "How..." rather than "Why...". Any purported horrifying is surely unintended.
Windows 7 widgets were also written in HTML and JS. This is the dumbest controversy ever.
Vista and Windows 7 presentations were never about "here's your widgets and that's it". The way the whole story about HTML+JS on Windows 8 was presented ("a new platform" and not a peep about what else's there) is what legitimately pisses people off.
The strategy seems fairly simple to me:
* HTML -> Web apps
* Silverlight -> Native Apps & Mobile Apps (DirectUI?)
* WPF -> Dead
* HTML -> Web apps
* Silverlight -> Native Apps & Mobile Apps (DirectUI?)
* WPF -> Dead
http://forums.mydigitallife.info/threads/26404-Windows-8-(79...
In this thread you'll see much more clearly what MS is planning. It's not just HTML/JS for these immersive apps. Rather it appears that the CLR will become a first class part of Windows. If you are a Windows dev or are interested in Windows dev, this is a must read thread. In fact I'm shocked that no major publications have noticed it.
There are lots of really interesting nuggets in there. In many regards I think they're finally delivering on a lot of the promises of Longhorn.
I must say I'm excited about it, and looking forward to September now. MS screwed up on the PR, but I think they may have gotten the technological direction right.