This project is actively developed by the WinJS developers working for Microsoft Open Technologies, in collaboration with the community of open source developers. Together we are dedicated to creating the best possible solution for HTML/JS/CSS application development.
Another bit of Build news: WinJS has been released under the Apache 2.0 license.
So this is apparently an alternative to building Windows Store apps with C#/XAML. What is actually the preferred method, esp with the new ‘Windows everywhere’ announcement today? Does this change anything? I mean, what do you use when you want your stuff to run on all those platforms?
Edited 2014-04-03 00:21 UTC
Nice. But I hoped, that Microsoft would publishing .NET under an OpenSource-license during the //build/-conference.
The source code of .NET is already published
http://referencesource.microsoft.com/
http://referencesource.microsoft.com/download.html
it is only not OpenSource.
I thoughted so, because there was some rumor, that Microsoft could acquire Xamarin:
http://www.crn.com/news/mobility/300072056/sources-microsoft-in-tal…
http://blog.xamarin.com/party-with-xamarin-.net-at-build/
And Xamarin is the main-developer of the OpenSource .net-implementation Mono:
https://github.com/mono
http://www.mono-project.com/Main_Page
I think, Microsoft wouldn’t have lost anything, if they have had done it. But they would have won a happy OpenSource-community.
For me, Satya Nadella is disappointingly.
Not much opensourcing.
Going straight the way of Steve Ballmer:
The Win8.1 update becomes the start-menu back, but with live tiles and all the Win8.x shit.
His new mantra is “mobile first, cloud first”:
http://www.pcworld.com/article/2094281/mobile-first-cloud-first-mic…
http://www.microsoft.com/en-us/news/speeches/2014/03-27nadella.aspx
and so on.
8.1 comes with all disturbing, displacing, hiding, bloating (midnight TV info-mercial mentality) things???
It is a working tool. Something to do something else.
“Virtual store”, “virtual theater”, “virtual kiosk” and else are just travesties, clothing, and as such, should be totally optional an extra.
Begins to look like a lost argument
Edited 2014-04-03 16:53 UTC
Have been looking at the page where you can try all components and I must admit I’m impressed. Finally a decent GUI toolkit for the web.
Only downside is that a lot of controls are IE only.
I haven’t tried it, but that sounds like a pretty big downside – big enough for me not to consider using it for anything.
As far as I’m concerned if some of the UI controls are IE only then this is not “for the web” in the open sense of the word.
If something displays in IE only open an issue about it so that it can be fixed.
Obviously they’re not going to open source a framework intended to be IE only.
I just went though the majority of the examples on the playground using Chrome on the mac and I didn’t see any that didn’t work. Can you tell me which ones failed for you?
Well, it seems I was a bit too early in my judgement. The bulk of them work in Chrome, although some of them are IE only.
See this issue list for more info:
https://github.com/winjs/winjs/issues
But open sourcing it, will definitely make support on other browser better.
Only if they other developers see a use for it and want to use it and report bugs.
Who exactly is so insane to develop apps using a bunch of technologies designed for documents?
I hate all of them – first, because I don’t like them, and second, because you _have_ to use them.
Dig into most Mac apps and you’ll find that the UI is defined in XML documents. Sure, developers tend to not write that XML themselves and instead draw out their UI inside Xcode, but the underlying tech is XML. I’m not all that familiar with other platforms, but I’m fairly sure that most these days support having the UI defined using some kind of document format. It’s generally considered good practice to separate your views from your controllers, and it makes sense to use a document format for views.
Using HTML for a user-interface layer of an application really isn’t all that different to many desktop applications.
HTML+CSS has long since evolved away from being just a simple document markup pair.
Of course if you’re adamant in insisting on avoiding using both for apps that run on a web stack you can always use HTML5 Canvas or WebGL and draw all your UI widgets yourself.
Yes, I do some Mac coding
But that’s not the question. The underlying model of a window system is completely different from a document model, that’s the point. It’s a nightmare to try to mimic a window model in HTML.
No thanks, too much work. And I hate JS too.
The only thing that and HTML have in common is the fact that they’re both markup.
HTML is poorly suited for actually describing interfaces. Its more oriented towards documents because that was its original purpose.
Writing UI in HTML is a nightmare thanks to what could quite possibly be the most backward layout model ever with CSS.
Sorry but you don’t really know how to do CSS with comments like that.
Oh come, its a mess of cryptic properties (inconsistently implemented), a ton of hacks to get even basic layout functionality working, and some trial and error.
The problem imo stems from layout being split across HTML and CSS where you define structure in HTML but define layout behavior in CSS.
Whereas in XAML I can just define a Grid, in HTML I need to define a parent container, then apply a layout mode (sometimes to itself, sometimes to children via a selector).
That’s to make up for a lack of attached properties.
You end up with this real disjointed representation. You can’t reason about the layout without looking at both the markup and the styling.
The same goes for a vertically stacked panel with proportional sizing.
In XAML layout and structure are defined in XAML and its a first class experience. That’s because it was from the start conceived to be a model for applications.
With HTML after more work than I care for, I can have something resembling a coherent layout that works on most browsers (quirks and naming differences aside).
These comments would have been fair back when CSS 2 wasn’t fully supported. But it is completely nonsense now.
If you write semantic and well structured HTML there is no problem. If you use well understood patterns (Object Orientated CSS and Atomic Design for example) it is extremely easy to create web components.
http://bradfrostweb.com/blog/post/atomic-web-design/
As for dealing with Minor Quirks. Use a CSS framework, the hard work is done for you. All these comments come out of not actually learning it properly.
HTML + CSS certainly has come a long way they last 15 years, especially with the aid of jquery and browsers supporting all of CSS 2 reliably by now.
But the key issue HTML and CSS has always had is that both were designed for text document layout. The page is always laid out top down and the CSS cascade only really makes sense in a text document context. Same applies to the concept of semantic tags – there are no tags for describing complex controls beyond the generic div tag. It is exactly for reasons like this that vertical alignment and layout is so difficult in CSS and creating controls (what your silly article tries to describe using comical references to the periodic system) is equally hard.
There are of course hacks and workarounds for the problems and even CSS 3 specs trying to address some of these issues – but pages like you linked really just confirms that even the most basic concepts from traditional UI frameworks are only now beginning to be possible to implement with a combination of HTML, CSS 3 and Javascript.
There are no tags for describing layout because there shouldn’t be. Structure and Layout should be separate.
Sorry but if you look at the bootstrap framework, things that are Styling are styling, things which are markup are markup and things which are logic are done in JS.
Claiming there are hacks, because other people haven’t grasped how to do it properly (when there are plenty of good frontend frameworks that do it right) is exactly the same as claiming Java is bad because you only seen in mis-used.
Sorry Nelson but the more you carry on the more you are showing yourself up to be ignorant.
I think structure and layout are fundamentally the same thing. And the container should dictate the layout semantics, not have it interleaved with CSS.
Your response serves only to underscore my point, that a lot of this by default isn’t suited for general application development. Its been bolted on after the fact. There are a lot of pain points. WinJS addresses those as do other JS frameworks, but Christ man how is anyone supposed to grok all of this.
You’re digging into tons of learning before you even get to actual application logic. Its comical.
Through patterns, and a lot of reading you can possibly start to do some nice things but the learning curve is staggering.
But the person you replied to most recently isn’t me 😉
Nelson,
I agree with you. HTML/CSS can be lousy at times. I appreciate the idealism of having the ability to change styles separately from the content, however it get’s severely abused when it comes to layout.
Obviously it’s best when content is authored from the get go by people who understand CSS, but it’s rare that clients do. They just want you to copy/paste the document they emailed you and wonder why it’s taking you so long to muck around with CSS. Then they make more changes to their document and want you to magically sync it to the website, this is when CSS becomes a nightmare to maintain. It is often easier just to keep it simple and copy/paste what we are given, local styles and all – it avoids the whole “I made this change in the document, why isn’t it on the website?” problem. While the “uncleanliness” of this approach is not ideal, it usually fits better with what the client is actually trying to do.
TLDR: Global CSS styles are not always compatible with client workflows.
Please disregard: I posted this on the wrong story.
Edited 2014-04-03 16:02 UTC