We cover some general usability guidelines and best practices for creating your own video backgrounds.
It should come as no surprise that fullscreen video backgrounds are quickly growing in popularity. Internet speeds are increasing, browser technology is advancing, and the simplicity of capturing HD video is galvanizing.
Since this trend has gained such a large following I’d like to cover some general design tips, guidelines and some resources for creating your own video backgrounds.
From entertainment venues to creative agencies and personal portfolios, there are dozens of websites that incorporate fullscreen videos. Granted not every project can benefit from this type of server-intensive design technique. Yet using a keen setup paired with careful attention to detail, fullscreen video backgrounds can be an enormous benefit to an overall layout design and website branding.
Simple Videos with Contrast
The best style of background video will build heavy contrast between the video and the page text. A simple rule of thumb is to lighten text with a dark video or darken text with a lighter video. It definitely helps if the footage is mostly uniform with just a few colors.
Coulee Creative is a pristine example. In the website header you’ll find a small navigation along with some intro text. The video switches between various scenes but each of them appears somewhat faded. This effect is created with an overlay grid of repeating black dots. If you look real close you’ll notice a repeating pattern on top of the video.
While this tiled pattern method isn’t foolproof, it really does work and looks fantastic. You might also try editing the video in software like Premiere Pro or After Effects – but not all designers will have experience with video editing.
Just Say Mute
Website video media that’s setup to auto-play has one fatal flaw: loud audio. I can’t count how many times I’ve recoiled away from a website because of the unrequested noise. It’s something that’s almost never expected, which means it’s unwelcome and just plain annoying.
When people notice an embedded video player on the page it usually waits to be activated. The person can choose whether to play the video or leave it alone. Video backgrounds are set to autoplay, which is totally fine. But there’s a reason why most of them are muted by default.
People browsing the Internet will often be playing music of their own. When another sound comes out of nowhere it’s either a brief shock or a persistent annoyance. Even if you assume most visitors will have their speakers turned off, is it really worth the risk?
Do the right thing and just mute background videos. Trust me, you and your visitors will be happy you did.
Not every video background needs to conform to a fullscreen interface. It may be wiser to limit the background section to a smaller height, thus leaving direct access to further areas on the page. Take a look at BKWLD to see a wonderful example.
All of the video content is crisp and fits nicely into the layout. Also there’s no text to worry about, so the design flows with less effort. Each design project will be different so it’s smart to consider all of the options before moving onto a completed mockup.
Another example I really like can be found on Risk Everything. The video tends to shift between differing rates of contrast, but it also fits nicely into the header and doesn’t belittle surrounding content.
There is no size requirement when it comes to fullscreen backgrounds. Most videos will span the entire width of the page but there’s no reason you have to follow this ideology. Find whichever dimensions work best for each project and take it from there.
The video BG trend is most commonly fitted into divs on the page. The design often runs naturally and scrolls like regular content. But some designers go for the parallax effect where background content shifts as you scroll down the page.
Take for example Whiteroom which actually uses a fixed video background. As you scroll through various content sections the background will follow along. This is a strange yet intriguing style of background design which I haven’t run into on other websites.
Specific development techniques would be required to incorporate a parallax effect into the background. It would definitely require some custom development or a combination of plugins.
I recently found a fullscreen video case study which talks about the implementation of a video background on Wistia. There’s a surprising drought of fullscreen video articles but information is out there if you know where to look.
On the topic of usability there’s a burning question related to video filetypes and widespread browser support. HTML5 has shortened the gap but we’re far from a universal solution.
If you have traffic analytics at your disposal they can prove immeasurably helpful. Track which browsers are most commonly used and tally up the level of support for each video type. Flash video is perhaps the most widely-supported choice if you need to handle legacy versions of Firefox and IE.
But generally speaking aim for the most widely-supported codecs and video containers. H.264/MP4 and VP9/WEBM seem to be the two most popular choices. If your video uses at least one of these filetypes then you’re off to a great start.
Another important thing to keep in mind is file size. Your 1080p video might look amazing scaled on the larger iMac. But is it worth the trouble of forcing a video that’s hundreds of megabytes onto each visitor using a 13″ laptop?
Unlike traditional JPEG backgrounds, videos have a more natural method of scaling. Even with a reduced filesize your video should still look pretty darn good. So for video background usability the two most important tenets are proper filetype and reduced filesize.
Video Background Resources
Unless you want to reinvent the wheel by hard-coding a video background from scratch, in which case I wish you the best of luck and a 6-pack of Red Bull, then investing in a plugin will reduce your coding time & blood pressure.
The trend of fullscreen backgrounds has slowly burrowed itself deep into the world of modern web design. Although background images are still the most popular choice, video backgrounds are gaining traction with larger support and easier methods of implementation.
This post should offer ideas in the way of tips and resources to help any designer or developer create a marvelous video background experience.
Yes, you can delete them. You can even tell your Mac to never swap again. But you shouldn’t. Even on systems that have a lot of memory, your Mac might find a need to swap to its storage space instead of use its primary memory, or RAM. There is no way to know what is in a given file, so it is unpredictable when a file will be deleted.
What is the Mac swapfile? Is it important? Can you delete it? We’ll walk you through this mysterious Mac file and what you can do about it.
If you’ve even run out of disk space on your Mac, you’ve probably sat and taken some time to look and see what’s eating up all this space (pro tip: it’s easy to forget how many files you move to the Mac Trash folder; the first thing you should do when you run out of space is right-click on the Trash icon on the dock and select Empty Trash).
You might have run across something called swap, or a swapfile. It can be difficult to understand just what these files are, and whether you can manage to do without them, especially since they seem to just sit there and take up space; sometimes they take up quite a lot of space indeed.
What is the Mac swapfile?
Before we delve into what the swapfile is, we have to talk about swapping in the context of how your computer works. When you run a program on your Mac, it gets loaded into your memory (RAM). You have a much smaller amount of RAM than you do storage on your SSD.
Occasionally, if you’re doing something that requires a lot of memory, you’ll come up against some of the limits that come with having limited RAM. Enter paging. Paging is what we call using your storage drive as memory. It’s all done automatically by your computer, so you never tend to notice when it happens. While the terms originally meant something different, these days paging and swapping are largely synonymous.
When you write something to your disk, it isn’t always written in contiguous stretches of storage; instead it might be written in a number of places, wherever your Mac (PCs do this, too) finds an open spot.
In order for swapping to work, your Mac usually needs one of those contiguous stretches, which can be difficult to find on a drive as it increasingly fills up with data. To mitigate this, OS X will generate a number of these swapfiles so that it can write (or page, or swap) to them whenever it needs them.
You can find them by navigating to an arcane folder deep within the bowels of your Mac. Just click on an open part of your desktop and mouse up to the bar at the top of your screen. Click on Go, and in the drop-down menu, click on Go to Folder.
A box will appear with an address bar in it; you’ll want to copy and paste the following location into it: /private/var/vm/ and hit enter. Finder will pop up with a new window listing the swapfiles your Mac currently has active.
How many files appear depend on a number of factors: how much and how often the Mac has needed to swap to your storage drive (which itself will depend on how much memory you have and how many programs you use that may have memory leaks). For reference, the above swapfiles were generated on a Macbook Pro with 16GB of RAM; it’s gone around ten days since it was last rebooted.
Can you delete Mac swapfiles?
Yes, you can delete them. You can even tell your Mac to never swap again. But you shouldn’t. Even on systems that have a lot of memory, your Mac might find a need to swap to its storage space instead of use its primary memory, or RAM.
If you delete your swapfiles, you might cause your system to crash, as it’s possible that your Mac is using one of them right as you delete it. The same goes for whether you should disable the ability for your Mac to use swapfiles in the first place – the best result is that you won’t notice a difference, and it’s more likely to make your Mac increasingly unstable.
If you really need to free up some space taken up by your Mac’s swapfiles, there’s an easy and simple fix: just reboot your Mac. Shut it down and restart it, and then check your swapfile directory again – they should either be gone or substantially reduced in size.
Chances are good that on a new Mac you’re unlikely to run into issues where your swap is seriously impacting how much free space you have. Should you keep running into an issue, however, take a look at the apps you run on a regular basis, and try playing around with them one at a time. You might find that one app has a memory leak, and by rebooting after use or finding an alternative app, you can avoid the big swapfile issue altogether!
Swap files are easily misunderstood. They will disappear when no longer needed, but they go away in reverse order, i.e., newest first. There is no way to know what is in a given file, so it is unpredictable when a file will be deleted.
Note that if an application allocates a lot of memory, and a new swap file is created, it is because the system is moving other stuff out of the way to make room in RAM for the active application. Active memory is always allocated in RAM. So if you quit that application, the swap file will generally not disappear right away. The swap space is being used for something else.
Once a swap file is created, it doesn’t move or change size until it is deleted. The system has direct access to the the internals of the file. From the point of view of the file system the file doesn’t change until it is deleted. The modification time will not change. It is meaningless for judging when the file was last used.
You can not delete a swap file. sudo rm does not delete the file. It “removes” the directory entry. In Unix terminology, it “unlinks” the file. As long as the file is in use it will not be deleted. That is why the disk space is not released. The file is still there and still in use. By removing the directory entry, you can no longer see the file. You can not monitor whether it is still there (except indirectly, by watching disk space). You, as a user, no longer have any link to the file. But the system does have a link to it, and the file can not be deleted until the system releases it. Various “cache cleaners” that claim to delete swap files are almost certainly bogus. No doubt they do the equivalent of sudo rm.
The mere existence of swap files has no effect on system performance. The performance hit only comes when memory is being moved in or out of RAM. If something in the swap file is needed, it is moved into RAM. There will be a temporary lag as the swapping takes place, but then the memory remains in RAM as long as it is active. If the disk space used by swap files is an issue, then you need more disk space, more RAM, or probably both.
On laptops, space can be limited, especially if you’re using a solid state drive of modest size. For example, wasting 16+ GB of capacity on a 240GB SSD is un appealing.
If you’ve ever put your Mac into “hibernate mode”, you might find that space equivalent to the amount of memory in your Mac is suddenly missing from your boot drive eg if your Mac has 8GB memory, an 8GB sleepimage exists, 32GB memory a 32GB sleepimage, etc.
Banishing the sleepimage file
The missing space can be mysterious, because the file won’t be shown by the Finder, so it’s just space that’s apparently gone missing.
To get rid of this gluttonous file, you can use Terminal (found in your Utilities folder). The ‘sudo’ command allows this protected file to be removed with the rm command. You will be prompted for your password. Type the command shown in bold (copy/paste is best):
That’s it, you’re done— at least for the moment. To make sure it doesn’t reappear, see below.
Making sure the sleepimage file does not come back
(1) With Hibernate on a laptop computer disabled, any unsaved work will be LOST if the battery power runs out, because memory will not be written to disk.
(2) Turning Hibernate off on a laptop is NOT a recommendation per se, but rather an advanced technique for users wishing to squeeeze out more drive space, and find the side effect in (1) acceptable.
If hibernate mode is enabled, the sleepimage file will reappear (on laptops at least).
Hibernate mode with some 3rd-party devices can cause wake-up issues (crashes). That is another reason to disable it.
With Hibernate enabled, if power fails while sleeping, the contents of memory is preserved.
That a nice feature, but for me it is not worth losing 8GB or even 16GB of space on my MacBook Pro boot drive, especially with an SSD. And since I personally never sleep the machine and then have the battery go completely dead, and I’m usually on wall power anyway, it’s a complete waste of space.
You can disable hibernate mode with the following command, in Terminal (“sudo pmset hibernatemode 0”):
llcMBP:~ lloyd$ sudo pmset hibernatemode 0
The easiest fix is to the Smart Sleep control panel, setting it to Sleep Only. Then reboot. If the space has not been reclaimed, see how to remove the sleepimage file. But SmartSleep has an option to remove the sleep image file when Sleep Only is chosen, so you should not have to do so.
When it comes to boosting traffic to your website, you have two basic options: pay-per-click (PPC) advertising or search engine optimization(SEO).
You can pay for traffic using the PPC advertising programs provided by Google Adwords, Yahoo Search Marketing and others. They enable you to display ads in the sponsored results section of each search engine’s results page. Then, you pay a fee — based on how competitive your chosen keyword is — whenever a viewer clicks through from your ad to your website.
Alternatively, you can build traffic for free by achieving high rankings in the natural search results — the listings displayed next to the sponsored results. You will need to follow SEO best practices to try to get your site displayed on these pages more prominently and more often. It may take time to reach the top of the natural results, but the free, targeted traffic will probably prove to be well worth the investment.
But which approach is better? It depends on your needs and budget. If you want more traffic fast and are willing to pay for it, then PPC might be right for you. But if you’re operating on a shoestring budget, it may make more sense to invest time in chasing high search rankings through SEO.
Here are three questions to consider when deciding whether SEO or PPC is best for your business:
1. How large is your website advertising budget?
In choosing between SEO and PPC, you first need to decide what size advertising budget your business can support. You can set your daily spending limit as low as you’d like, but it can be a good idea to start with a minimum of $5 to $10 a day.
If you have no money to commit to advertising, you’ll need to stick with free SEO methods. But if you have even a little capital to invest in PPC advertising, consider giving it a try because it offers a number of benefits, including: • Faster testing. Websites should focus on achieving conversion, whether it’s selling products, signing up email newsletter subscribers or some other action. That means actively testing website variables to improve conversion rates. These tests, however, require traffic to generate data, so you might want to purchase traffic through PPC advertising to get faster results.
• Protection from SEO algorithm updates. One major weakness of SEO is that algorithms change from time to time. When that happens, sites that have been optimized in one way can lose rankings — and profits — practically overnight. But when you pay for traffic, you’re assured a steady stream of visitors, no matter what changes Google and the other search engines make.
PPC has a learning curve, though. Start with small, highly targeted campaigns and tie your PPC campaign to your Google Analyticsaccount. It can tell you which conversions are from PPC visitors and whether your ROI is positive or negative.
2. How high are the average CPCs in your industry?
In addition to setting your overall advertising budget, take a look at what other people in your industry are paying for ads.
PPC platforms typically allow users to bid what they’re willing to pay for a single keyword click — a fee that’s referred to as “cost-per-click” (CPC). For instance, if you want to reach people searching for the keyword phrase “car insurance online,” you could use the Traffic Estimator within the free Google External Keyword Research Tool and see that the average CPC for the phrase is $2.76.
But average CPCs can run much higher — $28.55, for example, for the phrase “auto insurance.” Those prices make it more difficult for new advertisers to turn a profit from PPC traffic. In such cases, SEO might be a better choice.
3. How competitive are the SERPs in your niche?
You also will want to determine how competitive the search engine results pages (SERPs) are for your target keywords. To do this, enter your keywords into the Google External Keyword Research Tool, which will tell you the estimated competition level, as well as the number of advertisers bidding on your keywords and the average CPCs.
In the most competitive industries, you may find that results pages for your target keywords are dominated by authority websites. They can be nearly impossible to displace without a significant investment of time and money. In such cases, it may ultimately make more sense to pay for traffic via PPC promotions.
But it isn’t always necessary to make an “either-or” choice. When combined, PPC and SEO can be quite powerful. Ask yourself these three questions and determine the optimal mix of PPC and SEO for your website.
Around the time I first published this I started assessing this myself. It is never an easy decision because there is so much to consider.
This article was originally written as a summary of Rob’s excellent talk. I still believe it is well worth spending a full hour to watch the whole talk yourself, however as time passes on there will gradually be more things moving on from the point when he gave the talk in June 2016.
I am gradually updating this article and extending this article to contain more information about other libraries and frameworks that I consider to be worthy alternatives to the shortlist that Rob selected. I also welcome you to submit your own suggestions and I will try to accommodate them if I can.
The NDC Oslo Talk
Rob introduces himself and says due to time constraints he’ll be presenting a “hello world” like example of each framework. Each app is a web component which simply shows First Name, Last Name and a computed Full Name.
First he asks you to bare in mind that:
He’s obviously biased, especially against Angular 2 (also bare in mind that this summary could potentially contain some other bias)
Don’t be swayed or swept up by hype. Be professional and choose what meets the needs of your business.
As bias is a theme here, it is only fair to discuss any possible biases I might have.
My brother is a React JS developer. I am also a guest blogger on Outlier Developer, which is run by the same guy behind React JS Consultancy. I do not currently use React JS or any of the other featured frameworks professionally.
I currently use only jQuery, Bootstrap, Webpack and a few small libraries, which in my opinion is all you need for small projects. However I am currently working on a big project, so I need to get agreement on a suitable framework quite soon.
I am not paid to write for Outlier Developer or have any financial interests in any particular framework.
Any personal commentary on the talk is (italicized and in round brackets).
Rob believes our tendency to jump to technology choices too quickly is a systemic problem in our industry.
Rob says he’s trying to be as unbiased as he can be, and will cover the frameworks in alphabetical order.
He points out that they aren’t all frameworks in the same category, or even all frameworks.
Angular 1.x is an all-in-one framework. Rob says it is
pretty much deprecated, there’s literally a fixed number of months left on the lifetime of that framework
it’s probably fair to say that you shouldn’t start a new project in Angular JS right now, and you should be thinking about how you might migrate any existing code bases.
(I’ve never been a big Angular 1.x fan, but I feel it is only fair to point out that Angular 1.x is currently actively supported, and every framework has a number of months left in its lifetime, whatever that means.
If you are interested in using the Ionic Framework then you need to adopt Angular 1.x as well. To dismiss Angular 1.x is also to dismiss the Ionic Framework. Ionic v2 uses Angular 2. Rob doesn’t mention mobile at all in the talk.)
Rob describes Angular 2, Aurelia, Ember and Polymer as also All-in-one frameworks, but modern ones.
React is not a framework, per se. It’s a view rendering engine or a component model.
Rob says that although the demo is extremely simple, it shows the different approaches that each framework takes.
Rob recommends Visual Studio Code and is using it on his Mac. I’ve since heard Mark Rendle and others agree with this point. I have found WebStormis well worth the license fee but if you want a free solution Visual Studio Code works pretty well.
(For brevity, I’ll be referring to lines of code. Some lines of code can be much longer or shorter or more or less readable than others so to get the full picture you’ll need to watch the video for yourself. Rob has a style of leaving a blank line at the end of each file. I will discount those. The line count stats do not attempt to keep up to date with any newer versions released, only the versions at the time of the recording.)
index.html is 13 lines of code
We see the ng-controller and ng-model directives.
app.js is 8 lines of code. Rob describes this as a throwback to the previous generation of frameworks: Angular specific modules rather than ES2015 modules. He describes the Angular 1 two way data-binding model.
Rob says Angular 2 really focuses on TypeScript, and
index.html is 32 lines of code
(I could not believe that there isn’t a simpler way to write this in Angular 2. Rob has found some Angular 2 documentation that pulls in a whole load of modules. For the purposes of developing a hello world type app, Rob is pulling in the following modules:
There is also a bunch of code for here configuring a System JS module loader. System JS is written by Guy Bedford and Max Norlund and has nothing to do with Angular 2
Update: I have found this code is very similar to the Bill Stavroulakis “Hello Component” demo which you can find on Plnkr. Bill describes it as “a very simple Angular 2 setup”. I was very surprised to find that this simple demo won’t work at all without Rx.js. You can create “Angular 2 components” easily, but using the Web Components standard with Angular 2 appears to be a lot harder.
Bill is a fan of Polymer JS and has created several Hello Component demos available at HelloComponent.com
Please let me know if there’s an easier way to achieve this.)
main.ts — 4 lines
app.component.ts — 20 lines
Rob explains the Angular2 decorator. He uses an inline template rather than using a template URL. He also explains two-way data-binding in Angular2, and points out that Google have deviated from the HTML specification by using mixed casing.
index.html — 10 lines. This imports System JS and uses it to import the Aurelia bootstrapper.
app.js — 8 lines
app.html — a template with 5 lines of code. Rob explains the two way data binding mechanism used here.
index.html — 16 lines. Imports jquery, handlebars, ember and app.js
app.js — 23 lines. Rob says Ember is a very strict MVC paradigm and requires a router even for Hello World.
index.html — 10 lines.
my-app.html — 22 lines including template, a script block and 4 blank lines.
Rob says the web components centric philosophy concerns him because
…it doesn’t make sense to do everything in HTML but there it is, that’s my opinion
(Again, some totally unnecessary imports doing nothing except adding ridiculous complexity to a hello world app.)
app.js — 39 lines.
At 28 mins in we’re wrapped up with the hello world examples and go into the slides.
Size (minified, not gzipped)
React+Redux — 156k or 167k with plugins
Angular 1 – 158k minimum, 240k with router, HTTP and animation system
Polymer — 222k minimum, 302k (spec compliant)
Aurelia — 252k minimum, 302k with standard plugin
Ember — 435k including router
Angular 2 — 698k minimum, 919k with RxJS, 1023k with RxJS and router and HTTP client
(Not that Redux is in any way large, but it is unfair to add Redux to the file size for React only. Redux happens to be more commonly used by React users, but it is an optional extra regardless of which framework you choose.)
Rob mentions that the Angular team are using tree shaking to reduce the file size.
This test uses DB Monster Repaint. Numbers are frames per second.
Rob says that to be honest all of these frameworks are very fast because 50 frames per second is faster than what we can usually see.
(This tool was popularised by Ryan Florence (from Facebook) in his talk at Conf 2015 showing React was faster than Angular 1 and much faster than Ember at the time it was recorded.
You can see Matthieu Ancelin’s dbmon repaint rate challenge which tests a much wider choice of frameworks, however Aurelia is a “TODO” implementation at the moment. Rob says the Aurelia team are working on an implementation for submission and it will be available soon.
Latest Performance Developments (updated 25th Mar 2017)
There is still nothing available on dbmon to support Aurelia’s performance king claim.
The dbmon test has recently been updated with adjustable mutations percentage. I have set these to 50% for these tests. The top performers may be different at lower or higher percentages.
I ran the optimized tests for Rob’s selected frameworks on my laptop on Chrome 57 for Windows and got these results:
I also ran these tests on Firefox and Edge. Frame-rates are significantly slower in both of these browsers. I found Angular 1 outperformed Polymer on Edge. Ember performance is massively improved with the latest version and there is an optimized version here which is insanely quick!
Many other fast frameworks are tested here as well. Angular Light and Motorcycle score well, although not as fast as Inferno. At the end of the talk Rob recommends Riot as an alternative to React. I found Riot scored about 36fps at 50% mutations. Also see more benchmarks from auth0
It is interesting that Rob downplays the significance of leading performance here because — giving the Aurelia team the benefit of the doubt — in the past other frameworks have easily generated a lot of interest just by being very vocal about their superior benchmark results. It is a crown which is never held for very long however.)
Aurelia: HTML, ES 2016, Web Components (including the Shadow DOM)
Polymer: HTML, ES 2015, Web Components
Ember: HTML, ES 2015
Angular 2: ES 2016 (TypeScript). Non Compliant: NG2 Markup and Dart
Angular 1: HTML, ES5. Non Compliant: Modules, Dependency Injection
Since v2 was released, the Google team has mostly met its own proposed schedule on releasing new minor and major versions
Angular 2.1 — Route Preloading
Angular 2.2 — AOT + ngUpgrade
Angular 2.3 — Language Service
Angular 2.4 — “Stability Interjection”
Angular 4 — March 2017
The Google Team have agreed to release new patch versions every week, a new minor version every month and a major version every 6 months.
So this is the plan for new major versions
There was no Angular 3 but don’t worry about that.
By new major version we mean new features and potential breaking changes since the last release. So we should not necessarily get overexcited about new major versions, or conflate higher major numbers with very much higher quality.
Google always use the latest version of AngularJS for their own applications. He also mentions TypeScript and the desire to support v2.1.
Some of the new Angular features we can expect by March are:
– Better Compiler Errors
Angular 4 is backwards compatible with Angular 2 (but not Angular 1) so Angular 2+ looks to be the better bet for new applications that you will need to maintain and improve over a long lifetime.
For applications that you expect to be one-off releases and need to release very soon, it might still make more sense to use Angular 1.x if your experience is with Angular 1.x and you want to take advantage of the more mature ecosystem that surrounds it, however the case for Angular v2+ over v1 will only grow stronger as time goes on.
The Google team recommends we use the latest version.
Asked about using Angular with a module loader Igor said
“This will probably change in 6 months…it seems that webpack is a better option from the developer ergonomics.”
he goes on to explain where Rollup or SystemJS may be better.
Google’s Green Tea app was rewritten big-bang for Angular 2.
I’ve also written reviews of first look and getting started. Deborah Kurata’s getting started course has been updated for the RTM version of Angular 2 and contains more than an hour of additional content than her original course: I am currently updating my review to include that.
For a history of the evolution of Ember.js see the EmberConf 2017 keynote — Yehuda Katz and Tom Dale address the common perception that Ember is an outdated framework with too much baggage 21 minutes in. They are continually working to modernize the framework in a way that doesn’t alienate the existing user base.)
Another detailed table at 48 mins in. Rob claims that the Angular teams don’t use their own frameworks, and that only the Aurelia and Ember teams are available to provide training.
(If you need React JS Training it is provided by Ryan Florence and Michael Jackson from Facebook)
Community and Communication
Another table of information and commentary on how strong each community is and how well the teams communicate with those communities.
All frameworks score well on this.
Another table of information at 54 mins giving details on:
Rob says Angular 1, Angular 2 and Polymer are not Google products. They are open source side projects from teams inside of Google.
(For detail’s on Google’s CRM system greentea, and it’s relationship with Angular, see How Google Uses Angular 2 with Dart. Google has also rewritten Google Adwords using Angular 2, and this is millions of lines of code.)
Yes: Aurelia and Ember
Maybe: Polymer (or web components JS) and React (or Riot to avoid the patent problem and smaller size)
Rob says React is much better for read only apps and a lot more work for input intensive apps.
No: Angular 1 and Angular 2
Rob finishes the talk by re-iterating that he is biased, but hoping that the talk included useful information.
(I definitely feel that this talk has been useful to me. When doing your own assessment don’t forget there’s also Elm, Meteor, Cycle, Marionette, Inferno, Sails, Vue and many others worth considering.
There is no one framework that is objectively “best”. Every option has its own strengths and weaknesses as we have seen. Your choice should depend on your own circumstances. A few guidelines:
Strongly consider Angular 1 if:
You are already using Angular or have developers with Angular 1 experience
You are looking to recruit one or more developers who already have experience in your framework of choice (easy to find developers with Angular 1 experience)
You are not particularly interested in chasing the latest shiny things; you just want something that is proven and reliable
You need good performance but it doesn’t need to be state of the art
Strongly consider Angular 4 if:
You are a fan of TypeScript or have developers with TypeScript experience
You want to write large, very high performance applications
You don’t mind taking a bit more time to learn an advanced framework
You don’t mind your users downloading a larger than average file
You do not want to fall behind the technology curve (it is being regularly updated in a way that makes it easy to stay current)
Strongly consider React if:
You are writing a medium or large scale app and are concerned about maintainability
You prefer to make your own specialized decisions on how your software works — you enjoy investigating and evaluating new technologies
If you write a bug you prefer to fail fast and early
You do not mind writing a bit more code as long as it clear and understandable
You are not religious about web components, as React’s virtual DOM does the job well enough
You are not frightened by the patent clause
Strongly consider Ember if:
You are not particularly interested in chasing the latest shiny things; you just want something that is proven and reliable
You don’t want to waste time being overwhelmed by the number of possible solutions to a problem — you want an opinionated framework that gives you standardized and high quality solutions to the common problems
Strongly consider Polymer if:
You love Web Components
You love minimalism
Your users, or most of them, are using very modern browsers
You want the minimum “startup tax” on your users — Polymer 2 file size is tiny
Strongly consider Aurelia if:
You want a framework that doesn’t get in your way too much
You are a fan of Web Components
You need high performance, but not necessarily state of the art
You appreciate a clean syntax
You consider standards compliance an important consideration
You only hire good developers, so you are confident they will be able to learn the framework quickly enough