WinJS looks like another soon-to-be-legacy wrapping framework. It doesn't use Shadow DOM, or allow developers to create new elements, which means that you end up with div-soup and important APIs and state that should be part of the view are in separate objects.
Because of this, WinJS will have a hard time interoperating with other wrapping frameworks like Angular, Ember, GWT, Ext-JS, etc.
Custom elements and Shadow DOM are hugely important for composable web applications. At this point, for SPAs, I wouldn't use anything that doesn't support them, even at the cost of IE8 support.
Unless I'm reading something wrong, that doesn't look like W3C custom elements ( http://www.w3.org/TR/custom-elements/ ), but CanJS's own system for recognizing custom tag names, like Angular directives. The docs even say "Currently, this only works within can.Mustache templates."
W3C custom elements allow the browser to still parse the document, and when it encounters a tag that has been registered with document.register() it calls user code to create construct element. By having the browser be in charge of parsing and element construction, custom elements work without a framework, and when you modify the DOM via things like innerHtml.
Approaches like Angular directives, and I'm guessing CanJS components, usually break down when the DOM is modified outside of certain blessed APIs.
Isn't XAML just HTML (declarative markup, with some default behavior, with most behavior defined through linked code in a more-traditional programming language) for the .NET stack?
I know everyone has their reservations about Microsoft and their developer ecosystem, but WinJS really is a delight to use, at least in my limited experience. A WinJS app is really just a zip of a bunch of JS (using WinJS's nice APIs for fancy stuff), CSS, and HTML, so most web developers who are used to the modern tool chain should be pretty comfortable with it. And yes, you can supposedly use it alongside Backbone/Angular/whatever. Worth a closer look.
I was really surprised for how much they pushed it today, considering that is not strongly adopted in the windows dev ecosystem (maybe also because, since today, it did not work on windowsphone).
I am personally happy of this decision, and also for the support announced for other oss.
To be honest I've always wanted a file format that is exactly as you described. A zipped up front end web app. No internet dependencies so it works 100%. User can open the open the format and it opens in their browser of choice. All the files contained within are "hosted" from a static "webserver" that just hosts the files within the .zip.
I can't say much to WinJS yet, but I am interested in their choice of container.
Had no idea the Skype and Music app UI's were built with WinJS. Playing around with the demo's really does pass the eye test. This is really good stuff.
IndexedDB is fine for storing JSON objects, etc. but a relational database with SQL query syntax, indexes, etc. more powerful and means less code to write. With IndexedDB one has to reinvent the wheel to just get basic query features.
That's because both thoroughly understand the difference between a standard, and picking a random implementation that all other browsers would need to inherit (which was exactly what WebSQL would have led to).
Instead we got a kickass asynchronous IO ordered map + secondary indices implementation, which is vastly simpler to describe and implement in a uniform fashion, on top of which one could easily write an SQL parser/planner, or simply use it as a blobstore for a cross-compiled SQLite binary, or whatever else.
(Funny how SQLite is about the only SQL implementation that would even be suitable for this. Same reason WebSQL was a bad idea.. it essentially required SQLite's exact semantics)
WebSQL is not deprecation, the W3C Working Group Note actually says 'This specification is no longer in active maintenance and the Web Applications Working Group does not intend to maintain it further'.
As SQLite is in public domain, no company would "loose their face" if they choose to use it. They could fork off SQLite and change the SQL query syntax (parser) to whatever the W3C finds suitable.
Mozilla Firefox and FirefoxOS both already ship SQLite for years and can be accessed by its internal JavaScript API. And several Microsoft products already use it anyway (e.g. Forza Xbox games). Microsoft has of course also various other SQL database libraries like MS Access JetRed (http://en.wikipedia.org/wiki/Extensible_Storage_Engine ), MS Outlook JetBlue (http://en.wikipedia.org/wiki/Extensible_Storage_Engine ) and MS SQL Server Express (http://en.wikipedia.org/wiki/SQL_Server_Express ) the SQL backend originally forked off for WinFS for Longhorn (Vista beta). It would be trivial for Microsoft to choose one of its many SQL engines and add it to IE 12. The same goes for Mozilla (just expose the API).
For some reason Oracle and Mozilla pushed IndexedDB. Oracle has conflicting interests, as it owns OracleDB(SQL), MySQL (SQL) and BerkeleyDB (NoSQL and now also SQL support, based on SQLite). Oracle is an official "sponsor" of SQLite development and even ships it as part of it's BerkeleyDB package: http://www.oracle.com/technetwork/database/database-technolo...
One can speculate that a less powerful HTML5 API translates in the long run to more SQL server licenses for Oracle and Microsoft. If the web app devs cannot do the processing & storage on the client side, one has to do it on the server side.
Anyway, I hope that we get a SQL API for HTML 5.x that also Mozilla and/or Microsoft implements. As of now WebSQL works fine in webkit based browser which includes Safari, Chrome, Opera and includes also 95% of all smart phones.
Welcome to 2014, where Microsoft web stuff still works best in Microsoft Internet Explorer...
They had an actual shot on getting up to par with proper HTML5, with funky ms extensions being optional where absolutely neccessary. Instead, they rely on an astounding number of non-cross-browser methods and features, as they have done since '95
Not entirely fair, considering: (1) these are marked as issues that need to be fixed, and (2) many of them are related to IE implementing the CSS-grid W3C draft, vs. coming up with their own proprietary technologies.
(Your comment was modified since I hit reply, but I think my point still stands, especially that it isn't strictly MS-extensions, but actual standard drafts)
"The WinJS is a library of CSS and JavaScript files. It contains JavaScript objects, organized into namespaces, designed to make developing Windows Store app using JavaScript easier."
I did notice some of them only to work in IE since it uses the MS- prefix. However they are also marked as an issues that would be fixed later. So hopefully it be corrected soon but since its already open sourced and the syntax is merely CSS3, its won't be that hard to go ahead and fix it yourself.
Working on a project that relies heavily on CSS3, I have come to the conclusion that most browsers still depend on vendor specific prefixes. Take the CSS animation for instance, without the inclusion of "-webkit-", it fails to work in the latest Chrome and Safari while having no issues on Firefox or IE.
LESS or SASS/Compass are you friends :) ...and the only way to maintain sanity when doing heavy edgy CSS3. Once you have your mixins abstracting away browser prefixes and common patterns, you can get to the new level of style patterns reuse with higher-order-functions-like features like LESS's mixins that can take mixins as arguments (great for the @keyframes prefixes madness at first, afterwards only your masochism and imagination set the limit). I'll never be able to stand the pain of writing "plain ol' CSS by hand" again...
I was recently commissioned by a mid-size company to port their web-based issue manager app from Microsoft Silverlight to plain HTML + a server side language.
Their reasoning was that as Microsoft is pulling the plug on Silverlight, the company did not want to implement new features in their issue manager app inside a dying platform. So they decided to first port their app to a vanilla thing and from then on continue developing their app further.
Am I comparing Silverlight with WinJS? No. But will this company rush to invest time and money into yet another pumped-up Microsoft product? No either.
Microsoft's earnings are tightly coupled to the tech churn they themselves instigate; it is impossible to count on their new technologies until each gains self-perpetuating inertia.
I had a conversation the other day on my commute about rough (or failed) SAP migrations/implementations and it was clear that the buyers and other supply chain folks fallback to emailing excel spreadsheets when things hit the fan. This ubiquity of their products and it being the lowest common denominator means they will never go out of business. Like it or not Microsoft products are the glue that holds the business world together.
Like any commercial vendor optimized around selling software licenses. A commercial vendor optimized around selling software-backed services and complete solutions has different incentives, since they end up eating the costs of churn. Unsurprisingly, lots of companies that do the latter are built around (and often sponsor) open source software.
Perhaps. Service providers ensure the services they provide are often needed to get the job done in a timely manner. More subtle, but effective. All companies have to make money.
Sure, and that can be problematic -- see Intuit's intensive lobbying to keep tax filing onerous to protect TurboTax's niche -- but that's a different specific issue than promoting software churn (well, except in Intuit's specific case, where while they demonstrate the problem that can exist with solution providers, they are also a licensed-software provider that can also be seen as promoting software churn at the same time.)
Their main target with this library is Windows Store Apps though - not web sites or applications. I'm sure they'll work on cross-browser compatibility, but I don't think it's one of their priorities.
It wouldn't be fair to mention this without mentioning of the 3 fixes landed since that repo was created, 2 are for cross-browser compatibility bugs..
That aside, I love how this negativity only seems to stick to Microsoft when every other major player has their own private set of bits that only work well on their platform (WebOS, Firefox OS "proposed standard" mobility APIs, Chrome endless variety of "we're doing it so it's going to be a standard" APIs, etc). It's no excuse, but it's hardly unique to MS
Datacenter hardware designs are valuable. They solve physical limitations of heat dissipation, airflow, as well as compute power density problems and electrical stuff.
Companies building their own DCs spend a lot of money on doing this, so companies like Microsoft (I think Facebook do it too) showing off their designs is really useful.
Just IMO, but perhaps it doesn't "stick" because none of the other folks spent years trying to use their effective OS monopoly to extinguish everything that wasn't their proprietary browser.
Maybe I'm misunderstanding, but isn't NaCl meant to be cross-platform? ActiveX was basically "hook directly into Windows (and only Windows) from the browser." It gave many free-license to create "Windows-only" webpages, in addition to producing many security holes during its run. This is where much of the resentment comes from.
How many security bugs does NaCl have compared to ActiveX? How do Microsoft's attempts to sandbox ActiveX compare to the efforts made to sandbox NaCl? IIRC, you could format the C: drive in ActiveX with a couple of lines of code (by design). NaCl (so far as I know) isn't supposed to allow that.
As far as I'm concerned, NaCl and ActiveX aren't even in the same ballpark.
The github issue for that is listed right under it. It looks like they may be pulling them in automatically via tags on the issues. If so, that's one of the best documentation -> issue systems I've seen.
I share/understand your cynicism, but am hopeful that Microsoft is really turning a corner with the latest management change. The messaging has certainly been a lot more cross platform. And something like WinJS you don't do in a day or a week, I could easily believe that throughout its life it was a 'windows only' thing until the strategy changed and now its a cross product thing but carrying a lot of technical debt from that previous positioning.
Lucky for both of us there is a built in barometer for seeing how committed Microsoft is, in the form of the Github issues list.
The funny thing about the do-not-track header, is when you setup Windows 8 it's on by default... then on the next page all the things that send data to MS are also enabled.
Understood, but as I said they have a chance to show us they are sincere by making WinJS a really exceptional cross platform tool. I am a firm believer in keeping your hopes high and your expectations low.
Did you click on read more? Even if you didn't, just scroll a bit down and there is the WinJS in production code section which show off some example apps. That didn't tip you off about WinJS?
Just to point out, at the moment the big part of those signaled bugs does not work also in IE version < 11. This must stress the fact that, at the beginning, winJS was used only for windows app store and only recently it is being opened towards a cross platform evolution
But really, I suspect the name is indeed intended to reflect Microsoft's flagship brand: Windows. They're proud of the brand and I'm sure there's no shortage of misunderstandings within Microsoft about how the public (mainly developers I believe) view the brand.
They called it WinJS since the start—it seems this is the same library that's used to build Windows 8 metro apps in JS. They just officially open sourced it now (although you could always access the source, as it was just another dependency for your Visual Studio project) but it's been in use by people from Microsoft and otherwise for quite some time.
Because its origin is as stupid as the origin of MtGox...
...and hopefully it will die the same kind of burning death.
Use HTML5. End of discussion. If Microsoft want to work hard to get their ideas into HTML5, then go for it. PLEASE. HTML5 could get better with their help.
So, this would basically be Microsoft's Windows-only version of node-webkit[1], then? (I've been thinking the comparison was pretty clear since Metro JS apps first appeared, but now that they're going to be able to be window-ified as well, it's much more stark.)
no. In order to do that, they would have to release the IE html rendering engine (i think they call it Trident) to open-source, and bind it to the nodejs engine..
This(WinJS) is basically a library that wraps UI components in JS, CSS and HTML DOM.. its sugar for baked and easy to use UI components (in theory in any html rendering engine)
I didn't mean implementation-wise, I meant in practice: they're both technologies that allow you to ship a zipped blob of HTML+CSS+JS that presents itself as a program, and has additional native APIs, beyond the regular HTML5 ones, exposed to the Javascript engine.
> has additional native APIs, beyond the regular HTML5 ones
I think maybe in windows you have native bindings to windows-specific api's.. but whats is shipped here is only the UI + databindings, mvc voodoo for plain HTML5.. for aditional native api's exposed to the javascript engine, you will need something like node-webkit..
This use nodejs just to compile giving a minified js + css styles.. so it's more like bootstrap or ionic framework
Microsoft is doing a big developer conference this week, and is announcing a lot of new stuff that HN finds interesting. When WWDC rolls around again, I'm sure there will be a ton of Apple stories on the front page.
Negative. This is just a tool for creating Metro apps and it has existed since Windows 8 came out. People are talking about it now because Microsoft just open sourced it.
How does it compare with AngularJS? There might be some overlap but it is not a competitor. In fact, Microsoft uses AngularJS frequently on their sessions, documents, templates, etc.
WinJS started out as a tool for creating Metro apps with HTML5 and JavaScript as an alternative to XAML and C#. I don't know if Microsoft is now spinning it as a general purpose web tool but that was not its original purpose. And this has always been explicit. The default ASP.NET MVC template, for example, bundles Bootstrap and jQuery. And if you look at the SPA examples they're all in tools like AngularJS and Knockout. In fact, in one of their build sessions they teach how to create a SPA with AngularJS. As far as I know the ASP.NET team has never used WinJS.
So it wouldn't surprise me if this library didn't work great on the web on any browser because it wasn't created for that purpose.
At first I thought it was a cross platform app building something-or-another (kinda like Xamarin), but now that I actually am building it and playing around with it I see that it's something else entirely.
I'm actually glad this happened though. Seems like MS is finally rallying around C# as the defacto language for building apps (as opposed to Visual Basic or even Visual C++). This project might succeed (or at least find a nitch) among developers who are building touch centric web applications.
Though I haven't checked, I would guess that WinJS has strongly-typed TypeScript bindings, for those who choose to use TypeScript. But releasing the library itself in JS makes it available to a wider audience and doesn't prevent it from being used in TypeScript.
I'm surprised they decided to re-implement a lot of the available open source libraries (like WinJS.Promise looks a lot like kriskowal/q). Why re-invent the wheel?
Issues like https://github.com/winjs/winjs/issues/25 continue saying that MS is maintaining an internal project and dropping things to Github and then synching back. That's the last mile, the thing that desperately needs to change to gain full credibility within the open-source community. It should only be on Github and all development should be in the open.
One thing that isn't clear at all is if it is necessary to use Visual Studio to build a WinJS app. Can I develop and test the app on a MacBook or Linux laptop in a web browser, and only involve Visual Studio when I need to package the app for the store? Or is VS required to even get started?
They have a project file for Sublime Text 3 and are using grunt as a build system so you should be able to use it on a Mac or in Linux. However from their road map it looks like they are still trying to fix a lot things that only work in IE.
"GitHub issue 9: This control currently works only in IE due to its dependency on IE-only styles ::-ms-fill-lower, ::-ms-fill-upper, ::-ms-ticks-before, ::-ms-ticks-after, and ::-ms-tooltip."
Another reason why this sucks, you can even't copy that stupid text from that page in Chrome.
/me smashes monitor with keyboard, then ragequits.
I could! `GitHub issue 9: This control currently works only in IE due to its dependency on IE-only styles ::-ms-fill-lower, ::-ms-fill-upper, ::-ms-ticks-before, ::-ms-ticks-after, and ::-ms-tooltip.`
132 comments
[ 3.0 ms ] story [ 181 ms ] threadWinJS looks like another soon-to-be-legacy wrapping framework. It doesn't use Shadow DOM, or allow developers to create new elements, which means that you end up with div-soup and important APIs and state that should be part of the view are in separate objects.
Because of this, WinJS will have a hard time interoperating with other wrapping frameworks like Angular, Ember, GWT, Ext-JS, etc.
Custom elements and Shadow DOM are hugely important for composable web applications. At this point, for SPAs, I wouldn't use anything that doesn't support them, even at the cost of IE8 support.
[1]http://canjs.com/docs/can.Component.html
W3C custom elements allow the browser to still parse the document, and when it encounters a tag that has been registered with document.register() it calls user code to create construct element. By having the browser be in charge of parsing and element construction, custom elements work without a framework, and when you modify the DOM via things like innerHtml.
Approaches like Angular directives, and I'm guessing CanJS components, usually break down when the DOM is modified outside of certain blessed APIs.
[1]: https://github.com/winjs/winjs/wiki/Roadmap
Isn't XAML just HTML (declarative markup, with some default behavior, with most behavior defined through linked code in a more-traditional programming language) for the .NET stack?
So wouldn't XAML for the web just be HTML?
I am personally happy of this decision, and also for the support announced for other oss.
I can't say much to WinJS yet, but I am interested in their choice of container.
You can do ClickOnce and WPF as well if you want.
I rather like these solutions. I've built several of both.
http://en.wikipedia.org/wiki/WebSQL
IndexedDB is fine for storing JSON objects, etc. but a relational database with SQL query syntax, indexes, etc. more powerful and means less code to write. With IndexedDB one has to reinvent the wheel to just get basic query features.
Instead we got a kickass asynchronous IO ordered map + secondary indices implementation, which is vastly simpler to describe and implement in a uniform fashion, on top of which one could easily write an SQL parser/planner, or simply use it as a blobstore for a cross-compiled SQLite binary, or whatever else.
(Funny how SQLite is about the only SQL implementation that would even be suitable for this. Same reason WebSQL was a bad idea.. it essentially required SQLite's exact semantics)
As SQLite is in public domain, no company would "loose their face" if they choose to use it. They could fork off SQLite and change the SQL query syntax (parser) to whatever the W3C finds suitable.
Mozilla Firefox and FirefoxOS both already ship SQLite for years and can be accessed by its internal JavaScript API. And several Microsoft products already use it anyway (e.g. Forza Xbox games). Microsoft has of course also various other SQL database libraries like MS Access JetRed (http://en.wikipedia.org/wiki/Extensible_Storage_Engine ), MS Outlook JetBlue (http://en.wikipedia.org/wiki/Extensible_Storage_Engine ) and MS SQL Server Express (http://en.wikipedia.org/wiki/SQL_Server_Express ) the SQL backend originally forked off for WinFS for Longhorn (Vista beta). It would be trivial for Microsoft to choose one of its many SQL engines and add it to IE 12. The same goes for Mozilla (just expose the API).
For some reason Oracle and Mozilla pushed IndexedDB. Oracle has conflicting interests, as it owns OracleDB(SQL), MySQL (SQL) and BerkeleyDB (NoSQL and now also SQL support, based on SQLite). Oracle is an official "sponsor" of SQLite development and even ships it as part of it's BerkeleyDB package: http://www.oracle.com/technetwork/database/database-technolo...
One can speculate that a less powerful HTML5 API translates in the long run to more SQL server licenses for Oracle and Microsoft. If the web app devs cannot do the processing & storage on the client side, one has to do it on the server side.
Anyway, I hope that we get a SQL API for HTML 5.x that also Mozilla and/or Microsoft implements. As of now WebSQL works fine in webkit based browser which includes Safari, Chrome, Opera and includes also 95% of all smart phones.
It'd be nice to have a real standard relational database API and supported functionality in browsers, but WebSQL wasn't ready to be it.
WinJS is at the core of Lightswitch development coupled with JQueryMobile.
They had an actual shot on getting up to par with proper HTML5, with funky ms extensions being optional where absolutely neccessary. Instead, they rely on an astounding number of non-cross-browser methods and features, as they have done since '95
https://github.com/winjs/winjs/issues Most issues listed currently are about stuff that just doesn't work on any other browser/platform than IE
Footnote: I'm a web developer myself and I use Windows 8.1. How tempted have I been at fiddling with the winjs flavour myself? not at all.
Footnote2: I do have to give them credit for the roadmap though. It seems like they're on the right track https://github.com/winjs/winjs/wiki/Roadmap
Footnote3: I've been fooled into thinking that Microsoft was on the right track again and again.
(Your comment was modified since I hit reply, but I think my point still stands, especially that it isn't strictly MS-extensions, but actual standard drafts)
Working on a project that relies heavily on CSS3, I have come to the conclusion that most browsers still depend on vendor specific prefixes. Take the CSS animation for instance, without the inclusion of "-webkit-", it fails to work in the latest Chrome and Safari while having no issues on Firefox or IE.
[1] http://www.w3schools.com/cssref/tryit.asp?filename=trycss3_a...
1. https://github.com/ai/autoprefixer
Their reasoning was that as Microsoft is pulling the plug on Silverlight, the company did not want to implement new features in their issue manager app inside a dying platform. So they decided to first port their app to a vanilla thing and from then on continue developing their app further.
Am I comparing Silverlight with WinJS? No. But will this company rush to invest time and money into yet another pumped-up Microsoft product? No either.
"Trust, Users and the Developer Division" discussion 2 months ago - https://news.ycombinator.com/item?id=7107544
Like any commercial vendor optimized around selling software licenses. A commercial vendor optimized around selling software-backed services and complete solutions has different incentives, since they end up eating the costs of churn. Unsurprisingly, lots of companies that do the latter are built around (and often sponsor) open source software.
That aside, I love how this negativity only seems to stick to Microsoft when every other major player has their own private set of bits that only work well on their platform (WebOS, Firefox OS "proposed standard" mobility APIs, Chrome endless variety of "we're doing it so it's going to be a standard" APIs, etc). It's no excuse, but it's hardly unique to MS
I think Scott Hanselman put it best with his recent 'Microsoft killed my Pappy' post...
http://www.hanselman.com/blog/MicrosoftKilledMyPappy.aspx
Quote: We've open sourced Azure hardware specs, opening SDKs, and we're making systems more pluggable than ever.
Companies building their own DCs spend a lot of money on doing this, so companies like Microsoft (I think Facebook do it too) showing off their designs is really useful.
Also, ActiveX. ;)
How many security bugs does NaCl have compared to ActiveX? How do Microsoft's attempts to sandbox ActiveX compare to the efforts made to sandbox NaCl? IIRC, you could format the C: drive in ActiveX with a couple of lines of code (by design). NaCl (so far as I know) isn't supposed to allow that.
As far as I'm concerned, NaCl and ActiveX aren't even in the same ballpark.
There is NO EXCUSE for a TOGGLE to not work, cross-browser, in the year 2014.
http://try.buildwinjs.com/default.aspx#toggle
Does work on BlackBerry Z10 - no tap to toggle, but press and drag to toggle.
all on os x 10.9.2
Doesn't work in Chrome on Ubuntu 14. Doesn't work in Firefox on Ubuntu 14.
Lucky for both of us there is a built in barometer for seeing how committed Microsoft is, in the form of the Github issues list.
Word used to describe the latest coming out of Microsoft for decades now. And each time we're left wanting.
I, for one, am no longer hopeful. Internet Explorer has been and continues to be hostile to the web.
If Microsoft is open sourcing this code nothing prevents from the OO community to help them from making it more compatible with rest of the browsers.
Not much different than everyone else. Chrome, Firefox, Safari, all have features that work best in their own browsers.
Footnote: You should read it first before jumping into a conclusion.
<h2>Bringing WinJS cross-platform</h2>
But really, I suspect the name is indeed intended to reflect Microsoft's flagship brand: Windows. They're proud of the brand and I'm sure there's no shortage of misunderstandings within Microsoft about how the public (mainly developers I believe) view the brand.
e; library to build windows apps = WinJS
[0] - http://msdn.microsoft.com/en-us/library/windows/desktop/bb77...
It's Apache 2.0. If it's good right now, there is no reason whatsoever to not use it.
...and hopefully it will die the same kind of burning death.
Use HTML5. End of discussion. If Microsoft want to work hard to get their ideas into HTML5, then go for it. PLEASE. HTML5 could get better with their help.
Instead, we get this flaming pile.
I still think most of their stack sucks, but I am quite surprised with this new Microsoft. It'll be fun to compete against them again.
[1] https://github.com/rogerwang/node-webkit
This(WinJS) is basically a library that wraps UI components in JS, CSS and HTML DOM.. its sugar for baked and easy to use UI components (in theory in any html rendering engine)
I think maybe in windows you have native bindings to windows-specific api's.. but whats is shipped here is only the UI + databindings, mvc voodoo for plain HTML5.. for aditional native api's exposed to the javascript engine, you will need something like node-webkit..
This use nodejs just to compile giving a minified js + css styles.. so it's more like bootstrap or ionic framework
How does it compare with AngularJS? There might be some overlap but it is not a competitor. In fact, Microsoft uses AngularJS frequently on their sessions, documents, templates, etc.
http://channel9.msdn.com/events/build/2014?sort=sequential&d...
Edit: It seems like Microsoft is transforming WinJS into a general purpose JS library.
https://github.com/winjs/winjs/wiki/Roadmap#the-present
So it wouldn't surprise me if this library didn't work great on the web on any browser because it wasn't created for that purpose.
I'm actually glad this happened though. Seems like MS is finally rallying around C# as the defacto language for building apps (as opposed to Visual Basic or even Visual C++). This project might succeed (or at least find a nitch) among developers who are building touch centric web applications.
Jesus f Christ! 100% of people commenting here don't even fucking bother to read what the fuck WinJs is about before shooting off their mouth.
The winjs page is just a bunch of buzzwords randomly strung together.
You seem to be misunderstanding.
Disclaimer: I'm ex-msft.
http://try.buildwinjs.com/default.aspx#toggle
"GitHub issue 9: This control currently works only in IE due to its dependency on IE-only styles ::-ms-fill-lower, ::-ms-fill-upper, ::-ms-ticks-before, ::-ms-ticks-after, and ::-ms-tooltip."
Another reason why this sucks, you can even't copy that stupid text from that page in Chrome.
/me smashes monitor with keyboard, then ragequits.