5 ms·

Building a better online editor for TypeScript

61 points by fbuilesv 1y ago

rafram 1y ago
Why not Monaco? It works great. https://github.com/microsoft/monaco-editor https://github.com/microsoft/monaco-editor
- jsejcksn 1y ago
  The title doesn't make it clear that it's actually about TypeScript plus Deno-specific syntax — and Deno's LSP doesn't run in a worker [1]. [1]: https://github.com/denoland/vscode_deno/issues/515 https://github.com/denoland/vscode_deno/issues/515
  - gvkhna 1y ago
    yet 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?
    - WorldMaker 1y ago
      The biggest deal difference between the Deno LSP and Typescript sort-of-LSP in my experience is around the import model. Typescript has a bunch of "module resolution" modes based on various combinations of browser, bundler, and/or Node. For various reasons the Deno LSP is the only encoding of the Deno "module resolution' and upstream Typescript doesn't have a "denoX" set of "module resolution" options. 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.
      - gvkhna 1y ago
        Ah interesting, Yes i see what you’re saying regarding eslint and didn’t consider that. I’m a big of newer linters with better perf but none match the depth currently with eslint. Will keep an eye out on deno lsp!
- d357r0y3r 1y ago
  I've built significant applications using Monaco, including things that tie into custom LSPs. They really just should have used Monaco. This will be a burden to maintain and won't be a core differentiator.
  - whazor 1y ago
    Codemirror nowadays has first-party LSP support: https://github.com/codemirror/lsp-client https://github.com/codemirror/lsp-client
- whazor 1y ago
  CodeMirror 6 is more modern with better accessibility and variable width fonts.
  - rafram 1y ago
    CodeMirror 6 is more modern than the editor that powers VS Code?
gdotdesign 1y ago
I've done something similar for the Mint, and it's try page: https://mint-lang.com/sandbox/try https://mint-lang.com/sandbox/try (and all interactive snippets). 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.
conartist6 1y ago
Shoots themselves nicely in the foot for scaling and profitability to have to centralize all the work for everyone forever
thecopy 1y ago
I worked on adding a web-vscode editor in my project (MCP gateway https://mcp-boss.com https://mcp-boss.com). Initially i also spun up a container to provide terminal access, package installation etc. It turned out to be very resource intensive, and the cold-start-up UX sucked. This approach also comes with scaling challenges. 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.)

61 points by fbuilesv 1y ago

rafram 1y ago

Why not Monaco? It works great. https://github.com/microsoft/monaco-editor https://github.com/microsoft/monaco-editor

jsejcksn 1y ago
The title doesn't make it clear that it's actually about TypeScript plus Deno-specific syntax — and Deno's LSP doesn't run in a worker [1]. [1]: https://github.com/denoland/vscode_deno/issues/515 https://github.com/denoland/vscode_deno/issues/515
- gvkhna 1y ago
  yet 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?
  - WorldMaker 1y ago
    The biggest deal difference between the Deno LSP and Typescript sort-of-LSP in my experience is around the import model. Typescript has a bunch of "module resolution" modes based on various combinations of browser, bundler, and/or Node. For various reasons the Deno LSP is the only encoding of the Deno "module resolution' and upstream Typescript doesn't have a "denoX" set of "module resolution" options. 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.
    - gvkhna 1y ago
      Ah interesting, Yes i see what you’re saying regarding eslint and didn’t consider that. I’m a big of newer linters with better perf but none match the depth currently with eslint. Will keep an eye out on deno lsp!
d357r0y3r 1y ago
I've built significant applications using Monaco, including things that tie into custom LSPs. They really just should have used Monaco. This will be a burden to maintain and won't be a core differentiator.
- whazor 1y ago
  Codemirror nowadays has first-party LSP support: https://github.com/codemirror/lsp-client https://github.com/codemirror/lsp-client
whazor 1y ago
CodeMirror 6 is more modern with better accessibility and variable width fonts.
- rafram 1y ago
  CodeMirror 6 is more modern than the editor that powers VS Code?

gdotdesign 1y ago

I've done something similar for the Mint, and it's try page: https://mint-lang.com/sandbox/try https://mint-lang.com/sandbox/try (and all interactive snippets). 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.

conartist6 1y ago

Shoots themselves nicely in the foot for scaling and profitability to have to centralize all the work for everyone forever

thecopy 1y ago

I worked on adding a web-vscode editor in my project (MCP gateway https://mcp-boss.com https://mcp-boss.com). Initially i also spun up a container to provide terminal access, package installation etc. It turned out to be very resource intensive, and the cold-start-up UX sucked. This approach also comes with scaling challenges. 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.)