WinJS
-
Did anyone try using it? Opinions or ideas? Xaml still seems to be ok so why would one switch to WinJS? I can find some comparison charts on the internet but nothing beats experience.
Mobile Apps - Sound Meter | Color Analyzer | SMBC | Football Doodles
Abhinav S wrote:
why would one switch to WinJS?
Windows Library for JavaScript Yeah, exactly. Why??? Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
-
Abhinav S wrote:
why would one switch to WinJS?
Windows Library for JavaScript Yeah, exactly. Why??? Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
-
Did anyone try using it? Opinions or ideas? Xaml still seems to be ok so why would one switch to WinJS? I can find some comparison charts on the internet but nothing beats experience.
Mobile Apps - Sound Meter | Color Analyzer | SMBC | Football Doodles
You're looking at it from the wrong angle. WinJS was never intended to pull people from the XAML stack; rather, it was introduced to try to persuade JavaScript/web developers to develop apps that would run on the confusingly named WinRT/Metro/insert name here platform. If you are a web developer, the theory is that it makes more sense for you to target WinJS than it does learning C#/XAML (for instance).
-
I know what you mean - I looked at moving from WinForms to WPF a couple of years ago, but it looked and felt very "unfinished", a work in progress as it were. And the VS support was frankly very poor, even in VS2010. So I figured either the tools would evolve into a profession package or MS would drop it as they do with many good ideas. Looks like they have just sat on it and done nothing so far.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
In the meantime, WinForms (or rather, the common controls) is still one of the most tested and tried user-control set available. They're intuitive, well-known, tested to death and well documented. It is available on every platform that runs Mono, which is quite a lot. If I am to change a winning formula, there'd better be a good argument or incentive to do so.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
You're looking at it from the wrong angle. WinJS was never intended to pull people from the XAML stack; rather, it was introduced to try to persuade JavaScript/web developers to develop apps that would run on the confusingly named WinRT/Metro/insert name here platform. If you are a web developer, the theory is that it makes more sense for you to target WinJS than it does learning C#/XAML (for instance).
Documentation on WinJS is limited and at first instance it seems rather cumbersome to use. Imagine they have a namespace concept in JavaScript (sort of neither here nor there)! Any experience working on WinJS?
Mobile Apps - Sound Meter | Color Analyzer | SMBC | Football Doodles
-
In the meantime, WinForms (or rather, the common controls) is still one of the most tested and tried user-control set available. They're intuitive, well-known, tested to death and well documented. It is available on every platform that runs Mono, which is quite a lot. If I am to change a winning formula, there'd better be a good argument or incentive to do so.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
Eddy Vluggen wrote:
It is available on every platform that runs Mono, which is quite a lot.
Having mono sounds like a disease. :-D
Once you lose your pride the rest is easy. In the end, only three things matter: how much you loved, how gently you lived, and how gracefully you let go of things not meant for you. – Buddha
-
Documentation on WinJS is limited and at first instance it seems rather cumbersome to use. Imagine they have a namespace concept in JavaScript (sort of neither here nor there)! Any experience working on WinJS?
Mobile Apps - Sound Meter | Color Analyzer | SMBC | Football Doodles
I did evaluate it when it first came out - there was nothing that would make me switch from XAML, but as I have been using XAML a long time, I'm not really part of the target profile.
-
Did anyone try using it? Opinions or ideas? Xaml still seems to be ok so why would one switch to WinJS? I can find some comparison charts on the internet but nothing beats experience.
Mobile Apps - Sound Meter | Color Analyzer | SMBC | Football Doodles
I've poked at it a little bit, and it seems more built to interact with a stack back end template than with a actual developer. Just the navigation model is oblique and, as mentioned previously, cumbersome. There's also the fact that several of the hooks in it are for Windows API and not for a browser, which makes its usefulness as web application UX component limited. I can't recommend it.
-
Did anyone try using it? Opinions or ideas? Xaml still seems to be ok so why would one switch to WinJS? I can find some comparison charts on the internet but nothing beats experience.
Mobile Apps - Sound Meter | Color Analyzer | SMBC | Football Doodles
I've looked into using WinJS as a control suite/UI framework for Web Apps, as the most recent version, 4.0, can be run straight out of the browser. In this regard, it looks like a very good competitor. However, for writing Windows Store Apps, if targeting other platforms is not a concern then XAML wins. XAML/C# is far more elegant than HTML/JS. As for WinForms, XAML was definitely a step in the right direction and then came along the whole web craze which kind of killed it. Web frameworks are only starting to catch up to the abilities of XAML (check out http://aurelia.io).
-
In the meantime, WinForms (or rather, the common controls) is still one of the most tested and tried user-control set available. They're intuitive, well-known, tested to death and well documented. It is available on every platform that runs Mono, which is quite a lot. If I am to change a winning formula, there'd better be a good argument or incentive to do so.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
It's not WPF that attracts me to the methodology, but XAML. The ability to see immediate results for my UI design is mission critical. The code-compile-test-debug-compile-test cycle is a major slowdown. But XAML does have that unfinished feel. Things you would think would be part of the markup system, aren't, it omits standard elements, etc. An example of the last one is the lack of 3D primitives (sphere, torus). And the documentation is quite poor. And of course the solid entanglement with the Microsoft platform that currently exists is what stopped the Mono project from trying to import things over. But given a choice of WinForms vs. XAML? XAML/WPF wins every time (at least on Windows platforms).
-
It's not WPF that attracts me to the methodology, but XAML. The ability to see immediate results for my UI design is mission critical. The code-compile-test-debug-compile-test cycle is a major slowdown. But XAML does have that unfinished feel. Things you would think would be part of the markup system, aren't, it omits standard elements, etc. An example of the last one is the lack of 3D primitives (sphere, torus). And the documentation is quite poor. And of course the solid entanglement with the Microsoft platform that currently exists is what stopped the Mono project from trying to import things over. But given a choice of WinForms vs. XAML? XAML/WPF wins every time (at least on Windows platforms).
Basketcase Software wrote:
The ability to see immediate results for my UI design is mission critical. The code-compile-test-debug-compile-test cycle is a major slowdown.
So, you can't design a WinForm and see the results without compiling/testing/debugging? How is it mission-critical to see EACH instance of a textbox or button you create?
Basketcase Software wrote:
But XAML does have that unfinished feel.
It is not a feeling; compare it to WinForms and it is immature. The XAML-designer ate roughly 20Gb of my harddisk before crashing the IDE. You run into all kinds of crap that has already been solved before.
Basketcase Software wrote:
But given a choice of WinForms vs. XAML? XAML/WPF wins every time (at least on Windows platforms).
No, it doesn't. Some people/companies/governments prefer recognizable, consistent UI's, and will not pay to have some hardware-accelerated animations and gradients. They'll pay to not have those.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
Basketcase Software wrote:
The ability to see immediate results for my UI design is mission critical. The code-compile-test-debug-compile-test cycle is a major slowdown.
So, you can't design a WinForm and see the results without compiling/testing/debugging? How is it mission-critical to see EACH instance of a textbox or button you create?
Basketcase Software wrote:
But XAML does have that unfinished feel.
It is not a feeling; compare it to WinForms and it is immature. The XAML-designer ate roughly 20Gb of my harddisk before crashing the IDE. You run into all kinds of crap that has already been solved before.
Basketcase Software wrote:
But given a choice of WinForms vs. XAML? XAML/WPF wins every time (at least on Windows platforms).
No, it doesn't. Some people/companies/governments prefer recognizable, consistent UI's, and will not pay to have some hardware-accelerated animations and gradients. They'll pay to not have those.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
Eddy Vluggen wrote:
So, you can't design a WinForm and see the results without compiling/testing/debugging? How is it mission-critical to see EACH instance of a textbox or button you create?
Because it's not just the textbox or button, but its appearance, location, etc. I'm a game UI designer and the aesthetics often matter as much as the function. If you want "plain vanilla" appearance and function then the usual cycle is shortened as there isn't much new - but you aren't being very creative.
Eddy Vluggen wrote:
It is not a feeling; compare it to WinForms and it is immature. The XAML-designer ate roughly 20Gb of my harddisk before crashing the IDE. You run into all kinds of crap that has already been solved before.
Agreed. That's the bad thing about Microsoft. They start off with some wonderful technologies that look promising and then just let them die. And of course typically never let them completely mature in the first place. WinForms has had a LOT of developer feedback. For the longest time it was the only game in town and it's what everyone got used to. XAML/WPF comes along and there has been resistance to learning a new paradigm (as if that's a surprise!) even when some things have really needed to be overhauled. A case in point. Even with XAML/WPF I'm presently still stuck with the the standard file load/save/print dialogues - Microsoft (last I knew) never developed versions for the framework. The code is ancient and doesn't seem to grasp asynchronous operations very well. The result? I've seen some weird hangs just saving several image files to a USB drive. ...What on earth were you doing that used 20GB? Hell, I've run XAML on an old XP machine with VS 2010 and a HDD of less the 20GB in size. Never had the IDE crash. I had it give up on some malformed XAML, but never had to go as far what's happened to you.
Eddy Vluggen wrote:
No, it doesn't.
For me it does, which is what I meant.
Eddy Vluggen wrote:
Some people/companies/governments prefer recognizable, consistent UI's, and will not pay to have some hardware-accelerated animations and gradients. They'll pay to not have those.
Yep, those are the people who have stubbornly stuck to Internet Explorer 6, Windows XP, etc. If they are willing to pay for it, I'll give it to them. I don't need animations or gradie
-
Eddy Vluggen wrote:
So, you can't design a WinForm and see the results without compiling/testing/debugging? How is it mission-critical to see EACH instance of a textbox or button you create?
Because it's not just the textbox or button, but its appearance, location, etc. I'm a game UI designer and the aesthetics often matter as much as the function. If you want "plain vanilla" appearance and function then the usual cycle is shortened as there isn't much new - but you aren't being very creative.
Eddy Vluggen wrote:
It is not a feeling; compare it to WinForms and it is immature. The XAML-designer ate roughly 20Gb of my harddisk before crashing the IDE. You run into all kinds of crap that has already been solved before.
Agreed. That's the bad thing about Microsoft. They start off with some wonderful technologies that look promising and then just let them die. And of course typically never let them completely mature in the first place. WinForms has had a LOT of developer feedback. For the longest time it was the only game in town and it's what everyone got used to. XAML/WPF comes along and there has been resistance to learning a new paradigm (as if that's a surprise!) even when some things have really needed to be overhauled. A case in point. Even with XAML/WPF I'm presently still stuck with the the standard file load/save/print dialogues - Microsoft (last I knew) never developed versions for the framework. The code is ancient and doesn't seem to grasp asynchronous operations very well. The result? I've seen some weird hangs just saving several image files to a USB drive. ...What on earth were you doing that used 20GB? Hell, I've run XAML on an old XP machine with VS 2010 and a HDD of less the 20GB in size. Never had the IDE crash. I had it give up on some malformed XAML, but never had to go as far what's happened to you.
Eddy Vluggen wrote:
No, it doesn't.
For me it does, which is what I meant.
Eddy Vluggen wrote:
Some people/companies/governments prefer recognizable, consistent UI's, and will not pay to have some hardware-accelerated animations and gradients. They'll pay to not have those.
Yep, those are the people who have stubbornly stuck to Internet Explorer 6, Windows XP, etc. If they are willing to pay for it, I'll give it to them. I don't need animations or gradie
For textboxes and buttons in a WinForm, the location would be rather predictable; games are a class in its own; it will be judged mostly by its graphics, something which would not be my primary concern for, say, Visual Studio or a data-entry application :)
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
For textboxes and buttons in a WinForm, the location would be rather predictable; games are a class in its own; it will be judged mostly by its graphics, something which would not be my primary concern for, say, Visual Studio or a data-entry application :)
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
WPF has that nice "Device Independent Pixel" feature that WinForms lack, so location isn't as readily predictable as a developer would like (this was brought elsewhere in these forums: What is the big deal with WPF[^]) Not sure why you included VS in your short list, but a data entry application is somewhere we would agree. Check out that article link. Found it after my last posting in this thread.
-
WPF has that nice "Device Independent Pixel" feature that WinForms lack, so location isn't as readily predictable as a developer would like (this was brought elsewhere in these forums: What is the big deal with WPF[^]) Not sure why you included VS in your short list, but a data entry application is somewhere we would agree. Check out that article link. Found it after my last posting in this thread.
Basketcase Software wrote:
WPF has that nice "Device Independent Pixel" feature that WinForms lack
I never missed it, but it IS fun to read the history of scaling and how we try to negate different resolutions and dimensions.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
