The (Proper) WinRT Speculation Thread

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 ...

@Bass:

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).

@Bass:

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.

Yes universal means least denominator ... http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(HTML5) Of yet to be finalized spec

@aL_:

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?

@Bass:

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.

30 seconds ago,Bass wrote

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).

@Bass:

yeah because apple never tries to lock in developers or anything.. get real dude

the RDF is strong in this one..

The real question is why would one program Windows specific  HTML5/JS when he could use superior XAML/C#?

@W3bbo:

1 hour ago,W3bbo wrote

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.

Any thoughts, speculation, or evidence otherwise?

6 minutes ago,Bass wrote

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.

If you look at any of the non-browser-based HTML+JavaScript development platforms, you'll most likely see platform-specific script libraries and direct access to native APIs through "plugins". Why would Microsoft get sued for "embracing" HTML+JS and not HP/Palm for WebOS or Samsung for its Smart TV SDK?

2 minutes ago,section31 wrote

The real question is why would one program Windows specific  HTML5/JS when he could use superior XAML/C#?

I wouldn't, but you might want to in order to get up to speed quicker if HTML+JS is all that you know.

@section31:

indeed.. i've used both pretty extensivley and i'd pick xaml in a heart beat

4 minutes ago,cbae wrote

*snip*

If you look at any of the non-browser-based HTML+JavaScript development platforms, you'll most likely see platform-specific script libraries and direct access to native APIs through "plugins". Why would Microsoft get sued for "embracing" HTML+JS and not HP/Palm for WebOS or Samsung for its Smart TV SDK?

Because HP and Samsung don't have a long history of anti-trust convictions?