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 ...
For further actions, you may consider blocking this person and/or reporting abuse
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.
Hi!
I'm currently learning React and I'm seeing frameworks like "next" and "gastby". Im thinking, do I really need to learn these frameworks? Or React alone is good enough.
Would love to get your opinion on this 😊
I see this question a lot (or a variation on it), and unfortunately the answer really is 'it depends'...
If you're aiming for a role that's very React heavy, then you're going to need at least some exposure to it. Do you absolutely need to know React or Gatsby? No, not necessarily. For example (although my website uses it), I don't have much experience with Gatsby. It's a specific tool for a specific job and I've no use for it (at the moment) in my day to day work. There's nothing to stop me learning it, but if I don't use it then I know that knowledge will be lost to me.
I think hireable developers are flexible and adaptable. Having some exposure to different frameworks and toolsets will help you in the long run, but you don't necessarily have to learn absolutely everything out there, and in so much depth.
I think, ultimately, having a solid level of knowledge and experience in JavaScript will stand you in much better stead than doubling down on a particular framework. After all, even React is just JS, right? It has it's own quirks and ways of doing things, but it's all JS. It's easier to pick up a new framework (e.g. Vue) if you have a solid foundation.
Thanks for the detailed answer. Really appreciate it 😁
I think I'm just overthinking the "just in case" stuff.
Hey can you please suggest a good path in learning vanilla javascript ,we can get many materials online but after some time learning javascript is so overwhelming that i get lost .
so please suggest some good material also i am a person who is more into step by step watching videos and practicing rather than reading docs. And also give some projects ideas that could help in practice more...
Thankyou
Howdy,
Sooo, my go to list for things like this includes:
Free Code Camp is brilliant and, although it's a little more formal, you can gain certification in various web development skills, not least of all JavaScript.
Wes Bos, on the other hand, is a hugely popular online personality web developer who provides lots of free and paid courses such as you describe (like videos with real projects). He's engaging and super helpful, so definitely worth a look.
In terms of staying focussed and not getting lost, a common mistake for people seems to be spreading themselves too thin. What I mean here is consuming lots of different courses or online tutorials and it ends up getting overwhelming and confusing. Find something you like and stick with just a couple until that knowledge sinks in and you can move onto another topic or series of them.
Projects-wise, I like more 'complete' solutions that solve a problem. I find those help me to cement my knowledge when trying to get new things to stick. For JavaScript, you could try thinking of something you struggle with and building a simple solution to it that can be added to when your knowledge increases.
For example, the classic (and cliched) todo list. Or a simple calendar/appointment app. Maybe a journal/diary app, or even the music search app I mentioned in a couple of these replies somewhere in the thread. Or, a topical idea might be to build a learning tracker where you can enter your goals and learning materials to date, making notes and reflecting on where you are in your learning journey.
Ohhhh thats a great help thank you so much i have tried freecodecamp but never tried wes bos, and i would surely be working on this mentioned projects also i loved the idea of that last project a learning tracker it helps in planning and also tracks our pace as well as it also helps developing our basics
Thank you
Hey that was a great help i am gradually mastering on Vanilla javascript also i have started learning react basics and now i want to master react and react redux can you please help in suggesting good articles and some projects
PS : I want more materials on hooks rather than state components
Hi Rob, Many thanks for this thread. I have three questions.
At what extent a Front end developer should know the Backend or DevOps?
Actually, how do you define a Senior Frontend Developer? ( The first question's answer may be included here! )
Lastly, I am in this problem now actually. How do you make side projects to rank up your skills and show to your probable employees (as I am not so good at backend, showing a full functional app is bit trickier for me)?
Hey Anower,
Great questions. In order:
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.
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
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 future of Redux?
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...
Thank you for ur concise yet thorough response!!
I'm completely with u on this one. I'm quite happy it's shifting towards that direction:):).
Hi,
I struggle with CSS a lot, like a lot. How should I go learn and get comfortable with it.
Hey Ankit,
CSS is my first love. So simple; so expressive. Aces. But yes, some things can be confusing, such as the cascade and inheritance, and definitely CSS grid!
I think I'd recommend a few different things used in combination to improve and get comfortable:
Try one of the Free Code Camp certifications on responsive web design and CSS. They'll walk you through everything step by step and build on the knowledge you have
Break down the areas of CSS and identify which you struggle with most. There's bound to be some things that you're fine with and it's likely to be very specific things that are causing you the most pain. Work on those. It might be using flexbox (specific) or spacing (more broad), but by working out what you struggle with the most, you'll be able to progress more quickly by working on those aspects
Practice, practice, practice. A good way to practice CSS skills is to try and make something real. So (and I've mentioned this a few places in this topic) grab a template from somewhere like Themeforest, a finished design, and try to recreate it as best you can in just HTML + CSS. You can break down each area into blocks and sections and plan out how you're going to approach it and almost work out lots of the styling before you even touch a .css file.
Thanks. Will surely do it
Hi Man, i start learning development since almost 2 and half years coming from IT background.
i have great exposure to Javascript echo systems as well as python/Django. i did some side projects.
for the last six months i had more than 13 interviews and i failed in all of them.Most of those interviews required a test and those test were conducted on HackerRank website. i felt that those tests involving math where im suck at it, therefore i was failing.
what do you think im doing wrong ...please i need your opinion
Nothing in particular but you might also be applying for the wrong jobs. If they’re all measuring standards by abilities on HackerRank then the company is going to miss out on a lot of potential.
I’m talking with Emma Bostian about this on Mondays podcast episode (The Front End, check it out!). All about the technical interviews.
From a more practical point of view though, take the failures as opportunities to learn. It sounds like you have some good experience behind you but if you’re having trouble around algorithmic tests, that’s something to work on. If you’ve not come from a CS background (I haven’t either), then you can miss out on those sorts of areas of knowledge.
Take some practice tests, find out what gaps you have and learn learn learn. Take the tests again and measure how you’ve improved. ☺️👍🏻
You got this!
Thanks a lot
Hey Rob,
Thank you for this AMA. I have the following questions:
I am a full stack developer who although can code your front end app and handle all the behaviours, I often find myself struggling to make the UI look more appealing. What would you suggest I do or things I can read up on to come up with better designs.
I am a strong proponent for separation of concerns. One of the reasons why Angular appeals a lot to me and to an extent Vue as well. Nevertheless, I see companies increasingly switch to react or mention that they want developers with React experience. Should I pick up react or continue on my path of vanilla JS with a dash of Angular/Vue when a framework is required?
Hey Deepak,
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).
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!
I'm a backend developer with 3 years of experience. I want to move on to frontend development ... what should I know?
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?
I'm currently working with php + symphony but in the past I have worked a lot with node js ... so I know js well enough.
I've always been a very creative person ... I love composing music and drawing. the idea of designing an ui has always attracted me. are there other tools you need to know? for example those related to the creation of a mockup or adobe stuff?
I think there's definitely a lot to be said for learning some complimentary skills, such as UI/UX design. Wireframing is valuable too, so check out something like Balsamiq, or Moqups (highly recommended), and Sketch (although that's a bit more design-y than pure wireframing).
A good tool to practice your front end skills is to take a theme design from something like Themeforest and try to recreate it yourself. It'll give you a good idea of the layout of a design and how to sharpen your creative eye for where things don't look quite right.
Photoshop skills can be useful, but it really depends on what you're doing. For example, I can chop graphics up and create clipping masks, but nothing fancy. I'm not a designer, and I shouldn't be. But it's useful to work in overlap sometimes and understand each other's language.
I've been studying the front-end developer universe for 14 months, right now I'm learning and practicing React, Hooks, Redux, Firebase, Styled Components ...
I want a job as a junior front-end developer, here is my website where I focus my projects: ebradeveloper.netlify.app/ what advice would you give me to get a job in the market? So far I've only worked as a freelancer!
Firstly, if you're into puns then you're missing a trick by not using 'Ebra-cadabra' — you're welcome!
But seriously, it looks like you have a lot to offer and some great experience under your belt. I'd start building up your linked in network, reaching out to recruiters. They're a vital (if sometimes necessary evil) in the market place and they're especially useful to help less experienced or junior developers get foots in doors of places that might otherwise be closed.
Work on a succinct CV that highlights what you're about and your achievements, rather than just a list of 'worked with technology x' or 'built thing with React'. And then you can also try to approach companies directly, especially if they're smaller, you may have more luck with responses.
Hey, thanks for the opportunity!
Do you think Stack Overflow contributions(answering questions) matter as much as side projects from an experienced dev/employer perspective?
I personally follow this approach if I really want to learn a tool/tech: explore & understand its source code and answer questions on SO. I find many benefits in doing that
Hey Andrei,
I can honestly say it has never ever been an issue for me, or any other developer I know. I think it's super helpful and a valuable experience so I would certainly not discourage answering questions on SO; as you said, it's a great experience and lots of benefits.
For things for potential employer to look at, I think things like blogs, videos, podcasts, and other content are what you can point them to as a measure of your level of understanding and experience.
Hi Rob, you mentioned in your descriptions that you just moved to another job to become a full-stack dev, so I guess this means that you got the job not having all the requirements for that role?
How would you suggest to approach a new role when you don't have all the skills required but want to have a chance to learn new things? Usually, this kind of situation is a classic for a junior dev but how does it work for seniors? Do they apply for entry-level too?
Congratulations on your new job!! :)
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:
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!
Hi Rob,
I’m a junior dev, currently mostly working on backend things. At work we have a legacy API written in PHP. I’d like to rewrite that in Node. I’m lacking the conceptual, and structural knowledge to be efficient. I’ve read about the mvc model but I’m not sure how to implement it and where to start. Would you have any advice on that? Maybe a resource, book to read ? Thanks and take care!
Thomas
Ooo now that's a tough one. So, in essence, the MVC model is Model, View, Controller, where 'Model' is the data model or shape of the object that the 'Controller' (which usually accepts some sort of input or otherwise processes a request) provides to the 'View'.
In terms of structural stuff, I'd look to start small, with one aspect of the API and break it down into the component parts. So, what should the controller do when we hit something like '/users'? Then, if it should return a list of users, what should the data model of a 'user' look like? Take that approach and build on it. Starting is the hardest part, sometimes because the task seems enormous, partly because we want it perfect from the start.
Don't be afraid to ask for help internally for advice on that too. Ideally, you should have some senior devs who will be willing to help guide you and share their knowledge, especially if they've got working knowledge of the API you're dealing with too 😄
There's also a good article on Sitepoint that walks through building an MVC-based Node app that might give you some direction.
In react where should i use redux.
Should i store all states in redux?
Should i call all apis in redux?
What data should i put in redux?
currently in my company we do all type of api calling in redux. Sometime it cause issue like because it's UI is connected with store. it shows previous data first and after few sec. it shows new data.
Do you have any repo where i can see good coding structure?
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:
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.
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
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.
I think this is answered in the previous answers :)
Yep, check out the article link in the first part.
Your thoughts on Atomic CSS approach? Do you believe in it's future potential and the chances of it to become the main way we write styles?
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.
Exactly what I was thinking! Thanks for approving from experienced dev!
sir , please become my teacher cus i want a mentor like you ♥️♥️♥️♥️
Check out Guru.com or CodingCoach.io and you'll find a mentor that is a perfect fit ☺️
Hello, what do you think about the future of Javascript? Will Svelte take place of React? Will WebAssembly make a huge difference in Front-end?
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.
Great answer, thank you very much!
Hello
I'm a beginner in front end web development
What's a best piece of advice you would give to me
Hey Shivanand,
I think the best advice is to start small and build up. Play to your strengths and how you like to learn and don't overwhelm yourself.
I see too many new developers become desperate to learn every single thing out there; they do a million courses and videos, and they're simultaneously trying to master HTML, CSS, JS and then bounce straight into Vue, React, and start slapping back end things in there and databases.
Focus on the basics: HTML, CSS, JavaScript. Find one or maybe two different courses that you like and stick with them.
I always recommend Free Code Camp to people because it's free, it's well structured and you'll get a well-recognised certification at the end of it.
Oh, and like any skill, you have to practice! If you're learning about HTML forms, build a couple outside of the lesson and see how you can adapt them. If you're learning about Promises in JS, try building a few different mini-apps that use them.
Hey..
Thanks very much for such an amazing answer ❤️
Hi Bob,
What do you think about all of these libs for react state management and what do you prefer? If we can make our own state management with Context APi, when and why shoud we use others libreries?
Hey Christian,
I've used the React Redux Toolkit extensively and it's amazing. It takes a lot of the hassle and some of the complexity of redux out. But you're correct, if I was starting a new project, I'd use the inbuilt React tools such as the useReducer Hook and the Context API like you said.
This does have drawbacks, however, such as unnecessary re-renders. You can mitigate this using a small helper library like React Tracked.
Thanks for this post!
What advice would you give to a teen who's looking for more work / internship experience, and how would you approach learning backend technologies?
Hey Kewbish,
Huge kudos to you for getting into development and putting yourself out there for more experience. It's really about reaching out to companies, finding some people on twitter, putting yourself in front of as many faces as you can.
You might also start locally. Have a look at development houses or agencies in your area as they will be more likely to have you in as an intern or work experience.
Finally, you could look at contributing to some open source projects as that's a great way to increase your reputation.
With learning backend stuff, take a look at Udemy, or Free Code Camp as they offer courses on Python (for free!). 👍🏻
Popular backend languages these days seem to be Python, Ruby and Go. Usually linked up with Mongo DB for the database side of things. If you're more interested in the Microsoft side of things, then they have a ton of helpful tutorials and starter projects for getting into C# and .Net, which is well established and has a great community.
Thanks for your advice - definitely looking into reaching out to startups and businesses in my area :)
How you structure your project in folders/files ? Abd if your project grows in complexity how do you ensure reduce coupling between your modules ?
If you use react what stack you are going to chose to scale your application (mobx, redux, react-router, reach-router ...)?
Do you use event emitter to reduce your application complexity and module dependency?
Do you recommend using css-in-js .. which library do you recommend?
And thank you very much for this post ^^
That’s a lot to take in so let me fire some quick answers at cha:
Structure wise, I don’t overthink it. Just get started, you can always change it. I like to keep various assets together, styles in their own folder, and separate out by areas of responsibility. So I have a helpers folder, constants, components and dat handling.
For complex react projects, I lean on react router, and the redux toolkit for state management.
I’m familiar with the event emitter pattern and have used it in the past. But I’ve not found too much place for it in React projects I’ve been a part of, especially with Redux. I do, however, like to introduce data handlers as middle men that handle interaction between the API and Redux. This reduces complexity in my controlling components.
I don’t like css-in-is. It muddies the waters for me; maybe I’m too old school. However, that shouldn’t stop anyone from trying it and seeing if it’s a fit for them. I hear good things about Styled Components (for React)
Can you tell me good articles on linking react frontend with backend..like by using axios. And please give some advice on this topic
I think the Axios docs themselves are pretty good for this. But I have an article on using Redux with a data handler mechanism which is pretty useful and you can always strip out the Redux part. Here's the article (there's also a part one).
Advice-wise, I'd really look to implement whatever you like to handle API's. I like Axios as it covers some backward compatibility with frustrating browsers like IE11. However, I'd definitely look to abstract any API handling into a separate utility class or set of them. It'll clean up your component code nicely :D
Do you even write dirty code only to finish small projects faster ?
Lol, I try not to. As a general rule I don't believe in hacking things together in a sloppy way or 'quick and dirty' as it just sets you (or colleagues) up for more problems down the line. You do have to make some compromises sometimes in order to meet deadlines, but you shouldn't compromise on quality as it's only putting off a nightmare in the future.
2020 must know technology for front end devs? ( :
Hi there, great question!
I think some important learning points on my list would be:
I mean, these are relatively standard, baseline things in some respects, but it depends a lot on people's role. CSS animations and SVG manipulation is really hot too, but I have little use for it in my role.
What do you think differentiates a junior, mid level and senior dev?
It’s not always clear cut but I would say a junior is someone at the start of their career. They have less experience. It’s not all about knowledge, but they may have less overall experience in a number of areas and are just starting out. They need more guidance and mentoring.
Mid-level is your average developer. They’re comfortable in their role and can function more autonomously but don’t have more managerial or team leading responsibilities and perhaps don’t have any decision making power.
Seniors I would say are more experienced developers with some leadership duties and decision making power.
They’re just titles at the end of the day and there is overlap of course that blurs the lines a little.
What is your Front End horror story?
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...
How do I learn to make UX/UI Designs?
Good question, a combination of a few things:
As a front-end developer, can you do mockup and UX/UI design? I want this to be clarify because some of front-end developer I know think that it's not their job.
I think it's important to know the boundaries and limitations of the scope of your role, but I think the design and development worlds are a series of large Venn Diagrams where there are a lot of overlaps depending on where you sit within your role.
But either way, I think it's useful to have at least some level of knowledge and understanding of UX, UI design, and wireframing/mockups, both the tools involved and the processes.
At the end of the day, design, UX/UI work and mockups/wireframes are all different means of communicating ideas. The more understanding you have, the easier you'll be able to communicate with your team, your users, etc.
How do you feel in the theme cleancode vs modern structures (like react)? How do you organize your code to make less spaghetti code?
I've given a pretty comprehensive structure answer in one of the other threads on here, so check that out 😊👍🏻
But generally, it's about not writing more than you have to and sticking to DRY (Don't Repeat Yourself) and KISS (Keep It Simple Stupid) as much as possible. Components and utilities should have single responsibilities and break longer components into smaller, reusable ones. I also like to abstract as much as possible to avoid needless repetition.
React + Data Visualisation tips. Do I need to learn D3 or 3rd party libraries are enough?
If I want to work with choropleth map things, what is the best way?
I’m going to hold my hands up here and admit I don’t have enough experience to recommend anything here. D3 is super popular and probably for a reason.
But, happy to open the floor here if anyone can help answer this for you?
How do you manage CSS in large projects with multiple frontend developers working on the same project? Do you have rulesets or standards to follow? And do you make it maintainable and scalable?
It depends on the project and how it’s structured and things like are you using approaches like css-in-js or utility css.
But, in general, for larger teams with large, complex projects, I think you want a few things in place:
In terms of scale ability, I think that’s where utility-driven css (e.g. Tailwind) is quite helpful. But really, keeping things as simple as possible means you don’t end up in a styles soup where you’re fighting specificity and the cascade
Could you share your view about what define a senior in front end development?
Without trying to shirk the answer, I’ve answered that kind of question a few times in the thread.
Have a read through and you’ll find it ☺️ But it comes down to experience and leadership duties for me.
How did you transition to become more full stack? And what backend technologies are you involved with?
I actually started full stack. I was a C# dev and made e-commerce sites in asp.net 2.0 with good ok’ MS SQL Server.
I’ll be moving back to a full stack role shortly where it’ll still be very JavaScript heavy but with React on the front, Node, and all the goodness AWS has to offer ☺️
Is it worth learning DS and Algo for front-end dev?
Emma Bostian and I are talking about this very thing on Monday’s The Front End podcast (thefeontendpodcast.site).
It’s not absolutely necessary, no. However, it depends on what you’re doing and the company you’re working for (or want to work for). There are lots of top devs who don’t come from a CS background and don’t have that knowledge of data structures and algorithms.
That said, you can always learn the basics or gain a little exposure via something like Free Code Camp.
How to the senior FE dev using CSS, they'll set exactly pixel or using percentage