As the project grows I found Meteor more manageable than most other frameworks/platforms out there.
But the rest of your post, is exactly what I mean… 1.3 has become more verbose and less productive. 1.4 hopefully won’t be too bad based on change list but I haven’t looked in to it much until it’s a RC, but Apollo seems to be a completely different beast… and I’m worried about how it’s going to change Meteor in the end.
I don’t mind learning something new, but I DO mind the primary software I use becoming less productive and more verbose. Would most of us even be here if it wasn’t so productive…?
I recently came back to Meteor after about a year and YES, why has it gotten so much more verbose? That was pretty much the reason I got into meteor in the first place, it was dead simple and productive.
Why bother integrating Apollo into Meteor proper (thereby in a way deforming/mangling the stable-just-works-easy-to-use-not-verbose Meteor we use today)? Why not start over, start fresh, with Apollo and Saturn as a new stack (or even use in conjunction with Meteor)?
They seem to be making Meteor “less safe” with this strategy (or is that the idea)…
From what @sashko said it sounds like Saturn is unlikely to become a “product”, and far from make Meteor “less safe”, Apollo’s making it more robust, scalable and more appealing to a wider audience. I have to say I got somewhat stoked!
@robfallows, I can’t tell to whom you’re addressing, so I’ll pick up your comment:
No, I haven’t heard the latest Transmission episode, but it seems plain to me… and others:
… that they’re gutting the entire Meteor stack as we know it today in favor of Apollo and all the tech that will form the glue around it. Maybe you and others are excited about what all this will mean, but I simply don’t have the luxury of such indulgences when I have a full fledge production application running Meteor 1.1 on the market.
If it’s true that MDG is “corse correcting” as others has said/suggested (and I believe), why not leave Meteor as it is today to the community and start over with their new Apollo strategy on a clean slate? Why is MDG ever-so-slowly replacing the Meteor stack with the Apollo stack?
That’s almost like saying – YES, Saturn is to become the “Product”! (also, maybe this IS MDG wiping the slate clean after all in some respects).
I just don’t agree with you on this. It has become “less safe” than it was 6 months ago. The future we’re told (for now) is SQL/Apollo/Redux or **Saturn/React (to replace Mongo/DDP/Tracker/Blaze). But wait, this new strategy is not fully baked, and based on roadmaps floating around we don’t know when this tech marriage will be ready for production apps.
Now start a real project today (one that you or your company will make money off of and will be client facing) with Meteor and tell me how safe you feel you made the right choice.
** The Saturn repo: “Saturn (at least initially) is heavily inspired by (/ outright copied from) the React Redux Universal Hot Example, and hjs-webpack.”
That would be you - I clicked the wrong reply button
I’m excited, but that’s not to say I’m comfortable with all the new learning I need to do.
We have an app at 1.2.1 - which we’ll upgrade to 1.3 - but retaining the traditional all-packages architecture. We’ll upgrade to 1.4 using the same strategy. Looking beyond 1.4 is less clear, but it seems unlikely that the rug will suddenly be pulled from under us. If it is, well at worst we’ll just continue to support the app using the highest level of Meteor which allows us to do the least work in upgrading. We may bite the bullet and rework to use all the latest “good stuff”. We did that for Blaze to React and it worked out well refactoring piecemeal over several sprints.
Let’s face it, if I wanted to, I could checkout the 0.6 branch of the Meteor repo and build myself an application with that. I honestly don’t see that we will lose the ability to pin our app to a particular point in Meteor’s evolution given that has always been a feature of Meteor.
Given @sashko’s comments on Transmission, it sounds like we’ll have a lot of easy-win (typical Meteor workflow) situations in 1.5. We’re already integrating data from MongoDb, MySQL, MSSQL and SAP HANA. That sounds like it should be a whole lot simpler with a tight Meteor/Apollo integration.
Of course, it’s all speculation on my part, but I’m optimistic.
Fair enough. I’m in the same boat, but unlike what you guys did, I’m waiting to see what that stable version looks like before updating. Besides, I made the mistake of using Autoform, instead of rolling my own, so I’ll have the added work of migrating off that tech.
I’m so busy adding new features and improving the software I don’t have the cycles to rework then entire app – it could possibly take months of rework.
Really, you don’t see what is lost by pinning our apps to a version ad infinitum?
I think what @Spyridon was really saying is that he wishes Meteor was as user-friendly as it used to be. Part of the problem is that you guys didn’t invent React so despite all it’s advantages, the syntax can be rather obtuse.
So you only just don’t like the new Javascript. Meh.
The only react-thingy there is in your screenshot is the embed html tags. Every thing else is standard.
It is true that what I’m saying is it’s not as user friendly, but not necessarily because of React. My primary project does not use React.
My main problem is it does take more time to work in Meteor than it used to, and I’m worried if this trend continues in to the future.
I am already very comfortable with Meteor (this last project of mine has been worked on for over a year), but I do recognize that being friendly for new users is an important priority for Meteor to grow. And Meteor has been lacking in this department since 1.3 as well.
So it seems Meteor has became less user friendly as a whole - both for new users and experienced ones. It’s still manageable right now, but if the transition to Apollo and NPM require the same kind of trade offs of development speed & user friendliness for functionality, there’s going to be trouble.
Personnally, I do believe that Meteor is dying, because some of the major packages out there are not maintained anymore. You can clearly see it in the Graph Activity in Github and the number of issues piling on.
Just to mention a few: Simple Schema, Collection2, CFS, Iron Router and more recently Flow-router, meteor-roles, meteor-spin, etc. Basically most of the major packages. They were actively being worked on last year but not anymore.
Now look at the comments in that blog post and the GitHub activity:
Clearly there won’t be a Flow Router 4.0, I highly doubt it.
and 3. I’m not talking about NPM package wrappers. The packages I mentioned are meteor-specific, MDG-recommended, packages. Packages that you need to develop real-world applications.
The people that have developed these packages (arunoda, aldeed, etc.) seem to have basically left within a few months. Meteor does not have a strong community of developers actively participating in the development of third-party packages able to take over.
I have invested months of work in developing a meteor-based app and honestly this is extremely worrisome to me.
(also, maybe this IS MDG wiping the slate clean after all in some respects).
so despite all it’s advantages, the syntax can be rather obtuse.