Let’s make meteor the best it can be, and we’ll figure out how to pay the bills.
11 Likes
It’s called Discover Meteor 
But seriously, I feel like this “Meteor Classic” approach is the wrong solution. I’d much rather have the community focus on making the “new” Meteor simpler and easier to use than divide it between people who want simplicity, and people who want cutting-edge-ness (or whatever you might call it). What if you want both?
I feel like Webpack provides a good case study: for months all I heard about Webpack is how hard it is to set up and configure, yet @benoitt was able to create a no-config, drop-in “Meteoric” Webpack package. Personally I think this is the right path for Meteor: move towards the rest of the JS ecosystem while preserving ease of use as much as possible.
15 Likes
Well, my posting above wasn’t against Meteor. I just think that “Meteor 2.0” will be the framework for Apollo, so it’s only changing but not dying.
Oh sure - I’m just saying a big part of the Apollo strategy is monetizing the data layer directly, in addition to Galaxy for the full-stack platform angle.
The problem I see with this is that you just arbitrarily decided you would put some Rocket.Chat people in charge of refactoring the Accounts stuff and it never came to pass. I offered to help and never really heard back. The accounts packages are in terrible shape and can be really frustrating to work with. Things like accounts-twitter and accounts-facebook pull in Blaze still, leaving Crater with a bunch of extra/dead code we don’t use in our already out of control JS bundle.
I’ve certainly spent a lot of time building packages around Meteor accounts-base over the years and have a good bit of knowledge of it.
Is that set of packages being maintained? Looking mostly lifeless atm. I also question the viability of Blaze going forward when things like React and Angular are more performant, have better tooling options, and are more widely adopted by the community at large. Useraccounts set of packages suffer from a deeper problem of relying on Iron Router and Flow Router, which aren’t being actively being maintained anymore from what I can tell.
I’ve been personally pushing clients to adopt more active and widely accepted packages from NPM like React Router, instead. Better to rip the band-aid off now and at least gain some decent performance at the same time.
2 Likes
They actually made a lot of progress.
Would you like to make a PR to remove the blaze dependency from Accounts? I would immediately click “merge” on that one, and we could check that task off!
5 Likes
Would just making it a weak dependency work? Or is it more involved than that?
But wasn’t a lot of their progress around trying to make it db agnostic so the postgres package could work?
Ok, will see what I can do, would love to fix this issue.
4 Likes
Yes, that is part of it. We would also have to look at where accounts-ui and Blaze are being used inside accounts-twitter and accounts-facebook. My guess is that the oauth config interface lives in accounts-twitter and accounts-facebook, but maybe that could be moved off to service-config-ui or some type of package?
Just to add my two cents, as someone who came to Meteor from php and jQuery:
React vs. Blaze vs. Etc
Performance isn’t everything. With complexity comes maintenance. And at the end of the day, when view layer purists are focusing on squeezing every last bit of performance out of the browser, how much attention is really being paid to what’s actually being displayed? As Google will inevitably teach us time and again, content and accessibility are king.
Perhaps part of the reason I’m turned off by React is because it drives the metaphysical wedge between code and content even further. Which, interestingly enough, is a separation that seems to drive the company (and CEO) behind the technology.
I still believe in Blaze and am excited for a community-maintained package. If Meteor Classic is realized, I can’t help but think Blaze is a part of that.
Packages
While Atmosphere was originally amazing, I think the unintended consequence has been this swirling mass of packages that follows Meteor along through each release, with little curation and no way to easily identify the viability of a package. I think the sheer number of users who come to these forums with questions about IR is an indication that (especially for newbies) Atmosphere can be more a curse than a blessing. Which is unfortunate, because NPM can be a tough place to get started.
In all honesty, before working with Atmosphere packages, I found NPM frustratingly hard to understand and work with, another testament to some of what made “Classic Meteor” great.
Classic Meteor vs 1.3+
I think most of us would agree that 1.3 marked the definitive change between what we know as “Classic” Meteor and the “New” Meteor. And while I think we would also all agree that many of the changes in 1.3 (and since) have been truly beneficial to those of us developing apps for production, I also think that the concepts (and original Meteor principles) are harder to grasp as a result.
Again, in looking at the posts here, you can see Meteor newcomers debating about view layer choices for non-production apps that haven’t seen a line of code, or trying to decide if Meteor makes sense for an app they’d like to try out.
I feel like in the old days, when Meteor was more opinionated, you could just tell a newcomer to dive in and find out if they like Meteor. Now that dive comes with choices and baggage, Atmosphere vs NPM, imports, folder structure choices, build and install issues, etc. Which is fine, if you’re deciding about a long term project and js frameworks. But not so much for “Hello, world”. (Or in our case, “You’ve pressed the button 3 times.”)
I love Meteor. I don’t love it any less today than I did in 0.8. But if I didn’t know Meteor, and we met today, I’m not so sure I’d have the patience to fall in love.
What Classic Meteor Means to Me
While I look at Meteor now largely as a tool, that’s not at all what it was to me initially. Initially, it was an experience. Just like the first time you connect the circuits in science class and see the bulb light up, the first time I deployed and saw a web app that I had written, with a functioning db behind it, on an actual website – holy ****!
That is an experience.
And I feel like the community (and perhaps MDG) has lost a bit of that initial wonder and excitement, in lieu of what is ultimately a better long-term, viable, business-backed strategy.
I guess my hope is that amongst all of the new and wonderful things we can do with Meteor, the fact that it can turn a lowly jQuery hacker into a full-fledged web-app developer isn’t lost in the mix…
13 Likes
‘Meteor Classic’ & ‘Meteor Pro’
Hopefully it at least stopped a couple of them 
I’m all for constructive discussion, and a lot of this post has been. Much due to MDG showing their presence via @sashko and willingness to meet the issue head on.
Honestly, the fact that the community has noticed a lot of people complaining, means that a lot of people are using Meteor. Which is a good thing! I do feel that a lot of the posts seem to miss the mark in terms of understanding the meteor (or other frameworks) paradigm. I sometimes read them as: “Can we stop using this tool because I don’t understand why X does Y and it makes my code bad” or “I don’t understand how this tool works or what it’s actually meant for. Can we change it so I do?”
I’m all for anyone forking meteor and doing whatever they feel like. Perhaps a few PRs will make it to the “mother-repo” and improve the product. But I’m also for a centralized group to give the tool direction. I’d much rather have a tool that does a few things well(and then uses npm for extensions) than a tool that attempts to do absolutely everything!
I’ll take a bit screwdriver over a swiss army knife any day of the week.
Wow, very active thread. Re accounts (cc: @joshowens, @sacha, @sashko)
Just a heads up that I’m currently working on an apollo-passport package, that, as you can imagine, is a wrapper around PassportJS to work with Apollo, and heavily inspired by Meteor accounts (it also uses JWTs). It’s not tied to any database or UI framework, and there are official packages for RethinkDB and React, and it’s fairly easy to replicate, e.g. @tomitrescak did a MongoDB driver in 1 day.
I hope to make an official announcement in the next two weeks. It’s built from the beginning to be community maintained, in it’s own github org with 100% test coverage, jsdoc, sensible contributing guidelines, etc. I would especially love for contributors from the Meteor community to get involved and I mention this in the README.
I decided to start fresh vs porting the current accounts stuff to avoid removing blaze, ddp, minimongo, flow from each package, and also to leverage the 300+ strategies already available for Passport. Unfortunately this leaves quite a lot to do, but it’s great to add features incrementally with full test coverage.
As said, announcement coming as soon as I’m ready for others to get involved, but feel free to open a new topic before then if you’d like to discuss, and @mention me (rather than hijacking this thread).
15 Likes
Or Meteor Classic and Meteor Standard … using Pro implies that it’s somewhat ‘better’ which I think is subjective.
“Discover Meteor” … hmm … sounds familiar 
I would agree it’s more of a marketing / presentation / training approach. We need to cater to all users.
Let me add this as many people want to break with the past and just steam roll forward.
Point #1
We deployed our App with Blaze (which we internally refer to as Handlebars – anyone using expressjs would know that hbs is one of the most popular frameworks around). It took us a few months to migrate to Meteor, and we are now growing exponentially (US, Canada, France, Far East) and even have been approached by Google and Microsoft to attack new geographies. And the app is working beautifully!
Point #2
We are often asked to add features. Thanks to Blaze, we can often simply make the changes in the templates quickly, and push, and clients are super-impressed!
Point #3
We had to translate to French (and soon Spanish). A whole complex app was translated in under two days and started sales cycle almost right away.
While I sympathize with consultants being able to make more money off React, we will invest in Blaze, make it more performant. We want to see virtual DOM in it. Ember is still growing, a testimony that html-based engines are still alive and well.
People talk about spaghetti code … we haven’t seen that. Maybe some ‘programmers’ need to learn the basics of good programming instead of blaming it on their tools.
8 Likes
sashko: Meteor 1.4 is the last release to include an MDG-published Blaze. Future releases are managed by Mitar, as far as I know. I understand it took a long time, but it’s really happening.
I’m not visiting these forums often, but last time I looked, MDG stated, explicitly, that Blaze would stay. Now it’s not. Thing is, everything you do and say has consequences. The fact that MDG stated that the rumors of Blaze’s death was unfounded made me skip React and start projects using Blaze, since it did all I needed, and that sends me out on a path of relying on third party developers who any day might decide they want to open a bookshop instead.
I am currently very frustrated, Meteor 1.4 (not 2.0) suddenly breaks my deploy infrastructure, an infrastructure that relies on community projects that now seem to be abandoned (mup). Maybe abandoned because it no longer fits into MDG’s new plans for our future.
Yes, Meteor is free, but the stuff we create with it are not. We invest huge amount of time and we build software that someone is actually paying for. We need predictability because our customers need predictabillity. “Sorry, can not do that because the stuff I’ve been using for your stuff has been deprecated and some vital parts are no longer maintained on Github, so we must refactor everything for a huge amount of money”.
Meteor was a framework, now it is a collection of fragments. There is nothing to love anymore, nothing whole, just some fragments to like and others to ignore. Just like before Meteor.
3 Likes
Glad to see the will to keep the classic Meteor going. I have a router coming that I think will be great for the classic stack.
IMO the most important thing is to solve the oplog issue. Maybe just Rethink working through the server and pub+sub would do it.
2 Likes
Blaze is staying, but is one of many UI options and the community will have to maintain it (just like React and Angular)
1 Like
I read in the (now closed) “Sad state of web development” that it was being deprecated and I just quoted sashko saying 1.4 was the last Blaze release from MDG. What gives?