Thanks for lengthy response. Actually cleared a few things up!
Blaze is not developed anymore by MDG. This is a fact.
1 Like
I’m really curious where that perception comes from. It’s 100% wrong in my opinion, and the data seems to support the fact that React is definitely solving a lot of people’s problems, not just Facebook’s.
4 Likes
It really amazes me how in-denial some fokes are. How some on here lash out at others for bringing this information to you. Devs need to understand that Blaze is no longer maintained by MDG.
Also, In another thread someone from MDG asked if another Dev wanted to take on useraccounts maintenance. MDG is moving to NPM and Atmosphere will eventually be put out to pasture. Tracker, MiniMongo will also become the community’s responsibility as soon as someone steps up to take them on I’m sure. Who’s going to eventually pick up the build-tool? Even the Apollo client is community driven from what I’ve read.
Meteor classic’s parts will be farmed out to the community for maintenance as the community steps up. Blaze is the first big part to go to the community.
MDG is preparing for this. Meteor 1.4.1 allows for pinning, so we now have the ability to release things like Blaze outside of the Meteor release cycle.
MDG will be building out Apollo Sever and Client, this will be their focus. Meteor-classic will become one of many integration points for Apollo, and as such I’m sure MDG will make sure Meteor is prepared for the task. MDG has chosen not to complete where they have in the past. Instead MDG focus on the data persistence and analysis experience.
From what I’ve read, React is maintained by an army of FB devs. According to @joshowens it will improve the performance of your site just swapping it out from Blaze. And according to @sacha survey, devs are happy with the tech and plan to use it again.
GraphQL was designed by FB too, and MDG will do their best to bring us a great experience with it – they’re betting a portion of their business on it.
This is not just smoke you-all. There is nothing to fear or have uncertainty and doubt about. Devs need this important information to base their decisions on. I have a business running on Meteor classic. I will continue to use Meteor, and slowly switch out Iron Router + Blaze for React Router + React. When Apollo nails reactively I’ll adopt that too.
By the way, I’m sure Vue.js and Angular2 are probably great choices as well. Blaze is also great and I’m very productive with it, but is maintained now by only a few. And since I have a business to run, I need the fastest view layer framework, with some of the best tooling available, supported by a large company that is committed to further its state of the art.
Also, MDG is not forcing anything on us devs. We can continue to use Meteor classic and just swap out the portions you don’t want if you so desire. And I’m happy to report so far MDG seems to be helping with the transition to this new tech stack.
Also, @joshowens we appreciate you brining your perspective and insights into this discussion. And are you running a conference in the near future? I’m interested in attending if things line up.
1 Like
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.
1 Like
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.
1 Like
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.
2 Likes
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.
3 Likes
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…
1 Like
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.
1 Like
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?