These are chat archives for bem/talk

21st
Aug 2014
Vladimir Starkov
@iamstarkov
Aug 21 2014 19:42
I think noDeps is unnecessary complication of BEM methodology, because it was used only in one file only for one block. I searched noDeps in code of user bem at github http://git.io/cXA2cw
Alexej Yaroshevich
@zxqfox
Aug 21 2014 19:43
Calm down, It's just because in core library there's no need to use it.
It's widely used in some different custom libraries, projects, etc.
But probably you can offer some better way to replace or cancel some dependencies?
Vladimir Starkov
@iamstarkov
Aug 21 2014 19:47
why node modules system not need to cancel any dependencies?
Alexej Yaroshevich
@zxqfox
Aug 21 2014 19:49
Because it can load more than need. Some code parts just won't be executed.
While you working with browsers and need to decrease file sizes you just need it.
Or something like this.
Vladimir Starkov
@iamstarkov
Aug 21 2014 19:52
we can have smaller blocks, which will be not so greedy as current ones and will have in deps only minimal stuff
so problem of size will be solved
Alexej Yaroshevich
@zxqfox
Aug 21 2014 19:53
Agreed. It's possible. But atm we can't avoid it. We must have these smaller blocks (with perfect design) to remove noDeps from standard.
Sergey Berezhnoy
@veged
Aug 21 2014 19:54
if you think that noDeps is unnesessary just do not use it ;-)
Alexej Yaroshevich
@zxqfox
Aug 21 2014 19:54
@veged As I see they parsing deps for some reason. So probably it will be a problem to ignore it.
But noDeps already used in core libraries
Actually hard to tell but sometimes you just need to replace something with something better, and have no time to refactor base blocks. And MUCH easier just to cancel something used in super block.
Sergey Berezhnoy
@veged
Aug 21 2014 19:56
we talk about our libs otr BEM methodology? ;-) you can implement your own blocks and deps as much as you like and it still would be BEM
speakeng about our libs — we doesn't
invent any other way
Alexej Yaroshevich
@zxqfox
Aug 21 2014 19:57
What if Methodology with bem-core ;-)
Sergey Berezhnoy
@veged
Aug 21 2014 19:58
so we open to suggestions — but they should fit our needs of bem-core usage
you can fork bam-core and "fix" noDeps
but it's really weird when you considering some solutions as "unnecessary" based only on your usecases — we doesn't add any code or concept without real life need
Alexej Yaroshevich
@zxqfox
Aug 21 2014 20:00
;-)
offline topic again
Vladimir Starkov
@iamstarkov
Aug 21 2014 20:02
search on github "noDeps user:bem" — there are no usage in bem-core or bem-components, only in deprecated bem-bl
Sergey Berezhnoy
@veged
Aug 21 2014 20:02
anyway — we open to suggestion about another possible solutions, but in code format
Alexej Yaroshevich
@zxqfox
Aug 21 2014 20:03
Ah. Sorry then.
Sergey Berezhnoy
@veged
Aug 21 2014 20:03
so what the problem then? if it's doesn't appear in bem-core (which you parse with own tools)
Alexej Yaroshevich
@zxqfox
Aug 21 2014 20:03
I just thinking about time. 3am?
Sergey Berezhnoy
@veged
Aug 21 2014 20:04
just close your eyes to noDeps ;-)
Vladimir Starkov
@iamstarkov
Aug 21 2014 20:09
At current moment BEM consumers has no real need in noDeps because core BEM libs has no noDeps itself, maybe it's time to deprecate this complicated part of deps specification?
if core libs can live without noDeps, so it is something redundant and end BEM consumers will can live without it too?
Sergey Berezhnoy
@veged
Aug 21 2014 20:56
as I say — it's need in some cases, but it's no penalty for those people who doesn't need noDeps (just skip this part of specs)
it's incorrect to make desision about noDeps based only on core libs and you own usecases — mainly it start to roll when you have few more laters of libs and some projects
Sergey Berezhnoy
@veged
Aug 21 2014 21:01
also I think it's no so big part (in terms of information volume) comparable to other stuff — so "economy" after deprecating noDeps not so significant
Alexej Yaroshevich
@zxqfox
Aug 21 2014 21:04
depsByTech is much bigger part y ;-D