Saturday, August 20, 2016

Emerald Framework - Guidelines

After the post "MVC or not MVC?", many people wrote me to ask about Emerald Framework. I don't intend to talk too much about it before the first release is available, which is scheduled to next weekend, but I decided to post here about the guidelines I followed in the development, as well as about some special characteristics of it.

The first interesting point about it is the fact it is written in Ruby and will be distributed as a Ruby gem. But it is not limited to Ruby. In fact, it's slogan is

Many programming languages
One framework to rule them all
One framework to find them
One framework to bring them all
And in the web bind them

Yes, I love Tolkien's "The Lord of the Rings"! And the releases will be named after characters of this books. This first release will be named "Aragorn".

We are so used to the fact that all frameworks are tied up to one language that we tend to forget that a framework is not language, but methodology. It is more connected to the procedures, the flow of development, than to an specific language. As the name says, it is a frame of reference for development. A set of tools and rules, a specific architecture. Stealing a few words from Fabio Akita, in this article here, "a coherent, opinionated full-stack".

So, Emerald Framework will be written in Ruby, but it will make possible for its users to develop using Ruby, PHP, Python... and other languages in the future, if the community around it create new sets of generators for other languages. As long as they keep the development rules in mind.

Yes, because Emerald has rules! I'm going to tell you about some of them, the main ones.

  • Be simple, without being simpleton. I value simplicity. My ideal of perfection is not something we don't have anything to add, but something we don't have anything to take away. Something like a Japanese Zen garden.
 A Japanese  Zen garden

One of my criticisms about PHP language is the fact they inserted too many things in it's ecosystem and it ended up as a big mess. Similar what good old Richard Stallman did to Emacs. Hell, that thing may even act as psychologist, if you need one!!! And believe me, if you are ready to discuss your mental condition with a computer program, then your really need a psychologist!!!

 Richard Stallman
  • A total separation of (Ruby | PHP | Python | ...) code and views. As I said in the above mentioned post, I don't like HTML code being server-side processed to detect special tags, like ERB does in Rails. First of all, this impacts performance. Anyone who dealt with configuring Apache to run PHP, as I did thousands of time in the last twelve years, knows what happens to performance when you say to PHP module to parse all .html files instead of just .php files. As far as I'm concerned, the only acceptable programming language one may write within HTML code is Javascript.
  • Server serves data, not pages. One of the sequels of my above mentioned post was a comment done in a LinkedIn group by a programmer. He said I was making no sense at all when I said servers shouldn't serve HTML pages. It surprises me to see people thinking like that, when I've had so many talks with senior programmers and software architects about just the opposite in the last few years. The objective of a web server is not necessarily serving HTML pages, but serving 'things' for the web! If fact, in the last few years people are doing huge efforts to avoid this: AJAX; data-aware components reloading just pieces of data when data changes; push technology; libraries and frameworks like knockout.js, ember.js, react.js and others. This is why I got surprised to see that some people still haven't got the spirit of this movement. When one transfers the HTML creation to the browser level, the web also profits from this, with a massive traffic reduction. And if you do it smartly, your pages will load faster.
  • Forget MVC. This was another interesting sequel of my post. I was in a skype call with a customer of mine and one of his programmers. We entered this subject of Emerald and I mentioned that Emerald wasn't MVC. The guy asked, as if he was surprised: "If it is not MVC, then what?" I felt like if MVC were the only thing people knew about web development standards now, and this is absurd. There are lots of other standards, and some of them are obviously better to web development than MVC. Then, why is MVC so popular? Why, for instance, Rails adopted it? The answer is quite simple, indeed. It works and organizes things, then it is better than no standard at all. If you doubt what I'm saying, maybe you'll change your mind reading these articles.
  • Loosely coupled components. A simple implementation decision helps Emerald to have its inner parts, its inner components, loosely coupled. We have no special data type being passed from one component to another. We use JSON extensively to this. Adopting a widely used public standard, not a proprietary one, makes Emerald's components easy to replace in future releases and able to be used by any library capable of sending/receiving JSON. I know that it is not usual, these days, to think about the future, to plan for future releases. YAGNI, "You ain't gonna need it", they say when we talk about planning a bit more. And I tell you that this lack of planning is one of my usual sources of humor, every time I see a team involved in an extensive refactoring due to the fact they needed to perform some change that could have been predicted with a few more hours of planning in the very beginning of the project.

 There are certain moments when worse is better.
But generalizing this as a immutable truth is as stupid as any generalization.
  • Focus on DRY. We base our development in small components made of Javascript in the UI/UX and of [Ruby | PHP | Python | ...] in the back end. Both parts are small, clean and independent. Both very easy to reuse in other parts of the systems created with Emerald. This is a great help when it comes to enforce the DRY principle. We don't need to repeat code because we made it very easy to reuse code wherever we need to.
 Repeating himself didn't help Agent Smith
  • Provide archetypes. Those Java programmers who are used to Maven know how easy it is to start a new system when there is an appropriate archetype to model it to you. We are going to enforce among our users, and provide tools for, people uploading archetypes for many types of applications to Emerald servers. We believe we may have an easily accessible bank of solutions to help Emerald developers to do things quickly and easily, without the need to rethink solutions that are almost always based on the very same basis. Those who created a blog using a framework, for instance, know that all those who do this create the same classes, with the same names and almost the same content. Having archetypes is taking code reuse to a new extent in web development. And if you need more than the usual, go ahead and take the archetype as a head start and improve what you need.
  • Your app is completely disconnected from Emerald. If you want to know why I mention this, open this great article by Piotr Solnic, "My time with Rails is up", and search form ActiveCoupling inside it. Emerald does the perfect separation among the framework and the app. I'd like to thank Piotr, for he called my attention to this problem, helping me to avoid it in Emerald.
  • Emerald is SEO friendly. SEO techniques are very important today. Thanks to a gem I developed and to a simple routing process, it was easy to make Emerald SEO friendly.
  • Have a great CLI. A great command line interface has always been a must for me. This is something that attracted so much users for Rails. I opted for Slop gem to help me build this CLI.
I believe this is enough for now. If anyone has questions, suggestions or criticisms (which are always welcome), please send your ideas to

emerald.framework@gmail.com

and I'll be pleased in discussing them. I'm also looking for beta testers to Emerald and if you want to take part in this project helping the tests, I'll thank you very much.