Ecosystem approach to building a web project with TeaCSS

In this article I will tell you how to organize the process of assembling the front-end "from and to".

I advise you to start with an introductory article , if someone has not read.

There I talked about TeaCSS as a superset of CSS, and it was not true. More precisely - a half-truth. And so he was at the time of his creation (whence the name).
')
Now it is a declarative meta language for content generation, largely drawing inspiration from QML, Lisp, Clojure, Nemerle.

Prerequisites

I would like to start by negotiating some basic things to avoid holivars:

1. The type or orientation of a language does not determine its capabilities; if the Turing language is complete, then anything can be done on it
2. The type of language and syntax determine only the convenience of the developer in relation to the subject area.
3. For universal use, imperative languages ​​are generally better suited. operate with basic entities (strings, numbers, structures, classes) and from them, as from bricks, allow building houses.
4. For finished subject areas, declarative languages ​​are better (again, in general) because the process is more like not building, but setting up ready-made complex entities.

It is because of this separation of "abilities" that various third-party DSL (Domain Specific Language), built-in in the DSL language (in Ruby, Lisp, etc.) of a declarative sense, are now flourishing in a wild color. It is convenient to describe the processes of assembly, testing, interfaces, appearance, i.e. all where the base entity is already defined. For the above examples, entities are “project”, “functionality”, “user input and program behavior” and “type of item whose appearance is described”.

What is TeaCSS

This is the framework for declarative DSL, compiler builder with Javascript API. And a few basic DSL implementations for styles, scripts, templates, and images out of the box.

It takes on parsing, provides substantial assistance in generating content. Something this project is related to PEG.js and Jison - if you have time, I recommend to get acquainted.

And if there is a desire, then I can write an article about parsers and compilers, if someone needs it.

TeaCSS syntax is simple to ugliness:

[] _ { //  /*   */ @import "another_tea_file.tea"; @  JS @{  JS } [] ; [] _ { //   ,     } } 

It is precisely because almost any declarative language can be described as a set of nested rules, and the built-in JS allows you to add imperative elements to the language, such as variables, conditions, cycles, and so on.

For example, to describe a LESS-like language for styles, just 150 lines of code are enough.
github.com/boomyjee/teacss/blob/master/src/teacss/core.js#L309

This is the default generation language (Style).
To switch to another language, just start the selector with it:

 SomeLang { //      } 

TeaCSS as an assembly system

The second embedded language in teacss is Script, as you can guess, it serves to build application scripts.

Its syntax is simple:

 Script some_name { @append "some/script/path.js"; @append { function bla() { /* … */ } // Some javascript Code } } 

Those. linear elements are simply third-party scripts; block elements are simply code that you do not want to isolate separately. In production, all scripts will be combined by some_name, i.e. You can group JS as you like.

The TeaCSS library itself is assembled by itself, here is its “makefile”:
github.com/boomyjee/teacss/blob/master/src/build.tea

With this approach, TeaCSS is a replacement for modular development libraries and an ecosystem for building a web application facade.

It takes on what RequireJS or StealJS do .

I gave these 2 libraries as an example because only the AFAIK two of them also support the minification and creation of production versions of scripts.

But they (rather than even the libraries themselves, but the approach itself) have a number of serious flaws:

1. They mix the build system with the application code, i.e. leave specific calls to the build API inside the code production. To require you have to customize your code in a special way. In Steal there is a pluginify method, but it is simply buggy and is an attempt to cut code from dev versions of files with the Steal minifa.
2. Require is not friendly with CSS
3. The idea of ​​mixing the assembly and the code implies weak control over the assembly or cluttering up the code. These are different entities and code that assembles, provides modularity, etc. things should be kept separate from the code that will go to the final program.
4. Steal does not allow you to flexibly configure the final paths to the resources and there is no way (except for manual digging in the minifen script) to reconfigure it.

Therefore, it immediately suggests that the build rules be allocated to a separate place (in C development, this is a makefile).
The role of such makefile is assumed by teacss.Script.

The approach to using the same.

 <? if ($applicationMode=="development") ?> <link tea="scripts.tea"> <script src="teacss.js"></script> <? else ?> <script src="production.js"> <? endif ?> 

Connecting other languages ​​and a few examples

TeaCSS itself is a modular and extensible build system. To connect a new language based on the basic syntax, it is enough to add an import with a language description.

For example:

 @import "some_language_definition.js"; @import "some_tea_file.tea"; //         

About how to describe a new language in the TeaCSS ecosystem, I will write a separate article. In the meantime, I will show an example of such a language.

TeaCSS can be used as a system for generating static sites, analogs - Jekyll and here is a list, a lot of iwantmyname.com/blog/2011/02/list-static-website-generators.html

The syntax is intuitive, while there is compilation support in Liquid.

 Template layout { html { head { meta[http-equiv="Content-Type"][content="text/html; charset=utf-8"]; title TeaCSS; } body { #header { .item(url,text) { % if path == "@{url}" { a.active[href="@{url}"] @text; } % else { a[href="@{url}"] @text; } } div { .item('index.htm','Intro'); .item('canvas.htm','Canvas'); a[href="download.htm"][target="_blank"] Download; } } #content { % block content {} } } } } 

This is used, for example, to generate the website teacss.org .
Here is the repository in which the site itself and its generator lie - github.com/boomyjee/teacss-docs

And a more detailed example is github.com/boomyjee/teacss-docs/blob/master/build/templates/pages/index.tea

As an auxiliary language, constructions like

 Highlight xml { <link tea="style.tea"> <script src="teacss.js"></script> } 

Which give the output html for the highlighted code.

I made a small playground so that you can see in more detail how the html generation works - teacss.org/template.htm

Conclusion

TeaCSS is a declarative, meta DSL that was originally designed to facilitate the development and assembly of web applications, but is essentially a universal content generator on a declarative basis using browser JS as a friendly language.

This means that to launch and work, you do not need anything other than a browser to open up the possibility of creating an interactive development process right in the browser.

About this I will tell in one of the following articles.

PS

Let me remind you that I decided to write this article because in essence, I am doing things very similar at the same time to the latest Adobe project, Brackets, and to Kickstarter Light-table. But there are a few differences and it seems to me that they can be key, to tell about them, you need to start with the library, which underlies the project - a teacss. I hope to find like-minded people and assistants / partners in this largest project in Habre.