9 ms·

If you still haven't given TypeScript a go as a Javascripter, now is a great time to do so. Whether you end up adopting it or not, it's interesting to get the

If you still haven't given TypeScript a go as a Javascripter, now is a great time to do so. Whether you end up adopting it or not, it's interesting to get the types out of your mind and into the code. The first time you feel the speed/confidence of refactoring with accurate 'Find usages', you'll decide if the undeniable overhead of types is worth it.

g00gler 10y ago
I have to second Mr.timruffles. After using TS in a couple of projects I grew to miss it when I couldn't use it. If you don't like the C#-ness of Typescript, try using Facebook's flow. Typing isn't a magic bullet, typescript isn't even type safe, but it sure makes development easier and your apps more stable.
- eklavya 10y ago
  "Typing isn't a magic bullet, ..., but it sure makes development easier and your apps more stable." That right there is the whole essence of typed programming :)
  - stcredzero 10y ago
    Going one level deeper, the underlying truism is that computers make better bean counters than people, even programmers. Type systems are good insofar as they free up cognitive resources of the programmer. Conversely, type systems are bad when they make programmers burn attention resources without enough return. (This is a difficult thing for people to evaluate, because sometimes the "return" from a type system can pay off many years later.) Again, it all comes down to cost-benefit. A new, modern 21st century language should be designed with the above in mind. The type system should make the resulting apps more stable, stay out of the way of coders reading code and writing new code, yet enable powerful tooling that doesn't need a heavyweight background process running a O(n^4) algorithm to collate meta-level information to enable all the IDE features. (Ideally, the tooling should be able to parse everything it needs to parse at some small multiple of the time it takes to read the source files off the drive.) Again, it's all about cost-benefit! "Elegance" or popularity with tech hipsters be damned, what's the cost, and what does it get you? (The nickel-and-dime costs of waiting around for lugubrious and unresponsive tools not only add up, they operate with some huge multiplier effect.)
    - sjwright 10y ago
      In my opinion, the critical aspect of typed code is the ability to declare a variable as either a number, string or binary. Let me declare this up front, let the compiler enforce it, and my mind is freed from semi-paranoid concerns about edge cases and spurious inputs. But sometimes I don't care exactly what sort of number is used. This is where many type systems go overboard, by forcing me pick a 64 bit unsigned integer or whatever.
- RyanCavanaugh 10y ago
  Where do you perceive the C#-ness of TS coming from? TS and Flow are ~90% identical (most programs accepted by one would be accepted by the other) and TS adds only a few purely optional syntactic features (namespace, enum) that are widely found in other languages.
  - gokhan 10y ago
    Might be referring to <T> or var smt = new Smt(); or the use of ? etc.
    - thejameskyle 10y ago
      Those all exist in Flow as well. I assume the original poster is talking about how few types you actually need to write in Flow because of how good the inference is.
      - boubiyeah 10y ago
        Nowadays, typescript inference is not any worse than Flow's though.
  - g00gler 10y ago
    * Disclaimer: Correct me if I'm wrong, I haven't used flow extensively but I did check the docs. One big thing is TypeScript classes are entirely different than standard JS classes. I guess you don't have to use them but it adds Abstract classes, interfaces and access control (eg private, protected vars).
- boubiyeah 10y ago
  The thing is, you don't have to use the C#-ness of typescript. typescript started like that and I disliked it at first, but it's now very good at typing an entire codebase using mostly a functional programming style. flow is unfortunately way behind in terms of robustness and IDE support.
ggregoire 10y ago
> The first time you feel the speed/confidence of refactoring with accurate 'Find usages', you'll decide if the undeniable overhead of types is worth it. For your information: in VSCode, the "Find all references" and "Rename symbol" work out-of-the-box, even if your code isn't typed. Edit and disclaimer: Not sure why I'm getting downvoted, my comment doesn't contradict parent message. I personally type my code too (with Flow), it's an amazing tool for static code analysis and avoid errors at the runtime. I would suggest everyone give it a try (with TypeScript, Flow or whatever).
- stcredzero 10y ago
  VSCode, the "Find all references" and "Rename symbol" work out-of-the-box, even if your code isn't typed. With good coding practice, references, "senders" and "implementers," and renaming worked well in Smalltalk. Where I missed types was during refactoring, and that also worked well about 99% of the time without types. It was that one last thing that we couldn't be 100% sure of that blocked the big refactoring we all wanted to do badly -- that's when I missed types!
- johnfn 10y ago
  > For your information: in VSCode, the "Find all references" and "Rename symbol" work out-of-the-box, even if your code isn't typed. I didn't downvote, but this seems incorrect to me. I'm sure that it works in small code bases, but once your code gets large enough (and dynamic enough) it's going to have to start missing things.
  - ggregoire 10y ago
    Why would their algorithm stop to work if your code gets large? It's not some kind of magic. :) My current project has 10,000 LOC and 130 files. If I use "Rename symbol" on something imported in different files of my project, the editor will open all the files, edit all the names and just wait for me to save the changes.
    - 13years 10y ago
      Doesn't work at all for me. My project has about 500k+ LOC. I suspect though it isn't the size of project, but certain patterns of design that work or don't work in non typed JS. However Brackets does better at finding method definitions. Even in my mess of a project with non typed JS, Brackets can always find the method definition or at least give me possible choices.
lcfcjs 10y ago
I've tried it and it's awful. If you don't like the language, go code in Ruby. If your company makes you code in Javascript, you are in the wrong job, let someone who knows and loves JS do it.
ryanSrich 10y ago
Can anyone weigh in on TypeScript vs Elm?
- ggregoire 10y ago
  TypeScript has an easier learning curve (for people with a JS background) and it's really popular. Elm is sometimes on the frontpage of HN but let's be honest, it's not really used.
- johnfn 10y ago
  Elm is really cool language that's pushing a lot of boundaries. Use it for learning or for small projects. TypeScript is a highly practical and pragmatic language. Use it for anything serious.
  - riffraff 10y ago
    what boundaries do you think Elm is pushing as a language? It is a cool language and platform, but to me it looks like with time it has actually become more conservative. TS on the other hand appears to contain some interesting new things on each release (possibly too many). Case in point, Lookup and Mapped types in 2.1 seem like a brilliant idea.
- daxfohl 10y ago
  I've used both. They're different monsters. Elm is a functional-first language and a reactive GUI framework all in one. Typescript is just a superset of JS. Elm is pretty neat if you want to build a reactive GUI framework with everything immutable by default and have lots of functional programming idioms at your disposal. However that's all it does: if you want to do e.g. server-side rendering or use it in an angular project you're out of luck; if you want to interop with other JS code then it's a pain. Typescript doesn't enforce any paradigm or bring any particular framework with it. It's just Javascript with type annotations and some extra features. So you can use it with React and Redux to create something like Elm's framework, but it won't be quite as safe or concise as you'd get with Elm. However it fits in much nicer with other JS libraries and can run on the server or alongside any JS GUI framework of your choice. Elm is also still officially beta, and new releases often involve fairly large breaking changes. Personally I started off a big fan of Elm but fell off the bandwagon as I ran into its limitations.
zeusly 10y ago
I'm not the best Javascripter, is there a TypeScript resource to learn it from scratch without diving deep into js first?
zalq 10y ago
I have yet to give this a shot, but perhaps now indeed is a great time to do so. Thanks for the encouragement and recommendation!

g00gler 10y ago

I have to second Mr.timruffles. After using TS in a couple of projects I grew to miss it when I couldn't use it. If you don't like the C#-ness of Typescript, try using Facebook's flow. Typing isn't a magic bullet, typescript isn't even type safe, but it sure makes development easier and your apps more stable.

eklavya 10y ago
"Typing isn't a magic bullet, ..., but it sure makes development easier and your apps more stable." That right there is the whole essence of typed programming :)
- stcredzero 10y ago
  Going one level deeper, the underlying truism is that computers make better bean counters than people, even programmers. Type systems are good insofar as they free up cognitive resources of the programmer. Conversely, type systems are bad when they make programmers burn attention resources without enough return. (This is a difficult thing for people to evaluate, because sometimes the "return" from a type system can pay off many years later.) Again, it all comes down to cost-benefit. A new, modern 21st century language should be designed with the above in mind. The type system should make the resulting apps more stable, stay out of the way of coders reading code and writing new code, yet enable powerful tooling that doesn't need a heavyweight background process running a O(n^4) algorithm to collate meta-level information to enable all the IDE features. (Ideally, the tooling should be able to parse everything it needs to parse at some small multiple of the time it takes to read the source files off the drive.) Again, it's all about cost-benefit! "Elegance" or popularity with tech hipsters be damned, what's the cost, and what does it get you? (The nickel-and-dime costs of waiting around for lugubrious and unresponsive tools not only add up, they operate with some huge multiplier effect.)
  - sjwright 10y ago
    In my opinion, the critical aspect of typed code is the ability to declare a variable as either a number, string or binary. Let me declare this up front, let the compiler enforce it, and my mind is freed from semi-paranoid concerns about edge cases and spurious inputs. But sometimes I don't care exactly what sort of number is used. This is where many type systems go overboard, by forcing me pick a 64 bit unsigned integer or whatever.
RyanCavanaugh 10y ago
Where do you perceive the C#-ness of TS coming from? TS and Flow are ~90% identical (most programs accepted by one would be accepted by the other) and TS adds only a few purely optional syntactic features (namespace, enum) that are widely found in other languages.
- gokhan 10y ago
  Might be referring to <T> or var smt = new Smt(); or the use of ? etc.
  - thejameskyle 10y ago
    Those all exist in Flow as well. I assume the original poster is talking about how few types you actually need to write in Flow because of how good the inference is.
    - boubiyeah 10y ago
      Nowadays, typescript inference is not any worse than Flow's though.
- g00gler 10y ago
  * Disclaimer: Correct me if I'm wrong, I haven't used flow extensively but I did check the docs. One big thing is TypeScript classes are entirely different than standard JS classes. I guess you don't have to use them but it adds Abstract classes, interfaces and access control (eg private, protected vars).
boubiyeah 10y ago
The thing is, you don't have to use the C#-ness of typescript. typescript started like that and I disliked it at first, but it's now very good at typing an entire codebase using mostly a functional programming style. flow is unfortunately way behind in terms of robustness and IDE support.

ggregoire 10y ago

> The first time you feel the speed/confidence of refactoring with accurate 'Find usages', you'll decide if the undeniable overhead of types is worth it. For your information: in VSCode, the "Find all references" and "Rename symbol" work out-of-the-box, even if your code isn't typed. Edit and disclaimer: Not sure why I'm getting downvoted, my comment doesn't contradict parent message. I personally type my code too (with Flow), it's an amazing tool for static code analysis and avoid errors at the runtime. I would suggest everyone give it a try (with TypeScript, Flow or whatever).

stcredzero 10y ago
VSCode, the "Find all references" and "Rename symbol" work out-of-the-box, even if your code isn't typed. With good coding practice, references, "senders" and "implementers," and renaming worked well in Smalltalk. Where I missed types was during refactoring, and that also worked well about 99% of the time without types. It was that one last thing that we couldn't be 100% sure of that blocked the big refactoring we all wanted to do badly -- that's when I missed types!
johnfn 10y ago
> For your information: in VSCode, the "Find all references" and "Rename symbol" work out-of-the-box, even if your code isn't typed. I didn't downvote, but this seems incorrect to me. I'm sure that it works in small code bases, but once your code gets large enough (and dynamic enough) it's going to have to start missing things.
- ggregoire 10y ago
  Why would their algorithm stop to work if your code gets large? It's not some kind of magic. :) My current project has 10,000 LOC and 130 files. If I use "Rename symbol" on something imported in different files of my project, the editor will open all the files, edit all the names and just wait for me to save the changes.
  - 13years 10y ago
    Doesn't work at all for me. My project has about 500k+ LOC. I suspect though it isn't the size of project, but certain patterns of design that work or don't work in non typed JS. However Brackets does better at finding method definitions. Even in my mess of a project with non typed JS, Brackets can always find the method definition or at least give me possible choices.

lcfcjs 10y ago

I've tried it and it's awful. If you don't like the language, go code in Ruby. If your company makes you code in Javascript, you are in the wrong job, let someone who knows and loves JS do it.

ryanSrich 10y ago

Can anyone weigh in on TypeScript vs Elm?

ggregoire 10y ago
TypeScript has an easier learning curve (for people with a JS background) and it's really popular. Elm is sometimes on the frontpage of HN but let's be honest, it's not really used.
johnfn 10y ago
Elm is really cool language that's pushing a lot of boundaries. Use it for learning or for small projects. TypeScript is a highly practical and pragmatic language. Use it for anything serious.
- riffraff 10y ago
  what boundaries do you think Elm is pushing as a language? It is a cool language and platform, but to me it looks like with time it has actually become more conservative. TS on the other hand appears to contain some interesting new things on each release (possibly too many). Case in point, Lookup and Mapped types in 2.1 seem like a brilliant idea.
daxfohl 10y ago
I've used both. They're different monsters. Elm is a functional-first language and a reactive GUI framework all in one. Typescript is just a superset of JS. Elm is pretty neat if you want to build a reactive GUI framework with everything immutable by default and have lots of functional programming idioms at your disposal. However that's all it does: if you want to do e.g. server-side rendering or use it in an angular project you're out of luck; if you want to interop with other JS code then it's a pain. Typescript doesn't enforce any paradigm or bring any particular framework with it. It's just Javascript with type annotations and some extra features. So you can use it with React and Redux to create something like Elm's framework, but it won't be quite as safe or concise as you'd get with Elm. However it fits in much nicer with other JS libraries and can run on the server or alongside any JS GUI framework of your choice. Elm is also still officially beta, and new releases often involve fairly large breaking changes. Personally I started off a big fan of Elm but fell off the bandwagon as I ran into its limitations.

zeusly 10y ago

I'm not the best Javascripter, is there a TypeScript resource to learn it from scratch without diving deep into js first?

zalq 10y ago

I have yet to give this a shot, but perhaps now indeed is a great time to do so. Thanks for the encouragement and recommendation!