Thanks for the tip! I’ll double check that when I get back to work next week.
I’ve written a lot of NodeJS apps in vanilla JS, and plenty of .NET backend stuff too. The transition to serious TS has been relatively recent. I like it alright, but dislike the added complexity that comes with all the various config files - vanilla JS has enough of that already!
I’m a former .NET dev … I stopped quite a few years ago after I joined a Bay Area company. It was quite a change. React 1 was just coming out and I used to just write bad JS on my webpages and I had to rewrite our front-end in React. Also, ES5 or 6 or whatever was getting popular and we had to transition from CoffeeScript.
The JS world gave me whiplash after doing so many years of Enterprise .NET. The .NET tools felt so much more polished.
The fundamentals of Node to me were different than .NET. .NET felt like it had a lot more cruft and “magic” at first. With Node it felt deceptively simpler at first. Then when the require syntax was going away and we had imports but then it wasn’t a real import. It was a TypeScript import or a webpack import that did a require behind the scenes. Then I had to understand why we used typescript but then what was the point of tsc vs babel vs webpack vs esbuild what their roles were and I kind got a bit obsessed with understanding what they did and what was happening under the hood. Then Node officially did do import and I had to understand what that was all about and how it affected our compilers or bundlers.
Sorry I rant pointlessly. Godspeed on your journey!
In this industry where we are all a little afraid to admit that we don’t know something, it’s nice to be reminded that everyone is always learning all the time and that there’s no way any of us can know everything.
I’m enjoying the learning process, despite its paper cuts, and love where I work. I enjoy TS itself but I do wish the process of setting up a new project/config stuff were more streamlined. Maybe in the future!
Btw, you probably already know this, but if you don’t. The later versions of Node can run typescript natively. By “run”, I mean, it can run a subset of the language, if your project indirectly or indirectly references a file that has “decorators” or something like that, then you’ll need to use another compiler.
ts-node or tsx are runners that I use typically if I just want to “run” something. They’re basically zero config runners and I can debug with them with VS Code.
Oh, they are included in the build. But I still get error messages that don’t actually point to the line in the TS source file sometimes.
Maybe I have something configured wrong - TS projects always include a more config files of different kinds than I see in other languages I work in - but it happens.
If it’s only rarely, it might just be some dumb caching issue, or it can be a build ordering issue. Like you have to be careful in Rollup configs or some tasks will mangle the code before a sourcemap is generated. Otherwise iirc it may have to be turned on in browser settings, though hopefully they’re on by default these days.
It’s surprisingly good as a backend language, if you don’t really need OOP all that much. The perfect case is probably using it in microservices that only really need to do a bit of data manipulation and some database interfacing.
I’ve had pretty good experiences with it even situations with moderate data manipulation. There are some tricks you can use to engage different phases of the event loop to keep the data processing from blocking too much.
It’s still not as good as Java/C#/Go, of course, but it can help get some more performance out of Node.
This happens all the time with TypeScript. The transpiled JS that actually runs will naturally have different line numbers than the TS you wrote!
To be fair, the reported line number is usually close enough that I can find the issue without much trouble.
It’s not my favorite back end language, but it’s what everyone on my team knows…
This is what source maps are for. With the right tools you can debug the original source instead of the minified version.
Remember to add --enable-source-maps and as long as your tools are configured properly it should point to the right line!
Thanks for the tip! I’ll double check that when I get back to work next week.
I’ve written a lot of NodeJS apps in vanilla JS, and plenty of .NET backend stuff too. The transition to serious TS has been relatively recent. I like it alright, but dislike the added complexity that comes with all the various config files - vanilla JS has enough of that already!
I’m a former .NET dev … I stopped quite a few years ago after I joined a Bay Area company. It was quite a change. React 1 was just coming out and I used to just write bad JS on my webpages and I had to rewrite our front-end in React. Also, ES5 or 6 or whatever was getting popular and we had to transition from CoffeeScript.
The JS world gave me whiplash after doing so many years of Enterprise .NET. The .NET tools felt so much more polished.
The fundamentals of Node to me were different than .NET. .NET felt like it had a lot more cruft and “magic” at first. With Node it felt deceptively simpler at first. Then when the
requiresyntax was going away and we hadimportsbut then it wasn’t a realimport. It was a TypeScriptimportor awebpackimport that did arequirebehind the scenes. Then I had to understand why we usedtypescriptbut then what was the point oftscvsbabelvswebpackvsesbuildwhat their roles were and I kind got a bit obsessed with understanding what they did and what was happening under the hood. Then Node officially did doimportand I had to understand what that was all about and how it affected our compilers or bundlers.Sorry I rant pointlessly. Godspeed on your journey!
No worries on the ranting!
In this industry where we are all a little afraid to admit that we don’t know something, it’s nice to be reminded that everyone is always learning all the time and that there’s no way any of us can know everything.
I’m enjoying the learning process, despite its paper cuts, and love where I work. I enjoy TS itself but I do wish the process of setting up a new project/config stuff were more streamlined. Maybe in the future!
Yeah, absolutely agreed.
Btw, you probably already know this, but if you don’t. The later versions of Node can run
typescriptnatively. By “run”, I mean, it can run a subset of the language, if your project indirectly or indirectly references a file that has “decorators” or something like that, then you’ll need to use another compiler.ts-nodeortsxare runners that I use typically if I just want to “run” something. They’re basically zero config runners and I can debug with them with VS Code.Yeah, I’ve read about the development of the ability to run TS natively in Node. It sounds really promising!
I’m not familiar with ts-node though. I’ll have to check that out.
Well sure. But the error messages don’t point to those, which was what had me chuckling about this meme.
They would point to the right lines if source maps were included in the build.
Oh, they are included in the build. But I still get error messages that don’t actually point to the line in the TS source file sometimes.
Maybe I have something configured wrong - TS projects always include a more config files of different kinds than I see in other languages I work in - but it happens.
If it’s only rarely, it might just be some dumb caching issue, or it can be a build ordering issue. Like you have to be careful in Rollup configs or some tasks will mangle the code before a sourcemap is generated. Otherwise iirc it may have to be turned on in browser settings, though hopefully they’re on by default these days.
Wait you said back end…
It’s surprisingly good as a backend language, if you don’t really need OOP all that much. The perfect case is probably using it in microservices that only really need to do a bit of data manipulation and some database interfacing.
I’ve had pretty good experiences with it even situations with moderate data manipulation. There are some tricks you can use to engage different phases of the event loop to keep the data processing from blocking too much.
It’s still not as good as Java/C#/Go, of course, but it can help get some more performance out of Node.
You are familiar with NodeJS, yes? 👍
It’s a really popular choice and has been for the few years.