LSP doesn't cut it! Or does it?
summary
LSP uses JSON‑RPC with capabilities negotiation and treats documents as plain strings so positions are line/column; it works well for VS Code style editors that fire thousands of requests but omits critical details: character encoding is not specified, there is no binary file API, servers must read/write files themselves, and incremental state duplicates on client and server. No standard server‑to‑server or language‑embedding model exists; teams rely on custom endpoints or companion specs (LSIF, BSP, DAP, Kythe, JetBrains PSI) to patch gaps.
AI-written summary · about
chapters (9)
- 0:00Introduction
- 1:09Language Server Protocol
- 5:52LSP design advantages
- 11:37LSP specification gaps
- 19:38LSP limits for IDEs
- 22:52Verdict on LSP
- 27:10LSP governance alternatives
- 28:17Related protocols
- 32:39Q&A
related talks
17mState isn't all you need, but It helps: building better LLM apps in the browser
46mRethinking Server-Side Rendering in Modern PHP Applications
33mLona: Scaling Server-driven UI
03mJason Strimpel (WalmartLabs) Interview - OSCON 2014
46mWriting a DSL (Domain Specific Language) for PowerShell
59mHow to parse a file
42mBuilding a reactive multi user document editor in ScalaJS
30mBuilding Single Page Web Applications with Purescript and Erlang
