A perfect start

I got an opportunity to steal a client (all above board) from my previous employers, No Divide which gave me the cushion to go for freelance, full-time. I get on really well with the folks at Scott’s Bass Lessons and will continue to work with them, long-term. Working with them has provided some much needed stability because it wasn’t the ideal time to start as a freelancer, with a 6 week old baby!

With those folks, I’m working on something I really enjoy working on: a brand new design system. With their design system, I’m helping them to roll a completely new look and feel out over their vast, existing platform. The first part of this work will go live in December when we launch their brand new homepage. This design system is also enabling their team to better visualise the available design assets, so they can make consistent and informed decisions. I’m really looking forward to seeing how this will pan out, long-term.

This contract has brought some long term stability, which has enabled me to not panic and snatch at any project that is available. It means I can cherry-pick projects that appeal to me, which is super empowering. It’s also enabling me to work with people and organisations that I truly admire.

This is just the start

I’m only a month in and that month has been incredibly busy. This is mainly down to doing a lot of client work, but also meetings — lots and lots and lots of meetings. I’ve been a bit too open with booking in meetings, of which most have been a complete waste of time. From now on, I won’t have a meeting until I know:

• What the project budget is
• What the deadline is
• If the company in question has shady links that are at odds with my own ethical standards

I know I’m in a very privileged position to be operating like that, but it’s important that I make the most of my time.

I’m also not moaning about meetings because on one of those occasions, I spoke with someone who works on an incredible project that will help more women get into code. I very much look forward to helping them out in the future.

Wrapping up

This is only a little post to note down how my first month as a freelancer has gone and how I see it panning out in the future. I’m just about to embark on a tonne of work for a very exciting new client who I’ve been a big fan of for a lot of years. To say I’m excited would be a massive understatment.

I’ll finish up by recommending that if you are thinking about going freelance, or are already freelance, you read this post by my pal, Ben Howdle. It’s incredibly pragmatic and has already gotten me through a few wobbles.

👋 If you want to work with me, I’m taking bookings for Q2 2019, so get in touch 🚀

Originally published at andy-bell.design.

Making work, work for me

The gang and I at No Divide are going on hiatus and I want to maintain the flexible work day that we had there. We very much made work fit around us, rather than the other way around and I was struggling to get a role in a company that worked like that.

I also want to maintain a sensible pace of work. We put a lot of consideration into what we did there and I’ve struggled to find companies that would be an exact fit on that front. It’s not to say we necessarily did things better, but it’s my preferred way of working, rather than shipping fast and frequently.

After a couple of ideal opportunities got away from me, I decided to go for the next best thing: independence. I actually started my career in the web as a freelancer, back in 2009, so it’ll be interesting to do it again with much more experience and much better contacts. I’ve learnt how not to do things in various agency roles too, so I feel pretty confident that I’ll do it right this time.

The sort of work I’m looking for

I’m really into progressive enhancement, user experience, accessibility and inclusivity. I’m multi-disciplined in that I work as both a designer and a developer. This means I can work from concept, right though to delivery if needed. Any projects that allow me to do that will be warmly received.

These are the sort of projects / contexts that I’d be most useful in:

• A new startup that needs help making an MVP or prototype
• Design systems
• Pattern libraries (design and/or build)
• User experience research, design and prototypes
• User interface design
• HTML and CSS development
• React, Vue and Node development
• Accessibility audits and improvements
• WordPress / Craft CMS / Perch CMS websites (design and/or build)
• Jekyll / Hugo / Gatsby / Eleventy websites (design and/or build)
• Development for agencies that need a bit of help to get projects done

Hire me

I’m booking projects for 2019, so I’d love to talk. I prefer to work remotely, but I’m very happy to come to you for meetings and workshops.

💌 Get in touch

Originally published at hankchizljaw.io.

How many times have you thought to yourself something like this?

“As much as I love making <div> elements buttons, it’d be great if there was an npm package that I could install that would give me keyboard events and focus.”

Think no more, because I have exciting news. There’s a native element called a <button>, and I’m here to talk about it with you today.

A what now?

A <button> gives you everything you want out of the box:

• It’s focusable
• If you attach a click event, you get keyboard events for ✨FREE✨
• A screen reader will announce it appropriately
• It’s primary function is not dividing content, it’s actually an interactive element

Best of all, it’s already in every browser!

Oh, these are hard to style, though

Ah yes, the primary reason we find lots of <div onClick={this.myFunction}> in our hot-framework.js codebases is that buttons are tough to style, apparently. What if I told you that a few of lines of CSS will make it look like a standard element, though?

button {
    display: inline-block;
    border: none;
    margin: 0;
    padding: 0;
    font-family: sans-serif; /* Use whatever font-family you want */
    font-size: 1rem;
    line-height: 1;
    background: transparent;
    -webkit-appearance: none;
}

Pretty neat, huh? Wanna see it in action? No build steps required, my friend — just use some HTML and CSS 🎉.

Here’s a demo in CodePen for convenience:

Are you fan of using JavaScript to style your elements? Here’s an object that you can steal:

const buttonStyles = {
    'display': 'inline-block',
    'border': 'none',
    'margin': '0',
    'padding': '0',
    'font-family': 'sans-serif',
    'font-size': '1rem',
    'background': 'transparent',
    'line-height': '1',
    '-webkit-appearance': 'none'
};

Wrapping up with serious note

Although there are elements of satire to this post, it’s got a really important message. You get so much for free by using appropriate HTML elements. Sure, they can be a pain in the butt to style, but the tradeoff is minimal — especially when they’ll make the overall user experience much better. Don’t make users suffer for your personal convenience.

Hopefully with the above styles, or even a more detailed version like this one, you’ll consider using <button> elements instead of <div> elements for buttons in your apps and websites. I also recommend that you look at the A11y Nutrition Card, by Dave Rupert to make sure you’re meeting accessibility standards.

We’re all in this together to make our user’s lives easier because that’s the real priority.

Originally published at hankchizljaw.io.

Back in July, I launched a handy web app called My Browser. The premise was simple: generate a detailed report about a user’s web browser and create a URL to make sharing that report easy. In less than two months, My Browser generated an impressive 25,000 reports. That’s an average of 1,250 uses a day!

It’s become much more successful than I ever imagined, but why? This wasn’t a particularly new idea. Similar products and websites exist, so what is it that made My Browser different? I believe the answer is progressive enhancement. I took a gamble when I changed up my build approach, and I’m very happy I did.

I’ve decided to share some of the useful things I’ve learned along the way, in the hope that you’ll benefit and feel inspired to consider progressive enhancement as a concept too.

Improvement by simplification

Without a doubt, building My Browser progressively paved the way towards a simpler future and longer lifespan for this app. Not only do I have a very maintainable codebase to work with, but I have one that can also grow very easily.

Building progressively means that I’ve avoided the need for a bunch of fixes and polyfills for older browsers. If something isn’t supported then the app provides a simpler method.

The above figure is often used to demonstrate a minimum viable product, but I think it can also be used to demonstrate a minimum viable experience. The skateboard may be a little slower, but it doesn’t stop the user getting to where they want to go. So, if the user’s browser doesn’t support JavaScript or modern CSS then it doesn’t break, it presents the default experience instead: a button which instructs the user to generate a report. The user will experience a very similar process, but has to perform one extra click.

The beauty of this approach is that the site doesn’t ever appear broken and the user won’t even be aware that they are getting the ‘default’ experience. With progressive enhancement, every user has their own experience of the site, rather than an experience that the designers and developers demand of them.

It was crucial to have this default performance in place, because if this reporting tool refused to report, it would become totally useless. It needs to perform one job and to perform it well, and it needs to be supported in all browsers.

import { whoKnows } from ‘black-box’;

For some reason, the progressive enhancement approach seems to be surprisingly uncommon in our industry. So, for contrast, let’s explore a more popular but more prone-to-headaches build concept.

A much more common build approach is to throw dependencies at a project until the singular experience works on every browser. This can be very time consuming and frustrating, and often results in a proud declaration that you “no longer support IE!”, usually on Twitter.

Now, I can’t shame others without shaming myself — I’ve done that many times — and it’s only through experience and a solid foundation of skepticism for what’s “hot” that I’ve been kept on the fringes of that group.

I put it down to ever-increasing experience and associating myself with sensible, pragmatic figures in the industry that I’ve now begun to appreciate progressive enhancement as the de facto way to build things, instead of an evergreen approach.

A reminder that it’s okay to change your default

I’ve always been very skeptical of frameworks, especially heavy-duty ones. I appreciate that frameworks like React are very popular and useful but I think they should be used where necessary, rather than used by default.

Even Netflix, who are famously very into React, have talked about how rolling out a vanilla JavaScript homepage saw huge performance improvements. I single out React here because more commonly than not, the single default HTML element that’s rendered inside the <body> tag is a <div id="root"> element. This means that unless that big ol’ bundle arrives in one piece, you aren’t going to get any experience whatsoever.

Luckily there are methods such as server-side rendering, otherwise known as universal or isomorphic apps, that can help introduce a more progressive workflow.

Pixel perfection is becoming more difficult

As an industry, myself previously included, we are infatuated with this concept of pixel-perfect display for every browser. As Jeremy Keith suggests in Resilient Web Design, this is in-fact a collective, consensual hallucination, an artefact of the PSD-to-HTML desktop-only era of web design. We often felt the need to painfully hand-craft our websites to look beautiful, even in IE6. The problem now is that there’s so much variation these days, not just with browsers, but with devices, operating systems and connection speeds, so it’s impossible to be pixel perfect every time.

Another thing we seem to forget is that there’s a huge amount of fragmentation, particularly in the most popular mobile operating system around — Android — which, at the time of writing, has over 70% of the mobile market share.

We throw so much weight at trying to make our websites look the same in every browser that a lot of unnecessary bloat hangs around for way longer than it should. Tools like AutoPrefixer, heavy-duty resets and 960px 12 column grid systems have become bloat, just when newer, native, dedicated solutions like CSS Grid drop with massive support and no vendor prefixes (if you ignore Microsoft’s early prototype).

A modern approach to CSS

I decided to make a big change in my own approach to CSS for My Browser. I wanted to reduce weight and complexity. I chose to go completely ‘vanilla’, which differs to my usual preference of using Sass.

Don’t get me wrong, I love Sass and periodically write about it, but I’ve had a theory that it produces extra weight in the code that I write, mainly due to laziness and/or mild over-engineering. I was certainly made very aware of what was being output when forced to write the actual output code.

Writing vanilla CSS seemed to help me with progressive enhancement a lot. I don’t know if there’s an exact science there, but I definitely felt more aware. It’s also incredibly powerful compared to the CSS we had when Sass first arrived.

With ever-increasing support for Custom Properties, a lot of the most common use-cases for Sass are already available to us and a progressive approach to these newer tools is handy to keep in mind too.

If you’re thinking “What even is progressively enhanced CSS?”. Let me show you:

This example of a CSS Grid powered layout will support 92% of browsers. The other 8% will get stacked columns. This snippet of CSS is tiny and there are no expensive polyfills and fallbacks. Not bad, eh?

This is the exact approach that was taken with My Browser and that, along with modern, vanilla JavaScript, means that the total page size currently sits at 85kb. It can probably also support browsers as far back as IE7.

A modern approach to JavaScript

Much like the approach with CSS, the JavaScript on My Browser is also completely vanilla. I work with JavaScript frameworks every day, so I admit, going back to vanilla JavaScript was a daunting concept. Luckily, I’ve been learning about JavaScript’s native approach to componentisation: Web Components, of which I have a separate learning journal.

Working with Web Components feels very similar to working with Vue in a lot of senses, but the main similarity is that you can put your default experience within your custom HTML element, which gives you progressive enhancement for free.

Check out this example where the default experience is a simple heading and some paragraphs. If Web Components are supported, it transforms into a fancy toggle panel thanks to the magic of <slot>s and the Shadow DOM:

You can see the demo in action here and the source code here.

This approach to building My Browser allowed me to only have to write a bit more server-side code to accommodate both fetch based requests and form based requests. Again, the user will likely have no idea that their experience differs from another person’s. And it enabled me to ship not just code with no polyfills and hacks, but also non-transpiled ES6 code.

Thanks to the declarative nature of HTML, I know that if the JavaScript fails to execute then the default experience of a form-based, single click button will be available to the user.

The main usage of Web Components on My Browser is actually the report view. The default experience is a nicely styled representation of the JSON data that the app produces. If Web Components are fully supported though, the app automatically replaces this with a grid of nice looking icons and a more visually pleasing representation of the data. Again, this only required a few if statements.

My Browser is a very small and simple app, but it wasn’t only the small size that made the progressive enhancement possible, it was a change in my mindset…

Let’s change how we think about Progressive Enhancement

Progressive enhancement isn’t necessarily more work and it certainly isn’t a non-JavaScript fallback, it’s a change in how we think about our projects. A complete mindset change is required here and it starts by remembering that you don’t build websites for yourself, you build them for others.

There’s a common approach of “build for the best possible devices and browsers, then apply heavy-handed fixes just before go-live”. This usually results in said tests and fixes only happening at initial launch, once the issues have already been seen by many and have slowed down the experience.

An industry full of Apple Macs and high-speed fibre broadband certainly doesn’t help change this mentality, I need to emphasise this point: by having a high-speed connection, you are part of a privileged few, not the many.

For the many!

A recent article by Addy Osmani (which I recommend that you read) brilliantly highlights how bloated JavaScript payloads can be a lot more detrimental than you think. Especially when you consider poor connections.

Shipping multiple megabytes of JavaScript can be incredibly damaging for low-powered devices because of the sheer amount of computing that’s required in order to parse and execute it. You may have guessed where I’m going with this — The progressive approach means that if your premium experience features lots of JavaScript, then at least your users will be able to interact with the default experience if their slow connection lets them down.

By creating a minimum viable experience, you’re creating a better experience for a lot more people than you might think you are.

Smaller tools are nearly always better

My Browser’s small size certainly helps. It’s very lightweight in that it only takes a few packets of data to fully load and it’s also progressive if those packets fail for some reason.

This has inspired me to release a new tool for managing state called Beedle, which I won’t dwell too much on, but it gives you a lot of power to manage state in your application and is only around 0.5kb in size.

We’re also working internally at No Divide on similar tools that will be equally as tiny. The micro-library approach is very appealing when you’re hyper-aware of your output bundle’s size — tiny tools can definitely be the way forward.

Popular frameworks like React and Vue are excellent for big applications, they are really helpful. We love Vue here at No Divide. This is certainly not a “don’t use big frameworks” post either, because as with most things in this industry, it depends on what you’re doing. You can also improve the performance of large frameworks with methods such as code-splitting. This excellent article by Jeremy Wagner gives you heaps of knowledge to get you started.

An approach I would recommend that you consider is to be very aware of your add-ons and extra dependencies. Tools such as Import Cost for VS Code can really help with the decision making process, and might encourage you to use smaller libraries that have slightly less features than their popular counterparts.

Another approach that’s worth considering is: if you’re building something simple, maybe a large framework isn’t necessary. Libraries such as Reef by Chris Ferdinandi are really handy. I also strongly recommend using Web Components.

At No Divide, we’re working on a small progressive web app to help people monitor their personal finances and that is being built in a progressively enhanced fashion with Web Components. We’re hoping it’ll be absolutely tiny and completely accessible to anyone!

Wrapping up

I hope that if you’ve not already started considering progressive enhancement, that this post has been a good source of inspiration for you. Changing your mindset is really hard and it’s something that we’re continually trying to improve at No Divide, constantly monitoring our own processes and improving them.

The benefits of progressive enhancement are incredible, so it’s really worth considering. Smaller, more considered payloads are only ever going to improve everyone’s experience, not just your own.

I love to talk about this over on Twitter where you can find me at @hankchizljaw. You can also find the No Divide team at @NoDivide.

The power of progressive enhancement was originally published in No Divide on Medium, where people are continuing the conversation by highlighting and responding to this story.

Getting technical details from a bug report or support ticket is hard.

Often, when a report of a weird bug on the front-end of a website or web app comes in, it’ll contain something like “Feature X doesn’t work very well on Safari” or “The layout is odd on Firefox”. The problem here is that there’s a plethora of Safari and Firefox versions and even more variation in operating systems.

This vague information often results in more questions that are hard to answer. It’s really difficult to extract relevant data from whoever reported the issue because you’ve normally got to explain in a lot of detail how to get it to you. I decided to make a little web app that does all of that for you, the moment that you land on the page.

There’s existing tools to extract browser information, but they could be better, so I decided to build “My Browser” to make everyone’s lives a little easier. I’ll spend some time in this post explaining what it’s all about.

I made “My Browser” to do one job and to do it well. Its job is to extract and present data about a user’s browser and environment. It takes the information, stores it, then provides an easy to share url that links to a report. That’s all it does and I’ve worked hard to make sure it does it as efficiently as possible.

I’ve put a lot of effort into making the user experience frictionless and sharing the generated report easy. This is done by providing clear and simple options that require little to no effort. In my opinion, that’s where other similar tools fall down. They’re great at gathering and presenting data, but sharing that data is clunky. I’ve often found that I’ve had to explain how to use these tools, which to me, defeats the object of their purpose.

A tool that causes more problems isn’t a very helpful tool.

Progressive first

Although the site is built with bleeding edge technology such as web components, it’s built with a progressive-first approach. This means that in order to get the best experience, you need to be on a modern browser, but to do the most basic function — reporting data, you can still do it by pressing a “generate report” button, which is the default state. The data can also be read, regardless of your browser.

The app enhances the user experience by detecting supported features and presenting their UI only where they are supported. It removes default and fallback UI elements at the same time. This means that a user on IE9 will get a very different experience to someone on Chrome, but they shouldn’t notice because the app already works well for them.

We’re given so much for free to make a progressively enhanced website or web app. We’ve got feature detection and @supports in CSS which means that “My Browser” ships with no polyfills, fallbacks or hacks like Autoprefixer. The app degrades gracefully instead.

This has been a very refreshing way to work that I’ve enjoyed a lot. The fact that the whole thing comes in around 25kb tells you how effective progressive enhancement can be for performance too.

Privacy matters

I’m very fortunate to be friends with some very smart and influencial people. Because of this, I shared an early version of “My Browser” with some of them for some initial feedback. I got some incredibly useful ideas and support which I’m endlessly thankful for. In particular, the amazingly talented Laura Kalbag reached out and gave me some very useful advice on privacy and how I was initially handling data.

Based on this help from her, changes were made and extra protection was added to make sure that any data stored on “My Browser” is completely anonymous and there’s no way that your browser can be fingerprinted by corporations or governments.

Privacy is so important to me and I’ll continue to work hard to make sure that all of the data that is collected is protected, transparent and anonymous.

An evolving project

What you see today on mybrowser.fyi is very much a minimum viable product. There’s plans to make it even more useful, which you can see on the roadmap. If you do think of something that will be useful, go ahead and log a feature request!

I also want everything to be transparent, even though the code isn’t open source. If you find a bug or issue, please go ahead and log it on the public issue tracker.

Wrapping up

Go ahead and try out mybrowser.fyi and see if it’ll be helpful for you and your team. If you find it useful, please share it with your network. It’ll be great if it makes a positive impact on as many teams as possible 🚀

If you’ve got any questions or comments, get in touch on Twitter.

Originally published at hankchizljaw.io.

We’re very proud of Astrum and how it’s helped so many developers and designers create great pattern libraries. We’re also proud of how stable it’s been since we launched. In this post, I’ll discuss how we’re planning on doing some big updates to the Vue application that powers Astrum.

Time has flown by!

Internally, we’ve had a very busy period launching our own product, Leeve, and also working very hard on client work. Time has flown by (I’ve been here 6 months already 😱) and with that, the technologies that we use to power Astrum have come a long way. There’s some amazing newer features of Vue that will work well for us. These new features have also encouraged a lot of discussion about Astrum.

These discussions have focused on how we see Astrum evolving into an even more useful tool. What is now possible with Vue simply wasn’t available when we first build Astrum 2 years ago.

We’ve come to the inescapable conclusion that we need to rebuild from the ground up.

A rebuild of the application

Suggestions from the community and our own ideas would benefit from better granular control of the content and data within the Astrum application.

One area that we want to tackle is state. Specifically, the centralisation and control of state. If you’re new to modern JavaScript frameworks, state is an abstracted layer of data that can either be contained within a little component, or shared between many components. Imagine the latter being like a notice board on the fridge. Everyone can see it, but only one person in the house can make changes to it. This keeps a level of predictability and stability, but also total transparency.

We use state like this in JavaScript applications to provide a single source of truth to all of our components. It also makes it much easier to test and debug a project, which is great for the application’s resilience. In our opinion, this will be a great core change to Astrum to enable more complex additions in
the long-term.

Because of this change in our approach to state, the new application structure will be centred around Vuex. By abstracting state into its own system, we’ll be able to improve speed with a more asynchronous approach to loading components and content. We’ll also be able to toy with ideas such as implementing web sockets to help with live reload and a command-line based node-server.

With this in mind, we’re looking to abstract the logic from components as much as possible, to keep things focussed and hopefully, more maintainable. This should also open up opportunities to introduce different types of patterns, along with pattern-level state and icon systems.

Work is already underway

The rebuild has been discussed, planned and is currently underway. Because of this, we’ll gradually be doing housekeeping around the project in terms of pull requests and issues.

We really appreciate the efforts the Astrum community go to, but unfortunately, some of the pull requests and issues that don’t align with this new rebuild will be closed. This is mainly down to the fact that we don’t want to have to delete your work straight after merging it into the core. We think that would be unfair. We’ll also work on our contributing guide so there’s no animosity about contributing to Astrum. We want to be as transparent as possible about how people can help in the most effective way.

We’re going to start organising the projects section of the repository into smaller sprints that are well labeled. This will all begin once the rebuild is in-place though. We’ll communicate when these issues are ready to be worked on for those who are keen to get involved in the project.

A note on backwards compatibility

One thing we want to reassure the community on is backwards compatibility. Although we’re re-writing the core application—we won’t break existing instances of Astrum.

When you run astrum update you’ll get the new and improved Astrum with all the new features it provides, but everything you’d setup previously will just work as it did before.

Thank you

Lastly, we want to take this opportunity to thank the Astrum community for all of their involvement over the last couple of years. The community helps to make this product as good as it is and our focus is and always willbe making Astrum both feature-rich and portable, so it can be dropped into any web project.

We’ll be periodically updating you all on the progress of the rebuild. As things progress, we’ll be able to let you all know when this will be ready to launch. For now though, we’ve got lots to do, so we’d best get cracking!

If you have any comments or questions about this rebuild, head over to this dedicated GitHub issue. You can also follow us on Twitter @getastrum.

Astrum: looking forward was originally published in No Divide on Medium, where people are continuing the conversation by highlighting and responding to this story.

Three weeks ago, while watching Countryfile (I’m getting old), I came up with Dev Pal. I wasn’t sure if it would do very well, so I made a very quick and dirty logo and an MVP which is powered by CodePen Projects and Crisp chat.

I’ve been absolutely floored by how well it has done. So far, I’ve helped about 80 people 😱. I honestly thought I would only ever help a handful of people, so this success has inspired me to look at pushing Dev Pal into something really helpful.

A great success to build on 🎉

Because the idea has been validated, I’m going to push some hard work into the project. I want to extend it to more than just a landing page with a third party chat interface, so this is what I’m going to do with it:

Roll out a bespoke chat system

Crisp has been great, but it’s a support tool, so it doesn’t fully fit the purpose of Dev Pal. I’m going to roll something out that’s less geared towards instant messaging and geared more towards full, immersive mentorship. Tools such as reactive JavaScript frameworks and state management libraries will enable me to make something truly useful for this and I’ve already been playing with a proof of concept.

Produce written teaching material

I’m going to design and build a proper site using WordPress and Gutenberg, because I think it’ll be a great way for me to practice what I preach by getting back into working with the CMS, with its exciting new JavaScript setup.

With this new site, I’m going to write some foundation-level material to teach beginner developers some core skills. This will mainly be JavaScript orientated, but I’ll cover the whole front-end landscape where appropriate.

The aim here is to produce completely free content that’s kept up to date which can be consumed by anyone, at any time. Keeping the articles at a foundation level will hopefully create material that compliments the plethora of excellent teaching material already out there.

Screencasts and maybe a podcast

Folks seem to like video content for learning. I made a mini poll on Twitter to test the theory.

Andy Bell on Twitter

How do you prefer tutorial content to be served? (RTs appreciated for reach)

With this in mind, I think something really useful will be recording screencasts of me building out some core concepts and explain what I’m doing while I do it. Hopefully this will help and inspire some devs, because when they see how many mistakes I make and how I get stuck all the time, they’ll hopefully feel a lot better about themselves. This is quite the trend at the moment and it’s a trend I’m certainly becoming very fond of.

Another thing I think folks might find useful is hearing about some of my other pals who are also producing educational material. I think some sort of podcast might help with that.

How can you help?

A lot of work needs to be done and with that, there’s some material costs too. I’ve gone ahead and set up a Patreon to try and help with them. I don’t want to have to rely on adverts or paywalls and I also don’t want to have to create premium content because I want Dev Pal to be accessible to as many people as possible, regardless of their financial situation.

I’d be over the moon if you could support Dev Pal on Patreon. Even $1 a month would go a long way. If you represent a company, I’ve got a special tier that’ll get your logo on the new website too!

Let’s make Dev Pal great as a community 🙌

Wrapping up

There’s a lot of work to do, so there’s going to be a bit of time before anything is visible, because this is a side-project that compliments my full-time job. For now, the MVP will carry on doing what it’s doing: enabling me to help beginner developers, so tell all of your friends 🚀

Thanks for reading this follow-up. Dev Pal’s success is largely down to my pals sharing it with their Twitter followers. If you could do the same, that would be hugely appreciated 🤟

Useful links:

My Twitter: @hankchizljaw
DevPal Twitter: @YourDevPal
DevPal Site: https://devpal.io
Patreon Page: https://www.patreon.com/hankchizljaw

I had this thought a week ago:

Andy Bell on Twitter

I'm in a perpetual state of worry about how what a real front-end dev is, according to social media. I worry it'll put off some really awesome talent, because it looks like there's too much to learn. HTML, CSS, #a11y and JavaScript. The rest can be picked up as you need it.

I’ve been wondering how I can help folks who are learning front-end development for a while, and amongst a few ideas, this one stood out.

Introducing Dev Pal

I came up with the concept that if I created a landing page, someone could come along with a front-end development issue they were having, or a question about their career and I would be able to give them a pragmatic answer, or advice.

I offered similar on Twitter a couple of days ago:

Andy Bell on Twitter

Hello Pals. Just a note to say if you're learning front-end development and you need help with your CSS, HTML or JavaScript, hit me up - I'll give you a hand/advice. DMs are always open.

I thought something more sustainable may be more appropriate because Twitter has many downfalls in terms of engagement and community management.

I decided to knock-up a landing page with CodePen Projects and integrate my new favourite support tool, Crisp.

I chose Crisp for a couple of reasons:

• It has incredible multi-language tools, such as live translate
• It has great tools for blocking trolls
• It has a lovely, lightweight, customisable UI

A proof of concept to see how it goes

I hope this is a good idea and I hope I can help some folk out. This MVP / proof of concept only took about 30 mins to put together, because I wanted to test the water and see how it went. It’s good to get something up and running to test my concept, without spending weeks building it, thanks to CodePen.

It’d be awesome if you could share Dev Pal with your pals and let’s see if it works out. If it does, it’s certainly something I want to develop into an even more useful offering. If it doesn’t, it’ll be a shame, but at least I tried it out. Regardless — if I even just help one person, it’ll be totally worth it.

For now, here it is: check out https://devpal.io

If you’re in the WordPress community, you’ve probably been thinking and talking about Gutenberg for quite a while now. There seems to be a real mix of feelings within the community which range from excitement to worry. Unfortunately, the latter seems to be more prominent at the moment.

A feeling of worry isn’t a surprise though. The WordPress development ecosystem hasn’t really changed over its lifetime. We’ve had big additions over the years such as Custom Post Types and the incredible REST API, but generally, it’s been the same old loop. This is arguably one of the key reasons why Wordpress powers around 30% of the internet.

With a low barrier to entry, an approachable theme system and the famous 5 minute install, it’s easy to see why WordPress is so popular with developers from all ability levels. This is all potentially going to change though, because Gutenberg looks like it’s really gearing up to rock the boat.

About my experience with WordPress

Before we dive in, I thought it’d be useful to give you, the reader some context about my experience with WordPress.

I first picked up WordPress in 2010 when it was at about version 2.9 and I absolutely loved it. This feeling was stoked when I found Digging Into WordPress by Chris Coyier and Jeff Starr, which helped me learn fast to deliver a client project which I’d massively over-promised on…

Over the years I’ve dipped in-and-out of the WordPress world, working both on custom themes for websites and maintaining other developer’s work, so I’ve kept in tune with the API changes and community.

You could say…
( •_•)
( •_•)>⌐■-■
I’ve always been in the loop…
(⌐■_■)

Anyway…enough puns, let’s get cracking.

What’s Gutenberg?!?

Gutenberg is an all-immersive editor that allows an author to build out their content in easy to manage blocks in an almost distraction free setting. The block-based setup means that they can easily edit and rearrange content with no knowledge of HTML whatsoever.

It brings great power to content-producers, which are the heart of WordPress. It’s always worth remembering that WordPress’ largest sites are generally article based, so enhancing the production of articles needs to be the focus. I think Gutenberg is going to be a dream for content producers on that front.

Gutenberg feels really familiar to me because I’m a huge fan of Notion, which uses a similar, more advanced concept. It’s also similar to Dropbox Paper and Medium. It’s certainly a trend in content production that’s being capitalised on by the core WordPress team.

But, even with all of this exciting innovation, Gutenberg is not going down well with some of the WordPress community.

Understandable concerns

The main theme I’m picking up with the negative comments about Gutenburg is:

“What about our old sites? Why isn’t there an option to turn it off for them?”

I totally get that, because I’ve done a lot of work with WordPress, of which some has been maintaining some really creaky sites. This in my experience is usually caused by a developer or team of developers throwing multiple plugins at the site to make it do what they want it to do.

I get why they do that though. The platform enables it.

When I first started working with WordPress, websites were very much header, content, sidebar and footer only. The platform supported that with ease. As the web has developed though, the introduction of plugins such as ACF and Visual Composer have stepped in to help support that evolution.

The use of these plugins has however, made for a pretty janky user experience on the CMS-end and really adds weight to the front-end if not used responsibly. Because of this, it totally makes sense that WordPress would introduce Gutenberg into the CMS to flip that experience back around.

A change for me in custom WordPress development

Theme and plugin development within the WordPress ecosystem has always been a pain point for me. I’m not very strong with PHP and have always worked with it out of necessity rather than choice. Because of this, I’ve never enjoyed rolling out custom themes and plugins for WordPress.

I’ve also never been the biggest fan of the WordPress front-end either. I much prefer setups like Craft CMS and Kirby CMS because they tend to stay out of the way of my markup a lot more. This opinion and working within certain tech stacks in my day-job has seen me existing away from WordPress for quite some time now and if I’m really honest: I’ve not missed it’s workflow too much.

That opinion is changing though, thanks to Gutenberg and the power it gives to me, a front-end developer.

Modern JavaScript and design systems are suddenly first class citizens

Gutenberg brings in a heavy reliance on JavaScript for custom block development. To a JavaScript developer like myself, this is a dream scenario. What’s even better is that structure of a custom block is reminiscent of modern frameworks, which make it instantly recognisable and above all, attractive.

With a solid Webpack (or alternative) setup, we can be putting together custom blocks with ES6 and JSX. This is a world away from wrestling the jQuery-ridden spaghetti jungle of old and it’s a setup that’s making me want to come back to the WordPress community with arms-wide-open to give it a big hug. Gutenburg is more than a new editor because of this. In my opinion, it’s a movement.

Better theme development

This new infrastructure makes theme development more appealing to me too. I can see my template’s resembling something like this:

Mind blown, right? Abstracting the theme into blocks enables me to not work within the classic template system, which enables this sort of thing. This is also because Gutenberg’s block structure sits perfectly with component driven design systems, which is the way I love to work. This is true even for a small brochure site.

The patterns and components that I build with HTML and CSS can be translated into completely editable blocks of content by converting them into a compact, JSX driven component. This also means that the content producers have complete control with a tight style guide driven based system to work with which is incredibly easy to maintain.

With modern CSS and smart strategies to control rhythm and flow between components, there should be no reason that someone couldn’t fire up a new page and build it out from scratch. Importantly, this is done with all of the content being stored in one single column in one single table. Compared to the scattered and inefficient data-sets that custom field setups and plugins generate, this is massive in terms of performance and speed. Again, music to a front-end developer’s ears.

Gutenberg should give WordPress its identity back

From the outside, it’s seems like WordPress sites have been getting very bloated and very complex, both visually and technically. I understand that will largely be down to demand, but I can’t help think that it’s been pushed a bit too far at times.

With frameworks like Laravel around, it seems almost incomprehensible that someone would build something more complex than a content-based website with WordPress, but they do. I think this is contributing to an issue of a lack of identity where the lines between content management system and application framework are being blurred. This, in my opinion can have a negative impact to both new developers and “outsiders”, because it has an impact on searchable help content, such as within StackOverflow.

The way I see it with Gutenberg is that the WordPress core team have very much stuck a flag in the ground which screams content over anything else and they’ve produced one heck of a tool to push WordPress right back to the top with it too.

I want to help

So, aside from dumping my thoughts into this piece, I wanted to talk about how I hope that I can hopefully help the WordPress community in this transitional period. I’ve discussed the challenges of Gutenberg with a few friends who are working with WordPress daily about their worries and aside from legacy project issues, the main worry seems to relate to the modern JavaScript stack and the sudden reliance on it.

The modern JavaScript stack hasn’t made much ground in the WordPress world, which makes total sense based on the nature of WordPress development. I can only imagine how daunting some of the Gutenberg JavaScript stuff looks to someone who doesn’t work with that sort of structure on a regular basis too.

I hope to provide some remedy to this, because I’m going to create a reasonably in-depth tutorial on this stack and how you can work with it within the context of WordPress and Gutenberg. It’s currently being planned and revolves around custom block development, but starts by providing a primer to the modern JavaScript world to give developers a better core understanding.

Alongside this I have been planning a tutorial on developing a WordPress theme with Vue JS and the WordPress API. I’m going to pause that for a while so that I can push the former out as I think something related to Gutenberg will be more useful to the WordPress community. I do think a Vue JS based theme tutorial will provide some great knowledge to WordPress developers who are learning JavaScript though.

I think longer-term, some tutorials on custom theme development with custom Gutenberg blocks will be useful too. I think that’s a while off for now, but certainly being thought about.

If any of this stuff can even help just one WordPress developer get their head around this new situation, I’ll be super happy, so I’m looking forward to digging in.

For now though, stay tuned. I’ll report progress on Twitter as and when it’s appropriate to do so.

Wrapping up

Even though some of my comments could be deemed as harsh, I make them with the best intentions. I love WordPress and its community because they gave me so much, early in my career. I just want to provide an alternative viewpoint on Gutenberg and also offer my help.

I imagine some developers feel like I did when Apple announced that they wouldn’t support flash anymore. It was a worrying time then and I totally feel your pain now. I was lucky enough to be able to pickup JavaScript and develop a more sustainable skillset. I hope I can help you folks do that too :)

If you liked this post, give it some claps so it can reach others in the WordPress community. If you’ve got a comment, add a response or hit me up on Twitter.

Click here to share this article on LinkedIn »

Working with JavaScript can be one hell of a wild ride. These days, we’ve got some tools to help us make that ride a little less wild than it has been in the past. The modern JavaScript stack can be daunting to get into, so this post is designed to help you dip your toe into the linting water with a view to helping you better understand the plethora of more complicated articles out there on the subject.

The aim of the game with linting is to help you deploy better code into the wild. Used alongside testing, it can make a huge difference in preventing silly errors that can harm a user’s experience. It’s hard to get your head around initially, so let’s do some really high level stuff and focus only on the most basic elements, so you can see how it works. After that, you should hopefully be able to continue learning with that base knowledge you learned today.

Let’s dive in.

Introducing ESLint

ESLint describes itself as “The pluggable linting utility for JavaScript and JSX”. I think that needs building on for this post, though.

To use an analogy — ESLint is like a parking warden. It’s relentless and pedantic, but as much as you want to hate it, you can’t because it helps to maintain order.

But what does it do?

You set some house-rules and ESLint will tell you if those rules are broken. You can enforce these rules in a number of ways, such as:

• You can run eslint your-filename.js in your terminal
• You can attach it to your build setup such as Webpack or Gulp. ESLint can stop the build in its tracks if it hits an issue
• You can set it up in your code editor so it constantly watches the files that you’re working on
• You can set it up in a pre-commit hook, so that invalid code can’t be added to your repository

Some of those scenarios are intense and you’re here to learn the basics, so let’s do exactly that and tackle the third point in that list. We’re going to learn how to get ESLint running with your code editor.

Getting started

The first thing we need to do is globally install ESLint on your machine with NPM. If you haven’t got Node or NPM installed, go ahead and do that first.

Open up your terminal app and run the following:

npm install -g eslint

That command basically says “Grab ESLint from NPM and make the eslint command globally accessible on my machine”.

Now that we’ve got it installed, we need to set our rules and we’ve got a couple of options available to us to do that.

The first option is navigate to your project in terminal by running:

cd /the/path/to/your/project

Once you are in there, run:

eslint --init

This will fire up a setup wizard which will either ask you questions about your project, scan your project or let you pick a popular template. This is great, but I think we’ll learn more with the second option.

This option is to add an .eslintrc file to your project root and fill it in.

An .eslintrc or .eslintrc.js file is a definition file for your linting rules. This works great because it keeps the eslint terminal commands clean and also creates a fully transparent setup for you and your team, which is really important when you’re enforcing a coding style and rules.

We’re already in our project directory from the command above, so let’s create an .eslintrc file:

touch .eslintrc

If you ran through the init wizard, you’ll want to clean up the generated file by running this command:

rm .eslintrc.js

Once the .eslintrc file is created, open it up and we’ll add some basic rules to it. Let’s start by adding one of my favourites. Add the following to your file:

{
    "rules": {
        "no-unused-vars": "warn"
    }
}

So, what we’ve added there is a basic rule that says: “If there are any unused variables, present a warning”. This is a great rule to get you started and well worth adding to your codebase. You can save a tonne in performance and file size by removing references to unused variables in your code.

Next, let’s add another rule before we move on to our editor integration. Add the following to our .eslintrc file, inside the “rules” section:

"quotes": [2, "single", { "allowTemplateLiterals": true }]

This rule enforces a single quote policy on your JavaScript, unless you’re within a template literal. Pretty neat huh?

For reference, this is what your .eslintrc file should look like now:

{
    "rules": {
        "no-unused-vars": "warn",
        "quotes": [2, "single", { "allowTemplateLiterals": true }]    
    }
}

Integrating our editor

This step really does come down to your editor of choice, so here’s a list of links for some of the most popular editors. Go through the relevant one for you and then come back to carry on!

• Setup Vim
• Setup VS code package
• Setup Atom package
• Setup Sublime Text

Now that your editor is configured, let’s put it all to the test. Create a file called hello.js in your project root.

Add the following code to hello.js:

module.exports = function() {
 
    var hello = "Hello, world";
    var goodBye = "Goodbye, pal";
 
    return hello; 
};

Now, when you save, your editor should have given you two errors and a warning. This is because both of our rules that we set have been broken:

• Our strings are set with double quotes
• The variable goodBye was never used in the function

That was pretty straight-forward, right? Let’s fix the code to wrap up this little tutorial.

Replace the contents of hello.js with the following:

module.exports = function() {
 
    var hello = 'Hello, world';
 
    return hello; 
};

When you save, the errors and warning should clear up because your code is now fully linted! 🎉

Wrapping up

You’ve gone from “WTF is ESLint?” to “I’ve got a pretty good idea about what’s what now”, which is great!

You should probably delve deeper and expand your .eslintrc file to be even more useful for your project. All we’ve added are some rules, so you should check-out the documentation and go from there. If you want a basic example to look at, check out the one I added to the Boilerform GitHub repository, which I maintain.

You could also go back, delete your .eslintrc file and run the
eslint --init command again, now that you have a better understand of what’s going on.

The linting world is your oyster now!

If you liked that post, give it some claps so it can reach others to help them get a handle on the basics of ESLint. If you’ve got a comment, add a response or hit me up on Twitter.

Happy linting!

Getting started with JavaScript linting was originally published in ITNEXT on Medium, where people are continuing the conversation by highlighting and responding to this story.