@vjau thank you for expressing very clearly what many of us already knew by hearth. You must be an excellent developer.
The first step of solving problems is to identify them. And the problems you told are very high level problems, which makes analysis more difficult.
The Magic issue is true, I’ve felt it with a map project I recently built. And it is also reproducible. I think it could fall in the class of “race conditions problems”. Maybe giving meteor better debugging tools, and making load order more flexible (which would at least partially solve problem 1 & ") could be the direction to take?
This topic deserves a lot of love from the community. The sooner you fix problems in a framework, the less headaches you will have in the future.
I think another problem is that most projects don’t require to be real time through and through. My guess is that the benefit is not bigger than the cost of learning a new framework, dealing with its problems and possibly changing out a lot of components in your stack (although this will get better with React, Angular), when all you need is having a real time like counter or something
I feel that angularjs has alot of digest cycle, minification and scoping magic (inherent with js but doens’t work the way many people expect it to work). However this hasn’t stopped it from gaining popularity.
If we’re talking about why meteor isn’t popular vs why any magical framework isn’t popular, then I don’t think this is a valid reason for singling out meteor. Personally, I’ve spent alot of time debugging angular magic and I find meteor magic atm to be simpler to debug (either i’ve forgotten to publish, left out some rules or the variable is in a parent scope).
Also, re sessions, my understanding is that sessions is bad from a pov where you want to have stateless calls with a RESTful api. However, with DDP within a dedicated web socket connection, a SP"meteor"A is anything but stateless. So why is sessions bad? It’s just localStorage isnt’ it?
Re everything is global, are you just refering to autopublish and insecure? I think any dev worth their salt would figure that out within the first day or two of playing with the framework, I don’t see how this would have such a negative connotation as to dissuade the mass from adopting it.
Most important reasons have already been mentioned, but I’ll highlight this one:
Along the same lines of calling it ‘monolithic’, Meteor is too different than conventional decoupled server/client dichotomous architecture that many devs aren’t just comfortable with, but believe in on a deep personal level.
For better or worse, Meteor has re-conceived what web applications should be with current technology such as web sockets. Concerns about being locked into specific interface or database components are a valid current concern, but will be addressed.
The broader differences such as using DDP and isomorphic code are a much bigger pill for conventional/conservative devs to swallow, but they’re essential to the identity of the platform.
I was pretty keen on Meteor initially but a couple of things put me off. One was uploading photos. Meteor is not very keen to do that to your meteor server. I tried writing them to the mongo database and serving from there using ddp but it was really slow and tried writing to the public folder but it makes the app refresh and won’t work if you host on meteors free hosting. The standard solution seems to be to host on Amazon S3 but its kind of annoying to have to set up another server with another credit card bill when any normal setup like php/rails/dango lets you upload without problems.
Also I was a bit concerned that if you have a lot of pages and complexity, all the server code gets uploaded at the same time with Iron Router making your single page appear as multiple pages. I worry that will get slow if you have a lot of pages. Meteor already tends I think to seem a little slow on the web at the browser has to download a bunch of javascript before showing the page, compared to a simple html web page.
As a result I’d be a bit hesitant to use it for the sort of site that gets built in Wordpress at the moment and I’d be hesitant to use if for a gmail/facebook type sites as I’m not sure how well it scales. That said I’m fairly new to this so I may be worrying unnecessarily.
I’ll add that I was originally very interested in Meteor, but lack of SQL db support eventually made me go away. Mongo does not give me the security of knowing how to make arbitrary queries and joins once I have my data all locked up inside it.
Not that I’ve found. I’ve tried tweaking the version number in the .meteor/versions file but when I try to run the meteor command it just reverts back to the 1.1.0 version.
My boss and I had hesitations about Meteor’s heavy-handed control of the entire stack, but eventually decided to use it for the Mongo integration, DDP, etc. with React for the frontend. We’ve used React and Webpack for the frontend part of past projects and really loved it, that stack is extremely flexible and never gets in our way.
However, now that we’re trying to integrate the two, various ways Meteor is inflexible are getting in our way:
We don’t like Meteor style local and package-global variables. We want our nice modern require() or ES6 import in frontend code.
We don’t like dealing with file load order issues. Again, require()/ES6 provided by Webpack solve this problem.
So we started using Webpack to build our frontend, and Meteor can load the bundle, but it can’t load the source map from Webpack.
We wanted to include React from a CDN - that didn’t work because Meteor inserts all of its scripts before everything else in the header. Load order issues again
Why we wanted to stick with React instead of Blaze – React provides the freedom to include arbitrary components as children of other components. It’s difficult to explain without getting into long specifics, but currently with Blaze templates you can’t pass a bunch child templates of various types into another template from outside. Also, we get really tired of toggling between JS and HTML templates in Angular. We like having them together in JSX.
In short – if the data-handling components of meteor were refactored into things we could require() in the server or Webpack – we would have started using it much sooner.
This post is really encouraging for me as a Meteor core developer.
A month or two ago, we spent a couple of weeks doing extensive research into the concerns people had around these ideas, and came up with a similar set of issues. It’s encouraging that we found the right concerns, and I hope that we can tackle them fast enough so that we don’t lose too much goodwill from people.
Server Side Rendering on the first request. With proper http statuscodes and no “cheat” like fast-render. Some web projects have to cater google as the first class citizen, and especially content-heavy sites slow down heavily with a spiderable solution.
In general, this is the best practice lesson learned from SPAs over the years: the first page for a user should be SSRed automatically.
Im still doing meteor for my day job and love it, but Dealing with nuances of SEO and raw performance for bots/drive-by-visitors outright sucks so much time… .
I agree that in larger orgs there’ll be specialized engineers, but it really helps when engineers have the potential to work on both front and back end. Many features involve a combination of both, and if you have to pair two engineers to accomplish one feature, it slows things down and adds the potential for bugs with miscommunication between the two. I think isomorphism is a great selling point for this reason.
Meteor packages are somewhat better, but we still didn’t like to have to manually enter the load order in packages.js. Getting to require() what you need and have node/webpack/browserify work out the load order for us is 100% nice, and we’re too spoiled to want to go back to old school ways of doing things. packages.js is more boilerplate-like drudgery. It’s all about reducing those burdens so you can focus on the unique challenges of a given project.
I’d just like to throw in - that coming to Meteor - with a Rails and Angular background - I am super enticed by what I see so far. The all in one aspect, and rapidity of getting experiences up quick is hugely appealing So there’s a ton being done right. I think the framework or similar approach from another - where everything is JS, plugin-able and integrated - is gonna be extremely popular.
If there was one thing I’d point to as a hurdle it would be double edged sword of being heavily funded with a business attached. On the one hand it might reassure that the frameworks stays around - on the other - it could remove some of the aura of “authenticity” associated with open source frameworks that have success in the market purely because of the crowd/adoption.
I think the key for Meteor is becoming a leader in the coding education space. It represents a new threshold in the accessibility of building legitimately powerful experiences. Opens the door to bringing in a whole new population of people to code/create/build on the web.
A non-technical idea, I suggest working with Code Academy and developing a course of Meteor. It is a strategy targeting on people new to development. Often times these people choose big name (like rails) to start because of peer influence. Why don’t we open up more learning channel, increase the user base. Soon or later, we will see higher adoption.
