Hls.js: Support typescript modules

[senaev]

In hls.js there is a lot of very complicated internal interfaces.
Also there are a lot of issues about null-reference errors.
If hls.js was support typescript modules, it would be helpful for supporting existing cod and making new features.

I you don't mind, i can add typescript support in project and rewrite some module with typescript (for example).

[johnBartos]

@senaev I think TS definitions are a good idea but don't support actual TS in the codebase at the moment. TS would require lots of changes and we don't have the testing infrastructure in place to confidently refactor the codebase. Adding a few TS modules doesn't really help either and would force us to complicate our build process. A good first step would be to do JSDoc with TS annotations. https://github.com/Microsoft/TypeScript/wiki/JsDoc-support-in-JavaScript

[mangui]

TS already there
https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/hls.js
https://github.com/video-dev/hls.js/issues/905

[tchakabam]

I have currently and recently had quite some experience with mixed JS & TypeScript codebases, and a lot of experience in the past year with Typescript in general :)

I would love to get more motion into this discussion. Generally I think I became a bit of a TS enthusiast as I have been enjoying its power the last 12 months or so on later projects. I think type-safety is really the missing thing to manage complex components/frameworks in ES/JS based platform code.

@johnBartos While I am not saying you're wrong, as a matter of my experiences, I cant not confirm any of your points really. Maybe we haven't had the same experiences with it. What experiences concretely did you make with mixed TS and JS codebase?

I think that for a complex codebase, type-safety is a great improvement, and will allow us to get a better hand of the internal data-models and interfaces. I strongly agree here with @senaev and could argue further and more into the direction to point out how it will make us actually awesome. I don't see any problem with the build tooling, it's fully integratable in transparent ways via webpack in fact by now.

Cheers

[tchakabam]

Also, if you favor more "smooth" introduction of a type-system, then Flow can be an option to consider.

However, TypeScript allows easily as well to compile JS code and TS code transparently with each others (thus you can actually get completely rid of Babel as TS will understand standard ES6+ code in JS files and compile that down to ES3 or ES5 - at your choice).

Therefore, even for smooth transition i rather recommend to move JS modules one by one to TS modules.

With Flow we often end up with completely mixed up half-typed JS stuff. And TS is a proper language of it's own and I think it will gain a lot of traction, and already does, in order to produce the next high quality components for web platform. Like Angular is in TypeScript btw :)

The TS compiler can be set up to have a bit more loose type rules, and then the strictness can be increased. I suggest more this approach than using Flow/Babel.

[tchakabam]

@senaev ^

[senaev]

Thank you for answer, @tchakabam, I fully agree

[NicolasSiver]

Maybe I would look old-school. But JavaScript is not about types. The idea of types completely eliminates JavaScript super-powers. I just recommend learning the tools and habits how to harness JavaScript.

I think that JavaScript is doing a good progress (ES6, ES7, etc.). Staying close to "native" tech you would have future-proof product. With care, you can grow humongous JavaScript code bases, which are robust and impressive without a necessity to use any "types". With latest ECMAScript additions it's even easier.

I don't exclude a possibility that JavaScript 2.0 will have an idea of syntax for types. But my main point is to embrace "good parts" of the tools and languages you are using.

[senaev]

@NicolasSiver, i agree, using native code and features is a good way to write code. But as we see, there are lots of problems too.

1) If you wanna write docs and descriptions for functions, you should use jsdoc, which implements additional syntax
2) You can not avoid problems with null-references as good as it is provided by typed languages
3) You can not describe public interfaces in a separate part of your code

Typescript also provide great infrastructure, as typedoc, tslint and other tools that fully satisfy current hls.js project requirements.

[tchakabam]

@NicolasSiver In Typescript if you want you can use the any type which brings you back the whole fully dynamic-typing "super-power" which you probably meant. Also, Typescript allows you to cast any typed variable to any at any moment. Same accounts for global variables would you need them. We don't loose any of the "good" parts of JS technically. However, using any is definitely not the idea with TS, and it can be disabled (or made an exception to the rule) via compiler/linter settings. Probably you should first learn a bit more about the language before giving a final opinion :) 👍

About staying close to "native": Whatever native means to you, we aren't really interested at doing that if we use Babel, right? Chrome and Firefox barely implement parts of ES6 now, but other browsers don't. Also, the module-type script tag will make the browser know about import but that will have load tons of files everytime you load the lib. No-one would want to distro a library as a bunch of files like this. That means in the end we will always want to build a closed bundle with something like webpack. And if we do that, why not also take advantage of the tools and choose a language that can be compiled to something that will actually run consistently in every browser nowadays? (While also allowing us to write better code.)

Typescript simply allows you to build contracts between components which you can't with plain JS. It doesn't take any feature away though. It is an optional super-set that allows you to add information to the code you write in order to build more robust things, which btw document themselves, and assert things at compile-time that one would have to test in runtime otherwise.

My experience with Typescript has been that it crucially improves code quality, development speed and naturally helps you design things in a more meaningful, less redundants way. For anyone getting into the codebase or even maintaing it as it grows and ages is much more convenient.

For example, take Promises. With TS, you actuall declare what your promise is supposed to resolve to. And the compiler checks that every call to resolve will actuall provide that data type (or a subclass of it). Therefore, anyone who consumes the promise can do that with confidence. Same goes for data passed inside events. Once you actually build your event-data as contractful class, listeners can be implemented with more ease and elegance. Finally internal API can be explored while writing the code, instead of while running the code. Once you force typing on all components, in fact you get a real overview of what members exist, what state you are actually holding. Not to mention whoever uses our lib will get inherently a complete documentation of data-types on every public method, without us having to write a single line of JSdoc.

Generally my experience with codebases in typed languages, is that developer will think more about what they do, simply because the languages allows them to describe things clearly.

Yes, you can do that in JS too, if you use JSdoc annotations everywhere, and actually write robust JS code, which will also necessit to have unit tests for every class and function, and a couple of runtime checks. But please take a look at our current codebase, I don't think we are having the resources to get it there. And why, if there are better tools available.

Typescript takes aways that burden of having to write unit tests just to check on internal contracts API, it is inherent type-documentation of every class und function, and it allows to build these things faster than traditional JS. I guess the truth about JS is also, it's not perfect. And so is Typescript, and it surely isn't necessary for everything we do in browsers, but in this case it is clearly very helpful and I don't see really what we are loosing with it at all.

[tchakabam]

@senaev Better than Tslint we can simply use the eslint plugin for ts :)

About null-refs, typescript doesn't solve that (please tell me about the language that does), but at least it will not allow accessing properties or calling methods that haven't been explictely defined :)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.