Reason why I decide to rewrite back-end code to kotlin

[turtton]

一言で言うとTypeScriptの開発体験がKotlinに比べて酷いって話なんだけど、それじゃあ理解が得られないのでちゃんと理由を書く。日本語がネイティブなので誤解を減らすために日本語でも書く。こっちは結構砕けた文章で書くし、英語の方には書かない内容もあるけどそれは無視してほし
※英語で文法的な間違いがあれば指摘してもらえると僕が喜びます(勉強になるので)

I am not confident in my English, so I will try to describe it here in both Japanese and English. Since machine translationsfrom Japanese to English are often nonsense, I hope you can get the general nuances from both sides.

前提として僕はWebエンジニアでもなんでもないため、TypeScript/JavaScriptを扱うのは今回が始めてである点、そのためよりよいソリューションに気付いてない可能性や、単なる僕の技術不足による愚痴と化している可能性がある点ご容赦ください。(普段はKotlinやJavaなどの強い静的型付け言語を使用して開発をしています)

Keep in mind that I am not a web engineer, and this is my first project using TypeScript/JavaScript, so it is possible that I only don't know how to do it better or that it is simply due to my lack of skill.(I usually develop using strongly statically typed languages such as Kotlin and Java)

まだ #17 が作業中なので誤解のないようにしたいが、全てをkotlinで書き直すのではなく、複雑なロジックの部分だけを直すような形での更新を予定している

Note that the changes made by #17 plans not to replace all the code with Kotlin, but only those parts that are complex to process.

[turtton]

MarkdownパーサーのRemarkが扱いにくい(Remark, which is markdown parser is difficult to use)

TypeScriptからKotlinで書き直したいメインの場所の一つ。RemarkがJavaScriptで書かれているので型の解決が難しいパターンがあり、プラグインを含め型から処理内容が見えてこない。
Kotlinでは公式でパーサーが存在するのでこれで書き直す予定

These issues one of motivated me to rewrite from TypeScript to Kotlin. Since Remark is written in JavaScript, the main body code, as well as the plugins, have difficulty resolving type information, and the processing details, including the associated plugins, are for me a It is a black box.
Kotlin has official parsing library, so I plans to use it.

Example of gave up on type information resolution

volglass/src/lib/transformer.ts

Lines 82 to 88 in c04003c

	// eslint-disable-next-line @typescript-eslint/ban-ts-comment
	// @ts-expect-error
	.use(remarkRehype)
	.use(rehypePrism)
	// eslint-disable-next-line @typescript-eslint/ban-ts-comment
	// @ts-expect-error
	.use(rehypeStringify)

HTMLでの出力による問題点(Problem of HTML generation)

現在はRemarkのHTML出力を用いてMarkdownを変換しているが、これによって生成された内部リンクをクリックするとフォルダーツリーなどの状態がリセットされる。これを解決するにはRouterなどを使うようなJSX.Elementを出力する必要があるが、既存のものでこの需要を満たすプラグインは見つけられず、自作しようにも型の正しさと処理の正しさが一致しないので断念した。

Remark, which I am using as a Markdown parser, is currently producing HTML output, so clicking on a link to another piece of content in markdown will close the entire folder tree, etc.
To fix this problem I need a parser plugin that outputs JSX.Element, but I have not been able to find one that meets my needs. I tried to make my own but gave up because the type correctness did not match the processing correctness.

Obsidian特有の記法のサポートが難しい(Difficult to support Obsidian-specific notations)

マーメイド記法をサポートするためにremark-mermaidjsを試したが、そもそも上手く動作せず、その上ビルド時にChromiumを要求する。これは現在のCloudflarePagesでのデプロイを意識した設計に反するため使用を断念した。自作できないかどうかも試したが、他のプラグインなどを参考にしようにも何をやっているのかがまずわからず、型を頼りに実装しようにも型の正しさが処理の正しさにならないため断念した。
同じようなシチュエーションとしてObsidianでは改行のルールがMarkdownのそれとは異なるため、その挙動を変更するようremarkの変換処理を変えようとしたが、こちらも型が見えず失敗した。

To support Mermaid I tried remark-mermaidjs ,but did not work as expected and required Chromium at building time. It is contrary to the current CloudflarePages-aware design for deployment, so I abandoned its use. I also tried to make my own but gave up because I didn't know how to handle the conversion part of a code block.
Similarly, the line break processing is different between the original Markdown and Obsidian, so I tried to modify the conversion process, but failed in the end. So I had to revise the original data in a rush.

[turtton]

Slugの処理が難解(The slug process is a maze)

Slugは時にはid、時にはrouterPathなどの名前で処理され、先頭のスラッシュの有無などが僕も把握できてないほど色々な場所で修正され、場所によって異なる形で提供されている。また、それぞれSlug(string)でも期待されている形式は異なるためこれらを解決するには骨が折れる。コードを紐解く時点でかなりキツい。#13 が出来たのは奇跡みたいなもん。正直もうやりたくない

Slugs are processed with names such as id, routerPath, etc., depending on the case, and their format is modified in various places, with different contents in different places. This is already getting out of hand, as the same name may have a different expected format. It is quite tough when unraveling the code, and it is almost a miracle that #13 succeeded.

[turtton]

GraphやMarkdownコンテンツの処理が難解(The graph and markdown process is a maze)

Slugの話と共通している部分があるが、序盤のコミットにて型を解決し、動作の正しさをある程度保証したものの、その処理内容は未だに理解できていない。理由としてはそもそも元がJavaScriptのコードであるため、型による構造がしっかりと定義されておらず、冗長なコードが散見される点や、自身がTypeScript/JavaScriptに慣れていないため、そもそもの認知負荷が高い点などが考えられる。

Although I was forced to add type information early on in the project and have some assurance that the behavior is correct, the process is still profound to understand. The reason may be that the the original code is JavaScript, so the definition of the processing structure is ambiguous and there is a lot of redundant code, and because I am unfamiliar with TypeScript/JavaScript, I feel that the cognitive load of the code is higher than that of a typical web engineer.