News for hackers. Stuff that matters.
Re:Elm in Production: 25K Lines Later by jnbiche on Monday July 31, 2017 @01:37PM (#14894206)
This is trivial to avoid with a linter (which is a good idea to use anyway with JavaScript). For Flow, there's an eslint plugin that allows you to raise an error on the use of any weak type, such as `any` [1]. I'd be very surprised if the same doesn't exist for TypeScript.

1. https://github.com/gajus/eslint-plugin-flowtype#eslint-plugi...

Re:Elm in Production: 25K Lines Later by Skinney on Monday July 31, 2017 @01:53PM (#14894373)
Cool! Does it enforce third-party libraries as well? A thing that typescript and/or flow doesn't support, is JSON. What if a JSON object doesn't match the type? This can cause sneaky bugs later :/

I'm not saying that typescript/flow is bad. Whenever I have to use node.js, I end up using typescript. But I've been bitten several times by the fact that typescript isn't as strict as Elm forces things to be.

Re:Elm in Production: 25K Lines Later by jnbiche on Monday July 31, 2017 @04:14PM (#14895505)
> Cool! Does it enforce third-party libraries as well?

Yes, as long as you lint those libraries, too.

> A thing that typescript and/or flow doesn't support, is JSON. What if a JSON object doesn't match the type?

That's why you do runtime validations of your incoming JSON if you feel like you can't trust the data (and if it's an external API, you probably can't). How is this different from Elm?

> But I've been bitten several times by the fact that typescript isn't as strict as Elm forces things to be

In my experience with Flow, between the Flow analyzer and accompanying linter, you can make it just about as strict as you want with respect to types. The main thing you'll miss (as discussed elsewhere) is that unlike Elm, there's no way to guarantee referential transparency with JS and Flow.

Re:Elm in Production: 25K Lines Later by Skinney on Monday July 31, 2017 @04:37PM (#14895686)
It's not different from Elm. My point was that Elm forces you to do it, there's no way around. With Javascript+Flow or TypeScript, you need discipline to end up with code that is as reliable as Elm.

Me, personally, I take short-cuts when I'm pressed for time, stressed, or in a bad mood (which happens more often than I'd like to admit). I can always improve the code later (which turns into never). In Elm, I can't cut corners (as easily). This makes me write better code using Elm, which in turn makes me happier.

You --can-- get the same experience with Javascript, but it does require more from you, the developer.