The High-level Framework and the Low-level Dev-human

As the trend goes, there seems to be a lot of arguments involving the low-levelness of the Organic Web API™ suite.

I understand that there are some quirks about the DOM, about the CSS, and, of course, our love-hated JS language, but are they really that low-level?

It turns out that a number frameworks believe that:

Hey, change the text in that <span> to "Balloon"

is low-level, and the following:

Hey, this <span> is binded with Gift object
When I change Gift name the text in that <span> will change accordingly

is high-level.

Oh is that so?

For two objects (app data and view) to be in sync, sure, data-binding is needed, but who said that we can't do it with the Organic API?

It turns out that you for sure can.

Then you are left with two benefits:

• You don't need to understand other framework authors! We all know how hard that could be. When you try to understand other dev-human, basically you admit that he/she is thinking at a higher level, and now you can only follow.
• You can still get cross-browser compatibility. Many frameworks dispise jQuery, and some try to replace it. However jQuery is like a ten-year library still actively developed, who can handle cross-browser better than it? Moreover, why would you re-invent the wheels?

The Low-level Monkey

Monkey do not try to hide all the implementation details. What you see is what you get, what you do not specify explicitly will not get done implicitly. You get the chance to understand how browser and the Web work.

If you try to use a third party library, make sure it is not overly abstracted - the Web is not that low-level at all, it does not need extra abstraction. Remember, those are just the brainchild and avatars of other dev-humans, this is some kind of vegetable you don't have to eat.

JS is not a statically typed language, it is good and bad. I believe good more. This also means there are virtually no way to limit what a dev-human can do even within the constraints of the framework. They can still do pretty much whatever they want.

This also means that bad habits will still get into a framework-enabled app, smelly code still smells, bad performance is still bad. Why not start with a good and sound low-level implementation then solve the problem with robust (and probably small) libraries with a highly focused goal?

So, start DIY, and DRY!