My issue with typescript… and, correct me if I’m wrong… is it doesn’t exist without Javascript. Typescript needs to be compiled down into Javascript to be run. It has no stand alone interpreter (that I’m aware of) and definitely not one baked into web browsers or NodeJS (or adjacent) tools. In essence, Typescript is jank sitting on top of and trying to fix Javascript’s uber jank, simultaneously fracturing the webdev space while not offering itself as a true competitive and independent language for said space.
I really don’t get how people can feel more productive in JavaScript. With typescript the code practically writes itself. Sometimes when refactoring I’ll change a functions input and output signature and just fix compiler errors until it stops complaining, and the code just works without me having to really even think about what the code is doing.
Any time I’m forced to go back to js I feel like I’m going crazy trying to keep track of what’s in all the variables. With typescript I can use more powerful object structures without having to constantly double check where they came from.
I’ve never worked with it and don’t know in detail, but it lets you compile several languages into web based client/server code (basically, converting other languages into website code). Works with C, C++, C#, Go, Rust, Swift, etc)
I don’t think it really fractures anything considering you can call a ts package from js without knowing. The other way also works with third party typings in DefinitelyTyped.
It really just adds a bit of extra type info into js, looks like js, and transpiles into js that looks almost exactly like the input, including comments and spacing and such if you like, so there isn’t any lockin.
There isn’t any competition, it’s just an extra optional tool for the js ecosystem in my eyes.
The transpilation that typescript does doesn’t really have anything to do with typescript, it’s just there because typescript wants to support the latest ecmascript features, so transpilation is necessary for that, but technically you could simply strip out the type info and have another transpiler like babel handle the backwards compatibility. I think there are a few minor exceptions to that, like enums. There was even a proposal to add some typescript types to native JavaScript that would be ignored by the interpreter and just act as comments.
I mean, tsc without any of the backporting functionality is still a transpiler since it goes from a high level language(ts) to another high level language(js). Transpilation as a concept doesn’t imply that it is for backporting language features or that the source and destination languages are the same, just that it is a transformation from source code to a similar or higher abstraction level language source code
Yes, it’s still a transpiler, I’m not saying it isn’t, but what I mean is that it doesn’t add any functionally specific to the typescript language. There’s a transpiler for TS that doesn’t even do any type checking at all and just does the type stripping and back porting. But of course, that’s not why people use typescript. All the features that are actually important to typescript could be done through a linter instead. If type annotations were added to JavaScript you could get most of typescript’s features with linting rules and just handle back porting in a more standard way.
V8 also doesn’t run js, it does some byte code compilation stuff amongst other things, then interprets that. But that’s all a bit pedantic too, V8 runs js, deno runs ts.
fwiw deno.com even has as one of their first bullet points that they have “native support for TypeScript and JSX”
As a professional with 25 years of experience I agree with you. The entire modern architecture was created by people who don’t like simple things that work. I’m pretty sure there are a couple of high ranking master developers sitting at the head of W3C competing to create the most convoluted system possible.
I’m a hobbyist. I don’t work on really large or complex projects. I just want to get the most productivity for my spare-time-dabbling and having tried a few times to get into typescript it seemed to create more “extra steps” for me than it saved.
I’ve used JavaScript since its creation. I would describe typescript as JavaScript as it should have been. I’ve always actually liked JavaScript’s simplicity, but I’ve never liked its lack of type safety. At its core, JavaScript has a tiny conceptual footprint, and that’s actually pretty refreshing compared to other very complicated languages. But it was plagued with terrible implementations and the inherent messiness of dynamic typing. I’ve watched it evolve over the years and it’s improved beyond my greatest hopes. Between the advent of transpilation, tooling, and typescript, I’m very proud of where the language has gotten to. Having made websites in the 90s and 00s, I feel like people don’t realize how much work has gone into getting the ecosystem in a much better place.
Typescript doesn’t have strong typing but static typing still gets you really really far. It means you need to be more careful with your io and avoid dangerous type assertions, but I don’t think that’s a bad thing. Having used typescript an absolute ton, the only real jank I’ve encountered is from bad library typings that either use it lazily or incorrectly, but for code bases that use it through and through it has been smooth sailing, and having professionally used both traditional static typed languages and dynamically typed languages, I really enjoy typescript’s type inference and structural typing. I think you should give it an honest try before judging it. But that’s just my 2 cents as an industry professional who has used many languages and have been programming for decades for what it’s worth.
javascript but more for philosophical reasons. when projects use typescript they always get focused on writing more scripts rather than optimizing HTML/CSS. Too many times I’ve seen overly complex scripts trying to solve what a properly arranged div and css tag have already solved.
I’ve been dealing with this at my job because a layout library was deprecated and is used throughout our codebase instead of proper css. Came to learn that my whole team doesn’t like/know css, so they used this library that used angular directives in the html instead. We had multiple giant scripts for arranging elements in a grid that changed based on screen width
There are many cases where this is a serious issue that can't be solved through pure CSS. Once container units are finally approved though, that will solve quite a few problematic layout issues in CSS.
I haven’t managed to break into the JS-adjacent ecosystem, but tooling around Typescript is definitely a major part of the problem:
following a basic tutorial somehow ended up spending multiple seconds just to transpile and run “Hello, World!”.
there are at least 3 different ways of specifying the files and settings you want to use, and some of them will cause others to be ignored entirely, even though it looks like they should be used.
embracing duck typing means many common type errors simply cannot be caught. Also that means dynamic type checks are impossible, even though JS itself supports them (admittedly with oddities, e.g. with string vs String).
there are at least 3 incompatible ways to define and use a “module”, and it’s not clear what’s actually useful or intended to be used, or what the outputs are supposed to be for different environments.
At this point I’m seriously considering writing my own sanelanguage-to-JS transpiler or using some other one (maybe Haxe? but I’m not sure its object model allows full performance tweaking), because I’ve written literally dozens of other languages without this kind of pain.
WASM has its own problems (we shouldn’t be quick to call asm.js obsolete … also, C’s object model is not what people think it is) but that’s another story.
At this point, I’d be happy with some basic code reuse. Have a “generalized fibonacci” module taking 3 inputs, and call it 3 ways: from a web browser on the client side, as a web browser request to server (which is running nodejs), or as a nodejs command-line program. Transpiling one of the callers should not force the others to be transpiled, but if multiple of the callers need to be transpiled at once, it should not typecheck the library internals multiple times. I should also be able to choose whether to produce a “dynamic” library (which can be recompiled later without recompiling the dependencies) or a “static” one (only output a single merged file), and whether to minify.
I’m not sure the TS ecosystem is competent enough to deal with this.
This last part sounds nice in theory, but it’s way outside the scope of what Typescript is intended to accomplish. I’ve been pursuing a similar goal on and off for 10+ years at this point, I even wrote an ORM for Backbone.js so I could use it on the server as well. Back then we called it Isomorphic Javascript, later on it got renamed to “universal javascript”, nowadays I’m not sure.
But yeah, the problem is similar with any code, really… What you’re often writing in software dev is just functions, but the infrastructure required to actually call said function is often not trivial. I agree it’d be nice to be able to have different “wrapper types” easily, but I’m afraid their usefulness would be limited beyond toy projects.
How can you even form an opinion on this if, as you stated in that thread, you literally have no idea what typescript is and are just a beginner in js? You got down voted for saying typescript is unnecessary without even knowing what it is or what the thing you’re working with’s limitations are, which is a pretty objectively braindead stance to take. You’re a beginner js developer, you have no idea what you’re talking about when it comes to preferences of ts vs js, just that all of the beginner level stuff you have tried to do works in js so therefore typescript or frameworks must be unnecessary
if you’re a beginner, and you post an opinion and lots of people say that many years of professional experience make them disagree with you, why would you not take that on board? I wish you well on your learning journey. at some point you’ll outgrow vanilla js and you’ll have learned enough to configure transpilation and webpack etc. it’ll be a good day.
The fact that you're doubling down on your ignorance is quite problematic. Typescript is not an enterprise system that forms arcane JS. It's literally JS with a slight adjustment that allows you to say "also this is this type". You write JS the entire time and can "disable" the typescript at any location you need to not be typed.
After this and saying that you’re a beginner to JS, I would instead suggest spending time to develop perspective from a place of knowledge and experience rather than… I guess, being proudly ignorant?
Typescript may have a million problems that make getting into it annoyingly hard and even seem pointless, but once it’s settled in your project and used well… Damn is it fucking good.
And I’m saying that even though I had to disable intellisense and most of those advanced features because the project I work for is too large and typescript would easily use over 20GB of RAM and get my computer to freeze.
But if you’re trying to use it like a traditional typed language, you’ll only see the bad side of it and you’ll certainly hate it.
Nearly all of these are illegal, but sadly there is little enforcement when it comes to this. (Tracking must be opt-in, not opt-out. Ignoring a banner must be interpreted as declining. Opting out must be a simple option, not navigating a complex and misleading menus. The users choice applies to any form of tracking, not just cookies…)
I’ve been writing my own render framework and component library for about a year now.
One thing I enjoy most about it is that the types are automatically inferred. There’s a lot of Typescript wrangling going on, and it gets really deep into what TS is capable of and barely capable of (polymorphic this, dynamic return types based on input, Class type reconstruction, mixins that influence both static and instance properties, event listeners based on event name, typed property watchers based on property name).
It’s all written in JavaScript with “JSDocs”. It’s not really JSDocs because there’s a lot of recursion that’s not possible with regular JSDocs. It’s TS type information slipped into JSDoc comments.
But that is to setup the ability to tap into inferred types. The actual code that’s written (eg: components) is fully typed check with little or no type declaration.
The reality is, no complex piece of code should be written without some form of type checking. TS isn’t perfect and if there were something better, I’d move. Alliances are stupid. There are problems with some things that have not been, and likely will never be, fixed. But what type-checkers should do best is infer types dynamically.
The result means all my code today just runs in the browser. I don’t have to wrangle builders or compilers (bye Webpack!). At most, I use just esbuild to minify, though it’s an optional step, not a mandatory one. If I want to mess around on Codepen with my library, I can refer to a git commit directly and load the file. I don’t need npm to package and release. (CodePen Sample)
I’m idealistically/philosophically committed to a Purescript Halogen front end with a Haskell Servant backend, biatch. Maybe someday I’ll get WASM in there. One thing I will not do is use TS or JS.
programmer_humor
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.