12 Jan

Third-Party Scripts

Trent Walton:

My latest realization is that delivering a performant, accessible, responsive, scalable website isn’t enough: I also need to consider the impact of third-party scripts. No matter how solid I think my prototype is, it doesn’t absolve me from paying attention to what happens during implementation, specifically when it comes to the addition of these third-party scripts.

I recently had a conversation with a friend working on quite a high profile e-commerce site. They were hired to develop …

Third-Party Scripts is a post from CSS-Tricks

14 Jul

Progressive Web App with Webpack

Depending on your web application, a progressive web app may not be essential, but it may be useful to some of your users. Going PWA allows your users to save a subset of your website directly on their mobile device to be able to use it off-line.

All you need to make this work is that you site is HTTPS, a manifest.json file and to register a service working within your current application. With a little bit of time these can quite easily be created manually, however I am going to focus purely on using webpack as a means of integrating it with your existing build process. Similar approaches can be used with gulp/grunt.

Once setup your site will register as a PWA and on supporting mobile devices/browsers, users will even be prompted to save your app to their home screen, effectively installing it.

What we going to configure is 2 small webpack plugins that will generate the service worker and manifest required for a PWA to be registers.

The service worker will configure how your PWA is to function, what assets and URL’s are to be cached and so on.

The manifest file provides additional instructions and theming to the application, this is the essential piece if you wish users to be prompted to save your application on their devices.

Setup

To get started simply install sw-precache-webpack-plugin and webpack-pwa-manifest.

npm i sw-precache-webpack-plugin webpack-pwa-manifest -Dyarn add sw-precache-webpack-plugin webpack-pwa-manifest --dev

In your webpack prod/dist config you then simply require these new modules:

const SWPrecacheWebpackPlugin = require('sw-precache-webpack-plugin');const WebpackPwaManifest = require('webpack-pwa-manifest');

Optionally you can also define a PUBLIC_PATH variable, this is used as part of the ServiceWorker config caching your domain name for later use.

const PUBLIC_PATH = 'https://www.my-domain.com/';
Service Worker config

Add a config similar to below at the end of your current webpack plugins array:

 new SWPrecacheWebpackPlugin( { cacheId: 'my-domain-cache-id', dontCacheBustUrlsMatching: /\.\w{8}\./, filename: 'service-worker.js', minify: true, navigateFallback: PUBLIC_PATH + 'index.html', staticFileGlobsIgnorePatterns: [/\.map$/, /manifest\.json$/] } ),

As you can see it is pretty strait forward, only thing that really benefits from updating would the cacheId. Additional plugin options for more advanced usage or extra info can be found at SW Precache Webpack Plugin Github.

Manifest config

Just like the service working, you include another plugin config at the bottom of your webpack plugins array, this will provide you all of your aesthetic options for the offline application.

 new WebpackPwaManifest({ name: 'My Applications Friendly Name', short_name: 'Application', description: 'Description!', background_color: '#01579b', theme_color: '#01579b', 'theme-color': '#01579b', start_url: '/', icons: [ { src: path.resolve('src/images/icon.png'), sizes: [96, 128, 192, 256, 384, 512], destination: path.join('assets', 'icons') } ] })
Things to note…

short_name: This is the name underneath the icon, keep this under 12 characters long.

background_color, theme-color and theme_color are all part of theming options for your manifest. The 2 theme versions are for different browser support, those will be styling the address bar.

icons: here you can provide multiple objects in the array, useful if you wish to provide a different icons for iOS and Android. More details on that Webpack PWA Github.I simply added in a singe set WPWA will generate icons at all the sizes provided in the sizes array and place then defined destination path.

Output

One last thing to do before we finish up, you need to add a publicPath key to your existing output object and set it to the PUBLIC_PATH const defined earlier.

  output: { // Snip publicPath: PUBLIC_PATH  },
Registering your worker

Now that your webpack is all setup, once final piece of code needs to be added to your project.

Within you applications main js file, you need to add in this Immediately Invoked Function.

(function () {
 if ('serviceWorker' in navigator) {
navigator.serviceWorker.register('./service-worker.js', {scope: '/'})
.then(() => console.log('Service Worker registered successfully.'))
.catch(error => console.log('Service Worker registration failed:', error));
}})();

This will check if the browser your visitor is using supports service workers, and if so registers your service-worker.js.

Your website, at least to some extent, will now be available offline and can be saved as a PWA on the users device, after their next visit.

If you run your build process now you should see a few icons as well as a service-worker.js and amanifest.[hash].json in your public/dist folder.

Google created a Chrome plugin that you can use to test your implementation, Lighthouse.

Also in chrome developers tools > Audit you should be able to see both your service worker and manifest registered within their respective Application menu items.

Here is what the PWA’ of my own portfolio site’s initial screen looks like. As you can see the Blue theming. My Icon in the middle as applications name at the bottom.

Thanks for reading, and I hope you found this useful.

RemeJuan/progressive-web-app-starter

Progressive Web App with Webpack was originally published in codeburst on Medium, where people are continuing the conversation by highlighting and responding to this story.

20 Jan

VueJS: First Impressions

With all the new libraries and frameworks it is pretty hard to keep up with all of them, and that is if you can even decide which ones are worth spending time one, over the last year or so I was exposed to many a new tech stack, with React for work and just personally playing around with React-Native, Aurelia and Angular2. Each of them attached to a new project, partly justified by wanting to try it out or form my own opinion.

Previously I had written about Aurelia, which I was very impressed with after than Angular 2 disaster, if you like, you can read more about it here:

Aurelia: First impressions

This time round I decided to dive into Vue.JS, a lot of good things are being said about it on the web, with it apparently being faster than react, with it’s implementation of Snabbdom, a simple and powerful Virtual DOM focused on performance. On top of that is is notably smaller than React sitting around 14kb.

Of all the frameworks and libraries I have worked with over the years, one thing that stood out to me about Vue.JS was the documentation, very detailed and easy to follow, covering multiple use cases and all the various options, where applicable, for each of it’s built in methods.

Now for a look at the code, the following example is for a very simple component, written in absolute bare-bones, just for you to get an idea of how things are structured..

https://medium.com/media/beff81343c8901397809efa413b5ccb9/href

Vue.JS uses a template file containing both you template body and a script section, and these files are saved with a .vue extension.

Vue.JS itself is completely template agnostic, you can use handlebar/directive template as above, you can also use JSX, or even build it up very manually using es5 or es6 string interpolation if you prefer.

This file pretty much handles it all, you will define the HTML structure as well as relevant scripting logic, and either define a <style> block or import a style sheet like in the example.

The script tag is where all the real work begins, we start by importing Vue and whatever components we intend on using within the component.

name: 'Events', components: { 'header-bar': Header, 'search-bar': Search, 'list-data': List, 'footer-bar': Footer, },

Above we have a snippet from the default export object, we start with the components name, followed by a components object. This object defines a key which is the tag name for the HTML element within our template with its value being the component we imported a little further up.

Next we have some of our methods to control initial logic and define usable functions.

data() {  return { data: [], searchTerm: {},  }},

The data() function is used to setup default data for initial rendering of the component, here the data key is setting itself as an empty array as later when we fetch the data it will become and array of objects, and we do not want to break the render by defaulting with invalid data types.

created() {  // API/Service calls would go here  return { data: [ {}, {} ],  };},

created() is similar to reacts componentWillMount life cycle method, this is the best place within the life of the component to go fetch any data that is not available on initiation of the component, in this case to go fetch the actual list items.

methods: {  search() { // Search method written here  },}

methods() is where you define functions that will be used within the component itself, or passed down to a child component as props, as is the case with search(), the child Search component will receive this method via the props, and this will then be fired off when a user interacts with the search component.

One thing that was not specifically included in the example but was was referenced was props, like react and probably many other libraries at this stage, Vue.JS also supports props, and like react they can be anything that a child component needs, be it static text, a function, and array of data needing to be looped over, or an object with key value pairs for simple dynamic display.

Props are quite simple to define, within the default export you would add another key, called ‘props’ with an array of all the props it is expecting to receive.

https://medium.com/media/a2ea9a8bddf8cd791185f447c20b0695/href

Above would then be an example of the search component, as you can see it is taking in 2 props, the submit method and term, which is a model for handling the search value that will be passed into the function.

This was just a taste of what is possible with Vue.JS, you will see many more examples by visiting their documentation at Vue.JS docs.If you wish to quickly spin up an application and start playing around with Vue.JS, I can suggest taking a look at the Yeoman generator created by FountainJS.

Working with Vue.JS was a great pleasure, I found the learning curve very shallow, however that could purely be based on my experience, as mentioned before I have worked with a few in the past.

The default template structure feels very similar to how it was working with Angular, so developers coming from that background may pick it up a bit faster than they would react. I cannot really go un-learn react to see if it influences how easy it was to pick up Vue.JS.

VueJS: First Impressions was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.

11 Nov

Aurelia: First impressions

Recently had a small personal project that I wanted to rebuild, a project I had initially started quite some time back using AngularJS 1.x, but had never gotten around to finishing it.

Since then, there have however been countless changes in the Javascript world, with ES6 and all the new frameworks available, it seemed a better idea to simply start over with something newer. My first consideration was React, as currently at work we are developing with it, and I had recently used React Native to build a mobile application, it seemed the logical choice, also in part as it is to be the web version of the mobile application, Lusus.

Then I remembered that Aurelia, something that was on my 2016 ToDo (learn) list, and being both a small and personal project, there was no harm in trying something new, not like it had any actual deadline. Worst case scenario, I dislike the framework, formed a valid opinion and can try something else.

Having worked with both AngularJS 1 and 2, I was not really sure what to expect from Aurelia, it was the idea of Rob Eisenberg as he was not happy with the direction the team was taking with Angular 2, and personally neither was I, quite frankly I found it to be a horrific disaster, but that is my opinion…

Starting off could not of been easier, a quick spin up of the Aurelia skeleton navigation application, ES6 flavor of course, and I was off.

My zero second impression was confusion, expanding the ‘src’ folder in Atom to find a mess of files with no apparent structure, which is not something I am used to, but very easily rectified to my personal preferences.

Having read none of the documentation, watched no online tutorials and effectively going into the framework all but blind, I expected just jumping in to be more difficult than it was, it however felt both familiar and different at the same time.

From AJS 1.x I would have to say some of the more menial things have been simplified, including modules/components is a simple require tag.

https://medium.com/media/b4736f540d32d5195f96080478870647/href

If you take a look at the block above you will see 2 ways of including a component, the first could be considered a ‘smart’ component which contains a view with logic, where both files share a name and only differ in extension.

Second would then be ‘dumb’ or a simply view component, containing no logic.

Rendering those imported components are just as simple, following the same convention as your file name.

https://medium.com/media/110a6c0778c7b00dd5400096101f2e82/href

Binding logic to your components is almost intelligence in the way it wires everything together, firstly you do not actually need to specifically reference the JS file within your component, everything is wired together with the extension-less ‘require’.

This does mean however that there are some rules around naming your files/classes. File need to match, and class names need to be the CamelCase version of the file name.

For data binding, you simple need to import ‘bindable’ module, declare your binding reference, and add in an optional change handler, useful if you need to do any modification to the data for view purposes, like date formatting.

There was definitely some learning that had to happen, but I would have to say that this is how I would have imagined AngularJS 2 to have turned out.

This is not to say that Aurelia is perfect, and maybe I still need to do some additional learning, but I found it’s error logging and failure handling a bit too graceful and silent. No errors are logged to the browser console when you made a typo for example, so you will make a change, things do not line up and the application just sits there in the browser in a state of limbo with no indication as to what is wrong, not even a useless message like ‘error’ shows up.

API Call fails and you have not written specific handling for it, it either returns to the previous view, or hangs again without any indication, this could of been intentional as well really should be handling errors ourselves, but I still feel it is a bit too graceful.

Also just really silly, with the build in gulp processes, the build which is used for dev minfies the index.html, but the export (production) step does not, not even 10 seconds to fix it, but still funny.

All in all, anyone coming from AngularJS 1.x looking to move into the next generation, I would highly recommend Aurelia over Angular 2.x, there is infinitely less stupidity and bad decisions in Aurelia, and a much stronger familiarity.

VueJS: First Impressions