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 <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.
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.
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
<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.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.