Same with switch fallthrough, same with error handling, same with half his issues with JS.
There are some legitimate grievances tucked in there, but the author lost me by pretending that his preferences were universal.
I strongly believe statically typed language are objectively superior to dynamically typed ones. Many might say that this is my subjective opinion or just a matter of personal preference, but I absolutely disagree.
[†] (a bit of) my experience explained here: https://news.ycombinator.com/item?id=12594616
I wouldn't even consider dealing with a big JS codebase without either Flow or Typescript now.
RN supports iOS, Windows, and Android. Plus RN is somewhat close to React, so some code could be reused between the two. Plus you get out-of-band code updates!
Xamarin supports iOS, Windows, and Android. But there is no web story. Or is there?
The JavaScript toolchain is more than good enough to build the kinds of applications that React Native targets. Most of these applications aren't stellar apps that require critical performance or rigorous type checking, they're just dumb front-ends to REST endpoints. If you're going to build an awesome app, then use better tools.
The reason I would use React over Xamarin is simple: Speed of training and development. I can hire, train and get a React developer up and running and building proof-of-concepts a lot quicker than on Xamarin.
Because targetting javascript has a lot of advantages, being cross platform is a major one of them. You basically get the type-safety of swift, with the ability to target multiple platforms.
The fact that it transpiles to JS is irrelevant, you can provide a safe interface to something unsafe. Take Elm for example, it transpiles to JS and yet guarantees that you will never produce a runtime exception.
TypeScript has a flag that prohibits switch fallthrough, for instance, though that's an easy one to set up a linter to catch.
One reason I prefer NativeScript to React Native; they are embracing TypeScript and Angular vs. React. I find Angular 2 to be more flexible, but that I freely admit is a preference.
With a proper type system (see: Haskell, Scala) and parametrized types, you can do everything that’s reasonable in a dynamically typed language, too.
I've worked on large production codebases in the past, for servers written in both Java (at company [a]), and JavaScript with Node.js (at company [b]).
The Java codebase was much easier to read, understand, navigate around, and debug. If a function took an argument "SomeClass foo" I could look up "SomeClass" and know exactly what it was.
In the Node codebase, if have argument "foo", you're lost with no easy way to figure out exactly what this "foo" is. You would have to run the code, set a breakpoint, and inspect "foo".
In addition, JavaScript encouraged a lot of bad coding practices that almost made me want to cry.
In the Java server, we used a JSON library where you would annotate a class, and the library would construct an object for that class. This guaranteed the JSON was well-formed, among other things.
In the Node.js codebase, people would pull something out of Mongo, chuck it in a variable "data", and then do "data.foo.bar[1].qux". (Yes, the "[1]" is real.) It was terrible.
The company that used Node.js had far less reliable code overall, and their services (written in JavaScript) would crash frequently, most commonly due to type errors.
And this is just a tip of the iceberg. There were so many problems that attributable to the choice of JavaScript as the language for a large, complex back-end system, and the failure to use any tool for type checking (like Flow), in addition to bad coding practices.
[a] Amplify Education, Inc. https://www.amplify.com/
[b] Lifion, a division of ADP. http://www.lifion.com/
You can, but you can't get any guarantee that said assertion will never fail.
Granted, that benefit is probably minor, but it is a benefit in TypeScript's favor.
At a previous job we tried TypeScript but it took around 20 seconds to build our front end. Since then I hear speed has improved.
I would say that a very fast edit-run cycle is an advantage of dynamic languages -- especially if you can edit code live without restarting the application -- but that's not always the norm.
* Look up member names
* Look up object hierarchy structures
* Run code (or tests) to verify that you've done the above correctly
When the compiler knows the types, it can bring your code up to 90% correct. Half the time you don't even need to specify types: TypeScript can guess them from context.
You need to specify parameter types and return types; if you're declaring a variable without initializing it, or assigning it an empty array or object, you need to specify its type. Other than that you generally get type inference from TypeScript (at least as of 2.0).
It just makes the dynamic typing safer. It absolutely should be considered a best practice; anything that can accelerate development by 100% or more should be.
While it can be tremendous help, calling it a best practice misses the point.
And having ES2015 features (+async/await) is very useful: var should be deprecated, arrow functions should be standard, etc.
Tiny projects? Sure, do whatever you want. But I've started switching even my one-file, 2-3 screens of code Node servers over to TypeScript, and it's not only useful, it accelerates development by 100% simply because you don't need to run your code to know that you've got the types correct.
I stand by "best practice."
The funniest/alarming example for me though was immutablility. The documentation exhorts the developer to take care not to make assignments to immutable objects. And there's your immutability: just don't change object and it will be immutable.