do we really need a front-end framework

Recently, I had to ask myself this question: "Do we really need a front-end framework?". You have likely heard about front-end frameworks like Angular, React and Vue. If you thought why and when these frameworks are used and whether it's time you implement once in your project trust me your not alone.

Put simply, a JavaScript framework is a tool that can leverage to develop advance web applications, especially Single Page Applications(SPAs).

In past days web developers would implement front end logic by relaying heavily on vanila JS add jQuery. But, as front end application became more and more complex, the tools rose to meet that complexity.

The most resistance question could be following question:

Why would we need to use Angular (or React), when we could do everything with classical HTML/CSS?

We are going to look at 4 points

1. How a front end grows 
2. The architecture problems you might encounter as it scales 
3. How a front-end framework might help address these
4. Other alternatives you might consider

front end grows

You can build a simple frontend with just HTML, CSS, and JavaScript. However, as your app scales, your files will grow along with it, filling up with unreadable and unmaintainable messy code.

For example lets say you are building Social Media web application in that you have profile page.You build the first version of this profile page with the three basic technologies, HTML, CSS, and JavaScript. it works like this:

• On the initial page load, the back end initially sends over a blank profile page with minimal styling. Then, for all other details about your posts and other things front end requests user data via AJEX.
• The back end sends over some public user data as JSON, and you use javascript to dynamically append DOM elements for posts and records on to the page.
• When you dcide to build post-specific pages that list all post and comments belongs to that post, you crate new JavaScript files that replicate much of the code, since they're drawing on the same post data.
• Each post uses the same HTML, so you store the markup in a JavaScript string and figure out a way to inject post-specific data in there, ex: "<p>{{ Post Data }}</p>". Then you append the post HTMl onto the page everytime.
• When a user updates some value on the page, you can either read data from the DOM by querying for attribute, or by attaching event listeners to every element-getting the data by reading from the DOM.

As your social platform gets popular and your data-set grows, this approach quickly becomes unwieldy:

• You find yourself appending data to the page and then reading it from the DOM by grabbing <div> values or reading ids or data attributes.
• The number of JavaScript and CSS files balloons, and there’s lots of repeated code between them.
• 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.
• When you need to make even a small change, you worry about how it’ll impact the rest of the application.
• When your friend offers to help with the development work (for some equity, of course), you spend hours explaining how your code works.

you might realize that storing your data in DOM and endlessly appending HTML stored in JavaScript strings can not be the best way to keep maintaining this project. Yeah you thought right fortunately there no need to do the same thing. You can build robust, maintainable UI, it's time for front-end framework.

Separation of concerns

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 “separation of concerns”, 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.

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.

Advantages to using a framework

  Easy and quick to get started

• They’re great for prototyping
• You can gain momentum by “getting something on the page”
• They’re handy when you’re against tight deadlines
• They provide a solid foundation for responsive design
• Components of the UI have a base style to be extended (forms, buttons, menus, etc.)
• The base styles persist throughout
• They provide a consistent UI design for developers who lack design skills, which is great for things like intranet sites or documentation
• They provide a base development for non-developers to get something up quick for prototyping or mockups

  Good looking UI, even out-of-the-box

• Components of the UI have a base style to be extended (forms, buttons, menus, etc.)
• The base styles persist throughout
• They provide a consistent UI design for developers who lack design skills, which is great for things like intranet sites or documentation
• They provide a base development for non-developers to get something up quick for prototyping or mockups

  Code is reliable and tested

• Code is widely used, especially open source
• Cross-browser compatibility is built-in, so you know where it will work

  Help is readily available

• Front-end frameworks are widely used, so answers to common problems are easy to find
• The documentation is usually thorough
• Free and professional themes and templates may be available

Disadvantages

  Abstracted, overhead code:

•  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.

  Learning curve:

• Learning to use a framework effectively takes time. To be productive, you need to understand the syntax, tooling, and 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.

  Overkill for smaller projects:

• 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.

  Setup:

• 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.

  Strong opinions:

• 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.

  Ecosystem evolution:

• The JavaScript framework ecosystem is famously volatile. The hottest framework of today may not be popular next year, and with this shift, developers and support may be hard to find.

Alternatives

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.

• Templating Engines: If all you need are reusable components, consider a templating engine like Handlebars.js, EJS, Underscore.js, or mustache. These engines allow you to store HTML/CSS/JavaScript components and insert JavaScript variables into them.
• CSS frameworks and libraries:  If you’re looking to create a consistent UI, a tool like Bootstrap, SemanticUI, Bulma, or Tailwind 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.
• Full-stack monolith apps: Many full-stack frameworks, like Ruby on Rails, Meteor.js, and Django, come with their own templating engines, which render HTML on the server. Server-side rendering and monolith 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 entire 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.