Frequently Asked Questions
Why is this a "library" and not a "framework"?
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!
... 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
Why are some words in the documentation such as Element and Array started with a capital letter?
<var> around them EVERY blasted time I use them.
Why the cryptic one-letter variables in the source that don't match the documentation
Just trying to keep the code base small; sure they'd be reduced to single letter in the minified copy anyways, and yeah - I'm usually a stickler for verbose and clear variable names - but in this case if you have a five line function is it REALLY worth saying "element" instead of "e" or "index" instead of "i"? You want the details, that's what the documentation is for!
Why don't your polyfills match the specification
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
.length() is already an integer... if it isn't, you're not manipulating an array. Another example would be converting
Array to an object, which seems to be done for the sole purpose of making it harder to process it.
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.
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')
- 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.
What type of release this is, typically one of the following:
- An early feature-incomplete untested version. Pretty much still in the planning stages
- All planned features are present, but debugging is still in progress and it has not passed QA testing.
- 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 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.
- 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.
- 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.
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!