New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open for comment: Should we move WinJS sources to TypeScript? #107
Conversation
The trick to get a reference to undefined is not needed in ES5-compatible browsers as undefined is non-writable.
Also, remove use of WinJS.Class in events.ts.
I would definitely support a move to TypeScript. |
I'm surprised WinJS wasn't already. Doesn't Xbox Music use this library, and is written in TS? |
@joewood The simplest explanation is that WinJS has existed longer than TS has. There are two sides to the TypeScript equation:
Clearly we are going to do the first one to make life better for TS developers today (yes, the music team does use TS and my understanding is that they use a .d.ts to get type information for WInJS). The question we want to put forth to the community about the second point is whether having the library be TS as opposed to JS would turn you off as either a application developer or contributor. |
It's a great question. I would imagine most people thinking of contributing would be in favor of TypeScript, given where WinJS comes from. Personally, I could never go back to regular JS. |
When WinJS was closed source I would've preferred it to be in TS; given that Microsoft is the champion of both and was tied to the platform. However, now that WinJS is open-source, a TS only implementation would limit the scope of people willing to contribute (sadly, not everyone uses it). Also TS tooling on other platforms isn't great. The only editor i've used painlessly with TS is Visual Studio which is Windows only. I am all in favour of of WinJS TS, but only if WinJS in JS continues to exist. TS would not put me off. In fact, it would make me happy =D. |
@ericjimenez For other platforms there is WebStorm and also a nice TS plugin for Sublime. Can you explain your comment "if WinJS in JS continues to exist"? |
@xirzec I'll check that out. Sure, I interpreted "Should we move WinJS to TypeScript?" as: "the JS version of WinJS will be phased out in favour of a TS only implementation". If WinJS goes the route of TS only, then the amount of potential contributors would probably diminish; given that JS is the more pervasive one. When I said: "if WinJS in JS continues to exist" what I really meant was, is it possible to keep two code bases JS and TS? One for those who only want to work with JS, and the other for those who want all the goodness that TS offers. Maybe I don't know what I am talking about; my exposure to TypeScript isn't that great. Did that make sense @xirzec? |
Maintaining parallel versions of all of our code would not be ideal, especially because I think we would want to lean into TypeScript for things like AMD modules. If we decided to go with TypeScript, then files we convert to TypeScript would only be editable as TS files, though they would compile down to JS in builds. Part of the motivation for this is that TypeScript is well aligned to ECMAScript 6, so things like classes, modules, arrow functions, and rest parameters will become standard JS in the future. The only part of TypeScript that is not likely to ever become standard JS would be the type annotations and interfaces. This is very different from something like CoffeeScript where there is a lot of divergent syntax to learn. I feel like the burden of adding types is not very large, especially if our code provides good examples. I'm also more than willing to educate contributors on the new syntax during Pull Request reviews. However, I am very sensitive to the possibility that we will be preventing folks from being able to contribute. Would having to write in TypeScript stop you from contributing? |
"Maintaining parallel versions of all of our code would not be ideal.." "This is very different from something like CoffeeScript where there is a lot of divergent syntax to learn." "I'm also more than willing to educate contributors on the new syntax during Pull Request reviews." "Would having to write in TypeScript stop you from contributing?" My previous commentary was me trying to take the perspective of a prospect contributor outside the Microsoft world. Thinking more deeply, developers who utilize WinJS are most likely already on the MS side of the fence. A move to TS would, I think, make their lives easier. Those not on this side of the fence would probably remain unaffected. At least until WinJS has better support for other browsers; that's still some way off. @xirzec Ultimately, I do support the move to TS. |
Having the source in TypeScript would require running a build step on any |
I am of the opinion that we should definitely move the code base to TypeScript. Besides the benefit of typing itself, wouldn't a move to TS also generally improve the issues of namespaces and classes, via the module and class system that TypeScript (and in the future, ES6) provides? @xirzec My consensus is Yes. |
@sompylasar yes - although to be fair we do already have a build step in place in order to concatenate files today, compile the LESS into CSS and to create test wrappers... @auralyte moving to TS would mean that we would stop using WinJS.Namespace.define and WinJS.Class.define/WinJS.Class.derive within the WinJS code (they would still be supported APIs for applications). The runtime form of classes and namespaces would not materially change however given that there is strong alignment between what the WinJS helpers produce and ES6/TypeScript. |
@sompylasar - we could also invest in some build tooling like grunt watch to make the recompilation happen automatically as you edit source files. |
I cannot image my JavaScript/CSS development without TS/LESS tools. So you have my vote for TS. I agree with @ericjimenez, that better support for other browsers is key to WinJS success. Plus uniform navigation pattern for both WebView x SPA Web applications. |
I for one prefer CoffeeScript any day over JS/TS. But I am able to adapt for contributions :) |
@pke - This one is probably for performance, since doing the lookup at runtime of a enum would just add overhead. To be fair, we actually do a very similar practice of using a raw number with a comment in our raw JS today in other places (like where we use a charCode or an enum value from WinRT). |
It would be great to have WinJs as a TypeScript library. I'd use it. |
TypeScript is a way for class-based developers to create prototype JavaScript code. Change WinJS to TypeScript means its not WinJS but WinTypeScript. If your going to do JavaScript, you should do JavaScript. JavaScript is not an output, It is a language. Please remember that there are a lot of developers that have chosen JavaScript because it is a non-class based language. The JavaScript community should not be forced to change to TypeScript to create JavaScript. After reading theses posts, I'm very hesitant to move forward with WinJS if its going to move away from JavaScript. I'm probably not alone in this. Most JavaScript developers probably saw this post and moved on. That is what I normally do. |
@HasIssues I'm not sure I understand your concerns since TS doesn't try to create true classical inheritance, it adds syntactic sugar that will be part of ES6: http://wiki.ecmascript.org/doku.php?id=strawman:maximally_minimal_classes Honestly, if ECMAScript eventually adds type hinting/annotations I'm not sure there will be much delta between TS and raw JS. The only advantage for TS at that point (or something like Traceur) is for servicing downlevel browsers. |
@xirzec I agree about ES6, but the discussions were about TypeScript. I will always support the ECMAScript standards but was opposed to using TypeScript as a temp solution until ES6. I think that some technology do damage to the developers learning. For example, when a developer uses jade (http://jade-lang.com/) to build html pages, he is not learning html and this limits his progress as a developer. I was concerned that if WinJS used TypeScript as its base, it would loose the ability to show developers how JavaScript can be used. When the developer is ready to learn the JavaScript, WinJS can be his example code for doing his own thing. That is what openSource is to me. Something to build on as I grow as a developer. I feel that products like WinJS, AngularJS, node.js, jQuery, and underscore enhance development without degrading the core knowledge of HTML, CSS, JavaScript. jQuery branched their support for legacy with the release of 2.0, maybe that could be the option for ES6 and WinJS. |
@HasIssues That's all well and good, but the trade off is that you get a less maintainable library as a result. Even AngularJS is moving to Tracuer soon so it can take advantage of newer constructs. There's many great libraries for developers to learn from in the community, and I don't believe that WinJS moving to Typescript will harm that effort in anyway. Also, as @xirzec said, there will hardly be any delta between Typescript and JavaScript. Arguably Typescript would be better to learn since it encourages best practices. |
I would very much like to see winjs in typescript. so that an accurate definition file can be created for typescript. |
Move? No. Make a TS version? Go ahead. |
I would not mind having WinJS be written in typescript, however please still force grunt to compile to javascript on build. |
Having WinJS in typescript would be great, though even more pressing is having the tooling to be able to use TS in Universal apps (looking at you, Shared project). |
Thank you everyone for your input! We have decided to gradually introduce more TypeScript into our tree. Right now you can see some TS happening in the tests and also in the fledgling "Toolbar" control. Please feel free to check out master and give us feedback. |
I've had a lot of success using TypeScript on previous projects. I find that it saves you a lot of runtime debugging by catching silly errors early. It also makes refactoring much easier since you can do things in the IDE like "Find All References" and "Rename Symbol". As such, I wanted to see how difficult it would be to convert WinJS to using TypeScript so we can have a discussion about it.
This branch contains the start (though nowhere near the end) of moving to TypeScript. I made all of the files that contribute to base.js compile as TS files and I moved the files in the base directory to use TypeScripts modules and classes instead of WinJS.Namespace.define and WinJS.Class.define.
There is still a lot more work to do if we want to commit to TypeScript, such as putting type info into our all of functions and creating custom event types for the modules and classes that implement an event pattern. However, in the interest of transparency I didn't want to go too far down this road before opening the floor for discussion from the community.
Feel free to check out this branch and look around at the source. If you are just curious about what the generated JS will look like, I made some gists for convenience:
The diff algorithm gist uses isn't the best in some cases, so I recommend using an offline diff tool of your choice if you really want to scrutinize them closely. There are a few cases where comments and whitespace get lost. This is a known point in time issue of the TS compiler and will be addressed in later versions. It appears that the external doc-comments are all preserved.
TL;DR Should we move WinJS to TypeScript? :)