I for one have stopped using Meteor - the main issues was the slow build time, the difficult deployment and also I wanted a stable system - not one I had to keep updating because Meteor changed the way things worked.
I didn’t get the memo, what’s disappointing about Galaxy?
1 Like
Just curious, what framework are you going to?
pure nginx and static html 4 
7 Likes
Correct me if I’m wrong, this makes it sounds as if they’re going to replace the entire stack (over time) and rewrite the glue (to be best in class) as their competitive edge.
1 Like
I hear you with regards to the slow build times, but I’ve never understood the “difficult to deploy” issue. As a quick example, here are 8 steps for getting a self hosted Meteor app deployed on Linode:
- Provision a new Linode VM with Ubuntu.
- Security harden the new VM.
- Install mupx to handle deployments (let it take care of node, mongodb and nginx installs via docker).
- Make sure the SSH user that will be used with mupx is in the sudo group and has NOPASSWD (see Additional Setup/Deploy Information).
- “mupx init” in local project; adjust mup.json as needed.
- “mupx setup” in local project.
- “mupx deploy” in local project.
- Profit!
1 Like
I’m new here, and even I get the sense that I missed the peak. I started doing a Meteor project (I have done 2 shipping projects) in May this year, and when I did that I found so much cool stuff that all worked out of the box. In particular, Aldeed and Yogiben’s stuff, but plenty of others. I started to notice problems when Meteor 1.2 was released. Folks just didn’t seem to update their packages, even when doing so was very very minor, like updating the less dependency (and I provided patches that languished for months).
Other than that, I still think Meteor has something, but it’s really the focus on developer experience. The package manager is so much easier to use than npm or bower, and creating and forking new packages is even a breeze.
I’m not sure if the activity has died down, or if there are just some very very popular packages (and package authors) that have been dropped (like Meteor Admin and some autoform packages - and judging by how many package yogiben and aldeed have produced, I can’t say I blame them), but being relatively new to this table, I hope Meteor sticks around for a while.
Finally, React is all the rage these days, but it does feel like it’s shoved in side ways a little bit into Meteor. Meteor could do something things to make it better. For example, a set of helpers as an object on a React class instead of just having the one reactive method. I also wonder if there might be a better Blaze like way to bind methods instead of putting everything inline the React way. And having some Blaze template tags (handlebar style) would be real nice in React. Ternary if statements and self invoking ES6 functions are ugly and less readable. If it were me though, I’d leave React basically the way it is, and add the Blaze stuff on top of that, rather than trying to go back to the Blaze way. It’s nice having an entire component (or even a set of components) in one file.
Switching to React also has it’s costs - there is no autoform for React (I know you can wrap it, but still).
Also, let’s get some React Native. And yes, some GraphQL, and PostgresQL. 1.2 was about multiple view layers. Maybe 1.3 can be about multiple databases.
3 Likes
Just curious, what framework are you going to?
I went back to node and express with mongoose for the db link - build times in Meteor was around 15-20 seconds - now it is less than 1 second if not nearly instant. Using Bluemix for deployment - extremely easy to use and has a lot more features.
I only thing I will miss is this forum - the users have always been very helpful.
The good news is that you can still hang out here if you’re not a Meteor fan … I’m looking at you, Phoenix Posse!
4 Likes
With Bluemix the steps are
1: login to Bluemix
2: Click on the app to update.
3. Click on "start coding"
4 - log into command line interface
5 - enter cf push
It worked first time I tried it and every other time afterwards.
Don’t get me wrong there is nothing wrong with Meteor - just that in my case I did not need 3 way data bindings so many of Meteor features were not being used.
Nice! To be fair though, I was providing quick steps for getting a fully self hosted solution in place (with all of the flexibility that comes from controlling the complete server/VM/container). Using Galaxy, Modulus.io, Scalingo, etc. is much more in-line with the Bluemix steps.
It looks like they will have to, but maybe unlike react they can keep the same subscription interface for those who want it, just built on top their new super robust graphql implementation.
I don’t think MDG will be able to suffer the same response as the blaze vs react fiasco when it comes to their subscription interface.
…now I don’t know that they r building this. @sashko hinted above. Care to elaborate @sashko lol? …but basically they were late to the party on the react thing, graphql is an opportunity for them to redeem themselves, while also fixing long time issues with LiveQuery.
Basically this is the opportunity to publish events prior to writes, rather than tail oplog. Graphql seems to be built specifically for that. So that’s why graphql is likely a lot more appealing than react ever was to them. Graphql provides a playground where they can focus on getting implementation perfect. Whereas before when it came to subscriptions they had to worry about interface and a lot of other things.
So as far as mongo subscriptions go, there is mongoose + graffiti By rising stack. But what’s missing and what’s also missing from graphql altogether is subscriptions. That part of the spec isn’t complete. I assume it will be complete any day now. But I also don’t think it needs to be complete for MDG to start implementing what’s under the hood there. Their are proposals for the interface and it can likely by adapted near the end of completion of implementation. So basically MDG can put DDP and the best of LiveQuery to use plus long time ideas to fix performance, eg observe writes and propagate those to subscriptions instead of oplog tailing, in order to do the subscription stuff graffiti does not do, and likely will never do, and honestly what’s the most complex part.
Graphql is all fine and dandy but without subscriptions its worthless. I really don’t understand why subscriptions weren’t a first class priority. Along with relay it feels like it was, but in fact those queries u specify in ur react components run once! It also seems ur gonna have to specify them again in subscription form, which seems stupid. We do that in meteor but the way relay works is it populates props of the precise component where its used rather than universally give the client the data–so u shouldn’t have to specify both a query and a subscription; I hope it works out that way in the end.
So anyway my overall point is that MDG has an opportunity to shine here. Be the first one to make a subscription implementation for a major database for graphql and that will be a big deal. Think about it–this intersection of the stack ties so much together, u basically will need to come to meteor. I do think they should abstract it out of meteor as discussed above so they can have a product appealing to a larger audience and therefore has potential for more longevity. But with the best implementation of it, ie the most coupled addons in Meteor, it will make the most sense to try it out in Meteor itself, especially in the early days.
If this wasn’t meteor, u need node, npm, express, mongo, react, relay, ddp, isobuild, etc to demonstrate this. Thats what I mean by “intersection of the stack.” It covers that middle ground where the client perfectly touches the server and is connected over the wire via ddp. There’s competitors to ddp such as that Json tokens library, so it’s not like at this point Json over a sockets library is that big of a deal. But collectively it’s a lot to put together. This gives meteor an opportunity to learn from its mistakes and apply all it’s knowledge about isomorphic apps nobody else has.
My hope is they get the marketing aspects right. That means building this irrespective of meteor so it becomes the defacto mongo graphql subscription LIBRARY. And maybe while they are it, the rethink db one. But more importantly a pluggable subscription transport library for NPM apps. So where meteor requires u to buy into a huge stack, they offer Meteor.publish/subscribe for easy use outside of meteor–and of course I’m referring to whatever the graphql interface ends up being.
As long as they continue with the proprietary approach that only works in meteor (or at least is mainly used there), more general packages for smaller portions of the stack will gain more popularity on NPM. That’s the NPM vision in general. I think MDG should entertain partaking in that vision. The question becomes: will people just use our package and not in fact adopt meteor? Will we be giving something out and not getting anything in return? I think the net results will be better. U will get more overall lock-in toward something they built. Just as graphql is seemingly gonna garner a lot of lock-in or as react already has, this library I’m proposing could as well. More lock-in than an opinionated full stack framework ever could in the post-rails npm world. With that lock-in they have the best possible hook to motivate people to come to meteor proper via value adds.
…maybe it’s pie in the sky that we could become THE GRAPHQL SUBSCRIPTION TRANSPORT LAYER, but it’s worth a shot. At the very least if would mean a hell of a lot more community contribution than meteor is used to. It’s time to branch out into the world. NPM dictates this building block vision.
5 Likes
In a perfect world, at this point, I would start with a plain old node.js project. If they were node modules, I’d import ddp, minimongo, and a few other things that Meteor does great. Then I’d do my own thing. I anticipate that, with more time, managing a meteor project will be eat into my ability to innovate. I’ll get sucked into tasks like switching from Blaze to React, and whenever the DB layer becomes abstracted, there will be some sort of ORM to migrate to as well, and when atmosphere inevitably closes shop and gets folded into NPM, that will just create more work for me.
2 Likes
How will this be different if you start from a plain Node.js project?
Better to say Meteor is dissolved.
Had I started with a plain node.js project, I would have certainly invested more time upfront choosing the technologies that go in to my stack (I’m not saying that MDG has not done this – however, it’s something I should have done personally). Choosing something like Meteor is a choice that basically says, ‘these guys are the experts, I’ll offshore those decisions of what needs to go into my stack’. As my development resources are currently tight, it pains me to continue writing Blaze code. I didn’t anticipate needing a more stable stack like I do now. Sure it will work, but I’m knowingly using dead tech. And if I wrap it in a blaze-to-react integration, then I’m just including both technologies in my initial page load JS, further slowing down my site’s initial load time. I feel caught in a bind, and my gut tells me it isn’t going to get better soon. Maybe I made the mistake of viewing Meteor too much as a silver bullet (I can’t be the only person who viewed Meteor a little too zealously-- your marketing efforts were too good :p). What Meteor looked like when I bought into it looks different from where it is now, and with time that will diverge further. I still believe in the core principles of the Meteor project, maybe just not on how it was delivered.
If the plan was never for Meteor to be so opinionated, why did it start that way? Had you only provided ddp and minimongo, and developers focused on the rest ourselves, we wouldn’t be having the blaze -> react migration discussion. I guess the answer would be ‘to get Meteor to market sooner’ and ‘nothing like blaze existed at the time’, but that came at the expense of a good developer experience. Managing a project as it grows is part of the developer experience.
1 Like
I guess what I’m saying is that it’s equally likely that whatever technologies you picked that weren’t Meteor could also be changing dramatically. For example, if you had built your app using Angular 1, you’d be in a very similar position when migrating to Angular 2.
9 Likes
I can only speak to my personal experience with Meteor, but when I was initially getting started with it last year, I feel as though if all you got out-of-the-box with Meteor was ddp and minimongo, it would have been tough to sell me on adopting the tech.
Part of what has made Meteor sticky for me (and countless others) is the rapid dev/prototype cycle. Piecing together a boilerplate stack for projects takes time, and while you may ultimately end up with exactly what you want, when swapping elements in and out on a per project basis, you end up cutting into your actual dev time.
Every tech/stack has its pros and cons. I always find it interesting here that in spite of the obvious pros, the cons always end up being at the forefront of discussions…
4 Likes
Agreed - but then @sashko usually replies with an answer that shows the cons are really pros, and everything becomes right in the world again.
5 Likes
I’m not sure I agree that the score is a bad choice for ranking packages, I’m just saying it wasn’t necessarily useful to display a timeseries of it over a week for a single package.
All the other metrics would suffer from issues that the synthetic metric aims to ameliorate. Basically all of the examples you quoted wouldn’t be very interesting, the top packages would just always stay at the top even if they weren’t being updated ever (for example IR). Basically the whole site would be the Most Used list.
Have you seen specific issues with the “trending packages” list or the ordering of search results in terms of popularity? I usually feel pretty OK about the order things are presented to me.