As a developer who considered himself “server-side” for a long-time, I found TypeScript the most natural way to build front-end code when I finally had to bite the bullet for Forge. Inside Atlassian, TypeScript is quite common. Outside Atlassian, I’ve seen a lot of evidence that TypeScript is very much part of the “modern” JavaScript toolchain. That said, our Developer Experience team is hearing a wide range of opinions inside about what we should do for you, the developer community, about TypeScript. To help us gather some data (even if unscientifically as an Internet poll), I’m hoping folks will answer and comment on the following survey.
Please be aware, this is Ian’s off-the-cuff data gathering, not a plan by the Forge team. This is not a plan or a commitment.
Prior to Forge, how much TypeScript exposure did you have?
I wrote Atlassian front-end code with TypeScript (ie P2 or Connect).
It wasn’t Atlassian code, but I’ve written plenty of TypeScript.
I can read it, but I had not written anything more complicated than “Hello World”.
I had not heard of it until Forge (maybe even this survey).
0voters
What is your current opinion of TypeScript?
Essential. I don’t feel productive without it.
Good. I prefer it, but can manage without it.
Neutral. I have no preference.
Bad. I find TypeScript gets in my way too much.
Unfamiliar. Per my answer to prior question, I just don’t know enough to have an opinion.
0voters
How do you think TypeScript is trending in the industry?
Ubiquitous. When developers say, “JavaScript”, they assume, “TypeScript”.
Common. Many developers will use it, but not all.
Niche. TypeScript will only be used by the “cool kids”.
Dying. TypeScript is a passing fad that the industry will come to regret.
0voters
How much should Forge embrace TypeScript?
Go all in. Cut out the “noise” of vanilla JavaScript.
Favored option. Forge would be better if it were “TypeScript first”.
Equal option. I need both options. Please make sure they are equally well supported.
Vanilla only. I only need plain, vanilla JavaScript examples, code, and docs. I don’t need to ask TypeScript questions.
I see two main concerns here, they seem closely related and are often mistaken for the same thing, but they’re different.
The first one is providing types. This is unambiguously good: you can have types without Typescript (e.g. the Deno team internally uses JSDoc instead of TS) and they give you relevant information that you’re free to ignore – although your code probably won’t work if you ignore it – any IDE/editor worth its salt will be able to use them even if you’re writing plain Javascript and you get much nicer Intellisense/LSP completions and hints.
That’s great and writing code without them is a pain, regardless of your favourite language.
The second one is providing a TS-compatible runtime. This can be a tough problem for Atlassian and some people might not care at all about it.
I personally indulge in recursive mapped types with nested layers of infer T just for fun and I have some libraries (yes I’m a nerd ) that I’d love to use in Forge but I can’t because it doesn’t support TS 5.x, or I could but I’d have to bundle my code as an intermediate step before deploying it and that’s boring and my team would kill me if I tried.
On the other hand, arbitrarily complex TS can make type-checking quite hard and expensive, and I get that you wouldn’t want to spend too much compute power transpiling my beautiful abstractions.
However, sticking to an older version of TS might frustrate newcomers, especially if they don’t know much about Typescript: if I’m a beginner and my favourite Medium blogger told me to use fancy-library-xyz which doesn’t work on Forge, I’d have no idea what’s going on and might conclude that TS sucks, Forge sucks or a linear combination of the above in the ([Forge, TS], Sucking) vector space.
If the problem is upgrading your runtime, I get it, but it should be eventually prioritized and having a timeline would be great, if the problem is transpiling and type-checking, I’d rather have Forge skip the type-check (i.e. set the transpile only flag) and have the dev do that, or run that on the dev machine, if it breaks, it’s the dev’s fault, I don’t think that you’d get blamed for it.
Come on, you haven’t even switched to Bun? Get with the times… (jk)
Lastly, documentation: MUI for example provides TS and JS examples. Again, this is a problem for your new users: if you know JS or TS well enough, this won’t be an issue, however if I’m new to JS and I have the added noise of type annotations, that might increase the slope of the learning curve. I guess that having both examples with a toggle might be the easiest solution.
For runtimes, I’m grateful that WinterCG will help converge the “Cambrian explosion” of new runtimes. If we did end-up on a Node-alternative, I’d put my money on the AWS one, since Forge runs on Lambda.
I think you understand the Atlassian-internal conversation quite well about “new to JS”. Hence, my motivation to have some of this discussion.
Hey @ibuchanan, I selected the “Favored option” for the last question, but I think this could be misunderstood.
For me, this means Forge interfaces and libraries are well-typed (no any types like today) and documented to be clear about what they do and what they do not do, what errors to expect, etc. The better this interface is, the better downstream apps can be. This is one place where Atlassian’s Typescript focus should be.
The question, however, should not be understood as Forge should support Typescript natively. In my eyes, compiling Typescript is the developer’s job, not that of the Forge platform. This will undoubtedly also lead to situations where Atlassian holds us hostage on a specific Typescript version (AtlasKit - React 16.8 ).
As already outlined, simply “adding” more Typescript to the Forge platform (apart from library typing) does nothing in my eyes. If Atlassian wants to invest more in this, I think Atlassian should take another step back and look at Forge app tooling more generally. Setting up a Forge project is the first step every developer has to tackle. Doing this in a well-structured manner with Typescript support, Custom UI building, etc., is a really time-consuming task. This is where Atlassian could contribute to improving Typescript support from the ground up and help every Forge developer.
I am leaving some links below that underline this point, which I have made a few times in the past and ultimately led to Nx Forge:
).