Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The State of Meteor Part 2: What Happens Next

discovermeteor.com

Post reply on HN
Print view View original

61–70 of 153 posts

Re: The State of Meteor Part 2: What Happens Next

#61

Post by faceyspacey »

qaq wrote: post #53
faceyspacey wrote: post #38

Earlier quoted context omitted.

Meteor has as a better chance than ever, ESPECIALLY if 90% of what you can do in Meteor you can do in "bare metal" NPM! Meteor doesn't have to provide that many "features" to win over the NPM crowd that it has struggled to acquire thus far. It's so damn complex to implement all this stuff that most developers need help doing it. Meteor's problem thus far has been it makes it easy but provides no way to "drop down" to…

Unless this comment is from SMM team at Meteor, WTF? What is NPM market :)? "Bare metal" npm? Name single sizable project that uses Meteor? You do realise that for 90% of enterprise projects it's a wrong tool. There is no usable universial/isomorphic option, you can't expose API for external consumption, if you have to consume services on the backend the only cool feature that Meteor has is gone. Not to mention long…

My assumption is that Meteor is moving towards becoming like any other app you can build on NPM. That means Meteor will be the wrong tool anywhere NPM/node/javascript is the wrong tool. That's a fine agreed upon limitation.

Currently Meteor is a layer above NPM, which is why I'm referring to NPM as "bare metal" NPM--you clearly knew exactly what I meant. Meteor needs to become an adjacent resource to thrive.

So my prediction is if Meteor does this correctly they will no longer scare away expert developers and grow more than they ever have.

Re: The State of Meteor Part 2: What Happens Next

#62

Post by vskarine »

sergiotapia wrote: post #46
MrBlue wrote: post #20

Is Blaze vs React really the issue? Try running a Meteor app with >500 concurrent connections.

Let's say hypothetically I have 600 concurrent users, what steps can a Meteor dev take to increase performance?

Most meteor apps are stateless on the server so you can safely scale by adding more servers (and more server to Mongo if that's the bottleneck). This can be easily done with Cluster package (https://github.com/meteorhacks/cluster). It's so easy you don't even need to configure anything.

Re: The State of Meteor Part 2: What Happens Next

#63

Post by paulddraper »

faceyspacey wrote: post #38
joshowens wrote: post #15

Earlier quoted context omitted.

Why would the post be business focused? The guy that wrote it doesn't run "Meteor the business", he just loves the framework itself. I am not even sure how a CMS got mentioned and compared here.

Meteor has as a better chance than ever, ESPECIALLY if 90% of what you can do in Meteor you can do in "bare metal" NPM! Meteor doesn't have to provide that many "features" to win over the NPM crowd that it has struggled to acquire thus far. It's so damn complex to implement all this stuff that most developers need help doing it. Meteor's problem thus far has been it makes it easy but provides no way to "drop down" to…

Quotes or not, this is the first time I've seen "bare metal" applied to npm. Hah.

Re: The State of Meteor Part 2: What Happens Next

#64

Post by EGreg »

apalmer wrote: post #16

I am amazed by how the article attempts to look forward to what the future will hold with JavaScript frameworks... and yet seems to be completely both dismiss or misunderstand (perhaps willfully) why previous frameworks have succeeded. jQuery did not succeed because it was a 'good enough' competitor to dojo or prototype or mootools or extjs... it succeeded because it went completely the opposite direction. it did not…

Frameworks succeed for diffrent reasons. I am guessing your definition of success is being widespread.

Of course, having to swap out both your front and back end or start a new app from scratch to take advantage will limit the number of applications for it.

Why did Wordpress succeed, by the way?

Re: The State of Meteor Part 2: What Happens Next

#65

Post by faceyspacey »

EGreg wrote: post #60

This all boils down to one key fact: Meteor is the only framework that controls the whole stack. After all, the fact that no other company than MDG has even tried to make it happen should be proof enough that it’s not trivial. I did it, over the last 4 years http://qbix.com/platform Actually our platform aims to be an entire "Wordpress for social networks". We realized that identity, security, roles, permissions, con…

yours isn't a full stack reactive platform. great work though.

Re: The State of Meteor Part 2: What Happens Next

#66

Post by imslavko »

sergiotapia wrote: post #46
MrBlue wrote: post #20

Is Blaze vs React really the issue? Try running a Meteor app with >500 concurrent connections.

Let's say hypothetically I have 600 concurrent users, what steps can a Meteor dev take to increase performance?

As the sibling comment said, you do the same way you scale anything else: add more servers that replicate the same data. As it becomes to large, shard your publications depending on type. Meteor's livequery works better serving a lot of similar subscriptions, so at some point you can have multiple server types each taking care of one scope.

Re: The State of Meteor Part 2: What Happens Next

#68

Post by siquick »

glenk wrote: post #32
tomcam wrote: post #12

Might have been different if they had chosen to embrace SQL, instead of just putting it on the roadmap and letting it rot.

This has been my feelings on meteor as well. It looked neat and I went through some of the tutorials and such, but really had no projects I could use it on. All my current projects interact with various sql database at some point. I realize that isn't as cool as all the nosql stuff, but I kept hoping they would get to it, and then kept getting disappointed. It's a pretty narrow full stack to me if you don't have real…

Exactly this..

Re: The State of Meteor Part 2: What Happens Next

#69

Post by all_the_things »

I gave it a try a few weeks ago but every other package was unsupported because a new package was being developed rather than following semver, the standard server logging was terrible when I had to debug a frontend dev's memory issue. Seems like the Wordpress of realtime applications. The DDP package is interesting but only helpful to supported DB's as far as I could see. I think choosing GraphQL will just narrow their 'full stack ecosystem' again. Why not provide better low level support for your community to write GraphQL Cypher, SQL and NoSQL themselves. There are some great packages I've seen for this.
Post reply on HN