You don’t need, but a lot of people use React, its cool, solid, performant, has tons of great packages, etc. Why would you want to learn Blaze instead of React?
Yes, you don’t, but why do you want to miss new awesome features and learn/use es5?
Yes, you don’t, but you can use npm now! You can’t use npm packages without import. I also think, Meteor will move core packages to npm some time.
You see, you have a choice, but for a newcomer - why learn old stuff and rewrite/relearn after some time. For an experienced one - I guess, you already know es6 and understand imports, React is also a solid standart nowadays in js.
To reiterate on a fact stated many times in different topics:
Not all of us are aspiring professional developers striving to be up to date with all the mainstream and cutting-edge technologies to be able to land next better (paid) job.
Some just want to build (as quickly as possible) cool apps, or just demos for potential clients, by focusing on processes, features and functionalities rather than tech underneath.
I’m pro all the changes because I’m an experienced developer and I understand exactly what an improvement this all is.
Having said that, the thing that bought me to Meteor originally, was how quick & simple it was to make cool apps. I’d often do something fun/small in just a weekend, because it was fun and easy. I’m definitely not as eager to do that as I was before. However, I do know that my apps are a lot more maintainable now, and I love being more a part of the bigger JavaScript ecosystem.
So while I miss the old simplicity, I think the trade-off was the right one and we’re on the right path.
P.S. That wasn’t always my opinion… there were a few months of grumbling involved first
As far as lazy vs. eager loading, maybe this could be implemented as a package? Kind of like autopublish and insecure. Then if you just wanted to build something quick or just preferred the “Meteor Magic”, you could have it, but if you want to build something serious and maintainable you just meteor remove lazy-loading .
I don’t know what it would take to implement, or if it’s even possible, but I think that this would be in line with the way Meteor has implemented other such things.
I was wondering, could the Meteor build process add these import statements automatically if required so that the developer doesn’t have to think about them?
I would kind of expect that in Meteor, at least for the Meteor API itself. Outside packages I can understand not doing that. But having to do imports for Meteor API and to every .js/template file does not feel like Meteors’ style.
I may be biased, but as far as I’m concerned 1.3 is an amazing step forward. It gives us ES6, modules and npm integration all with full backwards compatibility.
Given that, I’m very curious to know why people have the impression that Meteor is becoming harder to use. Is it because many examples and tutorials out there use the newer features of Meteor?
Don’t get me wrong, the new functionality is great. My concern is just that it’s at the cost of Meteor’s intended functionality (at least what Meteor was claimed to be about from the beginning).
For a developer who already knows Meteor, it’s not that it’s “harder” to use, but it’s definitely less convenient. I have been working in Meteor for over a year now and have not ran in to a situation where I’ve had an unsustainable project, or would even really need to bother using imports.
For now… it’s okay. As you said they are optional and it’s backwards compatible. But as Brajt has mentioned in his post, they stated a future release they expect it to become required.
In my opinion, that takes away one of the core things that made Meteor “Meteor”. If it were to stay optional forever, then I would not be complaining at all. But after spending so long learning the “Meteor Way” and choosing it as my main platform specifically for that reason, if they take that away… it’s very discouraging.
For new users, it’s much more complicated even from the very first tutorial. When I first did the tutorial, a few things stood out. Some of those were:
Meteor was much less verbose.
Meteor didn’t need import statements.
Meteor was very easy to understand.
Meteor’s projects were organized in a very easy to understand way.
Now if you look at the new tutorial, it’s not less verbose anymore. It needs import statements (and actually requires MORE import statements than some of the other frameworks/languages I worked with - which is an issue for me as Meteor has ALWAYS stood out as convenient to use in all areas), the tutorial is much harder to understand and organized in a completely different manner.
As I mentioned, I have new employees coming to work here, beginning next week. The plan was for him to use the Meteor tutorial and I would train from there in our projects setup. But the new tutorial? It’s insufficient. It’s more complex, and it’s using a completely different structure based around the “import” folder, rather than the commonly accepted structure that was used in the past. Giving the new employee this tutorial would cause more confusion than otherwise.
Also, another issue I had, was they didn’t even mention how imports were optional. I would not have known that if I had not checked the forum here. And apparently it’s not going to stay that way. That’s the problem.
Yes, you don’t, but why do you want to miss new awesome features and learn/use es5?
Because that increases development time, and if my project doesn’t really need it, I would value dev time.
I think all the new features are great, the only part I’m against, is > forcing imports to be used in the future. If it were just a new “feature we could use” that would be awesome. But if we are required to make our code much more verbose even for projects that don’t need it… that’s not really a new feature, it’s changing what Meteor is.
I would personally rather to not have to bother increasing my own dev time if it wasn’t necessary, and every time I have to train a new employee it would save time training them. As well as we could be easier on the job listing requirements - We had a job listing up for 6 months until around January-Feb… and in just those couple months, our job requirements are already outdated. If I knew what I knew now, I would have upped the requirements. That signifies a problem.
Having imports remain optional sounds great to developers using Meteor, but don’t forget to consider what this means to MDG and community contributors (developers building Meteor). With the push to move Meteor components to npm (see Move Tracker and all other dependencies into separate repositories and NPM · Issue #13 · meteor/blaze · GitHub for example) and become a friend to the rest of the npm ecosystem, leveraging globals with optional imports/requires will become much harder to maintain.
Being that MDG will be writing the packages for npm I have faith that they can work out how to import what needs to be imported from them. Maybe import all default exports? Other npm packages will not change as they already require manual importing. The rest of the meteor packages that have meteor specif functionality maybe stay as meteor packages. I’m sure there may be trials and tribulation to accomplish this but I think it could be done. Will it be done is another question.
Yes, I agree it can be done technically, but will the time required to make sure we can use both approaches be worth it in the long run, if we’re the only ones thinking that way? ES2015 modules are taking the JS world by storm (which of course makes sense). Maybe the time required will be worth it; preserving the instant gratification wow factor that hooked so many of us might be one of the best things MDG can do …
The other question is - this does indeed lower the number of lines of code in a project, but is that even a good thing? Something to think about.
I would personally be extremely against a Meteor-specific system to automatically import from NPM. If such a system becomes standard or even popular in the wider JS/NPM ecosystem, then sure we should make it easy to adopt in Meteor. But right now it is absolutely, unquestionably, not the best practice for JavaScript to automatically load modules via global variables.
But is it backwards compatible with how Meteor used to be written? And best-practice for whom?
Global variables are bad, sure. But are they worse than autopublish? Worse than an insecure package?
Put another way, right now, it’s absolutely, unquestionably, not the best practice for JavaScript to automatically publish all data to clients and provide insecure installations. But Meteor provides such packages because for prototyping, those are best practices. And autoimport falls into the exact same category of packages.
That’s a fair point, and we hear all the time about people using those packages, along with other Meteor “niceties” like profile in production, getting hurt by that, and then feeling like Meteor is not secure.
One of the things I really like about the new Apollo stuff is that this problem falls away entirely, because there is no concept of subscriptions at all so you just get data when you query it.
I think they should, along with some other things, like the aforementioned profile field.
How about a prototyping package that contains something like this:
insecure
autopublish
public-profile
autoimport
And then have the prototyping package be responsible for adding some logging instructions at each app startup saying ‘hey, you’re running in prototyping mode; check out this link for instructions on how to remove these packages and harden your app’.
That way, people can still have the prototyping features they love (including lazy-loading); but there would be a bit more proactive communication of where the not-best-practices are (which should ultimately lead to less people getting stung and less headaches for MDG).
I think that’s a spectacular idea! Something to think about for Meteor 1.4, or 1.3.1, or something. Mind filing an issue and I’ll comment on it? I feel like this will get lost on the forum.
This would force me to use autopublish and insecure when I just want to use autoimport. Autoimport may not be the best practice, but it is not a security risk. Plenty of Meteor apps were and still are running with autoimport and they’re fine as is.
Having said that, the thing that bought me to Meteor originally, was how quick & simple it was to make cool apps. I’d often do something fun/small in just a weekend, because it was fun and easy.
Exactly. And therein lies the core challenge in making Meteor scalable, robust, and enterprise-ready without making it feel complicated and annoying.
I think @sashko is on the bleeding edge of this tradeoff when he’s writing the tutorials. Who is the target? An experienced js/react/angular/mongo/node developer who is up-to-date with ES2015 or a rank beginner who wants to get into programming and has heard that Meteor is awesome, easy to learn, and fun? Or even an experienced Meteor developer who now has to learn how to think in Meteor 1.3?
In reality you need to support all of those personae but I’m not sure it’s possible in the same tutorials. Page 1 of the to-do app tutorial now has half a page of info on ES2015. Page 2 takes you straight into imports and the new, much more complicated directory structure. In the old tutorial everything was at root and you didn’t even need to consider directory structures until later, after experiencing the joy of quickly building a cool, reactive app. The flat structure might have been concerning for experienced developers but it was reassuringly simple for newbies.
In later pages of the new tutorial, the import/export overhead can be 50% of the code. That’s not simple or fun; it’s tedious (but yes, critically important but really, this is looking more and more like C++).
It could be done, but from the quote that Brajt linked in here, it doesnt seem they plan to.
[quote]The other question is - this does indeed lower the number of lines of code in a project, but is that even a good thing? Something to think about.
I would personally be extremely against a Meteor-specific system to automatically import from NPM. If such a system becomes standard or even popular in the wider JS/NPM ecosystem, then sure we should make it easy to adopt in Meteor. But right now it is absolutely, unquestionably, not the best practice for JavaScript to automatically load modules via global variables.[/quote]
As with all things programming, it depends on the project. For my situation, lowering the number of lines increases dev speed, and dev speed is a top priority.
I do not think automatic importing from NPM is a good idea at all. I don’t expect that, either. Manual import NPM is just fine.
All I would hope is that Meteor’s own packages don’t always need to be imported, and I do not really like the idea of having to import every single Meteor template/.js file. Just for my active project now I would have to sift through adding imports to hundreds of files, for effectively no gain, as this functionality isn’t required by my project.
I think an “autoimport” package is quite different from autopub and insecure. Having autoimport isn’t nearly as bad for most applications.
A live application, in many cases, will perform just fine with autoimporting. A live application with autopub or insecure simply is not reasonable at all.
I like the idea! But it would be great if they are separate modular packages as @awatson1978 has said
Agree completely!
But your first paragraph - that’s the point of concern for me. Meteor from the beginning stated it was intended to be easy, convenient, and enjoyable to use. I’m just worried that’s getting lost.
I don’t even view the new “tutorials” as a tutorial. Especially a tutorial that is specifically recommended for first-time users of Meteor.
@michelfloyd explained the issues with the new tutorial very well.
Even as a Meteor user for over 1 year, since I have been getting errors and have not been able to get 1.3 working, to be honest, I don’t even understand the reasons behind the new directory structure. It has completely changed. And because of this, if I linked this information to the new employees starting to work here, they would completely lost when they look at our existing project.
I’m kind of surprised the problems caused by this situation take so much explaining. It seems obvious to me, as when I look at the tutorial, and then think back to when I first tried Meteor’s tutorial and then I look at the new tutorial… the reasons Meteor stood out as being so awesome aren’t there anymore. It’s very hard for me to look at it and say “Why should I go with Meteor over the other options out there?”. The biggest seller was how it was a pure pleasure to work with. The front page of Meteor still lists “Delight” as one of the 3 main reasons of “Why Meteor?”, and still says in big letters “From idea to execution, faster”. But it seems Meteor is moving further from these principals it was built upon.
If Meteor is becoming more and more like every other framework out there, and the things that made Meteor stand out are disappearing… Isn’t that a problem?
Improved functionality is important for growth. But so is holding on to the core principals that got Meteor here in the first place. Forgetting core principals will alienate many of the original user base, and those core principals were what contributed to Meteor’s growth in the first place.
Again, I really have to stress… If my first impression was the one I would get looking in to the Meteor website today, I would have passed over it. What really separates it from the competition without holding on tightly to those core principals?
