You have a brilliant idea. You have a source of funding. All you need now is to hire people to make it for you. You need developers. Or, a developer. Or a team? Actually, come to think of it… how many people 

Let's start with the extreme. What if we told you that you don't need a developer at all?

If you look around the web, you can find dozens of frameworks for building an app. Some of these are code frameworks and environments, but others are what is known as "no-code platforms." A no-code platform is, essentially, a what-you-see-is-what-you-get, drag-and-drop editor. It has code under the hood, but the code is rendered into discrete modules.

You can add, remove, customize, and play with these modules, putting them together into an environment and an app. When you're done, you hit export, and the code for your app simply appears, compiled, and ready to go. At no point do you actually need to touch the code yourself.

Technically, you don't even need a developer to make an app. A simple enough app, anyway.

Is this going to be a viable option for you? Well, to be honest, probably not. No-code platforms that work well are fairly rare, and most of them still require at least a little bit of knowledge of development.

There are pros and cons to no-code and low-code development, 

. It's a viable option for some of you, certainly, but it's not going to be the best choice for most people.

The second option is to run with the bare minimum number of people. Salaries are expensive, and this way, you don't have to worry about the "too many cooks" issue. You can hire a rockstar developer or two, let them work away at your app, and eventually produce something precisely what you want it to be.

Most of the time, this is the domain of a startup. You want to be agile, you want to minimize the downtime associated with discussions and meetings, and you want to get a 

This model of development is one you can get away with only having one or two developers on staff.

With standard app development, you have a long, slow development cycle. You come up with an idea, pin down the details, and send it to your team of developers. They make several options, present them to you, and those options are discussed. You might even focus group them to see which ones appeal most to your target audience. You probably have other people with oversight, like compliance officers and user experience experts, taking a look as well.

Then, you implement the chosen solution and move on to the next phase of development. It's slow, it's clunky, and it's time-consuming.

With a skeleton crew, you can be much more agile. Instead of testing and getting feedback internally, you put out an MVP and get feedback from actual users. Their feedback guides your revisions and changes, as you build up your app to have more and more features.

This option is the most agile but not necessarily the fastest if you're not using an MVP model. Even if you are, you're fully reliant on one or two developers. What happens if, say:

Your developer is hit by a car while biking to work.

Your developer comes down with the flu and is taken out of work for a week.

Your developer doesn't know how to do something the right way.

All of these can lead to significant delays and drawbacks (and they're all just examples, of course.) For that matter, your developer could receive a better offer elsewhere and decide to jump ship, leaving you struggling to find someone to replace them. It's never a good thing to have all of your institutional knowledge stored in one brain; that brain might disappear from your ecosystem at the drop of a hat.

If you don't want to work with an MVP model, or you want a slower-but-steadier development process, or you want redundancy, or you just want a more traditional development model, you're going to go with a larger team.

A larger development team is going to run you around 5-6 people, depending on how much redundancy you want. Remember, if you have too many people, you'll run into the "too many cooks" problem, where they start to interfere with one another and slow the whole process down.

A scaled team will generally have numerous employees with specific tasks. You won't just hire two "full stack developers," you'll need to hire people with specific roles. For example:

, who organizes the rest of the team, assigns tasks, manages deadlines, and handles issues as they arise. You might be able to do this yourself, but a skilled project manager can be worth their weight in gold.

. UI and UX are slightly different; a User Experience expert will oversee the overall top-down view of your app to discuss the flow of users and functions, while the User Interface expert will get deeper into the weeds of details like button order/size/shape and accessibility. Sometimes, one person can do both roles. Sometimes, you need two people to handle this task.

. This is the person responsible for making the customer-facing, front-end portion of your app. They're the one working with the JavaScript frameworks, putting together the interface elements that are reviewed by the UI/UX staff, and generally making everything your customers will see.

. This is the person with SQL/PHP, Ruby, or another back-end coding language experience. They handle the cloud, API networks, and other infrastructure necessary for your app to run. They need to work closely with the front-end developer (and in some cases can be the same person if you're hiring a full stack developer). Without them, your app can't function.

. Too many app developers leave QA to the end, and think of it in terms of bug hunting and break/fix. Real QA is more in-depth, however, and can involve anything from accessibility in design to adherence to design conventions to security audits and reviews. QA can be extremely important to ensure that your app doesn't get hacked, among other things.

. If you want your web app to work on iOS and Android devices, either as a native app or as a web app, you might need a developer specific to those environments.

That's a development team of about six people. Sometimes you'll need more than one person in a given role, but even doubling up on all of them leaves you at a team of 12, and you generally won't need to double up on project managers. Instead, consider adding in a DevOps Engineer, someone to manage the communication between your software and IT teams. An even dozen people in a development team is pretty large, but half a dozen people isn't unreasonable, especially for a startup.

As your app grows and your business gets larger – and especially once you have a product on the market and want to invest in improving it – you invest more in your development team.

Each role listed above becomes a department instead. You'll have an overarching project manager, but then you'll have managers for each department, including development, UI/UX, QA, and more.

Generally, you build up to the point. You don't go into development expecting to put together a team of dozens of people. You build your app, and as you find that your teams are reaching their breaking point and have too much work on their plate, you hire someone else to add to their team.

Your developers become senior developers, and you hire junior developers to work with them. Your QA team becomes QA leads, and you hire more ground-level QA workers to test. Your mobile development becomes a full porting team.

This is how larger companies work. A company like Google will have a Search team, Gmail team, Docs team, and so on. Each of those teams will be comprised of anywhere from half a dozen people to dozens or hundreds, depending on how large, complex, and fragmented the development process is.

The same goes for pretty much any large tech company. Netflix doesn't have "the encoding guy"; they have a team working on it. Microsoft doesn't have one person dedicated to designing new features for Azure; they have a whole team working on it. Amazon doesn't have one person working on their search; they have a search team.

99% of the time, you won't have the funds to jump into this. It's the deep end of development, and it's only something you can reach after you've proven your app can be successful and support itself. If you're relying on venture funding and early adopters, it's another story.

Is this ideal? Maybe, maybe not. Some fantastic apps have been created and supported by small teams. More importantly, larger teams bring with them a whole host of issues, including:

Needing much more management, including a whole layer of middle management.

A lot more time investment, especially in communication via meetings and discussions within teams and between teams.

A ton of investment in communication, because a disconnect between two teams 

More of everything else. More directors, more HR staff, more people managing payroll, more of all of it.

Rome wasn't built in a day, and neither is a global corporation. You need to grow to get there over time. Luckily, the internet is full of scaling systems these days, so you can start small with subscriptions to AWS or Azure and a couple of developers, and build from there.

What happens if you have an app idea that will require a team of 18 people, no matter how you slice it, but when you run the numbers, you only have the budget for six? How can you handle developing your app?

You can cut back on features, prune down your minimum viable product until there's barely anything there, and hope you can attract enough attention with it to spin up and build out. If you can't simplify your idea, though, you don't have much leeway.

You can take to the freelance markets and hire the cheapest possible people for every role. Unfortunately, this also means you're likely getting people who flake out or who barely have any idea of what they're doing. Your product will be inefficient, sub-par, and might not even work right.

You can spend months, or even years, running the fundraising circuit. You go to conventions, hoping to sell your idea to venture capital firms or to angel investors. You can, eventually, pull in enough money to get what you need spun up. On the other hand, you might end up with too little interest to ever fund your dreams, and spend your life going from convention to convention with nothing to show for it.

Or, you can hire a company like ours. We're a development company with a staff of talented, trained developers capable of handling pretty much anything you can dream up. Whether you have a small MVP idea or a larger app that needs more investment, we can build it for you.

All you need to do is reach out and contact us today. We'll have a chat about what we can do for you, how many people we can assign to the task, and how much it'll cost. We bet we can provide a better alternative than trying to put together the ideal development team yourself. Additionally, if you simply have any questions or concerns about the web app development process, we would be more than happy to assist you with those however we possibly can! So, why not give us a call or 

 today? We're ready to get going at a moment's notice!

How Many Developers Do You Need to Build Your Web App?

There are two general styles of developing apps, programs, webpages, and live services. As you might infer from the title, they are low-code and high-code.

High-code is what you might think of as "traditional" development. A person or a group of people sit down and type out the code they're using for the application they're creating, whatever that application may be.

It could be anything from a simple Hello World script or a webpage with just a bit of text on it to some of the most complex software on the planet.

Low-Code is a means of development where you use tools and pre-made modules to perform the functions you want.

Consider something like cooking a meal. In high-code development, you might gather all the ingredients to make a broth from scratch, bake your bread, and cook a meal using base ingredients. (For a more extreme example, you might start by growing your grain and vegetables or raising the animal you use for meat.)

A low-code version would be buying a can of soup as an ingredient in a casserole or purchasing a boxed mix to bake bread in a "just add water"-style product.

One might have a tastier or more customized meal than the other, but many people might not care about the difference.

You don't always need to reinvent the wheel. When you want to develop an application, should you code a button from scratch or use a code snippet someone else made that includes all of the button's functionality, and you tie it to the action you want to have to happen when the button is pressed?

Low-code development can happen by using code snippets or using tools or platforms that have the functionality built into them. You might use a tool to build an application or webpage without ever looking at code directly. You might still need to interact with code to make the elements work together and code your functionality around them.

What Are the Benefits of Low-Code Development?

Low-code development comes in several forms, but they all share more or less the same array of benefits, with more emphasis on some over others depending on the angle. So, what are those benefits?

It can dramatically speed up how quickly you can develop a product.

At the barest minimum, typing in code takes time compared to copying and pasting the same code from another source or dragging and dropping a module that has that code in the back end in a visual editor.

Depending on how widespread the modules and functionality you're looking to use are, you might be able to make an entire app using nothing more than pre-existing code snippets.

In other cases, you might need to use manual coding for some features, but do most of your framework and elements using pre-developed modules and snippets.

Some estimates place the speed of low-code development at as much as 10x faster than traditional high-code development processes. Between templates, feature modules, and standardization, a business can bring a new idea to market significantly more quickly.

This process also facilitates a more agile and responsive business. You can, for example, combine a low-code development process with a 

This strategy allows you to build a small, functional app, test it with an audience, receive feedback, and make changes in a shorter time than it would take to develop the MVP in a traditional high-code environment.

It helps minimize the incidence of errors and bug-fixing.

Copying and pasting (or using a module or template in a visual interface, which is practically the same) is a lossless code transfer. Even if you were to re-type the code manually, you might make errors.

Developing a helpful code snippet from scratch is even more prone to errors, both manual typo variety, and tactical functionality variety. There might be anything from a misplaced semicolon to an unexpected behavior you didn't plan for.

When using a code snippet, someone else (or many others) has already thought of, tested, improved, optimized, and expanded that module. It does what it needs to do, with whatever failsafe or backups it needs, and it works consistently every time.

Many development platforms use large libraries of modules, all of which work consistently and are tested to work together without bugs or errors. Some more expansive environments may leave more room open for issues you would need to troubleshoot or bugfix, but even that is much less of a burden than engineering everything from scratch.

It lowers the barrier to entry for your development team.

Depending on your choice of environment, developers can be both expensive and hard to find. Suppose you need an expert with years of experience in a particular language, framework, or background. In that case, they may be hard to find as they are in high demand and command a high salary due to the rarity of their skills.

When using a low-code development platform, you dramatically lower entry barriers. Your developers don't need to have exacting, specific knowledge of the code; they need to understand the core principles and functionality of programming in the environment. You can have developers who virtually never interact with code directly, and they will still be perfectly adequate developers.

Since the skill floor is lower, the base salary for your development team is too. You save money and can hire more people to work on the application from different angles simultaneously. You also save money on the speed of development, as mentioned above.

You have tighter integration with the user experience design.

Part of developing a new app, program, or website is the user experience. In traditional development, your coders might not have much experience with UX design, so you need to hire people with specific knowledge of user experience to change and optimize or skin the program from scratch.

Conversely, when you're working in a low-code environment, most modules will include the functionality and a template of how it can look. They might have skins you can assign, or you might easily code them to use CSS in an intuitive or centralized way. They may also have a tool designed for you to edit directly in a WYSIWYG style, again without touching the code directly.

All of this results in not just a faster development cycle but better-looking beta apps and trial versions in your MVP.

It can facilitate cross-platform accessibility.

Many low-code platforms can export a finished project in a form that works on multiple devices or ecosystems. In the case of web apps, they will function on any device – PC, Mac, mobile – that can access the internet. For more traditional apps and software, often, these low-code environments enable you to export versions for multiple platforms, using alternative versions of modules and code snippets.

In traditional development, if you want to have a PC version of an app, a Mac version, an iOS version, and an Android version, you'll need to make it web-based, or you'll need to make 

of 3-4 different versions of the app. You'll need these variations because each different environment uses different kinds of code, different dependencies and libraries, and different arrays of available functionality. In many cases, the features available in one ecosystem won't be usable in another.

Are There Drawbacks to Low-Code Platforms?

While these advantages are very potent, don't fall for the hype of thinking that low-code environments are universally better for development.

There are several noteworthy drawbacks to using low-code platforms or systems as well.

"Low-code isn't the future of code. It certainly has a place in the future and will be leveraged to make many applications. It will not replace other ways of creating software because low-code breaks down when the solution's complexity increases. We saw the same thing with Visual Basic in the '90s. VB was valuable, and a lot of software was written in VB. In the end, it was the complexity required by some applications that caused VB to break down and no longer be a good solution. Low code will be the same." – Thomas Stiehm, CTO of Coveros, via 

You may be constrained to just what the platform allows, limiting your functionality.

One of the most significant drawbacks to low-code development is the same as one of its best features: constrained functionality.

The use of code modules and drag-and-drop editors means it's easy to throw together something that works in a minimal amount of time. This process is incredibly beneficial for agile development and MVP modalities, but it falters when you want to do something that the platform doesn't support.

You can use custom code to create your new module for the feature you need. This strategy is slower, requires manual coding, and may not be possible on some platforms.

You can strip the feature out and not make it. This strategy limits the functionality of your final product and, if the feature was critical enough, can kill off an app idea.

You can migrate to another environment, potentially a different low-code platform or a high-code environment.

None of these are great options when investing heavily in a low-code platform.

You may end up locked into a specific vendor or environment.

Many low-code platforms use a relatively standardized set of code or a core language shared across other platforms and high-code development. However, that's not true of all of them. Moreover, some will only allow you to export finished products and may make it difficult (or, rarely, impossible) to export and transfer your base code to another system.

This means you often end up faced with a choice. Do you go low-code using code snippets and self-guided development, or do you use a platform that may lock you into their environment, implicitly or explicitly?

Neither is an excellent choice for many businesses.

When using a low-code environment, you have code snippets pre-generated and usable through an editor. You can leverage this to your advantage by hiring people who don't have as much direct technical expertise. However, this puts you in a sticky situation.

Does anyone in your development team know what the code does?

It's rare for the significant environments with many users because someone (somewhere) looks it over and analyzes it. However, especially in the more DIY low-code development processes using untested snippets found online, there can be potential problems with unknown code. You may run into an issue where the modules you're using have unexpected code, unintended features, or even security issues.

If no one knows what the code does intimately, you never know what kinds of problems can arise.

Should You Use a Low-Code Development Platform?

The answer to this question is a resounding "maybe." The truth is, a low-code environment can be great for:

Simple or small apps with constrained functionality.

Agile development of a proof of concept or minimum viable product.

However, as an app reaches maturity, complexity, logical burden, and uniqueness rear their heads.

The easier it is to make your app in a low-code environment, the less uniqueness and value your app will have when it's finished, and the easier it will be for someone else to copy it and invest slightly more to out-do you. It can, in that sense, become a detriment to use a low-code environment for final development.

Generally, a low-code platform is excellent for getting started, but at some point, you will want to transition to a high-code environment for finishing your project. However, if you have further questions, feel free to reach out to us to discuss them.

The Pros and Cons of Low-Code Development Platforms

You may have heard the term MVP tossed around in developing a new product or, especially, software. What does it mean? No, we're not talking about your Most Valuable Player, that rockstar developer who seems to do everything for everyone. That person's great, but that's not what MVP means in this context.

MVP stands for Minimum Viable Product. What does that mean? How does it work? 

The MVP is the Minimum Viable Product, but what does that mean? 

"Minimum Viable Product or MVP is a development technique in which a new product is introduced in the market with basic features, but enough to get the consumers' attention. The final product is released in the market only after getting sufficient feedback from the product's initial users." – 

There are a bunch of definitions out there, depending on where you look, but they all come back to the same core concept.

"A minimum viable product, or MVP, is a product with enough features to attract early-adopter customers and validate a product idea early in the product development cycle. In industries such as software, the MVP can help the product team receive user feedback as quickly as possible to iterate and improve the product." – 

MVP is part of Agile/Lean product development and was introduced by Eric Ries, entrepreneur and author of The Lean Startup, a book about agile startup development.

"Eric Ries defined an MVP as that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort. This validated learning comes in the form of whether your customers will actually purchase your product." – 

So, a minimum viable product is a product your startup develops with the bare minimum number of and level of features.

Take, for example, a video streaming service. A company like Netflix, Hulu, or Disney might bring a video streaming service to the web with a bare minimum set of features. There's no Wishlisting, and there's no queue; there's a very minimal library of media. All they're doing is providing a streaming service to verify that there's demand for streaming video. You can add all of those features later, and the media library can be expanded using funds and user numbers gained from the MVP.

An MVP has three key characteristics to it.

It provides a feedback loop to guide future development early enough to properly adjust investment before wasting time, effort, or money.

It demonstrates the potential for future benefit to retain early adopters, even if they are not satisfied with what they get out of the box.

It provides enough value that people are willing to invest immediately, whether as venture capital or early adopters.

If any of these three is missing, the product is not complete enough to be an MVP.

A vital component of the MVP model is feedback, used to iterate on the design. That feedback can come from various sources, including focus groups, customer interviews, polls, surveys, monitoring discussions on social media or Reddit, and even user behavior tracking with apps like heatmaps or session tracking. Any data source that can meaningfully inform a business decision can be used to optimize an MVP.

There are tangible benefits and drawbacks to the MVP approach.

The most significant benefit of the MVP approach is agility and low investment.

With an MVP, you don't spend thousands of dev-hours and tons of money on building and implementing features that you don't know whether or not they're going to be used or desired by your audience. Many MVPs are nothing more than a landing page or a demo video to build up interest and gain feedback. The company solicits user feedback, feature requests, and an estimate of demand to determine what the product should have and then builds it. In many cases, no product even exists when the MVP is promoted.

Dropbox is a primary example of this model in action. When Dropbox was little more than an idea, the founders created a pitch video of the concept and its benefits. There was no product, not yet, but they used the video to convince venture capital to fund their business and used that capital to build it. The rest is, of course, history.

A secondary benefit of the MVP model is a speedy time to market. You can have an idea up and running in a matter of days or weeks, in some cases, and start getting feedback and building hype before other companies have even finished pitching the idea to the board that will present the concept to the decision-makers responsible for showing the idea to the directors who can green-light it.

Another excellent benefit of an MVP is to avoid investing in off-target features or products. If you come up with a great idea and build an MVP, only to find that no one cares and no one wants it, you can cut it off before ever spending another dollar on developing it.

This strategy contrasts the previous way of building products, where you would engineer the entire thing, and the consumer base would take it or leave it. If they chose to leave it, well, you would spend a considerable part of your subsequent investment (to justify the existing sunk costs) on marketing to find how to convince users they needed it.

MVPs can also help to avoid feature creep or scope creep. Many developers keep having more ideas to add to their product to make it better without paying attention to the added complexity or burden on users to learn how to use all of those features.

Moreover, scope creep costs money, time, and development energy, which can delay the full release, potentially even indefinitely. The video game Star Citizen is a primary example of this; with newly announced features often hyped and quietly canceled, the game has been in development for an entire decade and still has not achieved even a fraction of what it promised over the years.

There are several key drawbacks to the MVP approach.

The first is that many people don't quite understand it. They see "minimum" and make the bare minimum product they can, but they neglect the "viable" part of the acronym. Thus, what they bring to market is barely anything, leaving the audience resoundingly ambivalent to it.

The goal of an MVP is to harvest information about demand. Thus, the product needs to have enough to analyze the market.

If there's not enough to the product, users can't give appropriate feedback, and the business learns nothing.

However, one of the most significant issues with MVP development is the time to market for the full version of the product. You develop an idea and put it out into the world to build hype, but critically, 

you don't yet have the product available. 

Other companies with faster development cycles can take that hype and that idea, develop their own, and launch it, sometimes even before you do.

This cycle often happens in mobile app development and physical prototypes for small items, such as popular listings on websites like Kickstarter. One of the most iconic examples is the Fidget Cube, a product that went viral on Kickstarter and built a ton of hype and then 

was beat to market by a competitor copying it

The MVP model can be highly beneficial if you successfully navigate these drawbacks. If not, well, there's a reason most startups fail.

There are many different "bring a scaled-back idea to market for a purpose" ideas and models. 

What's the difference between an MVP and these options?

A proof of concept is an initial construct, a version of the idea that proves that it can work at all.

It's one thing to build a pitch deck of ideas, and it's quite another to create something to prove that you can bring those ideas into reality. We could quickly produce a video pitching a perpetual energy device, but we couldn't build it because it would violate the laws of physics. There's no way to bring that PoC into an MVP.

A proof of concept is essential to proving that you can build something and that your core idea works. A PoC doesn't need to be deeply functional, nuanced, or even look good; that's all polish you iterate on to make an actual MVP.

A prototype is somewhere between a proof of concept and an MVP. It's a version of the product you design to showcase how it works. This prototype is often your wireframe for software, a clickable, navigable version that starts to show the "flow" of how the product will work.

Prototypes are meant to be iterated, not simply refined. They're also intended to be usable enough to identify any significant roadblocks a user might encounter, points of failure you might not have noticed or thought about. Depending on feedback, you might go through dozens of prototypes, or you might hit on the core features properly in the first handful.

The MMP is the Minimum Marketable Product and is more advanced than the MVP. The MVP is there to build hype in the concept, research the market viability, and gain feedback to iterate on the idea; the MMP exists to be sold. It's the bare minimum that can be considered a "complete" product, even if you plan to add more features later. It's the 1.0 release, not the beta release, nor the alpha release.

Since the popularity of the MVP model arose, entrepreneurs have been iterating on it to see if they can come up with something to coin and cement their legacies. 

So, you see other models on the market, such as:

, the Minimum Lovable Product. This model doesn't focus on a product that people will tolerate as a starting point, but rather a product with enough to make people love it and become loyal to it and its brand.

 is about finding something that doesn't build an MVP in an existing paradigm but changes the paradigm itself. It creates such a reality-warping black hole of interest that potential customers can't help but fall into it. Something like Facebook or Amazon, which changed the face of how the internet and society works, were black holes.

. Like the Wizard, this model has a "man behind the curtain." Typically, this comes up with "AI" and "Machine Learning" apps that just have 

 human workforces behind them. The goal is to get the concept up and running and invest in the real AI in the back end afterward.

There are a lot of variances out there, and pretty much every model works for someone, somewhere.

If you have an idea you want to bring to market, you have a lot of flexibility on how you want to do so.

The MVP model is practical for an agile, responsive business, but it's just one of many different models with different starting points and different steps along the way.

Of course not. There's no such thing as a "best" way of doing business.

If you want to bring your idea to life, reach out and contact us today. We're here to help you figure out just how to build it, what technology to use, what model will work best for your goals, and, of course, we do the legwork too. All you need to do is 

What's an MVP (Minimum Viable Product) and How Do They Work?

The world of technology is a pulsing cycle. You'll have a period of expansion, where new technology is developed, and multiple different spin-offs, iterations, and variations appear until the market seems saturated with options. It becomes challenging to know which to pick. Then, as that technology ages, the expansion begins with the next iteration. Next, as people gain experience using these options and comparing them, some become the clear winners. Some will fold, some will be purchased and rolled into others, and the market consolidates with the most effective options.

We're in the middle of this cycle with development. Right now, there are three clear favorites for the core technology everyone uses for their web app development. 

Those three are the front-end frameworks of Vue, Angular, and React.

All three of these frameworks are iterations on JavaScript, and they all work in slightly different ways, but they're all compelling and can all be used to make well-functioning apps.

You can split an app's functionality between the front-end and back-end in development. Front-end is the stuff a user sees and interacts with - it's your dashboard, newsfeed, user profile, etc. The back end is the server-side databases and infrastructure that hosts and runs the front-end code. Angular, Vue and React are all frameworks for front-end development.

Front-end frameworks are like shortcuts and cheat sheets. You could code up an entire front end in JavaScript, raw. After all, JavaScript, HTML, and CSS combined are present virtually everywhere on the internet.

In a way, you can think of it as a recipe. Imagine you want to make a pizza. You're given wheat and a millstone, meat and casings, spices, seeds; you have to grind your flour, make your sausage, grow your vegetables. It's a ton of work to make a pizza that is likely to be delicious, though you'll probably encounter missteps along the way.

Now imagine you're making that same pizza, but you're given pizza dough, pepperoni, and vegetables. You still have to prepare the ingredients, but it's much faster to assemble. And while the from-scratch pizza might be tastier, it also has a lot more points of failure along the way.

This process is the difference between using a framework and not using one. 

Not using a framework takes more time and has more places it can go wrong

, and while you may be able to produce a faster, more effective result than you would with a framework, it will take a lot more work to do, and there's always the chance that you won't. Indeed, most users won't even notice the difference.

It's no wonder that frameworks are so popular.

All three frameworks – Angular, React, and Vue – are similar in that they're essentially 

. They're packages of dough, sauce, cheese, veggies, and so on, everything you need to make a pizza. The difference is one of them might give you dough and sauce while another gives you the ingredients to make the dough, or one might give you a specific selection of toppings while another gives you a different set of choices.

It's those differences that are important when choosing a framework. So, what are they? React is a library of UI elements, Vue is a progressive framework, and Angular is a complete front-end framework. What does all that mean?

The structure of the three frameworks varies significantly.

 is a library of elements and building blocks. It doesn't enforce structure (and is thus not technically even a framework, but since it's used in more or less the same way, we're keeping it in the comparison), so it's very flexible. You can think of it kind of like having a giant pile of Lego bricks to play with. You don't have to engineer a wheel when the wheel is right there to use, but you do have to build the car.

 is also technically not a traditional framework because it focuses solely on the view layer of app development. It's made to allow you to develop small, individual components per your specifications. A single Vue element can be a module of HTML and CSS that works the same way and can be re-used throughout your code. Vue can also be extended using official and unofficial expansion packages, like Vue Router, to be more like a traditional framework.

 is a more traditional framework. It allows you to build components from a combination of a template, a class (that defines how the module functions), and metadata that specifies how it looks and acts. You define the components; then you create services to use those components to develop the front end you're designing.

Each of the three frameworks has a distinct origin. 

However, they're all interlinked due to all being part of the same overall environment (the internet), and developers all talk to each other and socialize.

 was developed in 2010 by Google. However, what we think of as Angular today is now called Angular 2. Angular 1, currently called AngularJS, was deprecated in 2016. Most people, when talking about Angular, are referring to Angular 2. Or, well, Angular 13 (the most recent stable release) or whatever it's up to now.

 came out in 2013 and was developed by Facebook, primarily to power their architecture and content (Facebook, Instagram, WhatsApp, and all their components) but was released for public use as a framework anyone could use.

 is the youngest of the lot by a year. It was developed by an ex-Google employee and released in 2014, just a year after React. In a way, it's sort of like the indie offering trying to compete in the space dominated by Facebook and Google and is supported by a Patreon and independent funding.

All three frameworks are open source under the MIT license. If you're curious what that means, you can read a summary here.

It can be challenging to determine how popular each framework is. The most common way of estimating it is by looking at the number of stars the framework has on Github. As of this writing, they are:

While this seems dramatically lower, remember that Angular was forked; AngularJS has 60k stars of its own. Both are still in active use and are maintained, though they have fewer stars than their competitors even combined.

Of course, they're all popular enough to have significant communities, plenty of ongoing support, and a broad ecosystem of tools you can use to expand functionality or make it easier to develop in the framework.

Starting with Angular, let's talk about the pros and cons of using each framework.

 Angular divides your front end into a model, a view, and a controller, with a firm set of best practices for each component. This framework allows you to develop well-structured code and makes it easier to troubleshoot, edit, and fix.

Angular uses HTML for most of its templates, making them easy to read, code, and edit as necessary.

 This data structure gets into the weeds with technical details we don't need to get into here. Suffice it to say that it's a practical and fast-operating structure for small and simple applications. However, it might falter or slow down operations compared to one-way data binding on more extensive and complex apps.

 Angular is one of the more popular frameworks out there. There are many additional structures and tools, features, pre-made modules, and templates you can use as developed and supported by the community. You can also most assuredly find assistance with any problem you're having somewhere in one of their large community hubs.

Shadow DOMs are a way to encapsulate sub-elements of DOMs (don't worry if you don't quite get this) that, to simplify, basically means that you can use a template that would have CSS applied equally across every usage and segment off particular sub-uses of it to have their styling. It's a great way to use a template/module-based framework without the drawback of needing versatile styling for templates. Angular supports it but doesn't use it by default, so you need to emulate it.

Insights