State of JavaScript 2020
I’ve been doing web FE in various capacities for about a decade. First jQuery, then backbone, then Angular, then ClojureScript with React, now React and Apollo.<p>While I get the criticism about what might seem like an anarchic state of JavaScript, at each transition point there have been clear, demonstrable, and worthwhile changes.<p>Backbone addressed jQuery spaghetti code. Angular addressed backbone boilerplate. React addressed state complexity, and GraphQL finally forced backend engineering to coordinate with  frontend engineering (i.e., making full-stack engineering efficient).<p>People don’t switch tooling and frameworks for fun (well, not primarily), but because the pain of learning something new is worth the benefit of reducing unnecessary complexity.<p>What I don’t think non-FE engineers often appreciate is just how essentially complex user-dictated mutable state is. Even with immutable data structures (which I love), you can’t get around the fact that a web-app is, by its very nature, a canvas that changes according to human activity. The difference between FE and BE is the difference between painting with fingers and flipping a switch with fingers. Updating a user’s role on the BE is a single SQL operation, but for the FE, it might mean countless changes to the user experience. It’s the difference between storing data and using data. And if there’s anything to conclude from the overwhelming amount of work done on FE tooling, it’s not that people love to try new things (although we do), it’s that the struggle is real.<p>Side-note: BE gets a taste of FE complexity when dealing with syncing live mutable data among multiple clients. That’s a beast, and the point where everyone realizes that full-stack is the only sensible way to work.