3 ms·

JetBrains seems to be forging ahead with their own Space project and not trying to partner too closely with any existing forge. They seem to understand "IDE-in-

JetBrains seems to be forging ahead with their own Space project and not trying to partner too closely with any existing forge. They seem to understand "IDE-in-browser" undermines their fundamental market position; they need to make people not need the browser in the first place, to retain it.

vladvasiliu 4y ago
> They seem to understand "IDE-in-browser" undermines their fundamental market position How so? They've recently rolled out the "gateway" product, which is basically a remote IDE. Sure, you still connect to that with a local one, but the local one doesn't do that much. Why not move it to a browser? The remote one does all the things people love about their IDEs. And if people don't care, they're probably not using their products anyway. The only issue I'd have with a browser, is that I usually use Vim keybindings, which I've never seen well implemented. My favorite being the window intercepting ^W.
- zamalek 4y ago
  There's actually a few products. Gateway is a remote IDE in the browser, it's a rewrite of their front-end (Spring I think?) to marshal the UI over HTTP. Remote is similar to VSCode. The IDE is split into a front-end and a backend: the UI stuff happens locally, and does RPC to the backend for file access, terminal, language server, what-not.
  - deleted 4y ago
    [deleted]
  - NoahKAndrews 4y ago
    Gateway is a desktop app. https://www.jetbrains.com/remote-development/gateway/ https://www.jetbrains.com/remote-development/gateway/
canadianfella 4y ago
mgkimsal 4y ago
Would be sorta nice if their 'issue tracking' functionality in their IDEs would support... Space itself.
btown 4y ago
JetBrains' fundamental market position is that companies pay per seat for an it-just-works IDE. So if anything, IDE-in-browser, where code is executing on a hosted backend, is even more aligned with this. The real question is whether they can execute on this. Will they be able to replicate years of VS Code's work on providing UI extensibility without sacrificing performance, with a team that historically had been JVM rather than JS/TS experts? Will they be able to build the right abstractions to allow for temporary network outages and all the distributed-systems challenges that come with that? It's quite a moonshot to get to the level that people expect of VS Code, especially as Microsoft has access to relatively-limitless capital in ways that JetBrains, which has not taken outside investment, does not.
- theptip 4y ago
  I’m confused by this comment. Why do they need to move to browser-based JS/TS? Their existing toolchain is all about doing everything in the IDE. (Remote dev envs, code review, all of it). Am I missing something? I haven’t seen anything which suggests they are going down the path you refer to here. A local client they own is their differentiator over the browser, why would they abandon that?
  - tomnipotent 4y ago
    > Am I missing something? Fleet (https://www.jetbrains.com/fleet/ https://www.jetbrains.com/fleet/). They're building a distributed IDE. A web-based UI would fit nicely into their new roadmap.
    - theptip 4y ago
      I dunno, most of the stuff in Fleet looks to me like it benefits from being a native thin-client rather than a browser-based app (e.g. SSH to your remotes, run the language server locally, etc). I can see that a web-UI option could be built atop the "Space-hosted everything" architecture they are putting together, but I don't see any evidence that's actually what their core strategy is, as GP suggested. They spend a bunch of time discussing running things on "Your machine" too, which doesn't sound like a browser-first strategy. As I see it, their secret sauce is building client-side applications that are faster than other companies can build. I just don't see them giving up that performance edge to make a browser-based client their primary strategy.

vladvasiliu 4y ago

> They seem to understand "IDE-in-browser" undermines their fundamental market position How so? They've recently rolled out the "gateway" product, which is basically a remote IDE. Sure, you still connect to that with a local one, but the local one doesn't do that much. Why not move it to a browser? The remote one does all the things people love about their IDEs. And if people don't care, they're probably not using their products anyway. The only issue I'd have with a browser, is that I usually use Vim keybindings, which I've never seen well implemented. My favorite being the window intercepting ^W.

zamalek 4y ago
There's actually a few products. Gateway is a remote IDE in the browser, it's a rewrite of their front-end (Spring I think?) to marshal the UI over HTTP. Remote is similar to VSCode. The IDE is split into a front-end and a backend: the UI stuff happens locally, and does RPC to the backend for file access, terminal, language server, what-not.
- deleted 4y ago
  [deleted]
- NoahKAndrews 4y ago
  Gateway is a desktop app. https://www.jetbrains.com/remote-development/gateway/ https://www.jetbrains.com/remote-development/gateway/

canadianfella 4y ago

mgkimsal 4y ago

Would be sorta nice if their 'issue tracking' functionality in their IDEs would support... Space itself.

btown 4y ago

JetBrains' fundamental market position is that companies pay per seat for an it-just-works IDE. So if anything, IDE-in-browser, where code is executing on a hosted backend, is even more aligned with this. The real question is whether they can execute on this. Will they be able to replicate years of VS Code's work on providing UI extensibility without sacrificing performance, with a team that historically had been JVM rather than JS/TS experts? Will they be able to build the right abstractions to allow for temporary network outages and all the distributed-systems challenges that come with that? It's quite a moonshot to get to the level that people expect of VS Code, especially as Microsoft has access to relatively-limitless capital in ways that JetBrains, which has not taken outside investment, does not.

theptip 4y ago
I’m confused by this comment. Why do they need to move to browser-based JS/TS? Their existing toolchain is all about doing everything in the IDE. (Remote dev envs, code review, all of it). Am I missing something? I haven’t seen anything which suggests they are going down the path you refer to here. A local client they own is their differentiator over the browser, why would they abandon that?
- tomnipotent 4y ago
  > Am I missing something? Fleet (https://www.jetbrains.com/fleet/ https://www.jetbrains.com/fleet/). They're building a distributed IDE. A web-based UI would fit nicely into their new roadmap.
  - theptip 4y ago
    I dunno, most of the stuff in Fleet looks to me like it benefits from being a native thin-client rather than a browser-based app (e.g. SSH to your remotes, run the language server locally, etc). I can see that a web-UI option could be built atop the "Space-hosted everything" architecture they are putting together, but I don't see any evidence that's actually what their core strategy is, as GP suggested. They spend a bunch of time discussing running things on "Your machine" too, which doesn't sound like a browser-first strategy. As I see it, their secret sauce is building client-side applications that are faster than other companies can build. I just don't see them giving up that performance edge to make a browser-based client their primary strategy.