OK, so this is my second AMA, but it's been a while and I thought I'd try to answer any burning questions out there in Dev land.
I've been a web developer for close to 15 years, largely in front end, more recently specialising in JS and React. I've just moved jobs to become a little more fullstack, dealing with AWS and cloud engineering.
I run The Front End podcast too, and I'll be using some of the material here for an upcoming Q+A episode.
No question to big, too small, too weird or off-topic!
(PS - I'd probably avoid the 'is HTML a programming language?' one because some people will literally burst into flames...)
Top comments (107)
What is your definition of front-end developer ? There is a big discussion the last few years and people immediately assume (wrongfully in my opinion) React knowledge and no regard to knowledge of CSS and I do see it on the questions and responses of this thread. What is your take ? What would you answer to Chris Coyier question css-tricks.com/what-makes-a-good-f... ?
Great question!
In a nutshell, for me, it's about the knowledge and experience in designing and building successful, accessible user interfaces, using a variety and combination of the right tools for the right job.
However, I think people get bogged down in talking about the tools that define the term, rather than the role, i.e. what it is the front end developer needs to achieve.
We've talked in this thread about changing the term and because the tools involved in modern front end are blurring a lot, the title itself almost needs to become something like 'user-driven developer' or 'interface developer' — something beyond this idea of a 'front end'.
But think about it in terms of other jobs out in the world, like, say a plumber. A plumber deals with your waterworks and pipes, right? We don't talk about, 'oh, you have to know how to use a blow torch, or this shiny new spanner to be a plumber' do we? We talk about the processes and skills involved instead.
Development is such a broad collection of venn diagrams to me, all overlapping, and you can choose where you live in those diagrams depending on your passion, depending on your role. You absolutely can be a FE dev without touching a line of CSS, but you're likely going to be fairly niche. Similarly, you can be a successful FE developer that specialises in HTML and CSS, but with fairly little JS. It all depends on what your doing...
Great answer, I just wanted to raise some awareness especially to newcomers that one can be a front-end developer without knowing React ... but the places he/she could be employed in based on open job positions is rather limited (quite sadly, lots of open positions asking for front-end developers actually are positions for React developers)
I would call knowledge in React a specialization, but basic knowledge in CSS should be fairly standard in my opinion.
I agree. The holy trinity of CSS, HTML and JS are key, core concepts in front end.
Web API...I honestly don't know. I'm quite excited about some of the new JS features though. The optional chaining is on fire (developer.mozilla.org/en-US/docs/W...)!!
It's the little things on the front end that always prove the most fiddly and not, surprisingly, the huge complex features that people think will be hard. For example, in a recent project we had a really faffy combination of radio buttons and checkboxes. They had some tricky dependencies (like you could choose multiples of X but not Y) and the logic to remember all those choices and dependencies was mind-melting...
Recently, I've been working on a couple of things:
That's entirely up to you and how you prefer to learn. For me, I like to practice what I learn soon after by doing examples to cement the knowledge. I also write blog articles to help people (it also helps me in the future when I've forgotten what I learned!).
Partly, it's to remember that it's never quite as fast as people thing. There is the cutting edge where things progress very rapidly and it seems like they never sit still. Then there's this slower bubble in the middle (where most people live) where you're restrained to some extent by your workplace or tooling or tech stack, so it's not as rapid.
However, for me, I like to read several blogs, a lot of different opinions and techniques on places like Dev, and follow various people on twitter to keep up to date. If I come across something that piques my interest or I feel is valuable and I want a deeper dive, I'll invest in a solid book or course to learn more, with a view to implementing that knowledge as soon as possible.
Could you give advice on projects for newbies? What kind of technologies/skills you'd expect to see in a junior frontend dev's portfolio? I'm starting small, so feel like my github is a collection of trivial things. Thanks a lot.
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.
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
Sorry I got triggered by your comment Rob. DynamoDB is a fully fledged DB solution with global tables (multi region) and caching (DAX) built in. Amazon and other major corporations use it to for peta-byte scale databases. In terms of design and built for purpose for cloud it will beat MongoDB on performance without actually having to install and manage anything.
See the use cases here: aws.amazon.com/dynamodb/
It's highly recommended to use with local installs available on Docker.
Hey Rolf, no need to apologise sir and I definitely don't like the sound of triggering anyone 😬
But that's my bad, I phrased it poorly.
Of course Dynamo DB is a full solution. What I meant was, in Nadia's context of not having a lot of back end experience, something like Dynamo DB will give her some persistent storage with the hassle of setting up a full, traditional-style, relational DB. It also brings a much shallower learning curve too, especially when, as you say, there's no installation and managing of things.
Thanks for highlighting!
Hi man, your profile is quite similar to mine. How do you think about Hooks? I think it sucks, and the people love it sucks even more. Nice to know you :D
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
Thanks man, I just read the other article that you shared, and frankly, it doesn't change my mind. I am stubborn, I know, but her use of Class components is just terrible to begin with, and even if I don't know how to use it better than her, the benefit of Hooks code being shorter won't bribe me to look away from its hacky and dangerous nature. Thanks anyway. It's nice to know you
You too matey, always nice to make a connection :D
I think that's a great nature of development: what works for one, doesn't for another. And the Facebook team have explicitly said that class things aren't going away because they have literally 1000's of components that depend on them.
So the good news is that you don't have to choose!
Yeah, and then we have Preact, or Vue or stick with old versions... anything that keeps me away from Hooks. I thought Redux was worst until I saw Hooks.
Anyway, have a good day (or night). Cheers
Hi there!
As a junior FE dev, what is the main thing I need to focus on when wanting to improve and graduate to senior level.
Is it just years of service that give me that title?
Do I need to learn as many technologies as possible? (because more and more employers are expecting you to know more and more)
Is it about becoming an expert in a field you decide to specialise in?
Or is it just simply learning a new mindset of curiosity, questioning everything and finding better and better solutions, as well as adopting an attitude of transparent communication and knowledge distribution?
It's something that comes with time. And that thing is experience. It's being able to look at problems and see commonality, familiar solvable issues and knowing how to tackle them (more importantly, how not to tackle them). That 'time' isn't a fixed thing either: there are developers better than me, younger than me, with less 'time served' than me, it's about your journey and your learning.
With what you learn, that's up to you. You absolutely don't have to master everything going, but being a generalist is super useful. Being able to adapt to changing environments and be flexible is very appealing to employers and will allow you to change your direction if you wish.
However, becoming an absolute specialist in a core set of topics is also a great route and move into consultancy.
Thank you for your answer! It makes a lot of sense. I think we often get stuck on a thinking that the 'senior' title is based on one definitive thing. But that my actually keep us from being able to really learn and grow as developers. Rather we should be focusing on our journey and coding with our eyes open and questioning as much as possible.
Thank you for taking the time to answer my question!
Do you think FE and BE should be renamed? In the past years FE has morphed into something that is not anymore so clearly defined. On the one side it has become very Backendy and JS complex, but I have the feeling that a lot of FE devs who are really passionate about CSS and the actual UI/UX aspects of FE feel like they are forced to go in a more fullstack mindset. I think that largely is a good thing. But it also seems like both sides of FE are full time jobs in and of themselves. A lot of coders and programmers love getting into these complex logic problems and all these great technologies and they love fighting about Vue or React or Angular and if HTML is actually a coding language. But what about the side that is closer to design and conceptual stuff. Usability, Accessibility and all those things should not lose their priority for FE devs. I am not sure if my question is clear.... :D
No I get ya 👍🏻
It's funny, we talked about this on the latest episode of my podcast about how FE and BE are so overlapping now. I think the terms are becoming more UI-focussed and data-handling focussed. I don't have a great set of names for you but if anyone's got a better pair, then let us know 😊
But I think it's a good thing in a way. We've never had a better time to diversify our interests and follow what challenges you. When I started, you were back end or front. There was a clear divide, but it was fairly boring in some respects. Now, you can chase your passion whether it's UI, UX, JavaScript but in a backend way.
Ultimately, it's all development, it just depends whether you want to be more user-driven (UX/UI) or service-driven (API's, databases, backend stuff).
Well user-driven and service-driven is a good start for a new naming convention :D
Thank you for sharing your thoughts on this. I agree, the diversity is a great thing. Sadly I think companies could often do much better if they understood the diversity better.
I will have to check out your podcast episode where you talked about this. :)
Thank you again.
As a backend Java developer that is also doing frontend, I am really shocked how frontend toolchains works. Compared to the backends I know, everything seems to be slow, extremely resource consuming and non-deterministic. Builds have hundreds of warnings and noone seems to care as long as it’s working. I would really rewrite it if I had the time...
Do you think that there is some „good enough“ attitude In the industry and if yes, why is it, or is just me having bad luck?
Thanks!
I think there's definitely some of that yeah. But you're also dealing with a lot of balls, in a lot of airs, and a lot of jugglers all trying to keep track of them.
For example, at my last job, we've got an API developer. He's writing things in C# and also looks in on some SQL, but that's about it (not to undermine that at all, believe me, those things are more than enough!!). Then there's the front end. We've got to manage JavaScript, CSS, HTML, how they all interact and affect each other, then build tools to manage that, and libraries like React thrown into the mix, all with a healthy smattering of third-party things that we have no control over. But I do think we should take more care when developing to keep the quality and refactor as we go.
But it depends on what the warnings are too. Ideally, you should keep them to a minimum, but some are less avoidable. Plus, when it comes to JavaScript, it's so loosely defined that that doesn't help.
On a personal note, I've not found the tooling to be that slow but I might be biased because I'm front end for life 😍😍
Thanks for your reply.
I was not so much talking about code quality. This is also an issue sometimes but I absolutely agree that frontend is a whole lot more complex than I thought before. But backend also is, langue, Relational / object DBs etc, Message queuing systems,
Operations, Linux systems... I could go on.
But I was really about the tooling, the stuff that you use everyday when compiling code, running tests, seeing changes in the browser, updating dependencies, fixing issues with dependencies. This is all a lot worse than in Backend and it drives me crazy every day and wondering how anyone could have ever worked with it for years...
We have a very large application so maybe it is not so bad when dealing with smaller web apps or even just „normal“ Dynamic Web Sites.
Ahh I see. Again though, I don’t find it that bad. I use VS Code and most projects can be fired up with something like Webpack and just hot reloaded so changes are immediate, especially with CSS which is almost instantaneous.
Having come from a C# background I actually found the whole Visual Studio effort to be sluggish.
But I think you’re right, it’s all about the project and maybe just the specific tools you use at the time.
Hmm, maybe I should give VSCode a try... :)
I'm using IntelliJ for both FE and BE so that should be a fair comparison. So I can have like 6 Java projects open without an issue, but having just one UI project will run at 50-70% CPU when having Karma and WebPack dev server running... When I change one line of code in one of the Angular projects, it will recompile that first, then the test app will be rebuilt and webpack runs... I have the feeling that I spend 30% of the dev time just waiting which is really frustrating.
To be fair, I don't have the latest and greatest CPU and this is a very large project. But I could run our whole backend with 10+ Java microservices on docker on my machine but running one UI project just kills my machine.