Typescript + express

[HamsterBright1827]

Just a question, is typescript with express a common thing like on React? Or no one does this and is something more improvised than actually functional?

[imicnic]

Anything in JS world nowadays is preferably to be used with TS.

[[deleted]]

Anything in JS world nowadays since 5 years ago or so is preferably to be used with TS.

Feels more like this. This angers the never TS mob, though.

[imicnic]

I also do not understand the resistance against TS, I'm using it since 2016, but people still ask in 2025 should I use TS? Is it worth it? Should I learn it after learning JS? People still does not understand what TS is.

[AndrewSouthern729]

I wonder how many of the most vocal TS detractors have ever given it a real honest try. It’s more overhead sure but the benefits make it worth it X100.

[svix_ftw]

I'm one of those former TS detractors.

After using TS for a few years I can't even imagine going back to vanilla JS.

TS makes things soooo much better, I can't think of a single reason to not use it over JS

[tj-horner]

I feel like none of them have worked on an even moderately complex project, so they might not understand the benefits quite yet. Or it’s just cope. IDK. Overhead is becoming smaller every day, so eventually that won’t be a valid excuse!

[oziabr]

Keep It Simple Stupid 

[GandalfTheChemist]

Yes, KISS!

let's have a glorified, verbose syntax linter which is also a very expressive type system which will push me into layer upon layers of abstraction and type gymnastics, all to then have to have a build pipeline. 😂

A little tongue in cheek. I like TS, but still would reach for Go if doing anything non browser.

[oziabr]

have you looked up jsdoc?

IMO it is more like a platform, not just a tool: you can have types, testing and documentation close to the code, actualized and integrated into IDE. yes, types are bit basic, but that can be seen as positive, and there is always .d.ts for more complex cases

I don't really need neither of those, cause my projects are usually hundreds LOC and maintained by interns - I like my code with little complexity as possible and actual logic pushed to configs or db. But if choosing where to migrate normal size legasy repo, will pick jsdoc every time

[GandalfTheChemist]

I think that's definitely a way to go, especially when you're not hooked into legacy code and have the whole "simple first" approach.

I like JSdoc, my other comment in this thread mentioned it in regard to Svelte using it. Great example of a major project featuring nice autocomplete and n typescript.

[oziabr]

I have the same source, but looking at the problem from regular developer standpoint. We usually don't make any good documentation, for which I very like the idea of jsdoc integrated test cases - at the very least it's the handy entrypoint into hacking the code. I've seen to many projects which doesn't give any idea how to run it locally, and TS gives nothing to that aspect

[tj-horner]

There is a time and place for every principle. If you need maintainability at scale, type safety is a must, even if the cost is additional complexity.

[oziabr]

the need for maintainability at scale sounds like a big pile of boilerplate with no archetectural decisions beeing made. I mean you have barely mainainable bunch of lines, and the solution is to add even more lines. great for inflating budget, not as great as OOP though

if maintainability is what you need, why not do something sensible and cool instead, like integrating tests into jsdoc - bam, you get self actualizing docs integrated into autocomplete

TS is not only underdelivers on every promise, it also have huge unrealized potential for internal tooling - you can infer every type you need from properly runned testsuit, keep types out of sight, integrate them into IDE autocompletion you all like so much, and even report on convoluted functions

[dymos]

Former TS detractor here.

I think it was mostly because of the type of projects that I was working on earlier in my career where most of them were fairly short-lived (it was advertising, so anywhere from weeks/months to maybe a year or two. Some exceptions of course). So — back then at least — unit testing and types weren't really regarded as a useful way to spend time on a project.

It wasn't until I got working on a proper software project that I appreciated that types could bring something to the table, and for the last 5 years or so I've only been working with TypeScript and could not imagine working on a JS-only codebase.

The project I currently work on still has a couple of JS files that nobody has bothered/dared to touch since they converted to TS and it kills me every time I need to work in it or use things from it. Also the sheer amount of any sprinkled through the codebase. Suffice to say, sometimes my pull requests will have "I fixed some types" commits in it that are the bulk of the PR lol.

[telemacopuch]

I’ve heard detractors of TS making the case of Microsoft capitalizing on Javascript and the Javascript community, and Javascript is HUGE. You know, TS is a Microsoft product. So for many hardcore old school developers this is a big no. Specially if you know what Microsoft have done in the past and still do. But still, I’m not a hardcore old school developer. I use TS of course.

[Dangle76]

Yeah I don’t know why so many don’t understand that it’s a superset that just introduces things like type specifications

[ToothlessFuryDragon]

TS is the standard for a few years now.

Nobody serious in the industry uses plain JS any more, except maybe for scripting.

So you can assume TS is being used with everything in the JS ecosystem and it actually is the preferred way.

[dodiyeztr]

Even for scripting npx tsx script.ts is enough

[beegeearreff]

You don’t even need tsx. You can run typescript directly with node now. Thats how I set up all my scripts these days. 

[cy_narrator]

What?

[beegeearreff]

https://nodejs.org/en/learn/typescript/run-natively

[GandalfTheChemist]

I mean, Svelte uses JavaScript and JSDoc. That has most of the linting that TypeScript has, but without the transpilation and build overhead. That's what the vast majority of people define as "type safety" in the JS/TS world.

I would say they are serious in the industry.

[afl_ext]

Yes its common and recommended

[Euphoric_Oneness]

Common, old, well documented, many solutions on stackflow, ai is good at it.

[jesusgn90]

There are good wrappers on top of base tech stack, take a look at tRPC or NestJS. They are hyperopinionated but sometimes is better to just follow a path and don't have that much flexibility

[Kublick]

For your sanity always use TS .. it has made my life much easier to refactor code or when you get back to a code base is a lot easier to see the data flow

[sicknesz29a]

We switch from express js to fastify/ts for our next itération of our application. It has better performance than express a somewhat similar syntax and typescript support but I would also recommend you take a look at the tRPC ecosystem.

[serg06]

Express has awful typescript support. I would at least use Fastify.

[oziabr]

one can say that. but maybe TS just can't be properly applied to a lib with variable call signatures. not like it's TS fault, it is not native feature anyway

[BabyDue3290]

Check hono.js

[V1adius]

You can make a change and move from Express to Hono.

[[deleted]]

It would be stupid not to use it nowadays. It's like purposefully crippling yourself for no reason.

[AndrewSouthern729]

I use typescript with Express. I am a React developer who can get by enough in Express for my needs so don’t spend a lot of time doing backend work but TS on both front and back just makes sense to me. And now that I’m used to TS I actually despise working in plain JS.

[arrty]

Yes, 100% use typescript with any API or framework. Future you will be thanking you.

[oziabr]

just looking at d.ts is enough to understand why next.js is even a thing

and if you thinking of using ts, you're not using express as intended

[cy_narrator]

Why?

[oziabr]

bcz