A star is born … well more exactly a Meteor! (v1.0.2 is out)

meteor_logo

Meteor was recently released in its official version 1.0, and this has been long expected by its community of early adopters. If you don’t know what Meteor is, rush to the website https://www.meteor.com and see by yourselves.

In a nutshell Meteor is a new, but very well-funded and production-ready, player on the scene and is one of the few frameworks that takes full-stack approach. Your app runs BOTH on the server and the client (in NodeJS on the server, and in your your browser’s JavaScript engine on the client) and works very holistically together. It also comes bundled with MongoDB (although you can replace this with a bit of tinkering).

Everybody knows Meteor uses NodeJS behind the scene. But does it use NodeJS version in your PATH? Hmmm…. No. Meteor is ultra portable and the developer does not need to know about NodeJS at all. So when you are installing Meteor, it will download something called dev_bundle which has NodeJS and all the NPM modules needed by Meteor. All these modules are pre-compiled for your platform. That makes getting started with Meteor easier and quicker. Is there any problem with this approach? No. This is perfect, you just need to be aware of it, especially if you are planning to bundle several apps.

So why should you consider coding your next web app using Meteor?

  1. Your app will be a real-time one by default, thanks to the power of web sockets through NodeJS
  2. Just like in NodeJS you can code the full stack with just one language: Javascript
  3. You can save a lot of time with smart packages grabbed from the AtmosphereJS site
  4. The community is extremely supportive, and the company very well funded  (Read this)
  5. It’s optimised for developer happiness, and it’s friendly for beginner developers
  6. It inter-operates nicely with other JS libraries such as AngularJS, Famo.us, and more.
  7. It’s clearly ahead of the technical curve, and that reads through their mission statement: “… to build a new platform for cloud applications that will become as ubiquitous as previous platforms such as Unix, HTTP, and the relational database.”

Meteor 1.0

In conclusion, Meteor is extremely interesting and I think they do a lot of things very right – it’s a delight to work with. EVERYONE coding JavaScript should learn it, because it’s proposed the right way, full-stack. But it’s only an option if you’re in the position of replacing your entire stack, client and server (or working from scratch of course). If you already have, say, a web API that you work against, of if you have an existing JavaScript frontend app that you just want to add some structure to, it won’t fit your needs. Then you would probably consider a more versatile approach with ExpressJS as a NodeJS framework and Ionic as a mobile app packager (which I will cover in another post)

Useful links for Meteor resources

Benefits of Server-Side Device Detection

ImageThere’s a great article on Smashing Magazine to help clarifying on this complex topic of device detection, and most importantly of device “capabilities” detection. Even very senior developers and designers often fail to adopt the right practices in leveraging device detection for responsive design or progressive enhancement. Quote:

“The expansion of the Web from the PC to devices such as mobile phones, tablets and TVs demands a new approach to publishing content. Your customers are now interacting with your website on countless different devices, whether you know it or not.

As we progress into this new age of the Web, a brand’s Web user experience on multiple devices is an increasingly important part of its interaction with customers. A good multi-device Web experience is fast becoming the new default. If your business has a Web presence, then you need fine-grained control over this experience and the ability to map your business requirements to the interactions that people have with your website.

Drawing on the work of people behind the leading solutions on the market, we’ll discuss a useful tool in one’s armory for addressing this problem: server-side device detection.”

I agree that the proper way to do it is to do it on both sides:

=> Server-side detection is fast and fairly reliable, it’s smart and scales for high traffic sites, and coupled with the right device database (Wurfl, Device Atlas, Netbiscuits) it allows unique server side content personalisation and UX optimisation.

=> Client-side detection is much more granular and accurate, and it allows UI/UX designers to get the best out of each target browser, especially regarding rich media. But it can be cumbersome and slower, as we have to deliver Javascript code payloads to be run from the device at loading time. Plus it’s likely to lack flexibility and integration with the Content Management Systems in most Enterprise scenarios.

In my own experience, what I gather from the market and from our customers is that server-side device detection is critical to unleash the full power of content and feature personalisation, in a progressive enhancement approach (as opposed to just responsive design maybe).

Read the full article here

More