Question: Why does the editing experience of Web Auth differ so much from Tableau Desktop?

And why also does my dashboard often render so very differently on Cloud/Server compared with Desktop?

Ah, that old chestnut. This isn’t the first time either of those problems have been encountered, but you’ll be pleased to hear that this problem doesn’t only affect Tableau - no way, not by a long shot. Qlik Sense users for example also faced the same problem, right up until QlikTech moved Qlik Sense to web auth only, where all the problems seemingly disappeared overnight. Why?

C++ vs Javascript

The straight-up answer is: the difference between the language of desktop applications vs the language of function and interaction on the web

That’s all there is to it, unless you want the boring architectural part too, in which case dear reader, plough on.

So before we go on, lets first gain a small understanding about what a Tableau workbook is, or more precisely, how its encoded, how it is stored, and then how it is opened and rendered by the server; knowing this first, will help with understanding why the server can render functions created in Desktop, but why those same functions aren’t even present in Web Auth.

The Tableau Workbook (*.twb)

Have you ever opened a Tableau workbook?
I mean really opened one - in Notepad, Visual Studio Code, Notepad++, Sublime, or any other text editor?

When you next have a spare moment, give it a go, drag the twb file into your text editor to see the output:

Open

Tableau workbooks are simply encoded as xml documents, and being an xml document, means that the file can be read using any xml interpreter. You can even edit the workbook using a text editor but be very careful, as one mistake can corrupt the whole book.

And when uploading to Tableau Server, depending as to what you are uploading will define the steps the server takes either:

• You upload a workbook, in which case the server only needs to consider the workbook or

• You upload a packaged workbook, in which case, the server needs to deconstruct (unzip) the archive, storing extracted data, and image files before working on the file

But its what Tableau Server does with that workbook file - the *.twb is where it gets interesting.

Have you ever wondered how 70 or more concurrent users can open the same workbook independently, and each manipulate the visual to meet their own requirements, without ever impacting others?

Its because the file doesn’t exist.

You read that right: the file - the *.twb that you’ve spent all those hours building and perfecting, no longer exists, having been deleted by the server the moment you uploaded it. All that work, gone - poof!

Above all, Tableau Server is fundamentally two things - a document store, and an xml interpreter, and it uses a database to hold everything it needs including, a huge nvarchar(max) field where it stores the entire xml from the workbook:
When you upload the workbook, sure Tableau Server deletes the book as its no longer required, but not before copying the complete workbook xml, and storing this in the table.

And when a user opens the workbook in Tableau Server, the ‘book’ is recreated from the stored xml, passing through the xml interpreter before allowing the user to play as they require.

This is how it is possible to upload a workbook in 2021 to a v2021 server, upgrade the server in 2024 to v2024, and then download the workbook as a 2024 version, as when requesting Tableau Server to download the file, you are actually instructing Tableau Server to rebuild the file from scratch, from its extracted code.

And this explains the why behind Tableau Server being able to render functions created in Tableau Desktop, when the same functions aren’t available in web-auth.

But it doesn’t explain why those functions just do not exist in web auth, or, why the visual renders perfectly in Desktop with perfect placement, but not always as perfectly on Server.

What is it that causes this?

Javascript, or rather, both the limitations of Javascript (js) in that which is able to achieve, and, the Javascript engine that your browser uses to render the page.

As I said earlier, the desktop applications (Desktop, Prep, Public, Reader etc) are built (coded) using C++ which cannot really be used for web applications - it can theoretically be used, although this would be containerised inside a Javascript application, and largely subject to the same limitations of js main.

But programs built with C++ offer a much greater functionality than those built with js; even tools built using Visual Basic for Applications utilising Microsoft Forms can be used to create a reasonably rich in-application program in the MS Office desktop application they are built for - there’s that word again, desktop, as Office 365 is still built using js, so it too suffers from tooling limitations.

Javascript is a very powerful language, but it still has its limitations which unfortunately place it lower on the function-tree compared with C++. But as js continues to mature, so too does the available functionality. Add in some more functionality from the various extensions available too, and we’re beginning to really lift up the web-auth experience compared with just one-or-two years ago, and certainly 5+ years ago when web-auth was still in its infancy.

Ok, so we’ve covered the differences in tooling, but why does the dashboard render perfectly on my desktop, but not always when published and opened online? Is there something wrong with Tableau Server?

This all boils down to the Javascript engine that your browser uses, and generally, which browser you are using, how its configured, which security settings you are using etc, as published workbooks natively render client-side, which means, they render on the users pc rather than the server.

Workbooks can be switched to render server-side, although graphics rendering, even simple graphics such as plotting a couple of points on a 2-dimensional chart, can be a fairly resource hungry operation that can be handled in a jiffy using some fairly low-end graphics hardware.

So going back to Javascript, as the technology has matured, the upside is that most of the engines render similarly, although the downside is that each engine might take a slightly different path when rendering, and the real downside is, there isn’t much a user can do besides changing to a different browser, as js engines are usually baked-in to the browser’s core, and system-locked preventing them from being switched to or replaced by an alternate.

So there we have it. If you've made it this far, well done. I hope this article has helped shed more light on why users receive a different experience between the 'cut-down' web-auth functionality, and the sometimes dodgy user experience of rendering published workbooks, compared with the masterpiece we've built and tested to perfection on the desktop.

It's not Tableau, not this time.

Want to improve your web authoring experience? Or even to enhance your vanilla install?

Try adding an extension, visit the extensions library for more: https://exchange.tableau.com/en-GB/extensions

And if you're ready to make the leap into development to really enhance your Tableau experience, why not give the development programme a go: https://www.tableau.com/en-gb/developer