I am currently looking for a new job. One thing that keeps happening is that people get my CV, are impressed but then ask me that I seem to be focu...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
Ironically I had multiple occurrences of backend devs more or less just slapping a REST interface on top of the database (hey, newsflash, there are databases that can do that for you already) and let "the frontend figure it out".
Like which? Are you thinking about GraphQL here?
Great read
I believe you can't be considered a good frontend developer if you didn't have experience with the backend development. I'm not saying that has to be experience with writing code, but understanding of various high level concepts is needed. Let's face it, most work where frontend developer is needed is building application interfaces. A developer who doesn't understand relational databases, orm, erd, web protocols, network requests, etc. wouldn't be able to debug his own code. You need the experience so you're not a weight holding back your team and to build interfaces on a solid foundation.
That's just my opinion, I don't disagree with your points.
Well, I'd argue the opposite would be more important. Backend devs need to understand the frontend. The backend API should be built with the frontend (and the user) in mind, and not the other way round. If I have to care about the backend architecture while building the frontend, the backend probably messed up.
I wouldn't argue one is more important than the other one, it's not mutually exclusive. Backend developer should understand how frontend works as well. Though well built and documented API isn't concerned if the consumer is browser or not.
Can you enlighten me how that relates to the frontend? I mean, sure, REST basics and being able to use the Network tool in the browser is a mist, but orm, erd, databases?
Yeah, enlighten a messiah so he can tell me I'm wrong ? Sure, let me give it a try.
Understanding ORM, ERD, and relational databases concepts can be beneficial for frontend developers:
Efficient Collaboration: A frontend developer who understands ORM, ERD, and relational databases can communicate effectively with backend developers.
Seamless Integration: With knowledge of relational databases and ERD, frontend developers can design their application's UI to seamlessly integrate with the backend. They can ensure that UI components align with the schema and properly display and interact with the data. ERDs act as a common language for communication between frontend developers, backend developers, and database administrators. They provide a clear overview of the database structure, facilitating collaboration and ensuring everyone involved understands the data model.
Object-Oriented Approach: With ORM understanding, database tables and records can be mapped to object-oriented models and classes. This enables developers to work with data in a familiar object-oriented manner, making it easier to manipulate and use data in frontend applications. This helps ensure the integrity of data in the database, reducing the chance of errors or inconsistencies in the frontend application.
Data Modeling: ERD helps in visualizing the relationships between different entities in a system. By grasping this concept, frontend developers can actively participate in the data modeling process. They can contribute to defining relationships, constraints, and data types, leading to a well-structured and efficient design. This understanding helps frontend developers design API requests and handle the responses efficiently, ensuring they can retrieve the required data without making excessive requests or fetching unnecessary data.
Debugging and Troubleshooting: When frontend developers encounter issues related to data retrieval or manipulation, having a good understanding of relational databases allows them to diagnose and troubleshoot problems more effectively.
Scalability and Performance: By understanding how ORM interacts with the underlying database, frontend developers can make informed decisions when it comes to application scalability and performance. They can design UI components and API requests that align with retreival of data efficiently, ultimately improving the performance of the application.
Now you can tell me why I'm wrong and how writing pretty and semantic HTML is all that the frontend developer needs to know.
All these are for sure beneficial, but to me more the job of the development lead rather than the individual developers. So, you are right, but you'll need a frontend dev with a lot of time on their hands to also deep dive on that. Where you are absolutely correct is that knowledge sharing amongst the teams especially how their different technologies impact the others is a very important thing. And maybe only letting those who know or want to learn to do the specific jobs. Most terrible CSS is because someone had to do it, not because they wanted to. Same with databases and APIs that used presets instead of optimised settings.
This condescending remark dropped in at the end completely negated all of the other points, shame.
@codepo8 That's what I'm saying, I never implied that frontend developer should be contributing to the backend, but that these concepts will make you more independent as a developer and will create less blockers in a team, which is what I believe companies are looking for.
@jackmellis Yeah I can't disagree with that. I took a look at his profile then his website and the impression I got is 'of course I have to enlighten "him"'. Obviously I was wrong and the conversation didn't go as I was expecting.
The front end is much more a technical expression of the nuances of user interface design, user experience and product management than it should be of ORM and ERD. By all concrete accounts of major product companies and how they operate, the business end of the spectrum (meaning: product management, reflected in design and flows) should be the deciding factor in architecting both the back end and the front end, not the other way around.
Sure, @syndrom95 intercommunication is ideally made with the same set of data and technical restrictions at hand for all the people involved in decision making, but that also means the best back end developers know how good front end is architected as well, not just the other way around. And that means usability, accessibility, web standards, responsive design, SEO, structured data, interaction design, user psychology and the list goes on and on. I don't see that many back end developers crazy to find out more about such nuanced lenses of looking at a final product.
Which leads me to the point I'm trying to make: each of us, whether we're more biased to the front end or to the back end, should be a "T shaped" professional who knows at least the minimum about all other related fields that guide the quality and content of their work so they don't negatively affect relationships and workflows with other contributors in a team, and this is of course the ideal. But if I were a manager in a product team and all other roles are adequately filled, I would much rather have a VERY good front end developer biased towards knowing a bit more psychology, design and UX rigors than one biased towards mastering back end expertise, because the responsibility of the front end developer's end result (which is HTML, CSS and JavaScript) is correlated much more with UI and UX than with how databases work. And to be clear, I'm talking about the "front of the front end" here.
I agree that frontend developers need (and are often missing) an understanding of fundamental software engineering principals, but do they need to understand ORMs or relational databases? Absolutely not.
The segregation of frontend and backend means a frontend dev doesn't need to know about the underlying backend technology. Just like I wouldn't expect a backend dev to have to know React in order to send me some data.
If a backend developer told me I needed to look at the database schema to understand their API response, that'd be a red flag for me.
All that matters is the domain models and endpoints are agreed upon by both sides. The implementation detail is just a black box.
Certainly, frontend developer does not have to understand these concepts, a good developer does understand.
Yes, in a perfect world, existing in the realm of imagination that's true.
In a real world that is a practice applied in minority of companies so it's not worth debating on.
Okay I guess this isn’t going to be a constructive discussion.
And that minority of companies is 100% of the places I’ve worked at so I feel it’s not only worth debating, but worth pursuing actively.
Absolutely not
one of the most useless discussions I've encountered online for a VERY long time. 🍿🍿🍿
@codepo8 Can we just call a front-end dev a ✨DESIGNER✨.
Also I think CSS is easy. I have done it back in the day, and the use of hover, onclick and flexbox's was pretty simple and straightforward to me. I cannot imagine people saying it is hard, but that it is not for them instead. 😅
A designer is something else entirely. :) UI and UX designers, not to mention graphic designers will of course disagree with your statement. And they are all involved in the creative process of making a website come to life.
The old term of "web designer" might still hold some significance in that sense, but it's a bit too vague, I think.
"UI developer" might be a better name for the job. But even that has its limitations.
And CSS is not easy. It's easy to learn, but difficult to master. If you don't believe me, try reproducing with pixel-perfect accuracy any sort of complex interface you find on Behance or Dribbble, and you'll hit several edge cases and conundrums you need experience to fix. And most of the times, not even StackOverflow can help, since you won't often describe a visual context the same way as someone else. :)
CSS and HTML are not a tools needed to be mastered, because it is not a programming language, but markup and style languages. But, they are essential to know.
CSS is turing complete by now. Please stop belittling it as "not a programming language". Using dozens of npm packages without knowing what they do isn't programming either.
Sorry, I don't know how one can use "dozens of npm packages". I am a Software Developer, not a Web Developer and if I AM DOING Web Dev, I usually uninstall things I don't need 😅.
Sorry for maybe comming out mean, but I am just stating the fact that creating a UI design and implementating it becomes really easy once you get used to it.
However, if by "mastering it" you meant being able to do anything with it, then I agree with you. 😅
I categorically object to this as an experienced frontend dev who couldn't design a site if his life depended on it.
Wow, I used to just go onto Pinterest, write down in my notebook the relative percentage of each section and where it would convert to the mobile design. Didn't know you guys had such a hard time. Also prob I selected simple designs, which were quick and easy to implement. 😅
I also used to just go to colormagic.app for color patterns.... Btw there are a ton of tools to simplify css coding, if u need I can send you links 😆
onclick in CSS?
:active or :target 😅
Focus-inside
And then recruiters invented "full-stack" as if back-end were a challenge and a skill-set and front-end was only an afterthought with technologies a back-end developer could cobble together some late Saturday afternoon. Companies then jumped at the opportunity to get 2-for-1.
So while I might agree the need on an expertise, I fully disagree in silos inside a team (Silos = liabilities).
I would not hire a frontender, a backender, an infra, a dber,...If not as you can see it becomes absurd to run a single project if everyone is on their silo. If we would do so we are going backwards and having horinzontal slicing and not vertical slicing that improves team independance. It also has some other side effects as explained in team topologies.
That is why from my perspective people need to be T shapped, meaining "great, you have an expertise or prefference and you can help others improve on that knowledge, nevertheless you are open to learn and do other things".
Why? Its the team systems, we evolve it as a whole and we expect the input of everyone in discussion and understanding of the product. Silos also affects flow of value as people require more sync (A does the FE, B the BE, C the infra...). Also the same time for teams with devops mentality it does not work, if you only have the knowledge of part A of the system because when something fails people are unable to see the entire picture.
I could go on with the issue of team of experts, but I think i made the point.
my 2 cents, tp anyone that gets here, get something that motivates you and dig as deep as you want, but dont dig deep enough that you dont see anything else.
A bit late after the party.
But I totally agree with your post. I used to call myself full stack until a few year back roughly when flexbox and react took over the web. Then I got more deeply into the backend side. The main reason is that I enjoy way more designing db schema and optimising data process than working through the nightmare (for me!) of browser compatibility and user event. So yes hats down for specialised frontend dev there is a place for you and it's really worth it.
Small note following @kanekotic comment about team structure. While I agree that you need transverse ability in a team so that the work isn't fully segmented, I believe you need at least one specialised/experienced dev in front-end, backend and ops (and maybe mobile if apply). Hopefully those three people knowledge overlap and are not restricted to there speciality and the remaining part of the team should be more versatile "full stack". That way you get the benefit of all the domain expert with the flexibility to move forward with the feature.
And if some day you need more front end work, the specialized backend dev can take twice the time to do his first frontend pr in years and help the team move forward.
I've seen a lot of job descriptions looking for frontend developers with loads of fullstack experience.
Wait... companies are cheaping out on frontend by stuffing them into full-stack or design roles? Well that's one way to burn through your VC money I guess.
I'd argue just taking the money and run, or getting a findom if they are masochistic, but apparently they are going for the long con.
frontend =/= full-stack =/= UI/UX designer
“UI is basically form filling”, says backend dev. True, if you don’t care about UX. But if you do, then frontend is a thing. Modern frontend is so complicated because modern web app’s UX requirement is high, which pushes frontend so hard that it grows into this conglomerate.
LOL who considered JavaScript "easy"?? 😂
lol wasm will eat the world, and be the compile target for everyone! :)
On a more serious note: I don't think it has anything to do with the technologies used in the frontend. No matter if you are using Blazor, Yew or Leptos, React or Vanilla HTML/CSS/Javascript. The main challenge will still be to build the accessible, multi-device-capable (i.E. responsive), fast and nice looking interface for the users... it's simply a whole set of skills which should not just be an 'afterthought'.
Mh, CSS-in-Rust will be a joy....
A really good read - thanks!