Slashdot Mirror
Windows 8: .NET Versus HTML5 Metro App Development
An anonymous reader writes "Will Microsoft take advantage of .NET's Java-like CIL and allow .NET code to run on Windows 8, or force developers to switch to HTML5 Metro apps instead for porting apps to Windows 8? This article brings up important insights into both paradigms' advantages and disadvantages, and even correlates the options with Microsoft's past NT-era support of MIPS and PPC, as well as Windows CE's way of supporting embedded architectures."
as the article suggests, to port .Net apps to the ARM architecture. Arm-twisting both ways in the Wintel duopoly, first it was the turn of MS, now it's Intel's turn.
If you keep throwing chairs, one day you'll break windows....
While it is true, Microsoft may just be hoping for a foot in at this point. HTML5 is touted as the one stop shop to port an app to Android, IOS and windows. Microsoft is entering the mobile phone war late in the game and way behind, interchangeability at this stage of the game is a plus for them. They just need plans to mess that up late in the game if they take the lead.
Will Microsoft allow .Net to run on Windows 8?!??! Are you seriously asking this? The answer is a resounding YES for so many obvious reasons that it seems ridiculous to even respond to this.
http://en.wikipedia.org/wiki/Common_Language_Infrastructure
He was referring to the VM and portability in the article, not the bytecode language itself.
If you need web hosting, you could do worse than here
If Microsoft does not port the .NET runtime to Windows 8 on ARM, allowing apps compiled from C#/VB/C++ to CIL to execute on either supported hardware platform [...]
Sounds like he was.
They wont do that. Microsoft is no longer the leader. IE is a great example as IE 6 lockin lost. As a result it no longer sucks as IE 9 is ok, and IE 10 is quite competitive with Goole, Apple, and Mozilla as one of the most standard compliant browsers ever.
Therefore they are the good guys now just like Apple used to be before owning hte smartphone market and tablet and turning more evil than MS ever was.
If MS keeps losing they will have to compete with product quality and supporting standards and be friendly towards users. I hope to see MS do some more marketshare just so we have more competition. If Google decides that Andriod is too much of a patent liability and decides to let Apple use Google's services in exchange they leave the market we ARE FUCKED. IOS would be the next Dos/Windows for the next few decades. Would we want that?
I know we have issues with trust but to be honest how can I trust anyone else? Corporations supposed to follow the users needs and wants and when it is a free market this happens and they must correct themselves or die.
http://saveie6.com/
I've been through a number of cycles of The One True Greatest Solution For All Time a whole bunch of times now.
As The Comedian says, "It's a joke. It's all a joke."
Great, massive, scalable frameworks that we are to write once in, and that's it, it's nothing but code reuse and minor tweaks for as far as the eye can see...until three or four (or two) years goes by and it's all changed and you have to re-write everything all over again...once and for all.
Until the next few years goes by.
Entire graphical e-z layouts with auto code generation. General purpose driver systems. Document data sharing models. Database storage systems with query languages.
It's a joke. It's all a joke. Mother, don't you dare fuckin' forgive them.
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
This is me, and will be you, eventually when the next latest and greatest damned thing comes to change your life for the eleventyth twelfthtish time.
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
Now who's the idiot? CLR is a calcium, lime, and rust cleaner. It doesn't compile anything!
That is great for the corps and the users. Anual updates beats 6 weeks and intranet developers need to certify which browsers they support.
Um, no. I don't know of any other JS engine that implements the WinRT namespace. The Chakra JS engine is what will separate any browser from being able to run Metro apps. A metro app isn't a web app, it is important that people understand this. Even though the two are written in the same language, they are not the same thing. Just like Java applets and Android apps are two very different things, they are both written in the same language, Java.
So yeah, Microsoft can still use HTML5 to lock in people into their product, so long as the HTML targets Metro and not the web. Granted it *might* make it easier for one to port from Metro to Web and that's exactly what Microsoft is trying to sell. I don't know how exactly true that is however. But HTML+JS for Metro and HTML+JS for Web are two different things with the same language. Pass it on.
Yup, just more Microsoft word-spooge onto the faces of the developmentally naive.
Someone left an MSDN magazine lying around in work. It had an article titled something like "Leveraging code re-use via multiparadigmatic metaprogramming lambda expressions". After some head scratching, I eventually figured out that they were talking about implementing macros in C#.
If you were blocking sigs, you wouldn't have to read this.
"This guy is a complete moron. First, it's called the CLI, not the CIL."
No it's not. CIL is the Common Intermediate Language, it is .NET's bytecode format, that is part of the CLI (Common Language Infrastructure) and runs on top of the CLR (Common Language Runtime). The CIL is important for portability as it is effectively the abstraction layer that separates the actual code, from the underlying architecture. The CLR then acts as an architecture specific implementation to execute that bytecode on the architecture in question.
"Second, it's called the Windows Runtime or WinRT and it runs .NET apps and HTML5/js apps."
Just to clarify, as someone responding to you didn't seem to quite get it, it doesn't run existing .NET apps, that's done elsewhere. It does allow you to write new apps utilising parts of the .NET toolset however.
Despite this, I agree, the guy is indeed a complete moron writing an article about something he generally doesn't really seem to get.
This guy is a complete moron. First, it's called the CLI, not the CIL. Second, it's called the Windows Runtime or WinRT and it runs .NET apps and HTML5/js apps. This is all quite plain to anyone that has even a tiny understanding of the system. This architecture diagram has been posted for quite some time, and clearly shows C# and VB as well as C/C++ apps running under WinRT/Metro.
Hi, I'm the "complete moron" who wrote the article. I most definitely meant CIL and not CLI, as I was referring to the Common Intermediate Language, and not the Command Line Interface. One is used to interact with an operating system through mostly text (curses and cursor-based terminal graphics being a stark exception), and the other allows multiple human-written programming languages to be compiled to a common bytecode form for interpretation by a .NET virtual machine runtime, and the basis of this article was that the same VM can be ported to Windows 8 on ARM in place of Metro apps. And your diagram does not clearly note anywhere that it is valid for Windows 8 on ARM as it is for x86/x86-64. Next time, don't be so quick to jump to conclusions and throw the words "moron" and "idiot" around. Thank you in advance.
"Honestly, I'm not a big fan. Taking what basically amounts to the (current generation) Xbox user interface and applying it to desktops and portable devices just seems like a massive step backwards."
It was a step backwards on the XBox too to be fair. It really doesn't work well there IMO.
They developed the interface for Windows Phone, where it works, and are now trying to carry it everywhere else, where it doesn't work. It's stupid.
"The HTML 5 standard looks good"
Does it? It's bad enough as a web standard, god only knows how terribly it's going to map to the desktop paradigm. I can't really see many existing desktop developers wanting to use the HTML5 path, because the HTML5 spec causes such utter rape of the concept of separation of concerns that the likes of WPF developers have long gotten used to that it's going to make them vomit if they see it. It'll be used more by web developers wanting to make desktop apps, but I guess that's the idea.
"Also, am I the only one who reads Windows RT and thinks 'Windows Re-Tweet'?"
Yes.
He didn't mean Command Line Interface.
Common Language Infrastructure
Complete moron still applies, I think.
The fundamental problem is that it's all entirely backwards.
The web is moving more towards apps so rather than continuing to butcher HTTP and HTML into supporting apps, we'd be better off creating a new protocol handler (is app:// taken?) and creating a set of technologies better meant to facilitate that.
XAML may not be the best option, but it illustrates the concept - it would make much more sense to have something like this built for the web/desktop than it would badly butchering HTTP/HTML.
I agree with you on where HTML5 is going but it frankly scares me, it's a throwback to the bad development practices that came around in the 90s, culminating in Visual Basic 6 being used for actual commercial apps.
I get the feeling it's a new generation of developers pushing all these things, one that hasn't learnt from the mistakes of the previous generation. All the problems with HTML5 have long be solved, but for some reason the solutions have been ignored, and so the problems are merely being repeated. I get the feeling we've got a decade of really bad software ahead of us. Time will tell I guess.
Don't confuse "specification" with "implementation." Nowhere in the article is Mono mentioned, as it is a non-Microsoft application of the CLI specification. I was specifically referring to Microsoft-published software, and as mentioned above in a separate thread, I was correct in referring to the bytecode (CIL) with respect to how it can be interpreted by a Microsoft VM on either architecture. Obvious by my confusion with the command-line, I wasn't even aware there was an approved specification for .NET's VM (or any Microsoft product, for that matter). But regardless of whether it's standardized for all to use or not, the article focuses on Microsoft. Even if it were not standardized they could continue to publish VMs on their own platform as far as I'm aware.
I hate Slashdot sometimes.
>Hi, I.. wrote the article.
I am sorry but your article is full of very misleading information. First of all, you keep referring to WinRT apps as HTML5 Metro apps. Metro or WinRT have absolutely nothing to do with HTML5, except that they *can* be developed in HTML5/CSS/JS. Most Metro WinRT apps will probably be written in XAML on top of VB.NET/C#/C++/C. What have they got to do with HTML5?
I see no mention of WinRT in the whole article, that is what is leading to all the confusion in the comments, because WinRT is the underpinning dev platform for the new Windows 8 apps. That,combined with needless acronym(without expansion) throwing makes it hard to take the article seriously. What are all these great existing .NET CIL apps that "Microsoft must absolutely enable porting or shoot themselves in the foot" ?
This space for rent.
Chrome frame.
Is a browser helper object. The Metro version of IE doesn't run browser helper objects.
How is what you are proposing different from SEAM ( http://seamframework.org/ ).
Obvious by my confusion with the command-line, I wasn't even aware there was an approved specification for .NET's VM (or any Microsoft product, for that matter). But regardless of whether it's standardized for all to use or not, the article focuses on Microsoft.
Ironically, "CIL" is actually the term for .NET bytecode that comes from the Ecma standard. The .NET-specific one - and the one that's used far more often (hence why a lot of people reading your article are likely to be confused) is "MSIL".
But that's hardly of importance. Your article is subpar for several other reasons. To point out a few:
"HTML5 Metro interface" - HTML5 and Metro are orthogonal. You can write Metro apps in HTML5, yes, but you're not required to - .NET managed code, and pure native code calling WinRT directly, are other, first-class alternatives for Metro.
"If Microsoft does not port the .NET runtime to Windows 8 on ARM, allowing apps compiled from C#/VB/C++ to CIL to execute on either supported hardware platform" - a silly question. .NET already is on Windows 8 on ARM. That's what all Metro apps written in managed languages use. If you install VS 2012 RC, you can see over a hundred managed Metro samples...
"trying to shift their developers’ focus to HTML5 Metro apps with Windows Phone compatibility" - there's no compatibility between Windows Phone and Windows 8 so far. Most certainly, HTML5 would be the worst choice there, since there's no good way to write HTML5 apps for Windows Phone 7.x as of today. Whether it'll be different for WP8 is currently unknown.
"Microsoft may have something with making every part of their programming API HTML5-based" - more confusion between Metro and HTML5. Metro APIs are not actually HTML5-based - they are exposed via WinRT (Windows Runtime), which is a standardized native ABI that is further development of COM. This ABI is then projected to a higher-level API that is specific to every target language/framework - there's a high-level native C++ projection known as C++/CX, then there's the .NET projection, and finally the JavaScript projection. The latter is actually the most restricted of the three, though it's partly compensated by intrinsic HTML5 features (like canvas, IndexedDB etc).
"And, of course, Java is long-dead and more than likely will not be ported to the new Windows 8 for ARM OS" - it's not more than likely, it's outright impossible to port Oracle JVM to Win8/ARM. First of all, it does not allow third-party desktop (Win32) apps at all, and JVM is currently decidedly a desktop app. As for Metro, its sandbox (app container) is deliberately designed to restrict the ability to generate code at runtime - in particular, there's no way to allocate a block of memory that has both write and execute permissions, or change them after the fact. This means no JIT (other than the one in .NET and JS). So any Java implementation would have to be either a bytecode interpreter (slow!), or a native compiler, which precludes a straightforward port.
"It is unclear as of now whether genuine native apps written in C++ calling the Win32 API will be supported on Windows 8 for ARM" - it is not at all unclear. If the native app calls a
Guess how I know you've never actually seen either VB6, or .NET, or both? .NET as a platform - and both C# and VB.NET as languages - have far more in common with Java than they do with VB6.