-rw-rw-r-- 1 emk emk 30141 avril 9 11:32 angular.min.js.gz
-rw-rw-r-- 1 emk emk 52158 avril 9 11:30 ember-1.0.0-rc.2.min.js.gz
-rw-rw-r-- 1 emk emk 18377 avril 9 11:39 ember-data.min.js.gz
-rw-rw-r-- 1 emk emk 1870 avril 9 11:38 handlebars.runtime.min.js.gz
So now Ember.js is only 2.4 times the size of Angular.js instead of almost 3.5 times the size (71K vs. 30K). That suggests that one difference between the two is that Ember.js uses longer function and class names, which can’t be minified, but which compress well.
Ember is for “ambitious” apps… I suppose this means is not suitable for small mobile applications.
Recently, I found a great Mithril js library. A similar MVC concept and great docs. Lightning fast, 7kb gzipped, no jquery and handlebars deps. The whole framework is very minimalist and therefore easier to understand.
Interestingly, using Mithril I fully understood idea how Ember works, despite the fact that I spent weeks trying and reading the Ember documentation. That’s why I write about it here.
I’m probably more designer than developer so I can not see significant advantages of using Ember in my applications. I am full of esteem for the creators of Ember, but I find it hard to solve problems with its use, there are so many different aspects and API is so big. I do not feel safe if I don’t know exactly how my application works underneath.
I highly recommend for new Ember afficionados to start with Mithril and then learn Ember and build ambitious apps. It just saves time.
Of course, compare this forum (Discourse), Flarum is smaller, but also not as “ambitious” as Discourse is, in addition, if Discourse if upgraded to Ember v2 entirely, its size will be much smaller.
But please don’t misunderstand my meaning. Mithril is indeed lightweight & small, but when you create a system like a web application, you have to solve many many problems, the size of tool you use is only one of them.
You can choose a small toolset at the first, but you need to know how big/far the goal is, and If you have to extend your toolset, how complex it will be? whether or not you have the ability and time to archive this goal?
what “ambitious” means is not how many APIs you need to learn and how many code you need to write, but the scope of problem you need to face and solve.
I agree that the initial size of the library is of little importance in this case.
I also agree that scope of the problem is a key thing to choose right tools.
To be honest, my problems are deffinitely much smaller than those in Flarum app
As you can guess - my applications are also significantly smaller.
One of my problems to solve was to learn Ember, to be able to build a really ambitious applications like Discourse as a member of the team, or simply - to have tool when I find more ambitious problems to solve.
Perhaps the right tool to learn Ember is Ember alone. But in my case it was painful and did not bring the expected results in expected time. So I decided to change tool. I tried something simpler, which helps solve only part of problems with applications when compared to the Ember. But works in similar way taking into account the pattern and the relationships between application components.
I have experienced enlightenment and I know how to solve my first problem. It’s just my story.
My main idea is that to understand things more complicated, better to start from the basic elements. I think that that library is such a simplification of Ember, good for beginners.
I’m not saying that solves all problems.
99% of times when people worry about library size (could be jQuery, Ember, Bootstrap, D3, etc) it’s unfounded.
1-2 images (especially with retina quality) is easily more than all JS code.
Bandwidth is high these days, most phones have 3G/4G and people often stream HD video to their phones.
CDNs are super-cheap (CloudFront, Fastly, Azure CDN, etc) and with POPs in every major city downloads will be very quick.
gzip is often overlooked (JS is easy to compress).
Also, there are tradeoffs. Most of the time it’s very rational to pick a larger framework (resulting in, say, 50-200 ms longer startup time) if that enables higher development pace and yields a better app/website.
I agree with sandstrom, library size is rarely relevant in real life unless you know you are operating with very limited bandwidth and even then you should only need to load it once. It’s just something that gets brought out for willy-waving contests because an actual detailed comparison of libraries or frameworks wouldn’t be as effective as click-bait!
Library size would be one of the last things I would worry about when picking a framework.
There are some special usecases from advertising industry where you have to count every byte because your ads have to be within adserver limits (if not you pay then extra fee for adserving). And on the other hand you have to deliver some advanced “rich-media” functionality.
I am not referring to Ember, because it would definitely be an overkill but to sandstroms jQuery example and “library” word. When you have to assure browser compatibility or to build fancy animated Ads within insane deadlines… Some People use Zepto or their own mini libraries and “frameworks” for productivity.
This may sound strange to people outside the industry but in fact you build small spa applications with pages, nested components etc.