Hacker News Reader

Comment by deanclatworthy | Hacker News Reader

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.

View on HN

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.

> check for features based on the current browser shares

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

More here at https://kangax.github.io/compat-table/es6/

Browserlist [1] makes use of the browser market shares and you can use it with plugins such as eslint-plugin-compat [2].

[1] https://github.com/browserslist/browserslist [2] https://github.com/amilajack/eslint-plugin-compat

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.

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

Clever, but that's completely missing the point.

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.

I feel bad for such a brief reply:

contenteditable

And:

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

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.

There are many documents in the world, but knowing when to look or how to find them comes over time and with much frustration.

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.

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

> Actually I'd say every single one applies to Safari more than Chrome.

Then you must read closer.

Even one of your cherry picked examples is plain wrong.

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.

At the end of the day the discrepancy is my point, it doesn't matter which browser is the worst culprit.

Reply on news.ycombinator.com