Comment by hardwaregeek | Hacker News Reader

Comment by hardwaregeek | Hacker News Reader

Parent Full thread

I agree with this article more than I expected. I suppose a more accurate title would be "Dividing front end development from back end development is an antipattern". At first I thought it was about the actual act of separating the codebases.

I find it really baffling how much animosity there is towards front end. Nobody goes out hating on back end. If I had to guess why there's so much hate, I'd posit lack of control. Front end development requires relinquishing a lot of control. You can't really choose your programming language. You can't choose your styling language. Often times you're being told how something should look by a designer, which can be a bit of a blow to the ego. Being ordered around by a gasp artistic person. The horror.

Even if you get to decide how things look, that's even worse in some ways. I know I've spent hours slaving over designs that just don't look good. Maybe you give up and resort to Bootstrap/Material Design, but that certainly feels like defeat.

I'll admit. Front end takes some acclimation. I hated debugging JavaScript for the longest time. But with modern tooling it's quite nice. Plus there's something really amazing and challenging about having real, non technical people interact with your code. Only developers will notice an API bug, but everybody will notice a client side bug.

My dislike of frontend work mostly stems from the fact that, at least when I started, there were no generally accepted best practices. I started out with Backbone.js, and it wanted to be “unopinionated” in things like directory layout and the best methods refreshing data. Every tutorial I read did something different. Compare this to a more mature framework like Rails or Django, and you can see how one might easily waste time on some of the basics.

A few years ago, I built a small project using Nunjucks templates that needed translations. There were a half-dozen different ways of extracting translations, and most of them required some form of manual work. Coming from Django, with a single best way of handling translations, this was annoying.

I prefer “batteries-included” frameworks that let me focus less on foundations and more on the actual business. Angular was the only framework I used that resonated with me in this fashion.

Now I use React, and spend most of my time debugging tests.

I have the same issue with frontend dev, or other "unopinionated" frameworks.

I just want to get started with something quickly, not spend hours or days (when I'm doing something on my free time, not at work) reading about different libraries or plugins that I have to choose from, to accomplish something seemingly trivial.

I think if frontend didn't mean JavaScript and npm packages, that animosity wouldn't really exist.

While there is some use of JavaScript at the backend, IME it's much less that other languages, so backend developers are used to "better" languages with actually useful standard libraries (C#, F#, Elixir, Ruby, Python...).

Of course, JavaScript is evolving, albeit slowly, and recently TypeScript helps somewhat. Web assembly may eventually offer a real alternative, but I think we're still a long way front it becoming mainstream.

My impression is there are a segment of technically-minded backend engineers who look down on frontend work - who cares what the damn thing looks like as long as it works?

I think the truth is, most engineers just aren't comfortable with A) working with stakeholders and translating requirements to specs, aka soft skills, B) any sort of design (which is actually hard!) or C) learning the HTML/CSS/JS ecosystem. Also, I found learning how to write frontend applications to be just as challenging as writing CRUD apps.

Do back-end teams not have to deal with clients, requirements or software design?..

The HTML/CSS/JS ecosystem is hard, props for that, but then it's made harder by being reinvented every year by the latest fad.

From my perspective, the reputation comes from its roots. Modern web apps that interact with a multitude of APIs and the user are a far cry from the ad-hoc scripts or static webpage authoring that it was a couple decades ago.

I'm going to be a bit contentious here but

> you're being told how something should look by a designer, [...] Being ordered around by a gasp artistic person

Neither are very relevant. UI interface design is about supporting workflow. Visual appearance is not unimportant but it's shallow.

> about having real, non technical people interact with your code

yeah, that's how you do it! Assuming your company actually does UI testing at all.

I somewhat disagree about the irrelevance of visual design. A good or exceptional visual designer can quite often have an enormous impact on the user experience, and also save the development team a lot of work.

I don't think it's shallow, it's actually taken for granted. Look at how vertical scrollbars work on both mobile and desktop, for example.

We don't give it a second thought, but imagine how many layouts would break on mobile, with a default 20px scrolling rail on mobile browsers. Or the way the URL bar hides when you start scrolling.

Those kind of ideas, from my experience, rarely come from product developers without some visual design experience.

Reply on news.ycombinator.com