Front-End Web Development Questions – David Shariff

Original List

  • Execution context references the ‘environment’ a function executes in; that is, variable scope (and the scope chain, variables in closures from outer scopes), function arguments, and the value of the this object.
  • Lexical scope is the concept that every inner level can access its outer levels
  • Hoisting: The way in which the JavaScript interpreter declares variables at the top of the function it is contained in (the current scope.) And to clarify – declared not initialed (assigned) a value. This results in some variables being accessible even though they are not yet physically declared in the code. Common practice in JS is to always declare your vars at the top of your scope to avoid confusion. Here’s a list of different hoisting scenarios.

    Hoisting function variables:

    Hoisting regular variables:

  • Function expressions is declaring and assigning the function to a var at the same time:

  • .call, .bind and .apply:

  • Prototype and Constructors:

  • Event Delegation: You place the event listener on the parent to capture the bubbled event – imagine a table of 1000 rows. The callback function lets you handle it in any way.
    View example pen here.
  • typeof

  • Object.prototype.toString()

  • Traversal up, down, left and right: View Pen
  • Manipulation – add, remove, copy, and create nodes in the DOM tree.
  • Change the text content of a node and toggle, remove or add a CSS classname. View Pen
  • Explain: role=”button” Can make any element (span, div etc.) behave as a button control to a screen reader, role=”presentation” Removes any semantic meaning so screen readers don’t react to it semantically.
  • HTTP requests – GET and POST along with associated headers such as Cache-Control, ETag, Status Codes, and Transfer-Encoding.
  • Security – JSONP, CORs, and iFrame policies View Pen
  • REST vs RPC:
    The fundamental problem with RPC is coupling. RPC clients become tightly coupled to service implementation in several ways and it becomes very hard to change service implementation without breaking clients:

  • Clients are required to know procedure names;
  • Procedure parameters order, types and count matters. It’s not that easy to change procedure signatures(number of arguments, order of arguments, argument types etc…) on server side without breaking client implementations;
  • RPC style doesn’t expose anything but procedure endpoints + procedure arguments. It’s impossible for client to determine what can be done next.
  • On the other hand in REST style it’s very easy to guide clients by including control information in representations (HTTP headers + representation). For example:
  • It’s possible (and actually mandatory) to embed links annotated with link relation types which convey meanings of these URIs;
  • Client implementations do not need to depend on particular procedure names and arguments. Instead, clients depend on message formats. This creates possibility to use already implemented libraries for particular media formats. It’s possible to easily change URIs without breaking clients as far as they only depend on registered (or domain specific) link relations;
  • It’s possible to embed form-like structures in representations, giving clients the possibility to expose these descriptions as UI capabilities if the end user is human;
  • Support for caching is additional advantage;
  • Standardised status codes;

Peter Dillon

Development teams seek me out for visual design, reskinning, information hierarchy, usability, iconography, improving task flow, improving the front end build process and more. I specialize in creating engaging solutions to solve real world problems while designing beautiful applications that make the lives of users easier.