I'm sorry, but how are you in a lead position but somehow didn't understand a timeless principle of software development?
The State of Meteor Part 1: What Went Wrong
61–70 of 189 posts
Re: The State of Meteor Part 1: What Went Wrong
#62Earlier quoted context omitted.
I think it is for development only.
The intended use doesn't matter. That's a huge potential exploit. I would never deploy an application based on a framework where database access from the browser is baked in.
Database access from the browser is not baked in. This is a misunderstanding. Meteor has a browser cache that mimics a subset of Mongo commands, and auto-syncs with the back-end based on security rules you define.
Re: The State of Meteor Part 1: What Went Wrong
#63Earlier quoted context omitted.
Off topic but is there a reason I keep seeing this word 'grok' used all over HN? Just say 'understand' unless there's a reason to sound like you have aspergers. And 'fully grok' is redundant anyhow - grok implies a full and deep low level understanding with no lapses, you cannot partially grok something. It's dissapointing to see uncommon words used in poor ways, I'm seeing this word misused all over HN as if its now…
jargonfile or gtfo There's nothing wrong with saying "grok."
"Grok" in is original use is something more like a deep and complete understanding. Here is Heinlein's explanation from "Stranger in a Strange Land":
"Grok means to understand so thoroughly that the observer becomes a part of the observed—to merge, blend, intermarry, lose identity in group experience. It means almost everything that we mean by religion, philosophy, and science—and it means as little to us (because of our Earthling assumptions) as color means to a blind man."
But 'grok' is supposed to mean something more like understand various arbitrary things at a low and intimate level, not at a high level.
Re: The State of Meteor Part 1: What Went Wrong
#64I 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.
Re: The State of Meteor Part 1: What Went Wrong
#65Give 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 abou…
> Give me a box of boards and nails any day. All my ikea furniture is rickety and much of it is starting to look dated.
This seems to contradict the rest of your post where you go on to talk up the plug and playness of meteor. That's much more like ikea furniture than a board and nails. The board and nails approach requires you to do all the planning that meteor gives you out of the box.
Re: The State of Meteor Part 1: What Went Wrong
#66Earlier quoted context omitted.
The intended use doesn't matter. That's a huge potential exploit. I would never deploy an application based on a framework where database access from the browser is baked in.
Database access from the browser is not baked in. This is a misunderstanding. Meteor has a browser cache that mimics a subset of Mongo commands, and auto-syncs with the back-end based on security rules you define.
Thanks for the clarity. That will teach about commenting during the morning commute.
Re: The State of Meteor Part 1: What Went Wrong
#67I 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 deploying apps.
I knew there was something coming, since the beginning i heard about galaxy, an MDG developed deploying solution, which i thought was the solution for all my problems. But then, then came the galaxy launch and its price ($495/mo). At that price I felt betrayed, misrepresented. (still waiting for the individual price several months after)
The big problem i see with meteor for the future, is that MDG has/will have to answer to its shareholders rather than its community.
Re: The State of Meteor Part 1: What Went Wrong
#68I 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.).
Re: The State of Meteor Part 1: What Went Wrong
#69The 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…
Then Meteor does not meet your use case. Some people actually like opinionated, monolithic frameworks because it reduces decision fatigue and boilerplate coding. For small teams with outsized requirements, it's a perfect fit. I've built a couple (internal) apps with Meteor and got a tremendous amount done in a short time. Maybe someday I will need to replace 'x' with 'y' and have a hard time (or maybe not), but the t…
> 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.
Re: The State of Meteor Part 1: What Went Wrong
#70The 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.
It's why PHP still thrives.