Polymer 2.4: Paving the way for 3.0 and TypeScript support
polymer-project.org
polymer-project.org
TypeScript is not suitable for building the vast majority of web UIs; it just makes things way more complicated (with the added build step, source-mapping issues, missing type definitions, outdated type definitions...) and adds no value beyond improved code completion and compiler warnings (and those two are conveniences at best).
Web applications are centred around APIs. APIs use JSON... JSON doesn't have types; so already there is an obvious impedance mismatch!
It makes no sense at all whatsoever that the front end logic should be more strict than the API!
As far as the front end is concerned, the API is the one source of truth; so unless you're willing to go back to the old days of SOAP and also start adding type annotations to your transport protocol then it makes no sense whatsoever to use TypeScript.
The main exception I can think of are web-based games; in this case it's possible that most of the complexity is actually on the front end itself (and not in the data integration aspect).
On my last large project, I had to wait 10 to 15 seconds for the code to build every time I saved the file (and yes the compilation step was optimized to only include relevant code; a large number of dependencies don't help).
So every time I made a change to the code to check something, I had to wait... You can't use console.log() to quickly check stuff anymore; the compile overhead is so significant that you're forced to pull up the debugger and manually step through the relevant code every single time you want to check something (you want to get as much info as possible from each debug cycle because it's so slow).
When writing plain JavaScript, I only pull up the debugger when it's a particularly difficult bug (e.g. a race condition). For most bugs, I can get all the information I need with just a couple of calls to console.log() in my code. The debugger is just unwieldy.
The case you describe very rarely happens to me with JavaScript; having fewer primitives to work with greatly reduces these kinds of issues... Sure it opens up the possibility that you'll do something stupid like trying to add an object with a string; but that's a pretty silly thing to do. If you name your variables properly then that never happens.
With C/C++, there are many primitives so you might get errors when you try to assign an int64 to an int8 (for example)... With JS, however, because there are fewer primitives so the odds of that happening are much much smaller.
Because there are so few primitives in JS, it's easy to remember how they all interact with each other. The only exception is the boolean truth table for '==' (which is a mess); that's why it's usually recommended to use '===' instead.
But you're describing a fairly complicated scenario where you have multiple public API's with different request types, internal data (hopefully canonicalized at the border) and response types.
How do you keep track of all that data conversion without types?
It does to people who appreciate type information. To each his own. I can see the appeal of dynamic typing but I am pretty sure obvious errors (obvious if the compiler has type info) go uncaught.
I went with redux.
You could I guess technically you could implement $broadcast - but that would be slow same as with angular, as for $emit you can just emit standard events.
Very exciting.