Mr Branding

Wednesday, May 30, 2018

ES6 (ES2015) and Beyond: Understanding JavaScript Versioning

As programming languages go, JavaScript’s development has been positively frantic in the last few years. With each year now seeing a new release of the ECMAScript specification, it’s easy to get confused about JavaScript versioning, which version supports what, and how you can future-proof your code.

To better understand the how and why behind this seemingly constant stream of new features, let’s take a brief look at the history of the JavaScript and JavaScript versioning, and find out why the standardization process is so important.

The Early History of JavaScript Versioning

The prototype of JavaScript was written in just ten days in May 1995 by Brendan Eich. He was initially recruited to implement a Scheme runtime for Netscape Navigator, but the management team pushed for a C-style language that would complement the then recently released Java.

JavaScript made its debut in version 2 of Netscape Navigator in December 1995. The following year, Microsoft reverse-engineered JavaScript to create their own version, calling it JScript. JScript shipped with version 3 of the Internet Explorer browser, and was almost identical to JavaScript — even including all the same bugs and quirks — but it did have some extra Internet Explorer-only features.

The Birth of ECMAScript

The necessity of ensuring that JScript (and any other variants) remained compatible with JavaScript motivated Netscape and Sun Microsystems to standardize the language. They did this with the help of the European Computer Manufacturers Association, who would host the standard. The standardized language was called ECMAScript to avoid infringing on Sun’s Java trademark — a move that caused a fair deal of confusion. Eventually ECMAScript was used to refer to the specification, and JavaScript was (and still is) used to refer to the language itself.

The working group in charge of JavaScript versioning and maintaining ECMAScript is known as Technical Committee 39, or TC39. It’s made up of representatives from all the major browser vendors such as Apple, Google, Microsoft and Mozilla, as well as invited experts and delegates from other companies with an interest in the development of the Web. They have regular meetings to decide on how the language will develop.

When JavaScript was standardized by TC39 in 1997, the specification was known as ECMAScript version 1. Subsequent versions of ECMAScript were initially released on an annual basis, but ultimately became sporadic due to the lack of consensus and the unmanageably large feature set surrounding ECMAScript 4. This version was thus terminated and downsized into 3.1, but wasn’t finalized under that moniker, instead eventually evolving into ECMAScript 5. This was released in December 2009, 10 years after ECMAScript 3, and introduced a JSON serialization API, Function.prototype.bind, and strict mode, amongst other capabilities. A maintenance release to clarify some of the ambiguity of the latest iteration, 5.1, was released two years later.

Do you want to dive deeper into the history of JavaScript? Then check out chapter one of JavaScript: Novice to Ninja, 2nd Edition.

ECMAScript 2015 and the Resurgence of Yearly Releases

With the resolution of TC39’s disagreement resulting from ECMAScript 4, Brendan Eich stressed the need for nearer-term, smaller releases. The first of these new specifications was ES2015 (originally named ECMAScript 6, or ES6). This edition was a large but necessary foundation to support the future, annual JavaScript versioning. It includes many features that are well-loved by many developers today, such as:

ES2015 was the first offering to follow the TC39 process, a proposal-based model for discussing and adopting elements.

Continue reading %ES6 (ES2015) and Beyond: Understanding JavaScript Versioning%

by James Wright via SitePoint

An Introduction to Sails.js

Sails.js is a Node.js MVC (model–view–controller) framework that follows the “convention over configuration” principle. It’s inspired by the popular Ruby on Rails web framework, and allows you to quickly build REST APIs, single-page apps and real-time (WebSockets-based) apps. It makes extensive use of code generators that allow you to build your application with less writing of code—particularly of common code that can be otherwise scaffolded.

The framework is built on top of Express.js, one of the most popular Node.js libraries, and Socket.io, a JavaScript library/engine for adding real-time, bidirectional, event-based communication to applications. At the time of writing, the official stable version of Sails.js is 0.12.14, which is available from npm. Sails.js version 1.0 has not officially been released, but according to Sails.js creators, version 1.0 is already used in some production applications, and they even recommend using it when starting new projects.

Main Features

Sails.js has many great features:

it’s built on Express.js
it has real-time support with WebSockets
it takes a “convention over configuration” approach
it has powerful code generation, thanks to Blueprints
it’s database agnostic thanks to its powerful Waterline ORM/ODM
it supports multiple data stores in the same project
it has good documentation.

There are currently a few important cons, such as:

no support for JOIN query in Waterline
no support for SQL transactions until Sails v1.0 (in beta at the time of writing)
until version 1.0, it still uses Express.js v3, which is EOL (end of life)
development is very slow.

Sails.js vs Express.js

Software development is all about building abstractions. Sails.js is a high-level abstraction layer on top of Express.js (which itself is an abstraction over Node’s HTTP modules) that provides routing, middleware, file serving and so on. It also adds a powerful ORM/ODM, the MVC architectural pattern, and a powerful generator CLI (among other features).

You can build web applications using Node’s low-level HTTP service and other utility modules (such as the filesystem module) but it’s not recommended except for the sake of learning the Node.js platform. You can also take a step up and use Express.js, which is a popular, lightweight framework for building web apps.

You’ll have routing and other useful constructs for web apps, but you’ll need to take care of pretty much everything from configuration, file structure and code organization to working with databases.

Express doesn’t offer any built-in tool to help you with database access, so you’ll need to bring together the required technologies to build a complete web application. This is what’s called a stack. Web developers, using JavaScript, mostly use the popular MEAN stack, which stands for MongoDB, ExpressJS, AngularJS and Node.js.

MongoDB is the preferred database system among Node/Express developers, but you can use any database you want. The most important point here is that Express doesn’t provide any built-in APIs when it comes to databases.

The Waterline ORM/ODM

One key feature of Sails.js is Waterline, a powerful ORM (object relational mapper) for SQL-based databases and ODM (object document mapper) for NoSQL document-based databases. Waterline abstracts away all the complexities when working with databases and, most importantly, with Waterline you don’t have to make the decision of choosing a database system when you’re just starting development. It also doesn’t intimidate you when your client hasn’t yet decided on the database technology to use.

You can start building you application without a single line of configuration. In fact, you don’t have to install a database system at all initially. Thanks to the built-in sails-disk NeDB-based file database, you can transparently use the file system to store and retrieve data for testing your application functionality.

Once you’re ready and you have decided on the convenient database system you want to use for your project, you can then simply switch the database by installing the relevant adapter for your database system. Waterline has official adapters for popular relational database systems such as MySQL and PostgreSQL and the NoSQL databases, such as MongoDB and Redis, and the community has also built numerous adapters for the other popular database systems such as Oracle, MSSQL, DB2, SQLite, CouchDB and neo4j. In case when you can’t find an adapter for the database system you want to use, you can develop your own custom adapter.

Waterline abstracts away the differences between different database systems and allows you to have a normalized interface for your application to communicate with any supported database system. You don’t have to work with SQL or any low-level API (for NoSQL databases) but that doesn’t mean you can’t (at least for SQL-based databases and MongoDB).

There are situations when you need to write custom SQL, for example, for performance reasons, for working with complex database requirements, or for accessing database-specific features. In this case, you can use the .query() method available only on the Waterline models that are configured to use SQL systems (you can find more information about query() from the docs).

Since different database systems have common and database-specific features, the Waterline ORM/ODM can only be good for you as long as you only constrain yourself to use the common features. Also, if you use raw SQL or native MongoDB APIs, you’ll lose many of the features of Waterline, including the ability to switch between different databases.

Getting Started with Sails.js

Now that we’ve covered the basic concepts and features of Sails.js, let’s see how you can quickly get started using Sails.js to create new projects and lift them.

Prerequisites

Before you can use Sails.js, you need to have a development environment with Node.js (and npm) installed. You can install both of them by heading to the official Node.js website and downloading the right installer for your operating system.

Node.js Download page

Make sure, also, to install whatever database management system you want to use with Sails.js (either a relational or a NoSQL database). If you’re not interested by using a full-fledged database system, at this point, you can still work with Sails.js thanks to sails-disk, which allows you to have a file-based database out of the box.

Installing the Sails.js CLI

After satisfying the working development requirements, you can head over to your terminal (Linux and macOS) or command prompt (Windows) and install the Sails.js Command Line Utility, globally, from npm:

sudo npm install sails -g

If you want to install the latest 1.0 version to try the new features, you need to use the beta version:

npm install sails@beta -g

You may or may not need sudo to install packages globally depending on your npm configuration.

Scaffolding a Sails.js Project

After installing the Sails.js CLI, you can go ahead and scaffold a new project with one command:

sails new sailsdemo

This will create a new folder for your project named sailsdemo on your current directory. You can also scaffold your project files inside an existing folder with this:

sails new .

You can scaffold a new Sails.js project without a front end with this:

sails new sailsdemo --no-frontend

Find more information about the features of the CLI from the docs.

The Anatomy of a Sails.js Project

Here’s a screenshot of a project generated using the Sails.js CLI:

A project generated using the Sails.js CLI

A Sails.js project is a Node.js module with a package.json and a node_modules folder. You may also notice the presence of Gruntfile.js. Sails.js uses Grunt as a build tool for building front-end assets.

If you’re building an app for the browser, you’re in luck. Sails ships with Grunt — which means your entire front-end asset workflow is completely customizable, and comes with support for all of the great Grunt modules which are already out there. That includes support for Less, Sass, Stylus, CoffeeScript, JST, Jade, Handlebars, Dust, and many more. When you’re ready to go into production, your assets are minified and gzipped automatically. You can even compile your static assets and push them out to a CDN like CloudFront to make your app load even faster. (You can read more about these points on the Sails.js website.)

You can also use Gulp or Webpack as your build system instead of Grunt, with custom generators. See the sails-generate-new-gulp and sails-webpack projects on GitHub.

For more community generators, see this documentation page on the Sails.js site.

The project contains many configuration files and folders. Most of them are self explanatory, but let’s go over the ones you’ll be working with most of the time:

api/controllers: this is the folder where controllers live. Controllers correspond to the C part in MVC. It’s where the business logic for your application exists.
api/models: the folder where models exist. Models correspond to the M part of MVC architecture. This is where you need to put classes or objects that map to your SQL/NoSQL data.
api/policies: this is the folder where you need to put policies for your application
api/responses: this folder contains server response logic such as functions to handle the 404 and 500 responses, etc.
api/services: this where your app-wide services live. A service is a global class encapsulating common logic that can be used throughout many controllers.
./views: this folder contains templates used for displaying views. By default, this folder contains the ejs engine templates, but you can configure any Express-supported engine such as EJS, Jade, Handlebars, Mustache and Underscore etc.
./config: this folder contains many configuration files that enable you to configure every detail of your application, such as CORS, CSRF protection, i18n, http, settings for models, views, logging and policies etc. One important file that you’ll frequently use is config/routes.js, where you can create your application routes and map them to actual actions in the controllers or to views directly.
./assets: this is the folder where you can place any static files (CSS, JavaScript and images etc.) for your application.

Continue reading %An Introduction to Sails.js%

by Ahmed Bouchefra via SitePoint

Building Apps and Services with the Hapi.js Framework

Hapi.js is described as “a rich framework for building applications and services”. Hapi’s smart defaults make it a breeze to create JSON APIs, and its modular design and plugin system allow you to easily extend or modify its behavior.

The recent release of version 17.0 has fully embraced async and await, so you’ll be writing code that appears synchronous but is non-blocking and avoids callback hell. Win-win.

The Project

In this article, we’ll be building the following API for a typical blog from scratch:

# RESTful actions for fetching, creating, updating and deleting articles
GET    /articles                articles#index
GET    /articles/:id            articles#show
POST   /articles                articles#create
PUT    /articles/:id            articles#update
DELETE /articles/:id            articles#destroy

# Nested routes for creating and deleting comments
POST   /articles/:id/comments   comments#create
DELETE /articles/:id/comments   comments#destroy

# Authentication with JSON Web Tokens (JWT)
POST   /authentications         authentications#create

The article will cover:

Hapi’s core API: routing, request and response
models and persistence in a relational database
routes and actions for Articles and Comments
testing a REST API with HTTPie
authentication with JWT and securing routes
validation
an HTML View and Layout for the root route /.

The Starting Point

Make sure you’ve got a recent version of Node.js installed; node -v should return 8.9.0 or higher.

Download the starting code from here with git:

git clone https://github.com/markbrown4/hapi-api.git
cd hapi-api
npm install

Open up package.json and you’ll see that the “start” script runs server.js with nodemon. This will take care of restarting the server for us when we change a file.

Run npm start and open http://localhost:3000/:

[{ "so": "hapi!" }]

Let’s look at the source:

// server.js
const Hapi = require('hapi')

// Configure the server instance
const server = Hapi.server({
  host: 'localhost',
  port: 3000
})

// Add routes
server.route({
  method: 'GET',
  path: '/',
  handler: () =&gt; {
    return [{ so: 'hapi!' }]
  }
})

// Go!
server.start().then(() =&gt; {
  console.log('Server running at:', server.info.uri)
}).catch(err =&gt; {
  console.log(err)
  process.exit(1)
})

The Route Handler

The route handler is the most interesting part of this code. Replace it with the code below, comment out the return lines one by one, and test the response in your browser.

server.route({
  method: 'GET',
  path: '/',
  handler: () =&gt; {
    // return [{ so: 'hapi!' }]
    return 123
    return `&lt;h1&gt;&lt;marquee&gt;HTML &lt;em&gt;rules!&lt;/em&gt;&lt;/marquee&gt;&lt;/h1&gt;`
    return null
    return new Error('Boom')
    return Promise.resolve({ whoa: true })
    return require('fs').createReadStream('index.html')
  }
})

To send a response, you simply return a value and Hapi will send the appropriate body and headers.

An Object will respond with stringified JSON and Content-Type: application/json
String values will be Content-Type: text/html
You can also return a Promise or Stream.

The handler function is often made async for cleaner control flow with Promises:

server.route({
  method: 'GET',
  path: '/',
  handler: async () =&gt; {
    let html = await Promise.resolve(`&lt;h1&gt;Google&lt;h1&gt;`)
    html = html.replace('Google', 'Hapi')

    return html
  }
})

It’s not always cleaner with async though. Sometimes returning a Promise is simpler:

handler: () =&gt; {
  return Promise.resolve(`&lt;h1&gt;Google&lt;h1&gt;`)
    .then(html =&gt; html.replace('Google', 'Hapi'))
}

We’ll see better examples of how async helps us out when we start interacting with the database.

The Model Layer

Like the popular Express.js framework, Hapi is a minimal framework that doesn’t provide any recommendations for the Model layer or persistence. You can choose any database and ORM that you’d like, or none — it’s up to you. We’ll be using SQLite and the Sequelize ORM in this tutorial to provide a clean API for interacting with the database.

SQLite comes pre-installed on macOS and most Linux distributions. You can check if it’s installed with sqlite -v. If not, you can find installation instructions at the SQLite website.

Sequelize works with many popular relational databases like Postgres or MySQL, so you’ll need to install both sequelize and the sqlite3 adapter:

npm install --save sequelize sqlite3

Let’s connect to our database and write our first table definition for articles:

// models.js
const path = require('path')
const Sequelize = require('sequelize')

// configure connection to db host, user, pass - not required for SQLite
const sequelize = new Sequelize(null, null, null, {
  dialect: 'sqlite',
  storage: path.join('tmp', 'db.sqlite') // SQLite persists its data directly to file
})

// Here we define our Article model with a title attribute of type string, and a body attribute of type text. By default, all tables get columns for id, createdAt, updatedAt as well.
const Article = sequelize.define('article', {
  title: Sequelize.STRING,
  body: Sequelize.TEXT
})

// Create table
Article.sync()

module.exports = {
  Article
}

Let’s test out our new model by importing it and replacing our route handler with the following:

// server.js
const { Article } = require('./models')

server.route({
  method: 'GET',
  path: '/',
  handler: () =&gt; {
    // try commenting these lines out one at a time
    return Article.findAll()
    return Article.create({ title: 'Welcome to my blog', body: 'The happiest place on earth' })
    return Article.findById(1)
    return Article.update({ title: 'Learning Hapi', body: `JSON API's a breeze.` }, { where: { id: 1 } })
    return Article.findAll()
    return Article.destroy({ where: { id: 1 } })
    return Article.findAll()
  }
})

If you’re familiar with SQL or other ORM’s, the Sequelize API should be self explanatory, It’s built with Promises so it works great with Hapi’s async handlers too.

Note: using Article.sync() to create the tables or Article.sync({ force: true }) to drop and create are fine for the purposes of this demo. If you’re wanting to use this in production you should check out sequelize-cli and write Migrations for any schema changes.

Our RESTful Actions

Let’s build the following routes:

GET     /articles        fetch all articles
GET     /articles/:id    fetch article by id
POST    /articles        create article with `{ title, body }` params
PUT     /articles/:id    update article with `{ title, body }` params
DELETE  /articles/:id    delete article by id

Add a new file, routes.js, to separate the server config from the application logic:

// routes.js
const { Article } = require('./models')

exports.configureRoutes = (server) =&gt; {
  // server.route accepts an object or an array
  return server.route([{
    method: 'GET',
    path: '/articles',
    handler: () =&gt; {
      return Article.findAll()
    }
  }, {
    method: 'GET',
    // The curly braces are how we define params (variable path segments in the URL)
    path: '/articles/{id}',
    handler: (request) =&gt; {
      return Article.findById(request.params.id)
    }
  }, {
    method: 'POST',
    path: '/articles',
    handler: (request) =&gt; {
      const article = Article.build(request.payload.article)

      return article.save()
    }
  }, {
    // method can be an array
    method: ['PUT', 'PATCH'],
    path: '/articles/{id}',
    handler: async (request) =&gt; {
      const article = await Article.findById(request.params.id)
      article.update(request.payload.article)

      return article.save()
    }
  }, {
    method: 'DELETE',
    path: '/articles/{id}',
    handler: async (request) =&gt; {
      const article = await Article.findById(request.params.id)

      return article.destroy()
    }
  }])
}

Import and configure our routes before we start the server:

// server.js
const Hapi = require('hapi')
const { configureRoutes } = require('./routes')

const server = Hapi.server({
  host: 'localhost',
  port: 3000
})

// This function will allow us to easily extend it later
const main = async () =&gt; {
  await configureRoutes(server)
  await server.start()

  return server
}

main().then(server =&gt; {
  console.log('Server running at:', server.info.uri)
}).catch(err =&gt; {
  console.log(err)
  process.exit(1)
})

Continue reading %Building Apps and Services with the Hapi.js Framework%

by Mark Brown via SitePoint

SITE123: A Website Builder to Save Time and Money

This article was created in partnership with SITE123. Thank you for supporting the partners who make SitePoint possible.

Spend a few minutes, make a few little adjustments, upload your content, and you will have a stunning website with SITE123.

The internet is now full of platforms that allow you to create your own website – that isn't news.

However, those who have already immersed themselves in the universe of trying to build a brand in the virtual world know how difficult it is to find a good free website builder that is both complete and secure.

Finding a good platform can be an overwhelming task. It requires some research, several user accounts created, and you still end up with the possibility of not finding the ideal place to build your website.

But you don't have to worry anymore, because now you have managed to find the right place to create your own website without any investment.

SITE123 is a rich platform with layouts that are ready for you to use in building your website according to your business segment.

SITE123 is among the website builders that have grown the most in the market lately, because it presents ease and practicality for its clients.

You will not have to spend hours designing and coding a website. And you will not have to pay for a programmer/website developer if you cannot code. You can create everything yourself in the simplest and fastest way, without having to hire any professional knowledge for it.

In addition to keeping your pockets full and your agenda free, you will be proud to say that you have been able to create a website in less than one hour.

Can it get any better than that?

Continue reading %SITE123: A Website Builder to Save Time and Money%

by SitePoint Team via SitePoint

Top 5 Countries Embracing the Blockchain Technology

The so-called monetary system throughout the world is constantly subject to change. Initially, when different services and products did not have any specific value but only passed from hand to hand, people were using barter. Then, there were animal skins, teeth, tails, and more. After that, gold...

[ This is a content summary only. Visit our website https://ift.tt/1b4YgHQ for full links, other content, and more! ]

by Web Desk via Digital Information World

Ethereum’s Casper: Ghostbusting Proof of Stake Problems

Every complex society has many cases where a big number of players need to reach consensus. The main advantage of such a society is that people can agree and act together on different issues, and can solve more and bigger problems than individuals can do alone.

Society is based on consensus. Trade, diplomacy, finances — they all have this prerequisite of consensus. This has created a need for different mechanisms of governance to reach consensus. And with it, often, comes a lot of abuse, manipulations and rogue players.

To prevent different manipulations, we’ve had centralized institutions that gave us efficiency in reaching consensus and making decisions. The necessary tradeoff between democracy and efficiency is well known among the students of different modes of government.

While different levels and models of centralized decision-making have lead us to sophisticated, functioning society, it has also lead to accumulation of power and resources in the hands of the few. In modern days, things like the Internet and cryptography have given us power to explore new models of reaching consensus.

Blockchain is one of the modern inventions that’s supposed to enable us to reach consensus without centralization and trusted parties. It is, in its many incarnations, still in its baby stages, but we can safely say that if it delivers on just a part of its promises, it will help us have a more efficient society without the tradeoffs.

Byzantine Fault Tolerance

When we start designing (or imagining) decentralized institutions, decentralized organizations, we can reduce (in programmers’ terms) all the related logic and data structures down to voting and a ledger of decisions/votes.

The ideal of decentralization involves applications that are robust and have no single point of failure. No central authority, and yet, we should be able to guarantee the integrity of the ledger. For example, we need to know that our bank accounts, or vote results, or some online text, or the content of some online conversation, or some digital identity have not been tampered with.

Without central, trusted players, this can be hard.

In a decentralized, untrusted environment, we need to provide for cases of rogue players, who will try to manipulate the consensus. To simplify: everyone needs to have a vote, but no one should be able to cheat the system using their voting right.

When a decentralized system — which consists of untrusted parties — is able to function when there are treacherous parties in its midst, we say it has Byzantine fault tolerance.

In cases of creating a decentralized financial system, or critical decision-making systems, incentives for cheating the system are huge, so these systems need to be bulletproof.

Cryptocurrency solutions of the recent years have addressed the “Byzantine generals problem” by various consensus mechanisms, combining cryptography and various game theory strategies.

Consensus Mechanisms

In blockchain applications - and more narrowly, cryptocurrencies — different consensus mechanisms are, really, ways to solve the “rogue players” problem of trustless systems we outlined above — the Byzantine generals problem. These algorithms are different ways to deter the players from cheating the system. These players are usually known as nodes — computer systems with instances of the blockchain, or which validate new transactions and mine new blocks.

Consensus mechanisms are devised to make it non-lucrative, or not worth the effort, to cheat the system.

Read more about these mechanisms in this post.

Continue reading %Ethereum’s Casper: Ghostbusting Proof of Stake Problems%

by Tonino Jankov via SitePoint

What's new in Chrome 67

#342 — May 30, 2018

Read on the Web

Frontend Focus

Getting Started With CSS Layouts — Whether you’re fairly new to CSS or an experienced developer from elsewhere in the stack who wants to make sure your understanding of layout today is up to date, this guide covers everything you need to know about approaching building layouts with CSS in 2018.

Rachel Andrew

Chrome 67 Released: What's New For Developers? — The latest Chrome introduces support for desktop-based progressive web apps (PWAs) on macOS and Windows, support for the Generic Sensor API, BigInt support in JavaScript, and more. There’s also been a lot of tweaks to Chrome 67’s DevTools.

Pete LePage (Google)

Build Your Next React Class: Eligible for Free Tuition — Rank the priority of course material for your ideal React class by taking this 1-question survey. Respondents enter in a chance to take a free class.

Big Nerd Ranch sponsor

The Service Worker Cookbook: Practical Examples of Using Service Workers — Examples of using Service Workers to do things like push notifications, caching, fallbacks, complete with annotated code. (Note: The source files are linked at the top right when you go into a specific example. I missed seeing them at first..)

Mozilla

Wired Elements: UI Elements with a Hand-Drawn Look — Possibly useful for wireframes and mockups, or wherever you want a less formal look. Implemented as Web Components and cover things like checkboxes, cards, input fields, radio buttons, etc. GitHub repo.

Preet Shihn

Beyond SPAs: Alternative Architectures for Your PWA — Building a Progressive Web App doesn’t necessarily mean building a single page app. Learn about alternative architectures for content-focused PWAs here.

Jeff Posnick (Google)

Shadow DOM Enabled in Firefox Nightly Builds — Likely to turn up more generally in Firefox 62 or 63.

Mozilla

USA Today Sends EU Users to Ultra Lightweight Site Due to GDPR — The homepage clocks in at 297KB versus 5.5MB for the usual US site and includes no third party tracking.

Paul Calvano on Twitter

Experience the O'Reilly Fluent Conference for Just $199

O’Reilly Media, Inc sponsor

💻 Jobs

Sr. Fullstack Engineer (Remote) — Sticker Mule is looking for passionate developers to join our remote team. Come help us become the Internet’s best place to shop and work.

Sticker Mule

Frontend Web Engineer (London, UK) — Join us to develop our web app and internal tools that enable us to build cities & run transport services.

Citymapper

Front-End Expert? Sign Up for Vettery — Top companies use Vettery to find the best tech talent. Take a few minutes to join our platform.

Vettery

📘 Tutorials

How CSS Works: Understanding the Cascade — Make your CSS less brittle by truly understanding the ‘C’ in CSS.

Benjamin Johnson

Z-Index Explained: How to Stack Elements Using CSS — A nice reminder…

Veronika Ivhed

Cheat Sheet: Functional Programming with JavaScript Out Now — A handy resource for JavaScript developers interested in writing functional style code. Get it now.

Progress Kendo UI sponsor

The CSS Grid Layout vs CSS Frameworks Debate — With cutting-edge CSS standards like CSS Grid Layout and Flexbox, does it still make sense to learn and use Bootstrap?

Maria Antonietta Perna

▶ PWA Starter Kit: Build Fast, Scalable, Modern Apps with Web Components

Monica Dinculescu

(Sublime) Text Editing Techniques Every Front-End Developer Should Know

Ben Frain

How to Detect WebVR Support with JavaScript

David Walsh

Exploring the Concept of Progressive Web Games

Mozilla Hacks

▶ CSS Grid Can Eliminate Margin Collapsing

Jen Simmons

🔧 Code and Tools