4 ms·

What sold me on TypeScript was that it didn't just add features, it actively solved a problem I'd been experiencing. Once a JavaScript project scales beyond wh

by YCode 9y ago

What sold me on TypeScript was that it didn't just add features, it actively solved a problem I'd been experiencing. Once a JavaScript project scales beyond what can fit in your head, JS's initial productivity boost crumbles because you have to constantly double back and make sure your methods/constructors/etc. are correctly used, which properties are optional, etc... A lot of the debugging happens in runtime and god help you if you try to make a breaking change to one of the major classes/apis in your project. It's not unbearable, but the main reason for using JS is because of the productivity it allows. With TS for the cost of taking the time to explicitly define your data you get a C#/Java level of debugging that has clear productivity gains and shifts your debugging from the browser/console to the IDE. And when something doesn't fit the TS model you can just exclude it or only type the wrappers that integrate with the rest of your project. That and async/await is a godsend over promises.

pryelluw 9y ago
Have you tried Elm? Id love to know your experiences.
- YCode 9y ago
  I haven't; I haven't tried Flow either which looked promising. For kicks I tried the online Elm demo. Offhand it doesn't seem like Elm highlights errors inline(?). The syntax also looks a little foreign, whereas TS generally still looks like JS with a few exceptions. I imagine Elm/Flow both have this, but another thing I like that TS does in VSCode at least with a watching task is collecting errors project-wide in a "problems" window.
  - pryelluw 9y ago
    Yes, the Elm syntax is more Haskell than JS. Not C based, which makes it an outlier. Please try Elm and email me with your feedback. Id love to know more about it. Im a programming languages nerd. :)
  - bpp 9y ago
    Flow gets a good amount of the way there; it doesn't have quite the tooling of TypeScript but VSCode is actually able to bring a lot of that tooling to a Flow-typed codebase. Just yesterday I finished a major refactor that I'm not even sure I'd have attempted if we weren't using Flow. One giant action file feeding three insane reducers – yet I'm confident (with some testing) that it'll still work when I deploy today.
  - KurtMueller 9y ago
    Elm has a compiler (a very helpful one at that) which will indeed collect errors project-wide in a "problems" window. Text editors like VS Code and Atom have Elm extensions which will highlight any errors the Elm compiler comes across.
- boubiyeah 9y ago
  Elm is very different from typescript and is generally a much more involved choice than just "let's make our usual JS strongly typed". - You need to like Elm the language (it's pretty good, but limited, not expressive) - You need to like purity. Time.now or Math.random returns an asynchronous Task. I know why it's done like that, I just don't agree with the tradeoff. - You need to like Elm the ecosystem or be prepared to write lots of awkward JS glue code - You need to like Elm, the architecture (it's simple, but has tons of boilerplate and limitations) - You need to accept Elm, the roadmap made by a benevolent dictator. The progress is slow. Compared to a good typescript codebase, you will get like +5/10% type safety. Typescript is way more flexible, but that also mean you will have to rely a bit more on human code reviews, etc rather than the Elm compiler just telling you "no, there is only one way to do this". On the other hand, you have just typescript on one side, Elm + javascript/typescript if you want to achieve anything serious on the other :) Go with Elm if you like being in a very, very controlled environment (frameworky) and you're afraid to make mistakes. Go with typescript if you're a hacker who like to mix and match architectures, libs, etc and accepts things change fast in the frontend orld right now.
  - lfischer 9y ago
    Have you encountered limitations in Elm that pushed you to resort to writing JavaScript (as opposed to using JavaScript libraries from Elm through ports)?
- splintercell 9y ago
  Elm is so amazing. It isn't as amazing when you just try out it's tutorial, but if you try to build an actual application in it, especially if you are a single programmer working on a project. In my experience whenever I worked on a JS project on my own, there was an upper limit to how far I could keep writing the code on my own. After that, I had to spend time in doing other things (like writing Integration tests, lots and lots of unit tests, or refactor existing code because I realized that there are many issues unveiled). But now, with Elm, it's like a whole set of unit tests are being written at the time of writing code which take care of plenty of common errors usually made due to lack of a good type system. Add to that the usage of Maybe types (which are very beneficial in avoiding some UI antipatterns[1]), and the Reactive Programming pattern, I feel like I am writing a lot less code than what I am used to writing in JS projects. I highly recommend Elm to anyone who wants to write a personal project, you'd see what benefits I'm talking about. 1. http://blog.jenkster.com/2016/06/how-elm-slays-a-ui-antipattern.html http://blog.jenkster.com/2016/06/how-elm-slays-a-ui-antipatt...

by YCode 9y ago

pryelluw 9y ago

Have you tried Elm? Id love to know your experiences.

YCode 9y ago
I haven't; I haven't tried Flow either which looked promising. For kicks I tried the online Elm demo. Offhand it doesn't seem like Elm highlights errors inline(?). The syntax also looks a little foreign, whereas TS generally still looks like JS with a few exceptions. I imagine Elm/Flow both have this, but another thing I like that TS does in VSCode at least with a watching task is collecting errors project-wide in a "problems" window.
- pryelluw 9y ago
  Yes, the Elm syntax is more Haskell than JS. Not C based, which makes it an outlier. Please try Elm and email me with your feedback. Id love to know more about it. Im a programming languages nerd. :)
- bpp 9y ago
  Flow gets a good amount of the way there; it doesn't have quite the tooling of TypeScript but VSCode is actually able to bring a lot of that tooling to a Flow-typed codebase. Just yesterday I finished a major refactor that I'm not even sure I'd have attempted if we weren't using Flow. One giant action file feeding three insane reducers – yet I'm confident (with some testing) that it'll still work when I deploy today.
- KurtMueller 9y ago
  Elm has a compiler (a very helpful one at that) which will indeed collect errors project-wide in a "problems" window. Text editors like VS Code and Atom have Elm extensions which will highlight any errors the Elm compiler comes across.
boubiyeah 9y ago
Elm is very different from typescript and is generally a much more involved choice than just "let's make our usual JS strongly typed". - You need to like Elm the language (it's pretty good, but limited, not expressive) - You need to like purity. Time.now or Math.random returns an asynchronous Task. I know why it's done like that, I just don't agree with the tradeoff. - You need to like Elm the ecosystem or be prepared to write lots of awkward JS glue code - You need to like Elm, the architecture (it's simple, but has tons of boilerplate and limitations) - You need to accept Elm, the roadmap made by a benevolent dictator. The progress is slow. Compared to a good typescript codebase, you will get like +5/10% type safety. Typescript is way more flexible, but that also mean you will have to rely a bit more on human code reviews, etc rather than the Elm compiler just telling you "no, there is only one way to do this". On the other hand, you have just typescript on one side, Elm + javascript/typescript if you want to achieve anything serious on the other :) Go with Elm if you like being in a very, very controlled environment (frameworky) and you're afraid to make mistakes. Go with typescript if you're a hacker who like to mix and match architectures, libs, etc and accepts things change fast in the frontend orld right now.
- lfischer 9y ago
  Have you encountered limitations in Elm that pushed you to resort to writing JavaScript (as opposed to using JavaScript libraries from Elm through ports)?
splintercell 9y ago
Elm is so amazing. It isn't as amazing when you just try out it's tutorial, but if you try to build an actual application in it, especially if you are a single programmer working on a project. In my experience whenever I worked on a JS project on my own, there was an upper limit to how far I could keep writing the code on my own. After that, I had to spend time in doing other things (like writing Integration tests, lots and lots of unit tests, or refactor existing code because I realized that there are many issues unveiled). But now, with Elm, it's like a whole set of unit tests are being written at the time of writing code which take care of plenty of common errors usually made due to lack of a good type system. Add to that the usage of Maybe types (which are very beneficial in avoiding some UI antipatterns[1]), and the Reactive Programming pattern, I feel like I am writing a lot less code than what I am used to writing in JS projects. I highly recommend Elm to anyone who wants to write a personal project, you'd see what benefits I'm talking about. 1. http://blog.jenkster.com/2016/06/how-elm-slays-a-ui-antipattern.html http://blog.jenkster.com/2016/06/how-elm-slays-a-ui-antipatt...