Well, the issue here is simply comparing it to Meteor itself (and it’s own advertising/explanation of the intent/direction of the software).
If the ideal developer to hire has changed from the time we had the job listing up to now, it’s hard to say the intent/direction of Meteor has not changed, no? And that’s what tim & myself expressed a little bit of concern about.
It seems that @Spyridon and i share the same concerns regarding some of the changes Meteor has gone through the last few releases.
It seems that the standard for doing Meteor is increased to a point where i need to think about hiring people with expierence with node.js and python. Where it used to be anyone who could do html,css,js was able to step into meteor and explore the wonders Meteor “magic” gave to them with things like easy to use and find packages and all the other good stuff Meteor offers.
With ES2015 its clear javascript went through some big changes, and that is good for everybody. However people might get overwhelmed by the new const,import and other new features that come with it in the http://github.com/meteor/todos example app.
Also the project file structure really suffered from these changes, where it used to be a simple client,server,lib setup would suffice, versus now the server folder contains one file with an import and the imports folder contains everything.
I’m not sure if this is just an example and not an obligation but its really become messy if you ask me.
And not only the file structure but also the code with having to do all those import correctly with a …/…/…/filename like i hated so much before Meteor came around.
I find it pleasing to know that currently no paths need to be defined when working with meteor, and i hope that will not change in the long run. even when i decide to use NPM packages with for example meteor install npm --save faker.
The thing is i think that business wise it is good to have stuff like hot code push, the meteor build tools and others maintained by a company or group that was properly financed so that i dont have to be dependent on other opensource options that are maintained by all kinds of different parties.
When all necessary tools required and used are maintained by the same entity, ensures that as long MDG is around i can maintain my applications and once it does not i can migrate without 3 months of work.
But thats just my opinion 
For now ive migrated one app to 1.3 to see if it still works and it does it fantastically!
Great job you guys at MDG, @sashko & all the others.
Changes to the app are compiled almost instantly now and its very nice to work with.
So, at the risk of getting badly flamed, I’m going to come down on completely the opposite side of this argument.
For context, I’m an enterprise/line-of-business developer and also one of the people who makes tech choices for our company. When I first looked at Meteor I thought “this is too simple” and “this todo example is so simple and missing so many important things (true CRUD, testing etc) that I suspect the framework can’t actually be used for big apps, or if it can this code isn’t really representative”. Based on that I moved on and spent a (wasted) month learning Angular and we as a company very nearly didn’t adopt Meteor.
I’ve been programming for a long time and its given me a sense of the places that I think are well suited to automation and code reduction (either by pattens or language specific constructs) and those that aren’t. Things like binding and wrapping and unwrapping data for transmission across a network fit into well into that (which Meteor does for us behind the scenes), as do the use of boilerplate reducing helper classes/methods such as createContainer and validatedMethod.
It’s also given me a sense of things that I’m confident should never happen such as the use of global variables and things that I look for as absolute requirements from the outset such as a solid testing story and patterns and practices that will help me write code that is maintainable for the 5-10 year lifespan our client’s systems tend to be around for.
My guess is that MDG did their market research and found that I wasn’t the only one put off by the previous example code and so decided to shift things up a gear in terms of the completeness of the example in order to target those looking for a ‘full’ solution, especially those in the enterprise arena.
But as @sashko has said, one can still take the simpler approach. It’s maybe a shame that that’s not obvious as the new fuller examples could well be intimidating. I think the ultimate solution might be to have three tutorial worked examples; Simple Todo as was (simple as possible), Full Todo and the new forms based example that’s under discussion.
I think the ultimate solution might be to have three tutorial worked examples; Simple Todo as was (simple as possible), Full Todo and the new forms based example that’s under discussion.
I could not agree more. I used to encourage jquery aware designers to become developers with Meteor where the tutorial made ot very easy to see that it could actually be finally done. Now it is like “oh I am not an engineer I don’t understand these”
Perhaps app structure couldhave at least be one of the steps of the tutorial where everythingr started off with globals and at some point a structuring chapter says hey let’s use this new javascript feature called imports and tame our load order etc…
I think it’s sort of a trap to be comparing LOC’s in these typical todo-list tutorials. I believe there is an inverse relation between the LOC’s in these simple apps and the effort you save in the long run when working on more complex apps.
I’m not saying we should go Java-all-the-way (please don’t), but a little bit can surely help.
Even for a first-time developer, I don’t think the concept of imports is hard to grasp. I mean, it shouldn’t take more than 1 minute to explain to a pure front-end developer how imports work. By the way, the whole JS ecosystem seems to move into this direction. So in the future every developer will already be familiar with this.
Therefore I believe total training time of new employees will eventually be reduced, since you need to learn them less about the meteor-specific magic and instead rely on what they already know.
So in the future every developer will already be familiar with this.
HTML+CSS+jQuery “developers” will never ever be faimilar with this and will not want to be familiar with it if it is the first piece of code they see on line #1 of file #1.
They might however be “lured” into embracing these language standards and features and become actual developers in time.
Agreed. I’ve long been advocating for documenting refactor paths as part of the testing story. It would be great to have two example apps… Simple written in Blaze w/o imports, and Full written in React with imports… and a tutorial showing the refactor paths from Simple to Full.
Those refactor paths would amount to being upgraders… the scripts that wind up in .meteor/finished-upgraders. So there’s precedent, as were already doing this. Put another way, maybe the Guide should have a section on writing and registering upgraders.
Once the refactor paths are documented, there would be a complete story from prototype to optimized maintainable app.
@tomRedox I completely agree for multiple tutorials. That’s one of the main points of my last few posts - especially considering the import’s are not required when not using NPM.
Also regarding Tom’s post, I can completely understand the perspective of enterprise dev’s. I actually think it’s great that Meteor is catering to enterprise developers - that’s necessary for the success of Meteor as a whole.
My only concern is that, as Tim said, I hope MDG does not forget the original intent of Meteor. According to Meteor’s own site, it’s supposed to be easy to pick up and a pleasure to use. I hope it actually stays that way, and that the features that make it enjoyable to code in are not removed in favor of enterprise features. More options are great - that means Meteor is having more depth added to it But being forced to add complexity to code if you don’t require those options - that’s adding complexity to those users code for no significant payback.
As mentioned, many of my issues were alleviated upon finding out the import statements are optional unless you are using NPM. This actually makes sense. But if I did not post here on the forums, I would never have known that imports worked this way. It’s not really communicated well, and with the most basic tutorial on Meteor using them everywhere, it’s a bit jarring.
@seba It’s not that import statements are “hard” to understand. It’s just that one of the nicest things about working with Meteor compared to other frameworks/platforms was that you didn’t have to have import statements all over the place. As I said, it makes sense for NPM, but for Meteor’s built in functionality, it does not feel right. It just up’s the learning curve for new users, and even for experienced users, adds a layer of complexity that wasn’t there before.
Also, according to the tutorial, you don’t just need to import the Meteor API’s & packages, but also should import every single template and .js file you make?? That’s actually a layer of complexity that goes beyond some of the other frameworks I’ve used in the past. That’s a big point of concern for me, because that’s the first time Meteor is notably more complex than some of the other frameworks I’ve worked with. As I mentioned, I found out this is optional so it’s less of an issue. But I’m worried that it won’t be optional forever…
Now if your project is enterprise level, or having issues where your project is not maintainable, then adding those layers in order to resolve the issues is great. And would make sense for that stage of a project. But for users that don’t require that, there’s no reason they should have to lose out on one of things many people enjoyed about Meteor. Even today, the front page of Meteor lists as 1 of it’s 3 main catches that it’s a “delight” to use. But if every project of mine had to look like the new todo’s tutorial… it would be much less of a delight to use than it was before upgrading.
To put it plainly, being required to import Meteor’s own API, and having to import every single js/template file you make, simply does not feel like the “Meteor Way” of doing things. NPM - that completely makes sense. Not for Meteor itself though!
And if importing Meteor API/js/templates is an optional feature, that should be communicated clearly, because many projects won’t need those features, and the productivity gain from not doing imports is worth it if you don’t need those features. If sustainability becomes an issue for your project, and updating your project with imports at that point would make sense. But really, for a new user going through the tutorial for the first time, or any non-enterprise user, there’s absolutely no reason they should have to bother with any of that.
A lot of my other worries would be alleviated if Meteor went with Tom’s idea, In my opinion, it makes no sense that the “Creating my First App” tutorial, that claims it’s only going to make a “simple” app, and is loaded with content focused on production app’s.
But yeah… in the end, it’s not really about Meteor being compared to other platforms, it’s about Meteor compared to itself prior to 1.3. Rather than it feeling like Meteor + some awesome new functionality, if imports become required it will feel a bit more like Meteor isn’t even the same product. The ideal developer for job listings, the ease of use, and the enjoyable feeling of working with it, and even the productivity seems like it could potentially be changing directions. That’s a cause of concern for me, as I was a big fan of what Meteor stood for. I really hope that Meteor doesn’t go further and further in that direction in the future… I really want Meteor to stay as enjoyable to use as it has been for me over the last year, and if anything, potentially become even more enjoyable to use.
For now, looking at the official tutorial, it really gives an impression as if Meteor became much more complex and difficult for newcomers in just a few days. That’s very unfortunate.
That is exactly my concern as well , then i will be obligated to migrate 2 really big apps to 1.3+ to keep it all safe and sound.
I understand from a technical perspective that it needs to be in the new Meteor since its the new standard directed by ES2015. But for the future i hope it will not be obligated to use imports.
Yeah… it might just be poor communication, but since the tutorial for new users has them, that seems to imply that things might not be optional forever. I mean, why even update the new user tutorial with imports if there wasn’t a bigger reason that everyone needs to start using them now…?
This situation contributes to the same type of worry that the React conversations had. Things have finally began to settle with React, and I’ve continued to use Blaze as that’s what fits my project & business best. But I still have a little bit of lingering worry that I will be forced to upgrade my entire project in the future…
And now there’s new worries that I may have to go through hundreds (if not thousands by the time it happens) of files to update them w/ imports…
As of right now since it’s optional, I can’t complain too much about the current state. Just worried for the future…
Also, just bad timing on the tutorial front, since the old tutorial I was going to use beginning next week to help teach new employees. The new tutorial I don’t think will help much, it teaches many things that are not used in the project, and the overall structure of the project is different from the old lib/client/server structure. I have to look elsewhere.
BTW you can still see the old tutorials by cloning this repo: https://github.com/meteor/tutorial-viewer
Of course, Meteor is starting to be more complex. When I came to Meteor a year and a half ago, it was like magic - you write a few lines of code with clear separation client/server and boom - it works! You can even deploy and test the project with just one command!
I was blown away, how simple and fast it was, I even told all my dev friends how cool it was and suggested to try it. Some of them told that I got into a sect. At that time, I didn’t know raw JS well, but the magic of Meteor, ecosystem and community was awesome - I loved it and I switched to using it.
Some time ago, I saw the storm coming (we all remember a lot of articles and forum topics), React thing and had to stop using Meteor and moved to js + npm world, still reading the forum, podcasts and other resources.
As I can see now, Meteor today feels familiar to the people from JS world - npm, es6, imports, React, etc. Yes, it is a powerful combo with a lot of packages, choices and possibilities, but it all has a cost - now writing an app is more complex and takes more time.
So, I fully understand, what newcomers can feel and what experienced Meteor devs can see today. It’s a bit sad to remember the time when we had blaze, atmosphere, easy deploy and when we could write only a few lines of code to see the magic.
I guess, it’s an unavoidable part of evolution that comes with power, possibilities and choices. You’ll get used to it, but you’ll feel less magic. Welcome to the outside js world, guys, now you are part of it.
I know other people have said this before, but all the magic that people say they’re missing in 1.3 still works!
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?
I had a similar thought, but maybe just two versions to start with. The “production-ready” ToDos example app needs its own tutorial, maybe called “Advanced Tutorial”. So the simple one teaches the basics, whereas the advanced tutorial teaches how to make an app production-ready.
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?
import { Meteor } from 'meteor/meteor'; feels like something Meteor should already know to do instead of us needing to tell it.
That impression comes from answering newbies’ questions and talking with them. They look at the tutorial and then try to repeat the same thing in their own apps “because that’s the official way so if I try to make it different, it will break”. And plenty of them had problems even in the 1.2 world.
There’s a lot of new Meteor developers (especially those coming from PHP background for whom the only contact with JS was usually through JQuery) who have problems to get right even such a basic thing as a publication/subscription and plenty more who have problems to understand how Reactive Variables or global helpers work.
Now you put them in situation where they get import issues even before they write their first publication.
Let’s stay with publications. MDG decided not to teach people about publications and subscriptions until step 10 of tutorial. Until then, we’re using autopublish, even if proper publications are crucial for security of our application.
Imports are not crucial in any way - people were writing production applications without them for years already. But they’re forced into new developers since step 2 without giving the easier option first.
Now, surprise:
Try to find that in the tutorial. You know that, I know that, new Meteor developers have no idea. They take a guess that if it was possible, it would be included in the tutorial, just like insecure and autopublish was.
Also from the guide:
We expect a future release of Meteor will turn on modules by default for
all code, because this is more aligned with how developers in the wider
JavaScript community write their code.
So imports may become obligatory in 1.4.
I don’t think Meteor is becoming harder to use. (In some ways, it’s becoming easier to use, because you’re less likely to have to do a major rewrite 6 weeks in because you overlooked a fundamental architectural decision!) Sure, it’s becoming more feature-rich, but MDG is still very focused, much more so than competing platforms, on making sure it’s really easy to comprehend from both an idiomatic and conceptual standpoint. For instance by introducing modules in 1.3 and having them automatically be supported but simultaneously backwards compatible with apps that don’t use them, and by having an explicit imports folder that you can choose to use or not, they are gradually moving forward alongside the broader ecosystem but imposing none of that on people who don’t feel comfortable with it yet. (There’s something to be said for having a guide or tutorial that works for people who aren’t up to speed with new stuff, but @sashko linked to the old tutorials, so maybe someone can try updating those for 1.3?)
ECMAscript is becoming more mature, and introducing even more idiosyncracies (ironically enough – you’d think that as the language was updated, they’d iron those out), and as Meteor is following the path of ES, it’s affecting some parts of Meteor. Javascript gonna Javascript, apparently.
For instance, context binding has always been a tricky thing to learn in Javascript. You’d have closures, things like var self = this and needing to juggle references in your head.
So now there’s arrow syntax that supposedly makes that easier by automatically binding context for you, removing the need for many people to know how to use things like Function.apply and Function.bind. But there’s a catch: arrow functions intuitively suggest a lambda-like shorthand for writing a function. However, ES2015 explicitly makes them different from regular functions by automatically binding this when you use them.
So now you have function and =>, which if you look at documentation from other languages often are the same thing written two ways, but in ES2015 are actually two different instructions.
I’ve seen so many people trip up with this, both newcomers and experienced developers alike!
I think this is where a lot of the perceived added complexity is coming from. (Don’t even get me started on the new weirdness around things like shorthand function definition on objects…)
So then a question for me is: since @benjamn is on the ECMAscript standards body TC39 team, how can MDG contribute to ES’ further development and help maintain a simpler language?
(Here’s another really nasty one:
import {Foo} from 'Bar'
is not the same thing as:
import Foo from 'Bar')
Yeah I’m still amazed with how they didn’t want to go CoffeeScript route where we have -> for normal functions and => for functions with context binding.