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.
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
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.
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!
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?
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.
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.
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.
I personally don’ t believe that autoloading should be kept. It was one of those “wow” things back when meteor was first coming out. But we know it to be problematic with load order and then we have to have weird directory structures to make it the way we want. For me, once I got past the initial “wow” factor of autoloading and saw some of the issues associated with it, it really wasn’t a huge differentiator in the way that I saw meteor. In fact, I began seeing it as a downside.
Honestly, if the autoloading package gets created, it’s not a gigantic deal to me, I just won’t use it. However, if it is, I hope that there is a setting to turn it off for all meteor create's. I would rather not have to run meteor remove autoimport every time i create a new meteor app.
I’ve worked on fairly large projects in Meteor (nothing HUGE, but still reaching many hundreds of templates etc) and haven’t had any issues at all with autoloading. Considering this, I would guess the trade off would not be worth it for at least 80% of the projects out there.
And let’s be realistic here, which is the lesser of 2 evils - having type a single “remove” line, or having to go through hundreds-thousands of files adding import statements in order to upgrade a project if the backwards compatibility is removed?
If your project was pretty large and ran 100% fine with autoloading - no issues whatsoever, would you really want to update it to a version w/o backwards compatibility if there was no gain? Or a better example, if you worked for a business that had a large application that ran fine, would you want to invest the money for the developers to update it to 1.4 if backwards compatibility was removed? I would be willing to guess many people would skip on the update as long as possible in order to not waste money on upgrades that will not improve anything for them.
One final note - you mentioned “we have to make weird directory structures to make it the way we want”… When I look at the new recommended directory structure, I honestly think your statement fits this new structure more than the old directory structure…
I totally understand that upgrading projects wouldn’t be super easy with this. It would take plenty of time to upgrade old projects.
I think it boils down to how much people rely on Meteor to show them the “best way.” Again, personally it doesn’t affect me a whole lot since I can just remove it, and would.
And regarding the directory structure, no, personally I don’t like having an imports directory. However, I have been trying out webpack:webpack recently which alleviates some of those issues. However, the imports directory is most-likely an artifact of autoloading. If autoloading was removed, than we wouldn’t have to worry about eager loading, and therefore could avoid the imports directory.
Thing is, the “best way” is project dependent. I just hope the “best way” could be decided by the developer in charge of the project, rather than forced in to a specific path by MDG. For my project, and with my businesses resources, I don’t believe manual import is the best way for this project, nor is it in this businesses best interests.
I mean, hasn’t it been one of Meteor’s mantras that they will not enforce specific constraints on our projects anyway?
I see it this way: where NodeJS is a Linux, Meteor is an Apple. Linux gives its users much more choices, lets them to tweak everything there is to possibly tweak. Apple keeps things stupid simple with its own worked out way to do things.
Now, the key for Meteor is to progress, but without becoming Ubuntu.
I’m glad someone brought Apple in (and it wasn’t me
It all looks now like pissing my pants over Apple keynote announcing shiny new OS X with all the bells and whistles but delivering Elementary OS instead. Because, ya know, “it’s standard”
Again - it’s 21. century and I want to connect my external drive, enable Time Machine and move on to the next great feature my client wants (and PAYS for); NOT mounting drives, creating filesystems, writing backup scripts and dread over whether next rsync patch will blow the whole setup and leave me backupless…
And all this because of import I think meteor offers more than just global variables. Other than that i see that 1.3 has much more important announcements like full NPM support which was a big problem as we were dependent on atmosphere npm wrappers and there quirks.
I think there needs to be a specific subset of MDG that advocates for the novice and to keep the platform newbee friendly. I’m talking friendly for someone coming from VUE, Rails, Laravel, jQuery. If Meteor tries to do everything other javascript frameworks do then it gets lost in the sea of indecision. Meteor would always have a clear and easy market advantage if it stayed relevant for small beginner projects. I can spin up simple apps using meteor without a second though. A lot of this is because it’s so opinionated on the full stack. If I lose that ability I’m going to start looking into other frameworks.
