Extreme decoupling or all-as-a-module

I opened my laptop in the morning and found one of my open tabs in Nightly was for Vue.js. I don't even remember how I ended up there. Was I reading about frameworks? Did anyone send me the link? Who knows!

But I was curious. I am not a megafan of frameworks, but I like looking at them. One, because their idioms are often adopted by other developers, so it's good to be aware of where are things going. And two, because frameworks do lots of "magic" in the background, and I always want to know how they implement their "magic"---maybe I'll want to adopt some of it!

So instead of closing the tab, I perused the page. It has a virtual DOM as React does, but they seem to take great pride on their overall minimalism (small file size, little intrusiveness). The examples are amongst the most readable I've found for frameworks when it comes to the JavaScript API; the HTML directives are as alien-feeling as most frameworks.

Later I was discussing this strange incident with friends ("I found an open tab in my browser---do you think this is a signal from the universe that I should get into Vue.js?") and Irina also highlighted the fact that Vue.js "components" might be simpler to build than the equivalent in React, and also be less coupled.

This derived into talking about The Dream:

You know what the dream is? Have everything be an npm package that I can plug in to any framework I like. And everything is packages packages packages

📦.js

[caption id="" align="alignnone" width="429"]Oprah giving free packages away to everyone You get a package! And you get a package! And you get a package! And you get a package! And you get a package... everyone gets a package![/caption]

(Irina demanded an Oprah themed meme)

And of course this reminded me to earlier conversations with chameleonic Jen about modularising everything and maximising reuse. She would propose, for example, abstracting a card game into separate modules; one for handling the rendering, other for handling card games in an abstract way, another one for handling a specific type of game. This way you could build multiple games by just providing an implementation for the specific game. (Games are notoriously often not built this way).

Likewise, Aria talked about radical modularity at Web Rebels and the notion that if your modules are small enough, they are done. Finished. You rarely need to ever touch them again (unless there's a bug). Watch the talk: it's very inspiring.

I really like this "pure" idea, and can work very nicely as long as you keep your data and logic separate from your view.

Unfortunately, the issue is that UI code often intermingles both data and view, so you end up declaring your data as instances of whatever base component the UI is using, which is not very maintainable on the long run. If you want to change the UI you will need to take the 'data' bits out of the UI code, or write some sort of adapter between "UI code" and "data", to have to only change "adapter" when you decide you don't like your current view layer. This could be a performance hit, so you might want to sacrifice flexibility for performance.

But hey... everything in computing is always a trade-off!