Senior front end dev here, ask me anything!

Hello there!

I'll be honest, I was a little resistant to Hooks to begin with. But sometimes, when you're perfectly fine and dandy with whatever you're using, it's difficult to justify moving to something new, especially when the perceived benefits of that something new don't outweigh the effort involved to do the move. I was very productive with functional components and class-based ones.

However, I've made the leap after learning a bit more and gradually introducing them and now I love them as they make things much simpler more often than not.

Have a read of Amelia Wattenberger's amazing article on them and see if it changes your mind > wattenberger.com/blog/react-hooks

Ooo straight in with the hard questions, love it!

Redux has always been a funny one for me as it seems so complex to begin with; mainly because it's a lot of overlapping terminology and takes quite a few moving parts to implement.

However, now that React has brought the concept into the core (things like useReducer()), I think there'll be a shift towards using something like that as opposed to more elaborate third-party libraries such as React-Redux.

We may even see a shift away from this centralised state into smaller, micro-states that are only shared across part of an application...

Hey Thuyet,

Good question. I think I'd expect to see a smattering of different things as they try to work out what route they want to go down. I advise my mentee's to have a few 'complete' projects that showcase some exposure to a few different technologies or approaches.

For example, I have mentee who has built a great song-finder web app. You can search for artists or songs and view lyrics and find album info. It's really good as it showcases some HTML and CSS work, but exposure to real API's, React and (most importantly) how he thinks, how he has approached the problem.

Those kinds of things work really well for me and that's what I'd like to see if I were hiring someone.

Thanks Davide.

Well, firstly, this was a bit of a happenstance opportunity that came about. I'd applied for a front end role that was purely London-based (job advert was quite vague), but the recruiter happened to have another role (the one I got) that was available and thought I'd be a good fit for.

I wasn't sure about my skill set, mainly because it's been a while since my back end days, even though I'd spent a lot of time with C# and SQL databases, etc. The main thing that gave me pause for thought was the amount of AWS involved -- something that hugely interested me, but I had no experience in.

But my advice is to always apply for a role, unless you absolutely know it's not right. For example, I have used cloud computing systems before (albeit lightly) and I knew I could learn to use AWS products. Certainly when we're talking about using an AWS SDK for something like JavaScript then, it's not easy, but it's familiar, right?!

However, if it was a C++ role, then yeah, there'd be no way I would apply for that as it's just so far out of my wheelhouse and skillset.

I think senior or more experienced devs have it easier, because, whilst not applying for entry-level things, it is easier to transfer experience and skills to related environments. I have some comprehension and physical experience with SQL, so it's easier for me to bring that back to the surface and start off more familiar in a new role that uses those skills.

For newer or junior devs, I'd have two bits of advice:

1. Apply for a role regardless of your feelings of suitability. Unless it's ridiculously beyond you (see the C++ example above), then it's up to the company to decide whether you're a fit.
2. When approaching new roles, I'd try to go the extra mile if you can. This could be making a more stand out CV, having a suitable portfolio with some 'complete' examples of what you can do, and maybe reaching out to people in the company or even doing something bold like sending in a box of goodies with your information in!

Plus, recruiters can be great if you find one that's invested in you. They'll help open doors that would be otherwise shut if you tried on your own!

Hey Anower,

Great questions. In order:

1. It depends on the role. Personally, I think companies expect too much from a single roles these days. If you need large amounts of backend and dev ops, then those are specialist (and separate) roles in themselves. However, it's useful to have some exposure to the concepts and even maybe some experience in configuring a CI/CD setup. There are a lot of venn diagrams in tech, so it's useful to be able to at least understand what the dev ops team is talking about, for example.

2. Again, it depends. For me, I think it's about experience. You've seen the same problems and solved the same challenges time and again and this allows you to cut some of the trial and error and see at least the direction you need to be headed. Sometimes, it's about knowing what absolutely won't work, rather than what will :D

3. I answered this sort of thing in one of the other answers on this page, but I'd focus on making realistic things that showcase a few different skills combined together. For example, you could make a weather tracker that automatically locates you based on your browser's location identifier, then pulls in local weather info from an API and displays it in a sexy way.
   Not particularly flashy, certainly not original, but it showcases how you think and approach problems, which is what employers are most likely looking for (or they should be!).

The holy trinity: HTML, CSS, JavaScript. Then, how to slot them together successfully. You can always learn a framework (e.g. Vue, React, Angular), but I think it's easier to pick those up with solid fundamentals.

What are you coding in at the moment as a backend dev?

Hey Deepak,

1. Practice. Simple. A good example of this is to take an existing design (say, a template on somewhere like Themeforest) and code it up from scratch. By doing it over and over, you'll get to appreciate what works and why and develop your creative 'eye' for similar patterns (e.g. navigation or card layouts).

2. It really depends what you want to do. React, whether you like it or not, is the framework of choice in modern UI development. You don't have to make that choice, but it wouldn't hurt to be familiar with its concepts and approaches, which can only expand your skillset.
   That said, it is largely just modern JavaScript with some HTML thrown in there and some React-specific concepts, so vanilla JS won't go out of style!

Weirdly (and not least of all because it's a shameless plug :D ), we talked about this on Episode 7 of my podcast about Tailwind and the general shift towards this atomic/functional/utility-driven styling.

I really like it. I didn't to begin with. I think it takes a bit of a mind-shift to adopt it and it's not the most friendly of things to pick up. Especially when you've come from the cushty world of UI frameworks with their 'button button-primary' style approach.

However, I think the atomic approach is very appealing and I'm starting to adopt it in newer projects. I think it fits very well with our modern, modular development habits.

But sometimes, it's useful to have a blend. Tailwind, for example, is quite low-level by nature, but allows for common patterns to be grouped, where necessary, into something higher-level and more akin to a familiar design system or styling framework.

But the short answer is yes, I feel that it will start to replace a lot of common approaches which often become difficult to mange and bloated.

Nadia, hello!

Node might be a good way to go. It's already in JavaScript, so it should be less of a transition and learning curve for you. You can create API's in there using things like Express JS and hook up to a data store such as Firebase or AWS Dynamo DB, without having to muddy the waters with a fully-fledged DB solution.

That said, if you want to spread your wings a little more, then Python is a popular choice, coupled with Mongo DB for storage. You could host them on a service such as Netlify for very little to free cost too!

Hope that helps :D

Good question, a combination of a few things:

• Learning via a specific course (Udemy, or a paid course from somewhere like Smashing mag).
• Doing a more formal university course or degree.
• Working very closely with a talented designers to absorb some of their expert knowledge.
• Lots of practice from initially copying existing designs and understanding why decisions were made and gradually building up your own designs from there.

Hey Parmesh,

I have a good article on this using data handlers with Redux which might be a good read for you.

But, to answer your questions, in order:

1. Use redux to manage (store, retrieve and edit) only the parts of state that don't make sense to keep locally to the component. For example, if you have a number of components that depend on the loading state of an API call to display different UI elements: this belongs in global state. Similar if you need to share parts of common data across different, unrelated components.

2. No, not everything state-related should live in redux global state. See answer one, but mainly if you have something that's local (for example, a toggle state of a button) then keep that in the component and don't involve redux

3. I'm not entirely sure I understand that one, but I would say 'no'. You might call redux actions based on the outcome of an API call, but don't call API's using redux. The redux pattern should be used to update state and that's it.

4. I think this is answered in the previous answers :)

5. Yep, check out the article link in the first part.

Ooo horror story...I don't know how 'horrific' this is, but it certainly concerned me when I started at a very large organisation as a front end dev....

We had a website. The main website of the organisation that was responsible for everything from information to sales and marketing, the whole shebang really. It had 10's of millions of visits each year, and easily had between 1-2K of active people on the site at any given time.

How was this updated, you ask?

By manually running a Gulp task on someone's local machine to build the theme files, then MANUALLY (!!) uploading any changes over plain, vanilla FTP (using Filezilla) to the webserver. No unit tests, no decent form of manual testing available (because it ran on a complex and billion year old legacy CMS monstrosity), just copied over and clicking 'yes please, overwrite these files'...

I mean, it's not as bad as Hitler, but terrifying nonetheless...

I don't know enough about Wasm (other than that's the abbreviation) to really give you a good answer there.

But, as for the future of JS, I don't think it's going anywhere anytime soon. I think there has been a lot of improvements on the language over the past few years and I think, given its popularity, we may end up seeing some of the features of TypeScript merged into the JavaScript core. Type checking and safety seem to be high on people's list of 'wants' so you never know. It wouldn't be a bad thing.

React gets a lot of hate, partly because it's Facebook, partly because it's arguably the most popular library out there, but I think the downside of it is that people use it for everything. Often it's a hammer just looking at everything like it's a nail!

However, I think there's a reason jQuery was as huge and widespread as it was: it sort of filled in the missing parts of JS and made some faffy things quite simple. I think it's similar with frameworks like Svelte and Alpine JS where they help join the dots between some things, without having to look to much larger and unnecessary solutions, such as React or Angular, etc.

I've personally used neither Svelte or Alpine, but I think they're definitely the direction front end is going: essentially gaining some of the component-driven nature of React with its templating approach, but without all the other stuff you don't need in every situation.