Pinpoint the problems of excessive relying on a framework

Hi @apiraino, In my opinion, the main problem when using a framework is inappropriate coupling. Every time that you let a framework make a decision for you, that decision is hardly reversible. Evolvability is a great asset when developing a complex application, but to evolve you need to make reversible choices.

Every framework will help you with some kind of problem, but the help comes with a tradeoff. And to understand what are the tradeoffs of technical decisions is one of the purposes of this movement.

So, when we use a framework because we accept the tradeoffs we try to stick with an approach that we call "Defend from frameworks". You can translate it with "using Frameworks responsibly". This example should make clear what I mean. This is a standard AngularJS controller.

app.factory(‘getUsers’,[‘$http’,function($http){
 return $http.get(‘api/v1/users’);
});

app.controller(‘home’,[
 ‘$scope’,
 ‘getUsers’,
 function(
     $scope,
     getUsers){
         getUsers().then(function(response){
             $scope.users = response.data;
         });
}]);

As you can see we're using the standard $http service to make XHR requests. Today we have the fetch: a standard API to make XHR requests. The code will change like this. Using fetch the code will look like this:

users.js

export default function(){
   return fetch(‘api/v1/users’).then(function (response) {
       return response.json();
   });
};

Controller

import getUsers from ‘./getUsers’;
app.controller(‘home’,[
   ‘$scope’,
   function(
       $scope){
           getUsers().then(function(users){
               $scope.users = users;
           });
}]);

So as you can see I'm not using $http here. Doing that I probably reduced the coupling between my business logic and the framework, making my application more evolvable.

This is what I mean when I say "using Frameworks responsibly". Use them when it's useful, but never forget tradeoffs.

frameworkless-movement / manifesto

Pinpoint the problems of excessive relying on a framework #4