I started using Meteor in about 2014 and the main thing was that it was dead easy to get started with Blaze and basically no learning curve.
I built a few things back then, but haven’t revisited for at least a couple of years.
I’m trying to build something now with Vue and it’s so painful in comparison. It’s just a very simple site with dynamic sorting for some data. A few UI widgets to filter through some data. Should be very easy but I’ve been banging my head against the wall for a few days now with nothing to show for it.
I remember how easy things were with Blaze and Mongo and was tempted to use Meteor because of this until I remembered that even a basic boilerplate takes like 15 seconds to load. A quick google suggests not much has improved here, it’s down to something like 10 seconds for a very simple app with hardly any data.
If it’s still really this slow and resource hungry I guess I’m better off just using react or vue (without Meteor of course). Much steeper learning curve, but I guess I’ll be better off in the long run.
So, is it really still this slow? Can I build something with Meteor/Blaze/Mongo and have the initial load time be a respectable 2-3 seconds instead of 10-15? If so, what would be involved in doing that?
If you are referring to page load I have never seen anything near what you are talking about. Also, I have done a couple of performance measurements and usually discovered issues that I had introduced. These issues were usually easy to resolve and return the performance to very respectable levels.
To get an idea of performance, try loading up simple-todos. Page load time for me was sub 1 second. (of course that is running all localhost).
You must be doing something wrong. We have an app that has nearly 100K LOC in the frontend (and something similar in the backend), which is interpreted and loaded in just over a second.
Meteor was very fast in 2014 too. Unless you’re dealing with very large collections (in which case today there are very good, scalable solutions, like redis-oplog), you should be cruising.
You say you’ve been banging your head for days, but you show no code, or server log, to let us help you, so not entirely sure what the point of your posting is, other than to express a very subjective opinion.
Perhaps a quick test of the todo app would suggest otherwise? We’ve complex app loaded under 2 seconds. I’d suggest to actually try a sample app because your google search results and assumptions are simply wrong, there is no way an app would take 10 seconds to load, unless something is poorly coded!
As for the vue-meteor integration, I didn’t use it, but I see a lot of people using it here, so I’m not sure if your comment is about vue itself or the integration layer. If it’s about vue, you can still blaze if you want or React but I doubt you’ll find React any easier.
There is a lot you can do in 2017 to improve your load time, so give it a good try.
I was referring to Vue itself, not Meteor + Vue. I’ve been trying to use it with PouchDB and it’s about 1000x more difficult than Meteor+Mongo, I spent most of my time just trying to work out what Vue is doing with my code rather than being productive.
Is it public? Would really love to have a look if possible. Thanks.
I was trying to use Vue’s vue-cli thing and it was just a confusing mess, I’ve had a play with react which I found much more transparent to deal with but was looking for something a bit more frameworky. I guess I’ll use Blaze and then maybe throw some React in. Nothing has given me that warm and fuzzy feeling like when I first learned Meteor with Blaze.
I found Vue about as easy to learn as Blaze. Blaze has a slight edge when using Meteor in that it uses the same reactivity system, but meteor-vue works well too.
You shouldn’t have 10 second load times, but Blaze is indeed really slow compared to Vue. Especially noticable on mobile. The old Blaze version of my app had a lot of half-a-second or longer freezes when switching between views on mobile, with Vue they’re completely eliminated.
I keep hearing people complain about blaze performance. But I have not had that experience.
There are a couple of things that I have learned:
Chrome profiler is your friend. Use it.
Cache all the data your app will need. Don’t subscribe and resubscribe on every template load. This will indeed test your DDP channel bandwidth.
Do profiling and examine what the reactivity system is doing. Left to its own devices Blaze will rerender a lot. Track through your reactive variables and make sure they are updating in patterns you expect. For my key loops I was able to get the rendering down to a single render as expected.
With v1.5 and dynamic imports the initial payload can be greatly reduced. You will pay when you finally import but you only need to pay that once.
My Cordova app flies! Now, for me it may be app specific. But I think I could optimize to do the right thing.
It’s safe to say that choosing the JS framework was one of the most important decisions we had to make. Looking back at the journey from version 0.49 (our first prototype) to 1.6 … I can say Meteor was the best decision we could have made.
I wrote a small PWA (https://fopra.live/#/ ) with it recently to try it out and thought it was really nice and very easy to work with, as a first time Vue.js user.
Currently, I’m interested in this issue, as for now, I feel the opposite way.
I was making some ambitious program with Vue/express/postgreSQL/axios, and encountered with some annoying problem, which is a very basic part of web programming.
In short, after all, I’m a bit tired now after more than two days’ crazy deep digging(googling) the problem. Though I finally found a solution seems specific to Vue, now I’m considering to rebuild it with Meteor, simply for its high convenience when developing.
If you were to implement any kind of live query/reactivity in other frameworks, my guess is you’d have similar tradeoffs/compromises as Meteor.
Meteor is optimized for a large initial payload and then fast performance. We had a big initial bundle size of ~2.5MB and low PageSpeed scores. Using CDN, dynamic imports, and checking the subs on startup, its now down to ~600Kn and much faster loads.
I think the bottom line is web development is not easy. Meteor makes it easy to do a large number of things you have to do manually in other frameworks.
Yeah it’s full steam ahead with Meteor for me now. If anyone else is reading this later and worried about the initial DDP sync, FastRender has made this blazingly fast for me even over relatively slow connections with a pretty big database size (2-3mb).
Can you elaborate more on that? You mean just making sure nothing unnecessary is subscribed to in any given template?
We were creating and using subs for all possible use cases on the main site. e.g. what if user searches for something etc. By delaying those till the action is performed, and in many cases combining that with dynamic import, results in savings.
Thank you, @dr.dimitru. I’ll check that out. We do the dev wok on Linux and didn’t notice that. It used to work without issues in Sierra + Safari 10.1. We’ve hit quite a few obscure edge cases with Safari; I feel this one is slowly becoming the new IE