Hacker News Reader

Comment by BjoernKW | Hacker News Reader

Front-end and back-end are pretty arbitrary labels. Labels like these first and foremost are designed to help those who try to commoditise development work (e.g. recruiters).

Why should someone be able to become an expert in HTML but not, say, SQL? Only because one of these runs on a client and the other typically runs on a server?

Software development should be about creating something useful. Usually, neither back-end nor front-end code is useful on its own.

By nonetheless making that distinction chances are you're creating a culture where developers neither take responsibility for the end result nor have any agency in it.

View on HN

I totally disagree that they're arbitrary.

Front-end is commonly used to mean writing code that runs on a client browser or native environment, like iOS.

Back-end means writing code that runs on a server.

Sometimes they're intermingled code bases. At my companies, they aren't.

Browsers are sufficiently complex targets that it's reasonable to specialize.

In the case of web these terms are still defined by non-technical people and heavily misused.

In a typical web stack the front end is the UI and the back end is the database. You notice that precludes about 80% of the people writing code on modern web apps (such as Java people) who are somewhere in the middle. Its not backend just because Apache (or Tomcat) is somewhere in there.

You can still somewhat stratify people by their specialty.

Front-end devs might be working on server-side code that's generating their HTML/CSS/JS, but that doesn't require them to deal with the business logic between the database and front-end.

To your surprise code that runs on a server can have a frontend and backend too, this holds true for a lot of other things too like compilers.

Frontend does not mean visual, not at all.

See: https://www.quora.com/What-are-front-end-and-back-end-compil...

So does the word "design". The terms are overloaded and get a different meaning depending on the context.

In this case it's pretty clear we're talking about front-end as in "web front-end". The front-end/back-end distinction of a compiler is in another field entirely and means something completely different in the topic at hand.

"Frontend developer" is shorthand for "frontend web developer" or "web frontend developer". There is rarely any ambiguity in that.

While a compiler has a front- and back end, I doubt there are many ads for compiler frontend developers or compiler backend developers.

There aren't many ads for any compiler related issues, but that doesn't mean they aren't "real".

I'm not surprised. Keep your assumptions about my knowledge to yourself.

While you're right that there are other kinds of front ends, that's a different context than this entire discussion has been confined to.

If you want to be extremely literal, you can always find a way to disagree with people, but is that disagreement actually contributing meaningful information to the discussion?

If you want to be good, you need to know both anyways. Being a specialist on one side is for people who are still on their way to go deeper to multiple parts of the stack or those who feel good just by knowing 1 thing sufficiently.

> Front-end and back-end are pretty arbitrary labels.

I disagree. These are somewhat loose business standards that people have a general idea what they mean. The confusion mostly comes with the middle tier ( aka the interface between front-end and back-end ).

> By nonetheless making that distinction chances are you're creating a culture where developers neither take responsibility for the end result nor have any agency in it.

No. The front-end and back-end usually denote responsibility and security. Sure you can know HTML and SQL as a front-end developer but generally, the back-end servers itself ( especially in production ) are taken care of by DBAs, sysadmins, network admins, etc.

For toy projects that you do for school, you can wear all the hats. But in larger projects, nobody has the time or domain expertise to wear all the hats.

Front-end usually deals with getting data from the back-end and showing it to the client. Back-end deals with clustering, replication, network availability, disaster recovery, etc ( i.e. making the data available 24/7 ) or whatever the SLA dictates.

The difference between front-end and back-end isn't HTML or SQL or even where the code runs. It's about responsibility and security.

> I disagree. These are somewhat loose business standards that people have a general idea what they mean.

The problem with these standards is that they aren't conducive to creating value. They mostly help with pigeonholing developers into neat categories so they can be treated as fungible resources.

> the back-end servers itself ( especially in production ) are taken care of by DBAs, sysadmins, network admins, etc.

The main idea of the DevOps movement was to break down these walls in order to establish a culture of shared responsibility. What's the point in that if we even have walls within the Dev part of that equation? People thinking "I've done my part. Not my problem anymore." once they've thrown their stuff over the wall can be hugely detrimental to an organization.

> For toy projects that you do for school, you can wear all the hats. But in larger projects, nobody has the time or domain expertise to wear all the hats.

You don't have to be an expert at everything. Asking and relying on the expertise of others is perfectly fine. A developer in my opinion should however be able to take responsibility for creating an increment of business value without having to resort to managers or similar interfaces for coordinating the efforts required to do so.

Dividing developers into "front-end" and "back-end" lends itself to silo creation and the notion that someone higher up in the hierarchy is responsible for the business value your code contributes to.

>Why should someone be able to become an expert in HTML but not, say, SQL?

The more things you become expert at, the less deep your expertise can be. Some people may have the talent to become extremely deep at html, css, javascript, react, sql, and whatever back end language and frameworks, all at the same time. Many won't.

That's true but then again you don't have to be a 100% expert in a particular area to be useful.

80% often is more than enough. The remaining 20% can be researched or compensated for by an IDE if need be.

There's no need for example to know the complete JavaScript API by heart. That's what documentation and autocompletion are for. You just need to know where to look and have an understanding of how things work on a conceptual level.

I'd say even 50% with some firm conceptual understandings, and syntax for what you're working in/with. I don't consider myself an expert in React, but I'm more than sufficient with a relatively good understanding of concepts. Rarely do you really have to dig deep into event models, but when you do it helps to know conceptually.

Beyond that, it's similar for the very back. When to lean towards a given database type or environment is helpful. It depends a lot on your needs and other specifics to a situation.

I would say that a lot of higher level concepts and specific language syntax can help. I reach for map/reduce/forEach daily, as well as a ton of other things. Just knowing what's in the box can help a lot in a language... a given framework, meh, know enough to get things done and refactor/read a lot.

I think it's less talent and more dedication. My coworkers are impressed when I'm able to help them on all parts of our stack, but it's really because of the extra time I spent over my career outside of work learning new things.

From the start of college to about 4 years into my first developer job, I spent most of my free time building my experience. I'd experiment with new languages, build projects using different tech, etc, all to deepen my experience across the board.

To summarize that with "talent" cheapens the work that has gone in to it, and I think most people who are in the same position would feel the same way.

It's mostly about time invested, though aptitude certainly helps. Talent is learned and trained, not innate.

This. You won't be much special if you stick to one side of the stack which will give you only average salaries.

It's sad people get impressed when you can just program and handle servers at the same time.

Yeah, the whole issue seems like one of terminology to me.

It's not the case that an X developer has to know Y.

It's the case that an X developer that doesn't know Y will lose in a competition against one that does.

Hiring, job advertisements, recruiters etc are and always have been nonsense, we know that. It's certainly the case that developers all over the place are being misallocated. But that's not unique to whatever we're calling "front-end" today. It's probably not even unique to software development.

Where and how do you then draw the line? Should I expect you to also know Mobile Development?

I draw the line where it makes sense from a business value perspective. If the product you're working on is a mobile application then it makes sense to both know mobile and back-end development.

Personally, I work on business applications exclusively. Creating value in that realm nowadays usually involves a web front-end and a back-end. The front-end in these cases often is required to run on mobile devices, too, which however is perfectly achievable by using web-based techniques.

Occasionally, there's the need for having a dedicated mobile app. In those cases, I make use of web-based frameworks such as Ionic. Not only do those provide the additional benefit of staying platform-independent but they also abstract over the specifics of mobile platforms.

This might not be the perfect approach in each and every case but for business applications it's often more than good enough and the little additional value created by maintaining a dedicated Android or iOS codebase doesn't warrant the additional effort required to do so.

Reply on news.ycombinator.com