Writings on the wall…
That could also be framed as…
“If every other framework is moving in a different direction from Meteor, and the wider community is becoming less compatible with Meteor projects… Isn’t that a problem?”
5 Likes
Meteor doesn’t have to sacrifice the principals it was built upon for compatibility. That requires a conscious choice. One I hope is not made.
Besides, Meteor started off in different direction from the other frameworks since the beginning. It was different from the rest, which made it stand out from the pack… What would have been the point if it changes directions and ends up in the same place that those other frameworks were since the beginning?
I thought Meteor was about taking web development & making it “enjoyable, easy, and a pleasure to work with - the Meteor way”. That meant achieving all the important aspects of development - such as functionality and compatibility - while also taking away all those unnecessary complexities and annoyances.
Meteor was supposed to be the solution for what you state - It’s supposed to handle compatibility WHILE being enjoyable and convenient to use. If that is sacrificed, is it even Meteor anymore…?
11 Likes
angular-meteor had a great example of this with their party app that used ng-1 vs ng-2
I hope this will be one of the bases of “MDG’s plans and priorities” in the short term.
Instead of wasting my time going through hundreds of files just to add
import { Template } from 'meteor/templating';
import './corresponding-page.html';
I think I will wait for whatever auto-import feature comes out in the (very?) near future.
3 Likes
you don’t need to wait for an auto-import, everything is still 100% backwards-compatible and es2015 modules are an optional addition. if you don’t want to use imports, your code using globals should still work just fine
1 Like
Yes, I already know about backwards-compatibility as it has been mentioned numerous times. I mean I won’t start using the imports directory structure until things are made easier e.g. with auto-import functionality.
1 Like
Being different doesn’t inherently mean being wrong. It may also mean that (finally!) someone (MDG?) got it right.
1 Like
In whichever shape or form - it’s 2016. and I expect things to “just work”.
1 Like
Actually - that’s one of the principles to live your life by. Couldn’t have said better.
5 Likes
Actually I am with sashko on this. Without explicit imports a large app becomes a mess. You do not know what is being loaded before what and all the hell about using directory structure nesting. All those globals are good for prototyping but for a production app it is not a good idea. Also if Meteor goes in a different direction than rest of JavaScript world people will complain and run away as we have seen in the react threads. MDG is walking a tight rope and I think they are doing a good job till now.
1 Like
It’s not an issue with package based architecture which has been a best practice for medium and large apps before 1.3 and plenty of apps are written this way.
Also, how many Meteor (or even Node at all) apps are actually large apps with thousands of templates? I’d guess there are much more of smaller ones.
Some people will complain and run away to whatever is currently trendy anyways (like Phoenix).
5 Likes
People will run away if Meteor delivers the same like other free frameworks. I’ve chosen Meteor, because it has decreased my development time and I got “out of the box” reactive features, something every modern web application needs. If I compare it to my previous PHP projects, I love to develop with Meteor. If there is a time I feel uncomfortable with it, f.e. because my development time significallity increases, I’ll switch to another framework, and there will be some others in the future, especially if Meteor doesn’t deliver any special features.
There are already some things that MDG doesn’t deliver and I really can’t understand why, f.e. an OWN router or a scaling package that allow multiple core. Both available packages are community driven and the first one isn’t working 100%…and there are more examples of deprecated community packages that deliver important features that a “fullstack framework” should support.
4 Likes
I agree Package based architecture was your best hope before 1.3 and a reasonaly large app can be build with package based architecture. That can be done today with 1.3 as well so i don’t know why are people complaining. The old way is still there and people can use globals and stuff as they wish.
I do agree that there should be some package like prototyping which can add an auto import option which will make things easy to try and prototype.
1 Like
Because the guide suggests it may be deprecated in next version.
But main complaint is that for complete newbies, the available learning materials start the whole teaching of Meteor from how to import stuff. Not how to write a template or a helper, not how to use reactive var, not how to write a publication or a method. How to import stuff.
2 Likes
The important point for a newbie to understand in Meteor is not import statements rather using reactivity, writing a publication or a method or a react component or a template helper or how to use packages etc. These are important things that I agree should be highlighted more rather than import statements. They are just a standard javascript practice which should not get in the way of learning Meteor.
Import statements, npm modules add value to Meteor but they do not define Meteor that is what needs to be highlighted by MDG not the opposite.
2 Likes
I added back in info on Meteor default load order and a bit on how you can still use Meteor “pseudo globals” to the Meteor Guide. I agree that we don’t want to lose this information, but for most apps doing explicit import/export is probably the way to go.
3 Likes
I have to say that I sit on the other side of this. I found it quite annoying that meteor functioned differently than regular js. I loved some of the stuff you “get for free” like data transfer over ddp and user accounts and stuff, but hated that it hadn’t gotten closer to the regular js community in places like import/export and stuff.
I really enjoy using import/export even if it may seem tedious. I would rather open up a file and know that it relies on these 3 things rather than having to read the whole file to find out which things it uses.
Back when script tags were the way to include js in an app, I think Meteors way was superior (even with weird practices to get around file load order). But now that import/export exist, I think Meteor should go with that.
7 Likes
Yeah I agree it’s great that Meteor allows devs to do stuff like that now. Even if I prefer globals, I’m happy that Meteor provides the option to go the JS community way.
The “ease of use” factor and meteor being different were the main selling points for me and some of my colleagues.
I still remember when one of my colleagues told me about a smaller project he just couldn’t find the time to do. So I just fired up meteor, added some packages, got the whole thing done in a day and put it online in the blink of an eye.
In return I got a nice “What. The. F***!? I thought you were a Frontend Dev only? How did you do all that?” from the whole company and meteor spread like wildfire for a while 
I had only Frontend experience. Always wanted to be able to do the backend stuff but found it a terrible experience. Annoying to say the least. But after the first little meteor tutorial all the backend stuff just “clicked” for me.
I sat there in awe and thought “Wow, now THAT’S how I want to work”!
Client and Server folder? Damn, makes sense to me.
Publications and Subscriptions? Wow, that’s clever!
One command deploy? OMG, take all my money!
I feel like these things are getting more complicated now. To a point where (if I think of me as the total beginner I was) I’m not sure I would have adopted meteor with this much enthusiasm. (still probably would have though)
The one command deploy:
Okay, that’s already gone. Yes, it was never ment for production and I guess the reason behind it being removed is fair.
Now we have galaxy with is an awesome product. But I kinda expected something like scalingo from it: One command. Complete setup. Database included. Done.
I know MDGs reasons behind the no-database-decision, but the beginner in me still can’t understand why I have to host my database somewhere else and need a 1500 word tutorial to learn connect the two. Can’t a remote database be optional?
(The same is actually true for meteor not having a router. How many apps can live without one? Okay, some maybe. But would including one be so much overhead? Can’t meteor just figure out if the router part is used in an app, and if not remove all its parts on build?)
The Publications and Subscriptions:
I can’t really compare this to anything, but it seems like a cool system to me. Good naming. Easy to grasp. Now as far as I understand this will probably change with Apollo, right?
The Client and Server Folders:
Now as far as I can tell this will stay, right?
On the other side I have also been bitten by the load order problem. I also find it nice to see a files dependencies at the top by looking at its imports. So while it will probably feel tedious for a while I can see myself enjoying this approach. (It’s also cool that it’s optional)
Man, it is a fine line indeed.
I just wanted to point out that there are two complaints you will never hear from your customers:
- “Aw man, I wish I would have to pay more for this product!”
- “God, I wish this product would be more complicated and harder to use!”
So from a beginners perspective the whole “ease of use” theme in Meteor was spot on and should be moved forward. 
Edit:
Just felt like adding this - I LOVE what MDG has created here. Meteor just opened so many doors for me, it’s crazy. And this community, man! Just so many amazing people in one place. Blows my mind. So happy to be here! 
7 Likes