Elementals.js

Latest Version: 3.7 Final 20 December 2018

Frequently Asked Questions

Why is this a "library" and not a "framework"?

For me the term "framework" has come to have a negative connotation when it comes to JavaScript. It implies that it changes how the language works, or hides from you the nitty gritty of what's really going on. Worse, most of them are IMHO encouraging people to use JavaScript to do CSS' job, or just plain put things on websites that have no blasted business in there in the first place!

Why use this instead of a "framework"?

The simplest reason is that in real world scenario's it's a full tenth the size of most "frameworks". Fast loading pages are increasingly important as bandwidth caps become a reality and search engines begin penalizing slow loading sites. No matter how much 'caching' can "help", first-load you don't get cache, and only get one chance at a 'first impression'.

The smaller size also means a faster render time. No matter how good your cache all the code must be re-parsed by the browser and run again on every page-load. It is why Google's semi-faulty "pageSpeed" tool now lists "load blocking" scripts as a penalty; they discourage their use but *NEWS FLASH* if you are hooking the markup properly, ALL good scripts are "load blocking" -- playing games with caching and load orders is only a salve, not a cure; using less code is the cure!

Frameworks also encourage people not to use the underlying language, and if you don't have a command of JavaScript you aren't qualified to say if the framework is rubbish or not! The same goes for HTML/CSS frameworks in that most of the time they defeat the point of using the underlying language, and despite all the wild claims of them being "easier" or resulting in "less code", the real world result is often the exact opposite of those claims -- at least on anything more complex than a demo snippet. Which is actually where most such frameworks card-stack their facts when slathering glittering generalities all over the place!

... and not to flog the deceased equine, but quite often frameworks seem designed to do HTML or CSS' job. See jQuery's "fadeIn" or "slideIn" functions, which are slow, jerky, unreliable and waste CPU power on goofy animations that should either be done with CSS3, or -- as I keep saying -- have no business on a website in the first place!

Where possible I tried to avoid replicating existing functionality, something that plagues a lot of "frameworks". Redundancies and changing out how things work just separates you from the core language, and that most always results in bloated, buggy and needlessly slow and complex code.

The only real exception to this is the _.classxxxx methods which are redundant to the "new" ECMAScript classList element's methods, but since I was going to provide a polyfill for those anyways big deal. Laughably the regex they use to operate are in fact faster than the Element.classList operations sealed the deal. I suspect that because Element.classList is basically an extended Array, and JavaScript arrays are slow as ****, that's why the various methods on that object are, well...

Why are some words in the documentation such as Element and Array started with a capital letter?

This represents that they are referring to an actual JavaScript type of object. So if we say "object" we mean any type of object, if we say "Object" we mean JavaScript's "Object" type or something that is an instance of or inherited from it. Also means I don't have to type <var> around them EVERY blasted time I use them.

Why don't your polyfills match the specification

For the most part they actually do, functionally identical in the majority of usage scenarios! This is a common misunderstanding if you look at the polyfills on places like MDN or the actual ECMA specifications. The thing to remember is that the code people are basing those polyfills on are written from the point of view of a C or C++ coder... completely ignoring a LOT of common sense about implementing the same things in JavaScript. They're doing a literal 1:1 translation from the C examples instead of translating them to actual native JavaScript!

An example of this would be the use of a "shift by zero" to try and typecast an array's length to integer. If you are inside the Array object .length() is already an integer... if it isn't, you're not manipulating an array. Another example would be converting this inside Array to an object, which seems to be done for the sole purpose of making it harder to process it.

They use the excuse of it being to support "corner cases" -- those small times where specific browsers screw it up -- but when pressed the people creating such code are then unable to provide actual working examples of it breaking! The whole thing just reeks to me of a failure to bother grasping how JavaScript works... Which is actually kind-of scary coming from people who are implementing a JS engine!

UPDATE Since the time of the original writing of this section, MDN has updated their polyfills and good for a laugh? They're closer to how I'm doing it! Squeaky wheel got some grease! -- only problem is they are now RIDICULOUSLY overdocumented in pure 100% derp fashion but... one takes what you can get. As EXAMPLES of how to polyfill, verbose overdocumentation is good -- problem is I suspect too many people will just blindly "copypasta" them.

Why use underscore instead of a dollar sign like everyone else?

Actually, there's another library called underscore that uses it too. I went with it on the hope that this library MAY be able to co-exist with the major frameworks that use the dollar sign -- though, well... read the next section:

Can this co-exist with frameworks or other libraries?

Little to no effort was put into testing for that, as generally speaking if you are blindly mixing libraries via cut/paste copypasta, you probably have no business building websites in the first place. Sorry (well, not so sorry) if that seems a bit harsh, but the truth often is.

Good practices were maintained to at least TRY and make it have a chance at it, but really when one of the objectives of this was to make for smaller more efficient scripting on websites, mixing and matching libraries and frameworks is the antithesis of what this library is about!

Why is this site using Disqus?

It's a quick and easy way to add comments to a static (or in this case semi-static) website. Their export feature was one of the main reasons I chose it, as at some point the current "poor man's CMS" implementation that's glueing together static markup files will (hopefully) be replaced with my next-gen PDO driven CMS.

I'll also freely admit that here at launch I'm operating on a shoestring budget hosting-wise; if this takes off unloading comment database operations to them will help me keep the site up -- at least in the short term. This takes off and becomes a success THEN I'll revisit how comments are handled.

I'm not wild about it, but as scripting based comments for static sites it seems to be the least offensive to my sensibilities. I'm also using it as a test of those sensibilities, since I have this rule that if you don't actually try to use something, you have no business badmouthing it. Plainly put after evaluating several dozen options, it was the best of the lot since it seems to have it's own post-loading mechanism and doesn't disagree with my adding their script until AFTER Window.onload. This dual stage post-loading makes the important part of the site -- the CONTENT -- come up smoothly and quickly before the page starts dicking around with fancy scripting only stuff.

The Advertising sees a similar approach when it comes to late-loading it.

How are you handling version control?

I'm from an age of programming BEFORE we had CVN, Git, etc, etc -- where Project Managers actually rode herd on the programmers and codebase instead of letting some software do their job for them -- freeing them up to dick around with charts and meetings all day or worse, just sitting there playing Farmville.

To that end I maintain a archive of milestones that gets updated when I run a shell script. I similarly have a simple deploy script that creates all the archives and updated copies and moves them to the live website.

Really I have the feeling that if this was ever to get so large that I'd need some sort of dedicated software just to track revisions, then the code is too damned big to have ANY business going on a website I build in the first place!

What is the version number scheme?

#major[.#minor] TYPE #release, date('j F Y')

#major
The major version number. Only updated when significant changes are made to available objects, methods, and functions.
#minor (optional)
The minor version number, only changed when a function or method is added or removed from a RC or Production release.
TYPE

What type of release this is, typically one of the following:

ALPHA
An early feature-incomplete untested version. Pretty much still in the planning stages
BETA
All planned features are present, but debugging is still in progress and it has not passed QA testing.
RC
Release Candidate means that it is feature complete and has passed all internal debugging tests, but the software is still in a pre-release stage to see if the public has any problems with it. It is the policy of CutCodeDown to hold a software package at RC status for at least three weeks before releasting it to production. If any bugs are found in a release candidate they are fixed, a new release candidate will be issued, and the product will remain at RC status for another three weeks.
PRODUCTION
A version considered suitable and reliable for daily use, having passed both internal bug testing and quality assurance, as well as a public trial period as a release candidate.
#release
Which release number of the current TYPE the product is at.
date('j F Y')
The date the release was built and issued for public access, using PHP time formatting of the day of month, full month name, and full four digit year.

Examples:

2.0 BETA 10, 24 February 2017
2.0 PRODUCTION 1, 4 March 2017


This scheme is simple, consistent, and easy to maintain. I swear people overthink this stuff WAY too much with short version numbers that don't really tell you anything like "51.1.01a", or just "85", or long numbers that are even more confusing like "11.0.9600.18500 U 11.0.36 (KB3191492)"... and JOE fORBID anyone include a DATE in that information! Much less a clear legible date that you can understand regardless of what your local conventions is. Nothing worse than seeomg 1/3/50 and going "Is that 3 January 1950 or 1 March 2050?"

What CMS software is this site using?

It's what commonly used to be called a "poor man's CMS" -- or at least that's what Dan Schulz used to call them.

Basically it's just using PHP to provide a template, "friendly URL" handling and other basic functionality, while gluing together static page content from sub-files. I use the "one index.php to rule them all" approach, where all requests are processed against a whitelist of file extensions I want served by Apache, and if it's not on that list it's sent to index.php for handling. I will probably write up an article at some point over on CUTCODEDOWN.COM on how to do this as I find it a fine and dandy approach to building sites, particularly since it means you have no database overhead.

IMHO if you can't handle writing semantic markup starting at H2 depth for your content, you shouldn't be writing content for any website more serious than a blog.

There is a set of underlying core routines to aid in parsing $_REQUEST, create forms, access databases, providing gzip compression of output and so forth I call "squire". I have plans to someday turn it into a CMS that will be called "Paladin X" (indicating the tenth generation of my earlier Paladin system) but with my health in the gutter, Christmas only knows when/if that's going to happen.

Maybe if someone waved enough cash under my nose... 😜

What's with the cheap-ass logo?

Hey, watch it... I'd like to see you do better while fighting off Parkinsons! No, seriously, you can do better? Do it and donate it to the project, otherwise sierra tango foxtrot uniform!

Advertisement