Tables of comparing alternatives?

[tomByrer]

I think having a chapter or section for "How is Gulp Different" or good to have, but hard to scan. Could there be a table to compare features & gotchas please? I found Wil Moore's Frontend Packagers very handy. This table shouldn't have as much prose as Wil's does (chapters cover this), but since more than 2 possibilities are going to be studied, a single table helps to scan.

I would think the source data should be in .JSON, then a script ran to turn the data into what ever format table.

It could be developed with the book, or near v0.8, to help ensure the book explains the table, & the table can help find topics. Or maybe released after v1.0 is done, so all has to be done is collate the book's info.

cheers

[Munter]

Comparison tables only make sense if the premise for each system is identical. I am pretty sure explaining the differences between build systems requires a lot more prose than just a simple table with checkboxes. Of course you could just invent new categories for each unique thing a build system has, which would just end up wasting a lot of space in a table.

I think a comparison table is probably most relevant in regards to features, not differences. So categories like "CSS minification", "JS minification", "CSS bundling" etc are probably quite useful and comparable across systems.

[sindresorhus]

Comparison table doesn't make sense. I would rather see each thing succinctly introduced and let the users draw their own conclusions.

[addyosmani]

Before we close this, does anyone else favor a comparison table or do we all agree it doesn't make sense here?

[rictorres]

I also think it doesn't make sense in this case.

[tomByrer]

I would rather see each [topic] succinctly introduced and let the users draw their own conclusions.

I would hope each topic has such a introduction (or summary) also! I want to save readers having to memorize each synopsis when they do their A/B/C/D comparison in their head. The proposed comparison is really a pivot table; the same information collated to help readers get a different view. In my programming Meetups there is always someone asking, "So how does X compare to Y & Z please?" So while each topic must have a strengths & weaknesses summary, IMHO a table is more efficient to help compare.

BTW, I'm NOT thinking a huge table, more like 5-10 rows, should be less than 1 page printed. Sorry if I was unclear before

comparison table is probably most relevant in regards to features, not differences. So categories like "CSS minification", "JS minification", "CSS bundling" etc are probably quite useful

I would like to include very general features that can be explained in 1-3 words to fit in a table. Their 'features' will be different ;) I would love to see a detailed chart for your categories ideas, but out of scope IMHO, since I assume this publication will be static-ishy. It would be hard to maintain; just the past month i believe the Gulp plugin listing has doubled, thanks in large part to some of the posters in this thread :)

[michealbenedict]

The proposed comparison is really a pivot table; the same information collated to help readers get a different view. In my programming Meetups there is always someone asking, "So how does X compare to Y & Z please?"

I get these questions often as well and found that explaining why X over Y & Z with a specific use-case always helped, as it seemed a bit hard to express tool "features" succinctly without context.

Atleast for v1 of the book, not sure having a comparison table would help.

[michealbenedict]

Its been a while since this ticket has been updated. To summarize, I think the overall sentiment here is to not have a comparison table (at least for v1). @addyosmani good to close?