Windows 8: .NET Versus HTML5 Metro App Development
179
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."
Intel will not allow MS a free hand... (Score:5, Interesting)
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.
Re:Intel will not allow MS a free hand... (Score:5, Insightful)
The summary is concise and has decent grammar
The blog post it links to raises interesting questions without shoving a viewpoint down your throat
It mentions Microsoft, but has no kneejerk M$ bashing
The blog post it links to has no ads!
What has happened to the real Slashdot?
Re: (Score:2)
Welcome to Earth-2.
Re: (Score:2)
> What has happened to the real Slashdot?
Yeah, I find the combination of AdBlock Plus, NoScript, and WTF? Rewriter extensions surreal too.
.NET MF already exists for ARM (Score:2)
The .NET Micro Framework has already been ported to ARM---as well as BlackFin. Did intel bitch about that? .NET ported over to ARM (or most other architectures) at this point?
It's really up to what Microsoft wants to do. After all, how hard would it be to have the whole
Re: (Score:2)
I was referring to pre-existing aka legacy apps being able to run on ARM. It appears Intel has prevented MS from enabling that:
http://www.theregister.co.uk/2011/09/15/sinofsky_windows8_arm_support_x86_apps/ [theregister.co.uk]
It is going to take many many years for developers, developers and developers to develop brand new apps for the ARM platform, and MS is making it more and more unattractive for those inclined.
Comment removed (Score:5, Interesting)
Pentium II is enough (Score:2)
emulation would probably be roughly the speed of a Pentium II, not good enough to be useful.
I don't understand. Would emulation be "roughly the speed of a Pentium II", or would it be "not good enough to be useful"? A lot of applications spend most of their time in operating system calls, be they drawing something on the screen, blocking on the network, or blocking on the user. These would run natively. So I don't see how emulation comparable to a Pentium II would be too slow to be useful, especially for "that one app" whose absence keeps the user off the platform entirely (as long as it's not a ga
Re: (Score:2)
Once this UEFI Secure Boot thing ramps up over the coming years, it will no longer be possible to wipe a computer for another operating system
Read the UEFI spec. This isn't true. http://www.redhat.com/about/news/archive/2012/6/uefi-secure-boot [redhat.com]
Re: (Score:2)
Just write your app in .NET like millions of applications currently are, and you don't need to do anything.
Re: (Score:3)
Re: (Score:2)
Name someone OTHER than the enterprise that is using .NET?
Anyone who uses the Unity3D engine, which is extremely popular across multiple platforms. And there are many smaller projects but of course they pretty much all include the required runtime or web installer in the application installer so the user wouldn't need to know anyway.
Because i frankly quit supplying .NET on new builds and reinstalls over a year ago and haven't had a single complaint yet
Why would anyone complain? Unless they are running .Net applications that don't either include the runtime or a web-installer (which the VS installer project, NSIS, InnoSetup, etc... all do) the user won't even know about .Net until th
Re: (Score:3)
Re: (Score:2)
Haven't run into any Unity3D, have they made anything i might have heard of?
Unity3D is an engine. But of course there is also the extremely popular Steam platform which is much higher visibility and even high profile titles like Neverwinter Nights. And of course thousands of small utilities all over the net for various things.
One of the first things i do after installing the new hardware is to see if any of their software needs updating and frankly i have yet to see one since i quit including .NET by default come back with .NET installed in programs and features, I just haven't.
Your anecdotal evidence does not seem typical, not to mention the .Net framework is installed by default on any >= Vista install anyway and isn't in Programs and Features and can only be 'turned off' (but not really uninstalled) using the Turn Windows featu
Re: (Score:2)
It doesn't have anything to do with Intel. Windows on ARM does not let you run any third-party desktop apps, native or managed - period. Even if your Win32 desktop app is written in pure C++, you still can't compile it and have it run there.
Re: (Score:2)
if any native Win32 calls are replaced
Which would mean rewriting the entire view layer from using Win32 controls to using WinRT controls. Porting an application from Windows XP/Vista/7 to Windows RT would need roughly the same amount of effort as porting an application from Windows to Mac OS X, from Windows to X11/Linux, from Windows to iOS, or from Windows to Android. I will grant, however, that it wouldn't be quite as much effort as porting an application to Silverlight to run it on Windows Phone 7.
Most business applications shouldn't have many low level OS calls
You mean like the OS calls to open a window
Re: (Score:2)
hich would mean rewriting the entire view layer from using Win32 controls to using WinRT controls.
No, .NET apps use .NET controls not Win32 controls, which is quite independent from the underlying OS or architecture. On the Win32/64 platform, the .NET controls may indeed use Win32 controls, but the .NET app doesn't need to know or care about that. So long as the .NET control is implemented the same on both platforms, any .NET app that uses it will be portable with no code changes required.
You mean like the OS calls to open a window and draw things to it?
.NET has their own calls to do that. It is extremely rare that you would ever need to (or should) be making Win32
Re: (Score:2)
No, .NET apps use .NET controls not Win32 controls, which is quite independent from the underlying OS or architecture. On the Win32/64 platform, the .NET controls may indeed use Win32 controls, but the .NET app doesn't need to know or care about that. So long as the .NET control is implemented the same on both platforms, any .NET app that uses it will be portable with no code changes required.
It would be pretty tricky having something like, say, Control.Handle [microsoft.com] -documented as "An IntPtr that contains the window handle (HWND) of the control - portable outside of Win32.
In practice, .NET apps for Metro use a whole new API [microsoft.com] for UI (and many other things) that is specific to Metro, and is not compatible (even on source code level, much less binary) with any existing desktop .NET APIs - though it's most closely resembling Silverlight.
Re:Intel will not allow MS a free hand... (Score:5, Interesting)
Don't get me wrong CF will still have a lot of uses. Just not consumer based, CF will become mostly a industry thing, much like Java has become (the platform, not the language).
Second, legacy applications are going to have a pretty rough transition and the desktop version of Windows 8 is suppose to be there and help this out. This is why I think tablet Win8 is dumb. We all know that it is going to take a lot of time before vendors can really bring their wares to WinRT, most likely some won't make the jump at all. That's always going to put a divide between desktop and tablet. That's going to make their unified concept look mighty dumb. I hate to say it, in fact if you see me you can have a free punch, but Apple is correct. Desktops and Tablets are different and need different platforms. WinRT will make developers fume with anger as they find that they want to target as many people as they can but suddenly they can't find parity with tablet and desktop Windows versions. Developers are going to ask, why even have this unified looking OS to begin with?!
I know for a fact that native isn't dead. I think the better way to state it is, native isn't consumer anymore. I think any tech company that forgets this has doomed themselves. Business is still going to need (if not in fact demand) native code. I think tablet focuses heavily on consumer, and aiming the OS to be tablet and desktop second is aiming the OS to be consumer. XP was such a great hit because it aimed at business first and brought some consumer added features. It was build on NT which was the "business" OS, it had business features with friendly polish.
In the end I think that tablet has been blown out of the water. Desktop isn't dead, neither is native code, but with more and more non-tech users moving onto the Internet and using computers, there has been a growing demand for consumer friendly devices. The tablet has the right mix to be this, but let's face it, it was a big uh-oh to think Joe six pack needed a full blown out computer. However consumers and businesses are all going to need stuff for consumers to consume, that's your desktops, that's your native code. That stuff isn't going anywhere, it's just not hot at the moment.
That' why I say that WinRT is going to be the target for most on Win8 and it's going to fail hardcore for legacy applications. CF is just another niche thing that Microsoft will eventually kill off, just like Silverlight (yeah I know they didn't kill it but have come as close to it as they can.) The fact that most vendors are going to be hitting native and WinRT for most of their products is going to make this whole unified Win8 think look dumb in the end. Also, the fear that Microsoft may very well kill off the Metro thing too at some point if they get bored with it. I wouldn't put it pass them, that if they see Win8 becoming a flop, that this whole Win8 fiasco disappears come Win9.
Re:Intel will not allow MS a free hand... (Score:4, Insightful)
Tell me, how do you use Javascript to write a fast, efficient signal processing application? How do you write 3D graphics in HTML5?
Native is still consumer; you still need fast, close-to-hardware work for many things like image processing (iPhoto), audio processing (look at all the people raving about garage band on the iPad), games and the like. If anything, the "enterprise" is the one who doesn't need native. Who needs SSE and OpenCL for a billing application, email or even displaying a presentation? Write that in HTML5 + JS or whatever, your users wouldn't notice.
Your basic point is correct, but I think you stressed it too much. Native code isn't going anywhere, and if anything, it's going to get even hotter. It'll be for the superstar apps like Photoshop and Blender. Your flashlight apps and Yet Another Calculator are going to run on the interpreter. What's over is the days of 200 lines of COM gibberish to write Hello World. That was an avoidable fiasco which they're trying to correct in all kinds of ways now.
Re: (Score:2)
How do you write 3D graphics in HTML5?
WebGL, but good luck finding a browser that supports it.
Good luck finding Google Chrome for Windows RT (Score:2)
WebGL, but good luck finding a browser that supports it.
chrome?
Good luck finding Google Chrome for Windows RT. From this article [eweek.com]: "Microsoft says IE will be the only browser choice in devices running Windows RT, the variation of Windows 8 designed for devices running ARM processors."
Re: (Score:2)
I wonder how the EU, which required them to offer a choice of 3rd party browsers to purchasers of older versions of Windows, will react to this news?
Re: (Score:2)
Windows RT is not a general-purpose PC operating system, though - so they probably won't complain, much like they don't demand that Sony should offer competing browsers on the PS3.
Re: (Score:2)
Ludicrous -- Microsoft has antitrust experience and would never try to prevent other browsers from running on Windows.
Re: (Score:3)
These guys [mozilla.org] show real-time 2-D FFT. Admittedly, the combination of SSE/AVX and multi-threading/multi-core would have provided a 30x speedup, but I've been playing around with real-time 2D graphics in JavaScript and have been amazed at its performance. I was even guilty of premature optimization -- I started out coding for double-buffering the graphics with two Canvases and ended up throwing out the double-buffering
M$ has not announced any plans to support WebGL (Score:2)
These guys show real-time 2-D FFT.
How well does that demonstration work in Internet Explorer?
WebGL
From the article you linked: "Microsoft has not announced any plans to support WebGL". So provided I'm not missing anything, one would first have to implement WebGL as a software renderer in JavaScript, much like the other "shims" that add missing DOM features to IE.
Re: (Score:2)
How well does that demonstration work in Internet Explorer?
Works fine for me in IE 9+.
No BHOs in RT (Score:3)
Chrome frame.
Is a browser helper object. The Metro version of IE doesn't run browser helper objects [slashdot.org].
IE (Score:2)
WebGL
When will Internet Explorer for Windows RT support WebGL or the other APIs that you mentioned?
Comment removed (Score:5, Insightful)
Re: (Score:2)
You may be missing a crucial component of the tablet buyers teens to early 20s who have access but don't own computers i.e. they have one at school, their parents own one... Otherwise I agree that tablets are 2ndary not primary computers.
As for Microsoft.... I doubt they will pull the trigger in the end. Every time they bring out an OS they struggle with powerful new technologies (windows filesystem and palladium in the last cycle) and every time they are confronted with the fact that the reason people u
Re: (Score:2)
Re: (Score:2)
s. But I would argue the bigger problems is they are doing as they have done a million times in the past, they are creating a half assed copy of a popular thing and thinking their money and name will let them muscle their way in, and its a bad move.
I agree it is likely to be half assed. Microsoft as a company can't come together. And if they can't send out a clear message like Apple would, "this is the new direction, we are going here and you will be going here too" they can't get their base over this h
Re: (Score:2)
Re: (Score:2)
I agree with you that a touch screen won't work. Though Apple is switching people from mice to laptop style trackpads ( http://www.apple.com/magictrackpad/ [apple.com] ) more like a laptop configuration even for desktop users. And as a laptop & tablet & iPhone user I agree I use keyboard / mouse for my desktop I don't want to touch the screen. Heck I use ( http://www.microsoft.com/hardware/en-us/p/natural-ergonomic-keyboard-4000 [microsoft.com] ) when I use windows so I can touch the mouse less, much less wanting to touch t
.NET CF still used in XNA (Score:2)
developers are going to want to target the option that has the most options with the most platforms
For developers of video games, this will be the .NET Compact Framework, which (unlike full .NET) lacks support for DLR languages such as IronPython. XNA, based on .NET CF, is still the only way for a micro-ISV to target a game console, as Sony and Nintendo appear to have declined to extend their developer programs to micro-ISVs. .NET CF is also the only way to target a Lumia phone, which runs Windows Phone 7.
Desktops and Tablets are different and need different platforms.
What's the big difference in practice between a subnotebook and a tablet docked to a keyboard?
it was a big uh-oh to think Joe six pack needed a full blown out computer.
It dep
Re: (Score:2)
XNA, based on .NET CF, is still the only way for a micro-ISV to target a game console
I won't say that the statement is correct, but it is not 100% incorrect. As .NET CF is *a* way for micro-ISVs, it is hardly the *only* way. Nor is it the most popular way. However, you are correct that it is indeed a way. However, that doesn't render the fact that I said that CF will be rendered industry heavy, niche serving mostly, incorrect. The hotness is mobile development and that's where units are moving. Gaming is still big, but it's not moving like the mobile market. You can clearly see that
Re: (Score:2)
its got nothing to do with technical reasons, everything will be driven by the business at MS, and currently they seem to be reducing their fractured development teams by consolidating them all around a single platform runtime - WinRT.
So, expect WinPhone 8 to be built on the same (cut down) codebase as Window s8, and all new phone apps to require WinRT.
What that means for native v .net development, WinRT is entirely native, and MS has noticed that native code sucks less resources and goes faster than manage
A question? (Score:3, Insightful)
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.
Re: (Score:2)
Will Microsoft allow .Net to run on Windows 8?!??! Are you seriously asking this?
Of course not. They're creating .FIRE This new API requires developers to get IV's of liquid pain injected into their bodies, and allows them to experience coding mistakes first hand.
Re: (Score:2)
This new API requires developers to get IV's of liquid pain injected into their bodies, and allows them to experience coding mistakes first hand.
So, it's like coding on Windows ME, then?
Re:A question? (Score:5, Informative)
WinRT includes a .NET runtime. Yes, on ARM. It's a subset of .NET 4.5 (same subset metro on x86 has). There is no "if they port it". It's ported.
And no, porting the .net runtime does not mean x86 apps will compile and run on ARM, although almost any app written entirely in a high level language should, unless it depends on byte ordering or some other factor that is x86 specific.
Re: (Score:2)
The unfortunate aspect of using native code is that a large percentage of developers today don't have a fucking clue about C++. .NET was only feasible because of the advancement of the hardware needed to handle the .NET run time layer. However, .NET might use the terminology but it does not use the same native layer code implementations.. The GC, stack ,heap management., and inheritance are just 4 examples of .NET using terminology found in C++ but it's actual OS implementation is very different from C++.
Re: (Score:2)
I don't see how that would be unfortunate, or even what's the relation (between enabling native development and new devs not being c++ gurus).
Enabling the possibility of writing native code is a good thing on any platform, and there'll be always a great number of people relying on it. There won't be a huge crowd of such people, but if you want a nice future for your platform a
Re:A question? (Score:4, Informative)
If the .Net runtime is ported to ARM, then X86 apps will compile and run on ARM as well
This statement makes nothing even slightly resembling sense. .NET and x86 have absolutley nothing to do with eachother. Programs writtten for the .NET framework compile to Common Intermediate Language, which is architecture-independent (similar to Java bytecode). Programs written for x86 are, obviously, x86-specific, and will not run on a CPu with a different instruction set architecture, such as ARM.
The .NET runtime has already boon ported to ARM anyhow. First of all, both Windows Mobile and Windows Phone have .NET components, and both run on ARM (for that matter, so does the Zune HD, which is also programmable using C# and a subset of .NET). Parts of "big Windows" (Win8, in this case) use .NET, so even if it's not available to third-party developers, you can bet that WinRT includes .NET, and Windows RT runs on ARM.
Finally, and stupidest of all, Microsoft has already published the build tools for Win8 Metro-style apps, which will run on all Win8 systems including ARM (Windows RT) ones. These apps are written against the "WinRT" API (not the same as "Windows RT", which refers specifically to "Win8 on ARM"). WinRT is natively a C++ API, but it *already* has .NET bindings and it's perfectly possible, even today, to write Metro-style apps using .NET languages. In fact, this has been possible for months...
Re: (Score:2)
Then you can be the smartest guru on the cinder. (Score:5, Insightful)
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.
Re: (Score:2)
This is me, and will be you, eventually [youtube.com] when the next latest and greatest damned thing comes to change your life for the eleventyth twelfthtish time.
Re: (Score:2)
BEcause that means someday we will see the end of XML.
Re:Then you can be the smartest guru on the cinder (Score:4, Funny)
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#.
Re: (Score:2, Informative)
This guy is a complete moron. First, it's called the CLI, not the CIL.
Perhaps not as compete as some...
http://en.wikipedia.org/wiki/Common_Intermediate_Language [wikipedia.org]
Re: (Score:3, Informative)
http://en.wikipedia.org/wiki/Common_Language_Infrastructure [wikipedia.org]
He was referring to the VM and portability in the article, not the bytecode language itself.
Re: (Score:3)
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.
Re: (Score:2)
Re: (Score:3, Funny)
Now who's the idiot? CLR is a calcium, lime, and rust cleaner. It doesn't compile anything!
Re: (Score:2)
I think he's confusing it with the CLR, which does the JIT compilation of the CIL. And I've heard it referred to (less lazily) as the "intermediate runtime language", which would be IRL. O_o
Alphabet Madness!
Takes me back to the days when MS switched from ADO to DAO ... or was it the other way around?
Re:Idiot (Score:5, Informative)
"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.
Re: (Score:2)
Re:Idiot (Score:5, Interesting)
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 [devexpress.com] 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.
Re:Idiot (Score:5, Funny)
He didn't mean Command Line Interface.
Common Language Infrastructure [wikipedia.org]
Complete moron still applies, I think.
Re: (Score:3)
Re: (Score:2)
Ahem... the CIL is a specification. So what is it you were actually talking about?
The CLI has nothing to do with Mono, other than it's something Mono follows. The CLI is the basic "write once, run anywhere" specification, because it includes all the types and base class library definitions.
Just compiling something to CIL is pointless if it doesn't follow a type and library specification.
Further, you conflate the CIL with the VM all over your article, which is why your article did not make sense. For exam
Re: (Score:2)
Just reply with a hearty fuck off otherwise you'll just get buried in tiresome pedantry.
Re: (Score:3)
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 cal
Re: (Score:2)
Well except that everything he wrote, and the technical abbreviations he used were absolutely correct. But there is a large majority of slashdot readers that aren't familiar with Microsoft technologies and get easily confused when the same abbreviation is used for multiple things. CIL is indeed correct, as would MS-IL, or IL when referring to the byte code that .NET applications get compiled to.
Re: (Score:2)
Everything he wrote is definitely not "absolutely correct". See my long winded reply [slashdot.org] for details.
Re: (Score:3)
>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
Acronyms be darned (Score:2)
PowerShell is the cmd-line interface of .NET (Score:2)
.NET has a command-line interface?
It's called PowerShell [wikipedia.org].
Re: (Score:2)
This guy is a complete moron. First, it's called the CLI, not the CIL
What teh hell might cause such moronity, I wonder?
Re: (Score:2)
First, it's called the CLI, not the CIL.
Wrong, in fact both exist CLI (Common Language Infrastructure) and CIL (Common Interface Language), and given his usage he obviously means the latter, so I'd say if anyone is a moron, it's you.
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
Re: (Score:2)
You're plainly wrong. C# and VB Metro apps run on .NET, in a VM (CLR), they do not compile to native. There is a projection of WinRT classes to .NET, and the .NET standard library is significantly reduced in size compared to desktop, but it is still a managed language.
Re: (Score:2)
Re: (Score:2)
Re:No brainer (Score:4, Interesting)
Re: (Score:2)
There was a thing claiming to do that almost 20 years back. Oak, I think it was called. Never caught on.
Re: (Score:2)
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 friendl
Re: (Score:2)
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.
IE9 was competitive when it came out as well. Some time soon IE10 will have a feature freeze and nothing much will happen until IE11.
Re: (Score:2, Insightful)
That is great for the corps and the users. Anual updates beats 6 weeks and intranet developers need to certify which browsers they support.
Re:No brainer (Score:5, Insightful)
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.
Re: (Score:2)
I dont think you have used an Xbox if your making that claim, while metro is shit, metro is for smartphones and tablets, metro is nowhere close to dash ... the dashboard actually has responsive controls for one
Re: (Score:3)
"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,
Re: (Score:2)
It'll be used more by web developers wanting to make desktop apps, but I guess that's the idea.
Well yes that's precisely the idea. The entire next generation of developers is learning to develop for the web. They don't know how to make desktop apps. Microsoft doesn't want to be be IBM trying to teach younger developers how to write COBOL.
The problem is that just as C and COBOL were designed to solve totally different problems .NET and HTML5 were designed to solve totally different problems.
Re:Metro eh..? (Score:4, Interesting)
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.
Re: (Score:2)
We have technologies for web apps. The arguable most feature rich best was from Microsoft, Active-X. But Flash, Java, Shockwave are also all contenders. So was Silverlight [silverlight.net]. But they failed because web developers are skeptical of Microsoft.
So what can Microsoft do?
Re: (Score:2)
But they're only half-arsed proprietary attempts. I'm not talking about something that's just a plugin for a browser, but something that is equivalent to a browser for accessing apps, or even something that is natively supported in all browsers.
I'm talking about a standardised format (based on say, XML) for defining user interfaces that are designed to be event driven, sat on a protocol that supports event driven client-server communication, with the ability to pass blocks of executable (but sandboxed and s
Re: (Score:3)
How is what you are proposing different from SEAM ( http://seamframework.org/ [seamframework.org] ).
Re: (Score:2)
It might not be, but is it still built on the HTTP stack? is it platform agnostic?
I note it still makes use of AJAX which doesn't get us away from the fact that AJAX/HTTP is still fundamentally a hack, rather than a proper solution.
Javascript itself is rather crippling in terms of the way it can be used to support the client side of application development in part because it's not fully functional, and it's not properly OOP. Even with the efforts in recent years to improve the toolchain it's performance is
Re: (Score:2)
What platform agnostic languages exist that operate through browsers? That takes you back to Flash... I'm not getting what it is you really want. If it is going to work in a non hackish way there needs to be something on the client's system to handle it.
If it is the browser then HTML, otherwise it is a pluggin. Unless you want some other entirely different system that's just triggered by the browser like Active X or Java.
Re: (Score:2)
Yes that was the entire point. We need something that isn't HTML/HTTP whether it's implemented as a new type of browser that lets you interact with apps, or whether it's a first class citizen in existing browsers.
Some browsers already handle other protocols, like FTP, my point was that we indeed need a new protocol, and new set of technologies (even if they utilise existing technologies at first) to facilitate web applications.
We can't go on hacking technology to fit indefinitely, there comes a limit where
Re: (Score:2)
They could get a clue. You've listed a whole laundry list of their idea of what the "active" web should be. Executables that your browser automatically downloads and runs on your machine.
Any competent security person could tell you what a bad idea that was - but they did it, and protected it with stupid "secret is secure" trivia. Now your boxes are subject to all kinds of attacks, and that list you gave is the favorite vector. MS provided the way to get the blackhat executables onto people's machines, and
Re: (Score:2)
Yep. We are in a classic situation. People want:
a) Full featured applications
b) Web distribution
c) Security
d) No centralized approvals.
And don't understand they can only have 3 out of 4.
Re: (Score:2)
Re: (Score:2, Insightful)
Technology is no longer a game for the young anymore...
That is the problem. When Slashdot started it was full of 1990 hipsters, who were raking in the dough on the Dot Com Madness. They talk about jobs raking in 6 figures, where they spend half the day playing video games, and most of the jobs were either simple Web Development, or going into legacy code and changing the size of the year from 2 to 4, then finding spots on the form do deal with the change. Articles were about things people did with their
Re: (Score:2)
Microsoft Windows 7 is the same quality as Windows ME, just with a fancier UI, which I don't need anyways.
How the hell did a comment like this get modded Insightful?
Windows Me was a single-user OS with, frankly, no such thing as security. It was the last iteration of the 9x kernel, a system so archaic that it still used DOS as a boot loader and 16-bit device driver compatibility layer [msdn.com].
Windows 7 is the most recent production release of the Windows NT kernel, which effectively reimplemented the Win32 API fr
Re: (Score:2)
Uh, you're comparing a platform (.NET) to a language (Java); it doesn't quite work that way.
Re: (Score:3)
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.
Re: (Score:2)
Re: (Score:2)