I built an app with Meteor right around when 1.0 was released. The absolute worst part for me was attempting to shim what should have been a relational database design into the default NOSQL mongoDb (you pretty much had no choice).
The State of Meteor Part 1: What Went Wrong
41–50 of 189 posts
Re: The State of Meteor Part 1: What Went Wrong
#42Anything that implies the lock-up unless everything is rewritten completely is not a viable choice for me.
I'm wary of anything (especially JavaScript as trends change there faster than one can read the articles) no matter how praised it is. Sometimes things just do break in the most bizarre manner when you already have everything set up. If components are modular enough, you can swap them, or at least patch a completely new piece over the old one, to handle the problematic cases.
When I once had to replace a very old legacy system (non-web, but it still holds) I've just slapped a dummy do-nothing proxy-like system in the front and gradually did stuff piece-by-piece. Then threw out the old garbage when it wasn't doing anything anymore.
But from what little I understood about Meteor from the tutorials and examples, there's one single giant system, that you either use or don't. This means, if one hits some bug or - worse - architectural limitation, they're going to have really tough time.
Re: The State of Meteor Part 1: What Went Wrong
#43So, Meteor is going to turn into what SocketStream was, five years ago, before it was completely eclipsed by Meteor's marketing steamroller.
Re: The State of Meteor Part 1: What Went Wrong
#44The 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…
So why did you pick a tech stack for this project, given that you had not used it before, sounds like no-one in your team had either, nor is this stack widely used (afaik)?
It seemed to fit our use-case really well. The CTO and I did a Meteor hackathon to get a feel for the tech, and thought that it would be a lay-up. Alas, it was quite an error.
Re: The State of Meteor Part 1: What Went Wrong
#45The 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…
> I think our biggest mistake was biting off more than we could chew in using React and Meteor, when we had never made an app using either before. I see people make this mistake over and over again. It's so easy to underestimate the cost of learning something new. Often times it's best to just go with what you already know until you've done enough non-mission critical in the shiny new thing to be confident in it.
Yep, lesson learned big time :)
Re: The State of Meteor Part 1: What Went Wrong
#46'All happy families are alike; each unhappy family is unhappy in its own way.' -Tolstoy
It seems that many people are unhappy with Meteor in its own way. It takes 375 factors to make a 'Rails' and Meteor has 370 for each person, but each person is missing a different five.
Re: The State of Meteor Part 1: What Went Wrong
#47Give me a box of boards and nails any day. All my ikea furniture is rickety and much of it is starting to look dated.
I just spent a good amount of time over the last few months building a prototype for an application in Meteor and it has been a joy.
Out of the box I got happy, grokable app/server communication, I got sane user account tools and I got a build process that works well enough that I haven't thought about it at all. I almost never need to look at documentation, I just build features. I've only needed a few community packages, and the ones I have used have been working pretty well for me.
I feel like I've been living the dream. So much ceremony and overhead just melted away.
I'd be curious to hear what kind of issues people have hit with blaze/meteor package management/etc that make them want to swap in react/npm/etc. (I spent the better part of 2015 with react/flux and it would take a lot to get me to switch back).
Re: The State of Meteor Part 1: What Went Wrong
#48"Project Foo: The Greatest Thing Ever". What is that? I should look into that.
A year or two later. "Project Foo: Total Crap". Glad I didn't look into that.
Re: The State of Meteor Part 1: What Went Wrong
#49> Meteor has yet to establish itself as a mainstream development technology on the same level as Rails or even vanilla Node.js... almost four years after Meteor first launched, I have to admit I thought the framework would be more widespread by now. So what happened? A more general answer, I feel like the web programming world doesn't really need new frameworks, does it? Rails or Django got mainstream adoption becaus…
>I feel like the web programming world doesn't really need new frameworks, does it? Rails or Django got mainstream adoption because there was a need at the time
Of course we do. Those frameworks appeared because what was available at the time wasn't perfect. Rails/ Django addressed a number of pain points and made more rapid development possible. But development still takes time and creates bugs, so there's still room to improve.
Plus coders are always going to reinvent the wheel, so frameworks will continue to appear.
Re: The State of Meteor Part 1: What Went Wrong
#50This is a little worrying; after much research I'm starting a new project for a startup using the meteor stack.
I work for a startup that has grown our team and product over the past two years, building a major application on Meteor. It's been great seeing the platform grow, and we've been able to benefit from many of Meteor's components from the very beginning. We can add new features very quickly because of the base Meteor provides.
If Meteor is a fit for your project, definitely use it. Real-time, isomorphism, and more can be of big benefits to rapid development.