Roadmap & Features

[Rycochet]

Stage 1

• Use original source and add/update build system
• Convert source over to Typescript.
• Automated tests: especially useful for Pull Requests (Jasmine?, Mocha?)
• API Documentation within code (TypeDoc? GitBook?)

Stage 2

• Fix / close all valid open issues
• Merge / add / close all open Pull Requests

Note

This is an open issue so people can discuss and put their own views in for getting things moving again - not for bug reports and feature requests which should be opened as separate issues - if you want to refer to an already open issue then feel free, but we do want to try to get them all closed / resolved as soon as possible anyway.

---

• Typescript is described as "Javascript with types" - the code is pretty much identical but has type annotations added, so var test = "abc"; test = 123; doesn't give a warning in Javascript, but would in Typescript as you're trying to change the type of it (nice at preventing errors) - you could also use var test: string; test = "abc"; test = 123; to get the same warning.

[ydaniv]

Who's idea is it to convert the source to Typescript?

[Rycochet]

@kenwheeler and I have been talking about it - without using any of the TS specific handling of classes etc, it'll just mean adding types to methods and variables to prevent easily preventable errors - the output would be byte identical if we don't do any obvious fixes while converting.

[ydaniv]

But then the source would NOT be in JavaScript. And that is bad. Very bad.
Please don't do that. It's a bad practice to write the source of a public open-source library in a an opinionated dialect of language.

[Joeao]

Yeah, shouldn't you fork it in the case of converting to Typescript?

[Rycochet]

It's not a major difference to the source - hence why there are so many open source libraries starting to use it - unlike CoffeeScript etc, it still looks almost identical to JS - having used it at work on some huge projects at catches a significant number of errors that JSLint/JSHint and plain eyeballing miss - suggestions on alternatives maybe?

What are the specific objections to TS btw? Simply the fact it's not JS, or problems with personal usage of it in the past?

Please remember that the split source requires a build system such as Grunt anyway - so there will always be a step between coding and having a library (even if it's an in-the-background grunt watch running).

[kenwheeler]

@ydaniv do you feel the same way about adding flowtype annotations? es2015? I tend to generally agree, that it will make contribution less inclusive. That said, there are convincing arguments for a conversion: http://staltz.com/all-js-libraries-should-be-authored-in-typescript.html

[kenwheeler]

Btw, I have a strong preference for Mocha over Jasmine. And gitbook for docs. I would love some community input on all these points.

[Joeao]

I would have thought it'd be a bad idea to break away from the founders intended language and style unless it's something as significant as es2015. I don't think we're the ones to call the shots unless forking. I'm not a scientist though, could be wrong.

[kenwheeler]

@Joeao Julian handed maintainership over to me under the understanding that I would modernize the library to keep up with the times. That said, I've done a shitty job thus far due to full time job business. But it's time to finally make these changes, and I'm super interested in the community's thoughts on roadmap.

[kenwheeler]

@Joeao At the end of the day, I just want to make it super easy for the community to shape the project moving forward. A transparent source & build system, contributable docs, solid tests...

[kenwheeler]

If the community says nay on typescript then so be it. Thats why we are posting this here, in order to gauge the needs and wants of the community.

[ydaniv]

@Rycochet the main problem is that when you enter a new dialect to the source you're blocking away more people. Potential contributors/testers/maintainers/etc. The crowd is more powerful than software, hence open source (:

@kenwheeler yes regarding flowtype, but big no regarding es2015. Any version of plain JS should be 100% acceptable. It's like Python libraries that I consume. I expect them to be written in plain Python 2 or 3, but anything other than that will make it less accessible.
Of course es2015/next/whatever is still much less known than ES5, but that's the price of writing future-proof software, and that is also very important.

I'm using Rivets which is written in CS and it sucks dog balls. I had to learn CS to contribute and debugging is hell. It's been like a year under work of migrating it to ES6 but maintainer dropped it at the last stretch, and other contributors are also having hard time at finishing this refactoring. I'd hate to see that story all over again.

• I think a gitbook would be great!
• Jasmine is fine, I think Mocha is even better, but I really love Intern.js.

[Rycochet]

@ydaniv I know what you mean - CoffeeScript etc definitely has that effect - however TypeScript doesn't change JavaScript unless you're doing more advanced things with classes / modules etc - things that aren't actually going to be relevant - so anyone that looks at this is either going to be capable of coding in it (because they know JS), or not (because they don't know JS) - annotations are the other way to go, but as they're not enforced by the language it would mean more bad pull requests that TS...

[kenwheeler]

@ydaniv Isn't es2015 plain JS moving forward though? All evergreen browsers and node support like 90% of the spec. The difference between CS and es2015 is that CS is a transpiled dialect and es2015 is literally the language spec moving foward. It technically is plain JS moving foward.

That said, I dont see any clear wins in a es2015 conversion. It won't make the lib function any better imo

[Joeao]

Ohhh okay! Then no, I have no complaints. My main focus is performance, so as long as that's a priority, I'm happy. I've heard great things about Typescript though I know little about it other than what @Rycochet mentioned. The inner worrier in me is that people may understand the library better in general if written in JS, one of the great things about open-source is that you can break and fix it yourself in order to learn. I'm sure you've looked at the positives and negatives with whatever it's written in.

@ydaniv explained some of the points I'm trying to get at much better. I also share the same issue with another project where I have to learn special things to make the smallest of changes.

[ydaniv]

@kenwheeler BTW, with all due respect to mr. Staltz, that's like his opinion (:
Now, seriously, it's too much of an opinion. For me, I scan his post and see "Angular 2", "Visual Studio", and it hurts my eyes, no offense.

[Rycochet]

@ydaniv I use NetBeans btw, Visual Studio is horrible imho :-P

[kenwheeler]

@ydaniv hahahah in total agreement there.

[ydaniv]

@kenwheeler yes, es2015 is exactly JS moving forward. When I said above yes/no I was answering your question:

do you feel the same way about adding flowtype annotations? es2015?

So please go forth and es2015'ify!

[Rycochet]

Relating to es2015 - should we keep compatibility with obsolete and dropped browsers? Ie - jQuery is dropped all the compatibility code with jQuery3, and I'm pretty sure that there's at least a little bit of that in here...

[Joeao]

Maybe a Gitter/Slack channel would be good for the project too?

[ydaniv]

@kenwheeler regarding wins from converting to es2015: it's not a must, but if possible, moving on with the world and having the source written in the most up-to-date version of the language is good practice. Personally, I still didn't find the time to convert anything I own/maintain to es2015.

@Rycochet I'd say drop all the oldies! Especially IE, which you can support now at 11. The problem now is old Androids, and question is whether to support below 4. Same for iOS below 7.1.

@Joeao agreed!

[marian-r]

I just came accross this conversation, so I'm curious, what is the outcome? ES2015 vs TypeScript? Mocha vs Jasmine?

Regarding the browser support I would suggest dropping <IE11 support, but I would keep Android 4+.

[Rycochet]

As it looks like I'm the only one coding right now, Typescript - might sound scary, but I use it exclusively at work (it's basically just an extension to Javascript, as mentioned earlier and elsewhere) - and having just been through things in a little more depth today - almost all of the "bug" type issues would have been obvious and easily picked up by using Typescript.

As far as testing goes, I'm not particularly bothered. We've got some tests already using qunit, but needs time to put together proper ones in anything - most of them will be identical for v1 and v2 (in fact that's part of the v2 change - undefined behaviour needs to be defined so there aren't workarounds in specific situations).

ES2015 is sort of given - it's dropping support for legacy browsers that need specific workarounds due to browser bugs (yes, looking at IE there). Support for older browsers that need shims will be via shims - if something comes up that's important enough to use it and it's not supported in enough browsers then it'll be shimmed (I love a lot of the new ES2016 prototypes, so tend to shim them in my own code - but they're just shortcut functions anyway). Please remember that typescript can output ES3 and ES5 just as easily, it's purely dependant on what it's actually running on whether it works or not.

Via work I have BrowserStack access, so once tests are being written I'll be able to test exactly what browsers are breaking and where (such as just discovering that scale doesn't animate on Edge and is wrong on IE).

[marian-r]

Sounds great! Regarding TypeScript, me personally, I'm OK with that. And as you mentioned before, it is a superset of JavaScript, so it should be easy for the community to pick-up.

[julianshapiro]

Love everything here, except for Typescript. Not worth the hassle. New maintainer taking over who will provide a revised roadmap alongside all of Rycochet's work.