4 ms·

I would say that Frontend development in general (HTML+CSS) and the whole javascript ecosystem are a nightmare of patches on top of other patches, and endless e

I would say that Frontend development in general (HTML+CSS) and the whole javascript ecosystem are a nightmare of patches on top of other patches, and endless exceptions and small components whose sole job is to plug some hole from a different technology under it. You need endless people and bruteforce to build on it and provide more value for the end user. In comparison, Backend can turn bad sometimes, but a well designed, small Backend component can produce endless value and easy extensibility. I've never seen anything similar in Frontend.

shakes_mcjunkie 4y ago
As a frontend dev there are definitely well designed frontends. I've seen a lot of bad backends too. It just depends on how much engineers are able to plan ahead and also keep tech debt under control.
- everforward 4y ago
  The differentiating factor to me is that backends can typically define the runtime they want to use, while frontends are beholden to run on what the user brings. A backend from a decade or two ago can still run fine, because it defines what it runs on. It doesn't matter if CentOS 5 deprecated a feature the apps needs, we can run it on a CentOS 4 VM (not that anyone should). Frontend feels like it has more churn because it can't define it's own runtime. If Chrome deprecates a feature, frontends have to adapt to that. Because frontends have to adapt to their runtime changing, it becomes important to use a framework that's currently supported. You can't keep running on Java applets, because browsers won't run them anymore. You can't keep running on RandomJSFramework if it stops getting updates, because features may get deprecated in the browser. I think it has less to do with the average frontend vs backend dev, and more to do with the environment they operate in.
  - shakes_mcjunkie 4y ago
    I see you point but I have to imagine the vast majority of frontend devs are targeting Chrome which is very stable. TBH in 11 years of FE dev I've never encountered anyone complaining about Chrome deprecating a feature that wasn't explicitly experimental. Now, some frameworks or libraries might do that, or may no longer be maintained; but I doesn't BE dev deal with this too?
- Ambolia 4y ago
  I would say it's not so much about good or bad design, and more about which kinds of decisions, how many moving parts, and what consequences they have down the line. Like on backend you will have a choice of database, choice of language, and the design of the Schema/API, most of which are easy to detach and replace at some point. While on Frontend from the beginning, specially i you are working with a team, you will have to make a lot of small decisions that can cause all kinds of trouble down the line: - How you build the project, javascript transpilers and all that mess. - Decide a CSS framework, or not use a framework and then decide on an internal style guide. - Decide on a component library. - Decide on how to handle state. Or you can skip those above and use pure HTML+CSS+Javascript, but those usually end up as very spaguettified and idiosyncratic projects, I rarely see anyone even considering it unless it's a personal project. And for a good reason, the structure provided by component and state handling libraries reduces a lot of the inherent chaos that is structuring frontend web project. But each of those also comes with its own bag of new problems, and complexity that requires the developers to handle a lot of disparate information in their heads while working on a project.
  - shakes_mcjunkie 4y ago
    > Like on backend you will have a choice of database, choice of language, and the design of the Schema/API, most of which are easy to detach and replace at some point. This is absolutely not my experience. Every company I've worked at has had some long running back end tech debt, trying to swap out old tech. Every problem you listed for the FE has a BE analog. Is it just that there are a lot of choices for FE tech? IMO that's a strength and not a weakness. There's also a clear leader in the tech for each part of the stack to choose to get something running quickly. > Or you can skip those above and use pure HTML+CSS+Javascript, but those usually end up as very spaguettified and idiosyncratic projects, I rarely see anyone even considering it unless it's a personal project. This is like saying you're seeing BE devs consider writing all their DB queries in raw SQL in a production system rather than use an ORM. Sure, it's done sometimes but most of the time it makes sense to use an abstraction layer. Again, it's mostly whether or not engineers have the time to plan ahead and also update old code.
  - dt2m 4y ago
- akudha 4y ago
  I dunno, I’d rather take a bad backend codebase than a bad front end codebase. My job is moving completely to JS stack. The number of steps to build, number of packages to install, the cryptic errors… it is just depressing. Not to mention the resource hogging - we had to upgrade to 32GB RAM just to be able to do the basic stuff. Maybe there are better ways to do JS that doesn’t suck this much. I dunno. I just wish I could write just backend code. Python, PHP etc have their shortcomings, but none of them are as annoying as JS

shakes_mcjunkie 4y ago

As a frontend dev there are definitely well designed frontends. I've seen a lot of bad backends too. It just depends on how much engineers are able to plan ahead and also keep tech debt under control.

everforward 4y ago
The differentiating factor to me is that backends can typically define the runtime they want to use, while frontends are beholden to run on what the user brings. A backend from a decade or two ago can still run fine, because it defines what it runs on. It doesn't matter if CentOS 5 deprecated a feature the apps needs, we can run it on a CentOS 4 VM (not that anyone should). Frontend feels like it has more churn because it can't define it's own runtime. If Chrome deprecates a feature, frontends have to adapt to that. Because frontends have to adapt to their runtime changing, it becomes important to use a framework that's currently supported. You can't keep running on Java applets, because browsers won't run them anymore. You can't keep running on RandomJSFramework if it stops getting updates, because features may get deprecated in the browser. I think it has less to do with the average frontend vs backend dev, and more to do with the environment they operate in.
- shakes_mcjunkie 4y ago
  I see you point but I have to imagine the vast majority of frontend devs are targeting Chrome which is very stable. TBH in 11 years of FE dev I've never encountered anyone complaining about Chrome deprecating a feature that wasn't explicitly experimental. Now, some frameworks or libraries might do that, or may no longer be maintained; but I doesn't BE dev deal with this too?
Ambolia 4y ago
I would say it's not so much about good or bad design, and more about which kinds of decisions, how many moving parts, and what consequences they have down the line. Like on backend you will have a choice of database, choice of language, and the design of the Schema/API, most of which are easy to detach and replace at some point. While on Frontend from the beginning, specially i you are working with a team, you will have to make a lot of small decisions that can cause all kinds of trouble down the line: - How you build the project, javascript transpilers and all that mess. - Decide a CSS framework, or not use a framework and then decide on an internal style guide. - Decide on a component library. - Decide on how to handle state. Or you can skip those above and use pure HTML+CSS+Javascript, but those usually end up as very spaguettified and idiosyncratic projects, I rarely see anyone even considering it unless it's a personal project. And for a good reason, the structure provided by component and state handling libraries reduces a lot of the inherent chaos that is structuring frontend web project. But each of those also comes with its own bag of new problems, and complexity that requires the developers to handle a lot of disparate information in their heads while working on a project.
- shakes_mcjunkie 4y ago
  > Like on backend you will have a choice of database, choice of language, and the design of the Schema/API, most of which are easy to detach and replace at some point. This is absolutely not my experience. Every company I've worked at has had some long running back end tech debt, trying to swap out old tech. Every problem you listed for the FE has a BE analog. Is it just that there are a lot of choices for FE tech? IMO that's a strength and not a weakness. There's also a clear leader in the tech for each part of the stack to choose to get something running quickly. > Or you can skip those above and use pure HTML+CSS+Javascript, but those usually end up as very spaguettified and idiosyncratic projects, I rarely see anyone even considering it unless it's a personal project. This is like saying you're seeing BE devs consider writing all their DB queries in raw SQL in a production system rather than use an ORM. Sure, it's done sometimes but most of the time it makes sense to use an abstraction layer. Again, it's mostly whether or not engineers have the time to plan ahead and also update old code.
- dt2m 4y ago
akudha 4y ago
I dunno, I’d rather take a bad backend codebase than a bad front end codebase. My job is moving completely to JS stack. The number of steps to build, number of packages to install, the cryptic errors… it is just depressing. Not to mention the resource hogging - we had to upgrade to 32GB RAM just to be able to do the basic stuff. Maybe there are better ways to do JS that doesn’t suck this much. I dunno. I just wish I could write just backend code. Python, PHP etc have their shortcomings, but none of them are as annoying as JS