CSV files are one of the most common formats used to share data. Yet, opening very large files of this file format can be challenging for many applications. Since CSV formats are commonly opened with Excel on Windows and Numbers on Mac, one would expect these applications to open these files very fast. Surprisingly, they are extremely slow. There are many utility apps out there that provide various levels of functionality to manage large CSV files.

CSV is one of the common file formats for SQL Frames as well. However, since SQL Frames is written in TypeScript (which compiles to JavaScript) and JavaScript has a maximum limit for the size of a string, there can be challenges dealing with large CSV file sizes.

Interactive dashboards often come with slicers that provide the ability to visualize the same dashboard by slicing the data. However, many dashboards and BI tools don't have a way to keep the slicers fixed (or floating) at the top so that as the user scrolls down the dashboard (or a large data table) the slicers are always visible. This results in a poor UX forcing the user to go up and down as they want to slice and visualize the charts and reports that are well below the page fold.

SQL Frames provides a no-code UI that puts the end user in control of having the slicers fixed at the top or bottom of the page. This allows the user to scroll to any chart or data grid on the page and then start using the slicers that are readily accessible. Here is an example of such a UX.

Large enterprise application software companies like Oracle and SAP used to have powerful desktop applications. During the Internet boom of the late 90s, these companies tried to provide a class of software called "self-service" where all employees, and not just those working on back-office data could interact with the applications to perform simple tasks. The web UI of that era was very basic and so it wasn't possible to create desktop grade enterprise applications for the power users.

As time passed, concepts such as PPR (partial page rendering) and AJAX have helped to push the sophistication of the UI in these web applications to the extent that these days even the power user applications are completely delivered via the web. However this used to be a dark art until the advent of the frameworks like Angular and React. These days anyone can build extremely complex UI very declaratively.

This complexity on the fontend perhaps pushed the balance of the backend-vs-frontend. While historically backend development used to be hard and meant for advanced developers these days the complexity of the frontend also requires highly trained developers and in some ways simplifies the complexity on the backend. No wonder, a good React developer charges $250/hr or more these days.

In spite of all these advances, I think there is one area where things haven't really caught up enough. That is the ability to deal with semantically displaying large amounts of data. It could be too many rows or too many columns or both. Basically, the lack of an awesome semantic data grid. But SQL Frames wants is making progress to change that.

Bar chart racing has been a popular visualization technique that we all have seen in the last couple of years. In this post I will discuss about how bar chart racing works, it's benefits and drawbacks, a more generalized concept of bar chart racing provided by SQL Frames along with how to overcome some of the mentioned drawbacks.

There are a wide class of questions that can only be answered declaratively by using advance sql concepts like sub-queries. Sub-queries are also expensive compared to normal queries and hence one of the reasons that not all low-code platforms provide them.

"What are all the opportunities with no activity in the last two weeks" is an example of a query that requires sub-query and SQL Frames just introduced support for a wide variety of sub-queries in both SELECT and WHERE clauses.