There is no default theme, but which is most robust? I ask because many themes not working out of box. May be most github starred.
Being completely new to Hugo, it is challenging to choose a theme primarily because I do not yet understand how information is being put together and served up through a browser. That being said, it would also be challenging to point to one theme and say, “This theme is the most robust,” because “robust” is determined by Use Case.
If I have no use for a theme that lets me use Google Analytics, why would I want to have that “robustness” in a theme?
I’ve gone back to the bookshelf example to try to understand what one theme does for one use case.
I’m not completely new to Hugo. And already created several themes myself. Speaking about robust I mean: correct implementation of templates for all urls (taxonomy, pagination etc). Correct displaying of images of any sizes, too long titles, sticky footer, etc. Attention to details. Robust theme should correctly work both with lots of content and too less content. Many themes are not tested with content size > 10000 pages (so very often pagination looks ugly), thats why a lot of areas should be fixed after install. Then JSON-LD markup implementaiton would be great.
Ahhh. I see. Is there a minimum standard for Themes and is there a theme review team?
Everything is community member-contributed. Some themes are not maintained once they are released. Others are not intended to have all features.
The theme that is referenced here …:
… is a great attempt at a “teaching theme” in my opinion, so, maybe check it out?
2 Likes
Hmm that is interesting. I will check it out! Thank you!
That’s a great idea - theme review team. Or maybe a “go to” team of experts that can advice on theming? Any volunteers?
Happily using a theme, then Hugo gets upgraded and things get broken.
Does this mean we should not upgrade the hugo we are running on our computers?
Even in Wordpress or Joomla or Drupal, themes break, so maybe a theme team or theme review team would be great. At least newbies like me have hope 
It is counter-intuitive to how database-driven web software is released, but one of the features of Hugo is it being released as self-contained packages. So if Hugo 0.17 works for a theme today, it will work for the foreseeable future. That is a strong feature, undervalued while Hugo is being rapidly developed.
“Themes” in each of those projects underwent many transformations before they got to mean what they do today. And of course an “outdated” theme can have severe consequences, whereas a Hugo theme that doesn’t render with the latest release will still produce a website with the version it was made for.
The takeaway is that we won’t need a “theme review team” until Hugo stabilizes (and maybe have a 1.0 release), so in the meantime the best we can do is have obsessive folks stay on top of which themes work (I am one such person, but I am suppressing the urge actively blog about Hugo themes at this point).
With all that regards about themes, I am wondering if a “config.toml” for the parameters make sense or if they shouldn’t be inside a separated folder structure standard such as “data/themeconfig/”.
Since to change theme you usually to modify the config.toml with the exampleSite, or ajust your own config.toml I find it could benefits of having the theme parameters inside a different yaml structure that could be easily merged instead of a single config.toml file
Potentially, a standard could be made so it is easier to switch themes and remove unused parameters ?