Meteor keeps me sane. It isolates me from the insanity in the rest of the node/js community, where everything is rewritten every 3 months and nothing ever works out of the box, you have to duct tape and tinker every time you start a project, and it can be exhausting if you are not intentionally doing it to experiment .
We are starting to see signs of this spreading here, and I’d be cautious to become too invested in the newest and shiniest thing that pops up, because there is always something newer and shinier in just a few months/weeks. Having to re-evaluate/reconfigure all my tools constantly just kills my productivity. I just want to make stuff, damnit!
For me, Meteor is still AWESOME when it comes to development productivity. I came from a frontend developer / UI designer background, and I never thought I would find a framework that made it so easy for me to build a full-stack application. So I am still quite happy with the platform, and I also have a lot of “smile on my face” situations when I am able to solve problems in days that would cost me months if I had developed them on a Java stack (as we did in my former company). The only concerns I’m having at the moment is that MDG could drop fundamental parts of the stack before I can even finish my apps and bring them into production.
Sorry Josh, will probably only have regular cheese in favor of cows (they, imo, are tastier than goats). Hope you and the community visit me at the ranch sometime.
While it’s great that MDG are offering more choices within the Meteor stack, at a certain point does it make sense to use Meteor at all if all you’re getting is a glorified build-tool?
As long as this glorified tool helps me hitting nails and keep me getting a software home make over feeling (you know when the bus rides away, and people start crying), it makes sense. My 2 cents.
I think @niallobrien has a valid point with the sentiment here. If I’m using React, and Webpack, and Redux, and maybe don’t want to use MongoDB (for any number of reasons), and I’m moving to GraphQL from pub/sub… tell me again what I’m using Meteor for?
I’m already using React. I’m using RabbitMQ and I am starting to get Neo4j (graph db) happening. If I start using Redux (like a lot of the newest resources are saying I should because it’s awesome) and Webpack, Meteor basically becomes a generator.
That said, I love DDP. I can use that with my stack and just implement it without the rest of the Meteor stack by using a regular npm module.
To play the other side of the coin, I would say we have to wait and see what comes from Meteor 1.3 and into 2016. I would personally like to see MDG focus on making Meteor the “goto” data layer for realtime JS apps. If Meteor would make it easy for me to integrate any db I want into a realtime app or microservices architecture, I think that would be a huge win.
Of course, if Meteor moves away from the out-of-the-box app prototyping framework that it seems to be at the moment, they will alienate some of their current community.
So here is the multi-million dollar question for MDG: Who is going to pay those Galaxy bills? The prototypers or the devs building the large-scale apps that need/want realtime data but need flexibility in their stack?
… also this…
This is like comparing apples to NY strip loin. Just sayin’…
I think then you might not actually be using Meteor. And that’s fine! Those are all great tools. Perhaps when you start your next app, you’ll pick Meteor. And that’s OK too!
I am actually concerned that MDG started chasing most of the new shining things and trying to support too many (angular, react, webpack, etc). There are some clear things that need to be improved:
Blaze: “The sub-expressions syntax was very lacking for a long time. Having to create a helper for any trivial or complicated operation felt unnecessary. Also data context was a very confusing concept. Often times templates relied too much on what data context should look like and the templates became less reusable as the shape of the data was defined in how template is using the data context.”. In my humble opinion this is not too difficult to fix.
Dependencies. It is a little crazy that the modules get included in alphabetical order with the exception of the /lib folder.
Make easy to find the “blessed” packages among the clutter.
Full support of ES7 (including async/await).
Create a easy way to scale MongoDB and the reactivity of the UI to millions of users.
For the rest, I think that when we get to speed of development, Meteor is a faster tool to develop with than most react+flux boilerplates and angular ones.
Create a easy way to scale MongoDB and the reactivity of the UI to millions of users.
This will never happen. Meteor is holding 100 concurrent users on one node tops, and it doesnt scale vertically because of op-log, and it doesnt scale horizontally because of
…well, oplog.
Sure you can remove most of the reactivity, but now you’re stuck with sticky session and websocket when your app is not even reactive
I meant the opposite.
You asked: What’s the point of Meteor if there are other tools doing the same thing?
I believe it’s good to have multiple projects that tackle the same problem in a different way.
100 concurrent users tops? That can only mean you have no idea what you’re doing, for 2 reasons:
There’s an array of factors that determine the number of concurrent connections you can handle - the app itself doesn’t monolithically determine your ability to scale. 100 is just a random number you chose, right?
I’m terribly inexperienced with deployment, but have managed to scale a reasonably interactive app to 400 concurrent users using Digital Ocean and Compose.io. This is without clusters (only one of 4 cores utilized), and some pretty faulty design patterns I haven’t been able to fix yet.
EDIT: we barely crashed at 600 and had to take down the server for a while
do you have any idea what kind of things OPLOG does to your app servers when you scale out? I am talking about real time apps here and i replying to someone who thinks MGD can scale out mongo to millions of users real time
600 users all real time single box ? cool, how much real time do you actually have ?
yea, it’s not data heavy at all and can’t say all 600 were interacting. That being said, you’re absolutely right about oplog tailing, but it’s not like we’re going to be stuck with that forever.
Progress on graphQL and Meteor’s data layer will eventually make way for something better. I’m also excited about RethinkDB coming to Windows soon!
I believe MDG announced they would emphasis professional use more in 2016, and that the data-layer is going to be reworked??? Correct me if I’m wrong
i have no idea what they are gona do actually, my point is tho, if you’re app is not real time, then why not go for node.js backend for more flexable data backend? If you need alottt of real time, node.js is definitely not the job for it. That leaves meteor only good for prototyping, because of its fast start. But having to wait 30 sec between file saves is not saving people any time even for small projects
and had to take down the server for a while