# How to use TableView.jl in VSCode?

**URL:** <https://discourse.julialang.org/t/how-to-use-tableview-jl-in-vscode/44912>\
**Category:** General Usage\
**Created:** [August 14, 2020, 6:11am UTC](https://discourse.julialang.org/t/how-to-use-tableview-jl-in-vscode/44912 "2020-08-14T06:11:25Z")\
**Posts on this page:** 12\
**Page:** 1

<div class="post-metadata">

**Author:** ![xiaodai](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/xiaodai/32/15937_2.png) [@xiaodai](https://discourse.julialang.org/u/xiaodai)\
**Post date:** [August 14, 2020, 6:11am UTC](https://discourse.julialang.org/t/how-to-use-tableview-jl-in-vscode/44912/1 "2020-08-14T06:11:25Z")

</div>

I can use TableView on Juno as just

```julia
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.

---

<div class="post-metadata">

**Author:** ![nilshg](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nilshg/32/2283_2.png) [@nilshg](https://discourse.julialang.org/u/nilshg)\
**Post date:** [August 14, 2020, 10:19am UTC](https://discourse.julialang.org/t/how-to-use-tableview-jl-in-vscode/44912/2 "2020-08-14T10:19:26Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![xiaodai](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/xiaodai/32/15937_2.png) [@xiaodai](https://discourse.julialang.org/u/xiaodai)\
**Post date:** [August 14, 2020, 11:08am UTC](https://discourse.julialang.org/t/how-to-use-tableview-jl-in-vscode/44912/3 "2020-08-14T11:08:47Z")

</div>

So r u aware of works to makr the vscode display more via for large dataset?

---

<div class="post-metadata">

**Author:** ![nilshg](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nilshg/32/2283_2.png) [@nilshg](https://discourse.julialang.org/u/nilshg)\
**Post date:** [August 14, 2020, 1:16pm UTC](https://discourse.julialang.org/t/how-to-use-tableview-jl-in-vscode/44912/4 "2020-08-14T13:16:15Z")

</div>

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](https://github.com/julia-vscode/julia-vscode/issues?q=is%3Aissue+webio+)), which if implemented would mean `TableView` would “just work” ™ as it spits out the table as a `WebIO` object

---

<div class="post-metadata">

**Author:** ![davidanthoff](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/davidanthoff/32/223493_2.png) [@davidanthoff](https://discourse.julialang.org/u/davidanthoff)\
**Post date:** [August 14, 2020, 3:55pm UTC](https://discourse.julialang.org/t/how-to-use-tableview-jl-in-vscode/44912/5 "2020-08-14T15:55:48Z")

</div>

The relevant issue on the extension side is [https://github.com/julia-vscode/julia-vscode/issues/1489](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.

---

<div class="post-metadata">

**Author:** ![nilshg](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nilshg/32/2283_2.png) [@nilshg](https://discourse.julialang.org/u/nilshg)\
**Post date:** [August 14, 2020, 6:05pm UTC](https://discourse.julialang.org/t/how-to-use-tableview-jl-in-vscode/44912/6 "2020-08-14T18:05:25Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![davidanthoff](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/davidanthoff/32/223493_2.png) [@davidanthoff](https://discourse.julialang.org/u/davidanthoff)\
**Post date:** [August 14, 2020, 6:54pm UTC](https://discourse.julialang.org/t/how-to-use-tableview-jl-in-vscode/44912/7 "2020-08-14T18:54:31Z")

</div>

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](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.)

---

<div class="post-metadata">

**Author:** ![nilshg](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nilshg/32/2283_2.png) [@nilshg](https://discourse.julialang.org/u/nilshg)\
**Post date:** [August 15, 2020, 10:02am UTC](https://discourse.julialang.org/t/how-to-use-tableview-jl-in-vscode/44912/8 "2020-08-15T10:02:44Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![davidanthoff](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/davidanthoff/32/223493_2.png) [@davidanthoff](https://discourse.julialang.org/u/davidanthoff)\
**Post date:** [August 15, 2020, 4:08pm UTC](https://discourse.julialang.org/t/how-to-use-tableview-jl-in-vscode/44912/9 "2020-08-15T16:08:19Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Gabriel\_Kreindler](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gabriel_kreindler/32/24961_2.png) [@Gabriel\_Kreindler](https://discourse.julialang.org/u/Gabriel_Kreindler)\
**Post date:** [May 10, 2021, 9:30pm UTC](https://discourse.julialang.org/t/how-to-use-tableview-jl-in-vscode/44912/10 "2021-05-10T21:30:13Z")

</div>

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!!

---

<div class="post-metadata">

**Author:** ![pfitzseb](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pfitzseb/32/45566_2.png) [@pfitzseb](https://discourse.julialang.org/u/pfitzseb)\
**Post date:** [May 10, 2021, 9:34pm UTC](https://discourse.julialang.org/t/how-to-use-tableview-jl-in-vscode/44912/11 "2021-05-10T21:34:09Z")

</div>

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).

---

<div class="post-metadata">

**Author:** ![affans](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/affans/32/11911_2.png) [@affans](https://discourse.julialang.org/u/affans)\
**Post date:** [May 10, 2021, 9:41pm UTC](https://discourse.julialang.org/t/how-to-use-tableview-jl-in-vscode/44912/12 "2021-05-10T21:41:24Z")

</div>

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)