Review of meteor

Not too long ago I was looking at alternative development tools for Android other than what Googld provides. I got quite interested in meteor, which claimed itself as a "Javascript App Platform". I have written javascript since 1997 (since before it was called EcmaScript, since before DOM Level 1 was standardised); while not exactly a fan of the language, I can do things with it so it intrigued me. In the past I have also had fun with Aptana Jaxer (now defunct) which more or less did the same thing - without the Android part.

Most of it is what it says it is. Documentation works, tutorial works (which is more than what many products from large companies can offer!). The javascript works too, of course.

But I noticed something that I really don't like - it's blurring the line between server-side activities and client-side activities. Let me explain.

In meteor, scripts can be tagged to run in client (=browsers), server, or both. Round-trip latency is reduced or eliminated using transparent client-side caching (ie, your code doesn't need to know about it - generated plumbing code + embedded libs takes care of that). You're supposed to write stuff as if they run on clients; and only code server-side stuff when necessary (at least that's the impression I've got).

This is supposedly a very good thing - focus your development work on your requirements rather than the plumbing of the platform; and get stuff done quickly.

But it feels wrong to me. I would rather prefer an environment where I know (and can separate) what runs on the server, and what runs on the client.

For one, with this much close-coupling, when the plumbing stops working or starts leaking, I can imagine that debugging will extremely fun.

Another downer for me is the realisation that the app I make will be fully tied to this platform. The frontend (client-side) can only work with the backend (server-side) it is written with; there is no easy way to make a single server that services heterogeneous, multi-platform clients.

All these may still be acceptable if the end result of the (android) app is a single bundle that I can deploy as a standalone - but no, meteor doesn't work that way. The android app it created is basically just a webapp facade (bunch of html and js), and needs to connect to a remote server for it to *work*. The server-side stuff are not included in the APK. That means, if the (remote) server dies, the app is useless.

There are other concerns but they are relatively minor compared to the above, so with great disappointment I have to put it aside. It had so much potential in it.

Posted on 18 Dec 2015, 03:45 - Categories: General
Edit - Delete


No comments posted yet.

Add Comment

Title
Author
 
Content
Show Smilies
Security Code 6464473
Mascot of Fatdog64
Password (to protect your identity)