I don't think web vs non-web makes a difference for whether or not you should choose a type-safe language. IMO, you should err toward type safety whenever possible. It's way nicer for your toolchain to catch errors before a user does.
Even PHP is moving in that direction. If the PHP community can embrace type safety, I'm certain that you can :)
If I am comfortable with a more powerful typed language, it can do so much of the heavy-lifting for me, i.e: I used PureScript for a toy project and using type-directed search and type-safe routing and json deserialization was awesome.
I would put Elm and ReasonML/Ocaml into simmilar bucket (maybe even haskell with ghcjs and its reflex-frp library :)
On the other hand I would rather write pure javascript than try to compile golang to wasm (even though I know of people that are happy with that :)
I have no strong opinion on typescript.
Disclaimer: I have never had to maintain any web-page I wrote, all of them were toy project and I writhe python and go backend-services at work :D
6 comments
[ 3.4 ms ] story [ 38.9 ms ] threadEven PHP is moving in that direction. If the PHP community can embrace type safety, I'm certain that you can :)
So I guess that indirectly has an effect on the webapp, but your users will not care what tech stack you use.
If I am comfortable with a more powerful typed language, it can do so much of the heavy-lifting for me, i.e: I used PureScript for a toy project and using type-directed search and type-safe routing and json deserialization was awesome.
I would put Elm and ReasonML/Ocaml into simmilar bucket (maybe even haskell with ghcjs and its reflex-frp library :)
On the other hand I would rather write pure javascript than try to compile golang to wasm (even though I know of people that are happy with that :)
I have no strong opinion on typescript.
Disclaimer: I have never had to maintain any web-page I wrote, all of them were toy project and I writhe python and go backend-services at work :D