Who would win? JavaScript or TypeScript

Forge Forge Platform and Tools
, ,
1

I know tabs vs spaces can be funny. But this comparison could be trivializing a serious problem.

Already, @danielwester and @remie are chiming in for “both” (and see what happens in my blog post to “both”?). Let’s talk this through since those 2 know full well how few resources are applied to documentation and specifically examples. How do you really want us to prioritize efforts?

  • Do you want fewer and/or shallower examples in both languages?
  • Do you want JavaScript transpiled from TypeScript?
  • Is more developers better, if fewer are successful at getting anything running?

I feel like there’s an opportunity to set some values of Forge here. A parallel that I’m curiously watching play out is between Go and Rust. In the Go community, the “go” name represents a kind of “go fast” attitude. That’s been represented in choices about making sure compilation is fast, and that libraries are built quickly. That has lead some teams to have Go-regrets. The fast start sometimes stalls, especially when depending on cross-OS compilation where quickly built libraries often push problems back to developers. Meanwhile, Rust seems to prefer correctness. The spend a lot of time “getting things right” and they have a much slower compiler. In a lot of ways, Rust feels behind Go in terms of libraries and features. However, I’m seeing large companies (including Google who spawned Go) embracing Rust for that correctness.

The decision between those 2 isn’t just an arbitrary and individual-centric choice. Embracing a language is embracing the underlying values, which manifests in the patterns of change you will be subject to, and the quality of code you can write.

For all those reasons, I respectfully disagree with @rwhitbeck in that it’s a trivial choice, and with @danielwester and @remie arguing for “both” (but also while arguing in other threads for keeping quality documentation and examples working, even after engineering has “plateaued”.) I think Atlassian should pick the option that helps us avoid what we should have learned about P2 and Connect about making sure we only create so many examples as we can actually maintain. For me, that’s advantage TypeScript, where we get some leverage from tooling to help find problems with less human effort.

2 Likes
2

I did not argue for Javascript (well I did) - but if Forge is going to pick a language - I pick perl5 (but seriously - go for javascript).

1 Like
3

Well, as value, it does have, “making easy things easy and hard things possible.” According to @tobitheo some easy things are still impossible with Forge so it could benefit from that value.

4

To be painfully honest here, I think the main problem you are describing is not JavaScript versus TypeScript, but a well documented and persistent unwillingness to invest in resources by Atlassian.

For a company that prides itself of, and produces ample marketing material about, being a leader when it comes to TEAM-work and operations, Atlassian is not willing to meet it’s own standards. There are plenty of other (even smaller in terms of market cap) companies that do documentation and DevRel extremely well. It’s no rocket science, it’s a choice made by Atlassian.

But anyway, here we are. It is what it is.

Now given that we have to deal with this lack of resources, and thus having to make choices, I agree that this decision should not be taken lightly. I was serious when I noted that at this point, talking about “JavaScript” as a single language does not make any sense. Based on the documentation, it seems like Forge actually supports Node 10, which means that a lot of the features that modern NodeJS developers are getting familiar with are not supported out of the box.

During deployment, Forge uses a transpiler to transform the ES6, ES2020, ES2021 or whatever flavour the developer choses to the runtime Node version, adding polyfills to support the missing features.

Which means that this is not a discussion about vanilla (JavaScript) versus exotic (TypeScript) as it is sometimes made out to be. It also means that the whole “there are more JavaScript developers” argument is a bit smoke and mirrors.

At this point, can we still say that any documentation that involves “JavaScript” is not already opinionated? Will it use ES6 import? Because that is not even supported by Node at all. Changes are that the code produced by the examples will be outdated by the time they are published. Who uses

await arr.reduce(async (prev, next) => {
  await prev;
  // do something with Next
}, Promise.resolve())

when you can now also use

for await (const x in y) {
  // do something with x asynchronously
}

Point being: JavaScript is evolving rapidly. Same goes for TypeScript. And there are a lot opinions. Often I have trouble understanding the examples of AtlasKit because of the personal code style preferences of the developers writing the documentation.

So I’m going to reluctantly bring my argument back to the fact that in the end, it does not matter if you choose the contemporary JavaScript flavour or Typescript. What matters is that Atlassian decides to invest in DevRel and hires enough resources to keep the documentation up to date. Because in the end, that is also what went wrong with P2 and Connect. It’s not about the language, it’s about making the choice to be a developer oriented company.

5 Likes
5

I pick perl5

Bless