6 ms·

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

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.

steego 10y ago
I prefer statically-typed languages too, but this is easily solved by using something TypeScript or Flow.
- pzh 10y ago
  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.
  - DenisM 10y ago
    Speaking of 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?
  - steego 10y ago
    > 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.
  - leshow 10y ago
    >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.
SomeCallMeTim 10y ago
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.
- qwertyuiop924 10y ago
  TS over JS isn't best practice yet: Some of us like dynamic typing.
  - kuschku 10y ago
    For what purpose is dynamic typing ever useful except "it’s faster to develop"? With a proper type system (see: Haskell, Scala) and parametrized types, you can do everything that’s reasonable in a dynamically typed language, too.
    - evgen 10y ago
      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.
      - winter_blue 10y ago
        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. [a] Amplify Education, Inc. https://www.amplify.com/ https://www.amplify.com/ [b] Lifion, a division of ADP. http://www.lifion.com/ http://www.lifion.com/
st3v3r 10y ago
Plenty of JS's own failings are enough of a reason to say it's objectively terrible.
winter_blue 10y ago
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. [†] (a bit of) my experience explained here: https://news.ycombinator.com/item?id=12594616 https://news.ycombinator.com/item?id=12594616
- cageface 10y ago
  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.
banku_brougham 10y ago
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.
- JaRail 10y ago
  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..

steego 10y ago

I prefer statically-typed languages too, but this is easily solved by using something TypeScript or Flow.

pzh 10y ago
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.
- DenisM 10y ago
  Speaking of 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?
- steego 10y ago
  > 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.
- leshow 10y ago
  >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.

SomeCallMeTim 10y ago

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.

qwertyuiop924 10y ago
TS over JS isn't best practice yet: Some of us like dynamic typing.
- kuschku 10y ago
  For what purpose is dynamic typing ever useful except "it’s faster to develop"? With a proper type system (see: Haskell, Scala) and parametrized types, you can do everything that’s reasonable in a dynamically typed language, too.
  - evgen 10y ago
    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.
    - winter_blue 10y ago
      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. [a] Amplify Education, Inc. https://www.amplify.com/ https://www.amplify.com/ [b] Lifion, a division of ADP. http://www.lifion.com/ http://www.lifion.com/

st3v3r 10y ago

Plenty of JS's own failings are enough of a reason to say it's objectively terrible.

winter_blue 10y ago

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. [†] (a bit of) my experience explained here: https://news.ycombinator.com/item?id=12594616 https://news.ycombinator.com/item?id=12594616

cageface 10y ago
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.

banku_brougham 10y ago

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.

JaRail 10y ago
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..