Simple Component Pattern

import styles from './some.css';
import template from './some.html';

export default {
  constructor() {
  
  }
  template,
  styles
  /* my component class code here */
}

As soon as we write code against a framework, we have legacy code. For any company, new apps and features make the money. Existing features and apps pay the bills. But, the code behind any of those is written in the past as soon as it is written. And, we don't have a digital langoliers to come along and clean up behind us. We have stale code based on dependencies that live in the past. Where are our code langoliers? How can we pull what is written in the past into the present?

I have this fuzzy concept of code written in a current standards compliant way that is pure and decoupled from frameworks. Code written in this way would be able to have frameworks layered on top to interpret the pure standards compliant code and enhance the pure code from the outside rather than having the hooks written inside.

This outside-in enhancement would require static interpretation of the code like current patterns do now. Current patterns typically use some sort of demarcation like braces or double braces. What if there was another way to establish patterns that required no non-standards demarcation or signature. Could custom elements/web components be enough? Would just interpreting everything work? What about dynamic generation of components?

This outside-in approach is not new. Jquery is probably the most famous practicer of outside-in enhancement utilizing existing standards, CSS selector standards specifically.

Maybe I am asking too much. what is it that I am really trying to accomplish? I want to be able to write as much of my code in a standards compliant way that will work as much as possible without compromising the standards. Frameworks always ask you to deviate from the standards. The standards are that common ground on which we all walk whether writing an angular, vue, react, or any other framework based app. But, then the frameworks require you to break those standards. Maybe it isn't standards. Custom attributes with a data prefix are not a deviation but a way to convey information whether meta or actual. But, an data-ng-something means nothing to react but plenty to angular. The name spacing seems necessary. For example, if we were to make this new way utilize something like data-repeat="...", then no one could ever use data-repeat as an attribute in their code. It would become a reserved word for attribute names. So, we could go back to a selector-based outside-in approach.