Thinking Reactively. Meteor js
If you have not heard about meteor, then you don’t follow the world of JavaScript at all, you are not interested in the web and it’s not clear how you got here.
So be it.
Meteor is one of the most unusual and experimental js frameworks for a long time. Those who say that this is not an MVC framework are certainly right.
One of the 7 principles that authors highlight on the documentation page : "Meteor is an open source tools and integrates, rather than replaces, existing open source tools and frameworks". Thereby they hint that they are not trying to solve problems that have long been solved. This and the fact that one of the so-called “Smart Packages”, which are already integrated into meteor, is the backbone .
')
The main difference between meteor is that it does not try to structure your code like most existing frameworks, it tries to instill a certain way of thinking during development.
Behind this word lies the main idea of the approach. Historically, the traditional JavaScript approach is asynchronous. Despite the fact that there is nothing complicated here, sometimes there are problems in debugging. Sometimes people cannot understand where the code is executed asynchronously and where it is not. There are also such things as CPH (callback pyramid of hell), asynchronous soup, and so on. All of them are designed to identify the code of people who love to write everything in one function. For them, a great variety of flow control libraries and even js dialects were invented. My favorites are flow-js and IcedCoffeeScript .
However, as it turned out, this does not solve the problem, but only allows programmers who have mastered this tao, maliciously chuckling, sending code to their colleagues with a proposal to check and accept pullrequest.
And here we return to meteor. On the meteor start page there are 8 points that describe its main features, we are interested in two: live page updates (on-the-fly page updates) and latency compensation (compensation for delays). Together, these two properties allow you to create magic: to link pieces of templates with data. At the same time, as soon as the data has changed a piece of the template is re-rendered and the client receives the current state of your application, whereas you have not written a single extra line.
The example is taken directly from the documentation. In short, the following happens: there is a “magic” method Meteor.render, which returns a documentFragment and is able to update it at the moment when the data used in its body changes. One condition: the data structure with which we want to associate the template must implement a specific interface. More details can be found in the description of Meteor.deps , as well as “it just works”.
Further - more, it is cool to associate data with a template, but we still have a lot of routine code that implements data synchronization on the client with data on the server. And here, these guys famously slashed off their shoulders and realized what I adore them for, and most of the js-community mercilessly spread rot. Database Everywhere. They made transparent the process of adding data from the client to the server. You change the collection on the client and it is immediately synchronized via the web sockets with the server. Then the previous two principles come into force and we get that all customers who have been affected by the changes have an up-to-date page before their eyes. That is, in fact, we can directly bind the database and template. It's simple:
Please note that the line with the declaration of the collection must be executed both on the client and on the server, but the template engine must run on the client.
But what about security? Just a couple of days ago, version 0.5 came out, in which an authorization mechanism was added that works very simply (in fact, these features were already available for a long time in the auth branch):
We have just forbidden any actions to do with the Posts collection, except for selections. Details can be read in the documentation or on github .
At the moment there is a problem with large collections, as the process of synchronization takes a lot of time and memory. Now these problems are being solved, for example, here .
As a result, meteor allows us to write code that is initially focused on data and their changes. We remove the need to think about the transfer of information and how we keep html up to date after changes on the server.
It remains to add one small stroke and say that initially all the code you write is executed on the server and on the client, which means that data structure definitions can be described once and they will be the same everywhere. And, as you know : “Bad programmers worry about the code. Good programmers worry about data structures and their relationships. ”
But the code that refers only to the client part or should be executed only on the server should be stored in the client and server folders, respectively. In general, convention over configuration .
Deployment mechanism is built into the framework itself, but for now it can be deployed only to the meteor.com subdomains, which is certainly not cool. For those who already want to deploy meteor-applications on their servers in the documentation there is a detailed instruction . Well, I wrote a small cake task that automates this process. You will need to install the nver-packages NodeSSH and scp installed on the server forever and installed for the current project. To install the latest, go to the project folder / .meteor / local / build / server / and type: "npm install NodeSSH scp". To start deployment, you just need to type "cake deploy".
And finally, I want to assure you that all environments and all frameworks fade in front of meteor when it comes to usability. There are two reasons for this, meteor practically doesn’t limit you where and what files you want to store, and the second is “Smart Packages”. I, as a person who has long ceased to program on pure js and use pure css, simply trudge from the fact that any file created in the project directory should be connected to the page, and if I type a simple command in the console: meteor add coffeescript, then The .coffee file created by me will automatically be compiled into js and will be added to the page. The same can be said about things like less, stylus, sass, etc.
Various jquery plugins, framework languages and much more are just as easy to add. As the number of “Smart Packages” grows, meteor will become more and more convenient, but even now there is almost everything needed to develop a full-fledged one page app.
As for the community, it pleases. If you go to the irc channel chat.freenode.net #meteor, they will definitely help you or at least try to help. The issue in github responds quickly, and discussions are quite active.
Despite all the praises, meteor is still not ready for serious production decisions. Also, it is very sad that the authors so strongly attached their decision to mongo. Not that mongo is a bad database, but not fashionable anymore. I anticipate that, one day, the authors will have to spend a decent amount of time cutting out the mongo-dependent code in an attempt to make meteor DB agnostic (independent of the specific database).
But the rules were not written to us, so I took a chance and next time I will tell you how to load a 4-core server with a small promo site, raise several meteor instances to balance and not go crazy about the constant calls with shouts that nothing does not work.
PS All examples on CoffeeScript. And you can find me here: @thought_sync and http://github.com/Termina1
PPS And EvilFaeton also said that there are few pictures, so here is your morning bonus from the ResumUP team.
So be it.
opening speech
Meteor is one of the most unusual and experimental js frameworks for a long time. Those who say that this is not an MVC framework are certainly right.
One of the 7 principles that authors highlight on the documentation page : "Meteor is an open source tools and integrates, rather than replaces, existing open source tools and frameworks". Thereby they hint that they are not trying to solve problems that have long been solved. This and the fact that one of the so-called “Smart Packages”, which are already integrated into meteor, is the backbone .
')
The main difference between meteor is that it does not try to structure your code like most existing frameworks, it tries to instill a certain way of thinking during development.
Reactivity
Behind this word lies the main idea of the approach. Historically, the traditional JavaScript approach is asynchronous. Despite the fact that there is nothing complicated here, sometimes there are problems in debugging. Sometimes people cannot understand where the code is executed asynchronously and where it is not. There are also such things as CPH (callback pyramid of hell), asynchronous soup, and so on. All of them are designed to identify the code of people who love to write everything in one function. For them, a great variety of flow control libraries and even js dialects were invented. My favorites are flow-js and IcedCoffeeScript .
However, as it turned out, this does not solve the problem, but only allows programmers who have mastered this tao, maliciously chuckling, sending code to their colleagues with a proposal to check and accept pullrequest.
And here we return to meteor. On the meteor start page there are 8 points that describe its main features, we are interested in two: live page updates (on-the-fly page updates) and latency compensation (compensation for delays). Together, these two properties allow you to create magic: to link pieces of templates with data. At the same time, as soon as the data has changed a piece of the template is re-rendered and the client receives the current state of your application, whereas you have not written a single extra line.
fragment = Meteor.render -> name = Session.get("name") or "Anonymous"; "<div>Hello, #{name}</div>" document.body.appendChild fragment Session.set("name", "Bob") # ! The example is taken directly from the documentation. In short, the following happens: there is a “magic” method Meteor.render, which returns a documentFragment and is able to update it at the moment when the data used in its body changes. One condition: the data structure with which we want to associate the template must implement a specific interface. More details can be found in the description of Meteor.deps , as well as “it just works”.
Database on the wire
Further - more, it is cool to associate data with a template, but we still have a lot of routine code that implements data synchronization on the client with data on the server. And here, these guys famously slashed off their shoulders and realized what I adore them for, and most of the js-community mercilessly spread rot. Database Everywhere. They made transparent the process of adding data from the client to the server. You change the collection on the client and it is immediately synchronized via the web sockets with the server. Then the previous two principles come into force and we get that all customers who have been affected by the changes have an up-to-date page before their eyes. That is, in fact, we can directly bind the database and template. It's simple:
Posts = new Meteor.Collection 'posts' if Meteor.isClient $(@el).html Meteor.render -> someTemplateFunction Posts.find({}).fetch() Please note that the line with the declaration of the collection must be executed both on the client and on the server, but the template engine must run on the client.
But what about security? Just a couple of days ago, version 0.5 came out, in which an authorization mechanism was added that works very simply (in fact, these features were already available for a long time in the auth branch):
Posts.allow insert: -> false update: -> false remove: -> false fetch: -> true We have just forbidden any actions to do with the Posts collection, except for selections. Details can be read in the documentation or on github .
At the moment there is a problem with large collections, as the process of synchronization takes a lot of time and memory. Now these problems are being solved, for example, here .
As a result, meteor allows us to write code that is initially focused on data and their changes. We remove the need to think about the transfer of information and how we keep html up to date after changes on the server.
It remains to add one small stroke and say that initially all the code you write is executed on the server and on the client, which means that data structure definitions can be described once and they will be the same everywhere. And, as you know : “Bad programmers worry about the code. Good programmers worry about data structures and their relationships. ”
But the code that refers only to the client part or should be executed only on the server should be stored in the client and server folders, respectively. In general, convention over configuration .
Deploy?
Deployment mechanism is built into the framework itself, but for now it can be deployed only to the meteor.com subdomains, which is certainly not cool. For those who already want to deploy meteor-applications on their servers in the documentation there is a detailed instruction . Well, I wrote a small cake task that automates this process. You will need to install the nver-packages NodeSSH and scp installed on the server forever and installed for the current project. To install the latest, go to the project folder / .meteor / local / build / server / and type: "npm install NodeSSH scp". To start deployment, you just need to type "cake deploy".
And finally
And finally, I want to assure you that all environments and all frameworks fade in front of meteor when it comes to usability. There are two reasons for this, meteor practically doesn’t limit you where and what files you want to store, and the second is “Smart Packages”. I, as a person who has long ceased to program on pure js and use pure css, simply trudge from the fact that any file created in the project directory should be connected to the page, and if I type a simple command in the console: meteor add coffeescript, then The .coffee file created by me will automatically be compiled into js and will be added to the page. The same can be said about things like less, stylus, sass, etc.
Various jquery plugins, framework languages and much more are just as easy to add. As the number of “Smart Packages” grows, meteor will become more and more convenient, but even now there is almost everything needed to develop a full-fledged one page app.
As for the community, it pleases. If you go to the irc channel chat.freenode.net #meteor, they will definitely help you or at least try to help. The issue in github responds quickly, and discussions are quite active.
Despite all the praises, meteor is still not ready for serious production decisions. Also, it is very sad that the authors so strongly attached their decision to mongo. Not that mongo is a bad database, but not fashionable anymore. I anticipate that, one day, the authors will have to spend a decent amount of time cutting out the mongo-dependent code in an attempt to make meteor DB agnostic (independent of the specific database).
But the rules were not written to us, so I took a chance and next time I will tell you how to load a 4-core server with a small promo site, raise several meteor instances to balance and not go crazy about the constant calls with shouts that nothing does not work.
PS All examples on CoffeeScript. And you can find me here: @thought_sync and http://github.com/Termina1
PPS And EvilFaeton also said that there are few pictures, so here is your morning bonus from the ResumUP team.
References:
- github: https://github.com/meteor/meteor
- stackoverflow: http://stackoverflow.com/questions/tagged/meteor
- Do geniuses: http://meteor.com/about/people
Source: https://habr.com/ru/post/155579/
All Articles