Ughhh. It's fine if you prefer statically-typed languages to dynamically-typed ones, but that's a preference, not a reason to try and say that JS is objectively terrible.
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 have learned, from experience[†], that strongly and statically typed languages, and in general languages with rich type systems almost always result in fewer common bugs, and higher quality code.
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.
I would much, much rather use a modern, statically typed language than a dynamic language. This includes languages like Swift, Scala, Kotlin etc and specifically excludes Java.
I wouldn't even consider dealing with a big JS codebase without either Flow or Typescript now.
Yeah, but why use another patch on top of a patch where there are modern type-safe languages like Swift. JS has its uses, but it's difficult to debug, doesn't take advantage of all the advances in modern languages design that help prevent whole classes of bugs, and carries a lot of baggage. The only benefit would be universal app development, but even then Xamarin seems like a better choice.
>Yeah, but why use another patch on top of a patch where there are modern type-safe languages like Swift.
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.
> Yeah, but why use another patch on top of a patch where there are modern type-safe languages like Swift.
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.
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?
TypeScript is a JavaScript best practice at this point. It's a type safety net on top of dynamic types, so you get the best of both worlds.
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.
TypeScript gives you the benefits of dynamic typing without the drawbacks of a C++/Java restrictive-typing system.
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.
Unless you are doing Java, I would even take issue with the argument that dynamic typing is faster to develop. It's taken as obvious fact but I don't think we should just take that as face value. Getting as-you-type feedback, intellisense, and simple documentation (methods, parameters, types) is hugely productive. As well as the ability to break things and know you've caught all the breaks.
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.
I agree, and I consider TypeScript to be twice as fast to develop in as plain JavaScript just because you don't need to:
* 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).
You can do them, as you noted, at a much slower pace. Type systems catch one class of bugs, and if in your experience these are not the bugs you worry about or the bugs that cause you the most pain then slowing down development is a high cost to pay.
It goes beyond just catching bugs. Large code bases written in statically typed languages are easier to understand.
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.
That's an example of bad design. You can do that in Java as well, just in different ways. There are trade-offs that you make, and it means that various languages and type systems make different kinds of screw-ups easier.
Honestly I think the bug catching aspect of static typing is its least useful property. (Useful, but not like, amazing -- you can write assertions on a type in a dynamic language). I think the good thing about static typing is it makes a code-base much easier to navigate and much more self documenting. I spend most my time navigating other peoples code. I know you can get most of the reliability of static typing with extensive test suites etc., but that doesn't help my IDE and it doesn't let me look up parameters at a glance. I used to be firmly in the dynamic camp, but having to maintain other people's javascript definitely made me do a 180.
It does have a compile time cost and that's not negligible... although with all the heavy transpilation going on these days, a bit of type checking might drown that out.
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.
Maybe the initial write is faster, but any refactoring strongly favors static type systems in the speed department. Even an extremely well tested dynamic code base will have a significant disadvantage for refactoring because the tools can't catch all the small details and you'll have to iterate over and over again until tests pass.
If you are not building large applications then TS is counter productive. Just consider the extra compilation step, the dependencies and obfuscated source code.
While it can be tremendous help, calling it a best practice misses the point.
The code output is really clean; I wouldn't call it obfuscated. Especially when source mapping works just about everywhere.
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.
OP is not complaining about dynamic type -- the examples appear to show where 'type' doesn't apply at all.
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.
Alarming? Just use facebook's immutable types or a transpiled language (eg typescript) that has them built in. Unless you're meaning it's funny/alarming how the author was able to write so much without googling a solution..
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.