Not my point. My post that you are replying to was about this quote from the op:
This was the last official position post I could find from MDG:
Somehow more choice equal force.
Funny how no one claims MDG are “forcing Angular down our throats”. It’s almost like those complaining the most about this change have determined that React is the only view layer of the three that has a future.
I agree with you @peter.roehlen. MDG is not forcing React on us (although it might feel like that to someone new with all the momentum behind React right now from outside MDG). Use Meteor classic as long as we understand that it will no longer be maintained by MDG at some point relatively soon.
I think this community needs devs that have the time to step up and take ownership of the various Meteor classic components.
The main thing that drew me to Meteor about a year ago was that I could create a working application in a day. Now with 1.4 app structure, I find myself spending 20% of my time writing new code and 80% fixing imports.
Meteor has gotten fat and complex. But there are already more mature fat and complex frameworks out there. So I don’t see why would anyone start with Meteor now.
While you can still structure everything the same as prior to 1.4, the only issue I found is that the can’t put JS in the blaze header files…I’m a fan of staying close to clean HTML in templates and since they decided to not allow adding stuff in the header file, I had to spent tons of time fixing imports… also I find atmosphere way easier to deal with then NPM…but other than those, I find you can still do mostly what you were doing prior to 1.4 everything else is optional…
Imports are still optional. You can just dump all of your code in the client/server folders (or in root for that matter). Using modules is just supposed to be a help for anything other than very small projects.
I’m still able to add JavaScript in the header too so would be interested in what the issue was there you were having.
Of course you can also continue using 1.2 but my point is, if I had just heard about Meteor and tried to follow the tutorial, I’d give up around Startup files, the part where i need to create index.js which does basically nothing but import other files.
Coming from Java imports are nothing new but Java IDEs mostly do that for you and you never have to manually enter relative paths, like ‘…/…/ui/pages/app-not-found.js’ etc. Of course that’s more EcmaScript than Meteor issue but I’ve gotten used to things magically working in Meteor and now the magic is gone.
Peter - adding javascript in main header pointing to JS file in the public folder doesn’t seem to work for me if it has dependency on jQuery for instance, am I missing something?
Sure, happy to share my thoughts. The next Spacecamp 2.0 is up and coming in November, gonna be a blast like last year 
I think zerqie has a good point, I think the tutorial should stick to the basics and simplicity that we all liked when we first started Meteor and I also ago those imports relative path are ridiculous when compared to Java imports…
If it has any meteor dependencies it won’t work in the header. Those scripts are loaded before Meteor is initialised. You could try moving the script tag to the body.
Yeah that is what happened, after moving them to the body I wasn’t able to control their load order so I ended up moving to the client lib folder, but then some of them needed jQuery so eventually I moved them to compatibility folder…my point is that I had to do this refactoring after 1.3, prior to that you can simply grab a template online put in a Blaze template and it would work as it… From an expert eye, this looks trivial and easy, but from newcomers perspective it’s unneeded frustration I think.
OK, fair enough.
I’m doing something similar and was just curious about the issue you had. In my case though, I’m loading a library in the header and effectively kicking off the public folder script that uses it in client/main.js.
I don’t know that using external libraries and public folder scripts that aren’t loaded via packages where dependencies can be explicitly defined was ever supported or recommended in “Meteor Classic” but I defer to your experience that it used to be easier.
It was supported prior 1.3 however I don’t think it was considered best practice.
It was an easy way to just grab a Bootstrap template and start playing with it in “Meteor Classic”…I would convert the HTML files to blaze templates, grab the JS files in the public folder and change the path in the header files to reference to the public folder files and things would work as expected… It’s a big deal for me now, but when I first started with “Meteor Classic”, everything was working really smoothly and I truly enjoyed the development experience since the framework quickly got out of the way.
I think one of the main reason for the success of 'Metoer Classic" is that MDG did a phenomenal job in creating a very pleasent development experience within the Node.JS ecosystem and I truly hope they keep that emphasis as they try to provide more options and cater for wider audience.
Would you like to tell what are they?
@joshowen I did a reply to one of your emails on Spacecamp, but haven’t received a response. Where can I send you questions on this?
I already replied like 40 minutes ago 
I think here you mean pip, not Django 
I second your opinion.
As someone who DID build something and actually had people using it (and was at one point growing my base and even had to start using intercom to manage customer comms) I have found this flux to be immensely frustrating.
Let me caveat this by saying I’m not a developer. My motivations were solely to have an easy way to get up and running so I could validate and understand the product / customers. I didn’t need scale, or the newest programming language from FB - I needed ease and speed.
I started with an early version and experienced the pain of going all the way through 1.3, meteor.com hosting shutting down (and porting to galaxy etc).
In the beginning I was able to focus on quickly adding value, iterating fast and continuing to add value to customers and the product. but then the upgrades and shifts started to happen.
I started spending a majority of my time not adding value to my product or customers but to all the infrastructure, upgrade fixes and maintenance. The message of move to react, kill blaze / re-code didn’t help either. I kept stopping and restarting.
In the end I had to shut the project down because it became too complex and too hard to maintain. The value proposition of build fast, focus on the front end not on the dev ops, create value, validate and begin to get traction was essentially erased.
I still love the idea of Meteor and when I first learned it it was magical. I built a full stack node app fairly fast that people could use and it was awesome. But for someone like me who’s not a developer it became too overwhelming and messy in the end.
It’s too bad because I still get emails from people asking me about my service and if they can use it. And it sucks having to tell them unfortunately I had to kill the project because it became too un-manageable.