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

71–80 of 189 posts

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

#71

Post by minimaxir »

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 completely fail to understand why some developers seem to be allergic to learning about data structures and the means of query-ing them

I'm not a fan of Meteor's dependency of Mongo either, but proper database architecture for a rDBMS is not an obvious skill. Even with an ORM (Rails/Django), it still takes care to set up PK/FK relationships and that's not necessarily taught in a CS curriculum.

Mongo would be sufficient if the data loss issues were resolved. (JSON in PostgreSQL may be a best-of-both-worlds scenario)

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

#72

Post by tbrock »

> Once a new Meteor user starts to go beyond the basics and look into things like routing, pagination, subscription caching & management, server-side rendering, or database joins, they realize that the difficulty curve quickly ramps up.

Routing? Really? I am not an expert but I think if routing, of all things, is hard in to do in your web framework, you most likely have a problem. That's requirement zero!

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

#73

Post by Geee »

Meteor is easily the most productive webstack I've ever tried (couple of years ago) including learning, app setup, configuration etc vs some of other popular choices. I hope at least some of that carries over to what ever is coming out next.

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

#74

Post by m52go »

elchief wrote: post #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.

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 through some growing pains. Given how ambitious its vision is, it simply can't avoid them. I look forward to Sacha's next, hopefully more optimistic, post!

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

#75

Post by wsvincent »

I'm currently using Meteor to teach a college-level course on Web Development for beginners.

https://csci16.hellometeor.com/

It's incredible how accessible Meteor is for this purpose:

* One line complete local setup

* One line deployment (to Meteor servers, but still)

* Javascript only (no need to learn Python, Ruby, etc in addition)

* Out of the box User Accounts

* Simple templating engine with Blaze

I can think of no other framework/language combo where true beginners can deploy a live, database-driven website in a couple of hours. I really wish Meteor could focus more on this aspect: becoming THE entry-level framework for learning web development.

However Meteor's business model is around hosting, so it's inevitable they move further and further towards the needs of professional, rather than entry-level, developers. And this takes them further into the areas outlined in this article where they are currently weak.

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

#76

Post by nichochar »

Honestly, I used meteor and tried pretty hard, I went to their hackathons, etc...

I just don't think it's as good as the other options technically (does not scale well as a server, which is a problem for most applications).

More importantly, as a developer, I do not believe VC money should be bringing opinions to the open source community (which is what this is) is a bad idea. The whole point of open source projects is to have natural selection happen. Meteor having VC money allows them to get it wrong but still market it etc... Which just seems like a poor idea.

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

#77

Post by praveenperera »

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…

In regards to cost of launching a working demo-app or prototype my solutions was a Digital Ocean $5/month box + Dokku

https://github.com/dokku/dokku

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

#78

Post by sotojuan »

tbrock wrote: post #72

> Once a new Meteor user starts to go beyond the basics and look into things like routing, pagination, subscription caching & management, server-side rendering, or database joins, they realize that the difficulty curve quickly ramps up. Routing? Really? I am not an expert but I think if routing, of all things, is hard in to do in your web framework, you most likely have a problem. That's requirement zero!

Yeah I don't get this part and it has nothing to do with Meteor, just that new users find it hard to do anything beyond Todos. But that also makes no sense. So it's hard for the user to not do something very simple? Maybe the user should take the time to learn what they don't understand.

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

#79

Post by juanmnl »

mangeletti wrote: post #68
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…

To address your "co$t of launching a working demo-app or a prototype" issue, Heroku offers a free app / database for demo purposes[1]. Once you really get going, Heroku is expensive, but it might be worth the cost for teams (or individuals) that don't have the time (or expertise) to effectively manage a production deployment (security, up-time, backups, etc.). 1. https://www.heroku.com/pricing

You are right, i've used heroku (haven't seen it in a while though, so thanks for the link). Maybe now it's simpler, but at this time last year, it wasn't. Also, main problem with free-tiers is that meteor is CPU/RAM-intensive and they do not handle that very well. I'll have to check it up again though.

Surely, there are many ways of deploying meteor apps, but no true simple way (which is why i expected a lot from galaxy). Like a single production line: create > develop > deploy w/ scalable infrastructure and cost. That was the whole meteor attractiveness for me.

There was a meteor based project where i spent 2 weeks developing a prototype and almost a month trying different deploy setups with the client. (heroku, digital ocean, linode, modulus, compose, aws, etc...)

Now, with ember or react + firebase, i can do the same stuff at a fraction of the cost and without having to learn devOps.

Appreciate your answer :)

Post reply on HN