1. Back-end code runs on expensive software whereas front-end code runs on free software. People associate cost with importance.
2. Activities of back-end code are often not directly observable. People are conditioned to regard the mysterious with the sacred.
3. Front-end code operates in an uncontrolled environment. That makes development more difficult. In human society, however, control implies power and those with power sit higher in the hierarchy.
4. Front-end programmers often find themselves deferring to the opinion of UX designers. A variation of reason 3: Not being a decider is associated with lower social standings.
5. Front-end technologies change more rapidly than back-end ones. Again, that raises the difficulty of front-end development. Yet it means investment into front-end code wouldn't hold its value as well as investment back-end code. People are loss-adverse. It's an uncomfortable thought losing a critical part of a project to obsolescence.
6. Back-end programming is less exciting than front-end programming. People's sense of justice lead them to reward--rightly or wrongly--back-end programmers with greater regard.
As someone who has a CS background who wanted to work in front-end, I think a big portion of the "looked down upon" piece comes from an older era where front-end just meant HTML and CSS. Since there isn't much logic to HTML or CSS, it was looked down upon as easy from people with a CS background who generally gravitate towards the backend.
Now that the front-end is more robust with arguably just as much logic on the front-end, the thought is shifting. In addition, some people just don't like handling the GUI layer. For the back-end, dealing with the GUI layer is their least favorite part. So if you have a CS degree and you want to tackle the front-end, you could be one of the rare few who has the technical chops to handle this new world of front-end complexity.
well structured css and html are extremely important to project maintainability long term. Css is a declarative programming language and not at all trivial.
As for JS based front ends, yes, they approach the complexity of game development and totally deserve due respect.
As someone who has worked on both front end and back end code, I have a lot of respect for both. That being said, when I delegate work, I feel a bit more nervous about the front end because of the brittleness and potential compatibility issues.
Now there's nothing wrong with this flow. In fact it's pretty good as long as tech debts are kept in check. (Don't use unvetted node modules for trivial things.) Why do back-end devs think this isn't so great? We like knowing. Everything down to where the software interacts with the hardware and how the hardware behaves. Also, the 10K concurrent users are all using 10's of servers so best not to waste memory, CPU, or network. This feels like engineering.
There is a third category of front-end devs that do truly amazing things with very little. Elm is one such example. I also prefer Vue to React or Angular as it is meant to be the best of these two worlds. Nuxt/Next are also awesome. Front-end devs made these. After developing apps decided to do it better. Some single-page applications are really well written but they are the exception. Usually it's copy-paste, hit the deadline.
TBH, I often think front-end devs are more aligned with business. Doesn't change the fact I still like to do clean, efficient, well-factored back-end work.
1. How are your javascript test suits organised? Do you measure code coverage the same way?
2. Are there any standardised terms that you can use to convey stylistic concepts to other (front end)devs (excluding framework specific terms and html elements)? i.e. Software Design Patterns for code
3. Do you personally feel your field is more artistic or rigorous?
4. Do you personally think it should be artistic or rigorous?
5. (For reference) What is your job title?
6. Would you say you work more closely with the Tech Lead (or organisational equivalent) or Artistic Director (or organisational equivalent)?
7. What is your direct report's job title?
8. Are you able to suggest/implement global style changes on the basis of your own authority?
9. Do you maintain/contribute to any (front-end dev) documentation?
1. Tests are organized around their component. This includes unit tests for any logic (though often we prefer to keep as much logic out of FE as possible) and screenshot tests for components. We also have larger-scale integration tests.
2. You mean like MVC (model-view-controller)? That's a pretty common one.
3. I'm not sure artistic is the antonym of rigorous. For example, math proofs are often both. I think it's better to characterize it as a craft. It's like being an electrician; sometimes your wires line up nicely, but sometimes you have to find a way (aka a hack) to be up to code while still having the microwave's fan button turn on a fan on the building's roof.
4. I think it should be as rigorous as possible, but as another user mentioned, it's not realistic to own the environment in which your code runs. I would love to have a small set of environments/browsers/screen sizes to develop for, but that's not an option in 2019 at scale.
5. Software Engineer
6. Definitely tech lead
7. Senior software engineer
8. I can definitely suggest them, and everyone is open to ideas and discussion. Design and software is a team effort.
9. I write a lot of documentation. This includes writing/updating comments, writing design documents for new FE features, updating wikis etc.
I actually think really great front-end development, when necessary, is hard to do and the folks who are interested in it and good at it are great Engineers. I also think that good User Experience is what makes money, though this doesn't always mean lots of bells and whistles or even, what is traditionally thought to be, "front-end" development.
Unfortunately the barrier to entry is probably lowest in front-end development and so there are a lot of folks, when seeking a career change into software development, naturally gravitate to front-end, when their natural aptitude would probably be better suited to something else in tech, like product manage, devops, or even "back-end" engineering (though I will admit that "back-end" engineers tend to be biased against folks with non-technical degrees/backgrounds).
The way I see it this creates a chain of negative causal effects. First, "front-end" is chalk-full of people who don't know what they're doing or talking about. Second, naturally being biased to think that the work they do is valuable and important, "front-end" engineers often advocate for lots of front-end rewrites and Rube-Goldberg-esque front-ends that aren't actually necessary to the success of the product or business. The front-end is the most visible part of the product even though it is often the smallest piece of the product so business leaders, who have little technical experience, will often put the front-end team in a position of de-facto authority over the product or at least give them out-sized input. The stereotype that emerges is that front-end teams often get more resources then they need, get to rewrite the front-end once a year using the front-end framework du jour, when it is often not necessary to do so and a static website with few interfaces would actually not only be fine, but better. This is a trope that you will commonly find complained about on HN, and my own personal anecdotal experience confirms. I once worked at a company that had a massive back-end; not that VM count is always an indicator, but we had over 1000 large servers running our stack. Our front-end team was half the size of the back-end team and wrote their own CMS at one point. Two thirds of our users interactions (as evidenced by our server logs) were through the CLI that the back-end team maintained and wrote. Users often had no idea how to do something on the front-end, because there was so much feature clutter.
My personal opinion is that a lot of products actually don't need as much front-end as they think and that hiring a design firm to come in at the beginning (and then once every two years) and hand off the front-end to a team of back-end engineers to keep up to date with features would probably be fine. Of course, of course, of course there are lots of exceptions to this, and I'm not suggesting a ratio of when this is true, but even if it's 50/50 that does not seem to justify the proliferation and front-end bloat that a lot of us have come to loathe.
My two cents.
A great frontend engineer is worth their weight in gold... it's just that so many bad ones exist, the default thought when hearing 'front end engineer' is not a good one.
> First, "front-end" is chalk-full of people who don't know what they're doing or talking about
I've seen no shortage of this in backend roles, and in any technical role there's been no hesitation to let go of underperforming developers. If there is you have a culture problem
> The front-end is the most visible part of the product even though it is often the smallest piece of the product so business leaders, who have little technical experience, will often put the front-end team in a position of de-facto authority over the product or at least give them out-sized input
From previous job experience I agree with this. One role where I was the backend developer the project failed because the UI was prioritized to the extent that the API was fully fleshed out, but the infrastructure and user migration plan was nonexistent. But it's a leadership failure, not a technical one.
I'd also caution against seeing the front-end team as "de-facto authority" to business leaders. They're more visible to the business so they have more frequent communications, but I've learned that it's naive to think them as having _any_ authority. If anything I now spend most of my time fighting against impractical requirements that would impede a successful, timely product launch (sometimes at the expense of launching at all), and business leaders are deaf to it. It's an exercise in frustration if anything.
> The stereotype that emerges is that front-end teams often get more resources then they need, get to rewrite the front-end once a year using the front-end framework du jour
The team I'm on is on its 3rd or 4th front-end rewrite of the same application. You say 'framework du jour', I say "technology that has been abandoned by the vendor, is not meaningfully cross-platform, is too difficult to hire for". I've not been involved in the previous 3 rewrites, but I can tell you the company would lose the business if the rewrites weren't done. When technology at large moves on, front-end developers are rarely to blame
> Two thirds of our users interactions (as evidenced by our server logs) were through the CLI that the back-end team maintained and wrote.
It's true that depending on the application, a front-end may not even be necessary. But I would say that given a 2/3rd 1/3rd split, it's worth the investment for marketing purposes alone. Unless your salespeople are out there selling CLIs/APIs to clients (which in my experience, even if you're selling APIs, it's rarely the case).
> Users often had no idea how to do something on the front-end, because there was so much feature clutter.
In my case the feature clutter is likely a business requirement by a team of designers that the front-end developers can't meaningfully influence. I'd love nothing more than to have buttons with meaningful labels instead of implementing a designer's shitty iconography for the Nth time.