Switch to TypeScript

[PJB3005]

Like, whether or not JS or the usage of a browser is bad is another debate.

At least have the sanity to use TypeScript so you get static typing. You'll thank me in a few months.

[Kinrany]

Bluespess has less than 10k loc, it's still doable!

Though configuring TS is a pain.

[HeadClot]

Why not some Typescript bindings then? I am not a fan of rewriting something in typescript if it works good enough. Here is an automation tool for that.

[PJB3005]

JS works good enough until it doesn't (read: you have to refactor anything at all). At that point you probably don't even realize how much time a sane programming language would've saved you because you made the mistake of writing 10kLOC in JS.

[SupremeTechnopriest]

Is this project even alive? I though SS3D was the new open source SS13 remake.

Typescript is verbose. I can see why you would not want to use it. It only protects you from yourself. If you trust yourself, pure JS will save you a ton of keystrokes and headache. I think the best argument I've heard for TS is that it helps new people onboard to a project and know whats going on more quickly. I can agree with that, but its still just a glorified linter... That said, AssemblyScript is a better use case for TypeScript. It actually compiles to something faster rather than being a verbose safeguard.

I have written parts of my games in AssemblyScript and really enjoyed working with it. I have rewritten JS projects in TS only to refactor back to JS because of some bug or limitation in TS.

-- Two cents from a slowly reforming TypeScript hater.

[PJB3005]

Is this project even alive?

no

I though SS3D was the new open source SS13 remake.

And also SS14 and Unitystation, if you want remakes that are actually making progress rather than art assets.

It only protects you from yourself. If you trust yourself, pure JS will save you a ton of keystrokes and headache.

I don't know of any nice way to put this so I'm just gonna be blunt. That shows you have no idea what you're talking about. Static typing does far more than being a glorified linter. Here are some of the things it provides if your IDE isn't hot garbage:

• Actually functional code navigation so you can jump to class/function/field definitions without having to resort to barbaric methods like doing annoying global code searches for the name of the symbol you want.

• It makes refactoring 20 times easier because you can just do stuff like massive symbol renames with a few keystrokes. Try this in JS and it won't be able to rename stuff outside of the same class definition. You once again have to resort to barbaric methods like global code search to try to find usages which is cumbersome and error prone. And you fail to refactor one thing and you've just created an obscure bug some unfortunate player will run into in a week's time.

• You get code completion that actually works reliably compared to JS where code completion only works in the most obvious situations and more often than not does not.

• You know, a guarantee that the code you just wrote isn't gonna blow up due to a type or you misremembering a variable name.

If you are somehow still not convinced, let me attack:

If you trust yourself

If you "trust yourself" and you are writing anything larger than a couple files / a thousand lines, I'd say you're at best a naive idiot. You get to read and rewrite code you wrote 1 year ago. 2 years ago. at 2 AM 2 years ago. somebody else is going to have to do that. All of these things become exponentially more difficult compared to a real language like TS or C# when you don't have good static typing, for the reasons listed above.

I can say this with certainty because I know for a fact that DM's barely-functional static typing is the only thing keeping SS13 development going. I replaced the /vg/ scheduler with stonedMC first try and all I had to do was follow the paper trail of compiler errors created by deleting the scheduler. That was it. Try that in a codebase without static typing. You might as well give up.

SS13 has like 500,000+ lines of DM code. You're not maintaining that amount of content and complexity in a language without static typing.

[SupremeTechnopriest]

You don't need static typing for refactor and intellisense to work in your IDE.... What year are you trapped in? Why are you so angry? Show me on this doll where the bad JS touched you.

Write the game in C#. That I can get behind. At least C# compiles (rather than transpiles). You actually gain performance by writing all that verbosity, not just a message saying "Hey amateur, you made a boo boo". IMO, AssemblyScript is the only "real" use case for typescript, but I can see your point about larger projects with larger teams. If there are a lot of hands in the pot and I couldn't chose a real typed language, I would probably (begrudgingly) employ typescript.

Id almost rather write the entire project myself then have to write 100s of definitions that literally transpile to nothing. If I'm going to chose a typed language for the job, its not going to be TypeScript.

[PJB3005]

You don't need static typing for refactor and intellisense to work in your IDE....

For it to work at all decently, you do. I tried the built-in intellisense in VSCode for a few minutes. TypeScript was perfect and what I would expect from a statically typed language. JS was a joke.

Unless Microsoft just happens to include a very terrible JS language server in VSCode (doubt), I'm not buying it.

[SupremeTechnopriest]

Of course its going to be better with TS, you have spent hundreds of hours writing definition files LOL. Doesn't mean its non existent for JS. JS tooling, especially in VS Code is getting really good.

[SupremeTechnopriest]

Listen, I get the arguments you and the rest of the TS community are making in defense of TS.... However at the end of the day it still just transpiles to JS. You get some development benefits and some development detriments. Zero benefits in production (aside from AssemblyScript). It's up to the project manager to weigh those benefits and detriments against the job at hand.

In my opinion, I'd rather my team focus on compete test coverage than writing a desc for every facet. I also like to ship software, not spend countless hours writing things that don't benefit the end product directly.

The intellisense is nice though. :)

[Kinrany]

JS tooling, especially in VS Code is getting really good.

Which is based on TS type inference...

[SupremeTechnopriest]

@Kinrany Love it, abstract it away where it belongs. Im not knocking the tool, it's great in theory. Just don't pass me the tech debt.

[Kinrany]

Tech debt? What are you talking about?

[SupremeTechnopriest]

@Kinrany Maybe not tech debt, I imagine TS claims to prevent tech debt. More, making me inherit the responsibility of writing a definition for every single structure in my application. Increasing my iteration time substantially. It's also SLOW to develop in. We finally, almost, have ES6 everywhere and I have dropped babel from most of my projects. Transpiling every change is extremely slow and annoying in TS. It adds a more work to achieve less and at the end of the day runs no different.

[SupremeTechnopriest]

If you are comfy with TS I don't suggest you go back to JS. Types are nice, but if you already write good JS and don't need your hand held theres really no reason to switch, apart from the points mentioned above. If I need a typed language for a problem I'm going to write the solution in Rust, C# or hopefully one day V. Why trouble yourself writing types for an interpreted language... (apart from the aforementioned reasons).

[Kinrany]

All right... all right... but apart from better sanitation and medicine and education and irrigation and public health and roads and a freshwater system and baths and public order... what have the Romans done for us?

[SupremeTechnopriest]

LOL I think I get your meaning. Which is why I will reiterate, conceptually its a great tool, things like AssemblyScript were born from it which is actually a fantastic tool. Im not knocking the why, I'm more knocking the how. TS has its place, but I think we can agree its not a replacement for JS?

[PJB3005]

Of course its going to be better with TS, you have spent hundreds of hours writing definition files LOL.

No I haven't. I would've written the code in typescript in the first place so all the definitions are already there. This improves readability either way because you can actually tell what the types of function parameters and such are.

Doesn't mean its non existent for JS. JS tooling, especially in VS Code is getting really good.

JS autocomplete in VSCode only works in situations where the type can be guaranteed via type inference. This works for stuff like class members and usages of classes directly after instantiation, but good luck calling things on objects you take in via function parameters:

JS tooling, especially in VS Code is getting really good.

I can't do anything but laugh at this after having used Rider for C# daily for more than a year.

Zero benefits in production (aside from AssemblyScript).

If with this you mean "when the code is finally written", then yes, you're right. Except at this point you have to be intentionally ignoring my arguments to think that's all that matters.

It's up to the project manager to weigh those benefits and detriments against the job at hand.

Which is why I opened this issue on the repo to advocate for TypeScript.

In my opinion, I'd rather my team focus on compete test coverage than writing a desc for every facet.

Good luck doing that with a project the size and variety of SS13. Actually writing tests for every single gameplay interaction is simply infeasible. Much less so is expecting half the contributors to even bother.

It also provides little help for ease of refactoring. It provides no help for code navigation. It doesn't magically make JS able to read your mind and infer the types a function has through pure magic so that intellisense is useful half the time.

I also like to ship software, not spend countless hours writing things that don't benefit the end product directly.

If you think it takes "countless [extra] hours" to write code in a statically typed language I can only assume that you have never actually written anything serious in one. Writing out type annotations on function headers and field names is not difficult.

The benefits to to the end product are that you can develop it faster so that you can get more work done. How is this so hard to grasp?

You literally did not address any of my arguments then go "w-well it doesn't matter because it compiles down to the same!" Is Rust practically the same as C++ because they both compile to heavily optimized & similar assembly?

The intellisense is nice though. :)

I want you to know that Monster was streaming bluespess development once. During the one minute of development I watched he forgot a variable name and had to switch to another file to look it up. Instead of just being able to get it via intellisense. Because there is no static typing.

Also I was reviewing bluespess' code at one point and I came across many functions I could not find the definition for to be actually able to look up what they do. In a sane statically typed literally all I would've had to do was hit F12. I had to ask Monster instead.

More, making me inherit the responsibility of writing a definition for every single structure in my application.

This is such a common misconception with static vs dynamic typing that it hurts that I have to repeat this time and time again.

When you are writing code in a dynamic language like JS/Python, you are still reasoning about types.

If you write a class you are 100% aware of what goes where and what the types of the fields are. Just you're not writing them down. This just completely bones the next person that actually has to read your code.

Increasing my iteration time substantially.

Yes. and this comes at the cost of 10x harder maintenance. Working with dynamic typing is quite trivial while everything's still in your head. Then you or somebody else has to maintain the code a year later and it sucks because you have no idea what any of the types are. Dynamic typing makes the code arguably easier to write (but only if you ignore advantages like intellisense, better linting, etc!!!, seriously having to write out types is not hard) and 10x harder to read.

It's also SLOW to develop in. We finally, almost, have ES6 everywhere and I have dropped babel from most of my projects. Transpiling every change is extremely slow and annoying in TS. It adds a more work to achieve less and at the end of the day runs no different.

I can't speak for this but since we used to have 3 minute compile times in SS13 I'm sure we'll manage.

but if you already write good JS

And other hilarious jokes you can tell yourself

(this is not a jab at JS specifically, this goes for any language. You don't tell people to "become better drivers" to avoid deaths from traffic accidents. You give them seatbelts)

If I need a typed language for a problem I'm going to write the solution in Rust, C#

I don't see why there has to be a distinction between problems that lend themselves to static typing better and not. The only distinction I personally can think of is size of the project.

Why trouble yourself writing types for an interpreted language... (apart from the aforementioned reasons).

I have stated the reasons in my earlier comment. You have yet to dispute half of them.

but I think we can agree its not a replacement for JS?

It is in the context of this project. Or any project that isn't "write once and forget about it".

Otherwise yeah fair enough use whatever.

[SupremeTechnopriest]

My intellisense looks a little different, It has the full TS type inference, across files, just all the types are any.

I'm not trying to dispute all your points. Your points are valid, especially as it pertains to THIS project and games in general. I thought we were speaking about typescript in general and I've offered some perspective on why some people wouldn't want to embrace TS when JS works "perfectly fine".

I don't see why there has to be a distinction between problems that lend themselves to static typing better and not. The only distinction I personally can think of is size of the project.

Size of project for sure, but also vs. JS build times > iteration time > time to market and vs. other typed languages; performance. Every number in JS is still a double... TS cant help you there.

...any project that isn't "write once and forget about it".

That's a bit of an oversimplification, but it captures the gist of it. I think size of team, size of project, type of the project, deployment target, etc all play a part in language decision.

FTR:
I TOTALLY AGREE THAT IF BLUESPESS IS TO MOVE FORWARD IT SHOULD BE REWRITTEN IN TS! That's why I'm on this thread. I honestly think parts of it should be written in AssemblyScript.

[SupremeTechnopriest]

Also no not trolling, I really hope it succeeds 👍 but rust targets wasm so I'm g2g either way.