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

21–30 of 189 posts

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

#21

Post by subpixel »

marknutter wrote: post #3

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

> Another issue with Meteor is that it was envisioned, not extracted.

This has been the Achilles heel, in my opinion.

On what might be the bright side, this sort of thing is starting to happen, albeit from the outside (e.g. not from Meteor, but from a company who hitched their wagon to Meteor):

https://kadirahq.github.io/mantra/

This is great, but the envision/extraction disconnect persists within Meteor itself, where it matters most.

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

#22

Post by orthoganol »

> 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 because there was a need at the time, likewise with frontend JS frameworks (which seems to be consolidating around just 2 - React and Angular), and likewise with Node as filling a need for easy async. I'm not that knowledgeable on Meteor [1], however I think by default it's reasonable to expect no new frameworks to have mainstream adoption without a major change to the web.

[1] I don't know if Meteor's x-platform appeal is enough to convert users from other x-platform, native and/or hybrid solutions (Ionic, Titanium, RubyMotion, etc.).

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

#23

Post by magicmu »

The 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 actually had a total mastery of what was going on under the hood in meteor, which was a terrifying realization. All things considered, though, 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. On the other hand, blaze is pretty rough...

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

#25

Post by warcode »

Meteor has been perfect for the single page web apps I've been making as side projects. I don't know any other frameworks where I could have completed an encrypted chat application as fast and painless as I did with meteor.

All the things mentioned as "going beyond basics" seem like things that meteor was never designed for and that we have other tools to handle.

I really feel like the problem is with the people behind meteor trying to make it THE framework, instead of just being a framework that excels at a single purpose.

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

#26

Post by mariusmg »

orthoganol wrote: post #22

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

"likewise with frontend JS frameworks"

And jQuery. Probabil still the most used JS library.

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

#28

Post by arcatek »

orthoganol wrote: post #22

> 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'm far from being an Ember-fan, but it's still going well too, even if it doesn't have as much hype as the two poster boys.

As for Angular, I feel like it's still too early to tell how it will end up - I loved Angular 1.X but eventually switched to React because it was much more convenient and only required minimal boilerplate. Angular 2 doesn't really make we want to switch back in its current state.

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

#29

Post by marknutter »

magicmu wrote: post #23

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

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

#30

Post by metabrew »

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 realtime model updates (via websocket) in mind.

Post reply on HN