I Was Wrong About TypeScript

"Love" is a strong word. The syntax is nicer than JavaScript, and I prefer to use it when possible. Though granted JS is making strides and the difference isn't as great as it was 5 years ago.

You're part of a MS project doing this, or you're doing it on your own?

I don't think his criticism is too harsh.

Two of the main problems I had with angular - the template syntax and the way the digest cycle worked, both contributed to its scaling factor.

The template syntax meant you would always wonder what a parameter meant when passed to a directive. Essentially, all parameters passed to a directive were strings, but angular would parse some strings to mean "the property of a parent scope", and some more convoluted variations of that(check out https://docs.angularjs.org/api/ng/service/$compile#-scope-). Furthermore, using the recommended ng-controller directive created great spaghetti code, with template blobs where the current scope is almost impossible to track. Applying multiple directives to the same element sometimes required special parameter parsing, which further made the situation confusing. This confusion meant the more stuff you had, the more time you had to spend carefully memorizing it all so you knew what was going on.

The digest cycle fundamentally limits angular's scale. It was designed with some scale in mind at first - a digest cycle triggered at a specific scope would only run watchers under that scope, thus limiting the effect. I assume they hit the problem that there was no way to define explicitly "global" watchers, or to tell another scope to update itself. This issue apparently crept into the development of angular and local digests were pretty much abandoned in favor of using scope.$apply(), which triggers a digest cycle at the topmost scope. Local digests were not really talked about in the documentation, which was littered with examples of scope.$apply(), all of angular's provided directives used scope.$apply() and pretty much no one wrote any code limiting the amount of watchers triggered in an update. React specifically addressed this point with shouldComponentUpdate and the ecosystem built around it, which is one of its biggest performance benefits.

Further criticism would be the terminology confusion. Angular talked about directives, modules, controllers, filters, services, factories, providers, etc.

In essence, providers/factories/services were all just singletons instantiated in different ways(providers being the progenitor and factories/services being variations).

Filters were poorly named, as they were actually mapping functions or value formatters. Thus came the infamous "filter filter", which filtered elements in a collection, as opposed to say the "currency filter", which added currency markers to numbers. They were also incredibly inefficient, running on every digest cycle, even after the attempted fixes with "stateless filters"(http://www.bennadel.com/blog/2766-stateless-filters-don-t-ap...)

Controllers were essentially stunted directives, provided via the ng-controller directive. They were paraded as the way to start "simple" development, but led to a lot of bikeshedding about where to use controllers and where directives, the confusion around directives requiring controllers and the limitations around that, how to appropriately bind directive parameters to a controller's "scope"(not an actual scope but the controller function object itself), the bindToController function resolving that problem(introduced in 1.4?), etc, etc.

Modules were also a weird concept without much practical use. They do not provide a separate namespace(all your angular elements go into the same one), they don't leverage angular tooling to import your code(you have to import your code manually e.g. add script tags). Mostly they provided the config() and run() functions which would let you schedule code to be executed on-load.

I could go on and on about the confusion that angular's terminology caused, the microsyntax in its expressions and how interpolation worked, the scoping inheritance issues around directives and the subsequent overuse of isolate scope to avoid them, transclusion and how it affected scope inheritance(which led to articles like this one - http://angular-tips.com/blog/2014/03/transclusion-and-scopes...), the massive problems with there being no real directive lifecycle hooks you could use...it usually took a monumental effort to avoid all the traps and pitfalls of angular on any larger project.

That doesn't make angular necessarily a terrible framework, because it did enable some productivity when being fairly rigourous when using it. That rigour was developed by the community as it struggled to understand all the concepts thrown at you, but it certainly didn't come easy, and I'm not sure it became really widespread. This severely crippled "developer scale" for me, and the performance issues of watchers/filters worked against "performance scale".

Mind being a bit more specific with "has some issues"? Our project isn't exactly small, and we haven't bumped into a problem yet. I'd really like to know what to expect if something is about to jump out from behind a wall.

Typescript is still extremely useful even if you are writing more functional code. There is no "ideal Typescript", TS is still ES underneath and just about all the ES paradigms including high functional code are still available in TS and benefit from typing information. (The possible exception being that TS is not entirely great at some of the more complex prototype-oriented paradigms, but even that has gotten significantly better in TS >= 1.8 with support for things like intersection types.)

Hey rhymohr, I think I see what you mean. If you're already using something like Babel & Webpack, it should just be a matter of using a TypeScript loader like ts-loader[1] or awesome-typescript-loader[2]. TypeScript should just fit into that build step.

Let me know how that ends up working out!

[1]: https://github.com/TypeStrong/ts-loader [2]: https://github.com/s-panferov/awesome-typescript-loader