MDG’s plans and priorities

announce
143

@suhaila as brajt as stated, the reason people are complaining is because MDG states in their guide that the backwards compatibility is probably going to be removed in the next update. So the old way is there today, but may not be tomorrow.

I don’t mind the functionality. I just think it should be a option provided by Meteor, not a requirement. Reason being many (if not the majority) of projects don’t need that functionality, and using them is against the principals Meteor was built on.

Same here… it honestly looks a lot more like a JavaScript version of Django now.

No. Not according to this page: http://guide.meteor.com/structure.html

File structure is completely different.

I really love Meteor too. I’m just very worried that it’s turning from the software I loved in to… something else entirely.

2 Likes
144

And I disagree that it should be optional. I feel like if we keep up this mindset that JS is “too hard” and Meteor is our way to “dumb it down,” (how it seems like from some of these threads), than I feel like Meteor doesn’t have a bright future.

I feel like helping people understand what import/export is and how it works (and other ES6-7 features) is a much more valuable use of everyones time than making this to obfuscate whats happening. There are cooler things that MDG could probably be creating.

145

No one said js is “too hard”. The argument is that Meteor is giving up the principals it was built upon in order to support these new features.

You have ignored the point I made in my last response to you, and that point is that what they are doing is completely against the principals Meteor was built upon.

That’s exactly why some of us feel it should be “optional”. A project shouldn’t “lose it’s soul” in order to support features, or else it simply isn’t the same product anymore.

If Meteor - as a product - was intended to fulfill specific goals, and still to this day claims to stand by those same goals, and the way these new features work is not conducive to those goals, how could anyone expect the change to be supported by the community?

You mentioned Meteors future… If Meteor gives up the principals that have gotten it here, it’s giving up the users who have supported it this far. Do you really think it’s going to have a bright future in that case?

Some of the people who have expressed the same sentiments as I have, are some of the more active and helpful participants on these forums, and very big supporters of Meteor. How bright would things really be if they weren’t around anymore…?

You can take any product, any brand, and find examples of this. Would it help WordPress if they completely gave up the ability to blog in order to better support creating full websites? Chipotle was founded & grew based on the concept of fresh locally sourced foods (lets ignore the outbreaks). If they gave that up, they would lose their whole customer base who supported them for that reason. Would they have a bright future? How about if Whole Foods gave up those same principals? They would lose what they were built upon, and they would no longer be the same thing.

I’m not sure how you could support a product giving up it’s principals. That removes the security you should be allowed that Meteor is going to be what you know it and love it for. Why would anyone want to choose Meteor when in 1 year from now, Meteor may not be the same thing anymore?

Without having to look at any other variables, it’s easy to be 100% certain that a project giving up it’s principals it built & grew with will not end positively.

3 Likes
146

Because they like the direction it’s moving in? I honestly think that’s the case for the vast majority of the people who use Meteor every day.

It is my impression that there people who are unhappy with the changes are a vocal minority. The people who are very happy with the changes have also expressed that, but they’re obviously not writing entire paragraphs.

I believe if you look at the 1.3 announcement threads and count how many people liked the new release and how many people weren’t liking it as much, you’ll see that there are more people liking it than not, but you’ll also see that those who didn’t like it tend to write a lot more.

I think it’s very useful for MDG to be able to get both positive and negative feedback in the forum, but I think it’s also useful to point out that concerned and dissatisfied users tend to write a lot more, so the impression one gets from reading this thread or others in the forum doesn’t accurately reflect the feelings of the wider community.

5 Likes
147

I think you misunderstood the part you quoted. Let’s say you liked the direction it was moving in right now, but then next year it went in a completely opposite direction. That security you had in the piece of software you chose for your project (or your business, in my case) is gone, as well as potential investment in the software during that time, as the software does not fulfill the same purpose anymore.

I was one of those people that was happy with the direction it was moving in, up until 1.3 hit, and the tutorial/guide got completely changed around (ruining plans for new employees to study it prior to my teaching - the new tutorial doesn’t match structure or coding conventions), and it was announced that the backwards compatibility is likely only temporary.

BTW, a number of people who express the same opinions as me are regulars on this forum, not just random users who are vocal about being upset. They were here before, not complaining, but rather participating and helping the community. I think their opinion means a little bit more due to that reason.

I would not go as far to say the minority or majority was happy or not right now. It’s not fair to judge. Many people haven’t even upgraded their project yet - if they did you would see a lot more confusion and questions on the forum than you do right now. And the backwards compatibility is still there right now. Their projects still work.

I actually believe most users aren’t even aware of this issue. The only reason I’m aware is because I noticed such a difference in the documentation (as I was prepping for new employees) and found out by word of mouth here on the forum that the reason projects are still working is backwards compatibility. I also found out backwards compatibility might be dropped through this forum here.

If you aren’t monitoring these forums, you aren’t likely to even be aware of these changes…

Your average person wouldn’t complain until things just stopped working.

Don’t you think there might be a HUGE amount of complaints if 1.4 drops and takes away the backwards compatibility, and then users have to go through hundreds-thousands of files adding more code just to get things working, or be able to access any of the new features in 1.4? Or to potentially apply any fixes for security vulnerabilities that may appear?

Seriously… How different is this from the whole React situation last year? People went nuts because they didn’t want to have to rewrite a large portion of their project based around forced changes. That is a very similar situation that we are in right now. Only difference is things are still working for now and they have made no official announcements, so most people aren’t aware yet. But do you think it’s going to be well-received if people have to write over that much of their project if backwards compatibility is dropped?

148

Would it be possible to create something during the build process that automagically inputs all the needed import/exports?

Sort of like a babel/minification-esque process. So the production code gets the upside of import/export but devs don’t have to spend time reinventing the wheel?

149

If C# tools can do that for literally years now (Resharper etc), I don’t see why Jetbrains won’t bake that in their javascript tools at some point.

I have a feeling Webstorm either has it already, or will have it very soon.

1 Like
150

I think my issue with your previous few comments were that if Meteor follows its current course of aligning itself with JS, and in a year, I don’t like where it is, that means that I don’t like where JS is and then I think we have a much larger problem on our hands.

I don’t think Meteors overarching goals have changed much. Maybe with the goal now of aligning with the regular JS community (that didn’t particularly exist or wasn’t prominent at Meteors inception). As long as Meteor makes the things that are too hard, easy, than I don’t see how the goals have changed. The things that you do may change, the syntax may change, the underlying technology change, but the overarching goals, in my mind, have remained pretty consistent (just as an fyi, I have used Meteor since 0.5.0).

And sorry to be that guy, but I would hope that they would jump to 2.0 if they were removing backwards-compatibility just to make sure everyone knows that its not backwards compatible.

I agree that some people would be angry if they had to rewrite out of the blue. I wish Meteor had a better way of deprecating things, with helpful upgrade paths, to help avoid these kinds of things. Similar to Ember maybe?

2 Likes
151

Or they just walk away and abandon packages and projects, and you never even hear from them again. The community of regular contributors has changed a lot since ~0.5 days.

That’s what we’re talking about with the lazy-load and autoimport packages. The prototype package is a compromise of sorts, which would get autoimport added but positioned in a way that strict imports could become the default for non-prototyping situations.

Right? Imagine if a team of MIT grads built a Javascript version of Resharper to autoinclude <script> tags and node.js files in a build pipeline. I bet they could get at least $30M of venture capital in multiple fund-raising rounds, and became the most popular full-stack Javascript framework on the web and beat Rails on GitHub.

Of course, the broader JS community would criticize it to no end because it’s successful and lowers the barrier-to-entry into the programming world. It would be death by a thousand cuts until the team was forced to toss out the baby with the bathwater.

I’m expecting the Tesla Model 3 to ship as a hybrid electric/gas vehicle, now. Or maybe just a gas powered car. Because, ya know, that’s where the rest of the automotive driving industry is at. Gasoline is a best-practice, after all.

11 Likes
152

oh no you di’int! :wink:

Edit: Oh geez, your comment made me sad :frowning: Do you think it’s too late for Meteor to bring back it’s mojo? I understand it’s about broader appeal but it doesn’t feel like Meteor anymore, yeah?

Like Rails has it’s mantra and doesn’t care what the rest are doing.

1420×698 83.1 KB

153

Well, that’s why we’ve been doing a custom distro. The deprecation of D3 from core in Meteor@0.9 was the ‘big wakeup’ for us with regard to the differences between MDG’s incentives and our own.

So, for those of us who were drawn to Meteor as a big-data analytics platform, it’s not felt like ‘Meteor’ since 0.9 days. And why we started a separate distro to get that data analytics mojo back.

As far as Clinical goes… the distro is probably in the best shape it’s ever been after the upgrade to Galaxy. The next release will almost certainly be based on Meteor 1.3.1. As far as the core build tool goes; we’re excited by the latest release from MDG.

1 Like
154

There are actually pretty major changes happening, imo. You have a seed/A stage company building something cool in the early days of 0.5-1.0… Now you have a B stage venture trying to build revenue and traction, one that realizes the development of Meteor itself is a cost center and it would be better to rely on plain of Node ecosystem to draw in more dollars to the hosting platform.

While I don’t disagree with the current direction, I also firmly understand that MDG is a business in the business of making money. You either grow your customer base or cut your costs. They are feverishly trying to do both atm.

4 Likes
155

Definitely not saying there are 0 changes to meteor or mdg. But I am also only strictly speaking about the framework, not MDG as a whole. They obviously have been creating new pieces for their business, i.e. galaxy and apollo.

Also, I agree that there are probably business reasons behind going toward the node ecosystem (which i agree with). I think its interesting that it is both in their interest to align themselves to gain the benefits of the entire node ecosystem and good (imo) for the meteor community.

Also, still enjoying the podcasts! Keep up the good work

3 Likes
156

Change is the way of life. If it was not than we would just be all dead anyways. The point I am trying to make is that changes will come and sometimes breaking changes will come. The only thing is that they remain easier to deal with and the old versions are supported. MDG has many paid customer and it will be in there own buisness requirement to support old versions so I think we are inflating the issues.

I also do not understand why is everybody so concerned about breaking changes. In any ecosystem after a point breaking changes do come and people have to make changes to their code if they want to remain with the current releases. If not you can stay with the old releases and be happy. For example Microsoft does not support installation of SQL Server 2005 beyond Windows 7 or Spring from new version will only support Java 8 and higher etc.

They never said they are getting rid of publish-subscribe as somebody suggested rather Apollo will be a new data layer that you can use with publications. They do need to support other DB’s and with current approach they are getting no where.

Also Meteor getting closer to NPM is great because we were not able to use a tons of packages that are way superior than there counterparts in Atmosphere.

3 Likes
157

I was just about to make the same “analogy”, you beat me to it :wink:

Well, isn’t that a progress, or what?

158

I too would have made a similar analogy. It’s almost trite in the business world to suggest “zagging” when everyone else is “zigging”, but it’s still sound advice.

I’m grateful for the integration that Meteor have achieved with 1.3. It’s made me more confident about building something that will be maintainable, long-term. Yes, it’s lost a little of it’s magic, but is there any other alternatives that offer the same ease-of-prototyping? You could argue that something like Elixir (or even Laravel?) can offer a similar developer experience, but I still don’t think they hit that “ease-of-use” high note that Meteor does.

The problem is that we are comparing 1.3 to older versions of Meteor.

Imagine if, up until now, there had been no Meteor at all; and we all were working with the MEAN stack, or whatever selection of NPM packages suited us. Then, MDG drop the current 1.3 build, with all of it’s suggested practices, out-of-the-box packages, and support for industry standard tools like React, Angular, NPM; plus GraphQL on the way…

We’d all loose our minds at how “easy” and “simple” it is. It’s not Meteor that’s causing these debates, only our frame of reference!

6 Likes
159

Elixir with its Phoenix is very far away from anything that could be called “ease-of-use”.

As for Laravel, that’s actually very good example. Just like Meteor for NodeJS, Laravel is the easier, frontend-people-friendly alternative to Symfony, which is a big, complex and powerful PHP framework. Just like Meteor stands on NodeJS, Laravel is build upon Symfony libraries under the hood, but offering more user friendly experience, achieved among others by the heavy use of globals in place of Symfony’s dependency injection system.

I had nothing against Symfony, I even knew Symfony better than Laravel and had more experience with it. But Laravel’s hype doesn’t come from nowhere, it had a solid ground. There was an argument used in this topic that majority of developers prefer dependency injection and other more verbose stuff. So what’s the reason for much bigger Laravel popularity in comparison to its parent?

160

Really? I’ve only just started with Elixir & Phoenix (last week or so…) and haven’t found it to be especially difficult or obtuse. Yes, it requires a different mindset, but I’m certainly no-less productive than I was than when I picked up Meteor.

I do… Rebuilding a Symfony app at the moment that’s a complete pile of…spaghetti. It’s my only real exposure to the framework, and it hasn’t made a good impression.

I often use the Statamic CMS for small, simple sites; and regular chat to it’s creator, Jack McDade. V2 of Statamic is built on Laravel and Vue.js.

Every time I speak with Jack and we talk work, I have a new problem/complaint/irritation about JS/Node (us devs just love to grumble!) but Jack talks about features and releases. PHP is (wrongly) considered a relic by many developers. However, Laravel, PHP7 and a bit of Vue.js is an incredibly productive stack. It has largely different use cases to something like Meteor/Elixir, but if you just want to build something, and get it done; you can.

I think the attractive thing about it is the docs, ecosystem of plugins and dev/prod environments (Homestead/Forge/Envoyer) and tutorials (Laracasts). It’s a very “complete” offering, making it easy to jump into.

Anyway, enough OT discussion…

1 Like
161

Ouch, I feel your pain. But that mess may be caused by the developer. I remember my first websites written with Symfony, it would be a real nightmare to maintain or rewrite by other devs.

But yeah, back to Meteor.

1 Like
163

QFT. 100% this. All this.

Indeed. The Tesla Model 3 hybrid would probably sell more cars to the general public who want sedans, pickup trucks, minivans, etc. I’d probably spend $40k of my own cash on the hybrid, not the all-electric.

Me too. I know my post came off as snarky and cynical; but that was directed more towards the general JS community than MDG. I just hope my comments help put the autoloading features in context a bit. Autoloading has been part of Meteor since it’s beginning, and has been a major differentiator and part of what makes Meteor better than MEAN, Derby, Sails, etc. In a good, great, fantastic sort of way.

7 Likes