Front-end often has longer data transformation pipelines than back-end, and that leads to the complexity you mention. If you treat it as a programming problem,

Front-end often has longer data transformation pipelines than back-end, and that leads to the complexity you mention. If you treat it as a programming problem, you can write better front-end code by shoring up on your ability to compose, glue, and modularize code. You also need a way to represent front-ends as a data structure rather than a sequence of imperative actions. Data is easier to think about - imagine if instead of HTML you had to write imperative code to paint everything on the screen - that kind of code can get tangled up easily and make it difficult to understand or modularize the code. In this vein, using a library that lets you think of the front-end as data ('declarative') rather than imperative DOM mutation (with jQuery etc.) is an important thinking tool. A way to short-circuit the amount of learning associated with this is to pick-up tools that have already reified this knowledge, so that by learning the tool you pick up the many mental models they embody. I suggest either Reason (with ReasonReact) or Elm as great starting point. Pursue their homepages, toss a coin, pick the one that appeals to you on first blush. Both these languages are typed functional languages. Types here are tools of thought - especially the ability to represent data as One of Many (sum types) - will forever add a dimension to the way you model data. Functional programming is a toolkit of methods that let you compose and glue code together, and while it wouldn't appear that they attack the problems you're facing head on (should I add yet another conditional here, or should I extract another function that looks almost the same vs DRY etc.), those are exactly the problems you'll be able to confidently answer after you've practiced in this paradigm for a while.