4 ms·
I have not used TypeScript personally, just read and try some demo of it. But for me JS -> TS feels like C -> C++ evolution/Transition. For most of Unix ut
by tkinom 11y ago
I have not used TypeScript personally, just read and try some demo of it.
But for me JS -> TS feels like C -> C++ evolution/Transition. For most of Unix utillies or even as complex as Linux Kernel, Apache, Nginx, C is good enough. In the hands of developers who master it, there are no C++ equivalent.
For after look at the v8's C++ code, I can't imagine anyone would write that with C.
But when a new language's ego system is not mature enough, the development work flow can be a nightmare. I remember trying to use GWT to compile Java into JS. The demo works and looks cool. But more often or not, I end up debug "The JAVA code" AND "The machine generated Javascript" AND "how that JS interact with different browsers" for something that is extremely trivial to do with one line of JS/JQuery code.
* Writing code is easy.
* Debugging code is harder.
* Make sure that code works on all the browsers are much harder.
* Debugging system with multiple languages (JS, TS, React, Angular, polymer, etc) + machine generated code is not easy.
* Integrated them all together to fixed all issues and make sure the final program will work on all browsers are > N^2, N^3, N^4 times harder?
I am old enough to admit, that is not a job for me. :-)
- klodolph 11y agoThat's not my experience with TypeScript. To me, TypeScript feels like JavaScript, with a few bits that make it feel more like writing ES6 even though you're really writing something closer to ES5. The differences between C and C++ are much larger. You're never debugging TypeScript separately from JavaScript.
- tkinom 11y agoI see the following code in https://github.com/Microsoft/TypeScriptSamples/blob/master/todomvc/js/todos.ts https://github.com/Microsoft/TypeScriptSamples/blob/master/t... , For me, it is definitively not the JS I know. declare var _: { each<T, U>(arr: T[], f: (elem: T) => U): U[]; delay(f: Function, wait: number, ...arguments: any[]): number; template(template: string): (model: any) => string; bindAll(object: any, ...methodNames: string[]): void; }; declare var Store: any; If there is bug in this code, I won't know how to debug it. I have no clue on what the JS generated by it looks like. If I have to ask some JS programmer with no TS experience to integrate this "ts library" into their app and make sure the integrated app works on all browsers. I would have no clue on the complexity of the task just as I have no clue on how complex it was to make the GWT generated JS app to work on all browsers. If it is just a JQuery / JS app, I can have 80-90% confident on schedule and quality of the app delivery. But that's me, like I said, I am too old... :-)
- noonat 11y agoJust wanted to point out that that isn't the JS you know because that's just typing information -- it isn't generating any code at all, it's telling TS what the types look like for Underscore's external methods. This would be stripped out completely in the compiled code. The actual code that results in JS just below that is much more typical.
- Matthias247 11y agoThis is only a typescript definition. It only shows you the types that were already there - even before typescript was introduced. And if the JS developer was not aware that these are the accepted types for the functions then he obviously wouldn't also be able to use or debug it in pure JS.
- dmethvin 11y agoRight, for the human there are still the English API docs to figure out the arguments and return values. These are the type annotations that TypeScript uses to let you know when you've misinterpreted the API docs, which is an incredible time saver.