Skip to content

Instantly share code, notes, and snippets.

@additiveinverse
Last active August 29, 2015 14:18
Show Gist options
  • Save additiveinverse/5bb8438e75479bdbf285 to your computer and use it in GitHub Desktop.
Save additiveinverse/5bb8438e75479bdbf285 to your computer and use it in GitHub Desktop.
UI framework declaration of war

Declaring war on UI frameworks

Are we operating from the hall of justice?

  • css is a thing no one wants to think about too much (its not "development")
  • we haven't (or "can't") do markup/css properly.
  • we think repeatible patterns are cool.
  • tools != rules = a framework should allow us the greatest flexibility of implementation choices.
  • Projects are beautiful unique snowflakes. There is technical debt and intricate tribal knowledge for every project

Are we fighting Werewolves?

  • There is no magic silver bullet tucked inside any framework.
  • UI Frameworks are too smart for old platforms
    • great for green field dev where framework abstraction is knowable
    • for long term maintenance and back porting they are a vomitorium
    • Frameworks mean learning someone elses methodologies which might not fit with what exists.
    • Coding to a framework means UI controls of 100% of the markup 100% of the time. We don't. We can't always afford to fix it either.
  • UI Frameworks are NOT like Java/php/python/C#/go frameworks.
    • how many brushes do you need to apply paint?
    • they provide patterns that appease UI/UX design principles.
    • they keep "developers" in their place. Thinking about feature dev.
  • UI Frameworks are HEAVY
    • foundation is 192kb css complete (excluding JS)
    • bootstrap is 132kb css complete (excluding JS)
    • both foundation and bootstrap are full of bad practices ( heavy use of !important, descendant selectors, etc)
    • learn the utility names and parameters and markup patterns inherant to the system
    • what was the name of that variable again? its called "intellectual overhead"

Are we out of options?

Scaling up v. Scaling down

  • Pick a methodology
    • Lightweight mixin libraries
    • Only half dependant upon other peoples code
    • Should be close to native css syntax
    • Allows us to jump in providing just enough scaffolding to be useful
  • Pick a framework
    • Learn it
    • Teach it
    • Develop to it
    • Refactoring the ui codebase over time (step into the chilly waters of despair!)
    • Use what we need and toss the rest.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment