DEV Community: Dwayne Charrington

On state management and why I stopped using it

Dwayne Charrington — Fri, 25 Jun 2021 06:05:25 +0000

In the front-end/Javascript world, there was once a time when state management reigned supreme. The dominant player was Redux, primarily used by React developers.

State management has (had) a purpose. It allows you to do things like going backwards and forwards throughout the history of the state, convenient for instances where you need some kind of undo functionality. It can also help you understand what is happening inside of your applications thanks to time travel debugging.

Boilerplate & Buy-in

The biggest downside to state management is boilerplate. Once you do the initial setup of your state management, you can have to adhere to the paradigm of the state library you are using. You need to familiarise yourself with concepts such as reducers, actions and other terms that might not be familiar to newcomers.

Then comes the buy-in. You have to change how you structure and write code to use state management solutions like Redux. This means if you want to change to another state management library later on, you have to go through your app and change over every instance. It's rare that any two state management libraries are alike.

With this buy-in comes lock-in meaning once you commit to state management, it's all or nothing. While there is nothing stopping you from intermixing state management with other approaches, conflicting paradigms null the whole point of even having state management in the first place.

As someone who has had the unfortunate job of tearing state management out of a large-scale web application recently, I can tell you that it is torturous.

If state management solutions existed which were able to be included like jQuery and bam! I have state management, maybe it wouldn't be an issue, but architecting my apps around a library that might be deprecated or obsolete sounds like a maintenance nightmare.

It can complicate forms

I cringe every time I see state management being shoehorned into simple forms and I have never seen it done in a clean and unobtrusive way. Almost every state management solution I know of has a forms plugin, the fact you even need an additional plugin says all you need to know: don't use state management for forms if you can avoid it.

When dealing with form data, in most cases you are dealing with ephemeral state. A login form only exists until the user logs in, the data is sent to the server and then that's it. If you're using React, use useState if you have too, but making Redux or X name library bend to your will to have a username and password in your state seems like a waste.

In some cases, you might have form-based data that flows over multiple steps. Think of a signup screen where you need to guide the user through steps and then submit at the end? That's a valid use case for state management because you're effectively filling out a large object of data. Still, you could probably use something less complicated to achieve the same thing.

State management for simple booleans? Please stop

Please, for the sake of everyone else around you: stop using state management for loaders and modals. I swear, almost every web application I have seen using state management has loader states and other booleans in state management for the stupidest of things.

I'm sure you've seen isLoading used more than once or a boolean for showing and hiding a modal before.

Stale data

The age old problem of cache invalidation. I've seen state management used and abused as a form of data cache, fetching some kind of data from the server and storing it locally. Sometimes data doesn't change, but if you're dealing with data that can or will change, invalidating it is another story.

Do you know who solved data caching and invalidation a long time ago? Web browsers. Sometimes a good old fashioned GET request and some properly defined headers is all you need to cache data in your application and have it update when it changes.

Once again, there are solutions out there for these things in state management too. Redux has a trove of plugins that address its shortcomings, for example, but can you imagine buying a car and then continually having to add to it to drive on different roads?

Do you need even need state management?

My advice to anyone starting a new project whether you are using React or Svelte, don't be so quick to reach for state management. It still has merits, time travel debugging and the ability to undo/redo state changes are features I love. But more often than not, you're dealing with data that shouldn't be in state in the first place.

When you use state management I often say, it's like you're building two apps at once.

A Hitchhikers Guide To Unit Testing On The Front-end

Dwayne Charrington — Fri, 24 Jan 2020 01:51:37 +0000

Prior to authoring this post, I had spent an entire month at work solely dedicated to writing tests. This is an unprecedented investment I have not really seen at any other place I have worked.

In that dedicated month combined with my prior testing experiences, I had a few epiphanies and learning experiences that I had to put into written form. A lot of developers want to write tests but rarely get the opportunity to learn the art of testing nor the time to write comprehensive tests.

I have always been a huge proponent of testing. Sadly, I have also experienced what it is like arguing for tests and not really getting as far as I would have imagined in the process. The value of tests is undeniable. Anyone who tells you that writing tests are a waste of time doesn't know what they're talking about.

Having said all of that, this post is not going to be an article telling you how to get your boss, stakeholders and team to understand the importance of tests or convincing them to buy-in. I am making the assumption you are already writing tests (either permission or no permission) or you're about to start writing tests.

You might have one or more of the following questions once you start to dig deeper into the world of testing:

Where do I even begin when writing tests in a preexisting application, especially a large one?
Is Test-Driven Development (TDD) something I should aim for?
What is considered a good test?
Is it okay to have large test files?
Should I be writing end-to-end tests as well as unit and integration tests?
Do I have to have 100% code coverage, what percentage of code coverage is considered enough?
How do I deal with external dependencies and API endpoints?
When should I use mocks and when should I use real code?

A Few Words About Test-Driven Development (TDD)

In an ideal world, we would write our tests before writing our code. Test-driven development is a tried and test technique that promotes writing your tests first and then writing the code to make those tests pass.

The idea behind this approach is you write code that is simplistic, easy-to-read and results in code that requires little to no refactoring. Moreover, the reality of TDD is that it is rare you will get a chance to do TDD in a consistent manner.

One of the biggest downsides to TDD is that there is a time and by proxy, monetary investment. It takes longer to implement a feature if you're writing the test first and then the code, it also might not align with some methodologies like Agile (and popular variant Scrum) which assign points to tasks in a boxed time period of around 2 to 3 weeks.

TDD requires work to be scoped and finalised

Even in workplaces that prescribe to a methodology that promotes scoping work before it is started, we all know this is not always the case. TDD requires the problem you're coding for to be completely scoped and then finalised.

If a specification is changing or the requirements are also changing, it will require rewriting your tests and possibly get you into a situation where you have tests, but nothing you can show (except some green lines in a terminal window).

The only language most stakeholders (management, customers, etc) speak is deliverables. Have you delivered what was asked for? Are a bunch of test code and no code being tested deliverables? In their eyes, it is not.

TDD requires buy-in

The benefits of TDD far outweigh the negatives, but getting buy-in from stakeholders, especially stakeholders who are not "tech-savvy" can be difficult. I have also worked with my fair share of developers who are of the opinion TDD yields very little benefit over testing after development (TAD).

Even if you can get management and bosses to buy-in to TDD (perhaps they were or still are developers) you have the task of getting your team to also be on board which isn't always the easiest thing to do if they have differing opinions on the matter.

If you're having to fight your own team or convince them, you've already lost.

TDD requires discipline

Even once you have managed to get people to buy-in to TDD and have convinced them of the benefits, the reality is a lot of developers have no experience in test-driven development. It's a luxury not many developers have been afforded nor asked for.

If your team is mixed; juniors, intermediates, seniors and principle level developers, the learning experience is one thing, but the discipline aspect required by TDD is another.

For developers however experience who have not been subjected to TDD before, it will be intimidating for them. It's not like getting on a bike and learning to keep your balance.

I have seen experienced developers (10+ years) struggle with TDD because it's a complete and total shift from what they're used too. If you're set in your ways or used to doing things a certain way, old habits die hard as they say.

Usually, developers at the top and bottom are the ones who struggle the most with TDD. Experience and inexperience can be a blessing and a curse.

TDD is great, but...

You're probably not going to get to do it. That is the plain and simple truth, unless you're fortunate to work somewhere that does it, or you have an enthusiastic team that has managed to sell it to management, you're not going to get to do it (at least not properly).

I definitely implore you to try it out in your own personal projects, it's something you should get a taste of, even if it's not on a large team-based project. But just know, you're probably not going to get to do it at work.

Going forward in this article, we are going to make the assumption you're writing tests as you go along or you're testing an existing codebase that has many parts already built and you're retroactively testing them.

You Don't Need To Aim For 100% Code Coverage

A long long time ago in the world of testing, code coverage used to be a metric that was put up on a pedestal alongside other metrics which we have since come to learn do not matter or are inaccurate.

When you write tests just for the sake of trying to get 100% code coverage, you're ignoring one of the biggest benefits of tests by making your tests cover your code instead of thinking about the code itself.

Code coverage is a bit of a mirror trick. It provides the illusion that by having code coverage 100 or close to 100%, that you're covering all of your bases and strengthing your application. Wrong.

A good test aiming to cover 100% of your code is not only a waste of time, but you could also be testing bad code that needs to be refactored. You should never try and cover bad code with good tests. Sometimes you only know code is bad once you've written a test for it. Chicken and egg.

Sure that authentication file which handles logging in users, creating JWT's and other facets of auth might be completely covered, but if there is bad code in there you're testing, all you're doing is making sure that bad code works how it is written.

In most cases, I find 70-75% code coverage is the sweet spot. Sometimes code is so easy to test, you end up hitting 100% coverage without really having to try or think about it.

I Have An Existing Codebase, Where Do I Start?

In my situation, I had a codebase that was two years old with zero tests. Because of time constraints and an ever-evolving specification (user focus groups, stakeholder and customer feedback) test-driven development would never have been an option.

Even if we were to write tests, they would have become outdated or redundant quite quickly. For the first year, features were being added, removed or completely changed as testers and users provided feedback and we iterated.

I found myself in a situation where I was left scratching my head, where do I even begin and what do I test first?

It is tempting to go straight for the low hanging fruit, picking off some of the easiest parts first. But, the reality is those pieces of low hanging fruit being tested would have yielded very little benefit.

For example, we have an accordion component. It's simple in that you give it a title, think of an FAQ question screen where each FAQ is a question that can be expanded to show an answer.

The user clicks the heading, the answer is shown by expanding the box beneath. This component has a few options such as allowing you to group items together so when one is shown, the rest are collapsed or allow all accordions to show and hide independently.

This accordion component is not crucial, it is used in a few places, but not as many as other components are. Writing tests would be easy, it would bump up our code coverage numbers, but would it make me sleep soundly at night knowing this component is tested? No.

Worst-case scenario, if that accordion breaks users won't be able to read faqs. The application itself will still be functioning, users can log in and logout, interacting with other parts of the app mostly without issue.

Complexity !== Importance

Now, you're probably thinking that instead of going for the simple code you should audit your codebase and look for the biggest and most complicated pieces you can find and start there. Hold on, wait a moment.

The complexity of your code can be a red herring.

Sometimes complexity can be a sign of poorly written code, code that needs to be refactored and broken up into smaller pieces. Code that is hard to read and doing too much is a code smell.

It just so happens that bad code is a great candidate for a test. Using tests you can refactor that bad code into something better (which we will get into later on).

For your first few tests, I would not recommend going for complex code that needs to be refactored. While tests will help you do this, you want to aim for something more tangible that instantly pays itself off the moment you write a test.

Once you get your testing mojo, you will get more confident and be able to tackle those slightly harder to test parts of your application. Refactoring requires strong tests, a place where code coverage can help.

Prioritise Your Tests

An application is broken up into three categories. Non-essential, essential and critical. If your application is an online store, the non-essential parts might be tooltips showing on forms or animations on your modals. The essential parts might be image galleries for products, the ability to add them to a wishlist or ability to track an order using an order number.

The critical parts of your application would be a lot more serious. The ability to add an item to a cart, the ability to see your checkout, the ability to enter your payment details and place an order. For an online store, users being able to make purchases is absolutely crucial.

Your first few tests should be testing critical parts of your application. The kind of parts that you know if they fail, the business gets hurt. Examples of crucial areas to test include;

Any code that handles payment information
The ability to log in or log out (in apps with authentication)
Code that handles keep track of what items a user has put into their cart

Endpoints and API's

Inevitably, you will encounter a situation where you need to test some code that makes an API request to some kind of endpoint. It might be an authentication server, it might be a call to load some products for the products page. Whatever it is, you will have to write tests.

I have seen some people write quasi-integration type tests where they will actually make real API calls to a staging database comprised of non-production data. And hey, in some cases it works.

But, I don't recommend in anything but an end-to-end test allowing real API requests to be made. If you're unit testing a function that loads products from an API, use mocks.

Tests need predictable data

The biggest disadvantage of relying on any kind of server or dependency that goes beyond the scope of the test is they cannot be controlled.

What happens if the API goes down?
What happens if the data changes?
What happens if the backend team deploys a schema update and breaks the structure of the data?

For these reasons (and some others probably not mentioned) dealing with real data in tests is a recipe for failure. You should always be relying on mock data, the kind of data you know never changes. Tests are about predictability, inputs and outputs. If you're passing in data expecting a certain result and it changes, the test will fail.

Mocks, Stubs, Libraries & The Curious Case of Third-party Dependencies

Much like code that makes API calls, you will encounter code relying on third-party dependencies. Some of my most recent library encounters and tests have been MomentJS and Lodash.

Here is the thing with using external dependencies, if you're using something like Jest, they will break. Because Jest does not operate within the confines of a real browser, things can get messy really quick.

The lack of proper support for dates in a virtualised browser environment when testing with something like Jest is also a problem. This is where mocks come into play and if you're using Jest, its support for mocking/stubbing dependencies in your application is world-class.

Fortunately, if you use Jest, there are many community authored mocks and libraries which add in support for mocking browser API's and libraries like Lodash.

What constitutes a "good test"?

This is the million-dollar question. A good test can be a lot of things. But really what I personally believe constitutes as a good test is first and foremost, how easy it is to read.

One thing I like to do in my tests is to use comments explaining what I am testing. Yes, in most cases if you're testing good code, it should be clear. But, I find that comments explaining what I am trying to do are useful, especially if I have to revisit large tests later on or for other developers to read.

Repetitive code should be abstracted. Sometimes you will have some code that gets reused throughout different tests. You could duplicate it, but I find that that repeated code should he moved to a function. Case in point, a function that is responsible for staging your component, that's a great candidate. It makes your life easier if you have to change it later.

Last and not least, the most important thing about a good test is not blindly following the code. Throughout that month I spent writing tests, I encountered several instances where the code was really hard to test (side effects, too tightly coupled). I could have hacked my way around those issues and got the tests working, but it would have been the wrong thing to do. A good test doesn't test bad code, it improves.

What I did was then refactor the code in question, until I got it to the point where it was no longer difficult to test. The end result was much easier to read code, and fewer lines of code in the app overall (win-win).

It's okay to have long tests, but...

This is another one for the question pile: is it okay to have tests which are long? I've seen tests upwards of thousands of lines of code and the answer is yes, but.

A large test can be a good indication the code you're testing needs to be broken up. Unless you're testing code that has many different edge cases and flows, there is a good chance your large test is alerting you to the fact the code you're testing is too tightly coupled or not broken up enough.

Sometimes a test just ends up being large because you're thoroughly testing all branches and statements, you shouldn't obsess over irrelevant metrics, but you shouldn't ignore the warning signs of code that needs to be changed.

Conclusion

Many would agree that having tests is better than no tests. There are a lot of opinions and a lot of confusion surrounding testing on the front-end. Educate yourself, but don't blindly follow the advice of one person on the subject.

Stop Interrupting Me.

Dwayne Charrington — Fri, 24 Jan 2020 01:28:03 +0000

As a front-end developer, sometimes the hardest part about my job isn't the work, it's dealing with people and the complications that come with them. Followed by the processes that surround the work, it's a lot to deal with.

When you see me with headphones on at my desk, don't come and tap me on the shoulder unless you're telling me there is a fire and the office needs to be evacuated. If you need help, send me a Slack message or email. Better yet, wait until you see me get up from my desk for a moment.

In my long career I have worked in a wide variety of different environments. The Agile/Scrum environments, open plan offices, closed plan and offices with sales teams ringing stupidly loud bells when they make a sale to the roar of applause from the office.

Distractions are everywhere, which is why all reasonable developers will eventually realise they need to own a good pair of noise cancelling headphones. The kind that could drown out the apocalypse.

So, if you see me wearing headphones don't make me take them off, I'm most likely in the middle of something important.

Don't force me to participate in stand up meetings every morning which serve absolutely no purpose other than to give status updates to micro managing bosses wanting round the clock updates, not much changes in a day.

Let me come in late and miss the peak hour traffic, let me finish later for the same reasons.

Don't expect me to respond to your emails as soon as you send them.

Don't expect me to respond to your Slack messages right away either.

For an industry that has so many tools for managing work flow from project management to communication, it's still incredibly distracting. Use the tools or don't, you can't have it both ways.

I Use For Loops Almost Always In Javascript

Dwayne Charrington — Sun, 19 Jan 2020 23:24:27 +0000

Recently, Kent C. Dodds posted about an instance where using a for loop dramatically resulted in better performance.

When you delve into how filter, map and reduce methods work (based on callbacks), really it is of no surprise to anyone who sees the results for themselves that these methods are a lot slower.

Replying to Kent's Tweet, I mentioned how I always use for loops and how their performance is unrivalled:

Really, it did not take long for the defensive Tweets from other devs on Twitter.

For loops are not just about optimisation

Yes, for loops are faster and yes, if you're not careful they can have unintended side effects as a result of not using better-suited methods like filter or reduce, but I don't use for loops with the sole purpose of optimising my code.

In most cases, you won't notice any difference in performance for small data sets. When you're dealing with tens of thousands of items like Kent was, then you definitely will.

If you are working with promises and want to use async/await then you need to use a for loop to do that as those beloved one-liner methods do not support them very well.

If you want to be able to control the flow of the loop (break out of it), then you will want to use a for loop.

While for loops will add to the size of your code and not be as "clean", we need to stop focusing on clean code and focusing on clear code. To me, nothing is more immediately clear than a for loop.

I am also not advocating against using those specific methods. I still use filter, map and reduce where applicable. In most instances, I find for loop is easier to write, even if it usually results in more code.

As front-end and Javascript developers, we need to stop pretending there is one right and true way of doing something in Javascript. Because there is not. Everyone has opinions and preferences, we need to accept that we are all different.

Level Up Your Front-end Testing Game With Wallaby.js

Dwayne Charrington — Wed, 15 Jan 2020 23:09:13 +0000

I am a huge fan of testing, but for the most part, you either have to remember to run your preferred test runner of choice in some kind of watch mode and keep an eye on any terminal output for broken tests.

If you're using Karma, it opens up a web browser and can steal away focus at times when tests re-run. Jest is great for watching tests and output the result to the console, but if you don't have it visible at all times, the console output can be missed.

Which is why I want to talk about Wallaby.js. It's a test runner which runs your tests in your IDE/code editor of choice and provides distraction-free feedback to you when tests pass or fail.

I use Visual Studio Code as my editor of choice and Wallaby runs inside of it, as well as almost every other editor you can think of. Furthermore, you get realtime inline test feedback.

As you can see, I have a passing test and a test which is broken (highlighted by the shades of red on the left-hand side).

If you were to open up the code being tested, you get code coverage indicators as well as whether or not a test is passing or failing on specific pieces of your code.

If you look at the status bar in VSCode (or whatever editor you happen to be using) you will see some useful information:

The percentage indicator there changes depending on the file you have open. Wallaby automatically checks to see how much coverage you have. In the case of the file, I have open, I have achieved 100% code coverage. To the right, you can see I have 316 passing tests and 2 failing tests (indicated by the x and checkmark).

The file in question being tested looks like this in VSCode:

The number of times I have been writing code and noticed I have inherently broken a test thanks to Wallaby have been too many to count. Wallaby pays for itself the first time you use it. If you do not have any tests, maybe it will take a bit longer to pay itself off.

If you are a fan of TDD (Test Driven Development), Wallaby is the perfect accompaniment for TDD fans as you get that realtime information (the inline coloured blocks are super helpful). Wallaby actually highlights how poor traditional test runners really are.

If at any time you get stuck, the Wallaby team are very responsive (as can be seen on their GitHub here. They respond very fast to questions/issues and always manage to resolve them (even going as far as providing you with configuration and code examples).

I've only ever had a couple of interactions with the team whilst trying to get Wallaby configured for Aurelia (a couple of years ago) and they really know their product, providing a solution fast.

The Downsides

Really, there is only one downside and honestly, it's not that big of a downside. The cost of Wallaby can be a little expensive, especially if you're a freelancer or solo developer. You have to pay for a year upfront, no monthly subscription options are available (although, the Wallaby team should consider it).

At $175 AUD per year, it might be a cost some cannot afford. Although, it only works out to be $14 AUD per month (around the cost of a Netflix subscription). If you work for a company, I highly recommend asking them to purchase you a company licence at a cost of $350 AUD.

You can also try it for free to see if it works for you as well, so you do not have to commit to an upfront purchase. When you realise how productive Wallaby makes you and how great the support is (should you need it), you realise that Wallaby isn't expensive at all.

So, You Want To Test On The Front-end?

Dwayne Charrington — Wed, 15 Jan 2020 05:28:02 +0000

Recently, I published a post titled You Should Be Writing Tests where I lightly discuss some of the important reasons for testing on the front-end.

After speaking with some people who reached out to me, it became clear to me that people want to test on the front-end, but some developers legitimately do not know the best way to do so.

And honestly, when you look at the front-end testing landscape, it is confusing AF as the cool kids say (or so I am told). Where do you even begin? What is a Jest? Is Mocha a coffee or something related to testing? Jasmine, that's the nice smelling stuff, isn't it?

I do not delve into end-to-end testing in this article. For that, I highly recommend Cypress for end-to-end testing (it only currently supports Chrome). If you want to run e2e tests in multiple browsers, then Protractor is a safe choice (just older and configuration heavy).

Test Runners

When it comes to test runners you have really two solid options for running unit tests:

Jest
Karma

Jest

Created by Facebook, Jest runs your tests in a non-browser environment. As such, it can introduce complexities when you're testing code that is using dependencies that touch the DOM or use other libraries like jQuery.

This seems to be one of the most popular options right now, and honestly, I enjoy using Jest. It's fast and Facebook does a great job maintaining it. But, you can't run tests in a real browser like Chrome or Firefox.

The upside of tests not being run in a real browser is that it is really fast. It takes just a few seconds to run 322 tests in a project I am currently working on, it would probably take a good couple of minutes running the same tests in Karma, at least one minute.

To work around the lack of real DOM, you can patch the needed features either yourself or downloading a community created plugin. Numerous libraries have their own mocks/overrides already, including support for API's such as fetch and working with dates. For libraries like Lodash, you can mock them on a needed basis.

Another reason I love Jest is that you do not need to install any testing framework like Jasmine or Mocha. Install Jest and then start writing tests, using familiar Jasmine like syntax.

And yet another reason to love Jest, it plays nicely with TypeScript without needing to do anything fancy to support it. No additional plugins or anything else required.

Karma

If you have been around for a while, especially if you have worked with AngularJS (the original Angular) then there is a good chance you have used Karma. Unlike Jest, your tests are run in real web browsers.

Karma plays nicely with front-end code. It works with any code that already currently runs in a web browser. One of its downsides is that it is configuration heavy and tests can take a lot longer to run.

Speaking from experience, Karma is starting to show its age. It has great support for different testing environments and services like Sauce Labs, but I have had to really hack my karma.conf.js file to get it working in large applications.

Also, unlike Jest, getting TypeScript to work in Karma involves using a plugin and configuring Karma to transpile your TS files before it runs them.

Conclusion

If you don't need to test in a real browser, choose Jest. If you want to test in a real browser, choose Karma.

Testing Frameworks

A testing framework is a way in which you write your tests, it comes with numerous methods for checking values inside of your tests (known as assertions). Once again, you really have two popular options you'll encounter a lot.

Jasmine
Mocha

Jasmine

This is one of the oldest testing frameworks around for Javascript. Created in 2008 (wow, 12 years old), Jasmine is a self-described "BATTERIES INCLUDED" (in all caps) testing framework. It aims to give you everything you need right out-of-the-box.

In Jasmine you get a powerful assertion library, as well as support for all of the basics like async/, await and more. It's a battle-tested testing framework that has been around for a very long time.

Mocha

Unlike Jasmine, Mocha doesn't aim to be an all-in-one batteries included solution. It comes with no assertion library, but the most commonly used one with Mocha is Chai (which supports numerous styles including Jasmine-style syntax).

Once again, unlike Jasmine, Mocha also does not come with support for test doubles (the ability to spy and mock methods and values in a test). If you work with a framework that leverages dependency injection like Angular or Aurelia, you want support for test doubles. The most commonly used option here is a library called Sinon.js.

Conclusion

Really, you cannot go wrong with either Jasmine or Mocha. Whenever I have used Karma, my preferred testing framework is Jasmine because I am lazy and hate having to manage dependencies and configure them. It doesn't mean Jasmine is the better option, but it is the easiest one.

You Should Be Writing Tests

Dwayne Charrington — Tue, 14 Jan 2020 23:20:54 +0000

In the front-end space, while many acknowledge the importance of tests, I still encounter from time-to-time developers who believe that they're not always needed.

Maybe if you are working on a small hobby project consisting of one component and one screen with no routing, validation or anything else happening, that might be somewhat true.

If you are building a serious web application, consisting of actual functionality: avoiding tests is a one-way ticket to developer hell. As a bare minimum, you should have some unit tests and ideally a few integration tests as well.

As someone who has had to clean up a sizeable amount of messes left by developers who wrote terrible code, didn't write documentation and especially didn't write tests, it makes me clench my teeth whenever someone advocates for not writing tests.

Tests are documentation

Here is the beautiful thing about tests: properly written tests are documentation. A good test is like a story, it has a beginning, middle and end. It should accurately detail how a piece of code or functionality works.

Even if the Git commits lack detail, the internal wiki or Google Drive documentation is lacking, a test will tell you everything that you need to know. It will also allow you to refactor confidently.

Tests allow you to refactor unfamiliar code

How many times have you gone to change some code, and felt like you stepped into a murder scene? Horrific code all over the place, unnecessary abstractions (or none at all) and that sinking feeling in the pit of your stomach knowing if you touch this code, the house of cards might come tumbling down.

Provided the tests you do have are covering all of the critical parts of the code, you can go ahead and refactor code (to a high level of certainty) knowing that as long as the tests pass, the code is fine. That level of safety is something that not even the best documentation in the world can provide.

Even if something does break as a result of the refactoring, the likelihood of there being serious bugs, as a result, is lessened.

You don't need 100% coverage or test everything

This is a trap many newcomers fall into when getting started with testing, I have even encountered some senior developers who think like this. Aiming for 100% code coverage is useless.

What you should be aiming for is coverage of the critical parts of your application. Prioritise what is important, not what is the biggest and most complex functionality in your application.

Ask yourself the question: what parts of the app, if they broke, would have the most severe consequences for the business? Examples include authentication (ability to sign in and signup) and the ability for customers to purchase something (enter card details and check out).

You absolutely need tests, but you don't have to test everything. Not everything is critical. But, if someone tells you that tests are not important, politely smile and walk away because they do not know what they are talking about.

PS. Inspired by this post and some people who reached out to me, I published a brief little guide to getting started with test runners and frameworks here.

11 Front-end Predictions For 2020

Dwayne Charrington — Mon, 13 Jan 2020 23:42:16 +0000

Everyone seemingly has their own idea of what the future looks like, where they see trends and technologies heading. So, I thought I would throw my hat into the ring and share some of my own predictions for 2020 and beyond in the front-end space.

My intention isn't to make anyone angry, so if anything in this prediction upsets you, just remember these predictions are personal opinions and not guaranteed to come true nor are they based on any real factual data.

The rise of anti-frameworks

This one seems to already be happening, but in 2020 developers will start moving away from frameworks and libraries, opting for anti-frameworks in the form of Svelte and other offerings which minimally abstract HTML and Javascript, compiling down to native code.

While existing frameworks and libraries will shift focus away from features and focus on competing with upstarts like Svelte by narrowing their attention to performance and size. You will see frameworks and libraries either evolve or die.

This will all tie in with all major browsers supporting Web Components, as compile-to-code options like Svelte and standards-based frameworks such as Aurelia allow developers to build web applications that compile to Web Components.

React will begin to lose popularity

Do not misconstrue a reduction in popularity with dying, this is not a death prediction. In 2020 React will continue to be the #1 contender in the front-end space and will continue to do so for the foreseeable future, it is simply too big to just die. However, 2020 will see React lose a little bit of its market share as developers flock to other offerings.

Developers often pick React because it is a safe bet right now. It has a massive ecosystem, it is easy to find developers experienced with it. But the ecosystem is so big, it can be hard to make basic decisions and more often than not, you end up glueing together your own faux-framework with numerous packages.

Whether or not the trend of developers moving away from React and other choices towards compilers and "closer to the metal" offerings continue into 2021 and beyond, nobody knows.

Vue 3 will push some developers away

Releasing a new major version of your framework or library can be fraught with danger. Look at Angular with its turbulent release of Angular 2 which fractured the community and drove developers away to other options like React.

As Vue 3 introduces the new composition API and moves away from the Vue 2 class-based API amongst other features, developers concerned with Vue seemingly stepping in the direction of React will begin to look elsewhere. Some in my circle who moved from React to Vue have been making the move back now the honeymoon period has ended for them.

It is worth acknowledging that many of the differences between v2 and v3 of Vue seem to be behind-the-scenes and the way you build applications is largely the same, there are differences and there is also confusion.

Micro front-ends will be all the rage

In 2019, the concept of micro front-ends really started heating up as the community rallied behind the concept. Much like the backend saw a similar renaissance a few years ago the concept of breaking up monolithic front-end applications into smaller apps will be all the rage in 2020.

Eventually, developers will grow tired of micro front-ends and we will see a return to monolithic applications in 2021/2022.

TypeScript will get bigger

There is just no stopping TypeScript and as we saw in 2019 which was a phenomenal year for TypeScript adoption, 2020 will be more of the same. Many large-scale open-source projects such as Aurelia and Vue are rewriting their latest major versions in TypeScript, companies are jumping on board.

All the while, some of TypeScript's loudest critics will continue to peddle their anti-TypeScript agenda, but nobody will be listening. TypeScript is a force to be reckoned with.

Web Components will start to get better and see adoption

Right now, a few high-profile front-end thought leaders love to talk smack about Web Components. While Web Components knowingly have a few technical limitations, 2020 is the year we will see work to unify the specifications and improve Web Components get underway.

As we enter 2021, Web Components will be supported in major browsers and work will have started (possibly completed) on addressing some of the biggest limitations of Web Components, as we see frameworks and libraries in the ecosystem bridge the gap.

Aurelia will gain popularity

If you haven't heard of Aurelia nor used it, Aurelia is a Javascript framework that has been around since January 2015 when it was first announced. Since then, it has been quietly chugging along with continued updates and improvements, and a smaller ecosystem.

Sadly, Aurelia was introduced at a time when some web standards were still in flux when ES2015 was not overly supported and build tools were turbulent (predating the rise of Webpack).

In early 2020, Aurelia will see its second release Aurelia 2 which is a rewrite of Aurelia 1 with the same familiar syntax, expanded feature-set and more alignment with web standards. Now that many of the standards Aurelia abides by are solidified and improved, Aurelia 2 will be poised to take advantage of these better (including first-class Web Component support).

Browsers will take more initiative

For a very long time, the onus has been on developers to ensure they're creating performant and usable experiences for their users. Sadly, even with all of the tools at our disposal, things have not really improved.

Chrome is leading the charge here, in 2019 they implemented support for a loading attribute allowing for more performant loading strategies for images and iframes.

In 2020, we will see Chrome and other browsers begin to progressively enhance web applications by offering improvements such as the loading attribute implemented by the Chrome team.

Progressive Web Applications (PWA's) hit the big time

For years talk of web applications replacing native applications has been going around. However, PWA's have always been seen as these separate siloed things with additional steps to use. Not any more. In 2020, we are going to see PWA's finally given the respect they deserve and developers opting for PWA's over native apps.

Microsoft is already leading the charge on this front, by working on implementing support for PWA's to run on startup in Windows 10. Best of all, this is a Chromium feature and will support other operating systems.

Elm will get much-deserved attention

I think Elm is one of the most underrated languages around. While the focus is on Svelte right now and how it is an amazing compiler that compiles into native Javascript and HTML, Elm which has been around since 2012 has been doing that for seven years now.

I am not saying that people don't already use Elm (because a lot of people do), you just don't hear about it all that much and I think in 2020, that is going to change.

The attention that Svelte receives in 2020 will indirectly put Elm into the spotlight. With its renowned error messaging and lack of runtime exceptions, Elm will cause some developers to fall in love as they discover this underrated gem.

WebAssembly will continue to be fringe, for now

A lot of developers I have spoken to like WebAssembly and agree that it is important for the future of the web, however, nobody knows where to start or what to do with it just yet.

If you asked me in 2018 what I thought would be the hottest technology on the front-end in 2020, I would have said WebAssembly. While a lot of work has been done and support is decent, with a few things built in it already, sadly, WebAssembly isn't quite ready for its prime time moment just yet, but we are getting close.

Until WebAssembly has a safe and performant way to perform DOM-based operations, front-end developers using WebAssembly will be in a small minority who are. Once WebAssembly can cross that bridge and in a way that doesn't introduce a performance bottleneck, it will be a front-end arms race as libraries like React implement things like Virtual DOM in WebAssembly.

You don't need to work long hours to succeed as a developer

Dwayne Charrington — Mon, 13 Jan 2020 02:20:16 +0000

On both sides of the coin, whether you are front-end or backend, some people are of the opinion in the formative years of your career, you need to burn yourself out. That to become successful in your chosen field, you need to "invest" additional hours into your job by working overtime.

As someone who did this during the early years of their career, I can tell you that even if I didn't, I truly believe I would still be where I am today. I didn't get here because I did 14 hour days, I got here because of passion and drive. I got to where I am because I chose this field, I chose to do what I am doing and it's my love for the industry that keeps me here, even when things get tough.

At times in my career, I became burned out and disillusioned in my chosen career path I love so much. Let me tell you, there is no worse feeling than waking up one day and feeling like you don't love what you do anymore. To go to bed with passion, only to wake and be filled with dread and anxiety for no apparent reason.

Well, there is a reason. People don't just stop loving what they do. Long hours and crunch affect your mental health. Even if you feel like they don't, even the strongest people will eventually burn out and it can happen without you even realising it.

For some, there are warning signs (whether you choose to listen or not), for others, the effects silently build up over time and like an explosion, they'll detonate inside of you. No symptoms, just the devastating effects of repressed constant tiredness and mental stress.

Where the divide happens in the community and those who continue to spread this dangerous advice is, not everyone burns out. Some people are wired differently, their brains are wired to seemingly weather any storm that comes their way, hardened to the harsh realities of our industry and so, these dangerous opinions continue to be spread. For every person who doesn't burn out, numerous people do.

Lack of sleep leads to exhaustion and exhaustion has disastrous consequences. Sleep boosts your immune system, without sleep your ability to fend off the cold and flu is lowered, as well as other bugs. Lack of sleep has also been linked to anxiety and depression.

Fortunately, I have always had a good support network with my wife, my family and friends. By all accounts, I should be lonely and friendless. I invested so much time early in my career, relationships suffered for it. I did lose some of my friends because I stopped making an effort, but not all of them. I can't say I blame the friends I lost contact with for giving up.

And I am not trying to be pitied here, I am one of the lucky ones. While I worked long hours for quite a few years of my career, I came out on top. In the end, it all worked out. But, what about the people it doesn't work out for? What about the people who were driven out of the industry, driven to hate the thing they once loved as I did? I am sure there are many.

Spending excessive hours "investing" in your career comes at a cost. For some, it is greater than others. I do believe that developers should invest in their skillsets, but I do not believe that working overtime for an employer is how you do that.

If you want to advance as a developer, it should be of your own free choice and on your own terms not because someone else is asking you to stay back and help get that project completed by the unrealistic deadline placed upon you and the team.

Start an open-source project, contribute to an existing one, start a blog, write and publish a book on a subject you're knowledgable on. Do something that is wholeheartedly for you and only you, not somebody else.

Or better still, once you're finished for the day, do nothing at all. It is your choice. Sit down and relax with some Netflix, read a book or get a good nights sleep. Your career and your life should be in your own hands. Don't listen to thought-leaders, gatekeepers and managers who say otherwise.

You can rest assured that if you burn yourself out and fall apart, your employer isn't going to stand around and let you pick the pieces up and watch as you put them back together.

Aurelia + Firebase = The Ultimate MVP Stack

Dwayne Charrington — Mon, 13 Jan 2020 02:03:42 +0000

When it comes to tech stacks, there are many different options to choose from. In-fact, it can be quite overwhelming picking each individual part of your eventual stack.

When it comes to the front-end, there is no shortage of options. Do you go for something well-known and used by the community like React, do you buck hype and go for Vue (aka React Lite) or do you purchase yourself a first-class ticket on the hype train and choose something like Svelte?

All of these decisions you make matter. Are you making them for the right reasons, are you choosing a specific piece of technology because it's popular or because you feel it is the right fit for the job?

For me, I made a conscious decision in 2015 when I first saw Aurelia's announcement on the homepage of Hacker News to stop blindly following trends, to start thinking for myself and to start using what I want to use, even if it is not the popular option.

Over the years I have crafted the perfect stack, a stack suited to niche side-projects as well as MVPs and even something more serious (if you invest enough time and commitment before the next idea comes along).

Aurelia and Firebase

By combining Aurelia and Firebase together, I get an immensely powerful and flexible stack.

Aurelia for the front-end
- Standards-based framework with enhanced HTML and Javascript
- Conventions based, meaning you can focus on the task at hand and spend less time configuring the framework
- Official packages for; routing, HTTP requests (via Fetch), form validation and state management
- Plays nicely with TypeScript
- Works nicely with micro-front ends
- Support for Web Components
- Dependency injection (DI) for nicely dealing with inter-app dependencies
- Powerful and extendable templating syntax
- Easily scaffold new components and resources using the Aurelia CLI
- Class-based and easy to test
- Has no Virtual DOM meaning any library can be used (including those that touch the DOM) and requires no workarounds to use them
Firebase for the backend
- Firestore for the database
- Authentication for signup, sign in (also provides easy support for oAuth authentication and numerous providers)
- Functions for the backend scripting aspect of my backend
- Storage for static files (aka Amazon S3)
- Hosting (the ability to deploy site changes via CLI)
- Easy language for writing security rules
- A managed infrastructure that doesn't require a paid consultant to configure

Using the above two options in my toolbox, I am able to get functional applications out in record time. Once you get passed the initial learning curve that all frameworks, tools and platforms have, your productivity will increase a hundredfold.

The result is a thing of simplistic beauty. I am not spending hours configuring packages for routing, form validation, writing a tonne of boilerplate logic for state management or trying to work out what packages to even install in the first place. I take what I need out of its pristine packaging and I start building almost right away.

Best of all, Aurelia doesn't have a Virtual DOM or any DOM abstraction for that matter. Instead, it has a reactive binding system. This means that you can use libraries that touch the DOM (jQuery or elsewise) and drop-in sdks like Firebase without the need for hacks and bridges to get them working. Things are plug and play.

When you don't have to write a bunch of framework/library specific configuration and boilerplate, it's amazing how productive you can be. And you don't realise how much time you spend on these things until you use something like Aurelia and then it really hits you that you could have had all of this free time a long time ago.

I am not going to win accolades for choosing Aurelia and choosing Firebase. A lot of people happily will use the popular option and that will always be the case. I truly believe if there was an MVP head-to-head battle, my stack would result in me being victorious almost every time.

What is your favourite Javascript superset and why is it TypeScript?

Dwayne Charrington — Mon, 13 Jan 2020 01:09:06 +0000

With a wide variety of options out there for writing better Javascript, TypeScript seems to have "won out" of most other options. Growing in popularity immensely in 2019, undoubtedly continuing in 2020: why do you love TypeScript?

For me, I have seen first-hand how TypeScript has made me a better developer. It catches basic mistakes (like trying to pass a number to a function that accepts a string) and combined with ESLint and TypeScript specific rules, I've become more disciplined and conscious in the code that I write.

Stop Telling People For Loops Are Bad

Dwayne Charrington — Wed, 13 Nov 2019 03:41:47 +0000

Something had to be said. From time-to-time I see a post appear that goes along the lines of, "Loops are bad, you should be using filter, map and reduce instead" - it makes me grind my teeth every time I see a post try and argue that you should be using these functional methods for looping everything.

Yes, these functional methods have a purpose and valid use. I am not arguing that you should not use them, but I am arguing against using them for everything. In many instances, if you want to write performant code, a for loop is always going to be the faster option.

The whole purpose of methods such as map, filter and reduce is preventing the mutation of what gets passed into them. In FP (functional programming) style, passing in an array into these methods will return a new collection and leave the original untouched.

In the case of map (because it seems to be the most abused and least performant) the difference can be significant in comparison to a for loop. The reason is map will create a new copy, fire off a callback on every iteration and consumes more memory. A for loop is working off of whatever you're iterating, so it has no overhead almost.

Someone has created a repository where they have done the comparison work, the results for large results of data are astounding (and not at all surprising if you know how these methods work).

In my web applications, I tend to use map, filter and reduce a lot more these days than I used to. I am mindful however that a for loop is a better option in some instances because a for loop can do things these methods cannot.

Breaking the loop

You might already know this, but a for loop can be stopped using the break keyword. If you're using a for loop to iterate over an array until you find a specific item or a certain number of iterations have run, you can stop the loop by executing break in your loop.

On the contrary, map, filter and reduce by their very nature cannot be stopped; they will iterate until they have gone over every item in your array.

Asynchronous loops

A for loop can easily be used with async/await, meaning you can pause the loop and make it wait for a promise to resolve before proceeding to the next value being iterated over.

Functional methods map, filter and reduce are turbulent when you try throwing async/await into the mix. I think you can get it to somewhat work in a reduce if you await the accumulator, but it doesn't feel right.

A for loop makes it easy, so why make things harder on yourself? And yes, async/await works with all kinds of for loop.

Are you doing this? Stop it.

async function loadValues() {
    let myValues = await getValuesFromApi();

    myValues = myValues.map(value => {
        value.total = value.price * value.quantity;
        return value;
    });
}

The number of times I have seen a map used to iterate over an array of objects, only for the result to be reassigned to the very array being mapped is too many to count. The whole point of map is to create a new copy of the array, except many people use map as a loop and reassign the result back to the original variable instead of a new one.

If you are doing this, stop it already. Just use a for loop, because that is exactly what you are doing and you are gaining no benefit from using map in this instance.

Conclusion

In many instances, you won't notice a performance hit if you use any of the aforementioned functional methods over a traditional for loop. If you're not dealing with tens or hundreds of thousands of pieces of data, you won't be able to see a 100ms difference.

Write whatever you are comfortable writing and then if you notice performance is less than ideal, you can use your browser developer tools and common sense to pinpoint which areas of your application could be optimised.

Remember: premature optimisation is the root of all evil