Concurrent editing with Meteor

Concurrent editing with Meteor

Editing the same document at the same time by two editors is a key feature of an online IDE we’re currently working on. The application is built with Meteor. Which options are there to implement concurrent editing based on operational transformation?

Existing packages

Installing mizzao:sharejs edemaine:sharejs

Fortunately, Atmosphere provides us with packages which cater for this functionality. The most used one is mizzao:sharejs and its variants containing ACE and Codemirror as code editors. For analysis we’ll create a demo app using it:

meteor create ot-mizzao-sharejs
cd ot-mizzao-sharejs
meteor add mizzao:sharejs

In the next step we integrate the text area in client/main.html:

  {{> sharejsText docid="test" id="editor"}}

Unfortunately, starting Meteor gives us an error:

ReferenceError: ShareJS is not defined
     at sharejs-server.js (packages/mizzao:sharejs/sharejs-server.js:8:24)

The problem is known since over a year and can be fixed by replacing the package with edemaine:sharejs:

meteor remove mizzao:sharejs
meteor add edemaine:sharejs

This package is preconfigured to use an in-memory database for the transactions. To use Mongo, a settings file, e.g. settings.json, must be created and used for starting the server:

"sharejs": {
"options": {
"db": {
"type": "mongo",
"opsCollectionPerDoc": true
meteor --settings settings.json

Now, it works. 

No design, just functional: Editing the same document at the same time finally works.

Behind the scenes

The network tab of the developer toolbar reveals the communication between the browser and the server:

Let’s take a look at the network tab!

It shows two connections:

  • The standard websocket connection of Meteor
  • A second connection using long polling for ShareJs

Using Mongo to store the transformations creates a number of tables:

The Mongo collections created for this example.

A docs table contains the content of all documents. For every document an ops table is created, just like ops.test in our test case. It contains the operational transformations.

Setting the option opsCollectionPerDoc to false will create only one table ops for all documents.

The pros and cons

The great advantage of this solution is the easy integration. It took less than an hour to get this feature working in a basic way. The server API of ShareJS is available to access the documents on the server.

I see the big disadvantage that this solutions creates something like a parallel universe to the Meteor data features, which already provide a real-time communication between client and server using websockets, which can be considered better for this type of communication. The browser opens a second connection to the same server, which needs twice the ports and thus more resources.


Use of native Meteor features for communication

The client does the diffing to generate the transformations. The transformations are collected by the server and written to a published collection (after adapting the transformation to the current state). The client subscribes to the collection and adopts the content of the editor accordingly (keeping in mind, that some transformations might not be processed by the server yet).

This would lead to a pure Meteor OT implementation.

Use the Meteor websocket for ShareJS

The websocket of Meteor is reused for the communication between ShareJS client and server.

This would give all the possibilities and optimizations of ShareJS, which is a well-tested piece of software. There are no API changes, so existing applications based on edemaine:sharejs or mizzao:sharejs will continue to work without any changes.

This project is supported by a netidee grant from the Internet Foundation Austria.

Photo by rawpixel on Unsplash

The VulcanJS Framework

The VulcanJS Framework

After the experiences with Pup I have looked at another part of the Meteor world. VulcanJS is not a boilerplate, but sees itself as a whole framework.

Starting with the cloning or forking of the vulcan-starter repository. Afterwards the necessary npm packages will be installed as well as with Pup.

git clonce
meteor npm install

The standard functionality of VulcanJS is significantly lower than Pup – so the installation is much faster. It takes less than 4 minutes for the Vulcan tutorial to be locally available for the first time – which is a bit more than half the time of what Pup needs.

However, there is a problem with the installation immediately: npm’s automatically running audit reports three vulnerabilities classified as “high” in the used libraries. In any case, the app should not be set productively in that form. However, the problem has now been resolved and a simple solution provided . In the current version 1.12.13 the problem has already been fixed.

The tutorial

The Vulcan-starter repository contains several tutorials that explain step-by-step how to use VulcanJS. Each tutorial runs locally as a meteor application and describes each step directly in the browser. If the mentioned files are changed accordingly, the website is updated automatically and the tutorial continues.

This makes it clear which change is causing what. Related adjustments, even across multiple files, are sometimes explained with alternative solutions. This makes the underlying system easier to understand for the user.

VulcanJS has been in development for several years. The name Vulcan is only used since version 1.3.2 – previously the framework under the name telescope nova was rather unknown. Originally started with the Meteor version 0.8. In order to get to the current state, the framework had to implement many refactoring work. In some places this is still noticeable. Not all tutorials adhere to current Meteor Guide rules and not all videos match the descriptions and the associated source code. But that does not matter much, as these tutorials will are updated bit by bit.

All in all, the tutorial leaves a safe, though not too deep, impression of the feature rich framework.

Another development approach

A direct comparison with Pup is not entirely acceptable, as the template and framework are targeted at different audiences and applications. At Pup you get a starting point for a working app. At VulcanJS, on the other hand, you get the tools needed to do this, including an enrollment. When developing a new app both approaches can be followed and here I would like to respond to the differences.

If you have started a project with Pup, then the current version of the boilerplate will inevitably be used as a basis for the project. A later update of this basis is relatively difficult, because you changed exactly this boilerplate for your own purposes.

This is different with VulcanJS. Your own application is developed from the beginning as a package, encapsulated from the framework. As a result, an update to a new version of VulcanJS can be performed easily and the code can be adapted to any changed functionality faster. If you need more profound changes in the process, VulcanJS offers different entry points in your own packages – so-called hooks.

How to understand this package-based architecture is explained in the documentation.

Furthermore, VulcanJS differs from Pup in the choice of packages used. Instead of Bootstrap or Fur, the styling is not bound to any particular library. Instead, the user can choose what fits. The separation between modules and UI elements with the extension .jsx in the file name is also helpful.

Instead of the graphQL Playground in Pup, VulcanJS uses the graphiQL IDE to access the graphQL API. Instead of prepared and separately stored resolvers, mutations and queries at Pup, VulcanJS explains what makes a resolver and collects related data together.

The initial database filling with random values ​​that was implemented at Pup with the in-house Seeder Package is missing from VulcanJS. Start values ​​are created here only statically – the contribution of a random component or interdependent data must be implemented by yourself.

VulcanJS also provides simple support for multilingual text output with the I18n Package.

Conclusion and recommendation

Basically I can say: The further and more limited the functionality of the app to be developed has already been specified, the more I would advise to use Pup. If the requirements are rather vague or if the skills in handling Meteor are not yet established, we recommend the use of VulcanJS.

A comment from the package maintainer

Sacha Greif commented the article on the Meteor forum:

Thanks for the review! You touched on it, but I think the key difference is that Pup is a boilerplate, while Vulcan is a framework. In other words the way Vulcan is architectured, you can easily add/remove/update packages at any point in your app’s lifetime, whereas with a boilerplate you’re kind of on your own after you start. I think they both have their pros and cons, like you pointed out.

(I also think Vulcan and Pup might differ when it comes to actual features, but I’m not familiar enough with Pup to really say)

Boilerplates for prototypes

Boilerplates for prototypes

A good start is half the battle..

Such or similar statements also apply to the development of web applications. Anyone who starts with the right tools, in a suitable environment and with a solid foundation, may later not have to tediously restructure the app. Design patterns and best practices in general are often taken very seriously in boilerplates, giving the developer clear guidelines.

With this mindset I have looked at the “Ultimate Boilerplate for Products” Pup from This is a template for the development of a web application based on Meteor, React, MongoDB and GraphQL. Subsequently I want to answer the question to what extent boilerplates help us with the development of prototypes and when they may actually hinder us.

What does Clever Beagle’s Tool Pup have to offer?

With the installation of Pup (currently in version v2.0.1) you get the executable source code of a small web application for managing Markdown documents. The app contains components to realize the following tasks:

  • User registration via OAuth and user administration via an admin panel
  • Sending e-mails based on HTML and text templates
  • Automatic generation and indexing of a random database set
  • Table definitions via GraphQL and an own GraphQL Playground
  • Create a sitemap and SEO metadata with app details
  • Routing setup for public and authenticated requests
  • Server side rendering (SSR) for faster presentation in the browser
  • Form validation
  • Styling and customization via bootstrap and styled-components
  • Browser policies for protection against XSS
  • Data export, account deletion and declaration of consent according to GDPR / DSGVO
  • Local git repository with an own Linter Script Hooks
  • Unit and end-to-end (E2E) tests
  • Configuration for Development / Staging / Production Settings
  • Complete workflow for app releases and continuous integration including DNS entries, SSL certificates and hosting on Meteor Galaxy (Requires additional access data)

This list is constantly being expanded, as Pup always strives to relieve the developers even more and cover more areas through this boilerplate.

Continue reading

Gatsby: Static Website, super optimized

Gatsby: Static Website, super optimized

For many websites a static site is absolutely sufficient. They offer a number of advantages: Undemanding hosting, secure against malicious content changes, short loading times. Various tools are available to generate these static pages. One of them is Gatsby, which is characterized by the optimization for low latency by creating the website as a so-called progressive web app: The first time you open it, only the required content is loaded to display the page. Further information is then saved in the browser in the background, so that further page changes are possible without waiting time.

Other innovations of the last years are used as well: React as component-based framework for the user interface, GraphQL as query language, Webpack for the bundling. In addition to static files, external sources or CMS can also be used for the content via APIs.

qnipp has built an atlas showing the childcare facilities of the Austrian state Burgenland using Gatsby (Kinderbetreuungsatlas der Arbeiterkammer Burgenland). He showed at the Linuxwuochen in Eisenstadt and Vienna the possibilities and shared his experiences.

The presentation is available for Download. This is the video in German language:

Der Inhalt ist nicht verfügbar.
Bitte erlaube Cookies, indem du auf Übernehmen im Banner klickst.

React Native: JavaScript on the smartphone on the fast lane

React Native: JavaScript on the smartphone on the fast lane

App development divides the developers into three groups: The iOS developers, the Android developers and the group of developers, who try their best using Apache Cordova (former PhoneGap). The first two groups concentrate on own mobile OS, the third tries to build platform-independent apps. The latter one leads to disadvantages, as only a browser component is used.

React Native – an Open Source framework created by Facebook – tries to combine the advantages of both worlds: Instead of different languages only one is used, but the created programs use native UI components and do not have to hide behind the native app in terms of performance.

Franz Knipp showed at the Linuxwochen in Eisenstadt the first steps to create such an app und spoke about his experiences.

The presentation is available on Prezi. The video is in German:

Der Inhalt ist nicht verfügbar.
Bitte erlaube Cookies, indem du auf Übernehmen im Banner klickst.

We’ve created our first CSR report

We’ve created our first CSR report

How would an economy look like, where the primary objective of economic activity is not the money, but the common good?

Following this questions I created my first common good bilance for my company qnipp – not alone, we’ve been a group of four entrepreneurs, who discussed the topics of the economy for the common good.  We rated our companies in the fields of human dignity, solidarity, environmental sustainability, social justice, democratic participation and transparency. We thought of the supply chain, the funders, the staff, the customers and the social environment.


Finally, a score is determined using a matrix, which is evaluated by an external auditor, who creates an official certificate. You can find an English translation of the matrix here.



So, I reached 483 of 1.000 points. For me, the score is not as important as the confrontation with the theme and the detection of fields for improvement.

The bilance


Gemeinwohl-Bilanz qnippThe Common Good Bilance (available in German) gives a deep insight into the company qnipp as well as into my role as founder and CEO. It is our first step towards Corporate Social Responsibility.


If you want to find out more about the economy for the common good, visit the website, which is also available in English.

Meteor success story: Teams & Scores

Meteor success story: Teams & Scores

A few weeks ago we delivered the Meteor application Teams & Scores to the Regional association of sport clubs for target shooting in Burgenland.

The main target of the application was to provide an easy way to collect the results of competitions. Flexibility was a core quality, as the score calculation is different from discipline to discipline in target shooting. So, the application can be used for other sport activities as well.

It includes the management of the associated clubs and their members. The permission model is based on the email address of the members and allows the editing depending on their role, e.g. the director of a club may create and edit club members, a club member may edit his own entry, etc.

The application was built immediately after the release of Meteor 1.3. I tried to implement it according the fresh Meteor guide, so I could provide feedback and pull requests to improve the guide. The developer experience using Meteor was as fruitful as expected. The upgrade to the new version brought several changes, the new application is completely based on JavaScript modules and ES6. It uses Blaze for templating and the Flow Router. The Meteor guide was a good source of inspiration, as well as Exploring ES6 written by Dr. Axel Rauschmayer.

The customer is very happy with the new application, is it offers an up-to-date user experience for the competition directors, who enters the results, as well as for the users, who want to look up their scores and standing.

The next step is the implementation of team-based championships.

The application is available at

Meteor packages: Cleaning the package cache

Meteor packages: Cleaning the package cache

Meteor downloads all the packages in the user directory in ~/.meteor/packages. There is no command to clean up this directory, as Meteor doesn’t know the dependencies of all the applications on your computer.

As my partition is always too small, I just wrote a one-liner to solve this problem:

cd ~/.meteor/packages; for i in * ; do pushd $i > /dev/null; ls | sort -V | head -n-1 | while read v ; do rm -rf $v .$v* ; done ; popd ; done

This will delete all but the newest version of every package. If an application needs an older version, it will be downloaded and re-installed by the next start of this application.

It saved me 2.5 GB today. The script works very well in Linux, it should work on Mac OS X as well.

If you delete the link to the meteor command line tool by mistake (it happened to me in the first version of the line above, which contained a bug), you can use the following command to recreate it from the newest version available:

cd ~/.meteor/packages; ln -sf `ls -d packages/meteor-tool/* | sort -Vr | head -n1`/mt-os.linux.x86_64/meteor .

Use all the commands with caution and at your own risk.

Meteor boilerplates: an actual overview

Meteor boilerplates: an actual overview

You want to start a new Meteor project? Instead of starting from scratch with an empty directory and no packages, you could take an existing boilerplate. There’s no official boilerplate, but a number of them are provided by the community.

Meteor boilerplates

The list contains at least the link to the respective Github page. I haven’t tested them, as I created the list as starting point to find a suitable boilerplate for my next Meteor project.

AuthorLatest CommitLanguageRouterTemplateDesignSEOAutoformTable ViewUser and roles administrationCLI
matteodem24.09.2015JavaScriptIronBlazeSemantic UIms-seoorion
yogiben (MeteorFactory)15.01.2016CoffeeScriptIronBlazeBootstrapms-seo

And what else?


The boilerplate by @matteodem contains the command line utility orion to generate the folder structure for the application.

iron-cli is a scaffolding tool for Meteor, which generates the directory structure for Blaze templates, collections, routers, etc. (Tutorial)

Yeoman is a tool for all kinds of web applications, and Google finds various generators for Meteor applications, e.g. for Angular (very active project) and React.

Meteor Kitchen

A different approach ist taken by Meteor Kitchen. The complete application including views, models, navigation structure is generated by a single configuration file. Unfortunately, the project is not published as open source (yet).

My opinion

I’m still choosing the starting point. Let me know your opinion by commenting on this post.