One thing I understand as a "backend engineer" (which my front-end/web engineer colleagues usually hold in high regard): my code does exactly what I tell it to do, good logic and bad logic.
You can have the best and cleanest JS that targets FF, and have it fall over one million ways in other browsers (I'm looking at you, Safari). There is a level of respect that is lost, so far as the expertise of understanding the lowest common denominator across browsers, and actually getting that denominator to do something useful.
Front-end is, at the end of the day, much harder than backend. I understand why us backend people get praise: algorithms, distributed systems, coherency, performance, yada yada yada. Imagine coding against a system that doesn't behave consistently. No thanks.
It really isn’t. I’m full stack and do both every day. I’ve been doing both since the days of IE5. Things have changed a lot but the challenges you face on the back-end with different technologies, distributed systems, data integrity, security etc are far more complex.
The difference is that in the backend you have control over the runtime environment. In the frontend you don't.
However, because frontend devs know that, they have build tools to support them. It started with jquery as an cross browser abstraction and has grown to a whole eco system ranging from websites like caniuse.com to editor plugins that check for features based on the current browser shares and your specific selection (e.g. browserlist) up to test-farm services like browserling.
I think what makes frontend development harder, is that standards carry a lot of legacy (you can't just redesign CORS and 3rd party cookies) and that you have a very diverse set of runtime environments with very different capabilities.
I’ve had the exact opposite experience as a full-stack dev: backend code generally has a more or less straight-through code path from the request handler to the response, on the front-end a user can be interrupting your processes at any moment.
Probably depends on scale. I think front end is the harder part of getting something decent working while backend is the harder part of getting it working well under load.
Yep this is the point. Back-end for sure is simpler if you are not operating at any meaningful scale. As soon as you start tackling the problems mentioned in my OP, things get (much) harder.
All of those things are testable. It’s data in, data out. On the frontend, not so much. You can structure your code in a way that allows for intermediate representations, which are more testable. But past that? Things need to look right, behave in a helpful way. You can’t assess that from within the code. At least not yet.
For one I didn't mention "behavior among different web browsers". I think that's a red-herring in this discussion. What is hard about UI front-ends is not that, nor is it unique to it. It is the fact that you are providing something that's consumed by humans directly. Most of the heuristics surrounding that are fuzzy at best. It is an open system on top of that, because humans are wildly different in their perception of and ability to interact with computers.
I also didn't say "testing distributed systems is easier" than that. It's a completely different game. Contrast the language/jargon/papers/practices surrounding the two:
- Fault tolerance, CAP, ACID, replication etc.
- accessibility, affordances, interaction, perceived performance etc.
Which one of those you think lends itself more to test automation and engineering principles?
Whether you find one or the other easier might depend much more on how well you do and want to understand this difference and how well you apply that knowledge.
I'd am happy to deal day by day with the microservice based app we are developing (. NET, Postgres, Redis, Nats, Docker, Kubernetes, Consul) but I'd hate to deal with a Javascript framework.
On the other hand, I would like to do some fronted if that means handwritten JS + some JS libraries and NO framework.
It really depends on the project as a consultant I have seen crazy complexity on both "sides".
Most projects backend seems to be more complex but backend also get more slack. For example if there is a DB performance problem there is usually a DB-team to help with tuning.
Front end ppl are usually more on their own, since its expected they will have easier problems. That's not always true though. Some orgs are adapting and adding css specialist and design roles to enable more technical front end devs to focus on that.
Making a website for it is good marketing, but it doesn't make it anymore true.
Chrome is the new IE:
- introduces its own standards: check
- technologically superior in narrow fields: check
- forced upon everyone by the most powerful computer company at its time true a multitude of shady deals, bundling etc: check
- lazy programmers doesn't verify in other browsers: check
- will be abandoned as soon as they have crushed competition: jury is still out, bit based on previous behavior by defender it is more a question of when rather than if.
Actually I'd say every single one applies to Safari more than Chrome. Chrome is not forced upon anyone in most cases. Most sites in Chrome would work just as well or better in FF. Lazy programmers is not something Chrome controls at all. It's just what makes sense considering the ubiquity of its use worldwide but is not something that's a good practice or Chrome's fault
Chrome is open source (well, except few proprietary parts nobody cares about). And not just formally open source, there are plenty of browsers built on chrome engine. That's its main difference from IE.
These problems, much like the IE problems back in the day are well documented. Much like you need domain knowledge to work on the back-end this is "par for the course" in front-end world also.
Is this perhaps an accidental vs essential complexity difference? I find front end a lot "harder" as in more tedious, requiring more memorization of otherwise useless facts. But I find backend "harder" in the engineering tradeoffs sense. That smells like front end has more accidental complexity while back end has more essential complexity.
I am currently reading that book [1]. Such a great book of ideas. Getting vendors to agree is a hard task, though. Some of that accidental complexity may be arising due to the essential complexity of vendor interaction.
I think so. IMHO the browser/html/JavaScript/frameworks ecosystem is the poster child of accidental complexity. That is just what tends to happen when systems evolve continuously from humble beginnings to eventually tackle huge problems. You usually can't avoid it. There is just so much to know.
Backend is pretty much just the complexity of distributed state management, plus whatever complexity you bring to it. If you don't need horizontal scaling at all, a ton of complexity just sloughs off.
> You can have the best and cleanest JS that targets FF, and have it fall over one million ways in other browsers (I'm looking at you, Safari).
Conversely, you can have the best and cleanest JS that targets Safari, and have it fall over one million ways in other browsers (I'm looking at you, Firefox).
You can have the best and cleanest JS that targets FF, and have it fall over one million ways in other browsers (I'm looking at you, Safari). There is a level of respect that is lost, so far as the expertise of understanding the lowest common denominator across browsers, and actually getting that denominator to do something useful.
Front-end is, at the end of the day, much harder than backend. I understand why us backend people get praise: algorithms, distributed systems, coherency, performance, yada yada yada. Imagine coding against a system that doesn't behave consistently. No thanks.