The simplicity comes at a price. The actual state of development frameworks is a confusing layer to newcomers and the problem is that they aren’t necessary, but they’ve become the angular stone of nowadays dev teams.

Frameworks.

What is a framework?

To understand a framework as a concept, we must read a standard definition, let’s see what Wikipedia has to say:

A software framework, in computer programming, is an abstraction in which common code providing generic functionality can be selectively overridden or specialized by user code providing specific functionality. Frameworks are a special case of software libraries in that they are reusable abstractions of code wrapped in a well-defined Application programming interface (API), yet they contain some key distinguishing features that separate them from normal libraries. Software frameworks have these distinguishing features that separate them from libraries or normal user applications: 1) Inversion of control - In a framework, unlike in libraries or normal user applications, the overall program’s flow of control is not dictated by the caller, but by the framework. 2) Default behavior - A framework has a default behavior. This default behavior must actually be some useful behavior and not a series of no-ops. 3) Extensibility - A framework can be extended by the user usually by selective overriding or specialized by user code providing specific functionality. 4) Non-modifiable framework code - The framework code, in general, is not allowed to be modified. Users can extend the framework, but not modify its code.

So we can think of a framework as a super set of predefined functionalities that aim to make the development process easier than writing everything from scratch.

How a framework is born?

As the old tale says:

Once there was this little dev bee who wrote that little bee function every single time she had a bee project, one day, the bee decided to save that piece of code among other bee stuff she had written thousands of times and made it available to other bees so her hive wouldn’t waste time writing repetitive stuff.

No, that’s a bad joke, but frameworks are born in essentially the same way. It’s common for programmers to come across repetitive coding, and writing the same helper functions become tedious so, sooner or later, these functionalities end up being saved in custom libraries to allow the code being reusable. These libraries can evolve into a fully functional framework by defining its own control state and implementing new semantic into the workflow with the ability to simplify our lives.

How many frameworks are out there?

A little too many. There are a lot of frameworks for each language, and each framework serves its own purpose, some of them are specialized in some specific task and there are general-purpose frameworks that cover a variety of stuff.

Listing every framework will take a lot of space on this blog (and time) so I’m gonna leave you with a simple web example (you can go and check a more complete listing of web frameworks):

• JavaScript: Angular, React, Express, Meteor, Polymer, Vue, Node
• PHP: Laravel, CakePHP, CodeIgniter, Drupal, Symfony, Yii, Wordpress¹
• C++: Poco, CppCMS, Wt
• Python: Django, Flask, Frappe
• Ruby: Ruby on Rails
• HTML, CSS: Bootstrap, Foundation

This is a simple list, but there are thousands of frameworks out there in the wild.

The problem with frameworks

People

There’s no problem in deciding to use a framework, it’s actually a logical and sensible decision. The real problem is what people think about learning a framework.

“Should I learn X framework to become a developer?” No.

When I was finally accepting my fate as a web developer I began hearing a bunch of stuff like: “You should learn Node”,“Actually, Django is the best out there”,“Laravel or CakePHP will totally get you started” or “My friend does Ruby on Rails and it’s pretty well-paid”. Hearing it at meetups and casual talks got me into thinking that learning X framework was the way to go but it is not.

What should I learn then, smarty-pants?

You should learn the basics. I made a mistake and began to (try to) learn a bunch of frameworks without understanding the underlying language and functionalities. It was a disaster. I couldn’t understand anything, it was just copy-pasting code and following some blogs on how to create some views, business logic and some beta-male stuff.

It took me a lot of time to figure this out but here it is, just for you:

The biggest mistake you can make is not accepting you actually don’t know.

And it’s for real.

Accepting you don’t know and asking those who know will get you on the right track. For me, this came during a hackathon where I asked a friend of mine to give me pros and cons about using Django. He recognized immediately I didn’t knew what I was talking about and proceeded to explain the fundamental stuff I needed to understand before even thinking about getting into a framework. I was willing to learn, so I followed everything he said and it worked. In just about a month, I learned the very fundamentals of design principles and good software architecture and was able to adopt frameworks based on my projects’ actual necessities.

There’s no real roadmap out there

I mean, yeah, there are some roadmaps out there that explains pretty much everything you need to know in order to become a Web Developer. The problem is the pattern, hear me out, they’re always something like this:

1. Language
2. Tooling
3. Framework

And that’s it, following those simple steps you’re guaranteed to be able to become a developer, but you’re not. There’s more to it, but, let’s check each step.

Language

Okay, so first of all you need to learn the programming language you’re gonna use (pretty obvious if you ask me). You need to really practice a lot with the language, create simple projects and code some sample stuff, just to see how’s everything wiring up.

It depends on the actual language you’ve chosen for this task, but understanding it isn’t the same as being fluent in it (Remember, it’s a language!).

Tooling

The time has come, in this step you get to meet your friendly neighborhood packet manager.

It’s very important for you to learn how libraries are added to your code and how you interact with them. When you’re finished up with this step, you get to the final step: frameworks.

(As a side note, you should be able to create apps and more specialized projects from here, so practicing some previous exercises and rewriting them with helper libraries will help you understand better how a framework is built)

Framework(s)

By the time you arrive here you’ve probably spilled some blood (and some coffee) on your keyboard. You’ve learned the way and now you may fulfill your inner dream and become a software developer.

You begin by searching Framework Comparisons, start reading on stackoverflow about pros and cons about each one and try to make your own mind at it. That’s about it. You find the one (by comparing, recommendation or just by bloggers’ opinions why tho?) and begin to learn everything the frameworks’ documentation can provide.

And that’s it. You master the framework and now you’re a developer (Cheers!).

What’s missing from roadmaps?

Programming Design Principles

Actual product programming require a solid understanding of programming principles and good practices as they ensure the quality of your code for reusability and future-proof maintenance.

The thing about design principles is that they’re a guidance and not actual rules, so you have to make your own mind up.

The one’s that I learned and have benefited from are the S.O.L.I.D Design Principles as they ensure the abstraction of your code is well-defined and implemented. You can read about SOLID with this post on Medium.

Programming Design Patterns

Allow you to organize your code in a certain way that makes sense to you but also to other fellow programmers.

It’s important that you get to understand how to structure a project to be ready for future bugs features and get the most out of your implementation without wasting time and/or code.

Some design patterns that I’ve learned come from this blog post and you should totally check them out and tackle down one by one so you can get a deeper view into your code abstraction.

Data Structures and Algorithms

It’s fundamental that you understand Data Structures as well as Algorithms. You’re going to work with those in every single language no matter what. The easy way to go is just entering websites with online puzzles about those topics, and there’s a few of them:

• CodeChef
• UVA Online Judge
• USACO Training Gateway
• TopCoder
• Project Euler²
• HackerRank
• and more…

These are pretty important stuff, not just because it defines how the hard stuff is done, but because it teaches you how to think. Trust me, there are no regrets in spending daily time with this stuff.

Networking

Yes, maybe I’m a little biased here but hey, you really should learn some networking before starting to write some web-based applications. There are infinite reasons on why to do this, but here are my personal ones:

• You’re building things that rely on tens of thousands of protocols in software and hardware, some minor tuning can peak your app’s performance.
• The way users interact with the web is defined by the quality of their connection, being able to create and implement your own protocols can be a huge lifesaver (specially with real time apps and/or services).
• You can prevent common (and not so common) network errors in your application and act accordingly to mitigate an issue.
• It enables you to scale your app more efficiently
• It also helps you understand why your Wi-Fi doesn’t work in the kitchen (It isn’t just the kitchen, right?)

Networking also makes you capable of designing more specific processes and deciding from the beginning the best way to set up your DevOps architecture.

People gonna people (sic)

We’re humans, we make mistakes (a lot, actually). So don’t be disappointed if you miss on something. The most important thing is that you keep learning and improving your skills.

You shouldn’t be defining your programming stack by the restrictions of a framework, you should be using the framework for what it is: A tool.

For comments and feedback, you can find me on Twitter as: @humbertowoody.