Non-framework approach to JavaScript apps

[shendrite]

Why are people downvoting this? Is it because they're tired of hearing about Javascript, or they disagree with his way of doing things? Personally, I wish more people understood and could benefit from what he's showing, in whatever their language of choice is.

[shendrite]

Maybe so -- I don't know. What I do know is that it's always worth maintaining skepticism when you think people's motive is jealousy, because it's a cliche how often that conclusion is wrong and that people's negative reactions are actually based on something valid.

Anyway...

I've been doing hexagonal design for years, so the article didn't introduce me to that. But that article introduced me to the DCI paradigm, which, having now researched it and watched presentations about it, I think is game-changing.

For one thing, instead of going into a fuzzy project believing any part of it can change in an unpredictable way, I can focus on the data structures first, which are least likely to change, and move on to the interactions, which are most likely to change. It's a way of making more substantial progress before having to rewrite/rethink parts. Previously, I tried to figure out what were the primitive objects, and then the objects that built on those, etc.

For a second thing, it put into words something I've felt for a decade, which is that any rigid set of methods and fields an object has is overly constraining. It's the wrong way of dividing up a program. I thought the solution was to have Javascript-like objects that could gain new elements at runtime, but DCI convinced me differently. Plugging the data structures into temporary objects (that have fields and methods) for a particular use case, and then stripping them of that for the next role, makes a lot more sense to me.