I doubt they are still using the exact same stack or exact same set up, but that was around the time when meteor was also being born, out of the need to make it very easy for developers to set up a very similar stack.
Throw in redis (there are atmosphere packages for that) on meteor and you’ll basically have set up the “same” stack. There of course are a lot of implementation differences.
Trello’s stack perhaps benefits from being barebones in the scaling area.
Meteor also scales well, we don’t currently have a production example with few million users and billions of documents on the db, so it is hard to make a comparison just yet.
I think it would be easier to prototype in Meteor, as to test various principles and patterns.
But for production it is hard to answer as there is not so many projects which can provide us with info how Meteor handle thousands of connections etc.
Well, that’s a design decision they made. You can make the same decision for your project, or not. As long as you can deliver the results you want to your users in an agreed time, it only affects how you code your application.
I did not mean backbone by saying barebones but, yeah @robfallows’ pun is quite in place
Regarding subdocuments, Meteor’s DDP server’s livedata package makes some sacrifices to increase overall reactivity performance and one of them is not tracking subdocuments.
But if you were to mimic that, you could by writing your own diffing function, or tap into observechanges on the server side and publish manually. It would be really troublesome though and would be much easier to just separate the collection.
$ ping libreboard.com
PING libreboard.com (107.22.210.133): 56 data bytes
64 bytes from 107.22.210.133: icmp_seq=0 ttl=34 time=175.477 ms
64 bytes from 107.22.210.133: icmp_seq=1 ttl=34 time=175.251 ms
64 bytes from 107.22.210.133: icmp_seq=2 ttl=34 time=175.150 ms
$ ping trello.com
PING trello.com (192.230.65.4): 56 data bytes
64 bytes from 192.230.65.4: icmp_seq=0 ttl=54 time=119.943 ms
64 bytes from 192.230.65.4: icmp_seq=1 ttl=54 time=118.244 ms
64 bytes from 192.230.65.4: icmp_seq=2 ttl=54 time=118.176 ms
64 bytes from 192.230.65.4: icmp_seq=3 ttl=54 time=118.158 ms
But, in general, for some reason, I didn’t feel it’s better than the Trello.
Just my personal impression…
$ ping libreboard.com
PING libreboard.com (107.22.210.133): 56 data bytes
64 bytes from 107.22.210.133: icmp_seq=0 ttl=40 time=252.261 ms
64 bytes from 107.22.210.133: icmp_seq=1 ttl=40 time=251.587 ms
64 bytes from 107.22.210.133: icmp_seq=2 ttl=40 time=248.455 ms
64 bytes from 107.22.210.133: icmp_seq=3 ttl=40 time=248.803 ms
$ ping trello.com
PING trello.com (192.230.64.4): 56 data bytes
64 bytes from 192.230.64.4: icmp_seq=0 ttl=51 time=277.277 ms
64 bytes from 192.230.64.4: icmp_seq=1 ttl=51 time=277.746 ms
64 bytes from 192.230.64.4: icmp_seq=2 ttl=51 time=278.576 ms
64 bytes from 192.230.64.4: icmp_seq=3 ttl=51 time=277.386 ms
Haha… anything under 600ms feels snappy behind the Great Firewall …
Well you are referring to ping times and that’s not a software stack related issue. Such comparison would only make true sense if made on the same servers/isp.