Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The State of Meteor Part 1: What Went Wrong

discovermeteor.com

Post reply on HN
Print view View original

161–170 of 189 posts

Re: The State of Meteor Part 1: What Went Wrong

#161

Post by sanderjd »

mrcwinn wrote: post #108
magicmu wrote: post #23

The startup I'm with right now just finished a meteor/react project that I led. This article really touched on our major pain-point with the learning cliff that you hit after a certain point. We used FlowRouter since it has React support, but managing subscriptions correctly (let alone caching them) took way more time than we had anticipated. It wasn't until near the end of the project that we realized none of us act…

It's good to realize the mistake here, so good job. Never jump on the new thing. Always lean toward the simple thing. Always prefer tools closer to your core competencies. Meteor is really fun to play with and the community is very good, but Meteor creates complexity over time. It's also worth mentioning that unless you have a real-time app whose data model fits nicely with schema-less document storage, Meteor is alm…

> Never jump on the new thing. Always lean toward the simple thing. Always prefer tools closer to your core competencies.

This is correct, but it is also a balancing act. Sometimes the new thing is better. Sometimes it is simpler in important ways that provide leverage in the long run, despite being complex in other ways that create confusion in the present. Sometimes you need to learn new tools and shift your core competencies toward them.

An analogy: Nobody writes directly in machine code anymore. Symbolic assemblers were new technology that was better. The early ones may have been buggy, and it may have been simpler to just write it by hand instead of debugging your own code and the assembler, but eventually it paid off. Your core competency may have been writing machine code, but once the assemblers became good enough, it made more sense to be competent at using them.

Very few new technologies represent such a massive and obvious level-up as that, and it is unwise to chase everything in hopes that it will be one of those paradigm-shifters, but it is equally unwise to hide your head in the sand, believing that all new things are necessarily complex and unworthy.

I have been, and remain, skeptical of Meteor itself, but the problems it is targeting are real, and I think it and other projects are circling in on good approaches to solving them, which is worth paying attention to.

Re: The State of Meteor Part 1: What Went Wrong

#162

Post by akurtzhs »

cstrat wrote: post #148
juanmnl wrote: post #67

I loved meteor. Was committed to it for 6/7 months while still learning JS (and working on ember and rails projects with others). I knew it was a risky decision, but it seemed like a good choice for making it as a one-man dev agency. For me, there's no stack selection problem, for me, the main problem is the co$t of launching a working demo-app or a prototype. The only thing i wanted was a simpler/cheaper way of depl…

You must have missed it, the individual developer galaxy hosting is out. I am using it, its amazing. $13 per month per container. Its not the cheapest ($5 D/O wins there) however so far I have found it to be fantastic! They take care of all the nuts and bolts behind the curtain. You just deploy with a single command in console and it uploads, builds a new container, migrates active sessions, tears down the old contai…

Isn't Galaxy Developer Edition still invitation-only? The only official information I can find on it is this blogpost, http://info.meteor.com/blog/galaxy-developer-edition

Re: The State of Meteor Part 1: What Went Wrong

#163

Post by jonmc12 »

fefifofu wrote: post #128

This article does a disservice to Meteor. The article feels drama filled and says many things are broken when they are not. "Blaze is threatened by React". You can use React or you can use Blaze. If React becomes so popular that Blaze is not longer used, that's OK... nothing to be threatened about. It's nice that Meteor can move with a trend. "Tracker and Minimongo might eventually disappear as well". Tracker and Min…

> Routing is solved by community packages

Its a bit awkward in places. Like if you want to receive a server-side web-hook, Iron Router is really the only way to go. But, lets say you have an Angular client, Iron Router can't be disabled on client when being used on the server. Now you have to hack for Iron Router and Angular UI router to play together nicely - using 2 routers on client because you want to receive server-side webhooks is obviously not ideal. But, at the same time both the community and the roadmap are coming together to make solutions workable before being fully 'solved', imo.

Re: The State of Meteor Part 1: What Went Wrong

#164

Post by Lazare »

bjourne wrote: post #149
davnicwil wrote: post #34

Earlier quoted context omitted.

> What happens if I want to switch from MongoDb to.. Postgres.. The default choices with meteor are pretty fixed This is exactly the reason I'm not using meteor - and it's not so much wanting the ability to switch backends as knowing in advance I want to use an SQL database like Postgres, and not Mongo. With meteor, it's Mongo or nothing. I believe SQL integration is on their roadmap, but I think now it's too late. Y…

Query subscription is the reason. You can add a monitor to the equivalent of "select * from docs" in mongodb and get notified by the db when a docs row is inserted. Some RDBMS:es can solve the same task ad-hoc using triggers, but it is not the same and is much more resource intensive. That makes it hard to achieve Meteor's goal of "any data change is immediately reflected in all clients" with any db other than mongod…

It's actually even easier in CouchDB than Mongo. One of the smaller mysteries to me has always been why Meteor went all-in on Mongo rather than Couch.

Re: The State of Meteor Part 1: What Went Wrong

#165

Post by Bjartr »

jonmc12 wrote: post #163
fefifofu wrote: post #128

This article does a disservice to Meteor. The article feels drama filled and says many things are broken when they are not. "Blaze is threatened by React". You can use React or you can use Blaze. If React becomes so popular that Blaze is not longer used, that's OK... nothing to be threatened about. It's nice that Meteor can move with a trend. "Tracker and Minimongo might eventually disappear as well". Tracker and Min…

> Routing is solved by community packages Its a bit awkward in places. Like if you want to receive a server-side web-hook, Iron Router is really the only way to go. But, lets say you have an Angular client, Iron Router can't be disabled on client when being used on the server. Now you have to hack for Iron Router and Angular UI router to play together nicely - using 2 routers on client because you want to receive ser…

If there had been an official router, what's to say it wouldn't have had the same problem?

Re: The State of Meteor Part 1: What Went Wrong

#166

Post by rashkov »

extrapickles wrote: post #124
ianamartin wrote: post #64

I was never able to get on board with Meteor because of the Mongo dependency. Not to get too far off topic, but Mongo is guaranteed to lose data under certain well-defined conditions. I completely fail to understand why some developers seem to be allergic to learning about data structures and the means of query-ing them. It's not really that hard. If you can JS, you can SQL.

I currently use Meteor for a production app, but only use Mongo as a scratch pad (holding data until the user is mostly done changing their mind and other minor UI state). Data is then packaged and sent to MS SQL Server for long term storage and reporting. As an example, a user can start updating a piece of data (eg: sales order, item, etc), with everyone able to see the changes as they happen (no hard need for locki…

This is very interesting. Could you give a little more details on how you accomplish this? How do you serialize unstructured Mongo data into MS SQL? Does this system break down when front-end people change the data structures in Mongo? I'm not familiar with Meteor but maybe you could explain in broad strokes

Re: The State of Meteor Part 1: What Went Wrong

#167

Post by rglover »

jonmc12 wrote: post #163
fefifofu wrote: post #128

This article does a disservice to Meteor. The article feels drama filled and says many things are broken when they are not. "Blaze is threatened by React". You can use React or you can use Blaze. If React becomes so popular that Blaze is not longer used, that's OK... nothing to be threatened about. It's nice that Meteor can move with a trend. "Tracker and Minimongo might eventually disappear as well". Tracker and Min…

> Routing is solved by community packages Its a bit awkward in places. Like if you want to receive a server-side web-hook, Iron Router is really the only way to go. But, lets say you have an Angular client, Iron Router can't be disabled on client when being used on the server. Now you have to hack for Iron Router and Angular UI router to play together nicely - using 2 routers on client because you want to receive ser…

There are separate server-only routers. Here's a tutorial I whipped up: https://themeteorchef.com/snippets/server-side-routing-with-.... This would remove the need for a dependency on Iron Router on the client.

Re: The State of Meteor Part 1: What Went Wrong

#168

Post by m52go »

webjprgm wrote: post #110
m52go wrote: post #74

Earlier quoted context omitted.

Meteor is different. It's been over 4 years. It's not going anywhere. It has more stars on GitHub than Rails. If you haven't looked into it, and you're in a remotely adjacent field, you're behind. Even if you don't decide to use it. The ideas underpinning the framework are very progressive and sure to continue in some form even if Meteor itself ultimately doesn't. With all that said, I think Meteor is simply going th…

There are too many JS frameworks/platforms/libraries to keep up with. I can't spend my time investigating them all. I've heard of Meteor several times but in my mind it was associated with (a) real-time apps, and (b) not free. I'm guessing that was because it is the free alternative to a paid thing? Anyway, that's what stuck in my head so I've ignored this one. Is looking at GitHub stars a recommended way to find the…

There's nothing (I know of) with a more radical approach to the full-stack web than Meteor.

No one's saying you need to keep up with all the JS frameworks, but if I were hiring a JS dev, I'd expect the person to understand the pros and cons of the most important ones. Meteor is categorically one of the most important JS frameworks out there.

I'm not sure about a way to determine the "best" or "most important" frameworks. Perhaps number of appearance on the HN front page could be a heuristic?

"Not free" is not quite right. The software is open-source & MIT licensed. The entity is for-profit, as it intends to sell services adjacent to the software, not unlike Acquia & Drupal.

Re: The State of Meteor Part 1: What Went Wrong

#169

Post by debaserab2 »

nostrademons wrote: post #131
debaserab2 wrote: post #69

Earlier quoted context omitted.

> but the time savings now are worth the technical debt that I might face in the future Oh, man that statement makes me cringe. Have you ever replaced a piece of proprietary technology with a different one before? I promise you, you will consider this decision up front much more closely next time.

Most apps that become successful have to be rewritten multiple times as they grow. One of Jeff Dean's rules of thumb [1, p. 11] is that a system will generally need to be completely rewritten every 1-2 orders of magnitude growth. Yes, this sucks, as anyone who's gone through a rewrite can tell you. But the broader perspective is that this is what software engineers are paid for. If you could just build a system and l…

Your rewrite doesn't need to be on a completely new platform or language, and depending on the use case you'd still benefit greatly from using some of the original functionality of the current code base to do things until you're in a position to replace them.

In my experience, you often iterate towards a replacement instead of pulling the rug out from the current platform and replacing it with another. This isn't always true, but in the case of CRUD based web apps, it's a lot smoother in my experience.

Re: The State of Meteor Part 1: What Went Wrong

#170

Post by debaserab2 »

krisdol wrote: post #146
debaserab2 wrote: post #69

Earlier quoted context omitted.

> but the time savings now are worth the technical debt that I might face in the future Oh, man that statement makes me cringe. Have you ever replaced a piece of proprietary technology with a different one before? I promise you, you will consider this decision up front much more closely next time.

It's easier to rewrite something than it is to produce an MVP that consumers and investors want to buy into. I'm 150% into the anti-monolith approach for serious scale, but meteor is like Rails in the respect that small teams can accomplish rapid prototyping and fast iterations early on.

So why wouldn't you use rails and benefit from a matured platform and more proven scalability?
Post reply on HN