Custom Tabs: Hillbilly Tabs in Modern SharePoint

Worth a direct correction before anything else: “Hillbilly Tabs” isn’t a generic jQuery/Script Editor technique — it’s the name of one specific, real, open-source SPFx web part built by Mark Rackley, and describing it as DOM manipulation via a Script Editor web part describes a different, unrelated (and now largely non-functional) approach entirely. This post covers what the actual project is, how it works, and the real caveats worth knowing before deploying it — including one the author states himself.

In this post: What it actually is · How it’s used · The real caveat the author states himself · Currency: worth checking before you deploy it · An alternative worth evaluating · When would you actually use this? · Related reading

What it actually is

Modern Hillbilly Tabs is a real, packaged SharePoint Framework web part — not a DIY jQuery snippet dropped into a Script Editor web part, which is a different, largely non-functional approach on modern pages now that custom script is blocked by default. It groups other web parts already on the page into a tabbed interface, deployed the way any SPFx solution is: uploaded as a `.sppkg` to the app catalog, then added to a page like any other web part.

How it’s used

Upload the solution package to the tenant or site app catalog.
Add the “ModernHillbillyTabs” web part to the section of the page where the tabs should appear.
Add the web parts meant to become tabs to that same section — the tabs web part organizes whatever else is already sharing its section, not content added elsewhere on the page.
Edit the ModernHillbillyTabs properties and use “Manage Tab Labels” to assign a label to each web part in the section.

Worth knowing going in, straight from the project itself: web parts show up generically as “Web Part 1,” “Web Part 2,” and so on in that label-assignment step, with no identifying title — some trial and error correcting a mislabeled tab is a normal part of setting this up, not a sign something’s broken.

The author’s own description acknowledges this “goes against best practices for manipulating modern SharePoint pages” and ships the solution as-is, without warranty — worth reading before deploying it, not after something breaks.

The real caveat the author states himself

Worth taking seriously rather than glossing over: Mark Rackley’s own write-up on the project says he initially resisted building this at all over DOM manipulation concerns, only building it after repeated requests, and explicitly notes it goes against recommended practice for modern SharePoint pages — offered “as-is,” without warranty. That’s not boilerplate disclaimer language to skip past; it’s the author being upfront that this pulls off something modern SharePoint’s page model wasn’t really designed to do cleanly. Worth weighing against a genuinely native alternative — separate pages linked from a navigation menu, or the Quick Links web part — before reaching for a tabs solution at all, if the content doesn’t strictly need to live in one tabbed view.

Currency: worth checking before you deploy it

Worth confirming directly rather than assuming: the project’s GitHub repository shows its last meaningful update in March 2021, targeting SPFx 1.13 — a genuinely old SPFx release relative to the current toolchain, which has since moved through several major changes, including the gulp-to-Heft build system switch covered elsewhere on this site. A compiled `.sppkg` package generally continues running fine on a current tenant even after its source code has aged — SPFx maintains strong backward compatibility at the runtime level — but building it from source yourself, rather than using a pre-built package, may hit friction against a current Node.js/toolchain setup that didn’t exist when the project was last touched. Worth checking the repository’s actual current state before committing to it, not just trusting a two-year-old search result or this post’s own description of it.

An alternative worth evaluating

Hillbilly Tabs isn’t the only free option — spfx-40-fantastics is a broader open-source SPFx sample collection that includes its own Tabs component alongside dozens of other web parts, with a longer commit history suggesting more sustained development over time. Neither project carries official Microsoft support — both are community-maintained, issue-tracker-only projects — so the real evaluation criteria are the same for either: check the actual current repository state, not a description of it from any point in time, before deploying either one to a production tenant.

When would you actually use this?

Several genuinely related web parts need to occupy the exact same visual space on a page, and switching between them by clicking is the actual requirement — not just “the page feels long.”
A page that just feels long or cluttered — separate pages linked from navigation, or simply reordering content, solves the underlying problem without adding a community-maintained dependency to manage and keep working across future SharePoint updates.
An internal tool or team site where a non-critical customization breaking during a future platform update is a minor inconvenience, not something with a support obligation attached — a reasonable risk tradeoff for a low-stakes site, less reasonable for something customer-facing or business-critical.
You’re not sure whether the underlying need is really “tabs” — worth genuinely questioning before adding an unsupported customization, since it’s a one-way door only in the sense that removing it later means restructuring whatever content ended up depending on the tabbed layout.

SharePoint Online Modern Script Editor and Its Consequences — why the DOM-manipulation approach this post originally (and incorrectly) described no longer works by default.
Start Your SharePoint with SPFx — current toolchain setup, relevant if building a project like this from source rather than using a pre-built package.

A named, working solution to a real page-design problem — worth using with eyes open about what it is (a community SPFx web part, not an officially supported pattern) and its actual current maintenance state, rather than assuming either from a blog post’s original publish date. The name itself is the author’s own honest framing: not a polished, officially blessed feature, but a genuinely useful workaround for a gap modern SharePoint’s native web part model still hasn’t closed.