Why I’m not staking my future on MeteorJS | Hacker News Reader

Why I’m not staking my future on MeteorJS

medium.com

5 pointsstakent5 comments

Meteor is an excellent (or: the best) prototyping framework. Getting some idea implemented into something usable that mostly looks and feels nice is a cakewalk of a few hours (once you know a little bit about popular atmosphere packages). It also can be used to get the UX of an idea right in live-coding sessions and to give a try at the hard problems of your idea quickly (atmosphere + the giant clusterfuck of NPM stuff should contain something that does what you need more or less). If you do some small tools or or internal stuff or the like, there is no need to progress any further after prototyping.

If you know there will be pressure, high growth or stability/performance/predictability/maintainability requirements for years to come, by all means, use the appropriate technology to build your product. You should know where the application problems are after tinkering with a prototype in meteor. For the average "90% of current products" you'll end up building, phoenix[1] is an excellent choice to build the real stuff, and you can have the same soft-realtime-sockets of meteor with just a little more thought (but way more predictable, structured & scalable).

But again, IMO nothing beats meteor for prototyping stuff as fast as possible.

[1] http://www.phoenixframework.org/

I am a Python dev, so I don't know too much JS. Is it faster than RoR of Django for prototyping? I know that with Django's admin, you can have something with a relativley full set of features very quickly (as long as your features fall into Django's way of thinking).

way faster actually. (RoR dev for several years here).

You have zero-config user account system and drop-in admin panels (zero config) here too. more precise: you just code up templates and declare that you have data (mongo being schema-free helps in this case) and code up interactions with a few lines. done. with stuff like auto-form and other goodies, a CRUD SPA with batteries included is done in a few minutes, ready to run.

But don't dare to dabble with correct deployment, testing or stuff like that, waste of time.

Interesting comment.

Could you elaborate on the capability of Meteor to handle middle size pressure. I am not Google, I am not Facebook. But I have some hundred users, putting a very moderate load on a basic CRUD application, with classic simple client-side interaction. Can I expect Meteor to handle that case just fine?

I am also having a look at JHipster, and it has a quite good out-of-the-box feature set. With the usual full Java stack.

As long as you don't have many sites of content that you want to get indexed by google, it may handle it. In case you have, prepare yourself for going to buy many CPU cores to have `spiderable` working, it spins up expensive phantomJS processes to render the heavy client-side lifting to bare HTML, and is fairly brittle (having HTTP status codes alone means jumping through hoops). Oh, and meteor wants quite some RAM.., the server actually mirrors every bit of data that any client has in it's browser for every user. And too much data updates on often-needed resources can bring everything to a halt.

Reply on news.ycombinator.com