I used to be really into Meteor but have kind of cooled off over the past year. I’m picking up some more web dev projects and am looking back at Meteor. My main hesitation is that i’ve noticed that web apps built with Meteor always feel a little “flaky” to me.
The best way I can describe it is like a Phonegap mobile app vs a native mobile app…the first can be ever so slightly more sluggish than the native version, and things just dont feel as smooth.
These sites are great concepts but they have always had that flaky feeling to me when using it. Even some of my own sample projects, they just feel off for some reason.
Then I come across web apps built with pure Node and other parts of a MEAN stack and they feel flawless.
Whats confusing me is that I understand Meteor uses node and that Meteor is a client-server platform and the front end will heavily depend on what you choose to build it with.
So why do I have this stigma? Or has anyone else noticed flakiness with Meteor apps?
My input is that it’s not specific to Meteor. I feel like 95% or more of all apps I use are flaky in some way or another. One I’m particularly feeling right now is Google Inbox, which was worked on for 7 years by some hardcore people at Google, but still lags every time I try to open an email.
Yea thats what im asking about really, I’ve just only noticed it in apps i know are using Meteor. Could be confirmation bias perhaps, but thats why i posted this.
Yeah. I do feel some lag with Atmosphere. CodeFights seems pretty smooth to me though. Maybe not all apps are built with UI render optimization in mind.
It sounds like you’re confusing causation and correlation here. Just because a site has a poor user experience and/or poor design doesn’t mean it’s the frameworks fault.
Blaze and React themselves are quite fast and snappy in my honest opinion.
Meteor is quite easy to use. Easy to use systems have more beginners. Beginners have less skills. Less skills produce subpar user experiences.
Meteor is also very fast to get things out the door. Because of this speed a lot of projects are thrown together quickly and little time is spent on design and user experience. A lot of times bootstrap is used which has that stale feel.
Meteor also makes it very easy to plug in packages as needed. Sometimes a meteor add hairball is so easy and fast that people live with a poor quality package because they can’t (or don’t want to) write it themselves, even it it would be more efficient.
I also think latency compensation done right is less than trivial to implement. It needs to be done with care in order to prevent janky behavior. Overloaded subscriptions can also cause slow/laggy behavior. However I think this is far less of the issue than the ones mentioned above.
http://fastosphere.meteorapp.com is an example that focuses on speed over aesthetics. However, i’ve found most people don’t focus on this as much (opting for speed to market instead)
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
