JavaScript
Article

Frameworkless JavaScript

By Paweł Zagrobelny

This article was peer reviewed by Stephan Max and Nilson Jacques. Thanks to all of SitePoint’s peer reviewers for making SitePoint content the best it can be!

JavaScript frameworks offer many functionality and it’s not surprising at all that they’re getting more and more popular. They’re powerful and not so hard to master. Generally, we use them for large and complex applications, but in some cases also for smaller ones. After having learned how to use a framework, you’re tempted to use it for every app you want to develop, but you forget that sometimes using just old good JavaScript might be sufficient.

In this article I’ll discuss about the pros and cons of using a framework and what you should consider before starting your project.

Frameworks Are Powerful

Frameworks have their advantages. First of all, you don’t have to bother about namespaces, cross-browser compatibility, writing several utilities functions, and so on. You work on well organized code, made by some of the best developers in the industry. If you know the framework well, your development speed can be incredibly fast. Moreover, if you have problems with any of the features, it’s easy to find the documentation of the framework, tons of free tutorials, and big community happy to help. What if you need more manpower? There’s no hassle with hiring. If you know how a given framework works, no matter what the project is about, you’ll feel like at home. And the code of the framework itself evolves every day, to be even better, stronger, and more secure. So, you can just focus on what matters: your work.

In conclusion, frameworks are very powerful and offer a lot of features such as templating, routing, and controllers. But the question is: do you really need them for you project?

Often frameworks are a good choice, but this isn’t true for every situation. A framework has a lot of useful functions which in turn increase its weight. Unfortunately, in some cases this weight isn’t justified because smaller projects use only a tiny part of the framework. In such situations, raw JavaScript (sometimes referred as Vanilla JavaScript) can be the solution to all your problems.

By using raw JavaScript your code will be lighter, and easier for you to develop and expand. You also don’t have to spend your time learning one or more frameworks to use. Every framework works in a different manner, so even if you already know what feature to create (maybe because you did it already in the past) you’ll implement it differently based on the framework you’ve chosen to employ. It’s true that the more familiar you are with JavaScript frameworks the faster you learn a new one, but you always have to spend some time deepening the topic (more or less depending on your skills). Moreover, there is always a possibility that the framework you’ve chosen won’t gain popularity and be abandoned. On the contrary, with your own code there is no such possibility and you don’t have to bother about updates and breaking changes of newer versions.

Frameworks sometimes are an overkill and they overcomplicate the structure of small projects. If you need only a few of their features you can develop them by your own.

For instance, one of the most popular features of modern JavaScript frameworks is two-way binding. If you need it, you can write the code that implements it by yourself. Here’s an example of two-way binding in only 100 lines of JavaScript. One hundred lines, no intricacy, effect similar to frameworks’ solutions and, above all, lack of unneeded functionality. To implement this feature, there’s also a more modern approach. Have you ever heard about Object.observe()? Here’s an example of two-way binding feature using this solution. It may seem too futuristic because not every browser supports it, but it’s still interesting to take a look at it. If you’d like to see another solution, you could also check bind.js. Similar functionality, but without Object.observe().

Cons of Not Using Frameworks

Ignoring JavaScript frameworks could be a good choice sometimes, but you have to remember about the cons of this approach.

Firstly, without a framework you don’t have a solid basic structure. You have to do a lot of work before you can really start developing the features of your product. The more features you want to add, the more time you need. If you’re developing for a client, it could be a really important issue because deadlines are rarely friendly.

Secondly, code quality matters. Obviously, this factor depends on the developers’ skills. If you’re very experienced, the quality will be good. But not everybody has really mastered JavaScript and you don’t want the source of the project to be messy. Poorly written frameworks are not going to live too long while well written ones maintain a high quality for both personal and commercial projects.

Since we’re talking about code, we can’t forget bugs. Every serious framework is made by more than one or two people. With the contribution of thousands of people it’s very hard for bugs to be unnoticed. If you decide to avoid using a framework, your app will be checked by you and your team only. If you go on with in-depth tests, it’d take you even more time that you might not have!

The same point is valid for security. It could be a lot worse than in frameworks for the same reasons I mentioned before. If there are several people who work on the same project, there are more chances that a security issue is noticed. We could say that it isn’t hard to develop an application and that the hard part is to make it good and secure. If you don’t fell like an expert or you’re worried about the security, frameworks or libraries will help you a lot.

There’s also the cross-browser compatibility issue. With a good framework you can forget about this point. If you work with raw JavaScript, you have to handle it by yourself or just ignore it (which isn’t a recommended approach).

I also want to mention a problem with hiring developers. It could be a real problem, especially if you want to do this in a later stage of development. Unless they have a good experience, you have to explain them in details the project source before they can start working on it and, again, it costs time. Even if you teach them all they need to know, often there is no technical documentation of the code of a project. If your new employee has a problem, it’s your responsibility to help. Of course, you can write a documentation yourself, but it costs time and efforts.

To Use or Not to Use, Frameworks? This is the Question.

Based on the points discussed so far, when should you use a framework? You have to take into account several aspects.

Let’s start with what’s probably the most important one: the time. If your clients give you tight deadlines, not using frameworks is not an option. That’s a situation where you have to start developing quickly and with the confidence that you have a solid base. If you’re experienced, frameworks with their ready solutions are perfect for the job.

Another interesting case are large applications. If you’re building something really big, making use of a good framework is the best choice you can make. They have all the features you might need and they provide secure and performant code out of the box. Writing everything yourself would be like re-inventing the wheel for most features and it’s also time consuming.

If you build complex apps without a framework, you’ll probably meet all the cons of frameworkless JavaScript. One of them are possible bugs. If your app has to be reliable and you aren’t an expert, frameworks are a good choice. Even if you’re an expert, making in-depth tests of a complex application could take you a lot of time. If you have it, and your client doesn’t mind, go ahead with your own code. But usually there’s no such comfort.

In some case official documentations are quite poor, but if a given framework is popular enough, you’ll easily find the answers you need. For beginners, developing with framework seems simpler because they don’t have to deal with a structure to develop by themselves and they can simply “follow the rules” of the framework.

Finally, if you’re not alone and you have a big team, which constantly changes, frameworks are like a godsend. If your app is written with AngularJS, for instance, and you hire a developer who knows it, he/she will offer a great support to your project. If you work with my-company-framework.js, things can be a lot harder.

If you don’t know JavaScript very well, writing code by yourself can only bring harm. Your code can be buggy, insecure and not efficient enough. But if you know what you’re doing, the code written for a specific app can work better. It can be simpler for you to extend and you’ll avoid to load tons of unused features. So if you have time and experience, it could be a good choice to not employ a framework.

This is even more true for big apps that have a lot of bespoke features. The fact that your application targets a great amount of users doesn’t mean that the source must be very complicated. If your app is big but simple, using unneeded features of massive frameworks can cost you a lot. Big apps are the place where you can hit the walls of the framework and have to start to use inefficient workarounds. If you app is quite specific, a different approach should be preferred. Frameworks are quite flexible but can’t predict all the scenarios. You are the only person who knows what it’s needed.

Sometimes the decision to use a framework or not is all about personal preferences. If your app isn’t very complicated, you could set your own workspace. It’s always better to create a specific workspace for every project, but it’s not always possible. You need to be highly skilled to do it.

Let’s Meet in the Middle of the Road

Now that I’ve discussed the pros and cons of frameworks, let’s talk about another possibility. Let’s say that you have a small project, you don’t want to use large frameworks, but you have a tight deadline. What do you do?

You don’t have to roll up your sleeves and work 12 hours per day to meet it. When you think about framework, you probably think to a big set of features, but it’s not always like that. There are many small and lightweight frameworks and libraries for less demanding apps. They could be the best choice sometimes.

There are a lot of minimalist JavaScript frameworks you could adopt. For example, you can give a chance to Sammy which is only 16kB and 5.2K compressed and gzipped. Sammy is built on a system of plugins and adapters and it only include the code you need. It’s also easy to extract your own code into reusable plugins. It’s an awesome resource for small projects.

As an alternative you could use the super tiny Min.js, a JavaScript library useful to execute simple DOM querying and hooking event listeners. Thanks to its jQuery-like style, it feels very intuitive and simple to use. Its goal is to return the raw DOM node, which then can be manipulated using element.classList, element.innerHTML, and other methods. The following is a small example of how to use it:

$('p:first-child a').on('click', function (event) {
  event.preventDefault();
  // do something else
});

Obviously, it has some limits. For instance, you can’t turn off events.

Do you need yet another alternative? In this case I can suggest you Riot.js (1 kB). Riot.js is a library that has a lot of innovative ideas, some of which taken from React. However, it tries to be very small and more condensed.

Let’s get Custom tags for example. You can have it with React if you use Polymer. It allows you to write human-readable code, which is then converted to JavaScript. In Riot.js you can have it without any external libraries.

Here’s an example from the official website which shows how the code looks before it’s converted:

<body>

  <h1>Acme community</h1>

  <forum-header/>

  <forum-content>
    <forum-threads/>
    <forum-sidebar/>
  </forum-content>

  <forum-footer/>

  <script>riot.mount('*', { api: forum_api })</script>
</body>

This is only one from all the features the framework is proud of. You can check the website to find out more about this project.

There’s also Microjs, that I simply adore. It’s “a micro-site for micro-frameworks” that provides you a set of minified and fast JavaScript frameworks and libraries. Each of them does one thing and does it well. You can choose as many of these frameworks as you need. There are tons of solutions for templating, Ajax, HTML5 features to choose from. Microjs helps you to get rid of the frameworks full of the unused features and comes with another advantages. The frameworks and libraries provided are really small and simple. It’s rare even to find files bigger than 3-4Kb!

Returning to the previously-mentioned example of two-way binding without big frameworks, what do you think we would need to do in order to use this feature in Microjs? We would have to visit its website and search for a solution ready to be integrated. And guess what? It’s there! One of these solutions is a micro-library called dual-emitter whose size is just 3.7kB.

Now, let’s say we want a simple templating system. Type “templating” in the search box and you’ll find a long list where you can choose whatever you want. You can also combine one micro-library with many others, creating a specific workspace for your specific project. You don’t have to prepare it by yourself and you don’t have to deal with unneeded features.

There are a lot of possibilities to choose from, some better than others. You have to carefully select them and choose the most proper one.

Finally, I want to mentioned another great project out there called TodoMVC. If you’re confused and don’t know what to employ in your project, that’s the tool for you. The list of well-made JavaScript frameworks is growing every day and is hard to check features of every each of them. TodoMVC does the job for you. It’s a project which offers the same Todo application implemented using MV* concepts in most of the popular JavaScript MV* frameworks of today.

Conclusions

In conclusion, should you use frameworks or not? The decision is up to you. Before you start developing you have to consider what you really need, then measure all the pros and cons of each approach.

If you choose a framework, then search for the one which best suits your needs. If not, search for ready solutions hidden in the micro-frameworks or micro-libraries. If there’s nothing good for you and you want to develop it by yourself. There’s no ready recipe. You’re the one who knows your needs and skills. There’s just one advice: stay focused on your goals and you’ll find the right solution.

What about you? Have you ever tried one of these solutions? Which one? Feel free to share your comments in the section below.

  • http://www.adriansandu.com Adrian SANDU

    I think that a large factor in reducing the dependency from framework is the increased native support across all browsers for things like DOM navigation and other similar things. Before we needed a framework to smooth out the differences between browsers. Today we can get the same result with a lower code footprint.

  • Sylvain Pollet

    Riot.js is great, better than React in my opinion, but it is not 1kB :) 18kB in latest version

    • Jeff Jones

      Riot 2 is beautiful

  • steve

    When should you use a framework? It depends on the limitations, advantages and overall impact on development speed, resource, learning curve, page performance and page latency. Regarding the current frameworks – angular, ember, react etc, I think the answer is never. It adds bloat for small projects and it multiplies bloat for large projects. Irrespective of if you have a framework or not, you still have to write good architecture. You can write bad architecture inside a framework just as much as you can outside of it. If you aren’t experienced enough in javascript to work without a framework how are you going to write good architecture with it? You need a peer anyway. A peer should decide the format/architectural patterns inline with the common naming conventions and best practice.

  • http://tassedecafe.org Jérémy Heleine

    Very interesting question! In the “middle” category, we can also talk about custom builds to only get the needed features in a library (I believe that jQuery provides such a feature, but not sure).

  • SocialChooozy

    Thank you for pointing to microjs library, didn’t knew about that. Looks interesting

  • Greg Meyer

    Yuuup. Object.observe is not “futuristic,” it’s dead.

  • Greg Meyer

    Yuuup. Object.observe is not “futuristic,” it’s dead.

  • http://sravi-kiran.blogspot.com Ravi Kiran

    Interesting article. I got to know a number of small frameworks available that would just fit to certain scenarios. Thanks for posting this.

  • Indira Murugan

    very useful information. thanks.

Recommended

Learn Coding Online
Learn Web Development

Start learning web development and design for free with SitePoint Premium!

Get the latest in JavaScript, once a week, for free.