I think it is unfair to blame Meteor for the quality of some of the apps built with it. Perhaps they were rushed, or simply the designers couldn’t be asked to use CSS transitions in some situations, or the reactivity not properly managed.
We’ve built illustreets.co.uk three years ago (I think last Meteor version we used for it was 0.8). It has zillion moving parts, and I dare say that it is anything but sluggish.
Pick it up when you need to built something serious and sophisticated with it, not a chat app. You’ll never look back.
Ok first of all, I don’t think fastosphere is a good example of a complex app. I can imagine there’s not a lot of code that goes into the app. Especially the UI is very simplistic, it’s not like it requires a lot of code.
I think the main reason why apps are slow is no code splitting. There’s only so much that you can do to make a site feel responsive. If you have to load and initialize all kinds of scripts on the first page visit, things are bound to start having a shitty performance. Our app is still small at this point but it’s slow on the first paint.
But only because there’s so much stuff we have to load that’s unnecessary on first paint. On localhost our app loads in milliseconds (meaning, it’s not the view layer that takes too long to initialize). But of course, loading one MB takes a lot of time, especially depending on where you’re from. It’s not just the size that’s being loaded, also the amount of requests in general that are necessary. In some countries every HTTP request is a pain in the ass. In the Philippines for example (where our team’s from) I consider a HTTP request slower than the actual download - I am not shitting you. That’s why many apps are probably 1000% slower than they would need to be with Meteor, despite concatenation there’s still requests made here and there that don’t need to be made. Let’s hope for a brighter future soon …
(Our app doesn’t even initialize/load nested scripts from other views until they’re called for the first time and it’s painstakingly slow with just 5 views. And yes, we have optimized the app already but no code splitting is the bottleneck in our experience.)
They don’t feel flakey at all, and don’t look like they use Bootstrap at all. I personally think atmospherejs is a work of art (although buggy lately).
Now you’ve got me wondering which web browser you’re using. IE6?
I find using the web in general flaky since jQuery came around, it’s always kinda shitty. But that’s the web. Youtube, my banks website, facebook. They are all kind of laughable in that there are better working adult pr0n sites that have a less flaky feel.
Using any microsoft product feels flaky to me, as does pretty much all of the devices, android, ios, ipad especially.
I have never sweared as much as I do at any device as I do my ipad. It is the bane of my existence at times. And that is all native apps. What really fucks me off is paying sometimes huge amounts for an app (£30, £120 in one case) for something that is sold as studio grade audio software and its total crap. You cant do anything cos they have got your money.
I think technology is very rushed in getting the latest greatest thing for so long now its kind of like a base head who starts telling you the story from the end, I mean most companies adopt this financially safe model of just patch everything and never really pay attention to small details
This is really interesting. GraphQL is supposed to help with this by batching queries into a single request. Do you find that facebook (perhaps mobile) is faster than other sites/apps? It’ll be interesting to see how this improves Meteor speed as Apollo is integrated.
Out of curiosity… is this site considerably faster for you compared to others? https://dev.to
The developer recently blogged about how he made several speed improvements to his blog (Rails I think).
FWIW I think code splitting can be a huge win as well. This is especially true with large payloads. (my current app is around 3-400k w/o splitting)
I think that if you use twbs:bootstrap, don’t manage your templates well, don’t manage your subscriptions well, etc. you will end up with a bootstrap-looking site with content flashes, and a generally “flaky” feeling site.
Just because meteor can drastically cut down dev time doesn’t mean that things don’t still take time.
In a recent refactor, we switched from bootstrap to semantic, and started really dialing in our subs so that things look/feel instant (even when they’re not). I’ve found this post to be very inspirational, in the sense that even though you may have a ton of data flying around, that doesn’t mean that your app has to be slow.
As @SkinnyGeek1010 pointed out, it’s almost too easy to use packages in meteor and overlook optimization/custom work. But silky-smooth apps/sites aren’t just a bloated set of packages.
Blazing fast. But then some of his optimization suggestions are hard to make and most of them were made for us already, i. e. reducing js/css bloat. (Actually our page has a 100/100 score on speed tests)
We’re having Blaze & jquery in our app for the 3rd time without knowing where it’s coming from… Another issues that desperately needs to be resolved. 1/3 of our app is probably two scripts we don’t even use
Facebook is usually super fast, loads almost instantly (unless there’s some hiccups). It would be great if GraphQL could reduce that problem for us but first we need ot find the time to write a Polymer implementation of GraphQL before we can use it
Nothing! I use it all the time in both prototype and production. But if you don’t take some time to make it your own, you end up with a bootstrap-looking site, which I think (especially among devs) has become something of a stigma. *Not that it should be, as function/content should be the heart of the app anyway!
My observation was more that twbs:bootstrap is a super convenient way to add a bunch of core styling to an app, but that you can’t expect a professional, polished design simply by adding a package.
This looks like a package that just installs everything. You probably only use 20% of bootstrap. That’s what I’d consider “wrong” with it. Ok to prototype but not something you put into production.
This is a good observation and it’s real. Let’s not be the people who blame tech for bad UX not accept our tools if they’re not providing what we want. The truth is, waiting for “readiness” is the result of flakiness. Don’t blame other frameworks or say other apps are the same way. It’s not an excuse. Atleast not for me
I think things like reactivity and optimistic UI are just hard to get right. For a long time Meteor provided you tools to work with them, but no strong guidelines to get them right 100% of the time. I think that’s why there’s a class of early Meteor apps that feel a little “flaky”.
I think if Meteor devs can manage to “graduate” to Apollo/Redux/React and adopt better practices from the start, you’ll start seeing more better-performing apps.
This is a real issue. I tried to start a discussion on this topic a few weeks ago here:
It bothers me because my apps are flaky, junky, clunky, or whatever else you want to call it.
And it’s not about animations. It’s about optimistic updates, no code splitting, blaze/minimongo/tracker doing its thing, how I write my code, and Meteor magic just going and doing its own thing because everything is reactive and somewhat uncontrollable.
And where you really feel all this clunkiness is on mobile. If you’re running on a fast machine you might not feel the jank at all, but switching to mobile and suddenly an app might become almost unusable.
This is an app that I saw recently that was created with Meteor, and it felt very quick on mobile, despite it seemingly doing a fair amount. It uses React: https://trials2016.commitswimming.com
I’ve just had a look at Illustreets too and I agree it’s very nice to use (on desktop at least.)
One tip I can offer: for frequently used data, subscribe at a higher up point in the template/component hierarchy, and do it once. Subscribing results in a very slight lag as the data is pulled to the client. In my app I was subscribing to something on a page level, but the fact is that the user would navigate throughout the app frequently and hit that page repeatedly, meaning they’d have to wait for a re-sub every time.
I wound up moving my subscriptions for these various “things” into the layout component, and I saw a huge performance boost.
