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
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
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.
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.
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.
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.
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.
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.
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.)
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)
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...
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
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.
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.
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.
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.
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.
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.
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.
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.
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 writing this on a brand new, never used, lenovo thinkpad loaner with windows 7 because my 3yr old macbookpro decided to die. (Took it to apple in NYC, they'll fix it and send it to me in Portland, OR.) I can't begin to describe the awful feeling I have knowing that I have to use windows for the next week. This laptop has already frozen twice while using outlook. It takes forever just to figure out which packages to install to manage mssql server. I'm installing something now and am not sure it's even the right thing. I've already had to reboot several times.
Everything Microsoft does is counter intuitive, user and developer hostile and proprietary in some fashion. Just take a look at the Download Center. It's as if a horde of product managers were released into a Microsoft hunger games and the ones with the most esoteric description and versioning/ marketing scheme came out alive.
How anybody would willingly invest time, money or resources on anything Microsoft related is beyond me.
As someone who has a love/hate relationship with MS, I feel your pain. I've found as long as you stick within the MS family, all is well. Try to deviate from that pseudo-walled garden and its brutal.
For instance, doing Python or Ruby or ROR on a windows machine? No way. I just started doing more MEAN (Mongo, Express, Angular, Node) stack stuff and after several days of cursing the heavens and trying to figure stuff out on my Windows 7 PC, I just said screw this and went to my box running Linux Mint and within 15 minutes was up, running and coding.
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.
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.
So, this would basically be Microsoft's Windows-only version of node-webkit, 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.)
> has additional native APIs, beyond the regular HTML5 ones
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.