Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

I've had experiences in the past working with (traditionally back-end) developers, whose occasionally cross into the front end realm.

The resulting code would typically involve:

  • global namespace pollution (many many global functions included inline without flexibility or re-use in mind)
  • many one-off implementations of functionality which is already supported, or may be more easily implemented with the assistance of an already-included library (raw JS implementations of AJAX/DOM-related functionality)
  • mass groupings of inline styles

As a (relatively) seasoned front end professional, I've had some success conveying best practices to colleagues who were interested in learning. However, that success was largely based on trust and open-mindedness.

What one's options are when it comes to responding to questions asking to why some accepted "best" practices are genuinely better in a way which gains said trust and interest?


migration rejected from Aug 7 at 5:43

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as primarily opinion-based by MichaelT, durron597, Snowman, GlenH7, gnat Aug 7 at 5:43

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

I've heard a lot of weird things and I am mostly used to it, but this recent trend to distinguish between front-end and back-end developers as if they belong to two different species still gets me... – thkala Jan 13 '12 at 23:45
Do they not accept your explanations? Polluting the global namespace has consequences that should be fully understandable to back end developers. That in-line styles override the CSS you plan to write (to separate presentation out and put the presentation logic where you can trivially find it) is easy to follow and the benefits are pretty clear. Back end developers are familiar with the idea of using libraries. So where is the push-back coming from? – psr Jan 14 '12 at 1:03
just ask them if they would accept this kind of code in their back-end development. (if they say yes: fire them). there is no difference between back-end and front-end development regarding best practices. there are some things you have to learn like libraries or css. but doing back-end work you have to learn similar things. – thorsten müller Jan 14 '12 at 8:28

2 Answers 2

Don't evangelize. Evangelism is marketing.

Use clearly-defined logic to convince peers of what works and what doesn't.

Don't cite "best practices"; they're dogmatic. What works for "popular" developers isn't going to always work for you. Instead, clearly lay out why technique X is more likely to work than technique Y.

Here's an example I'll throw your way:

Consider you're on a small team of ideologically-divided programmers. Your task is to unify them and build a client-side tool—let's say a calendar.

Let "Adam" be a developer who favors a one-size-fits-all solution: ExtJS;

Let "Bill" be a developer who favors a "toolkit" solution: MooTools;

Let "Cam" be a developer who favors a dogmatic "best practices" solution: jQuery;

Your "enlightened" perspective is that building from scratch is the best solution. How do you convince your team that you're "enlightened"?

Suppose you make a pros/cons list for each position. It might look like this:



  • Pros: Modular, flexible

  • Cons: Dependency on foreign code


Hand-written Code

  • Pros: Familiarity, cleaner

  • Cons: Takes longer to produce, requires effort

Weighing the pros and cons, it's clear that Bill (MooTools) and you (hand-written) have the most flexible solutions.

From there, ensure your team is educated on how both strategies work. Heavily research the topic in order to more efficiently write "homegrown" code.

If time or complexity become an issue, consider deferring some responsibility to the "toolkit": it's likely to have an API for your problem.

Don't underestimate the power of "one-off" hand-written code. It may not be unified under a shiny namespace with slick marketing behind it, but it can still get the job done.

Above all, you need to educate your clientèle (team). Help them to understand why your position is going to work better. If you do your homework, people will benefit from your knowledge. Remain open-minded: if someone else raises a good point, compliment them on it and then research it further. Perhaps you've overlooked something.

If you want to be compelling, you need to fervently study the topic. You need to be the expert. Otherwise, you're driving with some form of blindness and will experience turbulence.

Can you give some examples of the "litany of browser issues" with jQuery? – nnnnnn Jan 14 '12 at 0:52
heck, examples of "poorly built" would be good too. Making a list of pros and cons with things like "Pros: Awesome" and "Cons: Terrible" is just a slower way to be dogmatic. I think there probably are reasons behind them, but they don't appear. Of course, this answer isn't about best practices, but how to explain them, but in the short space available those examples mostly don't follow the advice given, IMHO. But the advice is sound. – psr Jan 14 '12 at 0:58
Yeah, this answer seems more like a soapbox for JS library prejudices than really constructive in any way. – Jason Lewis Jan 14 '12 at 1:29
@psr at the very least the API is poor, I would say that classifies as the library being poorly build. – Raynos Jan 14 '12 at 2:43
I apologize for not fully elaborating on my assertions. I was in a bit of a rush leaving work. I'll edit in some links. – null Jan 14 '12 at 6:01

Ultimately, 'frontend' and 'backend' development boil down to one thing: development. Global namespace pollution? Bad. One-off implementations of already-supported functionality? Bad. Inline styles? Well, an example of either tight coupling or duplication of effort, so, bad.

The question comes down to this: Do they not understand general best practices in software development, or are they just ignorant of UI implementation technologies?

If it's the former, I'm very sorry, and I'd hate to see the backend code. In this case, they need a long sit down with The Pragmatic Programmer, Design Patterns, etc.

More likely, they're just ignorant of the capabilities of the technologies involved in UI implementation. Backend developers could (maybe?) be stuck in a mindset regarding the UI that was current ten years ago. If they're competent developers, maybe they just need to be briefed on the capabilities of the software.

Let's assume you're using jQuery, HTML5, CSS3. The good stuff. If they are actually good developers in general, they'll understand the benefits of things like dependency injection, the DRY principle, etc. This gives you an opening to discuss ideas like programming to an interface (jQuery DOM manipulation based on specified CSS selectors), DRY (use CSS ids and classes rather than inline styles), dependency injection (good place to bring up unobtrusive javascript), things they should understand, in order to argue for a give style of developing the interface.

Additionally, if you're the in-house expert on frontend development, perhaps you could suggest a code review process before changes by other devs make their way into the code base. The downside, is it's more work for you. The upside, is that you have a chance to spot the WTFs before they make it to the master branch and have a conversation about a better way of accomplishing the goal.

+1 It has nothing to do with a distinction between front-end and back-end developers. – Marjan Venema Jan 14 '12 at 9:23
@MarjanVenema Thanks. I often have a problem with this myself, so I don't usually critique the distinction; personally, I try to off-load front-end work to others as much as possible. That being said, when I make mistakes in the UI (which I certainly do), I try to recognize the root cause, and not blame the frameworks we're using. Software is software, wherever in the stack it lies. The same principles apply. – Jason Lewis Jan 14 '12 at 9:36

Not the answer you're looking for? Browse other questions tagged or ask your own question.