The Elementals JavaScript project has been shelved for perhaps too long. I've had paying clients, a hospital stay, my medium writing, and a host of other issues get in the way of my working on it.
E4 was mostly abortive in that by the time I was done creating it, it was IMHO already out of date. I've in fact already moved on to what I might as well label version 5. Code-wise it's mostly ready for beta testing, what's really holding it up is creation of a new website with all-new documentation... as well as hammering out some details/methodology for "view-like" behaviors.
The biggest changes in 5 is that I'm telling a lot of the "crybaby practices" to sod off. They're not good practices, they're worry-wart nonsense that fails to leverage several advantages you can find in JavaScript's alleged "failings".
Such as the mutability of live objects -- including the system library ones -- via their parent's prototype. This can result in a cleaner syntax and LESS namespace conflicts despite the wild protestations of the opposite.
There are many reasons people say you shouldn't do it, but the big two are:
1) Legacy IE (8/earlier) can't do it.
2) You risk namespace conflicts with other frameworks/libraries and possible future changes to the langauge.
The first one I just no longer give a damn about! My "support" for legacy is to now no longer send them any JavaScript or even CSS. They get my vanilla markup and if that's not good enough, OH FREAKING WELL.
The second one is more fear and paranoia than fact. It's used as an excuse for damned near everything when in practice it happens so rarely if you bother having a good naming convention, that it SHOULD be a non-issue. The best way is to not dive for the lame excuse and instead find a unique naming scheme. To that end E5 uses a double underscore.
Which is why the underscore object goes away. For example:
_.ajax === document.__ajax
_.cookes === document.__cookies
_.make === document.__make & element.__make
That last one, the latter method is used when you want to apply it to an element as a child. If the placement attribute in the command set says where to place it, defaulting to "last".
For example, let's say you've gotten hold of a node like a h1, and you want to remove it.
document.querySelector('h1').__remove();
Deletes the entire H1.
Let's say you wanted a cross-browser safe text-content.
let text = document.querySelector('h1').__textcontent
See why such a method even needs to exist here:http://perfectionkills.com/the-poor-misunderstood-innerText/Using defineProperties we can also make a number of simpler references to values.
let code = '<h2>Sample Text</h2>'.__htmlspecialchars;
Notice it's not () for a function. Since we need to send no properties, we can just extend string to have a getter. A LOT of things frameworks and even JS itself does as methods (for no good reason) I'm making as properties via getters and setters.
Other useful properties include:
String.__regexEscape -- make a string safe to plug into a regExp,
String.__condensed -- does a trim and reduces all whitespace to single characters
Array.__remove -- removes a value, or values in an array, from the array.
Example:
let source = [1, 3, 9, 11, 17 ];
source.__remove([3, 11];
console.log(source); // [ 1, 9, 17 ]
One I really like that I've done?
Object.__entries -- an alias for performing Object.entries(targetObject).
So instead of doing:
for (let [key, value] of Object.entries(testObject)) {
I can write:
for (let [key, value] of testObject.__entries)) {
I really don't know why they keep insisting on making all these static methods you have to pass an object to, instead of just making it an accessible property.
There are also other "modernizations" I'm doing like using LET and CONST, even though I'm not a fan of either... and arrow functions which I find cryptic, but it's "expected" by others these days. I have to remind myself this isn't about me.
This has had an interesting advantage in that I'm able to replace the IIFE with just {}.
One of the biggest changes is that the "make" routine will no longer return the element, but an object where result.__element is the parent element, and the rest of the object contains references to "variables" you can set in the DOM-JON that when you change, also change the live DOM showing said "variable". Thus we get something akin to "views" but without any dom fragment / shadow-dom nonsense in the overhead.
So it is in the works, even though sadly I've not touched it since shortly before I went into the hospital in March.