\u003C/figure>\n\u003C!-- /wp:image -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>You build the first version of this profile page with the three basic technologies, HTML, CSS, and JavaScript. It works something like this: \u003Cbr>\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:list -->\n\u003Cul>\u003Cli>On the initial page load, the back end initially sends over a blank profile page with minimal styling. Then, and for all future loads, the front end requests user data via AJAX.\u003C/li>\u003Cli>The back end sends over some public user data as JSON, and you use JavaScript to dynamically append DOM elements for game badges and records onto the page. \u003C/li>\u003Cli>When you decide to build game-specific pages that list all the users and their records, you create new JavaScript files that replicate much of the code, since they’re drawing on the same game data. \u003C/li>\u003Cli>Each game badge (and match badge) uses the same HTML, so you store the markup in a JavaScript string and figure out a way to inject game-specific data in there, \u003Cem>ex\u003C/em>: \u003Ccode>“<p>{{Game Name}}</p>”\u003C/code>. Then, you append the badge HTML onto the page for every game.\u003C/li>\u003Cli>When a user updates some value on the page, you can either read data from the DOM by querying for attributes, or by attaching event listeners to every element—getting the data by reading it from the DOM.\u003Cbr>\u003Cbr>\u003C/li>\u003C/ul>\n\u003C!-- /wp:list -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>As MySquare gets popular and your dataset grows, this approach quickly becomes unwieldy:\u003Cbr>\u003Cbr>\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:list -->\n\u003Cul>\u003Cli>You find yourself appending data to the page and then reading it from the DOM by grabbing \u003Ccode><div>\u003C/code> values or reading ids or data attributes. \u003C/li>\u003Cli>The number of JavaScript and CSS files balloons, and there’s lots of repeated code between them. \u003C/li>\u003Cli>You’re binding event listeners to common UI elements like input fields and buttons, then writing functions to update the values in those same elements.\u003C/li>\u003Cli>When you need to make even a small change, you worry about how it’ll impact the rest of the application.\u003C/li>\u003Cli>When your friend offers to help with the development work (for some equity, of course), you spend hours explaining how your code works.\u003C/li>\u003C/ul>\n\u003C!-- /wp:list -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Managing these problems is feasible with vanilla JavaScript and enough patience. With planning and forethought, you might be able to structure your app to anticipate some of these issues. However, as your front end grows, these problems will only deepen—you can never be sure how your app is going to evolve. \u003Cbr>\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>You realize that storing your data in the DOM and endlessly appending HTML stored in JavaScript strings can’t be the best way to tackle this project. Fortunately, there’s no need to reinvent the wheel. When you find yourself needing to build a robust, maintainable UI, it’s time for… you guessed it! A front-end framework.\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:heading -->\n\u003Ch2>Enter, framework\u003C/h2>\n\u003C!-- /wp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Front-end frameworks exist because for many apps, the front end grows and strains in predictable ways. While each popular framework offers its own design philosophy, they are all attempting to solve the same general problems we encountered earlier:\u003Cbr>\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:list -->\n\u003Cul>\u003Cli>Your code should be maintainable: easy for you and others to read, test, and change.\u003C/li>\u003Cli>Complex interfaces are usually made of the same components. You should be able to create and reuse these components to easily create new pages.\u003C/li>\u003Cli>Since DOM manipulations are slow, you want to perform as few element updates as possible.\u003C/li>\u003Cli>You should be easily able to manipulate your UI based on data.\u003C/li>\u003Cli>Your UI should be consistent and intuitive; this means standardizing typography, color, buttons, inputs, and other elements.\u003C/li>\u003Cli>You shouldn’t need to reinvent the wheel and write tons of boilerplate when it comes to solving these common front-end challenges.\u003C/li>\u003Cli>You should have a common language through which to communicate your ideas and patterns with other developers.\u003C/li>\u003C/ul>\n\u003C!-- /wp:list -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Different frameworks address some, but usually not all, of these questions. Some, like \u003Ca href=\"https://getbootstrap.com/\">Bootstrap\u003C/a> and \u003Ca href=\"https://semantic-ui.com/\">SemanticUI\u003C/a>, focus on creating readable, maintainable HTML and CSS, emphasizing consistent visual design. Others, like \u003Ca href=\"https://vuejs.org/\">Vue\u003C/a>, \u003Ca href=\"https://reactjs.org/\">React\u003C/a>, and \u003Ca href=\"https://angularjs.io\">Angular\u003C/a>, triumph at structuring data flow throughout your application, allowing you to focus on manipulating the data rather than the DOM.\u003Cbr>\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>(\u003Ca href=\"https://twitter.com/sarah_edo\">Sarah Drasner\u003C/a> has \u003Ca href=\"https://www.smashingmagazine.com/2018/02/jquery-vue-javascript/\">a fantastic introduction\u003C/a> that demonstrates the difference between reading data from the DOM and storing it in JS. Although her example discusses the switch from jQuery to Vue, you can read it as a broader mindset shift from DOM manipulation to focusing on data structures.)\u003Cbr>\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>What would MySquare look like if you implemented a popular front-end framework, like React? Here are a few changes you would experience:\u003Cbr>\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:list {\"ordered\":true} -->\n\u003Col>\u003Cli>You would create reusable HTML/CSS/JavaScript components with data placeholders for the game badges, match records, and other common elements. The framework would then render these elements based on incoming data (the JSON we get from the server or APIs). For example, if the JSON has nine game records, we render nine \u003Ccode><Match>\u003C/code> components, with match data automatically inserted.\u003C/li>\u003Cli>You would follow the boilerplate directory structure to create components, scripts, and stylesheets in a way that’s easy to follow and maintain. Need to make a change to the structure and styling of game records? Find the small, standalone \u003Ccode><Match>\u003C/code> component and make your changes.\u003C/li>\u003Cli>You would be able to take advantage of most recent JavaScript features as well as a CSS-preprocessor like SASS to write concise, expressive, modern code. The framework will transpile this to the HTML/CSS/JavaScript that browsers understand.\u003C/li>\u003Cli>With this infrastructure in place, you could focus on manipulating the data instead of worrying about the DOM. Our framework’s data-binding features will automatically re-render the relevant components when the data changes. For example, if you receive data on a new match result from the server, the framework will automatically append another \u003Ccode><Match>\u003C/code> component onto the screen.\u003C/li>\u003Cli>If you found yourself stuck on a problem, you could leverage the framework community to get help. It should even be easier to explain your problem since you’re following framework conventions that help build popular front-end features.\u003C/li>\u003Cli>Because popular frameworks often follow similar design principles, it would be easier to collaborate with other developers, even those who don’t develop in your specific framework—you wouldn’t need to walk new developers through your own custom code structure.\u003C/li>\u003C/ol>\n\u003C!-- /wp:list -->\n\n\u003C!-- wp:heading {\"level\":3} -->\n\u003Ch3>Separation of concerns\u003C/h3>\n\u003C!-- /wp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Ideally, you would want your front end to operate as a standalone application, requesting data from the back end, processing, and displaying it (you might hear this called “consuming an API”). The principle underpinning this is referred to as “\u003Ca href=\"https://en.wikipedia.org/wiki/Separation_of_concerns\">separation of concerns\u003C/a>”, and it states that each part of your program should operate independently, have a clear, singular purpose, and communicate via a well-defined interface. Although your front end doesn’t have to implement a framework to follow the separation of concerns principle, most frameworks encourage this architectural pattern.\u003Cbr>\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>The advantage to the resulting modular design is that developers can work on different parts of your application independently as long as their component accepts predictable inputs and delivers predictable outputs. Having a front end with a single responsibility (made up of modular components that follow the same principle) makes it easy to adapt to change. If you decide to move from Angular to React, for example, you can do so confidently; both frameworks expect data from the back end, so you can focus on how React’s interface receives that data and how it uses it, not how the front end is embedded in your larger application.\u003Cbr>\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>As the dedicated view layer of your application, your front end should be solely responsible for logic around: \u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:list -->\n\u003Cul>\u003Cli>which elements should be displayed or hidden\u003C/li>\u003Cli>when to request data or send updates to the server\u003C/li>\u003Cli>when to display simple validation and error messages\u003C/li>\u003Cli>which styling choices to make based on data\u003C/li>\u003C/ul>\n\u003C!-- /wp:list -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Here are two MySquare scenarios: one where the architecture follows separation of concerns, and the other where it violates it. See if you can figure out which is which!\u003Cbr>\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:list {\"ordered\":true} -->\n\u003Col>\u003Cli>The back end sends over a list of game records; each record contains a score, names of two players, and the match date. The front end appends an HTML component for each match, with a red or green background color, depending on who won the match.\u003C/li>\u003Cli>The back end sends over a list of game records; each record contains a score, names of two players, the match date, and a color hex code for winning/losing match styling, calculated based on which profile is requesting the code. The front end adds a component per match, styling it with the background color sent over by the backend.\u003C/li>\u003C/ol>\n\u003C!-- /wp:list -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Did you catch the violation? The back end shouldn’t be concerned with styling. That logic should live in the front end, which determines \u003Cem>how\u003C/em> data is displayed. If your designers want to spruce up the MySquare design, they shouldn’t need to worry about data structures.\u003Cbr>\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:heading {\"level\":3} -->\n\u003Ch3>Advantages to using a framework\u003C/h3>\n\u003C!-- /wp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Let’s recap the major ways in which adopting a front-end framework will help our quickly growing app:\u003Cbr>\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:list {\"ordered\":true} -->\n\u003Col>\u003Cli>\u003Cstrong>Maintainability\u003C/strong>: Breaking up your app into reusable, standalone components makes it easier to make quick changes that don’t impact the rest of the application. \u003C/li>\u003Cli>\u003Cstrong>Separation of concerns: \u003C/strong>Modern framework design encourages a maintainable, modular architecture and allows your front-end developers to focus on what they do best: taking data and displaying it to users in an intuitive and efficient way. \u003C/li>\u003Cli>\u003Cstrong>Speed: \u003C/strong>Boilerplate code aimed at addressing common problems makes it easier for you to get your app up and running; component-based design makes it quicker to develop.\u003C/li>\u003Cli>\u003Cstrong>Collaboration: \u003C/strong>Since frameworks often follow similar design patterns, it’s easier for developers who are new to your codebase to develop and maintain your app.\u003C/li>\u003Cli>\u003Cstrong>Community:\u003C/strong> Popular frameworks have a community of people around them with dedicated tutorials, forums, meetups, and generally supportive developers you can seek help from. \u003C/li>\u003C/ol>\n\u003C!-- /wp:list -->\n\n\u003C!-- wp:heading -->\n\u003Ch2>Disadvantages and alternatives\u003C/h2>\n\u003C!-- /wp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Of course, like any tool, a front-end framework isn’t always the right solution for your application. Here are a few factors to consider before implementing one.\u003Cbr>\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:heading {\"level\":3} -->\n\u003Ch3>Disadvantages\u003C/h3>\n\u003C!-- /wp:heading -->\n\n\u003C!-- wp:list {\"ordered\":true} -->\n\u003Col>\u003Cli>\u003Cstrong>Abstracted, overhead code: \u003C/strong>Until you’re thoroughly familiar with it, framework code is a black box. It can be hard to discern how much of the code is helpful to your application and frustrating to fix bugs resulting from code you’re not familiar with.\u003C/li>\u003Cli>\u003Cstrong>Learning curve: \u003C/strong>Learning to use a framework effectively takes time. To be productive, you need to understand the syntax, tooling, \u003Cem>and\u003C/em> philosophy behind how a framework functions. For projects where speed is essential, learning a brand new technology might not be the best use of your time.\u003C/li>\u003Cli>\u003Cstrong>Overkill for smaller projects: \u003C/strong>If you’re looking to deploy a static site or a site where every component is unique, you might not need the power and overhead of a full-fledged framework. It might still be helpful to implement a minimal framework or even library—we’ll discuss these in the next section.\u003C/li>\u003Cli>\u003Cstrong>Setup: \u003C/strong>Setting up and customizing a framework to your specific use case takes time. If speed is essential, go with what you know, or what your development team is comfortable with.\u003C/li>\u003Cli>\u003Cstrong>Strong opinions:\u003C/strong> An opinionated framework may feel constricting, and its design principles may clash with yours. Make sure you research the specific framework you’re implementing. If you prefer to build from scratch, go with your own solution.\u003C/li>\u003Cli>\u003Cstrong>Ecosystem evolution: \u003C/strong>The JavaScript framework ecosystem is \u003Ca href=\"https://stackoverflow.blog/2018/01/11/brutal-lifecycle-javascript-frameworks/\">famously volatile\u003C/a>. The hottest framework of today may not be popular next year, and with this shift, developers and support may be hard to find.\u003C/li>\u003C/ol>\n\u003C!-- /wp:list -->\n\n\u003C!-- wp:heading {\"level\":3} -->\n\u003Ch3>Alternatives\u003C/h3>\n\u003C!-- /wp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>There are a few alternatives to large JavaScript frameworks like Vue, React, and Angular. As we mentioned earlier, different front-end frameworks attempt to solve different problems. Depending on your needs, smaller frameworks and libraries may work for you. Additionally, you could abandon separation of concerns and go with a monolith full-stack app with server-side rendered views. Here are a few alternatives to consider:\u003Cbr>\u003Cbr>\u003Cstrong>Templating engines\u003C/strong>: If all you need are reusable components, consider a templating engine like \u003Ca href=\"https://handlebarsjs.com/\">Handlebars.js\u003C/a>, \u003Ca href=\"https://ejs.co/\">EJS\u003C/a>, \u003Ca href=\"http://underscore.js\">Underscore.js\u003C/a>, or \u003Ca href=\"https://github.com/janl/mustache.js\">mustache\u003C/a>. These engines allow you to store HTML/CSS/JavaScript components and insert JavaScript variables into them. I mentioned struggling with how to scale my project, Hackterms, at the start of this article. In retrospect, I absolutely should have used a full-fledged framework. However, at the time, I was short on time and patience, so I successfully used Handlebars to create reusable templates.\u003Cbr>\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>\u003Cstrong>CSS frameworks and libraries\u003C/strong>: If you’re looking to create a consistent UI, a tool like \u003Ca href=\"https://getbootstrap.com/\">Bootstrap\u003C/a>, \u003Ca href=\"https://semantic-ui.com/\">SemanticUI\u003C/a>, \u003Ca href=\"https://bulma.io/\">Bulma\u003C/a>, or \u003Ca href=\"https://tailwindcss.com/\">Tailwind\u003C/a> might be a good option. Someone once described using a CSS framework as “having a designer looking over your shoulder, nudging you towards good practices.” You don’t have to inherit the \u003Cem>visual\u003C/em> design of these frameworks, but for a developer without a strong design background, it can be really helpful to know how many fonts to use, what different button states are, and what intuitive forms look like.\u003Cbr>\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>\u003Cstrong>Full-stack monolith apps:\u003C/strong> Many full-stack frameworks, like \u003Ca href=\"https://guides.rubyonrails.org/action_view_overview.html\">Ruby on Rails\u003C/a>, \u003Ca href=\"https://www.meteor.com/tutorials/blaze/templates\">Meteor.js\u003C/a>, and \u003Ca href=\"https://docs.djangoproject.com/en/3.0/topics/http/views/\">Django\u003C/a>, come with their own templating engines, which render HTML on the server. \u003Ca href=\"https://stackoverflow.com/a/33953973\">Server-side rendering\u003C/a> and \u003Ca href=\"https://stackoverflow.com/questions/45661006/what-is-the-difference-between-monolith-and-n-layer/45661246#45661246\">monolith\u003C/a> architecture are both concepts that deserve their own blog posts, but you can think of this option as picking one full-stack framework for your \u003Cem>entire\u003C/em> application and writing the presentation layer and server logic within a single codebase. Most full-stack frameworks do allow you to plug in front-end frameworks of your choice, but default you to using their own templating engines. This is a good solution if you want to double down on using a single framework for your entire app; it can also be a quick way to prototype a full-stack application.\u003Cbr>\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:heading -->\n\u003Ch2>In conclusion\u003C/h2>\n\u003C!-- /wp:heading -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Front-end frameworks are a powerful tool for developing complex user interfaces. They encourage you to build out a maintainable, modular, standalone architecture that makes it easy to build your application and collaborate with other developers. Popular frameworks are backed by supportive communities, a wealth of documentation and tutorials, and offer battle-tested code that tackles common challenges that front ends pose as they scale. Frameworks allow you to tap into the most modern JavaScript features and offer tooling that makes it easy to prototype apps. Finally, they empower you with a shared language to discuss your architecture and challenges.\u003Cbr>\u003Cbr>\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>Front-end frameworks and libraries come in many shapes and sizes—you can use a full-fledged UI framework to build out your entire front end, implement a CSS library to tighten your visual design, or use a templating engine to create reusable components.\u003Cbr>\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>However, a front-end framework can be overkill for smaller projects and prototypes, and the steep learning curve, coupled with the quickly evolving JavaScript ecosystem, can make it difficult to implement in a young project. At the end of the day, you should implement a popular framework if you’re excited to learn about well-tested design principles, expect your front end to scale, or need to prototype quickly when performance isn’t a major concern. If you like thoroughly understanding every part of your application, or don’t want to learn a new technology, then it’s probably not the best option.\u003Cbr>\u003Cbr>Hopefully, this overview has given you an idea of the problems a front-end framework solves, and whether it’s the right fit for your next project. What has your experience with front-end frameworks been like? Which is your framework of choice? Looking forward to your comments below!\u003C/p>\n\u003C!-- /wp:paragraph -->\n\n\u003C!-- wp:paragraph -->\n\u003Cp>\u003Cbr>\u003Cem>Many thanks to \u003C/em>\u003Ca href=\"http://jamesmayr.com\">\u003Cem>James Mayr\u003C/em>\u003C/a>\u003Cem> and \u003C/em>\u003Ca href=\"https://www.linkedin.com/in/laurenrisberg/\">\u003Cem>Lauren Risberg\u003C/em>\u003C/a> \u003Cem>for reviewing this article, catching many errors, and making great suggestions.\u003C/em>\u003Cbr>\u003C/p>\n\u003C!-- /wp:paragraph -->","html","2020-02-03T15:10:33.000Z",{"current":1261},"is-it-time-for-a-front-end-framework",[1263,1271,1276,1280,1284,1289],{"_createdAt":1264,"_id":1265,"_rev":1266,"_type":1267,"_updatedAt":1264,"slug":1268,"title":1270},"2023-05-23T16:43:21Z","wp-tagcat-bulletin","9HpbCsT2tq0xwozQfkc4ih","blogTag",{"current":1269},"bulletin","Bulletin",{"_createdAt":1264,"_id":1272,"_rev":1266,"_type":1267,"_updatedAt":1264,"slug":1273,"title":1275},"wp-tagcat-code-for-a-living",{"current":1274},"code-for-a-living","Code for a Living",{"_createdAt":1264,"_id":1277,"_rev":1266,"_type":1267,"_updatedAt":1264,"slug":1278,"title":1279},"wp-tagcat-front-end",{"current":1279},"front-end",{"_createdAt":1264,"_id":1281,"_rev":1266,"_type":1267,"_updatedAt":1264,"slug":1282,"title":1283},"wp-tagcat-javascript",{"current":1283},"javascript",{"_createdAt":1264,"_id":1285,"_rev":1266,"_type":1267,"_updatedAt":1264,"slug":1286,"title":1288},"wp-tagcat-stackoverflow",{"current":1287},"stackoverflow","Stackoverflow",{"_createdAt":1264,"_id":1290,"_rev":1266,"_type":1267,"_updatedAt":1264,"slug":1291,"title":1293},"wp-tagcat-web-dev",{"current":1292},"web-dev","web dev","Does your web app need a front-end framework?",[1296,1302,1308,1310],{"_id":1297,"publishedAt":1298,"slug":1299,"sponsored":12,"title":1301},"1b0bdf8c-5558-4631-80ca-40cb8e54b571","2025-08-21T14:00:25.054Z",{"_type":10,"current":1300},"research-roadmap-update-august-2025","Research roadmap update, August 2025",{"_id":1303,"publishedAt":1304,"slug":1305,"sponsored":12,"title":1307},"5ff6f77f-c459-4080-b0fa-4091583af1ac","2025-08-20T14:00:00.000Z",{"_type":10,"current":1306},"documents-the-architect-s-programming-language","Documents: The architect’s programming language",{"_id":16,"publishedAt":17,"slug":1309,"sponsored":12,"title":20},{"_type":10,"current":19},{"_id":1311,"publishedAt":1312,"slug":1313,"sponsored":12,"title":1315},"f0807820-02d7-4fc5-845f-3d76514b81c0","2025-08-11T16:00:00.000Z",{"_type":10,"current":1314},"renewing-chat-on-stack-overflow","Renewing Chat on Stack Overflow ",{"count":1317,"lastTimestamp":1318},55,"2025-06-02T14:02:44Z",["Reactive",1320],{"$sarticleModal":1255},["Set"],["ShallowReactive",1323],{"sanity-ygcKB-1N7eOpPa-r47yDpU_uakCGy2z262vvRqmAKos":-1,"sanity-comment-wp-post-14904-1755853918114":-1},"/2020/02/03/is-it-time-for-a-front-end-framework"]