Comment by rglover | Hacker News Reader

Comment by rglover | Hacker News Reader

My company https://cleverbeagle.com is based on Meteor.js and we have an active customer base. I also run themeteorchef.com (tutorials on Meteor) and while we've definitely seen the hype die down, we still get organic traffic upwards of 25k uniques a month. Dead? No. We see a lot of new interest from overseas (Africa/Middle East/Asia).

Technically speaking, Meteor's in the best state it's ever been: latest Node version, full Babel support (zero config), great accounts system, full NPM support, ready-to-go MongoDB support and access to multiple DBs via Apollo. Things like Atmosphere, Meteor's package system—which have been earmarked to be phased out in favor of NPM—get Meteor some negative press.

It's a shame, too, because having actively explored alternatives over the last six months, the only platform that came close to being comparable (in respect to being fully featured out of the box) has been Firebase. It's not the only option but it's a damn good one.

Meteor deserves far more attention that it receives—miscommunication around 2015 regarding Meteor's choice of UI framework and the Meteor Development Group's shift to focus on Apollo put a serious ding in its trajectory. A guess: MDG had to make a return for investors and Meteor itself—and their hosting product, Galaxy—wasn't growing quickly enough (just a guess).

My experience with firebase is that it gets way more credit than it deserves. It's easy to develop on, but we had connectivity issues almost weekly with it, despite their status page saying everything was running smoothly. Firebase also has scaling issues. Last I heard, you can't have over 100,000 concurrent users, but it's not really publicly stated anywhere.

100K simultaneous connection limit is published here: https://firebase.google.com/docs/database/usage/limits

I’m using it for a side project which has been running for over a year. It’s not something to which I can devote much time and Meteor is easy to set up for what I need.

I suppose that if it dies I can re-write the application using some other framework (I’ve done Android/Java and iOS/RubyMotion versions), though it would be a bit of a pain. For now, with no new features planned, I can keep it running as long as the Meteor bug and security fixes keep coming.

Technically you can run it indefinitely. Meteor is open source and the Meteor team has been actively working with community members to do PRs and what not. There are enough people on it that the ball (to some extent) would be picked up by community folks. Perhaps not a bad thing, either, as it could breathe some new life into it.

Thanks, useful to know.

> It's not the only option but it's a damn good one.

I've been using Parse, is another good option in your opinion? I quite like it, especially as everything is available via REST so it is easy to use it with Elm

I'd personally avoid Parse as it's been shut down. I worked with someone who had inherited a Parse-based app last year and we had to do a fair amount of gymnastics to get it working smoothly. That was just my personal experience, though.

A good rule of thumb: if it works for you, use it. There's a lot of ballyhoo about keeping up with the tech Joneses which is mostly unnecessary. It's the most common excuse I see people using for not sitting down and just building their idea (we teach people how to build their own products at Clever Beagle). Tech always changes. If you're truly successful, at some point you will have to migrate to some new technology. Most concern about "blowing up" is just hubris disguised as optimism.

There isn't, hasn't, and will likely never be a permanent, perfect solution. Every single piece of technology has gotchas and idiosyncrasies. Use what you understand and makes you productive—the rest will take care of itself in time.

I like that it is open source, but the question is how well is it being maintained? Having said that one can self-maintain as I think it is NodeJS. That's what you'd have to do if you write your own Backend - so the only problem is how spaghetti like the code is.

It’s just Node.js. All of the Meteor-related code can be removed if you really wanted and just rely on the build system. Even if you had to do a port to a vanilla Node.js app, a large reasonably well-structured app might take a month or two tops to port.

Side note: frameworks don’t write spaghetti, developers do.

Oh I wasn't trying to say it is spaghetti because NodeJS :-). I was saying it might be spaghetti because thats how code sometime is.

Reply on news.ycombinator.com