Frontend is a separate application

Over last years there was a big leap in terms of complexity of user interfaces and its one quality in general — which is being dynamic. With applications like Facebook, Twitter or Trello people got accustomed to dynamic interfaces. While there are still lots of apps which are based on static HTML views served by the backend, there is a general shift towards rich frontends, where data is fetched in an asynchronous way, user flows are mostly contained on a one page without refreshes and the level of interactiveness is way bigger than clicking on the hyperlinks to go to the next page.

It’s nothing special. In fact, it is quite logical. You are using rich single page applications every day. Your clients are using them too — tweeting, sharing posts on their Facebook. No wonder they want the same level of interactiveness from products they will sell. Since there was a great demand and this scenario (“OMG I’m a backend developer and I’m forced to write frontend code!”) was quite popular, we’ve decided to write our best-selling book, Rails meets React.js with this particular target — backend developers forced to write frontend code, but not knowing how to do it. The best part is — most of them loved this kind of frontend work after reading the book (thanks, React!).

While having rich frontends is a valid business point of many projects nowadays, I see a disturbing effect among many developers coming more from the backend development background. The problem is: The frontend is a piece they’re developing nowadays too, but they’re not being professional at all. Lack of tests, lack of architecture, writing unmaintainable mess — those are all effects of this phenomenon. And the best part — after returning to their cozy backend work, all those professional techniques magically comes back.

I’m quite concerned about this effect. In fact, I think one of the root problems is inability to accept that frontend is a separate application. In this article I’d like to scan through two sins I usually see and try to reason about them.

Sin #1: Lack of architecture

I’m quite happy that we’re living in a world of React.js and Flux in many flavours. I’m having no doubt that there are many projects that are using Flux, because it is cool to use it — but it’s always better to work with code that is having an architecture than the one which does not have any.

And frontend applications are not simpler than backend apps nowadays. They have a clear infrastructure layer (consisting of, in most cases, code responsible for AJAX calls for fetching data and AJAX calls for pushing modified data), domain layer (which is usually vestigial at this point — but still there are some structures and some domain methods usually defined) and application layer (like routing, controllers [more in GRASP terms than in MVC terms], views…)… well, they’re no different than backend code in this matter. Some design patterns you use in your backend code have its use in the frontend code.

Still, many backend developers are still working with frontend code like it’d need no architecture at all. Maybe it’s an effect of pre-React days, where everything most people used was jQuery plugins? Or maybe it’s an effect that “frontend code is just generating HTML so fuck it”?

This sin often results in a very unhappy experience when it comes to add a feature or troubleshoot your code. That being said, **ensure your frontend code has a clear architectural pattern — it can be everything, from classical layered architecture, to CQRS/Flux or hexagonal architecture**

Sin #2: Lack of tests

Last week I had a discussion with a great friend of mine about the project he’s working on. He’s maintaining a fairly big application with a huge backend and rapidly growing frontend. An application is well tested — there are tests for every critical part of the code, and new code is committed with tests all the time. What a joy to work with such codebase! — I thought.

There was a task he’s working on and we were pairing on it. The task was about changing something in the frontend assets generation — which could’ve been a destructive operation. Since it was not that easy, I asked my friend to run frontend tests after each change he makes.

There is no sense to run those tests. There are not many of them and there’s a little value from them. In fact, they’re not testing anything reasonable.

This answer shocked me. Wait, what? So there are great programming techniques employed, an application is well tested, but frontend code tests are shitty?

Ok, I’m lying. This answer wasn’t shocked me at all. I see this pattern all the time: Great tests on the backend, no tests on the frontend.

Most developers asked why they’re not writing frontend code tests are answering that “I don’t have time to learn how to test frontends”. Sure, the programming model of JavaScript is a little more complicated with an event loop, many environments…

but it is not a reason to not test your code. There are great test frameworks and libraries nowadays like Mocha or tape that handles event loop and asynchronous test in an easy way. Environment issues are not a problem anymore with an excellent Karma test runner. Just sit and write those damn tests!

This sin often comes with the previous sin — without sensible architecture it is often hard to test an app. In such environments you should definitely use an end-to-end approach to test your code. You’ll get slow tests, but at least you’ll have a confidence of not breaking things.

What about unit testing code like React? Again, there is plenty of libraries you can use — enzyme is the one I recommend. The API is simple, the testing model — clear. It’s terrifying that due to a laziness (or an effect of false “business” reasoning — more on that later) programmer leaves its all professional techniques. JavaScript testing is not scary — and there is no reason to not test your code.

Some developers often respond that “I cut the scope of this feature by not writing frontend tests. My client don’t have a time for that”. Wait, really? Having all those wonderful techniques to explain the importance of technical quality to a client, the “technical debt” metaphor? I’m not buying it.

There is no more embarrassing thing for a programmer if a client fails miserably in selling the app because during the live demo this small button doesn’t work. All your carefully crafted backend code, thoroughly tested, waiting for a request to start its magic. Not gonna happen, the submit button broke and the programmer cut the scope on testing it.

Sure, on hardcode production apps with Honeybadger turned on there’s a chance that you’ll discover an error quite quickly and no-one will complain about it.

Well, there is a non-zero chance that a doctor who just left a surgery knife in your stomach during the surgery will realize it before stitching you up.

Keeping the doctor analogy — imagine you being the doctor and a patient is coming to you, telling you that this surgery is EXTREMELY important for him and he want you to do it RIGHT NOW. Would you just grab a knife, lean him on the table on your office and start the surgery?

Testing (and TDD especially) is a part of being professional and responsible developer, just like washing hands before surgery is a part of being professional and responsible surgeon. Since a frontend is an app, just like your backend, it is not a special snowflake — it needs to be tested, just as your carefully crafted backend code. Of course you being unprofessional programmer is (usually) not resulting in risking life of others — but risking your client money and reputation is (very!) often the case.

Summary

We’re living in a world of rich frontends. Today is a day where this must be spoken loud: frontend is a separate app. It needs to have a proper architecture and it needs to be tested. Sins I’ve just described are too often a reality — I encourage you to take a strong stand against it during code reviews you do.

Thank you for reading. As always you can tweet me. Have you experienced those sins in practice? Am I being too zealous? Don’t hesitate to drop a comment — I’m always happy to discuss with you!

In Arkency we’re maintainability freaks. We bother a lot about testing, software architectures and company culture. Be sure to check out our blog if you’re interested in those topics.