It's hard to say what people prefer, because for pretty much every phone platform (other than WP7?), HTML5 is a "native" form of development - store bought apps can be written in it. Statitics of what programming language a developer used to develop a mobile app is not disclosed.
There are frameworks like PhoneGap and Sencha Touch that make it very difficult to tell if some app is written in HTML or in the native widget toolkit of the platform. The advantage of the HTML5 approach is the same app can be share code between multiple phone platforms, of course, and with desktop apps as well.
@bass.. Yes .. That's correct I forgot googles non cloud os android applications are written in html5 ...
if you need a external framework to write html apps for mobile i woudnt really call it "native" but whatever
who cares really, time will tell. now we can choose whatever model we prefer when developing for win8 and i think thats pretty cool
That's why I put it in quotes. It's native in the sense that HTML5 apps are apps like any other, that can have an icon and a price. This was true even when Apple was going all fascist with their developer EULA and what development frameworks would be allowed on iOS.
And even now I believe Microsoft (the only company I know of that doesn't explicitly do HTML5 apps yet, even Blackberry does) is sponsoring PhoneGap development so that it will work with WP7 Mango. So really HTML5 is the universal mobile phone development environment, if you want to write an app that works everywhere you do it in HTML5. C# is close (thanks to Mono, not Microsoft).
yeah.. in theory.. all those platforms have their own quirks and so does all the browsers (yes even ff and chrome) so its not really the case that you can write the app one way and it will work everywhere.. you almost can though.
I don't find that to true. For instance if I code directly to ExtJS or jQuery my app will work with IE6 even, because they did all the work to get their stuff working on multiple browsers I get to take advantage of that.
The browsers anyway are very much converging in web standards support so writing cross platform web apps has never been easier, even without libraries.
IMO, Microsoft's embracing of HTML+JS is to bring in non-Microsoft web developers into the Microsoft ecosystem. That's really the only reason.
While the language and markup will be familiar to all web developers, you won't be able to fully-exploit the Windows OS with your application unless you use the Windows-specific namespaces. That means you can forget about running the same "immersive" application on anything but Windows 8. So the purpose of HTML+JS in Windows 8 isn't about "write once, run many". In fact, Windows 8 makes XAML the more likely candidate to truly realize the write once, run many utopia (at least within Microsoft's ecosystem: Windows 8, Xbox, and Windows Phone).
As with native mobile phone development, developers are going to have to decide which ecosystems that they want to target. From a market-size standpoint, it's going to be difficult to ignore Windows 8 as a target market. The ability to leverage HTML+JS will make it all the more appealing to target the platform since the learning curve is greatly flattened. And once Microsoft has these HTML+JS developers as a captive audience within the Microsoft ecosystem, I think they're going to push them hard toward XAML + C# development.
The cynic will call this embrace, extend, extinguish all over again, but from a developer's standpoint who wouldn't want to be able to write once, run many?
yeah, js might work, but css sure wont.. input fields anyone? and even if new browsers are getting better at standards, old one will be with us for a long time, especially on phones
certinly for windows 8 apps developed using the web model will not work anywhere but in win8, so the cross platform argument seems a little weak
The thing is Microsoft's ecosystem is not sufficient. Microsoft's business model of developer lock-in only works if Microsoft has a virtual monopoly over the software industry platforms. But seriously Apple and Google changed that. If you live in some la-la land where everyone uses Microsoft and only Microsoft, XAML is great stuff. But I don't think most do. I think Microsoft's days of monopoly are over, so they can embrace+extend all they want - it will fail and probably get them sued to hell anyway.
The thing is Microsoft's ecosystem is not sufficient. Microsoft's business model of developer lock-in only works if Microsoft has a virtual monopoly over the software industry platforms. But seriously Apple and Google changed that. If you live in some la-la land where everyone uses Microsoft and only Microsoft, XAML is great stuff. But I don't think most do.
You don't have to "live in some la-la land where everyone uses Microsoft and only Microsoft" for XAML to be compelling. The target market just needs to be sufficiently large for your investment in that platform. That's why a large percentage of mobile developers target both iOS and Android and leave WP7 out of the picture. That's why some mobile developers exclusively target WP7. While the target market is small (for now), the investment is small (for them).
Having now sat through the keynote and had a look at the WinRT stuff, I'm unconvinced that "WinRTis Windows" as the presenters claim.
I guess the proof will be in the pudding, and we don't have to wait too long for a download.
To me, WinRT is a series of native, "Win32" if you will, components that all have suitable managed wrappers that run on the CLR4. WinRT itself is a framework that hosts the CLR4 (rather than having a separate CLR fork) and includes the BCL4 assemblies in addition to the new Windows 8-specific ones (such as the sensor framework).
Everyone seems to throw all native development into the "Win32" bucket. Strictly speaking I'd put things like Window classes and the Message Pump in this bucket, and other things under the Windows (base) API. Windows Forms is directly built on top of Win32, and WPF to a lesser degree.
It explains a lot: the JS stuff most likely uses the DLR - which means it's possible someone will add the ability to use Python and other DLR languages. The presence of C++ was probably referring to CLI/C++ rather than pure native C++ on account of how the "XAML" box overlapped both the C# and C++ blocks.
There has been a version of Silverlight with XAML for Windows Embedded for a while now. XAML is really just a format for specifying object graphs so it could be used "natively" if you can express the concepts in a language like C++. Many people confuse it with markup languages that operate differently.
People often complain about the performance of .NET client applications. One of the biggest problems (that gets talked about less that memory bloat, graphic perf etc) is startup time. This is a big issue for anyone building a utility type app that you want to spin up quickly without a noticeable delay.
It is so bad that the IronPython team at one time had a workaround that interpreted scripts on the first run to give instant results. On subsequent runs jitted code was used. This is sad in a lot of ways because the performance of subsequent runs is amazing. Their users needed the scripts to support quick editing and iteration. For windows client developers the only way to get this rapid startup performance is to trying NGen, or write a native app.
I believe the source-level compatibility with Trident is a coincidental with the fact the DLR JS runtime strictly complies with the ECMAScript specification. I don't believe the native JS JIT engine makes any appearances in WinRT. This is further evidenced by the support of the HTML+JS platform in Blend, which is just a design-time host for XAML and presumably a similarly .NET-derived HTML+JS platform.
Following on from my last point, embedding trident in a native app is a great way to get quick startup and a simple programming model. With IE9 graphics acceleration was the icing on the cake. For the reasons of startup performance I don't think you'll see anything other than trident.
Off-topic, if this means Microsoft has developed a managed HTML+JS platform, it's possible we'll see a decent web-browser made available for the Xbox 360.
I doubt you'll see any managed browser, although Microsoft's efforts to port newer IE versions to Windows Phone might offer something in the future.
I think Microsoft's days of monopoly are over, so they can embrace+extend all they want - it will fail and probably get them sued to hell anyway.
Because HP and Samsung don't have a long history of anti-trust convictions?
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.