diff --git a/README.md b/README.md index 19908456..dc5f4448 100644 --- a/README.md +++ b/README.md @@ -92,15 +92,11 @@ Restart `R` completely for the installation to take effect. ## Alternative packages -Someone on Twitter asked me to make more explicit comparisons to -alternatives. So here are a few totally biased (and possibly unfair) -comments. - -There are many fantastic table-drawing packages out there. Most -alternative packages have features that `tinytable` does not (yet) -support. The ones I will focus on in this section are the ones I -recommend you try if you don’t find the features you like in -`tinytable`: +Several people have asked me how `tinytable` compares to alternative +table-drawing packages in `R`. And indeed, there are many fantastic +table-drawing packages already out there. Most of theses alternatives +have features that `tinytable` does not (yet) support. If you don’t find +what you need in `tinytable`, I recommend you try one of these: - [`gt`](https://gt.rstudio.com) - [`kableExtra`](https://haozhu233.github.io/kableExtra/) @@ -108,57 +104,63 @@ recommend you try if you don’t find the features you like in - [`DT`](https://rstudio.github.io/DT/) - [`flextable`](https://davidgohel.github.io/flextable/) -The first difference between `tinytable` and other table-drawing package -is that `tinytable` covers much of the same functionality without -loading any other `R` package by default. I think it is very important -for `R` package developers to have a table-drawing package that does not -force them to import the whole `tidyverse`. In my view, this service to -developers alone justifies writing a new package. +Here are a few totally biased (and possibly unfair) comments about each +of them. + +The first difference between `tinytable` and alternatives is that +`tinytable` covers much of the same functionality without loading any +other `R` package by default. I think it is very important for `R` +package developers to have access to a table-drawing package that does +not force them to import half of the `tidyverse`. In my view, this +service to developers alone justifies writing a new package. + +Now let’s consider alternatives one by one. `gt` (65 dependencies) is an amazingly powerful table-drawing package; -possibly the most powerful in R. I like it *a lot*, and it is the first -package that I recommend you try if you don’t like `tinytable`. The +possibly the most powerful in R. I like it *a lot*, and it is the one I +recommend if you don’t find the features you need in `tinytable`. The reasons I don’t personally use `gt` on a day-to-day basis are entirely subjective. First, and least important, I find its syntax very verbose: customizing any aspect of a table always seems to take *many* keystrokes. Second, and this is obviously a reflection of my own -limitations, but I have never quite figured out `gt` actually works; it -has so many exported functions (180+!) that I get lost. `gt` is more +limitations, but I have never quite figured out how `gt` actually works; +it has so many exported functions (180+!) that I get lost. `gt` is more powerful than `tinytable`, but that power comes at the price of complexity. One goal of `tinytable` is to let you do 98% of what you -need by learning 4 simple functions (and maybe some CSS). +need by learning 4 simple functions; then you can use a bit of CSS or +LaTeX if you need extreme customization. `kableExtra` (49 dependencies) is a very flexible package [with amazing -documentation.](http://haozhu233.github.io/kableExtra/) Before write -`tinytable`, I actually made a few (very minor contributions and bug -fixes)\[https://github.com/haozhu233/kableExtra/graphs/contributors\] to -`kableExtra`. In the end, I concluded that the package was great and -drew beautiful table, but that the code base was too hard to maintain -and extend. This is inside baseball, but the problem I see is that -`kableExtra` takes tables drawn **as raw strings** by the `knitr` -package, and then applies a series of complex regular expressions to -modify those tables. The author has done amazing work here, but it’s -just a really difficult strategy to implement, scale, and maintain -(incidentally, `kableExtra` is not very actively developed anymore). +documentation.](http://haozhu233.github.io/kableExtra/) Before writing +`tinytable`, I actually made a few [very minor contributions and bug +fixes](https://github.com/haozhu233/kableExtra/graphs/contributors) to +`kableExtra`. In the end, however, I concluded that while the package is +great, its code base is too hard to maintain and extend. The challenge +on the backend is that `kableExtra` accepts tables drawn as raw strings +by the `knitr` package, and then modifies them using a series of complex +regular expressions. The author has done truly amazing work, but it’s +just a really difficult strategy to implement, scale, and maintain. +(Incidentally, `kableExtra` is not very actively developed anymore.) Finally, I really like the concept of separating styling from data, and `kableExtra` modifies the content of every cell to style its content. +That sometimes makes LaTeX and HTML code pretty hard to read and edit. `huxtable` (29 dependencies) is an interesting and powerful-looking package, but I know it less well than the others. The key design -decision of that package is that each feature is associated with a -distinct function. I understand that design impulse, because going -through the documentation of a function with 50 arguments can be -daunting. But for me, at least, sifting through a manual with 300+ -exported functions also makes for a steep learning curve. Also, I like -HTML and LaTeX code to be readable and editable, in case I need to make -micro-modifications before publication in a journal or website; -`huxtable` code is not designed to be human-readable. - -`DT` (43 dependencies) is nice, but it only draws HTML table, so that -was a non starter for me. +decision of the author is that each feature is implemented with a +distinct function. I understand that design impulse: going through the +documentation of a function with 50 arguments can be daunting. That +said, I feel that sifting through a manual with 300+ exported functions +also makes for a steep learning curve. In addition, I prefer HTML and +LaTeX code to be human-readable, in case I need to tweak them by hand +before publication; `huxtable` tables are not that. + +`DT` (43 dependencies) is nice, but it only draws HTML table, so that’s +a non-starter for me. I need HTML, LaTeX, Word, PNG, PDF, and Typst +output, depending on the project I am working on. `flextable` (43 dependencies) is nice, but it does not support LaTeX, -and I need that format for my “real job.” +and I need that format for “real work.” At this point, it’s useful to point out that there are also many packages to compute statistics and build tables (ex: `modelsummary`, diff --git a/README.qmd b/README.qmd index 6cee979f..c35b465e 100644 --- a/README.qmd +++ b/README.qmd @@ -71,9 +71,7 @@ Restart `R` completely for the installation to take effect. ## Alternative packages -Someone on Twitter asked me to make more explicit comparisons to alternatives. So here are a few totally biased (and possibly unfair) comments. - -There are many fantastic table-drawing packages out there. Most alternative packages have features that `tinytable` does not (yet) support. The ones I will focus on in this section are the ones I recommend you try if you don't find the features you like in `tinytable`: +Several people have asked me how `tinytable` compares to alternative table-drawing packages in `R`. And indeed, there are many fantastic table-drawing packages already out there. Most of theses alternatives have features that `tinytable` does not (yet) support. If you don't find what you need in `tinytable`, I recommend you try one of these: * [`gt`](https://gt.rstudio.com) * [`kableExtra`](https://haozhu233.github.io/kableExtra/) @@ -90,17 +88,21 @@ dep_huxtable <- length(tools::package_dependencies("huxtable", recursive=TRUE, d dep_DT <- length(tools::package_dependencies("DT", recursive=TRUE, db=db)[[1]]) ``` -The first difference between `tinytable` and other table-drawing package is that `tinytable` covers much of the same functionality without loading any other `R` package by default. I think it is very important for `R` package developers to have a table-drawing package that does not force them to import the whole `tidyverse`. In my view, this service to developers alone justifies writing a new package. +Here are a few totally biased (and possibly unfair) comments about each of them. + +The first difference between `tinytable` and alternatives is that `tinytable` covers much of the same functionality without loading any other `R` package by default. I think it is very important for `R` package developers to have access to a table-drawing package that does not force them to import half of the `tidyverse`. In my view, this service to developers alone justifies writing a new package. + +Now let's consider alternatives one by one. -`gt` (`r dep_gt` dependencies) is an amazingly powerful table-drawing package; possibly the most powerful in R. I like it *a lot*, and it is the first package that I recommend you try if you don't like `tinytable`. The reasons I don't personally use `gt` on a day-to-day basis are entirely subjective. First, and least important, I find its syntax very verbose: customizing any aspect of a table always seems to take *many* keystrokes. Second, and this is obviously a reflection of my own limitations, but I have never quite figured out `gt` actually works; it has so many exported functions (180+!) that I get lost. `gt` is more powerful than `tinytable`, but that power comes at the price of complexity. One goal of `tinytable` is to let you do 98% of what you need by learning 4 simple functions (and maybe some CSS). +`gt` (`r dep_gt` dependencies) is an amazingly powerful table-drawing package; possibly the most powerful in R. I like it *a lot*, and it is the one I recommend if you don't find the features you need in `tinytable`. The reasons I don't personally use `gt` on a day-to-day basis are entirely subjective. First, and least important, I find its syntax very verbose: customizing any aspect of a table always seems to take *many* keystrokes. Second, and this is obviously a reflection of my own limitations, but I have never quite figured out how `gt` actually works; it has so many exported functions (180+!) that I get lost. `gt` is more powerful than `tinytable`, but that power comes at the price of complexity. One goal of `tinytable` is to let you do 98% of what you need by learning 4 simple functions; then you can use a bit of CSS or LaTeX if you need extreme customization. -`kableExtra` (`r dep_kableExtra` dependencies) is a very flexible package [with amazing documentation.](http://haozhu233.github.io/kableExtra/) Before write `tinytable`, I actually made a few (very minor contributions and bug fixes)[https://github.com/haozhu233/kableExtra/graphs/contributors] to `kableExtra`. In the end, I concluded that the package was great and drew beautiful table, but that the code base was too hard to maintain and extend. This is inside baseball, but the problem I see is that `kableExtra` takes tables drawn **as raw strings** by the `knitr` package, and then applies a series of complex regular expressions to modify those tables. The author has done amazing work here, but it's just a really difficult strategy to implement, scale, and maintain (incidentally, `kableExtra` is not very actively developed anymore). Finally, I really like the concept of separating styling from data, and `kableExtra` modifies the content of every cell to style its content. +`kableExtra` (`r dep_kableExtra` dependencies) is a very flexible package [with amazing documentation.](http://haozhu233.github.io/kableExtra/) Before writing `tinytable`, I actually made a few [very minor contributions and bug fixes](https://github.com/haozhu233/kableExtra/graphs/contributors) to `kableExtra`. In the end, however, I concluded that while the package is great, its code base is too hard to maintain and extend. The challenge on the backend is that `kableExtra` accepts tables drawn as raw strings by the `knitr` package, and then modifies them using a series of complex regular expressions. The author has done truly amazing work, but it's just a really difficult strategy to implement, scale, and maintain. (Incidentally, `kableExtra` is not very actively developed anymore.) Finally, I really like the concept of separating styling from data, and `kableExtra` modifies the content of every cell to style its content. That sometimes makes LaTeX and HTML code pretty hard to read and edit. -`huxtable` (`r dep_huxtable` dependencies) is an interesting and powerful-looking package, but I know it less well than the others. The key design decision of that package is that each feature is associated with a distinct function. I understand that design impulse, because going through the documentation of a function with 50 arguments can be daunting. But for me, at least, sifting through a manual with 300+ exported functions also makes for a steep learning curve. Also, I like HTML and LaTeX code to be readable and editable, in case I need to make micro-modifications before publication in a journal or website; `huxtable` code is not designed to be human-readable. +`huxtable` (`r dep_huxtable` dependencies) is an interesting and powerful-looking package, but I know it less well than the others. The key design decision of the author is that each feature is implemented with a distinct function. I understand that design impulse: going through the documentation of a function with 50 arguments can be daunting. That said, I feel that sifting through a manual with 300+ exported functions also makes for a steep learning curve. In addition, I prefer HTML and LaTeX code to be human-readable, in case I need to tweak them by hand before publication; `huxtable` tables are not that. -`DT` (`r dep_DT` dependencies) is nice, but it only draws HTML table, so that was a non starter for me. +`DT` (`r dep_DT` dependencies) is nice, but it only draws HTML table, so that's a non-starter for me. I need HTML, LaTeX, Word, PNG, PDF, and Typst output, depending on the project I am working on. -`flextable` (`r dep_DT` dependencies) is nice, but it does not support LaTeX, and I need that format for my "real job." +`flextable` (`r dep_DT` dependencies) is nice, but it does not support LaTeX, and I need that format for "real work." At this point, it's useful to point out that there are also many packages to compute statistics and build tables (ex: `modelsummary`, `gtsummary`, `table1`). Many of those packages delegate the actual drawing of the tables (ie: lines and colors) to one of the table-drawing packages listed above. In that sense, `tinytable` should be seen as more of a complement than an alternative to data summary packages. The goal of `tinytable` is to help users and developers convert data frames into beautiful tables easily. What people put in those tables is outside the scope of `tinytable`. If you are interested in a package to create data summaries and regression tables/plots, please check out my `modelsummary` package: