> What about Svelte?

Svelte apps aren't written in JS but in Svelte's own component syntax files. It's "HTML" but all the parts are extended (JS -> reactive, HTML -> directives, CSS -> scoping) and it needs its own compiler to transform the source to something everything else understands.

That's also true of JSX. The default output of both compilers is just a javascript module.

Yes, but JSX is much more conservative in what it introduces to the language. Other than the XML syntax rest of js is mostly left untouched.

In a svelte file, a lot of usual js constructs like labels, additions, assignments etc. have different semantics making it more work for another language to support it.

What are the things you liked about Kotlin that Typescript didn’t have or did poorly? I’m not familiar with Kotlin at all.

Data classes, co-routines and flows, internal dsl support, null checks, smart casts, type inference, an IDE that is actually smart, a standard library that is a bit more comprehensive than what a browser has, a lot of kotlin and kotlin multiplatform libraries, and more.

The general feel of the language is that of one developed by people who deeply understand what a nice language should feel like. It has a lot of features and syntactic sugar that eliminate verbosity, make things more straight forward to use and so on. It really shows that this is a language designed from the ground up to be genuinely nice to use by people who really know what they are doing because their core business is selling developer tools to developers.

I like typescript. It is a big upgrade from Javascript and MS has a lot of the same mindset that Jetbrains brings to the table in terms of developer friendly-ness and language ergonomics. Kotlin has most of the features that make typescript nice but without the whole business of trying to keep it compatible with javascript. That adds a lot of complexity, ambiguity, and weirdness to typescript that Kotlin simply does not have or need.

The biggest thing was automatic null checking. That is such a pain in Java and has bitten me so hard many times. Having the language prevent you from writing code that can crash because of a null access violation is a big step forward.

There were other things that made Kotlin seem more modern to me, but I'm foggy now on what they were. But, when I wrote Android, I would always choose Kotlin for new projects.

TypeScript has strict null checks and has only made them stricter over recent releases.

Yeah, like the other commenter said, Typescript has better (more comprehensive) null-checking than Kotlin (and, imo, a better type system in general).

Obviously both are miles ahead of Java.

A few things Kotlin does better:

- The annotation support is just better. JS ecosystem has forever been debating on decorator spec, but kotlin annotations (esp. with addition of KSP) provide good mechanism for compile time code generation.

- Support for builder dsl is just better. The js ecosystem has embraced ugly & verbose embedded XML (JSX) thanks to fb, but in kotlin we can do something like:

html { body { div(id="hello") { span(text="whatever") } } }

This is just syntax sugar for lambdas passed as last arg to a function, but it makes code a lot more readable.

- Inline methods - we don't have to worry about being functional vs being performant in most common cases. The implementations of map/reduce etc. in stdlib are all inline methods and compile down to for loops.

- Implicit it (single argument in lambda) and implicit this (in class methods) are minor niceties but they reduce verbosity of everyday code quite a bit.

- Interfaces don't get erased - you can use reflection to get interface references, check if an object complies with an interface at runtime. In TS this requires ceremony and assistance from third party libraries like zod/fp-ts etc.

- Extensions are cool, you can add extension functions to classes you don't control to mold their API in specific contexts. In JS world we can monkey patch whatever and TS interface merging helps with that but its a pattern generally frowned upon and prone to conflicts (which extension functions are not).

- Companion objects are nice to have. Instead of static methods/properties, you have a singleton associated with a class which can comply with any interface, can have its own extensions, can be passed around etc.

- Kotlin doesn't have F#/OCaml style pipelines, but you can achieve similar chaining by combining let/apply/with/also extensions. Eg.

getName().let { it.contains("foo") }.also { println(it) }

- expected & actual are pretty handy for multiplatform development

What TS does better:

- Structural typing: its a better fit when modelling types for a highly dynamic language. Being able to define interfaces for data coming from sources you can't control without needing mappers etc. makes life simpler.

- Features like intersection type, index types etc. are useful and missing in Kotlin.

- Compilation times are much better.

- large collection of typedefs in the definitively typed repo.

My current role involves mostly working with TS and a day doesn't go by that I don't miss kotlin.

No comment on decorators (I think they were a mistake to implement at all, and the TS team agrees), but extension functions? Putting aside the question of how often it makes sense to uses classes at all in Typescript, you can always just... extend a class (or interface) with whatever function you want? It's not like Typescript has sealed classes/interfaces. I might be misunderstanding?

Most everything else seems to come down to "Typescript is meant to be runtime-only", which definitely has upsides and downsides (I agree that the lack of meaningful reflection support is annoying).

Let's say we have a list of strings and want to filter for those starting with "a". In Kotlin, we can use an extension function defined on the standard Java ArrayList object:

  myStringList.filter { it.startsWith("a") }

...and on arrays:

  myStringArray.filter { it.startsWith("a") }

...and on, for example, a boolean array (a standard JVM primitive array object):

  myBooleanArray.filter { it != false }

This works for any kind of array and any kind of list, etc., even though the objects are ordinary JVM arrays and lists.

In Java, because it lacks extension functions, the stream functions are often not accessible from the object itself, so you have to hunt for where they've decided to put them for this particular type.

In the first case, we do have a stream method on the list:

  myStringList.stream().filter(s -> s.startsWith("a")).toList();

But in the case of arrays, we have to hunt down a static method in the Arrays class:

  Arrays.stream(myStringArray).filter(s -> s.startsWith("a")).toArray();

And in the last case, with a boolean array, that method doesn't work and the solution I've seen suggested is this wonderful mess (involving a different static method on a different class):

  IntStream.range(0, myBooleanArray.length).mapToObj(i -> myBooleanArray[i]).filter(b -> b != false).toArray();

> you can always just... extend a class (or interface) with whatever function you want

Not quite. Extension functions are statically resolved and abide by usual access modifiers.

So within a class, I can have a private extension method for another class (say C). Now if my class receives any instance of C, I can call these extension methods on this instance. But when I forward this instance to someone else, they wont have access to any of these extensions.

Libraries like exposed use this quite extensively.

> Most everything else seems to come down to "Typescript is meant to be runtime-only"

Yes, this one too because it would involve type directed emit.

If I had one request for TS it would be extension functions. Such a great feature in Kotlin and would be even better in TS.

> kotlin annotations (esp. with addition of KSP) provide good mechanism for compile time code generation.

Could you explain this a bit more? I thought kotlin annotations were like Java annotations - additional metadata attached to classes/fields/methods/etc but could not be used by themselves to generate code like a decorator.

Yes, that is precisely what annotations are - a common unified way to attach metadata that various tools can agree upon.

KSP [1] is a new addition to the kotlin ecosystem that facilitates cross-platform annotation processing. Various annotation processors can use this metadata to generate code - the generated classes etc. will be separate entities as opposed to direct modifications to targets.

Decorators are more powerful in that they can act upon their target directly but also (usually) have runtime overhead - this overhead is one of the reasons why the js proposal had to undergo substantial revisions.

[1] https://kotlinlang.org/docs/ksp-overview.html

Wait, Kotlin compiles slower than Typescript? That was kinda the main reason I wanted to switch.

Yeah, atleast last time I tried kotlin-js it took a minute or so for any change in IDE to actually end up in browser.

I don't understand understand the js tooling setup completely (I mostly used kotlin on backend) but the gradle-webpack integration seems to have quite some overahead. Perhaps moving to esbuild can make things faster.

I don't have a very powerful system (4yr old linux machine with 8GB ram) so ymmv.