> Promise-fatigue

JavaScript actually handles async IO nicely, and I've never heard this term before (callback hell, yes). So promises and async/await sugar actually make it pretty nice.

> poor ecosystem

Ecosystem is fine, just don't jump on everything new. The well-known problem is standard library, it is indeed a problem, usually addressed with a mix of additional packages.

> For the extra tax you pay in terms of build pipeline

This pipeline is norm in the frontend development, so in case you have people proficient in tooling, it is not that high (of course, it is hard if you have Java developers).

> Typescript vs Javascript as if these are the only two possible options for web development

They are not, but the nice thing about it is that you can have almost the same tooling as on your frontend, if you have some sort of complex application. So that increases speed of development, and TypeScript gives you some sense of scalability.

Last part is that TypeScript can be adopted incrementally, while another languages will require complete rewrite (and different deployment, etc).

I actually just made the term up myself just then to describe my feelings about the fact that all of the methods in our service layer are just `await this(); await that(); await another(); //...` and so on. Please be aware that this post is describing my own experiences in back-end web-app development using Node. I feel I'm courting more controversy here, but if you're using `async/await` ad-nauseum your app might not actually be as async as you think it is. Of course this is a godsend compared to the callback hell that it replaced, but I can't help feeling that this is the right solution to the wrong problem. In my experience, most of the server-side applications I've seen written in Node are only practically asynchronous at the router level. Once you get into the controllers they tend to become entirely procedural and effectively completely synchronous. With the exception of the rare `Promise.all(...).then(...)`.... If you're using `await` on every single function call, it stops being syntactic sugar and just becomes more syntactic salt.

I completely disagree. Or rather I'd say if you're making a bunch of remote calls, and you need the results before taking the next step, then you're going to need to be doing something like this in any case. FWIW I feel a backend controller in Node is much easier to write, and to understand, with async/await than the equivalent patterns in Java.

As you put it, "Once you get into the controllers they tend to become entirely procedural and effectively completely synchronous" but that's because for most people it's far easier to think about a problem as a series of individual steps. Even then, if you have a bunch of serial awaits it's usually pretty trivial to go back and then await on a Promise.all() if you realize things can be run concurrently.

> easier to think about a problem as a series of individual steps

You sound like we can be innovative on how we code but how can steps that do

- Parse inputs

- Query database

- Return output

be asynchronous?

Unless I'm writing a background job that is decoupled from HTTP requests, everything after the router is synchronous.

I think I might not have explained myself too well up there. I was referring to entirely sequential async calls. Like: ``` Thing thing = await loadThing(); Thing other = await thing.doSomething(); thing = await saveThing(); // repeat x1000... ```

I see this over and over.

And what exactly is the problem with that?

"Thing thing = await loadThing(); ": Start loading thing, then await so the main thread can continue doing other stuff while thing is loaded.

"Thing other = await thing.doSomething();": Invoke some other function that does some stuff in the background, then await so the main thread can continue doing other stuff while thing does something.

"thing = await saveThing();": Saving can often be done in parallel so no need to block the App while something is saved. Invoke the save function, then await so the main thread can continue doing other stuff while thing is saved.

This gets you the advantages of async programming while still maintaining a legible coding style that looks similar to common synchronous code.

we have await this() and await that() also in python aiohttp and we will have in C++ co_wait this() and co_wait that() and we have in C# await this() and await that() this is not something specific to JS / Typescript...

I never mind writing out the awaits. But that might be because I remember what writing asynchronous code was like 10 year ago and damn await is nicer.

I agree. Everything should be synchronous unless stated otherwise. The amount of 'await' and 'async' appearing is almost on every few lines but that is Node.js' problem, not TS'.

I think most people think async/await gives them all the previous benefits of async but doesn't

All the previous benefits of async? Did you mean promises, callbacks or async? async/await is just syntax sugar over promises.

What benefits don't we get with async/await?

Other langauges can be adopted incrementally as well e.g. ReasonML and Clojurescript. I am not sure how you concluded that other languages need a different deployment. On the front end everything gets delivered to the browser...

I am not sure about other languages, but I have been programming in Java for many years, and Typescript does what Java does (minus performance on a long running VM on CPU bound computations) at a rate that I assume should be sufficient for most (business) apps, without any bloat.

Can you elaborate on promise fatigue. In our setup we use async/await and the latest ES (although most of us prefer not using decorators if we don't have to - only used it with mobx for UI code) bundled through webpack.

I am not sure what you mean by poor eco-system either. Both JS and TS (increasingly), I feel like is the second best eco-system (in terms of libraries and tooling) after a mainstream language like Java.

There are some warts I think in JS (around numbers, stream handling in pipes), but I think very few languages don't, and it depends on how likely you would be fiddling in those areas.

Extra tax on build pipeline cannot be escaped for anything with any complexity.

I feel like anyone who can write a complex app in good js, refactoring along the way at good speed, and meeting deadlines along the way and not introducing too many regressions, and come back and maintain it after a 6 month context switch, either has way too much time on his hands and/or works too many hours, or is much more smarter than I am and has it figured out.

I've had too many terrible experiences having to maintain and work with buggy and poorly designed Node/Typescript packages. I'm especially thinking of the terrible choice of ORMs available for Node, Typescript in particular. TypeORM seems the de-facto standard and my experiences with it have been horrific. It looks like Hibernate but works like a dumpster fire. There isn't anything as robust as ORMs like EF or Hibernate for Node. I feel that the shortcomings of the NPM community have been pointed out one too many times, but on too many occasions I've felt that development of a product was made much harder by the choices of poorly developed frameworks as dependencies.

FWIW I've helped a team of Java developers transition to Node and the first questions I got were usually about standard library and hibernate. One guy was quite convinced that the NPM world just needed a reimplementation of Apache Commons to see the value in monolithic packages. I also had to do a lot of explanation about strategies for code reuse without inheritance/turning everything into classes.

These are all, at the end of the day, XY-style problems whose suboptimal answers can snowball into unmaintainable code. I do think there is a serious lack of training material in this area, though.

The ORM was your first mistake. They almost always get in the way and are way more complex than the relatively simple language (SQL) they are intended to abstract over.

> performance on a long running VM on CPU bound computations

I'm interested in learning more about this, any other keywords I should throw in if I start Googling about it?

True, because you cannot avoid JavaScript. If you are building a new web startup, most likely you are going to write a LOT of React/frontend code.

So it makes absolute sense to write the backend in the same language...if you can. Typescript goes a long way in making this pleasant.

Nothing is stopping you from writing the backend in different language...but as an organization, you lose the advantage of shared thinking in one stack.

Part of the appeal of TypeScript is that you could fairly easily migrate a team to it from JavaScript if they're all fairly comfortable and competent with the current JS ecosystem. For most JS devs I've worked with, this wouldn't be true with a language like C# or Kotlin.

I'd argue that buying into a more comprehensive language would probably be worth it if everyone was into it, but in my own experience JS devs really, really like JS and have very little interest in learning something better suited to the problem they're solving. This is true outside of software too. People love familiar tools and methods, even if they aren't the best ones.

There's also the fact that your team's output will be best based on their enjoyment and engagement. Even if the tooling isn't perfect, they'll probably build better software if they're enjoying it. JS and TS are good enough in most cases to get teams where they need to be.

What other languages would you recommend for frontend web development, given that you'll still need a build pipeline and so on?

My post was directed at back-end development in Typescript/Javascript. My apologies if that wasn't clearer. I don't really have any experience in front-end development in Typescript, so I can't really comment on that. It could be a real improvement there for all I know.

While your parent clarifies that he meant for backend- ill suggest trying one off bucklescript, Scala.js or elm. They are all very well done and have wide adoption actually

" Issues like Promise-fatigue"

Actually, async-await is a nice feature of the JS paradigm that simplifies things and that I miss in the threaded world of Java.

But yes - use TS where you would have used JS, but TS up against other, more classical languages may not be the right choice for a lot of non-web projects.

Yeah, it's a strength in my book. Node makes it trivial to sequence asynchronous tasks, stuff you may be juggling in a server route.

You can start this promise early, await two parallel DB request + one API request, branch off some more async work depending on a response, await that initial promise that had a head-start because now you actually need it, and then run 10 tasks with no more than 3 in-flight at a given moment. And the code would look exactly how I just described it. And it's ubiquitous.

It's a good tool in the belt and imo the most trivial async implementation out there.

I'm just jumping into TypeScript after a decent break from production coding. Prior to this break it was Rails, well before that Java.

In my own Hades moment -- Microsoft know how to build great developer tools. The developer ergonomics of TypeScript and Visual Studio Code are excellent. It's really quite surprising to see how far the JavaScript world has come.

Similarly, the DevOps world is becoming much (much) more JavaScript friendly. Serverless, Netlify, and things like AWS Amplify -- all with their foibles, but pushing JavaScript in meaningful ways. I don't think this is the case for many other languages/ecosystems.

I would actually agree with your statement about Typescript and vscode. Working with TS has actually been quite pleasant as far as getting up and running goes. I only ever had to consult the docs a handful of times, and each time my questions were easily answered.

Poor ecosystem? Have you used web frameworks like Express/Koa + a good linter + a modern IDE (e.g. VS Code) and of course npm? It's a breeze working with those tools. Productivity skyrockets and if you think a little bit about your design decisions then typescript (plus the proper support for it) gives you a huge hand in writing correct code from the first try. I think that if you want your opinion to be taken seriously you should propose an alternative. I would be interested to see a better ecosystem.

That's why there are compile-to-Js languages that see widespread adoption.

Elm, bucklescript, Scala.js to name a few.

... Clojurescript. A React app is 10x more complicated than a Reagent app. http://reagent-project.github.io/

In the following code segment, the `[:div` `[:p` et al- are the reagent or clojurescript?

```

  (defn simple-component []

    [:div

     [:p "I am a component!"]

     [:p.someclass

      "I have " [:strong "bold"]

      [:span {:style {:color "red"}} " and red "] "text."]])

```

Other than Ruby and PHP, I've only really worked with JS/TS on the backend. Which strongly-typed programming language would you recommend on the backend?

Depending on what it is you're doing, I feel that .net and Java are far superior choices. Obviously these are pretty heavy languages, so obviously decide for yourself whether the size of your app justifies using a language like this. My thoughts run along the lines of: "If people are justifying using Typescript because their projects are large and critical, they're probably large and critical enough to use a language designed for enterprise-scale development." I personally haven't used Go, but I've heard good things about its use in this domain too.

I would like to second this. This idea that everything will move more quickly if the same language is used on the client and server sides is compelling. But .Net or Java have been on the server side a long time, there are projects for which they are well suited.

TypeScript is very easy to use with Node. You can also use the debugger in WebStorm with it just fine, and you'll be stepping through your TS code instead of your generated JS code.

The problem is really the Node ecosystem, which is a mess and a circus of security issues. Deno[1] may fix most of JS/Node's problems eventually.

For now, if you want a type system that's comparable to TS with a great ecosystem, the best you can get is either F# or Kotlin. If you're not a fan of ML, then you might want to start with Kotlin.

1. https://github.com/denoland/deno