Why do most Meteor applications feel "flaky?"

[orbyt]

Uh, whats wrong with twbs:bootstrap?

[vigorwebsolutions]

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.

[AndreasGalster]

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.

[abhiaiyer]

Nah man, you need to look at concurrency with flakiness.

[abhiaiyer]

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

[sacha]

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.

[akryum]

but no code splitting is the bottleneck in our experience

That means more http requests, and you write just before that making http request are bad for your use case.

[elie]

This is a real issue. I tried to start a discussion on this topic a few weeks ago here:

Dealing with Jank

How do Meteor developers deal with jank? I.e. pages being unresponsive and running at under 60fps? One example of jank can be found at: https://crater.io/ It’s a flagship Meteor app, but try upvote an item in the list, whether on desktop or mobile, and it will take a good few seconds till anything happens. (I’m not here to bash any apps, my apps have the same problems, it’s more a question of how we can improve all our apps.) This is strange, because how hard is it to update a number from 14 …

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.)

[ffxsam]

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.

[elie]

Also using subs manager in such a case seems like it would help

[msavin]

It’s all in how you build the application. Meteor has no responsibility here, other than giving you an awesome starting point.

[AndreasGalster]

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.

[menda]

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.