4 ms·

I've avoided JS/TS almost entirely, and shown contempt toward it a bunch in the past. I'm now at a place where TS seems like a reasonable language for prototypi

I've avoided JS/TS almost entirely, and shown contempt toward it a bunch in the past. I'm now at a place where TS seems like a reasonable language for prototyping backend stuff: JS has a GC, big package ecosystem, sum types, static typing, good tooling support. Only thing that ticks most of those boxes (IMO) is Kotlin. Anyone been down this road before (skeptic->using in prod)?

hot_gril 3y ago
I used to avoid JS then tried it for backend stuff, finding it actually the easiest way to do web backends. Most off-putting thing was the "callback/promise hell" erroneously recommended in tutorials until I realized you're actually supposed to use async-await. Then React Native instantly converted me from the horrible native iPhone dev, then got me into React (web). So I'll do new app projects fully in JS. I also gave TS a serious try and found it pointless. Complicated the toolchain, made default stuff like the Node profiler not work anymore, and wasted tons of time on defining types that didn't actually catch any mistakes. Went back to JS. Turns out part of its strength comes from not caring. Before that had used Java, Scala, C, C++, Erlang, Python, Swift, ObjC, Rust, PHP, and a little Golang.
- yamtaddle 3y ago
  > Most off-putting thing was the "callback/promise hell" erroneously recommended in tutorials until I realized you're actually supposed to use async-await Async/await's pretty new, is probably why you're seeing so many tutorials that don't use it.
  - hot_gril 3y ago
    Yeah, but even new documentation sometimes uses promises, particularly anything related to Google like https://firebase.google.com/docs/auth/web/custom-auth https://firebase.google.com/docs/auth/web/custom-auth
    - yamtaddle 3y ago
      The page has a 2023 last-edited on it, but the code snippet (if you follow the GH link) hasn't been touched in two years. If their JS docs are anything like their Android docs, Google's terrible about updating examples.
      - hot_gril 3y ago
        async/await is still pretty old by now. Maybe they wanted to be consistent with even older examples. I dunno, every single thing Google-related uses promises, so I'm thinking they're partial to that for some reason. Another example from 4mo ago: https://github.com/kubernetes-client/javascript/blob/master/examples/ingress.js https://github.com/kubernetes-client/javascript/blob/master/... (the catch at the end is a promise catch)
        WorldMaker 3y ago
        There's a tiny benefit of the doubt to be given here that while async/await is several years old, support for "top-level await" was only more recently standardized and took too long for common LTS versions of Node to also support it. All of these examples appear to be top-level and perhaps they didn't want to write them as async functions or IIFEs, especially for error-handling code.
        hot_gril 3y ago
        That makes sense, someone copy-pasting async code into a JS console would get errors not too long ago. There's nobody to blame for this but myself, just wish I discovered earlier on how async/await works, along with other modern JS stuff that you won't see everywhere because it's new.
steve_adams_86 3y ago
Dart appears to tick some of those boxes, but probably not the big package ecosystem and sum types boxes. I'm considering building something with it at the moment, but I'm hesitant to commit much brain power to something Google has a lot of influence over. Yet, Go has been awesome and I don't regret learning it. In some ways, Dart looks a bit like what I wish TypeScript could be, though not exactly. Something I use a lot in Rust is exhaustive matching and sound types, which Dart now has. It's a somewhat specific thing, but I like designing finite, well-scoped systems which can be handled and tested almost completely. Doing this in TypeScript is kind of possible but can be incredibly verbose and difficult to navigate for less experienced programmers. While the design patterns aims to simplify and eliminate errors, the type system can easily complicate it and introduce mistakes. That's such a drag in my experience. For example, stuff like this can happen in TypeScript: https://www.typescriptlang.org/play?ts=5.1.0-beta#code/GYVwdgxgLglg9mABAWwKYGd0FUAOAVAC1QEEAnUgQwE8AKC8gLkTMqoB50pSYwBzRAD6IwIZACNUpAHwBKJgDc4MACaIA3gFgAUIl2J6pAHQ4Q6AjQDMMgNzaAvtu0QEnRJ2590TFtQ5cevFKIALyIANoA5MBwcBEANIgRYvQRALq2WmiYuIQk5NQ07gHoNo5azmCuXm7+fCE1HrzoYQBM6U4ucAA2qIZdcLyFhlBwADJwAO6SAMIU6Kg0MjLaQA https://www.typescriptlang.org/play?ts=5.1.0-beta#code/GYVwd... However, TypeScript has come a long way and it gets better in this regard all the time.

hot_gril 3y ago

I used to avoid JS then tried it for backend stuff, finding it actually the easiest way to do web backends. Most off-putting thing was the "callback/promise hell" erroneously recommended in tutorials until I realized you're actually supposed to use async-await. Then React Native instantly converted me from the horrible native iPhone dev, then got me into React (web). So I'll do new app projects fully in JS. I also gave TS a serious try and found it pointless. Complicated the toolchain, made default stuff like the Node profiler not work anymore, and wasted tons of time on defining types that didn't actually catch any mistakes. Went back to JS. Turns out part of its strength comes from not caring. Before that had used Java, Scala, C, C++, Erlang, Python, Swift, ObjC, Rust, PHP, and a little Golang.

yamtaddle 3y ago
> Most off-putting thing was the "callback/promise hell" erroneously recommended in tutorials until I realized you're actually supposed to use async-await Async/await's pretty new, is probably why you're seeing so many tutorials that don't use it.
- hot_gril 3y ago
  Yeah, but even new documentation sometimes uses promises, particularly anything related to Google like https://firebase.google.com/docs/auth/web/custom-auth https://firebase.google.com/docs/auth/web/custom-auth
  - yamtaddle 3y ago
    The page has a 2023 last-edited on it, but the code snippet (if you follow the GH link) hasn't been touched in two years. If their JS docs are anything like their Android docs, Google's terrible about updating examples.
    - hot_gril 3y ago
      async/await is still pretty old by now. Maybe they wanted to be consistent with even older examples. I dunno, every single thing Google-related uses promises, so I'm thinking they're partial to that for some reason. Another example from 4mo ago: https://github.com/kubernetes-client/javascript/blob/master/examples/ingress.js https://github.com/kubernetes-client/javascript/blob/master/... (the catch at the end is a promise catch)
      - WorldMaker 3y ago
        There's a tiny benefit of the doubt to be given here that while async/await is several years old, support for "top-level await" was only more recently standardized and took too long for common LTS versions of Node to also support it. All of these examples appear to be top-level and perhaps they didn't want to write them as async functions or IIFEs, especially for error-handling code.
        hot_gril 3y ago
        That makes sense, someone copy-pasting async code into a JS console would get errors not too long ago. There's nobody to blame for this but myself, just wish I discovered earlier on how async/await works, along with other modern JS stuff that you won't see everywhere because it's new.

steve_adams_86 3y ago

Dart appears to tick some of those boxes, but probably not the big package ecosystem and sum types boxes. I'm considering building something with it at the moment, but I'm hesitant to commit much brain power to something Google has a lot of influence over. Yet, Go has been awesome and I don't regret learning it. In some ways, Dart looks a bit like what I wish TypeScript could be, though not exactly. Something I use a lot in Rust is exhaustive matching and sound types, which Dart now has. It's a somewhat specific thing, but I like designing finite, well-scoped systems which can be handled and tested almost completely. Doing this in TypeScript is kind of possible but can be incredibly verbose and difficult to navigate for less experienced programmers. While the design patterns aims to simplify and eliminate errors, the type system can easily complicate it and introduce mistakes. That's such a drag in my experience. For example, stuff like this can happen in TypeScript: https://www.typescriptlang.org/play?ts=5.1.0-beta#code/GYVwdgxgLglg9mABAWwKYGd0FUAOAVAC1QEEAnUgQwE8AKC8gLkTMqoB50pSYwBzRAD6IwIZACNUpAHwBKJgDc4MACaIA3gFgAUIl2J6pAHQ4Q6AjQDMMgNzaAvtu0QEnRJ2590TFtQ5cevFKIALyIANoA5MBwcBEANIgRYvQRALq2WmiYuIQk5NQ07gHoNo5azmCuXm7+fCE1HrzoYQBM6U4ucAA2qIZdcLyFhlBwADJwAO6SAMIU6Kg0MjLaQA https://www.typescriptlang.org/play?ts=5.1.0-beta#code/GYVwd... However, TypeScript has come a long way and it gets better in this regard all the time.