Create a gist now

Instantly share code, notes, and snippets.

What would you like to do?
BEM HasGeek Workshop Notes (2013-02-24)

BEM HasGeek Workshop Notes (2013-02-24)

  • BEM seems like it solved a lot of today's problems way earlier than everyone else
    • Modules
      • Versioning
      • Installations
      • Requiring
      • Concatination
    • Compilation
    • Contextual Consistency
    • Validation/Linting
  • These days these problems are just starting to be solved by the community, and in a very fragmented way
    • Modules
      • Component/NPM/Bower for installations
      • AMD/Browserify for including
      • They're good, but they don't solve the issue of context (a consistent way of doing things across modules)
    • Templating
      • Plenty of pre-processors out now
      • Handlebars has support for blocks
      • Define different templating engines as "Technologies", modules then specify what "Technologies" they are dependent on
    • Validation/Linting
      • TravisCI
      • Sublime Linter
      • Grunt Linter
  • However, none of these alternatives addresses the issue of cross-resource/cross-task communication (or rather the "context" problem), bem addresses this
    • There are attempts at addressing this outside of BEM currently, however the situation seems a bit dire with many competing non-complete or non-function efforts - e.g. grunt, node-tasks, flatiron, big, component, bower, browserify, es6 modules - non of which solve the whole scope of the issues as well as BEM
  • All in all, it seems the main issue with adopting BEM is the following
    • Large learning curve which may not be justified by the simplicity of the alternative tools out there (this can be good or bad)
    • The lock-in compared to being able to interchange alternative workflow tools out there (this I could be completely wrong about)
  • In conclusion
    • The ideal use cases seem to be
      • Large scale front-end projects
      • Front-end projects where modularization of visual components is incredibly important
    • And poor use cases seem to be
      • Small size front-end projects where the investment costs outweighs the benefit
      • Front-end projects where the design is not modularize-able (could be wrong about this)
      • Back-end projects

arikon commented Mar 13, 2013

The ideal use case is startups also. BEM defines structure which could scale when time comes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment