Building a frontend with ErgoJS

I am glad to present to your attention a js-framework called ErgoJS for creating rich web applications. And yes, I love bikes.

In this article I will not describe in detail the framework itself and will touch only on general points, since I plan to post the relevant information in the near future on the project website.

Let's start dating.

Immediately I want to say that ErgoJS has no core idea, so to speak, a special “killer feature” like MVC, MVVM, its own template language, etc.
ErgoJS was primarily created as a library of widgets, but now as it grows, the emphasis has shifted towards building full-fledged web applications.
')
Work on this framework began a long time ago, it was intended for programmers who are used to dealing with a “fat” client and riveting applications alone. But participation in the web development team, initially broken into the top three specializations, “designer” - “layout designer” - “programmer”, and later on, a couple of “designer designer,” and “layout designer / programmer” made their adjustments. Creating a programming tool was easy and fun, but with styles and layout somehow did not immediately set (hello and goodbye IE6). Long meetings with the team, attempts to “make once and for all” did not bring noticeable fruits and only took precious time. It was necessary to look for another solution. And this lasted until the advent of CSS-frameworks, which, though not completely, but put in order and systematized the layout magic, making it available for use by simple web developers.

Targets and goals

Accumulation and fixing techniques, not solutions

ErgoJS consists of two parts: the core and the widget library. Although they are closely related, each has its own purpose. So the kernel tries to incorporate and systematize the techniques and methods of work of the programmer and coder, allowing you to create and modify widgets that play the role of web application blocks. In the most degenerate case, using kernel components, you can perform the usual page layout using the capabilities of the html namespace.

The library of widgets, in turn, contains the reference set of components from which the application is built. This changes the approach to development (not “create”, but “assemble”) and reduces the requirements for the programmer’s level of training (it’s not necessary to know how to align or center the elements on the page — just use the necessary layout). The programmer can use the components included in the library to create a prototype, sometimes coarse, sometimes quite accurate, to further “finish” it to the level of the finished software product.

Principle of least surprise

The functions and behavior of the framework components tend to have obvious and predictable behavior. This is difficult to achieve, since different people have different experiences and perspectives on how certain things should work, but discussing the issue in a group of specialists allows us to solve many problems.

Do not do too much

If something can be implemented using HTML or CSS, then it must be done that way. Using JavaScript allows you to compensate for the lack of full standards support by popular browsers (polifila) or add new features that did not fall under standardization.
When specifications are updated, the ErgoJS functionality is updated, for example, the expected support by all browsers of the flexbox-layout will allow to abandon a noticeable part of the ErgoJS layouts functionality, which concerns the automatic calculation of the size of widgets.

Compact code

Problem solving in general form always has one drawback - redundancy. In this case, there should be either a rejection of the generalization, or the creation of a mechanism for a brief record of operations. ErgoJS tends to follow the second path, but with one rule: “if code is written for reuse, then common forms should be used”. In all other cases, short forms are preferred.

ErgoJS Features

Declarative programming style.

When a programmer is assigned a task, he searches for an algorithm for the solution and implements it. With the user interface, everything is different - the solution does not imply an algorithm, but allows for structural decomposition. In this case, you can break the picture into small parts and solve each of them separately, one after the other. But what happens if all these parts already have their own solutions and the developer needs to assemble them together, how do the builders assemble and build a house from panels or bricks? The very nature of the development is changing - one has to think not about how to put a brick one by one, but how to join panels together, where to make openings, how to put overlaps. To understand what is at stake, consider a couple of examples.

Create a box with buttons imperatively:

var box = new Ergo.widgets.Box(); var btn1 = new Ergo.widgets.Button({text: ' 1'}); var btn2 = new Ergo.widgets.Button({text: ' 2'}); var btn3 = new Ergo.widgets.Button({text: ' 3'}); box.items.add(btn1); box.items.add(btn2); box.items.add(btn3); 

And declaratively:

 var box = $.ergo({ etype: 'box', defaultItem: { etype: 'button' }, items: [ {text: ' 1'}, {text: ' 2'}, {text: ' 3'} ] }); 

This example shows that with an imperative approach, we ourselves consistently create a widget, and with a declarative one, we indicate to a certain “performer”, the required result, so that it does everything for us. Naturally, the more accurately and clearly we describe the result, the better it will coincide with our plan.

In a sense, ErgoJS forces you to perform a minimal interface design and only then begin creating it.

Virtual Widget Tree and DOM

Widgets are independent entities, or rather, a hierarchy of entities for which the DOM is only a representation. This means that, although each widget is associated with a specific DOM element, when displayed, the number, location, and relationships between the elements do not necessarily correspond to those in the VWT.

VWT is very similar to Shadow DOM, but if the second is a mixture of logic and presentation, then VWT is pure logic. This means that VWT can use the Shadow DOM to optimize the rendering process, but is not its equivalent.

 //  - $.ergo({ etype: 'button', components: { icon: { etype: 'icon', // ,      weight: -10, //  ,     DOM (   ) autoRender: false }, content: { //     etype: '&text' } } }); 

Hierarchical Data Binding

In most cases, the data structure corresponds to the structure of the page elements, which, however, is not surprising, since the data is logically related within the domain model, and their display retains this logic, since it is known and understandable to the user by definition.

Connecting data to the widget, they are automatically attached to all child widgets. The binding process can be controlled by disabling or ignoring the binding for both individual widgets in the VWT and for subtrees.

 var obj = { title: '', datetime: '2014-11-10T12:55:00', description: 'Loremipsum', img: 'img/image_001.jpg' }; $.ergo({ etype: 'box', //      data: obj, //  components: { header: { binding: 'text', dataId: 'title' }, content: { //    layout: 'stack', items: [{ etype: 'html:img', //     src binding: 'src' }, { binding: 'text' dataId: 'description' }, { dataId: 'datetime', //       binding: function(v) { this.opt('text', moment(v).format('YYYY-MM-DD')); } }] } } }); 

Dynamic Data Binding

The binding mechanism implies the influence of data on the parameters, appearance, and state of the widget. With dynamic linking, the data define the structure of the VWT widgets, and the data connection with the widgets is one-way, i.e. changing the view does not affect the data, but changing the data rebuilds the relationship between the widgets.

 var list_data = ['', '', '', ''] $.ergo({ //   UL/LI etype: 'html:ul', //     defaultItem: { etype: 'html:li', //     text binding: 'text' }, // ,      dynamic: true, //     data: list_data }); 

In addition to the explicit assignment of dynamic linking for managing flat lists and tree-like lists, there is also an implicit one — delineating user access. Ie, you can change the page display not only by loading different scripts for different rights, but also by sharing the data that the server sends.

Division into components and elements

In fact, this separation is determined by javascript itself. There are two types of collections in it: Array and Object - simple array and associative. Therefore, child widgets that have a unique name become components (`components`), and those that have a valid number become elements (` items`).

 //    $.ergo({ etype: 'button', components: { // - `icon` icon: { etype: 'icon', state: 'fa-cog' }, //   `content` content: { etype: '&text' } }, text: ' ' }); //  $.ergo({ etype: 'html:ul', defaultItem: { etype: 'html:li', }, items: ['Item_1', 'Item_2', 'Item_3'] }); 

Popular framework as a basis (jQuery)

ErgoJS itself uses only a small part of the jQuery features, and as it develops, it switches to VanillaJS in performance-critical areas. However, in practice, jQuery greatly simplifies the work of creating impurities and opens the way for connecting a huge number of third-party plug-ins.

 //  - var w = $.ergo({ etype: 'list', items: ['', '', ''] }); // jQuery- <ul>    el w.el.css('color', '#f00'); 

other...

The best way to understand what `ErgoJS` is like is to familiarize yourself with the examples on the site .

Advantages and disadvantages

The good sides of ErgoJS include:

1. "Pure" HTML, no "extra" attributes
2. The application is being developed in JavaScript
3. One base object widget

And also to mention the disadvantages:

1. Relatively low rendering speed
2. Few ready-made solutions, while there is no possibility to work in design mode.
3. No specialized test support