When it comes to building web applications, choosing the right front-end framework is essential. In the case of Meteor, Blaze is a natural choice. Blaze, Meteor's built-in front-end templating engine, offers a range of advantages that make it an excellent companion for Meteor development. In this article, we will delve into the reasons why you should use Blaze with Meteor, highlighting its simplicity, low learning curve, reactivity, component-based approach, and ready-to-use templates. We will also compare Blaze with other popular front-end frameworks to showcase its unique strengths.

1. Simplicity: Blaze was designed with simplicity in mind. Its syntax is similar to HTML, making it intuitive and accessible for developers familiar with web development fundamentals. By leveraging Blaze, you can quickly create dynamic user interfaces without the need for extensive configuration or complex build processes. The straightforward nature of Blaze allows developers to focus on building features rather than spending time on setup and boilerplate code.
2. Low Learning Curve: Blaze's minimalistic approach makes it easy to learn, especially for developers who are new to web development or those transitioning from traditional templating engines. Its simplicity and resemblance to HTML reduce the learning curve, enabling developers to become productive with Blaze in a short amount of time. This ease of adoption makes it an ideal choice for teams looking to onboard new developers quickly or for individuals who want to rapidly prototype their ideas.
3. Reactivity: Blaze is built on Meteor's reactive data system, which enables automatic UI updates when underlying data changes. This reactivity feature eliminates the need for manual DOM manipulation, making the development process more efficient. With Blaze, you can create real-time user interfaces that respond to changes in data without writing additional code. This reactivity extends to both the server and client sides, providing a seamless end-user experience.
4. Components: Blaze embraces a component-based approach, allowing developers to build reusable and modular UI components. With the use of Blaze components, you can encapsulate the structure, behavior, and styling of individual parts of your application. This modular design promotes code reusability, maintainability, and scalability, making it easier to manage and update your UI components as your application grows.
5. Ready-to-Use Templates: Meteor's integration with Blaze offers a vast collection of ready-to-use templates and UI components. The Meteor community has developed numerous Blaze packages that provide pre-built templates for common functionalities such as authentication, forms, data visualization, and more. Leveraging these templates not only accelerates development but also ensures consistent and well-tested UI components for your application.
6. Blaze vs Other Front-end Frameworks: Compared to other popular front-end frameworks like React or Vue.js, Blaze offers a different set of advantages. While React and Vue.js excel in complex and dynamic UI scenarios, Blaze shines in its simplicity and seamless integration with Meteor. Blaze's tight integration with Meteor's reactivity system and its built-in templating engine make it a natural choice for Meteor developers who want a straightforward and productive development experience.

Conclusion: Blaze, when used in conjunction with Meteor, provides a powerful combination for web development. Its simplicity, low learning curve, reactivity, component-based approach, and availability of ready-to-use templates make it an attractive choice for building applications with Meteor. While other front-end frameworks have their strengths, Blaze's tight integration with Meteor's ecosystem and its focus on simplicity set it apart. Whether you're a beginner or an experienced developer, considering Blaze as your front-end framework with Meteor can lead to rapid development, enhanced reactivity, and streamlined UI component management.

The Meteor is a full-stack open-source framework to create Web, Mobile, and Desktop applications.

The main characteristic of the Meteor is using the same language in the Backend and in the Frontend, JavaScript (NodeJS). Due to the new wave of frontend frameworks, the developers need to learn more than one language, besides all concepts of software engineering. Then, to use the same language in the entire project is a blessing.

Only one language in back and front is great, but to can create a Web, Mobile and Desktop application with the same code base is awesome. With Meteor, you can save time and money of course.

Despite using the same language, client and server can be decoupled. Meteor has its own communication protocol between client and server, the DDP (Data Distribute Protocol). It gives a lot of goods to developers, as a default reactivity of data from the database (MongoDB). DDP works inside a Web socket, then you can connect to it using any language which supports Web socket.

An important variable to define how useful a framework can be is how many and how good are its tools (libs).  How about using any NPM Package? Yes, you can import any NPM package to the front or backend. The power of this is infinite.

I've been working with many languages and frameworks along with my professional life, and I ever hate losing hours or days to set up my development environment. It doesn't make sense. Meteor can be installed in Windows, Linux, and Mac using just one command line of NPM (you need NodeJS installed, of course, that is simple to install too). After Meteor is installed, you just need to start your application.

To deploy, you have some directions to follow:

• use a specific Meteor host (Meteor Cloud/Galaxy, Scalingo, NodeChef);
• use a NodeJS host;
• create your own server (Docker, Meteor-Up, Passenger).

The first way has many advantages and is good for beginners. They usually have a free tier to tests.

The documentation is huge, and the community is active. There are tutorials for each type of frontend technology you want to test. Meteor supports the most used frontend frameworks (React, Vue, Blaze, Svelte, and Angular).

If you or your team knows JavaScript, starting with Meteor is very simple, and the results come fast. Save your time!

Meteor is a great Node framework. I love it. Mainly because it is very easy how to prepare a development environment. Just a simple command line. You don't need to worry about the version of Node, database, anything. But when you go to put in production, you have two options: use a specialized host to meteor (Meteor Cloud, Scalingo, NodeChef, etc.) or build your own environment.

I think there are pros and cons to each scenario, and I don't want to discuss them in this article. Here, I just want to show how to prepare your Meteor application to be deployed using a Docker Compose in your own production environment.

With Docker Compose, you can have sure that your application is ready to go to production. You can run it in your own machine, in a server with Docker compose, or in a Docker Swarm cluster.

Now I'm going to stop talking and let's get down to business.

I don't want to teach about Docker concepts, so I'll show a Dockerfile ready, and I'll comment on every step I did.

Creating a Meteor simple application

We'll use a default Meteor Blaze application to complete the task. Choose a specific place in your computer and execute this command:

meteor create --blaze meteor-test

Building my application

We need to build the application to be used inside the docker. Remember, here I'm just showing a simple example to build a Meteor application. There are many other parameters that you can be setting in build time.

Go to the path of your application and execute this command:

cd meteor-test
meteor build --allow-superuser --directory ./build/

The above command will create a build folder with a Node code built inside. We'll use it inside de Dockerfile in the next step.

You will have a warning message like this below, just ignore it:
WARNING: The output directory is under your source tree.
Your generated files may get interpreted as source code!
Consider building into a different directory instead
meteor build ../output

Preparing the Dockerfile

This step is to create a docker image to be used by Docker Compose (or a Stack in the Swarm). Below, is the complete and simple Dockerfile:

FROM node:14.17.5-alpine
LABEL maintainer="Ricardo Aragao"
LABEL meteor.version="2.3.5"

COPY ./build/bundle /bundle
RUN (cd /bundle/programs/server && npm i)

USER node

CMD node /bundle/main.js

Commenting on each line:

FROM: define what node image you'll use as a base to create the image of your application. There are two important points here:

1. The chosen version should be the same as your meteor version. In this case, we are using meteor version 2.3.5 which uses Node version 14.17.5. You can verify in the Meteor Changelog;
2. For this simple example, we are using Linux distro alpine, but sometimes there are some problems with alpine, then use slim to test. Ex: FROM node:14.17.5-slim. You can see other options in the Docker Hub.

LABEL: it is just to add metadata to your file.

COPY: remember that we built that application outside of docker, then this command is to copy the result of the build (a node application) to inside the Docker.

RUN: it will execute a shell command inside the docker in build time. In this case, we are executing the npm i to install all NPM dependencies of your application because meteor build doesn't do.

USER: define the user we'll use to run the node app.

CMD: will execute the application.

Building a Docker Image

After the preparation of Dockerfile, save it in the root of your Meteor project and run this command to build a Docker image:

docker build -t my-meteor-test:latest .

When ended, you can check the image using the command:

docker images

The result will be like this:

REPOSITORY                                                          TAG              IMAGE ID       CREATED       SIZE
my-meteor-test                                                      latest           70abf23d15a3   2 hours ago   271MB

Now you have your application Docker image ready to use with Docker Compose. You can remove the build folder created, you don't need it after this step.

Preparing the Docker Compose file

I prepared a small Docker Compose file as an example:

version: "3.7"

services:
  my-app:
    image: my-meteor-test:latest

    ports:
      - 80:3000
      
    environment:
      NODE_ENV: production
      ROOT_URL: http://localhost
      PORT: 3000

Differently from Dockerfile syntax, a docker-compose file is a YAML file. Each indentation means that that line is inside the other level. By default, we are using 2 spaces to define an indentation.

Commenting on each line:

version: define the version of docker-compose. See the documentation about versions here.

services: define each service (or application) we need to start. In this case, we just will deploy our app.

my-app: the name that I chose for my application.

image: the image's name that I want to use for my service, in this case, the image we built.

ports: the map of the external port to the internal port. 80 is external and 3000 is internal in the example.

environment: here you can put all environment variables that Node or Meteor needs to run.

NODE_ENV: define what environment Node is running.
ROOT_URL: the URL that the app will respond to based on the port exposed.
PORT: port that the application will be running inside the container.

For this simple example, I put just the minimal of environment variables are necessary to power on an app. I'll show others common variables that you will need for real applications:

MONGO_URL: the URL of MongoDB that you use for your application.
MONGO_OPLOG_URL: the URL of OPLOG of MongoDB.
METEOR_SETTINGS: load a string with the settings to Meteor (is a JSON format stringified).

Environment variables can be set on Dockerfile too, but I prefer to use them in a docker-compose to allow us to use the same Docker Image to any environment (tests, staging, production, etc.).

Running the Application

To start the application, execute this command line:

docker-compose up -d

You will see a result like this:

Creating network "meteor-test_default" with the default driver
Creating meteor-test_my-app_1 ... done

Now you can check if the container was created and is running fine executing this command line:

docker ps

The result will be:

CONTAINER ID   IMAGE                   COMMAND                  CREATED              STATUS              PORTS                                   NAMES
2bd396ec088d   my-meteor-test:latest   "docker-entrypoint.s…"   About a minute ago   Up About a minute   0.0.0.0:80->3000/tcp, :::80->3000/tcp   meteor-test_my-app_1

And you can go to the browser and access http://localhost

You'll see:

Let me know if you could publish your application using this article.

References:

1. https://blaze-tutorial.meteor.com/simple-todos/01-creating-app.html#1-2-Create-Meteor-Project
2. https://guide.meteor.com/deployment.html#deploying
3. https://docs.docker.com/engine/reference/builder/
4. https://docs.docker.com/compose/compose-file/compose-file-v3/

First of all, before I explain my process on how to select a framework, it's important to think about why we need to use a framework.

When you start to implement a small software and you are very comfortable with the programming language chosen, a framework can bring excessive tools and extra layers. By the way, if this small solution can grow fast, using a framework can be prepared for future expansion.

If your project has more than one member, it isn't a small project. Use a framework.

In my opinion, the great advantage to using a framework is just because of these points:

1. It has many features ready to use;
2. Many people testing it;
3. Many people help it to improve.

You can create your framework or library set, but using something ready is very smart.

I tend to look for frameworks that use languages that I have some domain or that I plan to have soon.

An important point to analyze in a framework is its documentation and how quickly it is updated. You can check in forums and repositories. Then you need to evaluate the quality. I usually follow tutorials and change them by consulting official documentation to have my perception about it.

When you go to search tips on forums, you can validate the activity of the community. A strong community makes all the difference when you need support.

With the primary contact done you can have your first impression. You need to like how the framework works, don't be deceived. If you don't like it, in a few weeks you will want to change it.

Thus, you can go to the more technical part of your analysis with the below main questions:

1. Have It all the main features that the system needs for the short term?
2. Do the public benchmarks comply with the system demand?
3. How is the update process? Easy, hard?
4. How is the deployment process?
5. How is the learning curve?
6. There are people in the market that know it?
7. There are some companies where you can get help? Paid, of course.
8. There are any available courses?
9. What hardware resources do you need?

There are many other variables that you can evaluate, but if you get these as a base, your choice can be better. Make a spreadsheet and write your results, because we forget quickly.

A concern that you need to have is don't forget how the language works, then you will never have a problem that you cannot solve.

Any framework will help you in 80% of your work and don't so much in 20%. There isn't a silver bullet, but you can be more efficient.