Quick Links:
OEM Website
OEM Repo
The Own-Your-Framework Hypothesis
If you owned and understood 100% of your code and never had to deal with crazy dependency chains, abstractions, nightmare upgrade scenarios or mystery build errors, would that not be ideal? How fast and productive would you be? How easy would it be to do estimates, talk to designers and product owners or bring other developers into a project?
To maintain control of any codebase you need “framework” code. Today’s front-end ecosystem is chaos and produces tech debt that is antithetical to product development. It breaks down team efficiency by blowing up estimates, confusing discussions and creating unnecessary competence and dominance hierarchies, all of which becomes a stone in the shoe of a healthy SDLC.
Installing ready-made frameworks and flavor-of-the-month libraries leads to an anti-pattern called “Continuous obsolescence”. But what am I supposed to do, write my own framework? No. Writing your own framework and/or libraries from scratch is no better as this is a large undertaking and fails to provide the security and support that is offered by a community. So what’s the solution? Adopt one as your own.
First of all, adopting any ol’ framework isn’t going to solve much as most frameworks are fairly complicated and involve tightly coupled abstractions, highfalutin concepts and transient dependencies that have nothing to do with your project, etc. Second — if we’re being real — we are most often dealing with multiple “frameworks”. The definition of a framework is any code that calls your code (that is bad). That’s different than a library which is code called by your code (this is fine). React is a framework (it calls your code), Redux is a framework (also calls your code), Formik is a framework, Component libraries are frameworks and the list goes on. So what’s the solution?
Create a framework that has been written with adoption in mind from the start. A framework that has a simple structure, simple code, simple tests, workflow and a powerful library of components and utilities, all written around core code you understand as well as if you’d written it yourself.
Introducing OEM
Meet OEM, the dependency-free ui framework. OEM which typically stands for “Original Equipment Manufacturer” was chosen for its connotation of having a “private label” product, the ability to take something pre-existing and make it your own.
OEM is a ui framework, product starter kit, component and utility library that has (will have) everything you need to build out an entire ecosystem of web applications. Feature support for: state management, templating, styling, forms, components, utilities, etc. all written with no dependencies, no/low coupling and an every growing list of features and support that grows along with the community.
I Need Your Help
Since this is a massive undertaking, I’m starting small. I’ve scaffolded out the core structure and vision. I need devs to come in and help me flesh it out. Like minded fools who are crazy enough to try it and can give fresh perspective and evolve it into something the community will love. If you’re interested, reach out to me on github or twitter. If not, thanks for reading!
