What platforms are targetted? Out of, say, iOS, Android, Linux/X11 desktop, Windows desktop, WinRT, OSX?
What platforms are targetted? Out of, say, iOS, Android, Linux/X11 desktop, Windows desktop, WinRT, OSX?
We're starting with iOS and Android, which will keep us busy for the foreseeable future. That said, we will open source soon, and we'd be happy to accept help targeting other platforms!
I can't wait for the API docs and sources to be released.
Tweets and videos are lousy at conveying information : )
As a long time web oriented .NET developer wanting to pick up mobile who has been wondering whether to go Cordova or dive in fully native (ObjC/Java/Xaml) this is going to make the choice very difficult.
[1] https://github.com/winjs/winjs/wiki/Using-WinJS-with-React
I put "web oriented .NET developer" in my response for this specific type of question. I kind of defaulted (11 years ago) into ASP classic and ASP.NET as a result of ad hoc consulting/support work for MS technologies back in 2000. But despite my affection for C# I abandoned ASP.NET's faux desktop event driven emulation for MVC as soon as it was released. Ever since then I felt sort of stuck in between thinking of myself as a Web Developer vs thinking of myself as a .NET Developer.
Which brings my long winded response back to your original question about WPF and data binding. WPF and Xaml are pretty foreign to me (I still have no idea about how WPF/SL/WinRT Xaml differ it all seems like Xaml to me) despite a long history with C#. But I am interested in native app development, so I have been torn on whether to go all in with C# knowing I could take it cross platform with Xamarin but need to reorient myself into the Xaml world or go all in with HTML5 knowing Cordova could be "mostly good enough".
I'm a Microsoft fan (I actually enjoy my Surface RT and Windows Phone) so WinJS on Windows 8 seemed like a good hedge for not throwing away all my JS knowledge (which is becoming a predominant part of my work with SPAs) but still letting me go fully native. But the overall Windows dev community seems to have spoken, Xaml is it and WinJS is a pariah, MS doesn't help much by staying mum on the matter but I think they are trying to shove WinJS into the Cordova camp and double down on Xaml for Win 10 with WinJS eventually fading away.
w0.Right.Bind = w1.Left + w2.Width;
And that would automatically generate a one way data binding in WPF (so if w1's left property, w2's width property, or w0's width property changes, w0's left property is automatically recomputed).I've since moved on to my own dependency management (rebranded hence forth as managed time) system called Glitch [2], but that's because I'm trying to invent what's next.
I'm an MS employee but I have no idea what what is being done in this area. I do have lots of respect for WPF, it was weird that the other platforms couldn't put forward a decent UI platform for so long (well, JavaFX, but it didn't go anywhere).
[1] http://bling.codeplex.com/
[2] http://research.microsoft.com/en-us/people/smcdirm/managedti...
What they've done with react native sounds a lot like how WPF works anyways (scene graph updated in UI thread, rendering thread then renders scene graph). Now, there is nothing wrong with that, I think its all good. But I don't think there is a good reason to use React in Windows project since most of the problems it solves have already been solved.
Like many abstractions in WPF, bindings have a "shadow world" feeling, where they are their own little isolated DSL. With the React model, "bindings" are just JavaScript expressions. Sure, with WPF you can overload operators and create "ExpressionBinding" converters and play other tricks, but you can feel the seams between the subsystems.
On the topic of the scene graph: React's scene graph is an abstract service that you can only interact with in limited ways. WPF's scene graph is a big mutable machine with most of its moving bits exposed. To a first approximation, React's rendering strategy is laziness and WPF's rendering strategy is fixed point iteration. The former is much more likely to produce easy to understand and high performing UIs, even if it comes at the cost of making a few special use cases harder. In such cases, you can bypass the abstraction and muck with the platform guts, which seems to be the default choices in the dependency properties context.
I've never heard anyone claim that laziness leads to more performant UIs. It has always been the opposite in my experience: by loosening up evaluation orders and allowing for glitching, you reduce the amount of book keeping needed to come up with optimal DAG-style re-computation orders. For example, consider a double-indirect (flat-map-style) dependency:
countLabel.Content = folderView.Selected.Count;
If count changes, you update the label. But if selected changes, you have to stop observing the previous selected folder's count property and start observing a new selected folder's count property. Carefully tearing down and building back dependency chains is tough, but if you just play lose with the dependencies, it is actually quite easy to handle (you might get some spurious re-evaluations). Note that WPF can't handle this without lots of hackery, which is one reason I moved all my UI work to Glitch (the other is that WPF is totally inappropriate performance wise for writing compilers and language-aware editors). I'm curious how React handles indirect state? Or does it need to do dependency tracing at all (it wouldn't if its not incremental; I can't tell by looking at the website)?Link please!