Discouraged by plan to move to VSCode

[rm-minus-r-star]

I was in the process of moving from dbt to sqlmesh, playing with some toy examples before migrating a huge project. I just spun up the sqlmesh ui, and got a warning that sqlmesh will be moving its UI to VSCode. I find this discouraging, as I quit VSCode out of intense frustration earlier this year (and getting burned by it with loss of work) -- the whole experience was pretty on-brand for a Microsoft product. I'm really surprised an open source project would introduce this kind of vulnerability and not stay committed an agnostic dev ecosystem. Tobiko, please don't lock us in to a Microsoft product.

[patschwork]

I feel exactly the same way. I tested SQLMesh a while ago.
On a project where I’d just started implementation, I also received this warning in the user interface.

The user interface was one of my favourite features compared to dbt.
I know lots of people like VSCode, but I’m trying to move away from it, or at least use VS Codium. But in VS Codium, the SSH Remote plugin is rather inadequate. This makes using SQLMesh frustrating in shared environments.

If the plan is to strengthen the Tobiko Cloud solution, then, well, I suppose I understand the move...

[mday-io]

The strategy is likely not to strengthen Tobiko Cloud given the fivetran developments.

I think there is a good argument towards continuing to improve SQLMesh UI.

Are there any aspects of SQLMesh UI you see that could improve or be fixed

[tobymao]

no, that’s not true. we made this decision before the acquisition. building a full fledge web ide is a humongous task and not worth the effort. why not leverage an existing powerful ide and extend it with what’s needed for sqlmesh?

[mday-io]

Sure - I was referencing the comment about Tobiko Cloud taking the place of UI development, not the UI deprecation decision as a whole.

It's a fair question. I haven't worked on VS code extensions so can't speak to their extensibility.

[patschwork]

Are there any aspects of SQLMesh UI you see that could improve or be fixed

I guess there as still room for imporvements. But as far, as I can see it, nothing needs to be fixed. It is simply, that the UI will die in the future. IMHO it is a great feature for SQLMesh

Maybe other people are yelling positive about the VSCode and how great an integration is for SQLMesh and will not drop a tear for the SQLMesh UI...

[...] building a full fledge web ide is a humongous task [...]

Agree on that. It's a "task"

[...] why not leverage an existing powerful ide and extend it with what’s needed for sqlmesh?
But it's also not a no-brainer in keeping up with the VSCode API for developting an extension. This is also a task. But as @mday-io also mentioned, I'm also not to much involved in develtoing VSCode extensions. So, maybe the task is "easier"... I don't know 🤷‍♂️

"existing powerful ide" on the one hand, but a downgrade (yes I'm aware of the CLI), if want to run SQLMesh without IDE on the easy-peasy-way...

Sure, maintaining two UI's (the SQLMesh UI and VSCode) is much more work to be done.

Just my thoughts setting up a new project:

1. Setting up a machine, container, whatever (in the environment where the data lives). Install python. Install SQLMesh, run die Web UI, boom: Ready to work. (of course for productions some more things are to be done...)

2. Install local VSCode (in case you haven't). Install local Python and SQLmesh. Get access to the remotes (in case your outside). Set up the SQLmesh machine/container/cloud-env/whatever. Install Python + SQLMesh. Copy the artifacts from local to the SQLmesh machine OR build a CI/CD (yes, this should be done), run SQLmesh.

Don't get me wrong: I really like the SQLMesh and this is an amazing work.
I'm just thinking, the VSCode extension is the wrong path compared to the UI which is already great and only needs maintenance (but I didn't looked into the sources or issues: Maybe you've been facing much problems with UI I didn't saw...  🤷‍♂️)

[patschwork]

What about the following idea?:
Separate the UI from SQLMesh (core). UI uses the SQLMesh API. Development in a side-car project.

If people want to use the UI, they still could do so.

[c3us-dev]

I didn't use the UI too much before switching to VS Code but I did appreciate the sql snippet preview feature when hovering on a node. I understand that if you are in the actual editor instead of the web UI clicking and pulling up the SQL model is an option/you can use VS Code search tools, but even then on complex dependency graphs I'd rather get the preview of a specific column and trace it back to a point of interest quickly then stab around in the dark or search across files and open a bunch of VS Code tabs.

One problem I had with the web UI I remember (and this was definitely when I had just started using SQLMesh so very well could of just been doing something goofy) was at some point managing to do an accidental bulk operation of some kind that led to more tabs than I had the patience to close one by one and then... accumulation. I didn't find a UI way to close them all anyway. There were a few other weird behaviors and I think the SQL preview functionality sometimes showed random segments of queries instead of the intended column definition, but together those hiccups and the lack of support/development led me to the use extension pretty quickly. Also as @patschwork mentioned, the remote dev experience on VS Code is just too smooth so I ended up using it to replace other web UI's too (e.g. pg_admin).

All that to say, definitely opportunities to improve both/cross pollinate and while I'm personally fine with VS Code the analyst folks and other less technical users I'd love to get buy-in and participation from would find the UI much more approachable and accessible. Kind of dreading the 'it's so complicated!!' falloff after demoing SQLMesh where it's maybe the first time some folks have seen VS Code and especially when they see me move to the terminal to run the routine sqlmesh commands... Not the most familiar with internals of the web UI setup and have only tweaked the graph display in the extension but I could try and help where I can if development starts up again.