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?
2 Likes
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
1 Like
Ha no, latest Chrome.
I think it is truly biased opinion.
I have not noticed anything specially wrong about Meteor apps out there.
Another question puzzles me for years.
1 Like
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)
1 Like
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.
Work in = work out, even in meteor.
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
1 Like
Uh, whats wrong with twbs:bootstrap?
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.
2 Likes
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.
2 Likes
Nah man, you need to look at concurrency with flakiness.
2 Likes
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
1 Like
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.
1 Like
That means more http requests, and you write just before that making http request are bad for your use case. 
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.)
3 Likes
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.
1 Like
Also using subs manager in such a case seems like it would help
It’s all in how you build the application. Meteor has no responsibility here, other than giving you an awesome starting point.
7 Likes
This is a two edged sword. Of course I want to concatenate and make as little http requests what I actually need. But if I load 100% vs 10% needed chances are far higher than more stuff will load and execute along with that. Third party scripts for example.
I am also with the guys that say that it’s not really the framework’s fault. I was building https://www.launchcontrol.es not really thinking on crazy optimization, and the site loads quite fast IMHO. Always Meteor can do better, but it reached a really good level of responsiveness.