We are going to start a new web project for scientific visualization with similar (but limited, of course) functionality to Paraview - like filtering and processing the data. The main goal is to have a server-side rendering. The UI could be any-based. We are considering paraviewweb and trame as a candidates for the core framework. So the question is which one is better for this? Which pros and cons both have? Having some experience with a paraviewweb we found that trame as a new approach to the web application development. But after brief look into trame it seems like it’s like a low level version of paraivew - with it you can have all control over the rendering. At the same time you should implement a lot of filtering logic on your own. As well as other logic like remote folder browsing content, multiple dataset handling, selection, etc. But this is only the first impression.
Looking forward for suggestions or some comparison info.
Trame is based on VTK/ParaView Web and aim to improve the development speed by lowering the complexity of the application and enabling a wider set of developers to contribute.
Basically trame offer a built-in generic client that let you define your application easily and quickly from the server side. It abstract and optimize the network exchange and remove all the boilerplate code needed when developing in plain VTK/ParaView Web.
Trame has a strong reliance to Vue.js which means you can easily create your own widgets and enable them within trame if they are Vue based.
Trame can work with either VTK or ParaView like ParaViewWeb (even if the name is confusing here).
Usually you need to write more code when using paraviewweb (=vtk.js+wslink) than doing with trame. To my knowledge with both VTK/ParaView Web and trame, you need to implement your own logic for filtering, dataset handling, selection and more. Unless I don’t understand what you are talking about? Unless you are comparing the Python code of VTK vs Python code of ParaView?
In general nowadays, I would go to trame unless the client side needs to be in something else than in vue.js.
Thank you for the details. To be honest I don’t see a way to lower complexity of code while using trame. Moreover, it even seems opposite.
Let me explain a little bit what I mean. Lets take as an example browsing of the remote server directory. In ParaviewWeb I need just to call ‘file.server.directory.list’ method, what would be the analogue for that in trame?
Another use case would be to import some dataset. In ParaviewWeb I’ll call ‘pv.proxy.manager.create.reader’ method and that’s it. Now I have an ID for that reader and can add any other sufficient filter to it and do any other needed operations with it. And I can import and render any number of datasets simultaneously and control their states using corresponding IDs etc. On the other hand, as I understood from the trame samples, I need to create a lot of code lines just to open dataset, setting up all necessary properties. It’s good to have full control over the render in some cases but what about some out of the box capabilities for the cases when such low level details approach is too much?
It’s clear that ParaviewWeb is a pvpython process running on server-side. I`m trying to understand, what is trame in a nutshell?
May be I didn’t get the things right, I really appreciate the work you’ve done and products you’ve created. But even from the perspective of the samples ParaviewWeb is looking as mature software package with rich API and functionality taking minutes to launch and use. Also with possibility to use any UI client-side framework (instead of Visualizer.js) including Vue.js.
While Trame looks like the very first version of product with simple script samples from which it’s hard to understand where is server-side and client-side logic and how it can be used to build real applications.
Thanks for your feedback and clarifications. To be honest if you are already tapping into existing protocols and have no issue binding them on the client side, it is true that you don’t really need trame.
Remember trame is not killing ParaViewWeb, it is just based on top of it with a built-in client and infrastructure to streamline client/server binding. In trame, you can still register your paraviewweb-protocols. But if you do that, you probably have your own js-client and therefore the benefit of trame start becoming smaller and smaller unless you create vue-widgets that you orchestrate within trame which rely on those protocols by using the provided wsClient.
But the point that I was trying to make was if you want to bind a method or a variable between the client and the server, look at the amount of code you need to write for both. You will see that trame wins without question.
For your use-case, when you are heavily relying on existing protocols, it is true that with trame you will have to implement them within your application rather than using the one we wrote a while back. To look at the concrete example you can see how I implemented the file browsing with ParaView-Visualizer using trame here. That class define both the client and the server. And then its usage with the file loading logic.
Basically trame kind of let you forget the client side, so you can write your application as a whole in plain Python rather than thinking of it as a client/server and API you need to call.
If we want to go with separated client/server logic and for example use Trame how can we separate client and server logic? In other words, is there a samples somewhere for Trame client and server launched as separate applications? As far as I understood Trame is based on pywebvue server, lets imagine we launched it as a process or docker image. Where should we take a client to connect to that server?
Am I right that to utilize existing PW protocols we should launch Trame on top of the PW web? Or is there other way to import that protocols in pywebvue? The same question goes about plugins.
Client/Server distinction is the same as pvw except that with trame we always serve our client by default. But sessionURL and so on still apply if you just want to reach to it via ws only. With pvw I was always serving my client code via apache/nginx and not the pvw server. So it would be the same… Otherwise just add the --content arg like in pvw and you will be all set to point to your client.
Trame/pywebvue is PW web. Pywebvue internally register PW protocols and allow modules/plugins to register more. It is just exposed via a different API than the basic registerXXX in pvw as we aim to bundle client/server rather than keeping them separate like standard web development. Simput do register its own protocol.
But like I said, if you are not aiming to use any of the trame state, triggers, state reactivity and built-in client. Adding that extra layer on top of pvw seems useless. It won’t be armful for the perf but it would provide a more convoluted solution than plain pvw. With trame you will constantly be fighting that uniform app+plugins concept while you will always be looking for that client/server separation.
Another way of thinking of the difference between pvw and trame:
for pvw we expect backend/frontend/fullstack developers to work with it.
for trame we expect any app developer to work with it.