The State of Meteor Part 1: What Went Wrong • Hacker News Board

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

#51

Post by mccolin » Wed, Jan 20, 2016, 2:46 PM UTC

canthonytucci wrote: post #47

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. 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…

I can echo your positives regarding using the platform. It's been mostly a joy and learning it has been fun.

We've used npm for a server-only component of our architecture built in Meteor, but happily mix npm and atmosphere packages together with ease.

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

#52

Post by sundaeofshock » Wed, Jan 20, 2016, 2:49 PM UTC

patates wrote: post #39

yclept wrote: post #27

I was turned off to Meteor when one of the initial releases was touting being able to use the browser console as a Mongo shell. Never took it seriously since.

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.

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

#53

Post by jxm262 » Wed, Jan 20, 2016, 2:53 PM UTC

metabrew wrote: post #30

Seems like a good analysis of Meteor's shortcomings. I did some research on related areas a few months ago. My ideal stack at the moment would involve: * redux or cerebral with immutable model * react * css modules * webpack * a realtime-enabled version of falcor, which doesn't exist yet. The last bit is still the missing piece for realtime, as far as i'm aware. Neither GraphQL not Falcor seem to been designed with r…

Aside from Falcor, this is exactly my current stack and my preferred as well. React + Redux + Webpack + Immutablejs + Bootstrap/Less. I'd be interested to hear your thoughts on Falcor or Relay/GraphQL and see what it can offer. For my backend I run some minimal node webservices. I've recently started making all my stuff "pre-rendered" by statically generating my files (react renderToString -> Mustache -> create a file) , with all my needed data in a json file, and only access the webservices when absolutely needed.

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

#54

Post by davidw » Wed, Jan 20, 2016, 2:53 PM UTC

When I saw MongoDB, Meteor got put on a "check back some day" list. Phoenix is way more interesting: it's built on some very solid foundations.

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

#55

Post by oldmanjay » Wed, Jan 20, 2016, 2:58 PM UTC

I can sympathize greatly. I played around a bit creating an isomorphic "framework for frameworks" to explore some techniques I didn't get to use in my day-to-day. There is a constant tension between leaky abstractions and expressing functionality meant to run in very different environments that I personally am taking years to fully grok [0]. Of course, unlike the meteor folks, I'm doing it for fun, so there is no pressure to make any money doing it on my end.

[0] for instance, I made it trivial to invoke client functions asynchronously from server code using normal call syntax. Now how to deal with timeouts? The syntax doesn't permit much without leaking, destroying the original point.

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

#56

Post by bryanrasmussen » Wed, Jan 20, 2016, 2:58 PM UTC

marknutter wrote: post #4

cpplinuxdude wrote: post #2

This is a little worrying; after much research I'm starting a new project for a startup using the meteor stack.

Why worry? Does it solve your problem today? Don't fall into the same trap that so many people fall into who worry far too much about how popular the tools they use today will be 3 years from now. Focus on what makes you productive now . Your startup has a far greater chance of failing than Meteor.

and if it takes longer to get what you need to do done with meteor your startup might have a far greater chance of failing because of meteor.

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

#57

Post by eterpstra » Wed, Jan 20, 2016, 3:01 PM UTC

realusername wrote: post #9

The 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 time savings earned now are worth the technical debt that I might face in the future.

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

#58

Post by goldenkey » Wed, Jan 20, 2016, 3:02 PM UTC

oldmanjay wrote: post #55

I can sympathize greatly. I played around a bit creating an isomorphic "framework for frameworks" to explore some techniques I didn't get to use in my day-to-day. There is a constant tension between leaky abstractions and expressing functionality meant to run in very different environments that I personally am taking years to fully grok [0]. Of course, unlike the meteor folks, I'm doing it for fun, so there is no pre…

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 a cult jargon.

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

#59

Post by [deleted] » Wed, Jan 20, 2016, 3:02 PM UTC

oldmanjay wrote: post #55

I can sympathize greatly. I played around a bit creating an isomorphic "framework for frameworks" to explore some techniques I didn't get to use in my day-to-day. There is a constant tension between leaky abstractions and expressing functionality meant to run in very different environments that I personally am taking years to fully grok [0]. Of course, unlike the meteor folks, I'm doing it for fun, so there is no pre…

[deleted]

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

#60

Post by brandonmenc » Wed, Jan 20, 2016, 3:04 PM UTC

goldenkey wrote: post #58

oldmanjay wrote: post #55

I can sympathize greatly. I played around a bit creating an isomorphic "framework for frameworks" to explore some techniques I didn't get to use in my day-to-day. There is a constant tension between leaky abstractions and expressing functionality meant to run in very different environments that I personally am taking years to fully grok [0]. Of course, unlike the meteor folks, I'm doing it for fun, so there is no pre…

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."