Our view: Meteor vs Derby
From the translator : I didn’t see any materials on the Derbyjs framework, which is often referred to as the main competitor of Meteor, in Habré. Under the cut, a comparison of these two frameworks made by the authors of Derby. Comparison is already more than a year old, but I think it will be interesting for those who have not read.
We are often asked to compare these two products. I would like to thank Nick Retallack, who did a great job comparing them in our group: Google Group . Part of his conclusions will be used in this article.
First of all, I would like to note that for the first time Brian and I met with the Meteor team in November, during a demonstration of an early version of Derby at the Keeping it Realtime conference, organized by & yet . When we met, the Meteor team had already begun developing its own framework, and the similarities could be seen with the naked eye. A little earlier, I also met with David Greenspan (who recently joined Meteor), it was interesting to talk and discuss his experience of creating an Etherpad . Our teams are friends, communicate and learn a lot from each other.
We are united by a common vision of the world, where all applications work “in real time” and “in collaboration mode”. We, like many other developers, a year and a half ago, suddenly became acutely aware that using modern approaches to web development, it is extremely difficult to create a positive user experience, especially where data is dynamically updated.
')
Brian and I discussed this a year ago. At that time, I was a product manager on the Google Search team, and he was involved in several open source Node.js projects, including Mongoose and everyauth . I was interested in developing this framework, since I thought it was best to create applications with the performance I needed, and Brian felt that Node.js community needed an easy-to-use framework for developers who prefer Rails or PHP.
Working in Google Search, I realized that in order for the application to be responsive, it is critical to generate web pages, both on the server and on the client. Google is able to do this - there are a lot of developers, and speed is paramount when searching. To achieve fast downloads and fast updates, in Google Search all the code for generating pages is half written in C ++ and only half in JavaScript. Over the past couple of years, they have launched several projects to simplify this task, but it’s not worth saying that such a development process is too expensive and useless for startups or complex applications.
Gmail, Twitter, and other sites that are rendered only on the client are loading too slowly. Twitter went through a full circle - they started with a full server generation on Rails, then transferred the entire generation to the client, receiving as a result that reading the 140 character message began to take 4 seconds for the user. Now Twitter forms half of the page on Scala on the server, and then the other half on JavaScript on the client. All this together makes the code support more complex and means that less important parts of the page appear only a few seconds after the page is fully loaded. People are very sensitive to change, and newly emerging elements divert attention from more important ones.
Due to the rebirth of JavaScript performance in V8 and the ease of creating JavaScript servers with Node.js, many developers were inspired by the idea of using JavaScript on both the client and the server. But despite this amazing opportunity, only some applications use shared code. Even with one language, there are still a lot of problems, including: differences in delays and connection stability, differences in the way the URLs work on the server and in the browser, the DOM existence in the browser and its absence on the client, and finally, direct access to the file system only on the server.
Considering all this, our teams decided to move along similar paths in some issues, and completely different in others. Derby's goal is to give any developer the opportunity to write applications that load as fast as the search engine, just as interactive as a text editor and working offline. Quoting Jeff (Geoff), Meteor's goal is to create a “platform for a wide market” used in 90% of websites on the Internet, and for these 90% to make web development as fast as possible. ”
Currently, Meteor is available only under the GPL license. This means that if you do not want to publish your source code under a GPL or compatible license, you will need to contact them and agree on a commercial license.
Derby, Racer and all other components of our framework are published under the free MIT license. You can do whatever you want with your application, and we will not be able to stop you now or in the future.
I am not a lawyer, so you should not take everything that I just said quite literally. I did not see the future in a crystal ball or something like that. (Yes, our lawyer once asked me to mention this.)
Meteor has created its own packet system and package distribution tool.
Node.js modules follow the well-described CommonJS standard and have a built-in modular API. However, initially the package distribution system was missing. At the very beginning, Node.js had several package managers, but most developers have now stopped using npm . It is so versatile that it is even included in the distribution with Node.js.
Frankly, this is the main thing that worries me in Meteor. It’s as if people trying Meteor have never used Node.js and are not aware of the benefits of distributing packages through npm . I, and many other developers, see the key force of Node.js in npm, and it will be very sad to see its weakening by an incompatible package system.
As in many other Node.js projects, we distribute Derby, Racer and their plugins as npm modules. And we will continue to break our project into small modules, so that it is easier for them to use others. You may not be using Derby, but you need to parse the HTML. We needed to write a simple and fast HTML parser for the operation of our template system, and you can use it in your Node.js projects. Connect is an excellent example of a project with a rich ecosystem of modules based on it and distributed through npm, and we also hope to follow this path.
Meteor allows you to replace parts of your modules with other libraries. The flexibility of this approach is particularly noticeable in the case of client libraries, although they must first be wrapped like Meteor modules.
Meteor usually manages the creation of the server in its own way. This makes the process of creating and deploying Meteor applications to their server extraordinarily simple, but at the same time makes it very difficult to use Meteor as a module on a regular Node.js server.
In contrast, Derby is a regular npm module that can be added to any Node.js server. If you want to use one of the 8900 npm modules (now 39 thousand - approx. Lane), just add them to your package.json file and run
Derby does not provide any hosting solution, as there are already many excellent hosting services on the market. In the future, we will provide instructions on how to quickly install and run Derby on any public server.
Racer (the real-time engine that drives models in Derby) is a separate module, and can be used independently of Derby. You can infiltrate into any Racer UI level and control the methods invoked when the model is updated. Racer is based on the popular module, Socket.IO , which can be accessed directly if necessary.
The Derby core also uses several popular libraries, especially Express for routing and Browserify , which automatically packs most Node.js modules for the browser.
Meteor uses the MongoDB API directly in the browser. MongoDB API is powerful and easy to use from JavaScript. It is already used to it, certain development patterns have emerged, and, in general, it is sufficient for solving most of the tasks that may arise during the development of an application. It seems that many people find this approach quite convenient for creating applications, since it removes the need to understand the layers of abstraction. Some people talk about security problems, but I think you shouldn’t judge them strictly until the Meteor team brings to light its approach to authentication and authorization.
Racer has its own API, built around “data modification methods” and “paths”. This API allows 1: 1 to connect to any document-oriented storage, including MongoDb. This of course has its pros and cons, but we believe that this is better for several reasons:
“Ways” and “methods” are great for conflict resolution techniques, which, we expect, will be one of the biggest advantages of Racer. Now, by default, we use the “last write changes wins” technique, which is equivalent to how Meteor saves data. However, we have a preliminary implementation of the conflict resolution system through Software Transactional Memory and Operational Transformation methods. These techniques allow you to use Derby applications offline, and then synchronize correctly. It also becomes possible to implement things in the style of Google Docs - simultaneous simultaneous editing of content in one text field.
Our “paths” and “methods” are flexible enough to take advantage of most data warehouses, switch from one to another, and even use several of them at the same time. Switching between Riak, Postgres, CouchDb or any other service occurs without the need to modify the source code.
Our “paths” are perfectly combined with the PubSub mechanism, this is how we synchronize data changes in real time. In the implementation of LiveMongo in Meteor, the data is simply recorded in the database, then the database is periodically polled for changes, and for each client. The advantages of their query pool are that any Mongo request can be applied to the database, we have implemented a wrapper for most PubSub requests without having to access the database. We do not have obvious evidence so far, but we expect that PubSub scales much better than the pool of requests to the database.
It will be possible to make extensions that act as data warehouses, even if they interact with other servers or using third-party APIs. Database adapters are built at a fairly high level of abstraction, so they can be used very differently ...
Derby is one of a small number of frameworks designed so that the same page generation code and routing work simultaneously on both the server and the browser. You can even use Derby to generate static pages that use the same templates as dynamic applications.
This means that you get very fast loading pages right out of the box. Even simple applications that generate a page on the client load and render pages take 1 to 2 seconds. In simple Derby applications, the “onload” event is triggered after 200 ms. The more complex the application becomes, the greater the increase in speed due to server pregeneration.
Many large companies, such as Google, Amazon and Facebook, allocate enormous resources to optimize page load times, as this directly affects conversion and revenue. I almost died that day when Gmail added a progress bar with a load indication. Never do that.
In addition, the generation of pages on the server is crucial for SEO, and provides access to browsers and readers that do not support JavaScript.
The routing module ( routes ) in Derby on the server is a middleware module Express, so you can use it in conjunction with other Express server routes, for example, to download files, and you can even write many applications that use different sets of routes on the same Express server. For example, you can write a separate admin or mobile application that will not download all the code of the desktop version.
While Derby provides you with all the benefits of speed and availability of a regular multi-page application, it also gives you the opportunity to create a fully optimized single-page application that can generate any template and route directly in the browser. Client routing allows you to simply draw a link by reference without reloading the page, you do not need to use any specific API for routing. Just set up a regular link on the client, and Derby will do everything for you.
Meteor does not have this feature, although they have recently rewritten their template engine and can add it .
Meteor uses a reactive programming approach to update templates, which gives you the potential to work with any template engine. When generating from a template, all data used for generation is tied to the resulting part of the page. After changing the data, the template is re-generated and the result is compared with the existing part of the DOM. And after that, Meteor replaces only obsolete pieces of DOM with minimal intervention. The big advantage of this approach is the simplicity and ability to use any template language.
In contrast, Derby uses its template based on Handlebars. Bindings are explicitly defined, and the HTML template requires parsing to calculate the parts of the DOM that need to be updated. Unlike Meteor, in Derby the bindings work in two ways - when the elements are attached, the model automatically changes if the user enters something in the edit field, marks the check box, or selects an element from the drop-down list. You can also either bind all the data, or to optimize manually set the bindings of only the necessary data. The output of unrelated data may be preferable if the developer plans to manually update the view by manipulating the elements of the DOM.
Here, the differences are quite small - Meteor uses CSS selectors in templates, and Derby HTML attributes to bind event handlers. jQuery and Backbone made CSS selectors popular; Knockout and Angular use HTML attributes.
We prefer HTML markup , since it is more difficult to understand which CSS selector is responsible for the necessary elements, and it often happens that the HTML structure changes, imperceptibly destroying CSS selectors. With markup, it is less likely that function names will be accidentally changed and an exception will be thrown that the required function was not found.
Derby uses an innovative approach to bubbling events, which is more intuitive and understandable in comparison with the traditional approach. Instead of floating up events up through the DOM nodes to the very root, Derby stops the ascent when the first tied handler finds it, and, as with the routes, you can continue the ascent of events by calling next ().
Meteor uses Fibers , a Node.js extension that makes it possible to write code that looks synchronously, instead of the code traditional for most Node projects, based on a chain of callbacks. Someone likes this way of writing asynchronous code, someone is totally against it. There are many arguments, both for and against.
The question is controversial, at the moment we prefer to stand aside from it. A very small percentage of npm modules are written in this style, and we follow a more traditional approach to Node.js with callbacks.
You can achieve almost the same result with both frameworks. Both are powerful tools for developing programs that would be difficult to do using traditional web frameworks such as Rails or PHP.
Derby focuses more on support for technologies such as conflict detection, support for offline clients and extremely fast page generation. We are also more focused on compatibility with other modules that exist in the Node.js ecosystem, and are licensed to open.
Ultimately, we all try to create the best tools for developers and the competitive spirit will only generate more innovation. We are pleased to see other approaches in products such as Meteor , SpaceMagic or Firebase , since we all learn from each other. In the end, this will lead to better tools, a better web and more convenience for our users.
From the translator : In the time since the writing of the review, the products have grown, in a nutshell, what has changed in Meteor:
1. Meteor is now also released under the MIT license.
2. It became possible to use npm-modules, though not directly in the application - first they need to be wrapped in a wrapper from Meteor-packages
3. Meteor has normal authorization, authentication.
4. As for the server-side page generation, this possibility is incorporated in Spark (an intermediate DOM generation module, located under the handlebars in Meteor), but not yet implemented. Indexing of pages is possible by connecting the spiderable module - it works with both Google and Yandex.
If someone can tell what else has changed in Meteor or Derby - please comment.
PS When translating used: Thoughts on DERBY VS METEOR
We are often asked to compare these two products. I would like to thank Nick Retallack, who did a great job comparing them in our group: Google Group . Part of his conclusions will be used in this article.
How it all began
First of all, I would like to note that for the first time Brian and I met with the Meteor team in November, during a demonstration of an early version of Derby at the Keeping it Realtime conference, organized by & yet . When we met, the Meteor team had already begun developing its own framework, and the similarities could be seen with the naked eye. A little earlier, I also met with David Greenspan (who recently joined Meteor), it was interesting to talk and discuss his experience of creating an Etherpad . Our teams are friends, communicate and learn a lot from each other.
We are united by a common vision of the world, where all applications work “in real time” and “in collaboration mode”. We, like many other developers, a year and a half ago, suddenly became acutely aware that using modern approaches to web development, it is extremely difficult to create a positive user experience, especially where data is dynamically updated.
')
Brian and I discussed this a year ago. At that time, I was a product manager on the Google Search team, and he was involved in several open source Node.js projects, including Mongoose and everyauth . I was interested in developing this framework, since I thought it was best to create applications with the performance I needed, and Brian felt that Node.js community needed an easy-to-use framework for developers who prefer Rails or PHP.
Holy Grail: servile and client code
Working in Google Search, I realized that in order for the application to be responsive, it is critical to generate web pages, both on the server and on the client. Google is able to do this - there are a lot of developers, and speed is paramount when searching. To achieve fast downloads and fast updates, in Google Search all the code for generating pages is half written in C ++ and only half in JavaScript. Over the past couple of years, they have launched several projects to simplify this task, but it’s not worth saying that such a development process is too expensive and useless for startups or complex applications.
Gmail, Twitter, and other sites that are rendered only on the client are loading too slowly. Twitter went through a full circle - they started with a full server generation on Rails, then transferred the entire generation to the client, receiving as a result that reading the 140 character message began to take 4 seconds for the user. Now Twitter forms half of the page on Scala on the server, and then the other half on JavaScript on the client. All this together makes the code support more complex and means that less important parts of the page appear only a few seconds after the page is fully loaded. People are very sensitive to change, and newly emerging elements divert attention from more important ones.
Due to the rebirth of JavaScript performance in V8 and the ease of creating JavaScript servers with Node.js, many developers were inspired by the idea of using JavaScript on both the client and the server. But despite this amazing opportunity, only some applications use shared code. Even with one language, there are still a lot of problems, including: differences in delays and connection stability, differences in the way the URLs work on the server and in the browser, the DOM existence in the browser and its absence on the client, and finally, direct access to the file system only on the server.
So, to the point!
Considering all this, our teams decided to move along similar paths in some issues, and completely different in others. Derby's goal is to give any developer the opportunity to write applications that load as fast as the search engine, just as interactive as a text editor and working offline. Quoting Jeff (Geoff), Meteor's goal is to create a “platform for a wide market” used in 90% of websites on the Internet, and for these 90% to make web development as fast as possible. ”
GPL vs MIT
Currently, Meteor is available only under the GPL license. This means that if you do not want to publish your source code under a GPL or compatible license, you will need to contact them and agree on a commercial license.
Derby, Racer and all other components of our framework are published under the free MIT license. You can do whatever you want with your application, and we will not be able to stop you now or in the future.
I am not a lawyer, so you should not take everything that I just said quite literally. I did not see the future in a crystal ball or something like that. (Yes, our lawyer once asked me to mention this.)
System packages Meteor vs npm
Meteor has created its own packet system and package distribution tool.
Node.js modules follow the well-described CommonJS standard and have a built-in modular API. However, initially the package distribution system was missing. At the very beginning, Node.js had several package managers, but most developers have now stopped using npm . It is so versatile that it is even included in the distribution with Node.js.
Frankly, this is the main thing that worries me in Meteor. It’s as if people trying Meteor have never used Node.js and are not aware of the benefits of distributing packages through npm . I, and many other developers, see the key force of Node.js in npm, and it will be very sad to see its weakening by an incompatible package system.
As in many other Node.js projects, we distribute Derby, Racer and their plugins as npm modules. And we will continue to break our project into small modules, so that it is easier for them to use others. You may not be using Derby, but you need to parse the HTML. We needed to write a simple and fast HTML parser for the operation of our template system, and you can use it in your Node.js projects. Connect is an excellent example of a project with a rich ecosystem of modules based on it and distributed through npm, and we also hope to follow this path.
Compatible with other libraries
Meteor allows you to replace parts of your modules with other libraries. The flexibility of this approach is particularly noticeable in the case of client libraries, although they must first be wrapped like Meteor modules.
Meteor usually manages the creation of the server in its own way. This makes the process of creating and deploying Meteor applications to their server extraordinarily simple, but at the same time makes it very difficult to use Meteor as a module on a regular Node.js server.
In contrast, Derby is a regular npm module that can be added to any Node.js server. If you want to use one of the 8900 npm modules (now 39 thousand - approx. Lane), just add them to your package.json file and run
npm install .Derby does not provide any hosting solution, as there are already many excellent hosting services on the market. In the future, we will provide instructions on how to quickly install and run Derby on any public server.
Racer (the real-time engine that drives models in Derby) is a separate module, and can be used independently of Derby. You can infiltrate into any Racer UI level and control the methods invoked when the model is updated. Racer is based on the popular module, Socket.IO , which can be accessed directly if necessary.
The Derby core also uses several popular libraries, especially Express for routing and Browserify , which automatically packs most Node.js modules for the browser.
MongoDB API vs Racer Methods
Meteor uses the MongoDB API directly in the browser. MongoDB API is powerful and easy to use from JavaScript. It is already used to it, certain development patterns have emerged, and, in general, it is sufficient for solving most of the tasks that may arise during the development of an application. It seems that many people find this approach quite convenient for creating applications, since it removes the need to understand the layers of abstraction. Some people talk about security problems, but I think you shouldn’t judge them strictly until the Meteor team brings to light its approach to authentication and authorization.
Racer has its own API, built around “data modification methods” and “paths”. This API allows 1: 1 to connect to any document-oriented storage, including MongoDb. This of course has its pros and cons, but we believe that this is better for several reasons:
Conflict resolution
“Ways” and “methods” are great for conflict resolution techniques, which, we expect, will be one of the biggest advantages of Racer. Now, by default, we use the “last write changes wins” technique, which is equivalent to how Meteor saves data. However, we have a preliminary implementation of the conflict resolution system through Software Transactional Memory and Operational Transformation methods. These techniques allow you to use Derby applications offline, and then synchronize correctly. It also becomes possible to implement things in the style of Google Docs - simultaneous simultaneous editing of content in one text field.
Data Store Interchangeability
Our “paths” and “methods” are flexible enough to take advantage of most data warehouses, switch from one to another, and even use several of them at the same time. Switching between Riak, Postgres, CouchDb or any other service occurs without the need to modify the source code.
PubSub Efficiency (Publish / Subscribe to Data Changes)
Our “paths” are perfectly combined with the PubSub mechanism, this is how we synchronize data changes in real time. In the implementation of LiveMongo in Meteor, the data is simply recorded in the database, then the database is periodically polled for changes, and for each client. The advantages of their query pool are that any Mongo request can be applied to the database, we have implemented a wrapper for most PubSub requests without having to access the database. We do not have obvious evidence so far, but we expect that PubSub scales much better than the pool of requests to the database.
Extension API
It will be possible to make extensions that act as data warehouses, even if they interact with other servers or using third-party APIs. Database adapters are built at a fairly high level of abstraction, so they can be used very differently ...
Server page generation and general routing
Derby is one of a small number of frameworks designed so that the same page generation code and routing work simultaneously on both the server and the browser. You can even use Derby to generate static pages that use the same templates as dynamic applications.
This means that you get very fast loading pages right out of the box. Even simple applications that generate a page on the client load and render pages take 1 to 2 seconds. In simple Derby applications, the “onload” event is triggered after 200 ms. The more complex the application becomes, the greater the increase in speed due to server pregeneration.
Many large companies, such as Google, Amazon and Facebook, allocate enormous resources to optimize page load times, as this directly affects conversion and revenue. I almost died that day when Gmail added a progress bar with a load indication. Never do that.
In addition, the generation of pages on the server is crucial for SEO, and provides access to browsers and readers that do not support JavaScript.
The routing module ( routes ) in Derby on the server is a middleware module Express, so you can use it in conjunction with other Express server routes, for example, to download files, and you can even write many applications that use different sets of routes on the same Express server. For example, you can write a separate admin or mobile application that will not download all the code of the desktop version.
While Derby provides you with all the benefits of speed and availability of a regular multi-page application, it also gives you the opportunity to create a fully optimized single-page application that can generate any template and route directly in the browser. Client routing allows you to simply draw a link by reference without reloading the page, you do not need to use any specific API for routing. Just set up a regular link on the client, and Derby will do everything for you.
Meteor does not have this feature, although they have recently rewritten their template engine and can add it .
Data Binding Models and Views
Meteor uses a reactive programming approach to update templates, which gives you the potential to work with any template engine. When generating from a template, all data used for generation is tied to the resulting part of the page. After changing the data, the template is re-generated and the result is compared with the existing part of the DOM. And after that, Meteor replaces only obsolete pieces of DOM with minimal intervention. The big advantage of this approach is the simplicity and ability to use any template language.
In contrast, Derby uses its template based on Handlebars. Bindings are explicitly defined, and the HTML template requires parsing to calculate the parts of the DOM that need to be updated. Unlike Meteor, in Derby the bindings work in two ways - when the elements are attached, the model automatically changes if the user enters something in the edit field, marks the check box, or selects an element from the drop-down list. You can also either bind all the data, or to optimize manually set the bindings of only the necessary data. The output of unrelated data may be preferable if the developer plans to manually update the view by manipulating the elements of the DOM.
DOM event handlers
Here, the differences are quite small - Meteor uses CSS selectors in templates, and Derby HTML attributes to bind event handlers. jQuery and Backbone made CSS selectors popular; Knockout and Angular use HTML attributes.
We prefer HTML markup , since it is more difficult to understand which CSS selector is responsible for the necessary elements, and it often happens that the HTML structure changes, imperceptibly destroying CSS selectors. With markup, it is less likely that function names will be accidentally changed and an exception will be thrown that the required function was not found.
Derby uses an innovative approach to bubbling events, which is more intuitive and understandable in comparison with the traditional approach. Instead of floating up events up through the DOM nodes to the very root, Derby stops the ascent when the first tied handler finds it, and, as with the routes, you can continue the ascent of events by calling next ().
Fibers
Meteor uses Fibers , a Node.js extension that makes it possible to write code that looks synchronously, instead of the code traditional for most Node projects, based on a chain of callbacks. Someone likes this way of writing asynchronous code, someone is totally against it. There are many arguments, both for and against.
The question is controversial, at the moment we prefer to stand aside from it. A very small percentage of npm modules are written in this style, and we follow a more traditional approach to Node.js with callbacks.
Let's sum up
You can achieve almost the same result with both frameworks. Both are powerful tools for developing programs that would be difficult to do using traditional web frameworks such as Rails or PHP.
Derby focuses more on support for technologies such as conflict detection, support for offline clients and extremely fast page generation. We are also more focused on compatibility with other modules that exist in the Node.js ecosystem, and are licensed to open.
Ultimately, we all try to create the best tools for developers and the competitive spirit will only generate more innovation. We are pleased to see other approaches in products such as Meteor , SpaceMagic or Firebase , since we all learn from each other. In the end, this will lead to better tools, a better web and more convenience for our users.
From the translator : In the time since the writing of the review, the products have grown, in a nutshell, what has changed in Meteor:
1. Meteor is now also released under the MIT license.
2. It became possible to use npm-modules, though not directly in the application - first they need to be wrapped in a wrapper from Meteor-packages
3. Meteor has normal authorization, authentication.
4. As for the server-side page generation, this possibility is incorporated in Spark (an intermediate DOM generation module, located under the handlebars in Meteor), but not yet implemented. Indexing of pages is possible by connecting the spiderable module - it works with both Google and Yandex.
If someone can tell what else has changed in Meteor or Derby - please comment.
PS When translating used: Thoughts on DERBY VS METEOR
Source: https://habr.com/ru/post/191664/
All Articles