In general, I am a very loving person, especially in terms of various buns. But something in me turns over as soon as it is here (just a second ago, I am truly sympathetic) acquires the aura of holiness and becomes the subject of admiration. At this very moment, my inner voice (yes, I hear voices) strictly says so to me - “let's go, here we go!”.
And such crap happens quite often in our complicated, crazy, but very fun world of technology. In my particular case - in the world of web development.
The day before yesterday was JQ. Well, useful to her god thing. But specialists began to appear sincerely believing that JQ is part of JavaScript and that, without it, linking events to nodes is impossible at all (whispering in the hall: then there are some problems with cross-browser compatibility, csss). And churches with temples were built, and JQ from the icons began to look at us sinners, and the books were written with the title “We program JQuery” (JQ we “program”, Karl!).
And yesterday was AngularJS. And he was great because he was behind him ... Yeah, he is the most.
')
And today here is ReactJS. In general, our all. Why? Because it is good, because it is correct, because it is against direct access to the DOM. And why? And because it is wrong to contact DOM! And why? Boy, go to #poo!
No, Friends, do not think - I didn’t boil at all - believe me, I took prizes in loyalty contests. Just everything has its place and its purpose. Firing from a tank, trying to swat a fly is somehow frivolous. But at some point we are starting to see exactly this, when half a megabyte of JavaScript is pulled under a simple project (with source codes in TypeScript, because no one writes to JS or ask why, the answer was a paragraph above).
ReactJS is really great stuff. And when we were faced with the task of making an application with
blackjack and sending a bunch of widgets with the possibility of them on the desktop (which should be several), with all sorts of windows, tabs and other garbage, we chose without hesitation ReactJS. But if an “enlightened” customer comes to us with an unpretentious project and as if hints that he (the project) should be based on Angualr or ReactJS, then you want to cry, drink, fight and drink again as a sign of reconciliation. And you know, almost always it works, although in some cases you still have to write out a ticket to warm countries.
Meanwhile, I was lucky with the team. And as noted in the previous
post , I was allowed to develop in parallel a simple
template engine . Although something tells me that the company on this account has its own purely selfish interests)).
In general, since its
first public appearance, namely after five months, the template engine has undergone significant changes. What this note will be about (rumble in the hall: everything is different, this is not about ReactJS and not even Angular). Stand still I will definitely say the word "React" several times.
So, the main thing that was
done - a large association of parallel projects. Now one (rather big) library unites in itself:
- Analogue RequireJS
- Resource Loader (like CSS files)
- Cache controller
- Any basic functionality (like AJAX requests, tools for working with DOM, CSS, etc.)
- Well and shablonizator, it is about him
I am by no means going to bore you with a pile of dry and dull material, but I will give only a “couple” of simple examples to show what is actually being said.
For example, you need a banal table. And you have some
API that gives the data in JSON. We take and draw a separate HTML file with a template. And the styles you want to attach do not forget.
<!DOCTYPE html> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Flex.Template</title> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/> <link rel="stylesheet" type="text/css" href="pattern.css" /> </head> <body> <table data-type="Demo.Table"> <tr> <th>{{titles.column_0}}</th> <th>{{titles.column_1}}</th> <th>{{titles.column_2}}</th> <th>{{titles.column_3}}</th> </tr> <tr {{[rows]}}> <td>{{column_0}}</td> <td>{{column_1}}</td> <td>{{column_2}}</td> <td>{{column_3}}</td> </tr> </table> </body> </html>
Now, where this is necessary, we render our template.
_patterns.get({
That's all (the result here). And what is especially pleasant is that the template can be opened locally and debugged (calmly, slowly and without distracting) styles - after all, we have a banal HTML page.
Of course, you can enter data and pens.
var data_source = []; for (var i = 0; i < 100; i += 1) { data_source.push({ column_0: (Math.random() * 1000).toFixed(4), column_1: (Math.random() * 1000).toFixed(4), column_2: (Math.random() * 1000).toFixed(4), column_3: (Math.random() * 1000).toFixed(4), }); } _patterns.get({ url : '/patterns/table/single/pattern.html', node : document.body, hooks : { titles: { column_0: 'Column #0', column_1: 'Column #1', column_2: 'Column #2', column_3: 'Column #3', }, rows: data_source } }).render();
And you can stuff it straight into the markup - nothing is forbidden, because the main thing is for
love .
<!DOCTYPE html> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <link rel="pattern" name="my_table" src="/html/table/template.html" data-hooks="rows, c_0, c_1, c_2, c_3" /> </head> <body> <my_table> <rows> <c_0>0.0</c_0> <c_1>0.1</c_1> <c_2>0.2</c_2> <c_3>0.3</c_3> <c_0>1.0</c_0> <c_1>1.1</c_1> <c_2>1.2</c_2> <c_3>1.3</c_3> <c_0>2.0</c_0> <c_1>2.1</c_1> <c_2>2.2</c_2> <c_3>2.3</c_3> <c_0>3.0</c_0> <c_1>3.1</c_1> <c_2>3.2</c_2> <c_3>3.3</c_3> <c_0>4.0</c_0> <c_1>4.1</c_1> <c_2>4.2</c_2> <c_3>4.3</c_3> </rows> </my_table> </body>
With markup, you can do quite convenient things. Do you have, for example, a collection of tabs, very weighty, like this:
<div class="tabs-container"> <div class="tabs-buttons"> <a class="tab-button">Tab 0</a> <a class="tab-button">Tab 1</a> <a class="tab-button">Tab 2</a> </div> <div class="tabs-content"> <div class="tab-content"> <p class="tab-content">Tab content 0</p> </div> <div class="tab-content"> <p class="tab-content">Tab content 1</p> </div> <div class="tab-content"> <p class="tab-content">Tab content 2</p> </div> </div> </div>
Placing this in a template, that is, in a separate HTML file:
<div class="tabs-container"> <div class="tabs-buttons"> <a class="tab-button" {{[buttons]}} onclick="{{@onClick}}">{{button}}</a> </div> <div class="tabs-content"> <div class="tab-content" {{[tabs]}}>{{tab}}</div> </div> </div>
In the markup (on the page) with this template we can do this:
<!DOCTYPE html> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <link rel="pattern" name="tabs" src="/html/tabs/template.html" data-hooks="buttons, tabs, button, tab" /> </head> <body> <tabs> <buttons> <button>Tab 0</button> <button>Tab 2</button> <button>Tab 3</button> </buttons> <tabs> <tab><p>Content of tab 0</p></tab> <tab><p>Content of tab 1</p></tab> <tab><p>Content of tab 2</p></tab> </tabs> </tabs> </body>
And it is easier to read and understand intuitively. The
promo-site tabs are actually made.
The beauty is that templates are all
stored locally on the client . That is, when you reload the page, part of the markup of the page itself will simply not be loaded, but will be taken from the client. Which is also true for resources such as JS and CSS files. Solely as an experiment, there is also a function for full page caching, but for now this is only an experiment.
You can still, of course, create your
controllers under the template, giving it some functionality. You can “live” change the values ​​inside the template (in the example with the table, change the values ​​of the cells); there are models, events (certainly standard); and of course, it is allowed to access the DOM and enjoy it as far as knowledge is concerned.
A lot of things can be done there, which is not forbidden to read about
here (only if there is free time).
However, I will separately note the requirements that were set for Flex-Patterns during its development, which partly reflects the possibilities of its use.
- the first and most important is standard HTML only, only current JS standard. That is, any template is just an HTML file and no profits.
- this is a clean front-end solution, and although templates can be mounted on the markup, the Flex-Pattern is a client solution, not a server-side solution.
- complete independence from anything. It is enough to connect only Flex-Patterns to start working with it and get additional basic functionality (which was mentioned above).
Actually, these are the three whales on which the idea is based.
Well, again about React (I promised), because last time there were a lot of references to him and “requests” to compare, although these things are not compared, because there are different weight categories. I can only tell about the differences.
- React needs a bunch of
attendants with additional surroundings (for normal and comfortable work). Flex-Patterns are completely self-sufficient (and this is not counting the ability to create modules, the presence of basic functionality like the fact that JQ has other buns) - hooked up and work.
- React is comfortable with npm, and Flex Patterns doesn't even know what it is.
- React uses something similar to HTML, but not HTML. Flex-Patterns is based only on HTML and does not require knowledge of defaultValue.
- React as a whole is rather distrustful of the developer and in many respects limits it (which probably has its advantages). Flex-Patterns completely trusts the one who
sheltered him connected to the page.
- React works faster. Flex-Patterns as a whole is 25-35% slower, but “noticeably” this is on small patterns (say on a 1000-row table), where the drawing speed of the React 100 is 120 ms., And that of the Flex Patterns 150 is 200 ms. If we talk about huge objects (like a table with 10,000 lines), the result is almost identical.
- Memories "eat" both commensurately.
- React "interferes" with markup and logic, meanwhile, as Flex-Patterns aggressively tries to divide it and scatter it across files (which may seem inconvenient), not allowing any code inside HTML.
- React trusts browser caching, Flex-Patterns paranoid caches templates on its own.
- Over React works “slightly” more than one person, over Flex Patterns “slightly” less.
- In React there is a holy concept of state, and Flex Patterns allows an atheist and sin.
And finally, a couple of words about the future of the project (if anyone is interested, of course). The project has grown and its development is an increasingly difficult task. In the near future - a strict diet, which, according to my estimates, will allow you to lose weight from ~ 200 kb to 120 - 170 kb (where the first is the voice of an optimist). Also, the idea is in the air to do the same, but for JQ, which would allow you to get a library with a size of 70 - 100 kb at the output (do not forget inside not only the template engine, but a lot more, which essentially duplicates the possibilities of JQ).
However, without your support is unlikely to do. BUT! Scared))) No, it's not about finances. It's just that I will be given a little more time for the whole thing, if there are
asterisks (I'm not lying, this is the condition that was rolled out). For you - this is a click, and for me - an extra minute to develop this creation. Thanks in advance.
Happiness to all, good and light.
Shl. Learn React;)