I can use TableView on Juno as just
using TableView
showtable((a=1:3, b =4:5))
But for VSCode this doesn’t work.
I can’t use vscodedisplay as its performance is not as good as TableView’s for large datasets.
Ideally, the solution would need to work on WSL2 too.
This isn’t currently possible as TableView outputs a WebIO object, which isn’t supported in VSCode. There is work ongoing to support this though so it’s wait and see I suppose.
So r u aware of works to makr the vscode display more via for large dataset?
If you’re asking for improvements to vscodedisplay, then no, I’m not aware of anything (but I also haven’t checked, so this absolutely doesn’t mean none are planned!)
There are open issues though related to the support for WebIO in VSCode (see here), which if implemented would mean TableView would “just work” 
as it spits out the table as a WebIO object
The relevant issue on the extension side is https://github.com/julia-vscode/julia-vscode/issues/1489.
I think improving the vscodedisplay experience makes most sense right now, it will give the most integrated experience and just works out-of-the box.
I admit I haven’t used vscodedisplay much, in which way is it more integrated than TableView is in Juno (other than not requiring a package)?
I particularly miss the integration of TableView in the plot pane in Juno, with the ability to “plot” multiple tables in succession and specify titles for each to easily swap between different cuts of a data set.
It seems to me that an integration of TableView would be the most Julian way forward, allowing the benefits of progress on displaying arbitrarily large datasets in tables to be shared by various front-ends/development environments.
Main benefit is that you don’t need to install anything and there is no risk of any versioning interactions between the table view functionality and packages you might have installed as a user.
In terms of UI, there is a lot of improvements we could do 
I think eventually we’ll probably want to do something like https://github.com/jupyterlab/jupyterlab-data-explorer, i.e. have a notion of a data set in the extension and UI, and then have the ability to do various things interactively with that (show in a grid, use something like lyra and voyager in VS Code etc.)
I guess given that I don’t really know anything about VSCode development and how things currently work I should just keep my unsolicited comments to myself, in conclusion I just wanted to point out that these concerns about versioning exist with many other “factored out” things in the ecosystem and generally people seem to come down on the side of the benefits of modularity outweighing its potential costs.
Or more concisely: displaying arbitrary datasets is to VSCode as things that used to be in base Julia are to base Julia - nice to have all bundled up for convenience, but there are real benefits to having something generic and independently developed.
I think IDEs are in a special category here: they are probably one of the pieces of code in the ecosystem that needs to be compatible with more pieces of software than anything else. Heck, some things are even more difficult for us than Base: we go out of our way to make sure everything works with every Julia version since 1.0, so our codebase is littered with code that makes sure that actually works.
I think at the end of the day the requirement that we’ve followed here is this: the extension needs to always work, regardless of what is happening in the .julia folder. It needs to work with any wild combination of packages installed, and it is completely off the table for us to say “oh, feature X in the extension only works if you have at least version Y of package Z installed”. We want the extension to work exactly the same way if you have an empty .julia folder, or when you have a crazy list of outdated packages installed, or any other corner case situation.
This does not mean we can’t reuse code. For example the whole language server code is used by many IDE integrations besides VS Code at this point. But if we do use shared code, we need to make sure we can vendor it into the extension, and generally find a way to do that so that we still have this “it always works” experience.
In general that philosophy has served us extremely well over the last years: we just never get any errors or problem reports from users that something is incompatible.
I recently switched from Juno to VS Code, and also ran into the issue that vscodedisplay does not work for large dataframes (it crashes for me for a df with 20 million rows, whereas TableView.jl in Juno has no problem).
I was wondering whether there is any potentially upcoming upgrades to vscodedisplay() that might help with this?
The ability to “browse” a dataframe is central to my workflow. Is there any workaround in VS Code in the meantime, i.e. another way to easily browse a dataframe?
Thank you!!
Eventually we’ll have something more advanced in VSCode, but in the meantime you can just use Blink.jl to display a TableView.jl table (made easier by FloatingTableView.jl, I think).
Try FloatingTableView. I found that to work really well (and infact I work on WSL2 on Windows over X11, and the performance is still really good)