House Cleaning: Frontend Web

In the Beginning...

Javascript has come a long way from being a slow and inconsistent environment to one of the most popular languages. In the beginning there were many things holding back frontend web development. The internet itself was slower making frontend development more costly for the content provider (hence table layouts). Then there is the inconsistency between the browsers both in rendering and in Javascript functionality. Today we enjoy many tools, libraries, research resources that we did not enjoy until around 2006 (YUI released to public).

• Playing nice in the sandbox (2005-2009) Jquery, Prototype, YUI (and compressor tool), Ext, Mustache
• Structure and discipline (2010 - 2011) Ember, Backbone, Angular, Bootstrap, Pure.css, Modernizr, Handlebars
• Optimizing process (2012 - 2013) Grunt
• Death of a Loved One (2014) death of ie6

Now we have evolved in every way. The internet is faster and more ubiquitous (which means its more lucrative too). The environment is better; browsers with constant updates, code inspection, and a more compatibility across the rendering and Javascript environments. Along with the technology the community has grown. The web and open education go hand in hand so its no surprise that the styles of coding and boilerplates are shared freely. When the browsers didnt play nice it was these coders like John Crockford that did the heavy lifting to make sure we had the ability to share content in any environment and not have to worry about the underlying runtime engine. We have even taken it a step further from beyond the libraries to the tools used to create the libraries. YUIcompressor, Grunt, jshint, require.js, less, sass, and compass are all great tools to use in every project.

What we have learned

Here are a few ideas that have developed from Javascript (or languages like Javascript)and web development in general that you should be familiar with if you want to practice this art.

• 1) The Closure:
  A closure is a function + the variables passed to it + the the variables in its scope. If you combine this idea with the fact that functions in Javascript are fist class objects (they can be passed and returned like other variable types) you get a powerful idea of generative functions. We also can achieve many other techniques to describe(configure) different relationships in logic.
• 2) The Promise:
  A "promise" is the general abstraction of the idea that a function has a state. It has or has not been called, it did or it did not finish, and it finished successfully or in error. Promises have been used to handle asynchronous logic (like the ajax/xmlhttprequest call) as synchronous. This made the implementation of callbacks much cleaner and easier to structure.
• 3) Frontend code compiling:
  All of the fontend languages (html, js, css) are interpreted languages. This means that they are processed at runtime or as they are executed. Still the frontend community has constructed tools to make the code run more efficiently. Tools like yui compressor, jshint, sass, less, and require.js allow us to structure our code implementation in a organized manner while also boosting performance. This performance is not just focused on individual scripts. These tools help teams of frontend engineers layout and implement features faster in a distributed and efficient fashion. Tools like these took decades for application engineers to build and create we got over night because obstacles that were already overcome by past developers in their own environments.
• 4) Responsive css:
  When the internet wasn't an everyday thing responsive css would just have been a waste of time. Not only would it have been difficult but also impractical considering there were not that many variations and number of screens accessing the internet. Now its mobile first and having a responsive site is not a sign of excellence but a litmus test to know you at least have the basics down.
• 5) Frontend Templating:
  CSS and js have seen a lot of attention and tools created but not HTML. This is because html does not really give you any built in logic. The templating engines of Mustache and Handlebars allowed us to use javascript to create a system in which our markup is more reusable and descriptive. I expect this to be fully integrated into HTML very soon and then we will be able to separate our markup like we separate our javascript and sass/less files. This is the last feature that needs to be accepted across the frontend developer community to finally allow use to distribute frontend code as separate pieces of reusable libraries that can just be dropped in folders and called into our native code bases.

Some advanced topics to wet your noodle in case you want to be ahead of the curve or specialize in a certain type of application development:
-Polymer, a new way of generating interfaces from the ground up
-Reach.js and shadow dom, update the UI faster
-Media APIs (video and audio)
-Offline and Online web apps
-Location detection
-Web GL

On to the next one, two ,eight ...

When thinking about frontend development you are trying to conceptualize a vague answer to a vague problem. What is the best way to use the tools (JS, HTML, CSS) in order to serve web pages across the internet (desktops, ipads, smart phones ... etc). For frontend this problem is answered very differently than by backend coders. Backend coders, have one programming language to use (maybe two if you count DB code), they have one system to run in (linux or windows, doesnt change from day to day), and one set of output (url -> data -> output). When the frontend code gets involved its 3 languages, multiple screens and devices, and multiple inputs/outputs (interactivity, ajax response, ui evenets, features) depending on those environments. Backend coding is a problem of vertical scale, how do you do one thing a million times in milliseconds. Frontend coding is a problem of horizontal scale, how do you solve many different problems in many different ways. Backend problems are depth first search problems while frontend problems are breadth first search problems. This does not mean that optimization is not task a for frontend developers to think about what it means is that our environment is highly variable and that any optimization might have many different solutions depending on the current configuration.

This concept can be seen throughout the environment of a frontend coder. The language itself is multiple; HTML, JS, CSS all intercommunicating in one runtime environment. The UIs we try to interface with are varied by problem and by device; scrolling , clicking, typing, page size, hovering, and dragging. To go along with these varied interfaces we have multiple types of data structures/design patterns that are specific to how this environment is handled. We have state machines to handle the general tasks of syncing the multiple interactive states of a single page. We have event binding and closures to safely create variable scopes to be accessed on interaction. We also have differed binding and promises to handle asynchronous data access.

With all these tools and concepts in place frontend coding can now be a work of art instead of tedious painful necessity. Its nice that there have been some many people that have worked hard to make this foundation for us to create in. I hope it doesnt stop. We are now at a place where we have a solid understanding of good practices. Its nice to reflect on what we have accomplished but I wonder what other limits of logic and interfaces can this environment express and solve? How wide can this net be cast to help combine the raw power of the backend with the responsive and varied structures of the frontend?