Web Developer’s Fatigue

Compassion with professionals and encourage beginners.

Luke Hall
Luke Hall
Sep 17, 2018 · 14 min read

Being a front web developer is a blessing nowadays. You have all the tools and frameworks on the tip of your fingers for free as open-source.

Just go and build an awesome app in few moments!

Being a web developer is a curse nowadays. You have to know how to use all the latest tools and frameworks that are emerging every day.

Just go and get lost in this jungle with your brain burned out!

That’s how I feel today as a developer of web and mobile applications. Little schizophrenic feelings…

Sometimes it’s really fun to explore and search for the new, better and more effective ways of making useful apps and bringing real value to users.

But more and more often I’m also facing issues while starting a new web project or maintaining an existing one. Because things changes so frequently, that I can’t keep up.

Why the hack this package changed the API again? Why that library stopped working with this version of Webpack? What version of X do I need to be compatible with Y? Why am I suddenly getting all these warnings in the console? What do I need to do for this tool to work with symlinks? Why this feature is not documented anywhere? Why that package suddenly disappeared from NPM registry?

Why, why, why…

And how do you feel about it? Do you still want to be a web developer these days or you already gave up? Let’s see…

Little excursion to the history of web.

The famous nineties were the years when all the core languages of web platform were created.

  • 1990: HTML was developed by Tim Berners-Lee in CERN. This language was simple to use and became universal language for emerging web platform.
  • 1994: CSS was proposed as styling language by Håkon Wium Lie, again in CERN. Because having just plain HTML documents is ugly.
  • 1995: JavaScript was created by Brendan Eich. Because having just a static web pages is boring.

Then the millennium passed and the world of web became a lot wilder.

  • 2006: jQuery and similar libraries were developed on top of the JavaScript. Because you can write less, do more.
  • 2010: Knockout, Backbone, AngularJS and other JavaScript frameworks were created. Because jQuery wasn’t good enough.
  • 2011–2018: Ember, React, Angular, Vue and dozens of other JavaScript framework and few quadrillions of NPM packages were developed. At lease one new NPM package was released during writing of this paragraph. Why? Because simple websites evolved into complex web applications.
NPM registry

Do you see the exponential growth? Are we gonna have more JavaScript packages then atoms in visible universe soon? Fortunately you can’t fit an NPM packages into one atom, so we are safe (for now).

Would be working as a web developer require to study similar amount of information as being a doctor or interstellar rocket builder in future? I don’t think so. But it starts to be tough.

And we are talking just about front development now, leaving backend aside.

From web to app

The truth is that we don’t write web pages anymore. We develop complex applications, not only for web, but also for mobile and desktop platforms.

Setting up all the tools like Git, NPM, Webpack, Babel, linting, unit tests and other stuff requires a lot of time, energy and knowledge or at least googling.

And don’t forget that there is not only JavaScript anymore? We have a cool JSX syntax, you can write in TypeScript or WhatEverScript you want.

And all the helpful CSS pre-processors like Sass, Less and Stylus. Or do you prefer post-processors? As you wish!

Not to say that you need to know how to combine these transpilers, pre-processors and build tools together with all their dependencies matching correct versions and so on. You can be fed up pretty soon. You probably heard about JavaScript fatigue.

It was already a topic two years ago, but I would say it’s even more general today:

Web developer’s fatigue.

Somebody comes and says: “Hey, there was a new cool framework released today. It does this and that and it has cool syntax, how could I live without it!? It’s still alpha but quite stable most of the time, let’s pack it our project straightaway!”

Well… if you are masochist, just do it. But if you want to be productive or even if you have some colleagues to cooperate with, let’s discuss all the news first. Not everyone could be so excited. And not everyone is willing to spend few days on adopting new library instead of being productive using well-known dev tools.

Do you really need to watch latest and coolest libraries every day and staff it into your projects? Of course not! And if you are doing so, I suggest you to stop it as soon as possible. Because it’s counterproductive!

Remember that there is no single person in this planet, that would perfectly know all of the corners of the web development world.

Every time you start a new project, you have to make important decisions what is good idea to include and what is not.

Be professional

I’m not saying you should stop learning and stuck with your current knowledge for the rest of your life. On the contrary. It’s always good to have an inspiration and see what others are up to and in which direction the web technology is evolving.

But instead of constant exploration of all the new things, better invest more energy into becoming professional in the stuff you are happy with and you have been already using for some time. There is always a lot to improve.

Be professional — in your small corner of universe. Choose your dev stack and learn every aspects of it.

If you try to know everything, you will end up with poor knowledge of everything.

Before adopting any new tool or library, wait for a few months (or maybe years). Only time will show you, if it’s worth to invest precious time and energy into it.

If it’s still out there after a year, more and more people are adopting it, and if there are dozens of articles on Medium about it, it’s probably worth trying it in your next project.

Take React vs Angular as an example. Everyone was exited about both, but the time has shown that the first version of Angular was dead end. Angular 2 is basically different framework. Knowledge of version 1 is useless now.

I spend few weeks with Angular 1 back then and went through many tutorials. Nevertheless I adopted React as my primary framework in the end.

I heard a lot about Vue. Everybody’s talking about it. Maybe I could check some examples when I have some time. But for now I don’t care. I’m happy with React. When the React won’t be sufficient for me, I will consider switching to something else.

A you know what? I’m still discovering new ways of developing in React even after those years. I’m still learning how to make more effective, more reusable components that are simple to use.

Make things simple, make it fun.

You aren’t building rocket for interstellar traveling. Don’t get confused! No matter how large app you are building, no matter how many features it contains, it’s still the web app.

I will tell you a little secret, but don’t tell anyone!

There are only two reasons why users browse you web or app:

  1. Get some information
  2. Achieve some goal

They want to check latest news, find bus schedule, buy new phone or chat with friends.

From developer’s perspective it’s just:

  1. Display data
  2. Respond to events

Events can be triggered by user (click, drag, submit…) or by browser (resource loaded, network connection established, geo position found…).

No matter how the design of user interface looks like, all web sites and web apps that were ever created do only those two simple tasks. Display data and respond to events.

That’s it! Well maybe I’m simplifying too much here, but my point is that while you are building new website or mobile app, you should keep in mind with every key you press and every semicolon you type, why are you doing all of this — to show your users some information in the most suitable way.

Even if the app has dozens of features and hundreds of possible data states, it doesn’t have to be hard to develop or maintain — but only in case the architecture of the app is designed properly.

Every developer tends to overcomplicate things while his knowledge and experience grows. It’s natural and it’s challenging to face it. Use your knowledge to make things as simple as possible. Don’t allow your brain to find the most complicated or coolest solutions. Perhaps you will amaze your colleagues, you may feel like a hero, but your app will be a crap.

If your code is getting too complicated, you are most probably thinking in wrong direction.

One of the biggest satisfactions from my work is when I find the most simple and yet effective solution for given task.

Many times I found myself implementing an algorithm on hundreds of lines, because I was thinking too much. Then I looked at the same issue from completely different or wider perspective. And the final solution was one line of code. That’s the true victory and real programmer’s satisfaction.

“The main thing is to keep the main thing the main thing”
— Stephen Covey

Keep things as simple as possible.

Reuse what you can

I’m perceiving every web app as a collection of small lego pieces. Each piece is an independent unit with single responsibility. It can perform single task on its own. But when you join multiple pieces together, their synergy produces a multifunctional organism with complex features and capabilities.

If you have few years of developer experience, you probably noticed some repetitive patterns. If you didn’t… well, maybe it’s time to think about your life and your career :)

Fetching data. The way how you display images. Processing of the forms. Dragging and dropping. Spacing between blocks. Animations. Ellipses after shortened paragraph. Icons. Navigation. Toggling of some content. Positioning. And so on…

Nowadays, everybody is talking about components. I say you should create reusable components. Or better reusable components with single responsibility. Or the best of the best:

Pure functional components with single responsibility.

No matter how many times you pass the same parameters into component or whatever current state of your app is, you will always get the same result. No side effects.

Such a component does the only one thing, but is damn good at it. This is really important for reusability, testing, less bugs and less headaches.

Abstraction is your friend

Recently I started building my dream-library of reusable components. Standalone article about my components library will surly follow soon, so stay tuned. Now just few notes…

Every time I’m creating a new component that is not in library yet, I will use abstraction to make it as general as possible and add it there. It doesn’t need to be big thing. Important is, that it’s some pattern that repeats very often. Or at lease more then once.

Take spacing as an example. Every developer is dealing with it all the time. You need to add 10 pixels above and 10 pixels below. Or 15 pixels above and 20 pixels below. Or 8 pixels to left and 3 pixels to the right. Doesn’t matter. The core issue here is that you need to add some spacing.

Forget about adding new line of CSS every time you need it. Create general configurable component for it. Create it only once and then just use it with pixels passed as the parameter. And use it not only in your current project. But in any future project.

Or toggling as another example. You need to toggle the menu. You want to expand or collapse some block of text. You would like to display tooltip when you hover over the link. Or switch between two states of some component. Do you see the pattern? The “Toggle” component or whatever you call it. Create simple general functional component for this. Add it to your components library and use easily every time you need to turn something on or off.

You can write even higher-order components (HOC) or function. They are components that return different component or function. They are super-powerful in terms of reusability and abstraction. Anyway, they might be a little difficult to reason about, so you can avoid them if you prefer less mind-challenging solutions.

Platform-independent components

I will stay with examples from React world. Because I’m biased :)

I bet you already heard about React Native. If you are React developer and want to provide native experience to your customers on mobile devices, JavaScript will help you also with this task.

Yes. The same JavaScript code that runs in browser, can be used also in native mobile applications. The same app for Android, iOS and for web. Even for desktop if you want. For example Skype is written like that, so it’s definitely possible even for more complex apps. Write once, use everywhere.

You don’t even need to know different languages for server side of you app. JavaScript became universal language thanks to node.js. But it’s another story…

Performance matters

The less third-party packages you pack into your app, the less size of the released bundle will have. And it’s also very important.

I remember situation when one of my colleagues added moment.js into our dev stack. It’s library for easier date and time manipulation. We found out after release that more then 1 MB of translations files for almost any existing language were included into build. And we needed just English. What a shame.

Always check the size of third-party packages before you add them into your package.json. Tree-shaking might be happy to help. And try to keep size of the resulting build files under reasonable limit. Always ask yourself if you couldn’t write your own small code for given problem.

Or take a look into you components library, if you already haven’t written it before. The more repetitive patterns you transform into reusable components and functions, the less code you push into user browsers.

Performance topic would be for standalone article. Actually Addy Osmani wrote a good one already.

In case you need to create simple page displaying data in the table of few rows with some basic user interactions, consider if it makes sense to setup all the Babel, Webpack, Less and React stuff. What if writing small script in plain old ES5 JavaScript will result in the same functionality? The only difference will be 5 kilobytes instead of 50. Or 500. And that really matters.

One repo to rule them all

If you are working on one small project only, you can skip this part.

But if you are working on a bigger project, you probably have some unit tests setup, lint configuration or library of components mentioned above. It could be a good idea to store all these tools together with your project as standalone packages in one monorepo. Benefits will become obvious soon.

Are you working in larger team on multiple projects? Then the monorepo is almost a must. I have a good experience with Lerna but there are already more options to choose from.

Less commits, less branching, easier maintenance, increase of productivity. If you decide to add new project later, you have everything prepared.

Few tips for beginners

If you don’t want to study Babel and Webpack documentation, you can start straight away with create-react-app — in case of React. Or create-react-native-app in case of React Native. If you have different favourite framework like Angular or Vue, I’m sure you will find alternative start-up package.

If you need also server-side rendering, you can start with next.js. Everything is setup for you. All you need to do is “npm install” command.

After your needs grow, you can dive into documentation anytime. Professionals usually want to have a configuration under control, but before you type “npm run eject”, first ask yourself if the default setup isn’t enough.

Great help for your library of component is react-styleguidist. It enables you to create living style guide with live-editable examples.

Regarding CSS, decide carefully if you really need all the mixins and functions and other stuff from the preprocessors.

When I discovered Styled components, I was exited. It saves me a lot of time (no extra Babel or Webpack configuration is needed) and makes me more productive. If you are horrified of embedding CSS into JS, let’s take a look at JSX. When you first saw HTML in JS, you probably thought someone is insane. Now many developers are using it on daily basis.

Separation of concerns is still valid concept today but in different perspective. The way how we develop web apps changed significantly. Having CSS as part of the component is reasonable and clever.

It wasn’t easy for me to accept this idea either. Change of mindset isn’t easy process. But I found having both CSS and HTML written in JavaScript as a great improvement in the end. CSS, HTML a JavaScript are still separated — not globally, but per component.

If you still prefer having CSS in separate files, feel free to use Sass, Less or Stylus.

You always have to make compromises and tough decisions according to needs of your current project.

Conclusion

In addition to my job I started working on a few smaller projects for charity purposes recently. Because I would like to utilise my professional experience for projects that makes deeper sense then just making money.

And because I have also some personal life (yes, even such a creature exists — programmer with personal life), the time is very limited. My family is most important for me. And it’s essential to keep the first things first to live a quality and happy life.

So I’m very eager to make my day-to-day work more simple and pleasant. I don’t want to come home with my mind completely overwhelmed with not-so-important stuff.

Web development became hard and easy at the same time. Depends how wisely you set up your dev environment, which tools you decide to use and what you are focused on.

So, do you still want to be a web developer nowadays?

It doesn’t look so bad in the end. It’s still just those three simple languages that all web browsers understand. HTML, CSS, and JavaScript.

Nothing more, nothing less.

To be continued… <Simply />

I’m new to the world of Medium writers but I would like to share my thoughts and tips every now and then. Anyway I’m not sure if anyone will be willing to read my gibberish :)

In case you are interested, I created new Medium publication called:

If it’s going to turn into community of enthusiastic developers, it’s just up to you — readers.

Let’s make web development more simple, enjoyable and productive again.

I will publish all my upcoming articles here and will be really pleased if you follow me and provide any feedback, ideas or suggestion.

In my next articles, we will take a look at the core tools I use for development. Also I would like to show you how to build your library of reusable, platform-independent and simple-to-use components. And generally how to make your life of a web developer easier. Just stay in touch and see you soon.

<Simply />

Web Development Simply, Funny and Efficiently.

Luke Hall

Written by

Luke Hall

Senior JavaScript Developer • Keep things simple • medium.com/simply

<Simply />

Web Development Simply, Funny and Efficiently.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade