Skip to content

Commit

Permalink
readme alternatives
Browse files Browse the repository at this point in the history
  • Loading branch information
@vincentarelbundock
vincentarelbundock committed Feb 6, 2024
1 parent 9e155d0 commit ca222b9
Show file tree
Hide file tree
Showing 2 changed files with 42 additions and 38 deletions.
62 changes: 32 additions & 30 deletions README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -92,28 +92,29 @@ 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/)
- [`huxtable`](https://hughjonesd.github.io/huxtable/)
- [`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
Expand All @@ -122,26 +123,27 @@ 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).
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
obviously 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 learn 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
`tinytable`, I actually made a few [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.
and extend. The challenge 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.

`huxtable` (29 dependencies) is an interesting and powerful-looking
package, but I know it less well than the others. The key design
Expand Down
18 changes: 10 additions & 8 deletions README.qmd
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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/)
Expand All @@ -90,15 +88,19 @@ 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 first package that I recommend 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 obviously 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 learn 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 write `tinytable`, I actually made a few [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. The challenge 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 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, 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` 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 was a non-starter for me. I need HTML, LaTeX, Word, PNG, PDF, and Typst, 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."

Expand Down

0 comments on commit ca222b9

Please sign in to comment.