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.
Edit - Delete
No comments posted yet.