I’m a little put out by the annoying package structure of meteor’s libraries and it’s use of the whole global convention rather than require statements, I think that was a terrible architecture decision. I’m sorry, but It’s so hard to follow flow in the form of an app (especially for learning) . Logical ordered import classes allow you to follow the flow easily and see the bootstrap logic and its use of imports in logical order
I really thought the publish/subscribe stuff was genius, but combined with all the frustration of an experienced programmer to get libraries to work out of the box.
Also the reload watcher is so slow, it takes 10 seconds to recompile the code and reload, which compared to my other node apps using other tools, are .22ms. Curious why this wasn’t solved before the 1.0 release?
I am really speechless sometimes when I read posts like yours.
I understand that meteor as its current status does not meet your requirements and expectations. I am getting from your post that you have thought that this stack may help you at least to be faster in development for your clients. Now you have find out, that this is currently not aligned.
That is pretty fair and if you had post:
It is a pity but we can not follow up for our client projects with meteor.
For this reasons … we move back/over to
then I am sure everyone will respect your decision.
But you put your frustration directly to MDG (like Core team, why isn’t …) ??? I am sure they have not charged you and they also have not forced you to use meteor. This was your free and personal decision. You had all the time access to all sources and information were available.
So be fair enough and state that your POC maybe took a bit too long and you are now sorry for all the time you have spend. But please, post with respect.
The meteor group has $11 million dollars, that’s a lot of funding. Comparing to other frameworks in other languages (Django/Rails/Sails), schemas and ability to make some auto-forms for testing database entries are some of the most valuable time savers in building applications. I think that is a windfall of cash that the MDG received provides thousands and thousands of development hours and that’s a lot of time in engineering, this doesn’t seem to be some side project. By the way, I’d never pay to use a web-framework and there’s a lot of choice. So building something that has major movement in the development community is worth it, or it won’t gain the popularity to have the momentum a framework needs.
I assume MDG only wants Meteor to be a good as it can be. I just feel like in it’s current offering it seems like it’s 80% - and doesn’t feel quite production ready (or at least worthy enough to let my company put Meteor in production). I’ve been watching this project off and on for a year, and thought by now these problems I ran into would have been solved.
I had some real points and concerns, I think those areas are important points I raise:
Poor package structure in filesystem (ex: lib client server) folders… (I don’t want all my code in every folder executed, it should be explicit not inferred)
Loosey Goosey confusing variable scope (Class based objects why not?) why not support require AMD loading
Admin should be built in out of the box
Better watcher-reloader performance (I read that it’s coming)
Better dependency management for packages with libraries that conflict with other packages.
I’m hoping they rebuild the entire template system to use React btw, or a fork of the meteor project exclusively for React. I think React is a great pattern for Meteor development. The templates that React uses, as good as they are, already feel old fashioned.
Wasn’t meteor co-founded by former facebook devs? How come some of these choices were made?
Ok so Meteor has some things that are not 100% ideal for every use case but I think you have to weigh in the pros/cons of rolling your own stack to have the following:
optimisic UI / Latency compensation
clientside cache (and invalidating it correctly)
realtime data updates
To me building out those things takes a ton of time to do well. Making your client a custom dashboard / admin section is not that big of a deal (especially if you have your own boilerplate/components). Honestly I would never use a package to give my clients admin access… there’s too many things that could go very wrong. Rolling your own admin dashboard will be your best bet (and prob. easier for your client to use).
Personally I would rather have MDG invest time into SQL and other things before a GUI admin. system.
However I agree that that the reloader is slow in large projects and there should be CJS / ES6 modules. Those are coming to core soon and you can use those today with packages. edit here’s the ES6 module package
If you don’t like the admin, login, or autoform packages why don’t you write new ones? You are trying to meteor add your way to a production quality application. You could build your own admin package/micro service/code in a day. I know because I’ve had to do that myself.
All of the core functionality of meteor works out of the box. That’s why it’s at 1.0. You’re upset because the community packages aren’t stable. That’s a byproduct of open source software in the first place.
Both rails and django have been out for over 9 years. Meteor has been stable for one year. You could switch to Go and build your apps. Go is maintained by Google and has an amazing standard library.
If you don’t like meteor there are literally thousands of frameworks out there for any language you want. If meteor isn’t doing it for you just find a framework that does.
It’s a new framework. It takes time. It is stable. We use it in production and have had new framework issues but we worked through them. If you really like meteor and want it to succeed then you can be one of the early people that builds on it and finds the problems. Then when you find the problems you can fix them. @arunoda has been building with meteor for a long time and anytime he finds something that doesn’t seem right to him he creates a package to fix it instead of asking MDG and waiting for them.
Cluster is a load balancer custom for meteor.
Flow router is the router that he wanted to use instead of the standard iron:router
You could be a community leader and solve problems as they occur instead of letting them freeze your production.
I don’t want to sound like i’m trolling but what are you running into in core that isn’t stable?
I agree that it would be nice to have some packages that are more stable but that’s on the package authors… actually it’s on us to determine if we should use the package in production.
Also if you notice a bug, just fix it and submit a pull request. If you want a feature, just fork it and add the feature and use your forked package. The maintainer might even pull it in (I did this with Tabluar Tables when it didn’t fit my client’s edge case and now it’s in the main package).
At any rate I would be curious to what isn’t stable for you in core?
To my mind it’s not that bad as you described. As it was mentioned here, 1.1 is still pretty low number so I would rather have at this time, e.g., better scalability than official admin package, which is easily doable itself.
On other points you asserted.
ES6 is coming very soon in the next release.
According to this road map https://trello.com/b/hjBDflxp/meteor-roadmap, they are going to improve
way of defining packages/apps and controlling file load order in future release(s).
'Template and helper namespacing’ looks promising to resolve dependency management for packages.
React support (as well as Angular one) is already existed and officially coming in the next release.
And, yes, as I know, it’s built by a guy who worked on React at Facebook.
Even if something is missing you can just wrap it from node most of the time. I don’t think you’ve actually looked into the so called problems you have.
Hey, you’ve got some good points, and I share some of your frustrations. Meteor isn’t perfect, but we’re doing our best. Personally, I work at Meteor because I’m excited that at least somebody is trying to tackle some of the hardest problems around a full-stack JavaScript platform. Maybe not all of the choices are ideal, but Meteor’s heart is in the right place and we’re aware of all of the improvements we should make. At this point, it’s a matter of time, hiring good people, and prioritization.
About some of your points:
Poor filesystem structure - a lot of people at Meteor agree with this; you may have noticed that in the most recent blog post about the future of Meteor, we are talking about adopting ES2015 modules in the near future. It’s pretty clear that having a bunch of magic directory names is not the right way to structure app code.
Variable scope - same as (1)
Admin should be built in - this is a very Django mindset. As far as I know, it’s the only framework with administration features built in. However, I think the Meteor package system is powerful enough to make it happen; maybe soon there will be a perfect community-maintained admin package.
Better build performance - definitely coming in the next release
Better dependency management - I’m not exactly sure what you mean by this, could be useful to get more details.
As for React, I’m currently working on a big project to make React a first-class integration story along with Angular and Blaze. Personally, I love React’s component model and I’m now writing all of my Meteor apps with React (it’s awesome!).
Better build performance - definitely coming in the next release
This is something I’ve been working on with David Glasser for the past 2 month. On our experimental branch, we have reduced the rebuild time for one of a production apps we are testing on from 17 seconds to 1.3 second. It is still a bit more than a second, but is noticeably faster.
I just want to get this out here: I do get paid out of the company’s funding to work on features like these, but they don’t get built out of pure dollars. Every feature is being developed and tested and integrated with other components. Every feature I (or any other Core Dev) work on go through the process of product fit/approval, coordination with other efforts and many rounds of code review.
Any chance this is anywhere close to usable for others for development? If so, could you share (optionally in a PM) what branch that is (batch-plugins?) and possibly a rough list of steps to get that branch working locally, if anything special is required beyond running a meteor dev version from that branch! (Because it would be amazing to actually get back to near-instant reload-on-save with non-trivial apps!)
(EDIT: Just tried out that branch and it seems like compiler plugins for jade, scss etc need an update in order to work with the new version, which makes sense. Is it time yet to think about bringing community compiler plugins up to speed with the new stuff in that branch? If so, is there any documentation available already on what’s required / the process of migrating?)
And aside from that – thanks for your thoughtful and insightful answers, Slava and Sashko. Enjoyed the additional insight into what’s happening in core development!
FWIW – I wholeheartedly agree that it’d be awesome to have a super solid admin package that feels like it could just as well be part of Meteor core. But it should definitely be a community effort, not something MDG/core devs focus on since that would dilute focus on areas where the community would just have a much much harder time getting solutions up and running.
We are working on better documentation for package authors right now. The older versions would still work, but they wouldn’t cache anything. Porting a package like Jade is actually trivial. Porting SCSS would require some work if you want it to work across packages (the same way Less and Stylus do on our branch at the moment).
Running the branch is as simple as getting a checkout and running the meteor script from the checkout path.