In my experience, the best part of Meteor is its tightly couple stack so that I can developer very smoothly. But the worst part is also its tightly couple stack when my web/app grows. Really hope that it would be easier to decouple some important package like tracker or minimongo
The State of Meteor Part 1: What Went Wrong
11–20 of 189 posts
Re: The State of Meteor Part 1: What Went Wrong
#12Meteor is great and Im optimistic what 1.3 will bring with better NPM support.
Re: The State of Meteor Part 1: What Went Wrong
#13I tried out Meteor this past spring. I started with a simple Trello clone, which I got working in a couple hours, including learning time. It was good enough at that point that my brother started using it at work. I was pretty impressed.
So I got to work on some more advanced features I'd been thinking about. And at some point, Meteor started throwing an error from somewhere in its innards, and for the life of me I couldn't figure it out. Some kind of problem mapping data to UI, I don't remember the exact message.
I decided I needed to know the guts of Meteor to be able to debug problems like this, and put the whole project aside to wait for the Meteor in Action book. But now I'm onto other things.
Re: The State of Meteor Part 1: What Went Wrong
#14The thing which prevented me to use meteor for big projects is it looks really monolithic from the outside. What happens if suddenly I want to rewrite part of the back-end or part of the front-end with something else for various reasons ? What happens if I want to switch from MongoDb to RethinkDb or Postgres for some reason ? It's good to have default choices but it looks from the outside that the default choices wit…
Same. Welding the frontend to the backend is a definite no-go for me, regardless of the supposed benefits of this isomorphism.
I think the big problem with isomorphism is that there's a fundamental disconnect between the lifetimes of front and back end systems. Well written back end code (hell, badly written back end code) could be left running for decades with better front ends bolted on. A front end system written even a couple of years ago starts to be less maintainable as developer skill sets move on, best practice evolves etc.
Re: The State of Meteor Part 1: What Went Wrong
#15The thing which prevented me to use meteor for big projects is it looks really monolithic from the outside. What happens if suddenly I want to rewrite part of the back-end or part of the front-end with something else for various reasons ? What happens if I want to switch from MongoDb to RethinkDb or Postgres for some reason ? It's good to have default choices but it looks from the outside that the default choices wit…
Not to argue your point about the options being limited, but support for rethinkdb is in progress.
Re: The State of Meteor Part 1: What Went Wrong
#16The big mistake was trying to provide anything beyond Minimongo on the client side. People are very picky about what front-end frameworks they use on the front end, and typically people who have strong opinions about that are less opinionated about what they use on the back end. I'm firmly in that camp, for instance. I've been a huge fan of Firebase for a while because it frees me from the tedium of having to create…
[deleted]
Re: The State of Meteor Part 1: What Went Wrong
#17This is a little worrying; after much research I'm starting a new project for a startup using the meteor stack.
Understandable-- but if you are productive on Meteor today, or you and your team have already committed to learning about it, I would suggest that you should see that through. This kind of uncertainty/doubt around open source frameworks is par for the course, unfortunately, and I think it would be a real shame to stop before you've at least built a prototype with the technology you've already invested time with (particularly since so much of a v1 is figuring out the interface/interaction design anyways, y'know?) Just my 2¢.
Re: The State of Meteor Part 1: What Went Wrong
#18Another place I'd love to see Meteor move towards the (future) standards would be an eventual replacement of Fibers with async/await throughout, which to me is more explicit and intuitive.
Re: The State of Meteor Part 1: What Went Wrong
#19The thing which prevented me to use meteor for big projects is it looks really monolithic from the outside. What happens if suddenly I want to rewrite part of the back-end or part of the front-end with something else for various reasons ? What happens if I want to switch from MongoDb to RethinkDb or Postgres for some reason ? It's good to have default choices but it looks from the outside that the default choices wit…
> What happens if suddenly I want to rewrite part of the back-end or part of the front-end
Which is likely what is happening right now to detriment to all those that have already adopted meteor. But you sort of have to need to do this.
Re: The State of Meteor Part 1: What Went Wrong
#20The big mistake was trying to provide anything beyond Minimongo on the client side. People are very picky about what front-end frameworks they use on the front end, and typically people who have strong opinions about that are less opinionated about what they use on the back end. I'm firmly in that camp, for instance. I've been a huge fan of Firebase for a while because it frees me from the tedium of having to create…
Let's avoid turning this into a "Meteor is doomed" or "Meteor failed" comment thread; Meteor is and has been growing consistently since it launched (see: https://twitter.com/Rahul/status/673992512768507905 ). The title of Sacha's post reads a bit inflammatory, suggesting something "went" wrong and that it's too late now. Rather, as his post explains, the community is currently in a bit of an identity crisis as two gr…
The post's title is "What Went Wrong". What kind of comments were you expecting here? Running an OSS project is no different than running a startup in a lot of respects – marketing and PR matters. It's great to write candid posts like this, but you can't jump into other forums where the post has been linked and try to manage the conversation after the cat's out of the bag. It ends up sounding like damage control.
Instead, you should welcome further observations about some of the perceived mistakes the Meteor team made and point out specific examples where they're being addressed.