These are completely different types of skills. Front end is complex because there’s an explosion of different states driven by how the user interacts with the UI. On the other hand, backend workflows tend to be a lot more structured. You get a request, do some processing, fetch some data, and return a response.
Making good UX is fucking hard. I say UX because making it good is really about the user’s experience, not graphic design. An ugly front end can be good if it’s intuitive and easy to use. But a visually gorgeous front end will still be garbage if it’s clunky and confusing.
It’s really something you have to experience to fully understand. Ultimately it comes down to this: front ends have to deal with people, backends only have to deal with computers. So backends can be cleanly organized and well structured. Applying backend design principles to a front end will get you a CRUD interface - something that’s usable but no one really wants to use.
You need to be able to do layout design to do good ux. The visual presentation is a critical aspect of usability. Also backend code needs to be consumable future readers (including the author). That’s something that is very often lost and you get terrible unorganized backed code.
This is kind of what I meant. Appearance isn’t just colours and alignment, but also things like flow, organisation and layout. I can make the data theoretically accessible, but with all that stuff I’m completely out of my depth.
Write-only code can be an issue for either, while on the other hand complexity theory, big data structures and high math make me think backend.
The complexity of dealing with different states a UI can be in. The user can navigate the interface of an app in many different ways. The US has to be able to handle all the different combinations of actions the users takes. This means maintaining a consistent state, loading data that’s needed, keeping track of navigation, etc. The logic in an interface of an app like an email client is far more complex than most backend workflows.
Yeah, that could be reasonably complex I guess. I’ve never dealt with more than one navigation structure in a UI, like that would have. All the memes are about clients wanting it to look different.
I mean… the browser can do all that shit itself, just give it some HTML and stylesheets. It’s incredibly important to realize that nearly all this complexity is optional - it may make sense for Facebook to invest this much in a UI but most companies could get away with plain ol’ html with a bit of styling.
As a front end developer you should know when things like infinite loading dynamic tables with a search bar add significant value and when `` is good enough. Maintaining complex systems costs money and developers should always advocate for the simplest most sustainable solution to a problem. I think we have a real issue with pursuing shiny new technologies. <table></table>
I mean… the database does all the shit itself, just give it some SQL queries. It’s incredibly important to realize that nearly all this complexity is optional - it may make sense for Facebook to invest this much in their backend infrastructure but most companies could get away with plain ol’ script that on top of Postgres.
As a backend developer you should know when things like load balancing and and complex db schemas add little value, a single table is good enough. Maintaining complex systems costs money and developers should always advocate for the simplest most sustainable solution to a problem. I think we have a real issue with pursuing shiny new technologies.
Absolutely, it’s why at our company I laid the groundwork to eventually adopt a read replica based database approach but didn’t push to actually set up such an environment until about six years later when we had a compelling reason to switch. I work in PHP and the language itself is pretty irrelevant because most pages are just some validation and then shuffling the request off to the database - it doesn’t make sense to over engineer since you’ll end up paying to maintain things that don’t benefit you.
Using a single table is almost always a bad idea though - for prototyping it can make sense but strong typing ends off paying off quickly in not having to write defensive code.
People on all sides are guilty of over complicating things and it’s not helpful for building an agile product. I’d say that there’s a generally accepted assumption that “modern web” means react or some other flavor of SPA - these are amazing tools but aren’t always necessary. Tools are powerful, but you should understand what you’re using and have a justification as to why (or at least make it obvious that decisions were made arbitrarily since sometimes you’ve just got to choose one).
Nobody is arguing for overcomplicating things, and it’s true that a lot of projects out there are in fact overdesigned. However, there are also non-trivial applications out there, and front-end can in fact be complex in such apps. For example, I worked at a hospital at one point, and my team built an application that allowed multiple users to work collaboratively on shared documents seeing each other’s changes in real time. That’s a kind of app that is non-trivial, and where there’s plenty of legitimate complexity to be found both on the frontedn and the backend.
A simple web app will be okay with some HTML forms, sure. But something like a multi step wizard will lead you down the path of storing a huge amount of state on the server side, which turns into a mess. We have a wizard that uses Django’s forms and django-formtools’s wizard. You have to put the state and complexity somewhere. We put it in the backend and I can’t say I like how it turned out. The code is spaghetti and we get a stream of errors from people not acting how they’re expected to act.
These are completely different types of skills. Front end is complex because there’s an explosion of different states driven by how the user interacts with the UI. On the other hand, backend workflows tend to be a lot more structured. You get a request, do some processing, fetch some data, and return a response.
From where I sit, it seems like frontend is closer to being a graphic designer than on backend.
Then you haven’t developed a non-trivial user interface before.
I’ve made UIs, and at least one I’d say was complex, but it was also really ugly. What am I missing?
This wasn’t a put-down, BTW. I couldn’t be a graphic designer either.
Making good UX is fucking hard. I say UX because making it good is really about the user’s experience, not graphic design. An ugly front end can be good if it’s intuitive and easy to use. But a visually gorgeous front end will still be garbage if it’s clunky and confusing.
It’s really something you have to experience to fully understand. Ultimately it comes down to this: front ends have to deal with people, backends only have to deal with computers. So backends can be cleanly organized and well structured. Applying backend design principles to a front end will get you a CRUD interface - something that’s usable but no one really wants to use.
You need to be able to do layout design to do good ux. The visual presentation is a critical aspect of usability. Also backend code needs to be consumable future readers (including the author). That’s something that is very often lost and you get terrible unorganized backed code.
This is kind of what I meant. Appearance isn’t just colours and alignment, but also things like flow, organisation and layout. I can make the data theoretically accessible, but with all that stuff I’m completely out of my depth.
Write-only code can be an issue for either, while on the other hand complexity theory, big data structures and high math make me think backend.
The complexity of dealing with different states a UI can be in. The user can navigate the interface of an app in many different ways. The US has to be able to handle all the different combinations of actions the users takes. This means maintaining a consistent state, loading data that’s needed, keeping track of navigation, etc. The logic in an interface of an app like an email client is far more complex than most backend workflows.
Yeah, that could be reasonably complex I guess. I’ve never dealt with more than one navigation structure in a UI, like that would have. All the memes are about clients wanting it to look different.
I mean… the browser can do all that shit itself, just give it some HTML and stylesheets. It’s incredibly important to realize that nearly all this complexity is optional - it may make sense for Facebook to invest this much in a UI but most companies could get away with plain ol’ html with a bit of styling.
As a front end developer you should know when things like infinite loading dynamic tables with a search bar add significant value and when `` is good enough. Maintaining complex systems costs money and developers should always advocate for the simplest most sustainable solution to a problem. I think we have a real issue with pursuing shiny new technologies. <table></table>
I mean… the database does all the shit itself, just give it some SQL queries. It’s incredibly important to realize that nearly all this complexity is optional - it may make sense for Facebook to invest this much in their backend infrastructure but most companies could get away with plain ol’ script that on top of Postgres.
As a backend developer you should know when things like load balancing and and complex db schemas add little value, a single table is good enough. Maintaining complex systems costs money and developers should always advocate for the simplest most sustainable solution to a problem. I think we have a real issue with pursuing shiny new technologies.
Absolutely, it’s why at our company I laid the groundwork to eventually adopt a read replica based database approach but didn’t push to actually set up such an environment until about six years later when we had a compelling reason to switch. I work in PHP and the language itself is pretty irrelevant because most pages are just some validation and then shuffling the request off to the database - it doesn’t make sense to over engineer since you’ll end up paying to maintain things that don’t benefit you.
Using a single table is almost always a bad idea though - for prototyping it can make sense but strong typing ends off paying off quickly in not having to write defensive code.
People on all sides are guilty of over complicating things and it’s not helpful for building an agile product. I’d say that there’s a generally accepted assumption that “modern web” means react or some other flavor of SPA - these are amazing tools but aren’t always necessary. Tools are powerful, but you should understand what you’re using and have a justification as to why (or at least make it obvious that decisions were made arbitrarily since sometimes you’ve just got to choose one).
Nobody is arguing for overcomplicating things, and it’s true that a lot of projects out there are in fact overdesigned. However, there are also non-trivial applications out there, and front-end can in fact be complex in such apps. For example, I worked at a hospital at one point, and my team built an application that allowed multiple users to work collaboratively on shared documents seeing each other’s changes in real time. That’s a kind of app that is non-trivial, and where there’s plenty of legitimate complexity to be found both on the frontedn and the backend.
A simple web app will be okay with some HTML forms, sure. But something like a multi step wizard will lead you down the path of storing a huge amount of state on the server side, which turns into a mess. We have a wizard that uses Django’s forms and django-formtools’s wizard. You have to put the state and complexity somewhere. We put it in the backend and I can’t say I like how it turned out. The code is spaghetti and we get a stream of errors from people not acting how they’re expected to act.
How about UIs that are essentially web apps. I’m talking about needing to handle drag and drop, graphs and the like.
There is also the mess that is responsive design, multi browser support and proper accessibility.