I think TypeScript on the frontend and JavaScript on the backend is workable. Most modern frontend frameworks are TypeScript-native, and you really benefit from a lot of the hand-holding that the real-time static analysis + your framework extensions in VSCode provide.
On the other hand, in most cases backend code is dumb and simple; in basically every company I’ve worked for it’s an API that just does CRUD stuff through an ORM to the database. There’s not a whole lot that can go wrong if you keep package dependencies light and JavaScript is just a simpler option. You can even use a basic text editor if you’re a real pro.
I disagree with the article that it’s such a vastly different build environment or developer required. Different tools for different jobs works fine for me.
Writing JS/TS for browsers and backend applications is an entirely different skill. The only similarities are syntax. From the organization's perspective, the developer's primary expertise is a platform/framework, not a language syntax.
The point of the article is right for the indie developer who wants to stick with one language as a "mother language" and be able to produce any kind of software in no time. For scale, it is not the case.
I'm a big fan of JS/TS, but there are absolutely significantly better choices for many backend applications.
Having over 30 years of experience in delivering applications this is kind of amusing in how it shows how trends come and go. In the past dynamic typing was hot stuff that enabled great progress. Here we have another big trend.
It can be useful, but it seems like just more preference. The reason that strong typing is useful is that development groups have weak definitions and understandings of their data flow, their documentation is scant if it exists at all, and their test are woefully short of robust. So strong typing ends up being necessary, especially when developing always at top speed with chaotically dynamic teams. But unfortunately, the fact that you think you know what type some data is doesn't really tell you all you need to know about where it came from, how sure you can be it really is that type, and how you can know it is the specific data that you want for your business logic. It helps, but to really get development under control it will be necessary to define, document, and test data flows to a level that makes strong typing unnecessary and potentially even irrelevant.
When I hear this kind of statement from a developer I know that they are better at clinging to what are essentially religious beliefs than they are at coding solutions that will be consistently useful for users.
I don't disagree with the general premise of this post, but:
> Two different types of engineer your company has to hire for
That's going to be the case anyway. React and front-end work in general has gotten pretty damned specialized; if you want your front-end to look good, to work well, to be responsive, and to not be a garbled mess, you're going to need people who specialize in front-end work.
> A third API language to serve as an interface between frontend and backend (GraphQL, REST, SOAP, pick your poison)
You're going to need this regardless. And pretending that https://trpc.io/ (whatever it is) is somehow different from GraphQL, REST, etc in terms of having to learn a technology is a joke that doesn't land.
If your web app has a complex build environment, which will happen with Typescript and React as the author proposes, you already did it wrong. Have fun with that.
Do what works for you, then learn to distinguish between your own opinions, preferences, and limited experience on the one hand and universal rules and so-called best practices on the other. Typescript and React amount to a blip on the landscape of web applications, most of which got written in Java, C#, and PHP before those supposedly better tools came along.
I feel a little bad for the generation of web developers who started with TS and React and now have to wedge everything into those buckets and disregard everything else, either out of ignorance or ideological stubbornness.
On the other hand, in most cases backend code is dumb and simple; in basically every company I’ve worked for it’s an API that just does CRUD stuff through an ORM to the database. There’s not a whole lot that can go wrong if you keep package dependencies light and JavaScript is just a simpler option. You can even use a basic text editor if you’re a real pro.
I disagree with the article that it’s such a vastly different build environment or developer required. Different tools for different jobs works fine for me.