We have a lot of frontend developers leaving the company because they want to work with react, angular, npm and what not.

We use some corporate cms platforms and these javascript platforms don't provide much benefit to us. For frontend we need just css and javascript/jquery.

In the last years it has been extremely hard to find frontend developers willing to work with this stack and when we do find them they stay a short time just to learn some javascript and then leave the company because they want to work with react/angular.

In the last years every frontender leaving the company supplied this argument as the main reason for leaving the company.

How can we improve the learning environment for frontenders? Does it make sense to switch to js platforms just because it is popular and easier to hire devs?

  • 1
    Though I upvoted Ewan's answer, this question doesn't seem Software Engineering related. It's either working place or project management.
    – Machado
    Jul 28, 2017 at 12:27
  • 1
    meh, you could rephrase the question "what are the benefits of using modern js platforms" or something. I think we are too hard on these fringe questions. They can always be removed later if they don't fit
    – Ewan
    Jul 28, 2017 at 13:17

2 Answers 2


OK, so those platforms are popular for more reasons than just making coding easier.

The jobs pay more and most companies have adopted the tech. So its not benefiting these developers careers to stick with you.

  • If you adopt the tech in a limited way they will just learn it and leave.

  • Switching to the new tech, might be beneficial for the business, regardless of the impact on recruitment (i think there are a few questions on that subject you can check out)

So you really only have the normal choices of any business trying to make a job attractive

  • Up the pay
  • Up the benefits (working from home)
  • Target expensive employees who are further along in their career and want a steady job over a fast moving environment. Maybe they have started a family?
  • Target cheap employees who want to learn the basics and accept the high turn over as not a bad thing. If the job is fun for a year or two and you learn, its still a good job. You shouldn't have any problems filling it with new grads every year.

I don't understand the unexplained downvotes; +1.

If you have a long-term project (sounds like that based on the question), please don't choose whatever technology is trending now. You may find the technology trending 10 years from now is entirely different. Stay with well-chosen tools. JavaScript and CSS aren't going to go away, that's certain. jQuery is very lightweight library and it is actually quite handy, so I don't find using jQuery bad although there may be reasons to write raw JavaScript (example: in one project where I worked, updating jQuery broke compatibility, requiring major amounts of work to fix the compatibility issues). Seems like your current technology stack is good for a long-term project.

What you can do to motivate employees is to allow them to spend a certain amount of their time on researching different platform options, and perhaps to have their own projects they are permitted to work on during work time in a limited manner. This will essentially mean that you pay the same for less of work, so it can be considered to be equivalent to a salary raise. However, the additional motivation will mean you will get part of the effective salary raise back as increased working efficiency.

Who knows, perhaps by allowing them research of different platform options, you will discover some useful library you want for your current platform. Please be careful here, though. Choosing to use an external library isn't a decision to be done lightly. Also, usually a rewrite is considered bad: When is a BIG Rewrite the answer? ...so if using an external library requires a big rewrite, it's usually a bad idea.

Stay away from libraries that call themselves "frameworks". It means you will have to wrap your entire application around such a library, causing major amounts of pain if the framework development is stopped or if you wish to change to yet another framework later. Prefer libraries that affect only limited amount of your code. Do abstract the functionality provided by an external library into a simple wrapper with as simple API as possible; this means if the external library needs to be changed, you will need to rewrite only the simple wrapper, not your entire application.

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