After many years working as a UX designer, I decided to transition back into frontend development. It hasn’t been an easy journey, but as many others have done before, I just got a job as a full time frontend. No mix designer mix pm mix something else, a full-on frontend engineer.
Here’s my journey, in case it helps somebody else that want to do the same and like me 2 years ago and doesn’t know where to start.
So where do I start?
Two years ago I barely knew any development. Yes I was pretty handy at html/css as I started my career as a frontend dev, but that was in 2005. The world was easier, and being good at html/css was enough to have a job coding websites. JS was an emerging force with jQuery, as finally there was a way to support all browsers (back then cross-browser compatibility was hard). Fast forward to 2019, and you won’t get far without knowing TONS of javascript.
I always thought that I wasn’t good at thinking like an engineer. Bullshit. It’s just a different way of thinking, but you learn that. To some people it may come more naturally than to others, but it should not stop you.
The main difference to me is that html and css are declarative, if you can visualise a website and you know your tags and css rules, you can paint that idea on a screen.
You’ll need to think in a different way to learn JavaScript, but you’ll get there. More on this later.
I’ve also found that some of the frontend engineers, at least at junior and mid-weight level, may be great at javascript but have some gaps when dealing with certain html/css things. So you may have an edge if you’re very good at creating layouts.
The first steps
I started adding some jQuery to my sites and prototypes, mainly so I was able to hide and show elements. This was 2018/9 and by then jQuery was already like really? But it’s not a bad place to start your journey if you ask me. Simple and may trigger your curiosity to learn how to do things properly with vanilla JS.
A colleague at that time called Tim Brooke taught me the basics of how to do a React app. Just putting some pages together without any additional functionality, simply html inside JSX. It was handy as I could import some of my company’s existing components. In our case, I was testing a new design for a FX card we were selling. Having a working FX calculator was very useful for our usability research, so Tim coded the calculator and I used it on my React prototype. It worked great as during research people thought they were dealing with a real website, we got much better insights.
But I had no clue what I was doing, and simply writing html inside a React app didn’t seem to make much sense. I was hooked again, so decided to learn more.
But wait, I know nothing of that!
I’m assuming you are comfortable writing HTML and CSS. Maybe you’ve done some very simple JS as well. As I said earlier, by the time I got back into the development world I had done a lot of html and css. Even some PHP and MySQL (I wrote my own CMS back in 2004 using Dreamweaver! Like you do, always reinventing the wheel), so had some knowledge, just didn’t know how to put it all together and move forward.
If you know nothing about coding sites I’d suggest you start by learning HTML and CSS. Forget about JS at this point.
But if you know your way around coding a site but need to get started with JS, here are 4 things that helped me a lot:
- Manipulating data types with methods
- Events
- Working the DOM
- Fetch API
Sounds like some alien words to you? Don’t worry I’ll try explain them in plain English below.
Where can I get that basic foundation?
I knew I didn’t understand JavaScript. So I got a subscription on frontendmasters.com to learn the basics. It was recommended by Tom and another one of my frontend devs. You can learn from free/cheaper sources as well, be that YouTube videos, free books, freecodecamp.org etc, but that was a great way for me to learn as I could watch those videos on my commute home (pre-pandemic world! 🙈), while I was cooking, etc.
Working with data
Those videos gave me the basics of how information is stored in JS (strings, numbers, booleans, etc.), but more importantly the idea that those data types could be used as objects and have methods. That if you have a string called name you can call the following:
name.toLowerCase()
And that’d modify the string and make it lowercase. Or split it. Or change the order or an array. Add elements to it, etc.
Suddenly it was like ok I see how this can be useful. It was mind-blowing honestly. If I could store data in variables and then manipulate them using those methods, there was a way to make those html pages interactive.
But then… how do you actually interact with the page? I had no clue! Enter events.
People interact with sites via events
All the things we normally do on sites and apps: clicking, tapping, scrolling, etc., for the browser those are Events. And you can set something called an event listener so when they happen, you can execute something.
Now I could make my site do things based on user interaction, and modify data. But how about changing the actual page?
Working with the DOM
You can imagine the DOM as an inverted tree with all the tags of your site. Start with the <html> at the top, and start creating branches. Your head, body, headers, paragraphs… they are all nodes within that big tree that is the DOM. And you can query them, modify them and create new ones.
You use things like getElementByID or querySelector to select a particular node, then change its text content, or add classes (maybe when you select something?), or remove them entirely from the page if you need to hide something.
You can also create new parts of the tree by creating fragments and then appending them to an existing node of the tree. But for that, you’re going to need some data right? That’s where the Fetch API comes in handy.
Fetching data from the internet
Up until now all my sites would deal with static content stored on my hosting. You lay that down with some tags and create a site. But how do I get new information?
To gather some new data you need to fetch it from some database on the internet. And because you’re not going to interact directly with that database, there’s something on the front of the database called the API, that allow us to have a simple communication with it.
Imagine you want to buy a pair or shoes (I mean offline, physically going to a shop). You don’t walk into the shop, go to the back store, find the correct box, put the money into the cash register and go home. That’s nuts. You don’t know how each shop is organised, it’d be chaos! That’s why we talk to people and ask them “can I get this shows in size 9?”. They tell you how much it is, you pay, etc.
Those people at the shop? They work pretty much the same way on all shops right? So you learn how to shop in one, you know how to deal with all of them. Those people are your APIs.
So if you want to get the weather at some place, you could use the Weatherbit.io API to fetch that information. Latest news? There are APIs for that too.
Suddenly you’re able to gather information from the Internet, whether that’s your own or publicly available. And using the tools I mentioned above, you can modify the DOM to change your page to display that information, maybe request new one when the user clicks something. And you my friend, are now doing frontend developer work.
Those 4 things helped me a lot get an understanding of how to deal with sites on a more dynamic way. I started working that data, modifying it so it’d do whatever I needed. It was a two way process: my design hat would think what can I do, and then my engineer hat would break it down into all the steps needed to make it happen. It’s challenging and rewarding, and a lot of fun.
I hope that gives you an idea on where to start your path, like it did for me years ago.