This is my last suggestion, I sent a first suggestion, this is my last suggestion. I mentioned this as Baserow is amazing software, has many cool features. But, these two features I mentioned are personal stuff, I hope it helps more people using Baserow not just me. I tried to submit this idea in official contact form, but also got no response.
Problem
I don’t know if my data is heavy ​​to be processed ​​in the software or if it’s the graphical interface that can’t handle this data. I talked about an appropriate visual feature because if we have fewer elements to render, the the Baserow software will be faster.
Solution
There are web frameworks without javascript, only with html and css. This would be too good as it can allow for better digital security without trackers which is used a lot on the web with js.
So if i’m understanding you correctly you have tried to make a large table in Baserow and it was too slow for you needs? We have a number of changes coming soon to hopefully speed up the UI with large tables and other future plans here also.
As for your suggestion about building a HTML/CSS only renderer for Baserow tables I do like it. However i’m a bit confused about tabler, it seems to be an admin panel dashboard template and I’m not sure what that has to do with a table?
However one key problem i see with a no JS solution is that showing large tables on a single page would not be possible. if you have a table with too many rows rendering a single huge static HTML view would eventually become to slow to make / view in a webpage (i think). This is one key reason why we need the javascript, to dynamically calculate and only show the rows that are relevant. You could get around this with some sort of “only render the first 1000 rows, you have to scroll down and click a link to see the next 1000 etc”.
Are you also imagining this HTML/CSS only version still lets you sort, filter, search, basically do everything you can do on the current site? if so that would be a very large piece of work to accomplish I believe.
If it’s just, show a simple table view which is HTML/CSS then that is simpler. When we come to building the functionality to embed a Baserow table in your own website then it might make sense to think about this then. But otherwise do you believe this feature is more important than any of the ones we have in our current roadmap (scroll down on https://baserow.io/ to see the roadmap)?
I think one way to increase speed and performance would be if we had paging. That is, 100 or 1000 lines, the rest is on the next page. And so we’re only rendering 100 or 1000 lines per page
<script src="https://cdnjs.cloudflare.com/ajax/libs/json2html/2.1.0/json2html.min.js"></script>
<script>
//api axios
function apiLogin (domain, token){ // define 100 or 1000 lines
axios({url: domain, headers: { Authorization: "Token {token}"}})
}
// api data // return api
let data = [
{"title":"Heat","year":"1995"},
{"title":"Snatch","year":"2000"},
{"title":"Up","year":"2009"},
{"title":"Unforgiven","year":"1992"},
{"title":"Amadeus","year":"1984"}
];
// template data from api
let template = {'<>':'div','html':'${title} ${year}'};
//render
document.write( json2html.render(data,template) );
</script>
Yup paging would fix the “rendering a huge html problem”. But is that all you are suggesting here? Do you also want the big HTML table to let you sort/filter/search/add new fields/edit values etc? Or are you happy with it being 100% non interactive and read only?
No. In the rendering part, you render the table information as div, the best would be semantically the html element of type li or table, because the element of type li, as required by official W3C documents, is for html components of type list. The table rows, in my view, are of the li type, besides, li is faster to render than the div if you look at the documentation of the DOM - Document Object Model which is what makes HTML work correctly in the browser.
The li type is fast and agile and semantically correct within what the W3C proposal offers. The W3C is responsible for HTML in browsers.
Before:
Divs are content divisions, not intended to be li.
The best would be a tag <table>, but tag <li> is better if you have a lot of information, I indicate the tag <li> instead of the tag <table> because of that.
However i’m a bit confused about tabler, it seems to be an admin panel dashboard template and I’m not sure what that has to do with a table?
Baserow’s interface is not fluid, that is, it is difficult to use, tabler.io has a friendly css interface, it is a visual example. Like, you guys can add some frameworks to the Baserow. You can use some visual framework like boostrap, material-ui, tabler.io
Are you also imagining this HTML/CSS only version still lets you sort, filter, search, basically do everything you can do on the current site? if so that would be a very large piece of work to accomplish I believe. When we come to building the functionality to embed a Baserow table in your own website then it might make sense to think about this then.
Hi @anon7289648 , thanks for putting in all the time to investigate potential performance issues and solutions for Baserow. Replacing the div elements with ul or li is not going to make a difference. The difference of a browser rendering these DOM elements is negligible. The biggest problem, if you for example have a lot of fields in a single table, is that we need to render all the cells at the same time. This is quite resource intensive because we’re using a Vue.js component for each row and cell. We only render the rows that are visible in your browser to make sure we don’t have to render 100k rows, if you have that many. Only fetching and showing the rows that are visible in your browser is comparable to having different pages, it’s just a nicer user experience because they don’t have to think about on which page their data is. In order to improve the performance further, we could for example only render the cells that are visible. There is already a merge request for that here: Draft: Don't render out of screen columns (!361) · Merge requests · Bram Wiepjes / baserow · GitLab.
Using a framework like tabler.io isn’t going to make any difference because the performance problems have nothing to do with the HTML/CSS part. It has to do with the JavaScript part. Apart from that, we have created our own UI/UX framework that’s specifically made for Baserow. That allows us to be very flexible and specific in what we would like to build, which results in less CSS code. I would like to invite you to take a look at our CSS code and see for yourself, it can be found here: web-frontend/modules/core/assets/scss · develop · Bram Wiepjes / baserow · GitLab.
