The story of how the We.js project turned into a javascript framework.
The beginning
In 2013, Thiago Petra, Antônio Cordeiro and Rodrigo Vieira held an online conversation on Saturday to exchange some ideas about social networks on the internet.
At a certain point in the conversation, Antônio joked:
We have to invert the M, change Me (mine) to We (ours)…
The initial idea was to create systems with a decentralized flow of information where the user could be the owner of their data.
After this conversation I started researching technologies to create projects with this logic and some technologies I tested are: Elgg, Buddypress, Drupal Commons, Django, Synfony and Node.js.
Still in 2013, I went to the FISL event and saw that node.js was a promising technology, selecting it to be the basis for We.js.
After FISL, I carried out some tests with compound.js, Meam and sails.js, choosing Sails.js as the base framework for v0.1.0.
Version 0.1.x
We.js v0.1.0 was focused on social networks, with a Single Page Application (SPA) format and with great use of [pub/sub](https://en.wikipedia.org/wiki/Publish%E2 %80%93subscribe_pattern) of Sails.js to allow real-time updating of system contents, but in practice pub/sub was a resource little used in projects
A little later, We.js was selected to be the technology used in new Community of Practice projects, oauth and social reporting systems with a structure of interconnected services
Version 0.2.x
To improve the client part (Ember.js) of the system, we carried out the first major update of We.js, reorganizing the system and adding a plugin module, the we-plugin as Sails.js’ hook, which allowed “plugging” other modules and Resources saved in other npm projects.
Each plugin had its server and client part using grunt to assemble and prepare the client files.
Version 0.3.x
After another 1 year of using the systems with v0.2.x and some analysis, I realized that there was a lack of more resource support for relational databases and that the system could have a more divided request process with context loading steps, verification access, data processing and types of customized responses.
We implemented the custom response types feature allowing us to send the same information in many different formats and to have greater accessibility I added the HTML response type as the system default.
The HTML response type worked so well that I added the layout, regions and widgets (blocks) features and it was also possible to create a forms plugin that generates forms using JSON or the models attributes
Among many new features, the big advance was that We.js stopped being focused on just social networks to be a complete functional tool for any project.
Version 1.x +
Today we have a generator for pre-developed projects (distributions) for blogs/sites, conference portals and social networks, allowing the creation of these projects with just a few commands, reusing modules and greatly reducing the cost of systems with Node.js.
With the custom response types feature, we can reuse system data by creating new views or SPAs
And today the We.js framework serves my dynamic systems projects with great efficiency.
And a special thank you to everyone who has already helped the project, Thank you!