Programming

Full Stack Web Developer

Logic Fully Realized

PHP (PHP: Hypertext Preprocessor) — wishes it was C++

You know you’re in trouble when the acronym for PHP is an infinitely recursive loop. Some developers take that example too far and actually implement it as a strategy in code; it of course has a time complexity big-O of O(∞). Not the most efficient algorithm as it never completes.

All infinite recursion jokes aside PHP started out as a pretty bad programming language, continued to be a bad programming language for a while and only recently with the mass use of WordPress has it really become somewhat of a decent server side scripting language (and got the attention it really needed). Don’t get me wrong all languages go through a series of improvements, enhancements and either persist or die out due to popular demand, usability and competition. One thing we know about PHP is that it isn’t really going anywhere for the foreseeable future. Almost 83% of all websites who’s server side programming language we know are running PHP. It’s literally most of the internet (by volume).

Starting out as a relatively loose and inconsistent language PHP made strides to become more like C++. The introduction of classes and objects made PHP a much more extensible language, you could build out modular libraries and full scale applications with proper scope. The addition of namespaces later in PHP 5 also brought more scope into the language and solidified modular development. Today with PHP 7, the Zend engine was completely redesigned and performance was greatly enhanced; up to 76% over PHP 5.6.

Regarding my professional experience, most of my programming time was spent writing PHP. API integration, data importers, parsers, mail functions, application libraries, database layer classes, models, views and controllers (lots of MVC). Quite frankly PHP has been an extremely useful language, easily facilitating information between web services, databases and web severs; designed specifically for the web.

JavaScript (JS) & jQuery — who needs a GPU?

As they would say in Zoolander, “JavaScript is so hot right now”. For some reason people think it’s the best thing since sliced bread, and everyone is jumping on the JavaScript train. Even though the language only has two levels of scope (local and global), no real class support and numerous issues with scope creep, library conflicts and the insatiable inability to debug, it’s the bee’s knees.

But all bashing aside, JavaScript (JS) has an extremely important role and is the only language that can do what it was designed to do. Document Object Model (DOM) modification. For modifying the client side DOM, JS has no parallel, AJAX calls, adding / removing classes, interactive anything, search, sort, sliders and light-boxes JS has made a large dent in the user experience on the web. You can do almost anything in the browser in JS from editing an HTML element to large complex animations. But the real question is, should you be using it? The answer is, sometimes. Personally I only use JS when HTML and CSS3 can’t really do the thing I need it to do. HTML and CSS together in 2017 are stronger, flexible, safer and highly supported.  The main reason I use JS as a last resort is because unlike CSS it’s not GPU accelerated. Large interactive JS based web apps are often bogged down simply because the browser is unable to leverage the GPU to help with the CPU intensive transitions and animations. Often when you see animations on a website and they look choppy or are tearing the screen it’s because it’s running using JS.

Then along came jQuery. jQuery the JavaScript library that for some reason people think is different from JS. Yes, jQuery is a library written in JS designed to cut down on the amount of code you need to write to modify your Document Object Model (DOM) and build JavaScript apps quickly. jQuery is definitely slower than vanilla JS but pretty much everyone uses it because it’s extremely convenient and saves a ton of time. It’s not until you start building out a large scale application where parts were written in different versions of jQuery where it really starts getting fun. jQuery is very specific to the library it was built upon, trying to run any jQuery code on any jQuery version is just a recipe for disaster. Hence most modular web apps that plug into other sites might not employ jQuery as to prevent these types of conflicts.

CSS3 & [SCSS / SASS] — the style file

Remember when HTML tags defined styles and there was no CSS? Those were simpler but ugly days of the web. I started using CSS in 1999, the idea of styling HTML was incredible. CSS blew up, web design started to become a thing, bandwidth was blowing up, CPU speeds were blowing up and with the dawn of CSS the modern internet was born. I consider CSS to be a relatively fun language to write code in, you get instant gratification with a simple refresh of a page when adding or removing styles, it’s not like writing out a complex PHP class / app where the entire application comes together once all the essential functions are written. CSS gives you that ‘making progress’ feeling every few seconds when implementing new styles, transitions, transformations, fonts, etc.

Although the thing I find most interesting about CSS is the concept that’s most overlooked, aka the fact that it cascades. Yeah, you would think developers would be jumping head over heels for the opportunity to write less code as a trade-off for some simple planning. However all too often do developers not only refuse to ‘cascade’ properly but they often don’t even understand how it really works. The concept itself is very simple, things you write first apply to all selectors within the scope until they are overridden by an equal or more specific scope modifier. Often developers ‘over-scope’ or ‘under-scope’ CSS, meaning they apply a style to too broad of a set of tags, classes, id’s etc, or are too specific and end up repeating themselves later (copy/paste) because they scoped in too hard.

Speaking of scope, scope in CSS is POWERFUL! You have complete control over every single style you create and exactly what set of selectors it applies to. With this powerful scope came the ability to really focus in on specific device widths through media queries and responsive design was born — which really took off in 2012. The ability for websites to display the same content on desktops, tablets and mobile devices (aka phones). Today in 2017 having a responsive website is mandatory especially considering many businesses are finding over 50% of their traffic comes from mobile phones.

SASS (Syntactically Awesome Style Sheets) is a professional grade extension to CSS. Essentially it’s an envelope where you can write higher level reusable code (functions or mixins). You can declare variables and use them throughout your styles, so for example if you need to change a color down the road it could be as easy as changing one variable instead of manually replacing hundreds of instances of that same color where it needs to be replaced. SASS has definitely been helpful in creating clean, quick and extensible code. Keep in mind that the browser can’t read SASS, so the SASS file (.scss) needs to be translated into a CSS file before you can actually view the changes you made, I use compass to manage ‘watching’ the .scss file for changes and will automatically convert when it’s modified.