What is your take on Meteor JS?

1

I recently came across Meteor JS (www.meteor.com) a full stack JavaScript app development platform. I started playing around with it and it wasn’t long before I could do something meaningful with it.

Meteor is built on Node.js and is popular for its “database everywhere” concept. So far, I think its a decent platform that gets the job done but then I have read countless reviews against Meteor and most of these reviews bothered on issues with Meteor’s inability to handle complexity on scale and also security loophols.

My take on this is that even though Meteor is more of a journey than a destination, the concept behind it may be the future of web development. @xolubi what’s your view on it?

2

I thought Meteor was frontend, even looking at the features, am not seeing anything tying it to Server Sided JS, However alot of people have recommended Sail.js saying it’s superb but to be honest haven’t given it a try. Am still reluctant as I use Dojotoolkit on Node and there are mostly CLI stuffs not web.

3

Meteor is a full stack development framework. It has option of using Blaze for frontend. (Angular and React Js) are now officially supported in the new release. It uses Node js as server and has a package manager called atmosphere js with over 6k packages. The recent bootstrap 4 release also supports Meteor officially.

4

Hey @henryC, I have not used Meteor so I have no opinion on it. When it comes to web development, I am mostly that backend guy (Sails.js on Node) handling the internals and exposing a set of APIs - leaving the frontend devs to the user interface stack they are comfortable with. At work, we have standardized on AngularJS (though I have been looking at EmberJS and some of the devs have started taking a stab at it).

This post made me take a look at Meteor again and I think it’s rather ambitious, the tightly coupled feel it has to it notwithstanding. But until I take a stab at it for some reason in the future, I’ll refrain from speaking on it.

Cheers.

5

EmberJS is a bit too opinionated and some forced convention (meaning you have to pick up ES6 if you are going with EmberJS 2.0), but it’s good though, I think a simple framework that easily works with others is the best something like (Marionette+AuraJS).

EmberJS/AngularJS are too opinionated for my liking.

6

I’m currently working on my first full project using Meteor - so far it’s been good. I like it feels bundled together at the same time very modular, interestingly {{/routes}} isn’t included out of the box. It has a burgeoning community, who are willing to support however there seem to be an unwritten assumption that you already know JS so the conversations isn’t exactly start out “for dummies”.

I never really got a hang of Angular maybe it’s because of this “opinionated” thing you guys are talking about :smile:

1 Like
7

@udezekene I think one of the really great thing about Meteor is the Modularity and the level of freedom it offers. it’s more like a bunch of software bundled together and yet each of them are very independent.

Yes exactly. It is quite ambitious with the concept behind it. As regards Meteor being tightly coupled; I think it’s a general assumption because Meteor makes extensive use of global variables but there are quite a number of solutions to this.

8

If you think ember and angular are opinionated, wait till you use meteor.

I hate angular with a burning passion (ssh don’t tell my boss) but I’d much rather use it than meteor or ember.

Opinionated is a polite way of saying my way or the highway.

You can be up to speed and productive with ember, angular and meteor quickly, but as soon as you need to deviate from the well-worn path you’ll feel pain all over.

The fact that I can’t grab code from npm and directly use it in my meteor project bothers me.

Ember and meteor’s backend are tightly coupled with the front-end. They “do one thing well”, if you consider your whole app architecture, templating, database, routing, authentication and dependency injection one thing.

My big issue with these monolithic systems is as we make advancements in the web development community, you need to wait till they incorporate it into the framework.

Using a virtual dom is widely regarded as a very good thing. None of those frameworks natively use a virtual dom engine for layouts. You’re already drifting from their opinionated way of doing things.

Microservices are the ideal architectural design for apps. Ember and meteor couple everything tightly together so building a microservice is going away from their opinionated way of doing things.

If you don’t need / want to think hard about what you’re doing, a framework will help. For everything else, loosely coupled components.

9

Thanks this is actually a big experience on my part, I got turned off from Ember because I had to follow a certain convention, and Angular made me frustrated, coming from Dojotoolkit where I can easily use RequireJS to load any module i need and use as much components as i could, trying this in Angular is a nightmare, you will find yourself calling the $apply since you are working outside Angular Scope. Which is why Backbone/Marionette appeals to me as Dojo2.0 is still in development.

But it seems Angular 2.0 is free from Angular 1.x issues, it feels more like React.

10

I have used Meteor on a project for the past 6 months and I love it! I personally think the Meteor team is very ambitious about what they want to achieve wether they get there or not is a different topic but from what I have seen so far I am willing to bet on them and other people are too.

Meteor is quite opinionated (but not as much as Rails) and I genuinely think that is fine. It is a style of creating a framework. You can have a configurational framework where you can spend time setting up and configuring the framework to work and behave as you intend or you can have a conventional framework, where the designers of the framework have made design decisions for you up front and you spend more time creating your app but you need to fully understand the decisions that have been made for you and why.

Both types of frameworks have advantages and disadvantages. Configurational frameworks give you a lot of power in deciding the details of your environment and how they work but there is a longer setup time and things usually take longer to do cause these frameworks cannot assume things you have done hence very little "magic"because there is no convention. This is neither a good thing or a bad thing, it is just a style. Opinionated frameworks are great if its designers are great at designing software, you can get started off quickly and many things can be assumed and done for you because you followed the convention but like @akamaozu said, if you go down a path that is new to the framework there will be pain. All this being said, Meteor is quite new and still rough around the edges but if you come from a Rails background you will feel at home there.

Although I consider @akamaozu a good friend he and I don’t agree on many things and so I am not surprised that he does not like meteor but there are some wrong points he posted that I want to address.

Meteor “CAN” be architected as a monolithic framework but that is the decision of the developer/architect not the framework. The goal of meteor is supposed to be a build once run everywhere philosophy. They have considerations of micro-services architecture as a core part of meteor you can read about it here

Another thing about meteor is that the team is very proactive. They look at the best way to do things and they add this into the framework as soon as humanly possible which I find the most impressive. Like @akamaozu said the virtual DOM is the new hotness and so in the short few months I have been using Meteor they have baked in Facebook React and Angular as a native firstclass front end options alongside Blaze a front-end system they created , hell one of the core developers of Facebook react is on the Meteor team.

Another goal for meteor is for you is to be able to switch out different parts of it as you like freely. Up until recently you only had the option to use Mongo DB for your backend but three weeks ago the public started beta testing the ability to swap out mongo for postgreSQL with MySQL to eventually come down the pipeline.

The original question about what is my take on Meteor? I think it is a promising modern framework. It is also very new (created in 2012) so they are still sorting out some things that people might call basic (like MySQL support) but think of it like iPhone in 2007, it did not have MMS, multi tasking and some other things, but it will get there in its own time and no one died along the way. Meteor is very complex, it looks simple on the outside and can be if you dont want to think too much, but the deeper you go and the more you understand the system the more you will be able to configure it to your exact liking.

I want to also say something in closing. This is not a Jesus framework, it is not here to save us all. If it is any good it will be greatly hated and greatly loved at the same time. The best way to know if it is for you is just to try it. Do your research and if it looks interesting get down to business.

3 Likes
11

What exactly is your beef with angular? I find it very easy to use coming from a PHP background. I’ve taken a look at Backbone, Ember and React, and angular seems to require the least amount of shift from conventional JS/HTML.

Says who? If my app is built for a small audience, why the hell will I need microservices architecture? Microservices is a design architecture and it has little to do with your programming language or framework. You can see you’re coming off as being opinionated. :wink:

12

Great response and even greater insight. I am new to Meteor and generally a newbie in programing. One thing I love about Meteor is the community! They are always willing to help. I have met a number of mentors so passionate about meteor that they can spend as much as an hour helping u solve your problems remotely. Am glad we have a Meteorite in here lol

13

Those who come from Advanced JavaScript background will not be too comfortable with Anguar, because AngularJS is like a Blackbox where things work magically. I have never seen any way of been notified of a change in variable when something like this is used. eg var a=new_value; meaning there’s a form of hack or a check running constantly which happens to be the Digest loop, this too me is so weird, also decorating HTML with many directives and logic is also something else, the community frowned against it at some point and now it’s back and it’s actually dirtier than ever with Angular. I can pratically declare a variable and alter it all from HTML with Angular. Another issue is debugging because Angular parse/compiles your HTML, all your errors are thrown from within the Angular Library itself, talk about getting screwed. Directives are also too complex at first, look at AuraJS for creating reusable components, also creating directives as attributes or classname are actually confusing also God forbid you use a classname that’s already setup as a directive.

In Dojotoolkit I can create a Widget extend that Widget and alter some parts and extend it as much as I like, I haven’t seen a way to extend Directives in Angular. Angular is good no doubt but for those of us who came from frameworks like Dojo/jQuery/Backbone. Angular is quite frustrating especially when you try to bend it to your will.

1 Like
14

i think he’s referring to modular components compared to single application with so many part all tied together. Something like this http://aurajs.com/faq/

15

@adim86 It’s an admirable goal, but the fact that you need to be tied into a specific method in the first place is where I have my qualms.

It may make for a slower start, but it would be on more sure footing when you progress.

@logbon72 Conventional JS/HTML is trash. You put globally accessible callbacks in your html. You store state in dom. You modify the dom atomically. The least amount of shift is a positive thing only if what you’re shifting from is good in the first place. What you’re holding on to is familiarity, not necessarily what’s best for you

I built something for an audience of one; it was being pushed to its limits due to its core functionality being a very intensive operation. There was no way I’d have been able to open up the app to more people without the server consistently going down. The service would never be able to sustain 100 users. That’s a very very small audience, imo.

If your operations are all lightweight, then maybe you don’t need to dedicate extra resources to the operation. If you have the money, you can just rent a bigger box to do it all. That’s not always going to be the case.

Bear in mind my preference is monolith. Even in my “microservice” setup, there’s a file called monolith.js which I start up multiple lightweight services on one server. Each service is built in a way that they can run independently on one server, but they can be coupled together to make the most of resources. If I only need two machines … one for the intensive thing and one for everything else, why not?

My point here is that I’m not necessarily comfortable with microservices. I’ve had to learn a few new technologies to get them working the way that makes sense to me. That being said, the advantages are pretty clear to me. It may not be how I like doing things but I know its the right way.

16

My biggest beef with Angular, the errors are way too cryptic. Many of the other issues you raised can be addressed by having strict standards. It’s like PHP being a lose language, however, with best practices many of the loop-holes can be avoided. For me, I think the simplicity with which things get done is worth that extra effort. The learning curve of Angular is not as steep as that of many other frameworks.

This is a very terrible weakness of AngularJS, my work around is to just copy and paste, then make modifications, especially when it is an external library.

17

Good friends send birthday cake.

3 Likes
18

Friends do not also let friend bear false witness hence my previous reply. LOL

as to your comment:

I think Meteor being opinionated and yet aspiring to be flexible is a great feature/goal, it allows newbies to get off the ground without needing to figure out all sorts of technologies first and it allows experts to do things their way if they later choose. Conventional frameworks like Rails became famous because they reduced the barrier of entry into coding. Because you have many years of experience it is easy to forget that you did not always have an opinion about SQL or NoSQL databases or Monolith or Micro-service architecture. Many people just want to build something that works first and conventional frameworks are very helpful here.

Like I said this is just a preference, Meteor is trying to be everything for as many people as they can and as a new framework they have released their minimum viable product and are refining it quite rapidly. I think it is an interesting framework to watch

3 Likes
19

Make i no lie, when i write a code in Angular and compared it to what it would have been in Vanilla JS, it’s possible I would have written tons of code in JS compared to the same logic in Angular. does anyone here use Onsenui it’s a mobile platform like ionic, it’s really dope

1 Like
20

I totally agree. Very valid point on helping you get started and letting you make your own opinions.

I keep forgetting that as much as I like learning what’s underneath everything, I started with no opinion and acquired them over time. Frameworks help with that a lot.