[deanclatworthy]

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.

[arendtio]

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.

[exikyut]

> check for features based on the current browser shares

TIL! That sounds awesome. What are these called? :D

[fiddlerwoaroof]

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.

[sanderjd]

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.

[dgb23]

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.

[eska]

So you think testing distributed systems is easier than behavior among different web browsers? Are you up for hire? /s

[DeathArrow]

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.

[wwn_se]

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.

[zamalek]

I feel bad for such a brief reply:

contenteditable

And:

Safari (https://www.safari-is-the-new-ie.com/)

[skinkestek]

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.

The same absolutely cannot be said for Safari.

[deanclatworthy]

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.