My Journal




Recently, I attended a MeteorJS Meetup group in Burlington, VT. During this talk, I was able to acquaint myself with both the existing frameworks that Javascript has to offer and the potential that these newer ones are bringing to the field. I have been told time and time again that Javascript is mostly used in front-end applications. Although anyone can add interactivity to their webpages using the numerous frameworks floating around, Meteor stands above the rest and I’m not the only one who has found this to be true. Meteor Development Group, during their first round of funding, pulled in $11.2 million! $11.2 million for a framework that was still in development. Here are some of the takeaways that stood out for me:

1. Real-time. Reactivity. This feature of Meteor was very new to me and took me a minute to fully understand. The idea is that the developer writes code that renders values when the data is acquired, instead of writing code that retrieves values to be rendered later (push vs. pull). What Meteor now allows the developer to do is just declare something while the changes are processed on the server, and then delivered automatically back to the client whenever there is a change. With a socket always open, you no longer have to make those periodic AJAX calls. This will especially become valuable as more and more applications support hot code pushes.

2. Full-Stack. Meteor, a full-stack programming framework, is a huge change from the established norm most developers are accustomed to. Utilizing full-stack frameworks has countless advantages, including less of a learning curve for newer developers or others that want to switch. This will save companies time and money not needing to have specialized developers working on their own projects, independently. Meteor will eliminate the complexity of trying to integrate the front and back-end into an application. Many people, however, do think that full-stack frameworks are often lacking much of what is needed for a particular project and that in terms of frameworks, “one size never fits all”. In the past I would have agreed with that, but I would like to argue that with native built-in support for MongoDB (since release 1.0), utilizing Meteor can be just as easy as any of the dedicated back-end languages.

3.Security. Yet with all the positives said about Meteor, I have noticed a trend in the development community to discount the framework due to perceived security threats. Although security should be a large part of anyone’s decision to try a new framework, I believe the threats are not any more prevalent than in any other languages and frameworks. A huge advantage of Meteor is that when it is run on the server-side, it will be inherently safe. However, if you send out AJAX requests using client-side code instead, security risks now begin to appear. Although this can happen on the client-side of Meteor, it is less likely to cause damage because now the server does all the commits.

The problems gaining most traction are the insure defaults. Meteor, admittedly, did a foolish thing by making two of their packages active by default, autopublish and insecure. Autopublish allows clients to view the contents of the server-side database, while insecure allows them to modify the data. Intended to only be used for development, simply removing these packages removes these security risks.

Leave A Comment