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.
Then the millennium passed and the world of web became a lot wilder.
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 all the helpful CSS pre-processors like Sass, Less and Stylus. Or do you prefer post-processors? As you wish!
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.
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:
- Get some information
- 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:
- Display data
- 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
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.
I will stay with examples from React world. Because I’m biased :)
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.
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.
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.
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?
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.