Skip to content

Instantly share code, notes, and snippets.

@balupton

balupton/README.md

Created March 12, 2013 22:31
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save balupton/5147695 to your computer and use it in GitHub Desktop.
Save balupton/5147695 to your computer and use it in GitHub Desktop.
Download ZIP
BEM HasGeek Workshop Notes (2013-02-24)
Raw
README.md

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
@balupton
Copy link
Author

Discussion continued here: http://branch.com/b/how-bem-solved-the-issue-now-developers-facing-a-long-before

@arikon
Copy link

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