Meteor 1.5 is Here With Brand New Code Splitting!

As the latest version Meteor 1.5 is released, technology geeks and enthusiasts consider it as kind of a big deal. Reason being, Meteor 1.5 will be the first version of Meteor js that can be installable via Nodes Package Manager or npm.

And it’s beyond that.

Experts are already predicting that this transition to npm and a more open development model will definitely expand Meteor development. Earlier there was an apprehension whether Meteor was about to reach dead end, or even gradually slowing down and loosing track. But with the release of Meteor 1.5, it proves again that it has now become a grown up technology and has taken its performance through the roof.

The Early Days

Meteor, also known as Meteor.JS was first released in 2011 which instantly became a breath of fresh air. It brought in light that wow factor, ‘auto load’, which became a huge differentiator in the world of website submit forms, making dependency management a thing in the past. And as technologies evolved, Meteor 1.4 was released; primarily focusing on improving the application developer experience. Many features of Meteor were refined and it started supporting Mongo DB and Node js. And the result was revolutionary leading to optimized server, database speed and upgraded version of Node. Still there were certain questions raised by the application developers about its stability enough to load complex web applications easily.

And now, the latest version is the answer to it all. The current Meteor version 1.5 is all about resolving the earlier issues stated by developers which includes app loading time and performance. And as always, its product focused. The best thing is that it remains up-to-date even when so many clients interact with the application simultaneously, without really having an impact on Meteor’s otherwise traditional technicalities.
So what’s new on Meteor 1.5?

• Code Splitting

In Meteor 1.5, the Meteor Development team has implemented dynamic import(…). The new dynamic import(…) provides runtime supports for the ECMA Script dynamic import(…) syntax, which enables “code splitting”, a first of its kind introduced in any web framework, which will in turn enable asynchronous module fetching. Code splitting has now been made much easier now compared to older days due to some crucial changes made in JavaScript. You don’t need any special configuration to implement dynamic import(…).

So how does implementation of dynamic import (..) differ in Meteor 1.5?

This is where “exact code splitting” strategy is undertaken which will differentiate it from bundling approach.

In the new version, it will treat every module in your application individually whether it is an individual file in your application or an individual file in a package that you’re installing. So rather than running a code splitting object and amp with JavaScript files or so, you will run a server that knows how to respond to requests for individual subs of modules. There are 2 benefits by doing so:

1. Doing this exact code splitting approach over the bundling approach one is the obvious one, which is with the bundling approach you can easily end up loading the same code multiple times. Take for instance, if you have a component which is appearing on your front page and the same components also on the second page, the bundling system wouldn’t know which page you are going to first, so it has to put that component in both places where as in code splitting, by the time you reach the second page it will know that you don’t need that component again.

2. You can cache every module individually. Unlike the older days, when you upgrade to the new version of a particular app and when the browser reloads, it will actually be loaded from the memory instead of being loaded from the server again. It will be cached persistently inside your browser.

Click here to get a demo in case you have any doubts.

• npm package has been upgraded to 4.6.1

• The meteor-promise npm package has been upgraded to version 0.8.4.

• For fixing #8704 issue, the uglify-js npm package has been upgraded to version 3.0.13.

• If you are managing the standard-minifier-js Meteor package like most of the Meteor Developers, it will now provide a comprehensive analysis of package and module sizes inside your production .js bundle when you run meteor build or meteor run –production. Those data are accepted by the application web server at the same URL as the minified .js bundle, without a .stats.json file extension instead of .js. If you are using other minifier plugins and would like to support similar functionality, refer to these commits for inspiration.

• Babel plugins now accept file paths without leading/characters, which should prevent confusion about whether the path should be treated as arbitrary. PR #8610

• If you want to visualize standard-minifier-js, then run Meteor add bundle-visualizer and then start your construction server in reproduction mode with Meteor run –production. Make sure the bundle-visualizer package is removed before actually deploying your applications, or it will be publicized to your users.

To update already existing Meteor Application, all you need to do is to run Meteor update from the installation directory. Before that, do allocate your application’s .meteor directory to your version control system. This will help you to work out any upgrading problems, if any.

Continuing the victory run….

Meteor has been the darling of application developers since a long time and will obviously continue to be so with the release of latest version. There are many more improvements being developed in Meteor 1.5 which will keep impressing us in the coming days.

Stay tuned with Cubet to get the best Meteor experience!

Know More About This Topic from our Techies

Other Blogs:

• Why is NoSQL the new magnet of Big Data movement?
• IBM Watson Chatbot
• Infogarphics – Comparing Top 3 PHP Frameworks : Laravel vs Yii vs Symfony
• Advanced features in Laravel 5.4