19 ms·

Although I don't use TypeScript (I'm looking at Flow more and more recently instead) I have to acknowledge Microsoft's huge contribution to the JS scene (and no

by vmasto 9y ago

Although I don't use TypeScript (I'm looking at Flow more and more recently instead) I have to acknowledge Microsoft's huge contribution to the JS scene (and not only) with TS and VSCode, truly exceptional products. What's more interesting to me is that everyone who converts their code into Flow or TS immediately finds at least N bugs (albeit small). It's also quite amusing that this article came out today where HN's top article for a few hours was a bashing against Electron (and Slack specifically).

djtriptych 9y ago
And AJAX :) I'm also really hoping that the current crop of JS programmers learn event-driven / reactive style programming, and for that, RX is probably the best JS library out.
- zghst 9y ago
  I spent a lot of the earlier parts of my life hating MS, however later after working at a .NET shop and with the late developments at the company, my love for MS is becoming near-infinite. Reactive is definitely the way to go
  - mmgutz 9y ago
    It's strange but I went the other way. I started hating MS because of working in .NET. Basically, if something wasn't blessed by MS, it wasn't used. There were open source MVC projects but since MS only blessed ASP.NET forms back then, you couldn't convince managers to use MVC. Same with IoC. Same with ORMs I do like the new Microsoft. VS.Code is hands down the best all-around editor right now. TypeScript is awesome sauce.
    - bobwaycott 9y ago
      I started here, too. First production app was an early C# ASP.NET OSHA safety management and training platform for Mohawk carpets, built from the ground up back in 2007-08. Experienced all these headaches. Next major project was Python-based. Never went back to .NET.
      - NicoJuicy 9y ago
        Asp.net forms was a monster. Asp.net Mvc was not
        bobwaycott 9y ago
        The MVC variety was barely getting started when I was working at the time.
    - shouldbworking 9y ago
      VSCode and Typescript are stellar. In the case of Typescript, possibly industry-changing long term. However, the .NET stack still suffers greatly from what you mentioned. The Microsoft world is like the Oracle world, you either use their stuff for everything or never touch it. I'm confident that .NET core will change this when it's mature enough, but that's still ~2 years away.
      - KurtMueller 9y ago
        > In the case of Typescript, possibly industry-changing long term. I feel that way about a related Microsoft product, F#. It's too bad that it doesn't get the same amount of love as Typescript. I think it's more powerful yet just as easy to use in almost every way - I never knew how powerful or expressive algebraic data types could be until I used F#.
        NicoJuicy 9y ago
        Too bad nobody gives an example. Check out http://fsharp.github.io/FSharp.Data/ http://fsharp.github.io/FSharp.Data/ for an example why f# is 'powerful'
        mattferderer 9y ago
        Repeating myself a bit in this thread. If you love F#, try checking out Fable &/or Reason. Fable compiles F# to JavaScript and Reason is Facebook's attempt at OCaml to JavaScript. F# !== Ocaml but F# == Ocaml
    - daxfohl 9y ago
      I've gone, and continue to go, both ways simultaneously. They put a lot of effort into creating awesome experiences to bring developers on board. They also run a business that caters to clients who need "enterprisey" stuff backwards compatible with COBOL.NET or whatever and try to push that along with the good stuff. So it goes. I can't complain too much.
    - scalatohaskell 9y ago
      > There were open source MVC projects but since MS only blessed ASP.NET forms back then, you couldn't convince managers to use MVC. Same with IoC. Same with ORMs but that's not really Microsoft's fault
- deleted 9y ago
  [deleted]
- nathan_f77 9y ago
  Man, there's so many tools and styles to learn and evaluate. I'm still relatively new to React and React Native, and have enjoyed writing some apps with Redux. It took me a while to understand the need for redux-thunk, and now I'm about to get started with redux-saga [1]. I'm totally unfamiliar with RxJS, but some of the concepts sound familiar. Do I need to learn and use RxJS if I'm already using redux and redux-saga? I found this SO answer [2], and this post [3], which compares redux-observable and redux-saga. This guide [4] looks pretty good, too. [1] https://github.com/redux-saga/redux-saga https://github.com/redux-saga/redux-saga [2] http://stackoverflow.com/a/40027778/304706 http://stackoverflow.com/a/40027778/304706 [3] https://hackmd.io/s/H1xLHUQ8e https://hackmd.io/s/H1xLHUQ8e [4] https://gist.github.com/staltz/868e7e9bc2a7b8c1f754 https://gist.github.com/staltz/868e7e9bc2a7b8c1f754 EDIT: OK wow, as soon as you get to the "double click" stream diagram (in link [4]), it all starts to make sense. This is pretty amazing. EDIT 2: The example on http://reactivex.io/ http://reactivex.io/ is also good. I didn't realize it was available for so many languages: Java, .Net, JS, Swift. This sounds like something I need to learn. EDIT 3: This is the best programming guide I have ever read ([4]). It starts with a real problem, then goes on to show how you would solve it in RxJS in a rudimentary and familiar way. Then it expands on and successively simplifies that solution, to show how you would solve it in the idiomatic way. It's really the perfect way to learn these concepts. > A metastream for responses looks confusing, and doesn't seem to help us at all. We just want a simple stream of responses, where each emitted value is a JSON object, not a 'Promise' of a JSON object. Say hi to Mr. Flatmap: a version of map() that "flattens" a metastream, by emitting on the "trunk" stream everything that will be emitted on "branch" streams. Flatmap is not a "fix" and metastreams are not a bug, these are really the tools for dealing with asynchronous responses in Rx.
  - bpizzi 9y ago
    You might also like this: https://github.com/Day8/re-frame https://github.com/Day8/re-frame It's not js/es6 (re-frame is a react-based redux-like framework for clojurescript) but the author does a good job at explaining how reactive programming go well with functionnal programming and immutability.
    - Stoids 9y ago
smt88 9y ago
I like Flow better as a concept, but the tooling for TypeScript is absolutely amazing.
- simplify 9y ago
  I feel the same way. I'm eager to use Flow, but their tooling is just so far behind. Until it catches up I'm using TypeScript, which is much, much better than nothing :)
- WhitneyLand 9y ago
  Please tell what you like better. I was surprised when even the flow lead at FB said it doesn't really provide any advantage over TS.
  - muglug 9y ago
    For me, I like how it's designed to complement the language, not to replace it with a (very closely related) cousin. The conversion from JS-with-flow-types to plain JS is just a matter of stripping out that type information, which I feel is conceptually simpler than TypeScript's approach.
    - msoad 9y ago
      Flow is a different language than JS. Keeping the .js extension doesn't make it a "close to JS" language. TypeScript and Flow are both supersets of JS
      - smt88 9y ago
        > Flow is a different language than JS How so? Isn't JS-with-Flow just JS with specially formatted comments?
        abritinthebay 9y ago
        That's one option (my favorite and the simplest to use). But the "default" is annotated JS which is not dissimilar to how TS operates. I prefer Flow's syntax and if it wasn't for the annoying "you have to run a server to check code" thing... I'd use it a lot more
BinaryIdiot 9y ago
> What's more interesting to me is that everyone who converts their code into Flow or TS immediately finds at least N bugs (albeit small). When I was playing with TS I converted a project and found no additional bugs. Type related bugs shouldn't be that common IMO (if they are and they're systemic (not like a one off) I would argue that there is an issue with the way you're architecting). Maybe TypeScript just isn't for me. I see its value but didn't find it high enough to continue using. I'm working on creating a .d.ts file for one of my open source libraries but I don't know that I'll use it beyond that anytime soon.
- ng12 9y ago
  Yeah, I think the bug-finding value is overblown. I advocate Typescript entirely for developer experience. It lets me codify complex domain objects and will catch the obviously wrong bugs while I'm developing -- things like passing arguments in the wrong order or passing an x to a function instead of a y. Not to mention with Webstorm or VSCode you have actually reliable autocomplete too.
- chickenfries 9y ago
  To me, the value is at design/write time, not in converting old code. Old code that already works correctly will not be made more correct with TS unless you have branches of code that haven't been tested (by you during development, in tests or by your users). Working TS just lets me catch type mismatches while I'm writing instead of after the whole build process has run and I've reloaded the browser.
  - zip1234 9y ago
    Also don't forget refactoring. Try renaming a property with confidence in plain JS. In TS it is simple.
    - michaelmcmillan 9y ago
      No problem if you test your code, as you should.
Sophistifunk 9y ago
I like and have used them both, but for me there's two points that are massively in favour of TypeScript. The first, is that TS is written in TS, rather than OCaml. The second, is that Microsoft has a long history of developing and more importantly supporting dev tools, and is working on TypeScript for TypeScript's sake. Facebook is (and they're open about this) mainly concerned with Facebook's use-cases, and this drives their OSS products such as React(-native) and Flow.
- KurtMueller 9y ago
  > The first, is that TS is written in TS, rather than OCaml I think being written in OCaml would be a benefit, rather than a negative. One of the reasons I'm interested in ReasonML, which powers Facebook's Flow, is that is based off of Bloomberg's Bucklescript, which is based off of OCaml. I never knew the power of types (specifically algebraic data types) and the convenience of using them until I discovered them in F# (and Elm).
  - Sophistifunk 9y ago
    It's not that I'm against OCaml, I've tried to learn it a few times but the toolchain was a PITA. The benefits of self-hosting is that the more you use TypeScript, the more qualified you become to contribute, to troubleshoot, and to if-necessary help shoulder the burden of maintenance should Facebook/Microsoft decide it's no-longer profitable.
    - chenglou 9y ago
      I work on Reason, mentioned above. The goal of Reason is exactly to expose a polished layer over the OCaml toolchain: http://facebook.github.io/reason/ http://facebook.github.io/reason/ Give it a try! Ping us if you need to: https://github.com/facebook/reason#community https://github.com/facebook/reason#community
      - Sophistifunk 9y ago
        I was under the impression Reason was a library that let you write build files in OCaml? I'm not sure how this helps your average JavaScript programmer make sense of the source to flowtype. Edit: Never mind, you're referring to my complaint about the OCaml toolchain. Carry on :D
andrewchambers 9y ago
> What's more interesting to me is that everyone who converts their code into Flow or TS immediately finds at least N bugs (albeit small). Just rereading all your code carefully (which porting generally requires) generally finds a few bugs in my opinion. It might not always be because of typescript.
- wyaeld 9y ago
  It doesn't port anything. Valid JS is valid TS, its just that the TS compiler processes it and tends to surface issues that just running it under Nodejs doesn't

by vmasto 9y ago

djtriptych 9y ago

And AJAX :) I'm also really hoping that the current crop of JS programmers learn event-driven / reactive style programming, and for that, RX is probably the best JS library out.

zghst 9y ago
I spent a lot of the earlier parts of my life hating MS, however later after working at a .NET shop and with the late developments at the company, my love for MS is becoming near-infinite. Reactive is definitely the way to go
- mmgutz 9y ago
  It's strange but I went the other way. I started hating MS because of working in .NET. Basically, if something wasn't blessed by MS, it wasn't used. There were open source MVC projects but since MS only blessed ASP.NET forms back then, you couldn't convince managers to use MVC. Same with IoC. Same with ORMs I do like the new Microsoft. VS.Code is hands down the best all-around editor right now. TypeScript is awesome sauce.
  - bobwaycott 9y ago
    I started here, too. First production app was an early C# ASP.NET OSHA safety management and training platform for Mohawk carpets, built from the ground up back in 2007-08. Experienced all these headaches. Next major project was Python-based. Never went back to .NET.
    - NicoJuicy 9y ago
      Asp.net forms was a monster. Asp.net Mvc was not
      - bobwaycott 9y ago
        The MVC variety was barely getting started when I was working at the time.
  - shouldbworking 9y ago
    VSCode and Typescript are stellar. In the case of Typescript, possibly industry-changing long term. However, the .NET stack still suffers greatly from what you mentioned. The Microsoft world is like the Oracle world, you either use their stuff for everything or never touch it. I'm confident that .NET core will change this when it's mature enough, but that's still ~2 years away.
    - KurtMueller 9y ago
      > In the case of Typescript, possibly industry-changing long term. I feel that way about a related Microsoft product, F#. It's too bad that it doesn't get the same amount of love as Typescript. I think it's more powerful yet just as easy to use in almost every way - I never knew how powerful or expressive algebraic data types could be until I used F#.
      - NicoJuicy 9y ago
        Too bad nobody gives an example. Check out http://fsharp.github.io/FSharp.Data/ http://fsharp.github.io/FSharp.Data/ for an example why f# is 'powerful'
      - mattferderer 9y ago
        Repeating myself a bit in this thread. If you love F#, try checking out Fable &/or Reason. Fable compiles F# to JavaScript and Reason is Facebook's attempt at OCaml to JavaScript. F# !== Ocaml but F# == Ocaml
  - daxfohl 9y ago
    I've gone, and continue to go, both ways simultaneously. They put a lot of effort into creating awesome experiences to bring developers on board. They also run a business that caters to clients who need "enterprisey" stuff backwards compatible with COBOL.NET or whatever and try to push that along with the good stuff. So it goes. I can't complain too much.
  - scalatohaskell 9y ago
    > There were open source MVC projects but since MS only blessed ASP.NET forms back then, you couldn't convince managers to use MVC. Same with IoC. Same with ORMs but that's not really Microsoft's fault
deleted 9y ago
[deleted]
nathan_f77 9y ago
Man, there's so many tools and styles to learn and evaluate. I'm still relatively new to React and React Native, and have enjoyed writing some apps with Redux. It took me a while to understand the need for redux-thunk, and now I'm about to get started with redux-saga [1]. I'm totally unfamiliar with RxJS, but some of the concepts sound familiar. Do I need to learn and use RxJS if I'm already using redux and redux-saga? I found this SO answer [2], and this post [3], which compares redux-observable and redux-saga. This guide [4] looks pretty good, too. [1] https://github.com/redux-saga/redux-saga https://github.com/redux-saga/redux-saga [2] http://stackoverflow.com/a/40027778/304706 http://stackoverflow.com/a/40027778/304706 [3] https://hackmd.io/s/H1xLHUQ8e https://hackmd.io/s/H1xLHUQ8e [4] https://gist.github.com/staltz/868e7e9bc2a7b8c1f754 https://gist.github.com/staltz/868e7e9bc2a7b8c1f754 EDIT: OK wow, as soon as you get to the "double click" stream diagram (in link [4]), it all starts to make sense. This is pretty amazing. EDIT 2: The example on http://reactivex.io/ http://reactivex.io/ is also good. I didn't realize it was available for so many languages: Java, .Net, JS, Swift. This sounds like something I need to learn. EDIT 3: This is the best programming guide I have ever read ([4]). It starts with a real problem, then goes on to show how you would solve it in RxJS in a rudimentary and familiar way. Then it expands on and successively simplifies that solution, to show how you would solve it in the idiomatic way. It's really the perfect way to learn these concepts. > A metastream for responses looks confusing, and doesn't seem to help us at all. We just want a simple stream of responses, where each emitted value is a JSON object, not a 'Promise' of a JSON object. Say hi to Mr. Flatmap: a version of map() that "flattens" a metastream, by emitting on the "trunk" stream everything that will be emitted on "branch" streams. Flatmap is not a "fix" and metastreams are not a bug, these are really the tools for dealing with asynchronous responses in Rx.
- bpizzi 9y ago
  You might also like this: https://github.com/Day8/re-frame https://github.com/Day8/re-frame It's not js/es6 (re-frame is a react-based redux-like framework for clojurescript) but the author does a good job at explaining how reactive programming go well with functionnal programming and immutability.
  - Stoids 9y ago

smt88 9y ago

I like Flow better as a concept, but the tooling for TypeScript is absolutely amazing.

simplify 9y ago
I feel the same way. I'm eager to use Flow, but their tooling is just so far behind. Until it catches up I'm using TypeScript, which is much, much better than nothing :)
WhitneyLand 9y ago
Please tell what you like better. I was surprised when even the flow lead at FB said it doesn't really provide any advantage over TS.
- muglug 9y ago
  For me, I like how it's designed to complement the language, not to replace it with a (very closely related) cousin. The conversion from JS-with-flow-types to plain JS is just a matter of stripping out that type information, which I feel is conceptually simpler than TypeScript's approach.
  - msoad 9y ago
    Flow is a different language than JS. Keeping the .js extension doesn't make it a "close to JS" language. TypeScript and Flow are both supersets of JS
    - smt88 9y ago
      > Flow is a different language than JS How so? Isn't JS-with-Flow just JS with specially formatted comments?
      - abritinthebay 9y ago
        That's one option (my favorite and the simplest to use). But the "default" is annotated JS which is not dissimilar to how TS operates. I prefer Flow's syntax and if it wasn't for the annoying "you have to run a server to check code" thing... I'd use it a lot more

BinaryIdiot 9y ago

> What's more interesting to me is that everyone who converts their code into Flow or TS immediately finds at least N bugs (albeit small). When I was playing with TS I converted a project and found no additional bugs. Type related bugs shouldn't be that common IMO (if they are and they're systemic (not like a one off) I would argue that there is an issue with the way you're architecting). Maybe TypeScript just isn't for me. I see its value but didn't find it high enough to continue using. I'm working on creating a .d.ts file for one of my open source libraries but I don't know that I'll use it beyond that anytime soon.

ng12 9y ago
Yeah, I think the bug-finding value is overblown. I advocate Typescript entirely for developer experience. It lets me codify complex domain objects and will catch the obviously wrong bugs while I'm developing -- things like passing arguments in the wrong order or passing an x to a function instead of a y. Not to mention with Webstorm or VSCode you have actually reliable autocomplete too.
chickenfries 9y ago
To me, the value is at design/write time, not in converting old code. Old code that already works correctly will not be made more correct with TS unless you have branches of code that haven't been tested (by you during development, in tests or by your users). Working TS just lets me catch type mismatches while I'm writing instead of after the whole build process has run and I've reloaded the browser.
- zip1234 9y ago
  Also don't forget refactoring. Try renaming a property with confidence in plain JS. In TS it is simple.
  - michaelmcmillan 9y ago
    No problem if you test your code, as you should.

Sophistifunk 9y ago

I like and have used them both, but for me there's two points that are massively in favour of TypeScript. The first, is that TS is written in TS, rather than OCaml. The second, is that Microsoft has a long history of developing and more importantly supporting dev tools, and is working on TypeScript for TypeScript's sake. Facebook is (and they're open about this) mainly concerned with Facebook's use-cases, and this drives their OSS products such as React(-native) and Flow.

KurtMueller 9y ago
> The first, is that TS is written in TS, rather than OCaml I think being written in OCaml would be a benefit, rather than a negative. One of the reasons I'm interested in ReasonML, which powers Facebook's Flow, is that is based off of Bloomberg's Bucklescript, which is based off of OCaml. I never knew the power of types (specifically algebraic data types) and the convenience of using them until I discovered them in F# (and Elm).
- Sophistifunk 9y ago
  It's not that I'm against OCaml, I've tried to learn it a few times but the toolchain was a PITA. The benefits of self-hosting is that the more you use TypeScript, the more qualified you become to contribute, to troubleshoot, and to if-necessary help shoulder the burden of maintenance should Facebook/Microsoft decide it's no-longer profitable.
  - chenglou 9y ago
    I work on Reason, mentioned above. The goal of Reason is exactly to expose a polished layer over the OCaml toolchain: http://facebook.github.io/reason/ http://facebook.github.io/reason/ Give it a try! Ping us if you need to: https://github.com/facebook/reason#community https://github.com/facebook/reason#community
    - Sophistifunk 9y ago
      I was under the impression Reason was a library that let you write build files in OCaml? I'm not sure how this helps your average JavaScript programmer make sense of the source to flowtype. Edit: Never mind, you're referring to my complaint about the OCaml toolchain. Carry on :D

andrewchambers 9y ago

> What's more interesting to me is that everyone who converts their code into Flow or TS immediately finds at least N bugs (albeit small). Just rereading all your code carefully (which porting generally requires) generally finds a few bugs in my opinion. It might not always be because of typescript.

wyaeld 9y ago
It doesn't port anything. Valid JS is valid TS, its just that the TS compiler processes it and tends to surface issues that just running it under Nodejs doesn't