A new version of React is out with new fragment support.

I've really enjoyed reading Ben's blog.

Consensus seems to be forming for most of these choices but for a lot of things it's just too early to tell what is best practise.

I'd forgotten what DOM stood for so I spent a few minutes recapping the acronymns.

I knew about the DOM but I didn't know about CSSOM before reading this article.

I don't mind admitting I found higher order components quite difficult to understand at first but I am making good progress with them now.

I love these code snippets for creating React components. After a small time memorising the shortcuts they have sped up my workflow and made it more enjoyable. It's also had the benefit that creating a new component is quick and easy and so I'm more likely to do the right thing and break up large components when needed instead of thinking "urgh, that's too much effort".

I found this article on developer career progression very interesting. I agree with the coder, programmer, developer, architect, innovator progression and it did make me think about my own career progression.

I found a really cool React documentation generator called React Styleguidist. I definitely think that the code comments need to be in the code files instead of a separate wiki. Separate files will easily go out of date whereas if the documentation is straight in the code then it will changed in the same pull request. I've set this up and will use it as our living style guide. It can also build a static version so I might ask my team to add to that to the continuous deployment so we can share links to components by hosting it on the dev server.

I use this useful tool called purifycss to detect the possibly unused css in a legacy project. It's very easy for the css in a project to become "only add" as no-one knows how it all works exactly and so are too scared to delete anything. I think BEM styling can really help with this issue if everything is namespaced. SCSS then helps makes the namespacing less repetitive. My biggest aims when setting up a new project is to carefully architect how I am going to keep the css base as deletable as possible.

An interesting idea for improving culture by thinking about the phrase "just do as expected". I think the company culture is vital for happy, productive programmers. Knowing what is required or expected of you can be very stressful if not communicated clearly.

I loved this video on React animations. I then read this article to introduce me to react motion.React collapse is a really nice wrapper to make the simple animation much easier to work with. I'm still looking for a tool to create animations without code. I think I need to try inVision. Once I've created some animations I'll try to recreate them with React Motion.

I've been bookmarking sites I wanted to blog about over the last few months but have lost track of all the dates so am just going to publish all the blogs with today's date.

I was pleased that this article on efficient form design agrees with my UX ideas on performant forms. I think forms are especially important and their functionality has to trump their form.

Yarn is the improvement I didn't realise I needed until I used it! I needed to upgrade my npm anyway and so installed yarn as well basically to see what all the fuss was about. It appears much faster, better for repeat installs, better feedback as it installs and I love the lockfile idea. Unfortunately the Karma test runner I use has a bug so doesn't work with yarn but once that's fixed I'll probably swap over.

I have been practising unit testing which has involved a lot of reading the Enzyme docs and again RTFM.

I read this useful blog on integration testing.

Once I knew what testing platform I wanted I had to read this blog on how to set it up!

I knew I wanted to use Karma as the test runner and Enzyme seems the most popular React interface. I then had to chose between Jasmine, Jest and Mocha. I've gone for Mocha with its addons Chai and Sinon.

There are multiple ways to validate forms in React and it's taken me a while to think about all the pros and cons. I really like controlled components but generalised helper functions can reduce a lot of the boilerplate.

I've been reading lots of blogs like this one on validation.

As a JavaScript developer I constantly need to learn the latest features in ES6. My favourite feature being the new string manipulation features.

At work we are currently still building the site and adding features but I'm looking forward to optimising the page speed.

I would really like a styleguide for my team to use to write comments. Unfortunately this is quite far down the todo list at the moment.

My prediction is that Augmented Reality is the biggest technology boom in 2020-2030.

Again there are too many choices. Unfortunately I don't have time to try them all thoroughly.Css modules enforce BEM but also add another level of abstraction and complexity for people just used to basic css. SCSSis easily for people who only know CSS. I'm currently in a startup and I don't know how quickly we'll employ new people, nor their experience, so keeping the barrier to entry low is quite important. Everyone in the company already knows SCSS so there is no training time required.

We needed number formatting for credit cards details and phone numbers. We also need telephone validation including mandatory country codes. It's always hard to know if I should build a component and logic myself, use someone else's component or build the component but use a js library for the logic. I ended up usingReact phone number but I'm still not sure if it's exactly correct. Another useful looking library wascleave.js.

React a11y enforces good accessibility practices and teaching people about accessibility. I think it's fantastic and easy to set up with Eslint.

I really need to set aside some time to add hot reloading

I've been looking at these examples of buttons and this resource on colour combinations.

A useful resource with good examples on how to write clean JavaScript. Definitely something to keep referring back to.

Recently I've been trying to use Chrome devtools more effective. Learning how to step through my code has helped me quickly find the source of bugs.

Git is more complicated that I ever imagined!

I have previously learnt how to make custom templates using squarespace but found it quite limiting. My colleagues use Umbraco and so I am trying to learn how to use it. The first thing I have had to learn is the difference between strongly typed and dynamic content.

This article made me realise that I don't actually know much about security.

Lots of interesting articles by Boris Smus.

I learnt about some React interview questions.

Over the Christmas and New Year holidays I've been reading all the articles on hackernoon.com

I've been practising my designing and this smashing magazine article was useful

A very interesting article on CSS-tricks about using longhand and shorthand

Phew, the last few weeks have been really busy being the lead front end developer on greater.jobs. I'm very happy with how it turned out.

This is a great article on how to solve some of problems you face when using BEM.

This week I found out about using "let" instead of "var" in JavaScript, especially in for loops. I must admit I haven't actually used it yet and I need to research a bit more about how the two differ.

I knew about conditional HTML but had never used it. We used it to add a conditional CSS file with IE8 fixes.

I added some new control methods to the virtual reality examples page.

I updated the styleguide.

A client wanted a section removed from their website. The backend team were busy so on my local version of the site I found the relevant code and editted the razor file. The backend guys gave my work a quick check and I pushed my change to staging. My first 100% backend client amend.

I cloned my sister's website and linked it up to the SquareSpace CMS. Her website is 100% custom so their CMS didn't have all the features I wanted but it was a good learning experience.

I created a Virtual Reality experience without code using Kolor.com. They have basically built exactly what I was thinking of creating if I had the time. I really like how they use small videos on top of a photosphere to give the impression of a videosphere.

I had a good discussion with a freelancer over if we should use only min-width or use both min and max widths? I can see advantages for both. Currently sticking with only using min-width.

The design patterns book inspired me to learn more about jQuery plugins. I used this professionally to isolate a specific jQuery version for the social wall.

I then read about JavaScript design patterns in far more detail.

I learnt about the basic JavaScript design patterns.

I read more about improving and optimising my jQuery.

New Git command of the week:

git archive --format zip --output /full/path/to/zipfile.zip master

Used to package up our files to send to the client, with the git repository removed.

This carousel plugin looks good and I might use it in my next project.

Featherlight minimal popups has been very good and this lazy loading plugin is great for image heavy designs.

The webspeech API looks interesting but at the moment feels a bit of a gimmick. I might look into local speech recognition and use it for my home automation.

Recently I've thrown myself into learning A-Frame and you can see the results on my vr page.

Chrome dev tools updated this week and a mystery '$0' appeared. I quick search revealed the answer. It's actually quite handy.

Website obesity was mentioned again as this article did the rounds on social media.

I'm glad the topic is mentioned but the article uses a lightly odd version of 'average weight' and also apparently refers to the zipped shareware Doom game that is far smaller than the full game.

Website obesity is a battle I am currently having professionally. I am using a two-pronged approach. Firstly I am using my technical skills to cope with the designs. For example I am lazy loading images and optimising them as much as possible. Secondly I am trying to effectively communicate to designers and strategists the size implications of their choices.

My biggest success so far has been to communicate the idea that instead of just one full screen image to use a CSS background with images only uses for the foreground elements. This approach also helps position the foreground elements so then are never obscured by text.

I have to be careful that my technological solutions don't undermine my warnings about the implications of page bloat.

This repo has a huge list of front end developer [interview] questions.

I'm not ashamed to admit that I don't know some of the answers. My short-term plan is to know an answer to every question. Over the longer term I can expand my understanding of each topic.

I'm not planning on being interviewed any time soon but I feel going through this list periodically and learning sections in more depth is always going to be a good idea. Continuous professional development is required and fortunately enjoyable.

This week I read a useful article by Shekhar Gulati that repeated what I have been doing over the last 9 months.

I am going to start doing more in the command line, for example create and removing files. I think the command line Russian Roulette joke, and just 'rm -rf' in general, has made me too apprehensive and I want to fix that.

After 9 months I was bored of Sublime and wanted to see what else was available. My co-worker was using Visual Studio Code and I was slightly jealous.

I've been very impressed with VS Code. Installation was easy, I only needed one plugin to match all of my previous Sublime plugins.

All but one of my shortcuts work. In Sublime you can hold shift while pasting to match the indention. This is missing from VS Code, which is annoying, but there are other auto indentation methods which I am sure I will get use to.

It also has brilliant git support which is fantastic.

Overall I am very impressed and glad I've made the switch.

Over Christmas I learnt React. React on its own is pretty simple but learning ES6, Webpack configuration, Redux and other paradigms, frameworks and conventions has been difficult.

React switching versions from 0.14 to 15 is weird but also makes sense. Hopefully a client will pay for a project where React is the best choice. Probably via an app using Cordova. At the moment I will just continue learning more about React and its ecosystem.

I'm still trying to formulate my views on using libraries instead of vanilla code. I think it's best to scope out the website and see the required functionality. Normally you'll need so much that jQuery is the correct choice (for performance, lack of bugs, compatibility e.t.c) but if you have very little then vanilla is definitely an option.

youmightnotneedjquery.com made me laugh and has useful examples.

youmightnotneedyoumightnotneedjquery.com is a bit silly...

I spent an afternoon using Mocha and I can now run simple tests. I will try to use the TTD approach the next time I make a service. It's definitely how I would like to code but my current projects aren't really applicable due to their lack of complex JavaScript.

I am now learning Susy so I can stop using Bootstrap. I dislike the bloat in my HTML and want to move the presentational elements into my css. Hopefully this will reduce overall size and make my projects clearer.

There are many reasons to want to drop jQuery and instead just write in vanilla JavaScript. For a start it's 86k and often you don't need the majority of it. The arguments to keep using it that I have read have been weak and focus on ease of use or its popularity. Then I read a really good comment by HonoredMule.

This is the best pro jQuery argument I have seen:

Let's throw away AngularJS, EmberJS, Bootstrap, CSS grids, Modernizr, Underscore.js, Moustache, Backbone, e.t.c. while we're at it.

If you're talking about learning the basic tools of your trade, then by all means write raw javascript with reckless abandon. It is a core competency and if you can write jQuery (not actually a language) but can't write javascript (the language you are writing when you write jQuery) then you don't even actually know what you're doing and certainly need to address that. Once you master the basic language (or perhaps more to the point, functional programming which is the real learning curve even for experienced OOP developers), move on to language-appropriate design patterns and techniques like functions as generators/compilers, the prototype system, and the Yahoo module pattern.

And then, when you're ready to do real work - in a timely manner, on a budget, and with well-architected, maintainable results - rely on these well-established 3rd-party libraries without reservation. Don't just use them when you must. Pick an appropriate subset for your problem domain and use them whenever you can, as much as you can.

These tools, of which jQuery is easily one of the greatest (certainly the most broadly applicable for front-end work), are not merely a compromise against some "purist" perfection or a shortcut to results. They represent and promote solid architectural approaches, widely shared and established domain knowledge, additional design patterns with easy integration points for bringing multi-team work into a cohesive whole. All those developers who call jQuery /the/ solution aren't suffering from a shared delusion - they know something and many of them learned it the hard way, powered by the developer's archetypal self-assurance and NIH syndrome. Besides, every line of 1st-party code you shave (by using libraries and the terse/efficient techniques they enable, not by writing dense logic) reduces the number of mistakes you make, the overall complexity of your project, and the learning curve for other people trying to decipher your code. By extension it increases the long-term maintainability of your code for you and anyone else *even if you didn't really need it /yet/.*

Case in point: jQuery doesn't just give us fancy selectors, it also encourages and aids valuable design patterns like event-driven programming (with custom events, not just builtin DOM events) and taking advantage of DOM event bubbling, and takes over handler recycling, resulting in far leaner and more loosely coupled code that is better memory managed, avoids callback hell, and minimizes overhead in both code and memory usage. Were all the complex underpinnings for that not wrapped in such an elegant, easy to use pattern, few would even bother maintaining their event and DOM integration. And when they do, they get to choose between building their own NIH-driven solution with minimal support and mindshare and writing scads of boilerplate spaghetti code just begging to introduce memory leaks, bugs, or both. It doesn't take much to put you already well on your way to creating an unmaintainable mass, because you started with a mindset more concerned with minimal dependencies and 3rd-party tool usage than solid, proven architecture.

Popular software libraries are the exemplar economies of near-infinite scale. Talented developers are only more empowered by their use, and less-talented developers are at least guided toward less destructive paths by the communities and the ways that these tools want to be used. The downsides of using them are often so pitiful we find ourselves quibbling over the inclusion of tens of kilobytes in the cross-domain CDN-cached static resource load with our half-meg-on-every-load pages.

Now I might step back for a moment and recognize that you're only suggesting one particular library might be losing its lead over the underyling tools it on which it is built. But I doubt you'd even be saying that if not for the sake of a sensationalist headline. jQuery remains the most beloved, broadly applicable, and established of them all, because it provides so many tools that are constantly valuable to everyone. A couple years ago it surpassed Flash as the most used single tool of any sort on the web. And while native javascript today is finally getting some minor, rudimentary advancements that represent a tiny subset of jQuery's decade-old capabilities, the committee-designed javascript of tomorrow will also have to contend with the visionary-led jQuery (or successor thereof) *of tomorrow.*

Which do you think will advance faster? And more importantly, for what scale of project is an underlying language that (by nature of only being a language) provides few design patterns, no architecture, and no significant domain knowledge truly going to suffice?

Hooray for HTML5 and things like the Promise API and a decent subset of jQuery's (Sizzle's) selector engine, but these advancements are only adding to our toolset, with no significant impact on our existing tools at all. At the end of the day, "I can do this one particular thing about as well with native code anyway" is a terrible reason to throw away a solid and reliable abstraction layer for all but the most pitifully simplistic of use-cases - namely the case where that one things is *all* you have to do.

This is not yet a scenario I've encountered in the real world, but if I did I'd still be hard-pressed to give it any special consideration. Instead I'll just keep following the best practices for the tools I use, which covers things like separating native-backed selector resolution from custom jQuery-provided ones to maximize utility without compromizing performance available through native-backed underpinnings, and even on occasion implementing custom selectors or filters to provide a clean abstraction layer around less common use-cases.

Gaining experience and writing good code are wildly different things, and while the former enables the latter, it first precludes it. Be wary of trying to accomplish both at the same time. There lie all the most avoidable software design pitfalls.

At the end of the day, it is a professional's job to understand all of his tools throughout the software stack. Those who even reach that ballpark find few reasons to abandon any of the tools they've learned, and when they do it's usually because they're the ones building tools rather than simply using them (which is generally a pretty uncommon scenario), or in favor of an equivalent alternative that patches architectural weaknesses - certainly not just because sometimes they can.

During my lunchtime videos I watched a video by Moxie Marlinspike.

It was really interesting and has led me to learning about Tor, Orfox, Tails and security in general.

It was also nice to hear in the news that WhatsApp have introduced his end-to-end encryption to all of their users. If only I trusted them, or had proof, that they had implemented it correctly.

I really enjoyed these videos by Web Directions

Some of the best being Kitt Hodsden's presentation on automation and Maciej Ceglowski's talk on Website Obesity

I really enjoyed a video by Mike Riethmuller on responsive fonts and using viewpoint units.

I had previously created a mixin to interpolate between font sizes on small and large screens. It had the downside of creating a huge number of breakpoints which created large bloated css files. I hadn't thought of using vw units as I didn't realise they had cross browser support. My employer has recently dropped IE8 compatibility and so I can now use vw units in a basic way.

Here is my old mixin I created. The main reason I made it was to practise creating scss mixins.

I have used a language for nearly 10 years yet I'm not sure how to write it down. Is it "Javascript" or "JavaScript"; time for research!

The usual font of all knowledge says the answer is "JavaScript" and the official docs agree.

I still think the capitalised S looks rather silly but never mind, knowledge is power.

I want to improve the accessibility of the websites I create. I will be using HTML validators more that will help with cross browser issues, compatibility on novel devices and indirectly aid accessibility.

The easiest thing I am going to do is to let go of the mouse and check that I can easily navigate the site and perform all actions using the keyboard alone.

At the start of each project I need to think about where the h1 tags will go on each page. I will also need to ensure that I use at least one h2-h6 in each section. Retroactively adding these presents styling issues so I must make sure to do this during the architecture portion at the start of the process.

I need to make sure all my icons (in the spritesheet) have descriptive alt tags. I will check the backend team are adding them to the CMSable images.

I will only use the <button> tag for elements that fire of javaScript functions. Buttons will only contain either basic text or an image. Anything that links anywhere will be an <a> tag styled to look like a button.

Background image urls need to be in the HTML so they can be accessed by the CMS. Using <img> tags instead of background-image will help screen readers. We are going to try having a style section in the header for CMSable stylings instead of inline styles.

We should add a screen reader into our testing device list. At the very least we should run some accessibility checking during internal review. This checking should be added to our "pre UAT checklist" that I am currently compiling.

TODO: Reflect on these goals in a year..

Naming things is notoriously difficult. Here is my thought process when I added a new element to this blog.

If you scroll to the top and look on the right hand side you will see a link to all my posts. Right now it doesn't exist and I need to name it so I can create it.

I only need to add a tiny bit of css to it. Probably just "float: right" on large enough screens. It will just naturally stack on small screens. I don't plan on styling the home link specifically at all so that won't need a class.

My first thought was to put the class 'blog' on the body so this page is namespaced. The problem would be that I would still need a class name to select the link in the name space or use awkward css selectors to get the second link.

Instead I could use BEM and just call the link "blog__right". Right describes the appearance instead of the content and isn't even true on small screens. The content will always be a link so a better name is "blog__link". My class names are always lower case for consistency. I might want to add a similar link on another page. This right aligned link is always in the header so a better, more reusable, name would be "header__link".

I think that is a good name. It's clear what it is, can be used on any page and has the right level of specificity. The only downside is that the home link is also a link in the header but I'm not giving that a class so this will work fine. The name isn't perfect but I can't think of a better one. I told you naming things is hard. I will now stick with that name and get on with creating the element and the new page. At some point you have to decide the name is good enough for now and move on with the project.

If I end up doing something different to what I an currently planning, for example adding more links in the header, then I will look at the new situation and refactor my choice of name.

The benefit is that it is very easy to set up and has lots of built in functionality. The downside is that it is a third party so that adds the risk of the service ceasing or adverts being added. It also locks me in to continuing using their platform. The user expertise is also worse as they would be taken off this site and the branding wouldn't be identical.

I like their simple layout and their philosophy of focusing on the words themselves instead of fancy presentation. It also has a very cool share any selected text feature which, although I could recreate would require a fair amount of testing, so I probably wouldn't bother if I built my own blog. it also has the problems of being a third party.

It is third party but it is also the home of front end. I already have a pro account and embedding pens would be easy. I did actually decide that I would blog there. You can change the css to match this site but I realised it was going to take a lot of time to chance their complicated layout to match the minimalism here. I also quickly realised that there platform is rather feature lacking and when I read their development blog they had no posts on updates or improvements to the blog which was discouraging. I realised it would be nearly as quick to build my own blog as it would be to change all their css.

Build my own:

I already have a master Pug/Jade template and the css practically done. If and when I want additional features I will build then myself.

At about ten posts I'll split this blog into multiple pages. I could use Mustache.js to ajax in more posts for infinite scrolling. A previous comments section could be included but at the moment I don't want this to be a two way dialogue. Discussion could be kept to another social medium with links to the blog instead of embedding it here.

There are other advantages of building my own blog. The hosting lasts as long as the website and I know it'll be advert free. The styling perfectly matches the website which creates a consistent and pleasant UX. I will have complete control over which features I add and best of all I will learn how to create them.

As this blog grows I will have to think about categories, tags, overview pages and maybe adding in a search feature. The only thing I going to miss from codepen is writing in markup but as each post will be mainly just paragraphs of text and I will be using Pug/Jade it should be fine.

Optimising: Minimising http requests

We already use client dependency to concatenate all our javascript files into one file and all the css into one file. The main problems were the icon images.

To solve this I added a plugin to the grunt file. It takes all the images in the "icons" folder and combines them into one "spritesheet". It then optimises the resulting png to reduce file size.

Now instead of each icon needing an http request they all only require one request. The total size of them is also slightly reduced. This should reduce content and script blocking on page load.

Grunt Automation Choices - When to optimise?

All the CSS needs to be concatenated and minified for production. This doesn't take very long and so could be done in dev too. The advantage is that then the release build is the same as the dev environment, minimising additional bugs. I have chosen not to do this. During dev the grunt file doesn't optimise the CSS nor the javascript. This helps in debugging as the maps show you exactly which file the errors are coming from. I think this outweighs the risk of additional unseen bugs.

Print.css

In an ideal world we'd have time to create a css file so that printing the site looks nice. People are likely to print out job listings. If we could make this, or have a standardised one, or find a standardised one then I would like to add this to the build process. Css-tricks has a good article.