4 ms·

Dear TS authors: Thank you (!) for your amazing contributions. TS is the best new thing in tech. That said: Your linguistic genius is way ahead of the toolin

Dear TS authors: Thank you (!) for your amazing contributions. TS is the best new thing in tech. That said: Your linguistic genius is way ahead of the tooling. I feel as though some of these 'new and cool' 2.1 things are a little bit intellectual, maybe useful in some cases ... But getting TS to work in the real world, the various build configurations, tool-chains etc. - it's still clumsy. It was difficult to grasp the difference between AMD and other paradigms. I still have problems with circular dependencies, or rather, things happening before modules are loaded. Here's one pain point: Creating a static attribute on a class and initializing it right there, as in: class A { static b:B = new B(); } Means that 'new B()' will get executed right when that module is loaded, possibly before the module containing B is loaded. It's ugly, mechanical - but it's not a 'fine point'. I think these are the kinds of issues which are more likely to hold people back, as opposed to the lack of some rather fancy new paradigms such as 'Mapped Types'. Anyhow, keep up the good work. Lovin't it.

thejameskyle 10y ago
> Creating a static attribute on a class and initializing it right there, as in: class A { static b:B = new B(); } That is how the ECMAScript spec is designed. And TypeScript _should_ follow the spec.
- edblarney 10y ago
  Yes, it needs to be created 'right there' - but not in the context of other modules loads. I doubt that a strict interpretation requires that it does so before other modules are loaded. I suggest that 'right there' , i.e. the execution context can be delayed until mods are loaded. One could argue that all modules could be loaded before execution context. In Java, for example, you do not have this problem and yet, in Java we would say the attribute is initialized 'right there' as well. Obviously, when I say 'loaded' I don't mean 'executed'. In any event, it's a problem.
WorldMaker 10y ago
Your pain point sounds like a runtime problem with your module loader. You may want to investigate your module loader's issue tracker. (I recommend SystemJS [and jspm] over AMD these days, for what that is worth. It handles module loading quite well including all the complexity of circular dependencies that ES2015 specced and TS supports.) «I feel as though some of these 'new and cool' 2.1 things are a little bit intellectual, maybe useful in some cases ...» async/await and object spread should be useful in quite a lot of places. The other "intellectual" additions are immediately useful indirectly because they were built to support object spread (so that object spread types make sense), even if you don't wind up using the directly (because you aren't writing complicated type definition files for instance). Even then, you might find a bunch of uses for the types Partial<T> (partial objects) and Readonly<T> (shallowly frozen objects).
- edblarney 10y ago
  Yeah, agree with async/await and spread.

thejameskyle 10y ago

> Creating a static attribute on a class and initializing it right there, as in: class A { static b:B = new B(); } That is how the ECMAScript spec is designed. And TypeScript _should_ follow the spec.

edblarney 10y ago
Yes, it needs to be created 'right there' - but not in the context of other modules loads. I doubt that a strict interpretation requires that it does so before other modules are loaded. I suggest that 'right there' , i.e. the execution context can be delayed until mods are loaded. One could argue that all modules could be loaded before execution context. In Java, for example, you do not have this problem and yet, in Java we would say the attribute is initialized 'right there' as well. Obviously, when I say 'loaded' I don't mean 'executed'. In any event, it's a problem.

WorldMaker 10y ago

Your pain point sounds like a runtime problem with your module loader. You may want to investigate your module loader's issue tracker. (I recommend SystemJS [and jspm] over AMD these days, for what that is worth. It handles module loading quite well including all the complexity of circular dependencies that ES2015 specced and TS supports.) «I feel as though some of these 'new and cool' 2.1 things are a little bit intellectual, maybe useful in some cases ...» async/await and object spread should be useful in quite a lot of places. The other "intellectual" additions are immediately useful indirectly because they were built to support object spread (so that object spread types make sense), even if you don't wind up using the directly (because you aren't writing complicated type definition files for instance). Even then, you might find a bunch of uses for the types Partial<T> (partial objects) and Readonly<T> (shallowly frozen objects).

edblarney 10y ago
Yeah, agree with async/await and spread.