In the JavaScript world of today, getting a front-end application up-and-running has never been simpler. Load up your preferred package manager, install a command line interface (CLI) for the framework of your choice, punch in a few commands, and boom – you’ve got a full-fledged web application, complete with routing, styling, a modern build tool, automated testing frameworks, and far more. What now takes a morning to do, used to take weeks or even months to accomplish with a full development team. For someone new to JavaScript, it may seem like going straight to one of these frameworks is a no-brainer, but my experiences working with a legacy JavaScript codebase have convinced me that going back to the “stone ages” and learning from the ground up will make you a better developer today.
How Things Work
JavaScript frameworks today are generally encompassed under one brand name (for example, “Angular”) and often come with an opinionated CLI tool (for example, “Angular CLI”), which handle lots of the configuration plumbing for you. These CLIs are huge productivity boosts for development teams who need to focus less on wiring pages up and more on implementing business requirements, but as your application grows in size, you will start to run into issues that require more than just “[insert framework here]” knowledge. Modern JavaScript frameworks are built largely using concepts, technologies, and plugins that have existed for years, and many common issues you’ll see while developing are completely independent of the framework you’re using.
For me, working on an “old school” front-end forced me to learn the basics of web programming and how all the pieces of the puzzle fit together. How do JavaScript files interact with their respective HTML templates and CSS stylesheets? How does the browser know which files should be served, and how does it read those files? What are JavaScript “modules”, and why are there so many ways to import or export them? Modern CLIs do a great job of protecting developers from complex configuration (which is a good thing!), but in just about every enterprise application, you will eventually need to dig in and tinker with the inner workings. I found that the process of modernizing an existing legacy front-end gave me a deep understanding of how things work, which has allowed me to be more knowledgeable and productive as a modern JavaScript developer.
Latest Is Not Always Greatest
Software developers come from many different backgrounds, and each person brings unique ideas to the table, but the one thing we all can agree on is our greatest fear: not being able to find the answer to our painstaking coding problem on StackOverflow. Running into issues and not being able to find a quick, applicable solution can derail your work day, and no one ever wants to get stuck creating hacks and workarounds to make up for bugs in third-party libraries.
One of the best lessons I learned while re-tooling a legacy front-end is to invest time up front researching and evaluating potential packages before getting too far into the implementation process. Cutting edge technology can be incredible, and often can accomplish things that no tools before it could, but that doesn’t always mean things will be smooth sailing.
As with any new software, it takes time to iterate, evolve, and work out the kinks, which is why I’ve become hesitant to jump aboard the latest and greatest JavaScript has to offer. Thorough documentation takes time to assemble, and the early stages of new tools tend to be very volatile. Trying to develop your own application while playing catch-up with a plugin in its infancy spells trouble, and this often leads down a path that many teams can’t afford to take. One way to tell if a tool is right for you is to explore the community around it. Is it actively maintained on GitHub? How often is it downloaded on npm or yarn? Does it seem to have active support on StackOverflow? This process is something I now do each time I decide to incorporate a new tool in a project, and it ultimately results in more time developing and less time reconfiguring.
The Big Picture
As a developer, it can be easy to get lost in the details of a new feature you’re coding without stepping back and assessing the bigger picture. When you start working on a project from scratch, poor architectural or design decisions are less likely to surface as roadblocks while things are small-scale. Over time, however, projects and teams grow, and those decisions become much more prominent. Working with a massive legacy application helped me rethink my approach on a day-to-day basis, giving me the holistic perspective I needed to make smart decisions. Enterprise applications must be built to last; overlooking things like performance, security, automated testing, and developer experience will undoubtedly set you and your team back down the road.
In Summary
While “legacy modernization” might not have the flashiest sound to it, going back to the basics of JavaScript and learning how things were in the past can teach you how things work now and why they work that way. JavaScript evolves quickly, so investing time in its roots will better equip you to keep up with future tools and frameworks. You will feel far more confident in yourself as a developer and teacher, and, if nothing else, it will help you appreciate the astonishing leaps and gains that the JavaScript community has made in the past decade!
For more on the topic, check out Doguhan Uluca’s talk from NG-Conf, “Do More With Less”.