5 ms·

I've gone through the same experience this year, having picked up modern JavaScript, Angular2, TypeScript and RxJS for a project. For me it was TypeScript that

I've gone through the same experience this year, having picked up modern JavaScript, Angular2, TypeScript and RxJS for a project. For me it was TypeScript that did it. I came to appreciate strong typing. And ES6, fixing the 'this' scope problems and with a conventional class syntax (I understand prototype inheritance is clever, but it's not the way I've been trained to think). I didn't get to use async/await for various reasons, but that looks to remove my third pain point (callback hell/promises/observables). RxJS remains a mystery (I swear the API wasn't designed for humans) I use and hope it works, and combining code that use Observables with those that use Promises still wakes me up in a cold sweat. But now going back to old territory (PHP, Symfony) I miss it. Yesterday's miss was union types. TypeScript has spoiled me.

TomMarius 9y ago
There is no callback hell if you're using promises correctly. While await is the best option, plain promises are pleasant to work with as well. Could you paste an example of how do you use them? If you're actually using them wrong, I'll gladly show you how to do it right.
- bpicolo 9y ago
  Think he was trying to say that he likes neither callback hell nor promises
  - TomMarius 9y ago
    Oh, I didn't get that. If that's the case, I'm sorry for misunderstanding.
slackingoff2017 9y ago
Amen for typescript. With TsLint and all the options on JavaScript is almost pleasant to work with.
5trokerac3 9y ago
I left React for Angular 4 this year, because I came to the realization that once I made the decision to leave the loosie-goosie world of default JS, there was no reason to have my framework be loose either. I'm really loving the confines of a "one way to do it" framework like Angular 4. It makes teamwork much easier, speeds up development once you've gotten over the learning curve, and is damned impressive when it comes to app performance. I'm really looking forward to the day when TypeScript platforms like Angular 4 compile down to WebAssembly and performance goes through the roof.
- kneedeepclunge 9y ago
  how well does Angular perform on production? as far as i know, React is used more widespread
  - 5trokerac3 9y ago
    It's blazing fast. IMO React is more widely adopted, because it's been production ready for longer and because of the whole Angular PR debacle. Once the platform development settles down (v2 -> v4 anyone?), I think it'll be the clear option for enterprise level development.
  - calafrax 9y ago
    horribly.
  - pbowyer 9y ago
    We used Angular inside Ionic for an iOS app. Performance is OK, but I can't tell you if a different JS framework would be faster, or if it's a device/Ionic limitation. The main problem has been with rendering large sets of data (say 100+ items) in a scrolling list.
- pps 9y ago
  > I'm really looking forward to the day when TypeScript platforms like Angular 4 compile down to WebAssembly and performance goes through the roof. You will be disappointed https://github.com/WebAssembly/design/issues/219 https://github.com/WebAssembly/design/issues/219
disease 9y ago
TypeScript also works wonders in React. Using a component that someone else made? TypeScript will make sure you are passing it the props it expects. Change the expected props for a component? TypeScript will immediately let you know what code you need to change for every component that uses that component. Also NoImplicitAny and StrictNullChecks are two great tastes that taste great together. Everything in your code is now typed, AND TypeScript will now actually make you think about how you are handling (or not handling) null values. These two flags have basically allowed us to completely eliminate all the 'X is not a function of Y' and 'Z is undefined in this' errors - which is pretty amazing because for me at least these were probably the most common JS errors I get.
WorldMaker 9y ago
Most of my projects I wound up switching from RxJS to xstream [1], for several reasons related to size/performance and synergy with a framework I heavily use (Cycle.js). It's RxJS influenced, but written from scratch in Typescript with a much simpler API surface and somewhat easier to reason with semantics (default "hot" and "shared" Observables versus default "cold" and "unpublished" Observables). Also, Typescript now supports (since 2.3) downleveling async/await all the way to ES5, which is very handy. [1] http://staltz.com/xstream/ http://staltz.com/xstream/
flavio81 9y ago
Typescript will give you compile-time type checking, but the actual runtime (javascript) is weakly typed. For me this is the main problem with the language, otherwise it is a good language even without compile time type checking.
- pbowyer 9y ago
  > Typescript will give you compile-time type checking, but the actual runtime (javascript) is weakly typed. Yes and this sucks. There have been a few bugs I've had (can't remember details) where the types or visibility looked OK in the editor but I was bitten at runtime. No doubt due to my loose configuration - tightening up the linter would help and getting rid of null/undefined overlaps is my next move.

TomMarius 9y ago

There is no callback hell if you're using promises correctly. While await is the best option, plain promises are pleasant to work with as well. Could you paste an example of how do you use them? If you're actually using them wrong, I'll gladly show you how to do it right.

bpicolo 9y ago
Think he was trying to say that he likes neither callback hell nor promises
- TomMarius 9y ago
  Oh, I didn't get that. If that's the case, I'm sorry for misunderstanding.

slackingoff2017 9y ago

Amen for typescript. With TsLint and all the options on JavaScript is almost pleasant to work with.

5trokerac3 9y ago

I left React for Angular 4 this year, because I came to the realization that once I made the decision to leave the loosie-goosie world of default JS, there was no reason to have my framework be loose either. I'm really loving the confines of a "one way to do it" framework like Angular 4. It makes teamwork much easier, speeds up development once you've gotten over the learning curve, and is damned impressive when it comes to app performance. I'm really looking forward to the day when TypeScript platforms like Angular 4 compile down to WebAssembly and performance goes through the roof.

kneedeepclunge 9y ago
how well does Angular perform on production? as far as i know, React is used more widespread
- 5trokerac3 9y ago
  It's blazing fast. IMO React is more widely adopted, because it's been production ready for longer and because of the whole Angular PR debacle. Once the platform development settles down (v2 -> v4 anyone?), I think it'll be the clear option for enterprise level development.
- calafrax 9y ago
  horribly.
- pbowyer 9y ago
  We used Angular inside Ionic for an iOS app. Performance is OK, but I can't tell you if a different JS framework would be faster, or if it's a device/Ionic limitation. The main problem has been with rendering large sets of data (say 100+ items) in a scrolling list.
pps 9y ago
> I'm really looking forward to the day when TypeScript platforms like Angular 4 compile down to WebAssembly and performance goes through the roof. You will be disappointed https://github.com/WebAssembly/design/issues/219 https://github.com/WebAssembly/design/issues/219

disease 9y ago

TypeScript also works wonders in React. Using a component that someone else made? TypeScript will make sure you are passing it the props it expects. Change the expected props for a component? TypeScript will immediately let you know what code you need to change for every component that uses that component. Also NoImplicitAny and StrictNullChecks are two great tastes that taste great together. Everything in your code is now typed, AND TypeScript will now actually make you think about how you are handling (or not handling) null values. These two flags have basically allowed us to completely eliminate all the 'X is not a function of Y' and 'Z is undefined in this' errors - which is pretty amazing because for me at least these were probably the most common JS errors I get.

WorldMaker 9y ago

Most of my projects I wound up switching from RxJS to xstream [1], for several reasons related to size/performance and synergy with a framework I heavily use (Cycle.js). It's RxJS influenced, but written from scratch in Typescript with a much simpler API surface and somewhat easier to reason with semantics (default "hot" and "shared" Observables versus default "cold" and "unpublished" Observables). Also, Typescript now supports (since 2.3) downleveling async/await all the way to ES5, which is very handy. [1] http://staltz.com/xstream/ http://staltz.com/xstream/

flavio81 9y ago

Typescript will give you compile-time type checking, but the actual runtime (javascript) is weakly typed. For me this is the main problem with the language, otherwise it is a good language even without compile time type checking.

pbowyer 9y ago
> Typescript will give you compile-time type checking, but the actual runtime (javascript) is weakly typed. Yes and this sucks. There have been a few bugs I've had (can't remember details) where the types or visibility looked OK in the editor but I was bitten at runtime. No doubt due to my loose configuration - tightening up the linter would help and getting rid of null/undefined overlaps is my next move.