I've been developing a system called Chintz for working with technology-agnostic design systems and pattern libraries. The idea is that you should be able to create web components in a library, and that they can then be directly used in websites built in any language or framework.
If you've been following the hotness then you'll know that everything is written in JSX these days so get over it, but if you've also been around a while you might have noticed that new hot things come and go. New things are often great improvements, but however great they are they tend to be usurped sooner or later by something even better.
Brad Frost's post Managing technology-agnostic design systems describes a systematic solution. The idea is to have a design tier of components, which are converted for each flavour of tech in your ecosystem. That's a pragmatic way to not find your design system getting thrown out with the bathwater of your old technology stack.
When I worked at BBC News I was lucky enough to collaborate with the GEL team who develop the BBC's pattern ecosystem in a similar way to that which Brad describes. The BBC is an archetype of the kind of organisation which has a million and one technology flavours and a standardised look and feel, and it takes a lot of effort and activity on the part of GEL and the departmental design teams to keep it as consistent as it is.
One of the great leaps forward that happened while I was there was Shaun Bent and Al Jones's work on GEL Foundations, which is a flexible Sass implementation of the GEL guidelines on grid, typography, and iconography. It was readily adopted, and showed that sharing the code itself was possible, but perhaps only because Sass had become a de facto standard for CSS. Sharing HTML components would be more difficult, with teams using a wide variety of templating systems across the organisation.
The question is, how much could be automated? Could you build a repository of components, and then have those directly reused in codebases of any language or framework? Chintz is an attempt to answer those questions.
Chintz is a specification for component libraries. The idea is that by organising your components parts in a standard way and using manifest files to give the parts metadata which defines their dependencies and data types, you can then programmatically transform those component parts into any number of intermediate formats or consume them directly in an application by using a Chintz parser for that language.
For example you may use a chintz-react parser to transform your Chintz library into a set of JSX components that your React app uses directly. You may also use a chintz-ruby parser within a separate Sinatra app to render the same components from the same library, without duplication of code.
The spec in a semi-complete state. It needs tidying up and improving, and it's a bit out of date with actual implementations I've done.
In terms of tools there's a Node parser, a PHP parser, and a hack-day-code Ruby parser. All need work, but are working enough to prove the concept.