Yep. Agree 100%.
Meteor community is having a “core package syndrome.” 
Everyone needs to understand that, core is not about building everything. They do the foundation and leadership.
There needs to be a better community and that’s the best way to strength the eco system.
If we don’t trust community packages, we should start to do it. If there are some issues, we need to find ways to fix them.
11 Likes
I’ve been holding back responding to this thread for a few different reasons; but @arunoda has pretty much summed up exactly how I feel about things.
I’m trying not to plug and advertise the projects I’m working on right now, but suffice it to say that MDG has given us the tools to create package frameworks that are audited, follow different design patterns, work consistently together… the tools are the meteor publish-release command and the concept of Meteor Tracks (aka distros). We can solve the ‘core package syndrome’ by publishing Meteor tracks that are audited to work together.
What the community is clamoring for, and the OP expected (but didn’t get) is something along the lines of a Bootstrap Track. There will be other people who want a React Track. Others who want an Angular Track. Some will want a Security Track. The healthcare industry has already started funding a track for biomedical and clinical applications.
Packages not working together and a free-for-all of architecture design patterns is the long-term consequence of embracing the Bazaar philosophy, which started around 0.6.5. That’s fine. For people wanting a coherent framework, and a bit more Cathedral structure; Meteor Tracks are the solution.
1 Like
I’m in the ReactMeteor, CJSX Stylus work flow. I’m interested in CMS like tools and easy prototyping with a stable admin.
I like the ideas of “tracks”. I think the biggest annoyance has to be the package folder structure and the watcher which is painful, like watching paint dry. I am glad these issues are being addressed. I just hope my Stylus modules work and that I can easily port my CJSX module to handle the new workflows.
Uh, where’s that branch, I need it 
OK, when React is fully supported I’d like to build an admin tool with all react components (unless there’s something better). However, I’m too new at Meteor to take on such a feat. I’m 1 week into React and created a package and started my app.
1 Like
There was a sense of “the community here sucks, why don’t your open-source packages work together?” in your original post.
If that’s the case, perhaps you should realize that that’s true of all open-source software. You can make the choice to participate in the community and help make the packages inter-operate.
It makes me pretty furious to see someone blaming a volunteer community for not providing the right resources for their for-profit project for a particular client. If everyone had that mentality, none of these packages would exist.
15 Likes
Couple notes, I was pulling my hair out for more than a day just trying to get libraries to play nicely with each other and running into issues at every turn. Some of it was documentation problems, some of it was packages that must have not been tested to work with other libraries, and some other UI quirks while living with the lamenting through the slow rebuild process that takes about 30 seconds, even if I am moving a margin in css.
By the way, I didn’t say that I was charging my client. I am doing this app pro bono. I’ve already started participating in writing packages (albeit simple ones). I never said that the community sucks, I would never say the community sucks, those are your words, however, I do believe that that there needs to be more cohesion with packages and community and we need the next version of Meteor to be as good as the hype.
1 Like
I would say that the meteor watcher is the thing that makes me feel like the app is unstable, I know this is being improved for a future release, but often the watcher crashes trying to compile Coffeescript, this might be the fault of the wrapper and not the meteor app itself, although, I don’t know… Also, I went to do a meteor remove and a meteor add to get the new updated package of a library and for whatever reason (maybe caching, who knows?) I got the old version again, not the latest one on github, with the correct package version. I think that editing package file directly always seems to work correctly, still that was really confusing to me.
I think the lack of package organization would also make me feel that the framework isn’t mature. I am curious how that battle went over in front of the whiteboard of defending the folder structure that was designed? Was it heated, did anybody storm out? Can anybody explain how that happened, it might make me understand how we got here.
I’m not discounting the incredible work done by a lot of people, I’m hopeful since MDG has the resources to close the loop. I am sorry for any haste in m message, as I mentioned I got really hyped up on Meteor, bought the book and drank the Kool-Aid, now I’m ready to smash though a brick wall, instead of hitting my head on it.
I think if you have any problems with the coffeescript rebuilds, you should file a GitHub ticket with details and a reproduction, instead of writing about unstability you felt in a forum post. I appreciate your time you put into expressing your concerns and there is a better way to do this: for technical issues open github tickets.
FWIW, I’ve never heard coffeescript being unstable from anyone and it is a pretty heavily used package. Nobody seemed to complain so far, so I wonder what could be wrong.
Please, separate your concrete technical issues from the emotional response of instability.
5 Likes
Hmm that’s odd. I’ve been using Coffeescript in a legacy meteor app for over a year without any crashing. I’m sure MDG would love it if you could create an example repo that replicates the crashing.
Also one thing that helps mitigate the reload time is running my unit tests scoped to just the file/component i’m working on, this way specs pass in < 1 second. With React and Jasmine I can almost build the entire component before opening the browser For full reloads on a large app i’m around 4 seconds from save to page load.
@SkinnyGeek1010 Hey this is a little off topic, but do you have an example repo of you testing React components in Meteor with Jasmine? I’d like to start adding tests to some of my React play apps and I’d love to see an example of someone doing it successfully.
can you recreate any single scenario where Meteor is crashing due to valid coffeescript?
Or anything is crashing due to valid coffeescript?
Honestly I don’t think that’s possible. The fact you say this led me to believe that all your problems could be solved with some practice and a solid course on some of the more technical part of programming (Computability problems, design patterns and complexity)
17 seconds to 1.3 seconds that’s amazing!!
Ok, so to your point, here was my course, to prove my original point, if Meteor is really 1.0 worthy? The central problem is that the package manager has some real issues with dependencies, for instance, not rebuilding my projects correctly, if one of the packages changes.
I changed my package file. (By the way why does the package file not have an extension? I hate files on my filesystem without an extension, .txt .yaml .json whatever). I couldn’t get the bug resolved until I removed all my packages and then it printed “removed XXX from your project” 20 times. After it errored restarting (of course), I replaced all the packages, re-saved (essentially a clean build) and low and behold, tried my image upload and it worked! I had changed single dependencies around before, cut and pasted before with no successful results, after maybe hundreds of rebuilds. This has led me to the package manager.
Meteor is already a 1.0, I’ll concede that point and here’s to a much better 1.2 release that MDG can be proud of, a 1.3 second rebuild time is awesome - I love it! how long till 1.2 gets out?
Yep, short answer is they will be on https://github.com/AdamBrodzinski/react-ive-meteor within the week. I’m also going to create a minimal example repo and will post on the forum.
I’ll PM you for more details so we don’t go too off-topic here.
1 Like
Do you know there is button called fork in github?
You didn’t get the point here and I think you won’t understand it anyway.
We all know, Meteor is not perfect and (just like any other software) we try to solve issues as we can.
Most of use here work voluntarily just like the two packages you mentioned. There are bugs. If that’s pretty worthy why don’t you give it a try fixing it. If that’s not gonna work, I hope you better try to find some other framework.
With this kind of attitude, you never get any help at all.
I suggest you to do this first.
- First, try reading few threads on this forum and learn how we are interacting here.
- Read some Github issues and learn how to submit issues. We argue of course.
You don’t need to prove us anything. Try to learn something.
7 Likes
Oh Yeah, I am trying to learn from some of your examples on your meteor hacks website. I do think I can understand your point. I don’t expect everything to be perfect. I am aware there is a fork button on Github.
How can we coordinate community package development? What are some other frameworks doing to encourage community package maintainers to collaborate towards integrated solutions?
This sounds cool. What learning resources or examples can we use to begin building Meteor Tracks?