Building a Better Online Editor for Typescript
Posted4 months agoActive3 months ago
blog.val.townTechstory
calmmixed
Debate
40/100
TypescriptOnline EditorLanguage Server Protocol
Key topics
Typescript
Online Editor
Language Server Protocol
The post discusses building a better online editor for TypeScript using the Language Server Protocol, and the discussion revolves around the challenges and alternatives to this approach.
Snapshot generated from the HN discussion
Discussion Activity
Moderate engagementFirst comment
2d
Peak period
7
48-60h
Avg / period
2.4
Comment distribution12 data points
Loading chart...
Based on 12 loaded comments
Key moments
- 01Story posted
Sep 22, 2025 at 12:22 AM EDT
4 months ago
Step 01 - 02First comment
Sep 24, 2025 at 3:49 AM EDT
2d after posting
Step 02 - 03Peak activity
7 comments in 48-60h
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 26, 2025 at 4:01 PM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45329080Type: storyLast synced: 11/20/2025, 2:38:27 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
https://github.com/microsoft/monaco-editor
[1]: https://github.com/denoland/vscode_deno/issues/515
They could have also contributed to the effort. You can also add types to monaco typescript. I don’t see a need for a Deno specific LSP, am I missing something?
The second biggest deal is that the Deno LSP also includes a full linter, versus for the full experience the Typescript not-quite-LSP is often paired with the ESLint VS Code extension and a large eslint install.
Deno's LSP is also sometimes preferred for being a single Rust binary that runs quicker than Typescript's not-quite-LSP (plus or minus ESLint's non-LSP). It may be interesting to see how Golang Typescript's real-LSP fares in comparison in a future version.
They really just should have used Monaco. This will be a burden to maintain and won't be a core differentiator.
Leaning on CloudFlare Containers seems like a good balance though. But im wondering what the limits are, some packages are very large and require more than just Javascript (e.g node gyp).
(Personally I ended up hosting a web-only VS code served as static files. Luckily i dont need to support Deno syntax so the built-in Typescript language server worked fine.)
The client (CodeMirror) connects to the language server though WebSocket to offer semantic highlighting and some custom LSP actions related to compiling and serving the project.