4 ms·

Having spent quite a bit of my dev life with typed languages and now coding a LOT in pure JavaScript, I'm actually not at all thrilled by TypeScript. Yes, pure

by sytelus 13y ago

Having spent quite a bit of my dev life with typed languages and now coding a LOT in pure JavaScript, I'm actually not at all thrilled by TypeScript. Yes, pure JS is bit hard to maintain and it does occasionally pisses me off but at the same time it is liberating. Not having to constantly keep adding types all over, not having to constantly refactor things because I now accept object instead of an int etc is refreshing. And best of all, not having compile at all is fast and simple. I'm only using JS frameworks that doesn't force me do build before testing the page and retains purity of JavaScript (that means no simulations of traditional OOP). Yes, sometime I do make bad mistakes and spend some time chasing down bugs that would have been caught in typed languages. However overall I find cost of adding types all over and maintaining them over the evolution of code is actually higher. It would have been really great if they had produced cool algorithms that could have inferred types as much as possible and added it as static analysis tool instead of JS extension. Just because JS doesn't have type checking I'm now set in to mindset of doing quick tests of small changes, write more elaborate tests and so on. Even in moderately large project I think pure JavaScript is not only maintainable but also joy to work with compared to typed languages.

pjmlp 13y ago
> Even in moderately large project I think pure JavaScript is not only maintainable but also joy to work with compared to typed languages. You will see that joy quickly fade away in enterprise projects.
- anton-107 13y ago
  But isn't it because in the enterprise projects JavaScript code is written by Java/C# developers who think they know JavaScript, while they really don't? I've seen multiple examples of "enterpisey" web apps, and there was no joy, just because developers didn't know how to build a good application with JavaScript and even more - they didn't care at all. With a "don't touch anything that works" mindset that lots of enterprise developers have - you write write-only JavaScript code and when it becomes too large - of course, there is no joy in touching this kind of codebase. Every enterprise project with a in-browser front-end needs a good front-end developer from the start to set up good code, good practices and good attitude to a front-end part of the code, and it will be fine: the joy won't fade away.
  - pjmlp 13y ago
    > But isn't it because in the enterprise projects JavaScript code is written by Java/C# developers who think they know JavaScript, while they really don't? No, it is because: - Unit tests have zero value over new features - Project development tends to be outsourced to teams with high attrition rates - Most of the time cheaper developers are what matter - No one cares about quality, because there are no options to get the software from somewhere else > Every enterprise project with a in-browser front-end needs a good front-end developer from the start to set up good code, good practices and good attitude to a front-end part of the code, and it will be fine Oh, the dream enterprise, where can I get a job?
    - mattcole 13y ago
      If you're willing to live in sunny SE QLD, Australia, and good at C# as well as JS, get in touch.
      - pjmlp 13y ago
        Thanks for the invite, it is a bit far from Germany and Portugal. :)
pingec 13y ago
>Not having to constantly keep adding types all over You don't have to if you don't want to. >not having to constantly refactor things because I now accept object instead of an int etc is refreshing Again this is your choice, you can omit types if you want TS gives you the option to add typing if you want it. And that is huge in my book, try refactoring a large enterprise app written in JS vs. written in TS.
- nmjohn 13y ago
  Okay so if you don't use types, wouldn't you would just be writing vanilla javascript and would have no reason to use typescript in the first place though?
  - lmm 13y ago
    It has a somewhat nicer syntax for functions and better scoping rules, but you could certainly get that from a more lightweight js extension like coffeescript yeah.
    - klibertp 13y ago
      Not exactly, there is still type inference mechanism at work which, combined with DefinitelyTyped (https://github.com/borisyankov/DefinitelyTyped https://github.com/borisyankov/DefinitelyTyped) declarations will get you quite a lot type safety even if you won't write any type declaration by yourself.
klibertp 13y ago
I don't know very much about TypeScript, yet, but I'm doing some research and I'm going to advocate it on my next project. From what I already know: > Not having to constantly keep adding types all over, TypeScript is gradually typed (which means it's happy with as little or as much type declarations as you want to give to it) and uses type inference, which reduces amount of needless type declarations even more. Actually, coming from C and later C++ to Python and JavaScript I thought the same as you, that type systems are a complete PITA. I then learned OCaml and I changed my mind: bad, archaic type systems are PITA, but modern and powerful ones are a huge help and incur little cost. > and retains purity of JavaScript That's like saying that you're not using any Scheme library which implements convenient exception handling and you use bare call/cc instead. Prototypal inheritance in JavaScript is strictly more powerful than most of the class based systems, but it is less convenient to express some common idioms using just what's built-in. This is why you're going to implement some kind of object and meta-object protocols on top of prototypes sooner or later. It makes sense to agree on a standard way to do it, otherwise you're just going to add yet another slightly incompatible object system. I agree that there are many cases where prototypal inheritance is enough, though, and you shouldn't use classes by default in JavaScript. > adding types all over and maintaining them over the evolution of code is actually higher I have vastly different experience here. Types tend to make refactoring rather easier than harder. It's because when you change a return value or expected argument of some function you don't need to grep for all its calls in the codebase - the compiler will tell you. With sufficiently good type system, the compiler will tell you if the new type is compatible with the old one, which makes writing adapters easier. And it all happens on compile time, which means you don't need to run your app to test it. I read that TypeScript compilation is slow - that may be, but I bet it's comparable to running all the unit tests for a project, for example. > It would have been really great if they had produced cool algorithms that could have inferred types as much as possible and added it as static analysis tool instead of JS extension. Yeah, I agree, I'd like it too. I remember there being a very cool project from some distinguished JS developer which did just that; it was an editor and a supporting library for checking and validating JS code. I can't remember what it was, exactly, though... Help, anyone? > Just because JS doesn't have type checking As I said, it's not either-or situation. Gradual typing is one thing, contracts are the other. You can have the best of both worlds. After a few years I'm still amazed with Racket and Typed Racket combo - it's exactly the right mixture of compile-time and run-time support for ensuring program correctness and I would like to have something very similar in JS one day. In the meantime, TypeScript is a step in the right direction. I only hope it will continue to evolve after 1.0 release.
aquadrop 13y ago
TypeScript is the future of JavaScript, since all TS does is trying to introduce ES6 features right now.
CmonDev 13y ago
"cool algorithms that could have inferred types as much as possible" - like Hindley-Milner type system? Like OCAML/Haskell/F#? There is only one reason JS could be chosen. Because it's everywhere. Almost any other modern language is realistically better. But unfortunately Web is Closed to JS/HTML/CSS.

by sytelus 13y ago

pjmlp 13y ago

> Even in moderately large project I think pure JavaScript is not only maintainable but also joy to work with compared to typed languages. You will see that joy quickly fade away in enterprise projects.

anton-107 13y ago
But isn't it because in the enterprise projects JavaScript code is written by Java/C# developers who think they know JavaScript, while they really don't? I've seen multiple examples of "enterpisey" web apps, and there was no joy, just because developers didn't know how to build a good application with JavaScript and even more - they didn't care at all. With a "don't touch anything that works" mindset that lots of enterprise developers have - you write write-only JavaScript code and when it becomes too large - of course, there is no joy in touching this kind of codebase. Every enterprise project with a in-browser front-end needs a good front-end developer from the start to set up good code, good practices and good attitude to a front-end part of the code, and it will be fine: the joy won't fade away.
- pjmlp 13y ago
  > But isn't it because in the enterprise projects JavaScript code is written by Java/C# developers who think they know JavaScript, while they really don't? No, it is because: - Unit tests have zero value over new features - Project development tends to be outsourced to teams with high attrition rates - Most of the time cheaper developers are what matter - No one cares about quality, because there are no options to get the software from somewhere else > Every enterprise project with a in-browser front-end needs a good front-end developer from the start to set up good code, good practices and good attitude to a front-end part of the code, and it will be fine Oh, the dream enterprise, where can I get a job?
  - mattcole 13y ago
    If you're willing to live in sunny SE QLD, Australia, and good at C# as well as JS, get in touch.
    - pjmlp 13y ago
      Thanks for the invite, it is a bit far from Germany and Portugal. :)

pingec 13y ago

>Not having to constantly keep adding types all over You don't have to if you don't want to. >not having to constantly refactor things because I now accept object instead of an int etc is refreshing Again this is your choice, you can omit types if you want TS gives you the option to add typing if you want it. And that is huge in my book, try refactoring a large enterprise app written in JS vs. written in TS.

nmjohn 13y ago
Okay so if you don't use types, wouldn't you would just be writing vanilla javascript and would have no reason to use typescript in the first place though?
- lmm 13y ago
  It has a somewhat nicer syntax for functions and better scoping rules, but you could certainly get that from a more lightweight js extension like coffeescript yeah.
  - klibertp 13y ago
    Not exactly, there is still type inference mechanism at work which, combined with DefinitelyTyped (https://github.com/borisyankov/DefinitelyTyped https://github.com/borisyankov/DefinitelyTyped) declarations will get you quite a lot type safety even if you won't write any type declaration by yourself.

klibertp 13y ago

I don't know very much about TypeScript, yet, but I'm doing some research and I'm going to advocate it on my next project. From what I already know: > Not having to constantly keep adding types all over, TypeScript is gradually typed (which means it's happy with as little or as much type declarations as you want to give to it) and uses type inference, which reduces amount of needless type declarations even more. Actually, coming from C and later C++ to Python and JavaScript I thought the same as you, that type systems are a complete PITA. I then learned OCaml and I changed my mind: bad, archaic type systems are PITA, but modern and powerful ones are a huge help and incur little cost. > and retains purity of JavaScript That's like saying that you're not using any Scheme library which implements convenient exception handling and you use bare call/cc instead. Prototypal inheritance in JavaScript is strictly more powerful than most of the class based systems, but it is less convenient to express some common idioms using just what's built-in. This is why you're going to implement some kind of object and meta-object protocols on top of prototypes sooner or later. It makes sense to agree on a standard way to do it, otherwise you're just going to add yet another slightly incompatible object system. I agree that there are many cases where prototypal inheritance is enough, though, and you shouldn't use classes by default in JavaScript. > adding types all over and maintaining them over the evolution of code is actually higher I have vastly different experience here. Types tend to make refactoring rather easier than harder. It's because when you change a return value or expected argument of some function you don't need to grep for all its calls in the codebase - the compiler will tell you. With sufficiently good type system, the compiler will tell you if the new type is compatible with the old one, which makes writing adapters easier. And it all happens on compile time, which means you don't need to run your app to test it. I read that TypeScript compilation is slow - that may be, but I bet it's comparable to running all the unit tests for a project, for example. > It would have been really great if they had produced cool algorithms that could have inferred types as much as possible and added it as static analysis tool instead of JS extension. Yeah, I agree, I'd like it too. I remember there being a very cool project from some distinguished JS developer which did just that; it was an editor and a supporting library for checking and validating JS code. I can't remember what it was, exactly, though... Help, anyone? > Just because JS doesn't have type checking As I said, it's not either-or situation. Gradual typing is one thing, contracts are the other. You can have the best of both worlds. After a few years I'm still amazed with Racket and Typed Racket combo - it's exactly the right mixture of compile-time and run-time support for ensuring program correctness and I would like to have something very similar in JS one day. In the meantime, TypeScript is a step in the right direction. I only hope it will continue to evolve after 1.0 release.

aquadrop 13y ago

TypeScript is the future of JavaScript, since all TS does is trying to introduce ES6 features right now.

CmonDev 13y ago

"cool algorithms that could have inferred types as much as possible" - like Hindley-Milner type system? Like OCAML/Haskell/F#? There is only one reason JS could be chosen. Because it's everywhere. Almost any other modern language is realistically better. But unfortunately Web is Closed to JS/HTML/CSS.