Shameless plug: I've implemented something similar in the past, but with the addition of client-side encryption. I've been using it for some time without problems.
At a first glance at the design docs here, the present project looks more sophisticated in terms of syncing. I'm just using local file operations and hoping for dropbox to do its stuff :)
I think the problem with your analogy is that it doesn't include the measurement basis. Consider polarization of a photon: you can either distinguish between horizontal or vertical polarization with a measurement, so your basis looks like a "+". Or you can distinguish between diagonal polarizaitons, so your basis looks like an "X".
Now, considering two photons, you don't know which basis Alice or Bob will choose in advance. If you just say "the photon is polarized horizontally", then their outcomes will be random if they measure in the "X" basis. If you include so-called "hidden variables" for all possible measurements, then you're basically at Einstein's idea.
(I've simplified some things above, so please don't quote me on it ;)
Shameless plug: If you want the data in dropbox encrypted, try https://github.com/lucas-clemente/git-cr :) I think I've also solved most of the concurrency problems, but haven't tested it yet.
and shrinking :) We have some fun related work planned to continue the shrink.
One thing to note, often we must trade-off bytes for supporting older features. As those go away, we shrink. But moving forward the plan it to have more of a pay-as-you-go model. Utilizing ember-cli to do the r.js optimize esq step, to strip unused portions etc.
Nothing ground breaking, its tried tested and true in many other ecosystems. But when it lands it will provide nice value for our ember apps.
It's big, sure, but that's just another piece of decision making information. If you're building an app that'll be deployed for users in sub-Saharan Africa then it's clearly too much, and you need to revise your technology decisions. On the other hand, if the majority of your users are affluent westerners with broadband connections then it's less than the size of a single, full-screen background image, so arguably it's actually a relatively small download. What is "too much" changes - 120kb library, for some users, isn't too much.
That said though, if your ember.js code blocks rendering, or causes lots of repainting, and you're building a site rather than an app, then I'd question if you're making the right choice.
My Nexus4 has a faster internet connection and more RAM than my parent's laptop, and it's almost a 3 year old phone. Most (75%+) smartphone users in the UK have devices that can easily cope with a 120kb javascript library. Your rule is wrong for western countries.
E.g: is it an internal tool? Is it a landing page? Is it a SPA that has to do a bunch of things before content can get rendered? These considerations have an effect on what is an acceptable webpage weight for most teams.
Traditionally those sites may have also consider
I am sure they will continue to be happier as the byte size shrinks, but in the interim they are able to deliver what appears to be a great user experience, in-light of your concerns.
Ember is fairly all-encompassing. Sure, if you compare it with JQuery, it's big. But if you compare it to the full stack of libraries you need in order to run a reasonable React app, it's not too shabby at all.
It seems comparably pretty terrible to me actually after a bit of checking.
React comes in around 26k, Flux is another 1k or so, and say you throw in underscore that's still something like 30k combined. Add another 5k if you need an es5 shim / sham (say you're supporting earlier IEs). Another 4k for superagent. So it looks like somewhere around 40k minified and gzipped to run a reasonable React app.
The nice thing is that you don't even need jquery once you're in react land, unless there's an addon you absolutely must have and would be a pain to reactify. We haven't had to use jQuery in our last few projects.
That's 3X though and not 8X. 8X sounds like a biased exaggeration. I don't understand why people have to polarize so much over js frameworks...
Now I also think Artsy does a lot more than Bustle, to be fair. However the point is that framework size is only a part of the story. The complexity of your code, how you ship it, and how concisely the framework lets you express a design are all extremely impactful.
Ember gives you a big bang for your buck with that 108K (a minified, gzipped 2.0). In practice not many people find this to be the main performance hurdle in their apps, but regardless we're working toward smaller payloads (something we call "svelte builds") and better initial execution performance (https://github.com/emberjs/ember.js/pull/11576).
Exactly my thoughts. Only one JS framework of that size. You'll probably include a few more JS (analytics and what not)... no wonder my "unlimited but limited" mobile plan is hitting the limit every month.
Artsy.net home page weighs 5.2Mb compressed. Less than 20% of that is JavaScript that is fully cached between page views. Let's suppose average visitor will watch 3 pages on average visit. He'll consume 800Kb of JavaScript and 12Mb of images. Most likely, next visit visitor browser won't download any JS at all. If people are OK browsing so image-rich website on their phones, developers shouldn't bother about 140Kb of Ember.JS if it helps them deliver app faster. JavaScript is less than 10% even for the first time visitor.
I don't know artsy.net, it's probably image heavy.
But an average webpage size of over 1.5MB is not acceptable onmobile, imo: http://www.websiteoptimization.com/speed/tweak/average-web-p...
Also: http://royal.pingdom.com/2011/11/21/web-pages-getting-bloate...
It's far more then it should be. Graphics can be size optimized, SVG or jpg. A JS framework doesn't need to be 100k where most webpages are probably only using a small subset of functionality. And i also don't want to download a gazillion other JS files for web tracking and such things. Ever download on a high latency connection hurts.
Even though you always hear about the mobile web, web devs simply aren't trying hard enough to make the mobile web experience pleasant. They'd rather complain about mobile safari or mobile chrome than actually look at their own product.
(Yes, this is a generalization, but generally, the mobile web sucks.)
Your problem is a mobile network operators' problem primarily and not web/mobile devs'. Don't blame us for making the experience for you or us all prohibitively mediocre when those carriers are to blame for their ridiculous limitations imposed on data consumption and their exorbitant data plans.
That is really the thing, for a line of business application (which is what I write) I can hardly think of anything meaningful I can do in only 14k. If you are writing a marketing page for a random potato distributor I can see it, but even the standard run-of-the-mill home page has 1 meg of images, even more if there is video.
In 1999? Depending on what you're doing, ~100k of scripts is completely acceptable. If you just want some fancy UI interactions on a landing page, it is overkill though.
That's not 100k of scripts here, that's 110k of minified, gzipped javascript before you've started writing your own application, and it doesn't include ember data.
This or git clone + open source is pretty critical. I want to recommend this to my company, but I can't rely on the longevity of a fresh-out-the-gate startup for storing crucial enterprise knowledge.
At a first glance at the design docs here, the present project looks more sophisticated in terms of syncing. I'm just using local file operations and hoping for dropbox to do its stuff :)
https://github.com/lucas-clemente/git-cr