We introduced Typescript into our architecture. We start to love it, too.
One thing though: the engineers started to write classes for everything. I had to catch that and forced them to stay as functional as possible. Does that happen to other teams, too?
And I really like to see WebAssembly to become part of our browsers and Typescript generating it instantly.
I've written a lot of Angular code with Typescript and although you're right in saying functional code is preferrable I've found that a little bit OO when used correctly makes your code DRYer.
For example, if you have a lot of paginated lists you can write an abstract class that handles all the "get the results", "put them on a list", "display pagination", "on click display the next/previous page" trivia and then inherit from that to add the UI/presentation and any specific logic. It's absolutely possible in plain javascript but I shudder at the thought of writing something like that and even worse, refactor it. Typescript with OO and generics simplifies the task considerably.
As in everything in life: "dogma is bad", "παν μέτρον άριστον", "use the best tool for the job" etc. Words to live by.
Of course, I don't forbid to use OO. Its just adds more boilerplate if ES5 is generated and increases the size of the code. And the ES5 code we migrate is already mostly functional.
For cross cutting concerns like pagination, we already have functions that enhance the pagination controls.
I'm hoping WebAssembly opens up lots of other languages to browser development. Any language could compile to WebAssembly: rust, haskell, go, swift, etc. I think it will really open up the browser.
TypeScript will never generate WebAssembly for you. WA is used for hosting your own sandboxed native code environments, it doesn't offer any of the tooling you'd need to run TypeScript-based libraries/applications.
I don't understand this line of reasoning. WebAssembly isn't 'sandboxed native code', it's a compressed AST, and even if it was native code there's nothing stopping someone creating a native compiler for TypeScript.
That said, Typescript is most likely to support WebAssembly when WebAssembly offers a GC implementation for it to use (the WebAssembly GC is planned in the medium to long term IIRC).
Why not? Someone might write a compiler. And I expect that if WebAssembly becomes the primary source for browser runtimes, browser vendors will probably try to compile Javascript to WebAssembly first. It does not make sense to have two engines or two interpreters for a single WebAssembly engine.
One thing though: the engineers started to write classes for everything. I had to catch that and forced them to stay as functional as possible. Does that happen to other teams, too?
And I really like to see WebAssembly to become part of our browsers and Typescript generating it instantly.