Introduction to NikaFramework (NKF). Part 2

Continuation of the first part .

4. Project assembly system
What I love about the build system is that I can create many different files and not worry about how to organize it so that it all loads quickly on the user's side.

What does the project build system do?
One simple thing - takes all the files, packs them in a certain way and at the output we have one, only file - index.xhtmlz .
This allows the developer to create an arbitrary number of files, for example, divide classes into several subclasses, write styles in several files, create XHTML blanks for any occasion.

In addition, we can later access the same resources (XHTML, SVG, JSON) using inherited methods without resorting to AJAX, since all these resources are already in index.xhtmlz .
')
If pictures are used in XHTML or in styles (CSS / Sass), then the project build system converts them to data: URL , when using base64.

index.xhtmlz (index.xhtml):


DOM:


In the future, it is planned to introduce support for “annotations”, during which the resource should not be converted to data: URL, which can be useful for very large files, for example, video.

The project build system has two modes. development and production. In development (by default) all resources are packaged, but JS is not compressed and does not obfuskirutsya.
In production mode - additional compression is in progress. At the end of the work (in any of the modes) -
The file is compressed in a zip format, which saves on traffic.

The project build system is written in NodeJS and on average takes 1 second in development mode for an average project (350 files).

The advantage of using the entire compilation time (project build) is that you always have a code that meets the combat conditions, that is, production mode.
As it often happens, when using a separate script / link tag, everything works fine, and later, when everything is packed into one file, the jambs start to crawl out.

5. The semantics of the generated DOM
How often did you have to inspect an element (Firebug, Web Developer), and then look for its implementation throughout the code? NKF solves this problem by the fact that it knows what type of component each component belongs to, and it generates a DOM itself that is clear for finding the component quickly.

data-nkf-component-type - component type
data-nkf-component-name - the name of the component





6. Localization on the fly
This is an opportunity to change the locale to another without rebooting. This is done using the data- * attribute data-lang- *.

For example

 <label data-lang-textcontent="{{Search}}" data-lang-title="{{Search!}}"/> 

will end up like this, for the English.

 <label data-lang-textcontent="{{Search}}" data-lang-title="{{Search!}}" title="Search!">Search</label> 

or like that for rus.

 <label data-lang-textcontent="{{Search}}" data-lang-title="{{Search!}}" title="!"></label> 

Localization files are created in the / data / lang directory as regular JSON files.

For example

ru.json:

 { "translate":{ "Search": "", "Products": "" .... } } 

It is also possible to partially localize the generated part of the DOM and even CSS ( content ).

In the future, it is planned to make the ability to bind tags to localize large text.

In the next part, I will show how to create applications using this framework.

PS Constructive criticism and ideas for improvement are welcome.