Tag: javascript

Categories
Tools

Choosing a Javascript charting library in 2016

javascript charting library

Given the overabundance of tools available to a Javascript developer in 2016, finding and choosing the right one is often a challenge.

Especially when it comes to visualising data, either drawing animated charts or implementing custom interactive infographics, the choice becomes harder since there are a lot of tools out there: Wikipedia’s “Comparison of Javascript charting frameworks” currently lists 44 different libraries, jsgraphs.com currenty stands at 72(!) different charting tools and – to make matters worse – the Google search result for “best javascript charting libraries” over-delivers with approximately 786K results, out of which the first 20 results are all links with titles like “{{integer in multiples of 5}} best javascript libraries”.

Naturally, most of the relevant Stackoverflow questions of the”what is the best tool” nature are “closed as not constructive”.

In this article I aim to help with the above challenge by means of a slightly unconventional approach: In my research I tried to quantify the merits of the most popular libraries, given a series of “developer-friendly” metrics.

Sounds weird and subjective? It is. Read on.

Step 1: Understanding declarative vs imperative approaches

Before we start comparing, it is essential to understand how almost all of the available libraries can be split into two distinct categories based on their approach. Let us borrow from classical computer science and use the “declarative vs imperative” paradigm comparison for this.

The declarative approach

The majority of JS charting libraries follow the declarative paradigm: You write code that describes what you want to end up with, and the library ensures it happens dealing with all the minutiae.

FusionCharts, Highcharts, amCharts, Chart.js etc. all follow this approach: You pick a chart type (column, bar, pie), you specify a configuration object and the library outputs a nice looking interactive chart based on your wishes.

The imperative approach

On the other hand, tools like D3.js, Paper.js or Snap.svg follow the imperative paradigm. They provide you with helper methods which you then need to use to write code that visualises your data step-by-step.

For example, to create a bar chart with D3.js you will need to initialise the canvas, calculate where to draw the axis, draw the axis, calculate where to draw the columns, draw the columns, the legend, the point data, add the events etc.

It does feel a little counter-intuitive to choose any tool that follows the imperative approach, until one sees the amazing work implemented by Mike Bostock (creator of D3.js) for the New York Times, with animated interactive infographics such as the 2012 “512 Paths to the White house” to understand how powerful a library like D3.js can be.

In the next step I made an effort to establish “winners” in each of those two categories.

Step 2: Quantify the popularity of each tool

2.1 Mentions in Google articles

One needs to start from somewhere so my first step was to revisit the “best javascript charting libraries” Google search, filter out to show results only from the past year, open the first 20 hits (first two pages) and note down which libraries were mentioned.

95 libraries in total – see the “Mentions” tab of this Google sheet for a full reference (it’s the first tab – and yes, there exists a library called “Aristocharts”. Seriously).

I then filtered out the list to include only the libraries with at least 4 hits:

javascript-chartinglibrary.1png

Some surprises here already. No amCharts? No mention at all of Paper.js or Snap.svg? Interestingly, the fact that N3-charts “made the cut” here can be construed I believe as a testament to the popularity of Angular.js.

What comes as no surprise is the popularity of D3.js. It is also the only library in this list that follows the “imperative” paradigm making D3.js the clear choice when it comes to that approach. I marked D3.js as the “winner” in the imperative category, filtered it out and continued.

2.2 Licensing

Next step was to establish the license of each library. Many developers are partial to tools that are either open source or come with really relaxed licensing.

Library-mentions-license-visionmobile2

Some reading is involved if one wants to make sense of Google custom license for their “Charts” library (it’s free with a lot of caveats). Interestingly ZingChart offers a free (albeit watermarked) version of its library.

Please note that personal bias prevented me from filtering out the commercial offerings at this stage. I’ve used both Highcharts and FusionCharts in the past to great success and as a result I opted to not judge based on price – until I had all the metrics that is.

2.3 Github stars and watchers

Does the library have a repo in Github? And if yes, how many people are watching, how many have starred it? I intentionally steered clear of other Github measurements such as number of contributions or PRs since each repo has owners and each owner has his / her own personal approach towards how “open” they are to contributions.

On the other hand, a project’s star rating is a clear indication of how many developers (rather than simply users) “like” it. The “Watch” metric also tells us the number of devs who actively want to be notified when new things happen in the project.

javascript charting library

Google Charts had a few github repos but they were for projects that wrap / package their “Google Charts” project, e.g. GoogleWebComponents.

Two things stood out for me in the table above. The massive community support for ChartJS  – almost the same number of stars as Backbone.JS (!) – as well as the number of people who are watching Chart.js.

What is also surprising is that out of the three commercial offerings, Highcharts number of stars is orders of magnitude higher than the rest.

2.4 Stackoverflow tagged questions

Another metric that can tell us how many people are using a library is to see the number of questions that are “tagged” in stackoverflow for a specific library.

This is not foolproof – one might argue that extremely well designed and structured libraries will be so intuitive in their use that people will not be asking questions about them – but my personal experience has shown that even the simplest of tools generate a lot of questions when used by a lot of people.

javascript charting library comparison

Is Highcharts the most difficult library of all? Or is it perhaps the most widely-used one? Perhaps its developers are extremely responsive to the questions of the community? We cannot answer this with 100% confidence. What these counts show however, is that highcharts has more tagged questions in Stackoverflow than all rest of the libraries combined.

Choosing the winners

Since I’ve already opted for a (completely) subjective approach, what better way to pick a winner by simply…. adding everything up.

Here are the top 5 libraries sorted by “Score”, i.e. the sum of github stars, github watchers and stackoverflow tagged questions:

javascript charting library comparison

Full data available on the “Final results” tab of this Google sheet.

Declarative approach – Open source – Chart.js

If the Github stars are anything to judge by, there is a lot of developer enthusiasm for what Chart.js offers.

The documentation is clear and concise – http://www.chartjs.org/docs/ – with several inline examples, browser support is solid (as long as <canvas> is supported chart.js will work – this means no IE8 and some inconsistencies on <= IE 10) and the 8 chart types it offers should be more than enough for most needs.

Declarative approach – Commercial – Highcharts

I’m an avid user of Highcharts and I was pleasantly surprised to see it “rising” in the ranks of my little quantitative experiment. The massive number of stackoverflow questions clearly signifies that despite its commercial nature, the community uses it… a lot. The high number of github stars – (I repeat: for a commercial project) – is also quite indicative of the “developer feelings” for Highcharts.

The documentation is stellar (with a really powerful “Demo” showcase where every single example is linked to a working JSFiddle), the API browser / reference is a great resource and browser support is not an issue since Highcharts auto-falls back to VML rendering for older IE browsers.

Check out this JSFiddle to see how easy it is to visualise a table like the one shown in “Choosing the winners” above:

choosing a javascript ibrary

Imperative approach – Open source – D3.js

The central principle of D3 is to enable developers to programmatically construct SVG objects and render them as they see fit. As long as you can visualise it, D3.js can help you (a) draw it, (b) make it interactive and (c) animate it.

D3.js is the tool to use when a charting library simply won’t cut it. And the community demonstrates this very clearly:

Github stars – 54848
Github watchers – 2653
Stackoverflow tagged questions – 22036

If I had to score this the same way I scored the charting libraries, then D3 leaves everyone behind by a factor of 2 with a score of 79537.

Categories
News and Resources

News roundup – Google opens Early Access beta testing to more developers

razer fund gaming startups

Welcome to DeveloperEconomics’ weekly news roundup. In this edition, Google cancels its modular smartphone project, Apple plans to delete abandoned apps from the App Store and Epic releases a new version of Unreal Engine 4. Read on for the full news rundown.

Google opens Early Access beta testing to more developers

Google has expanded its Early Access beta testing, allowing any developer apply for the program. Previously, Early Access was only available to 29 hand-picked developers, who got to test out their apps with early-adopters (although other devs were given different testing options). Google says the Early Access program generated over 1 million beta installs since launching in May and “demand is only growing.”

Google Search can now look-up content within apps

Google has introduced a new search mode in its Google app that lets users perform in-app searches The “In App” feature currently only works with Gmail, Spotify and YouTube, but will soon feature in-app searching on Facebook Messenger, LinkedIn, Evernote, Gilde, Todoist and more. Because the search function involves the OS itself, In Apps currently only works on Android.

Apple removing outdated apps from App Store

Apple will begin removing apps from the App Store if they no longer work, are outdated or “don’t follow current guidelines.” The company will also prevent devs from using overly long app names to game app searches, limiting app names to 50 characters or less. Apple will start reviewing apps on September 7 and will remove the ones that crash on launch immediately.

Amazon rumoured to announce Echo UK launch on September 14

Amazon has sent out press invites to what’s rumoured to be the UK launch of its voice-controlled Echo device, which features the Alexa voice assistant. The event is scheduled to take place on September 14 in London, although it doesn’t mention the Echo. According to Engadget, if you ask Alexa what she has planned for the 14th, she replies “a visit to London.”

Google cancels modular Project Ara smartphone

Google has pulled the plug on Project Ara, its modular smartphone concept. Project Ara was designed to let users upgrade and customise their device with camera, speakers, microphones and other modules. According to Reuters, Google may consider licensing Ara to its hardware partners, enabling some of its features to appear on devices in the future.

Google to reveal Daydream VR and Pixel devices on October 4

Google will reportedly reveal its in-house design for a Daydream VR viewer device at an event on October 4. According to Android Police, the company will also show-off two Pixel-branded smartphones (which replace the Nexus brand) and a 4K Chromecast. The event will also provide more details on Google’s Amazon Echo-rival Google Home.

Qualcomm unveils VR all-in-one headset

Qualcomm has unveiled a new reference platform for standalone virtual reality headsets, which it’s calling the Snapdragon VR820. It’s built upon the Snapdragon VR SDK and is designed to help developers create the hardware, software and content needed to create VR experiences. It’s anticipated that it wil be available in Q4 2016.

Baidu launches open source machine learning project

Chinese search engine Baidu has released PaddlePaddle, an open source software platform for the deep learning community. According to Baidu, the platform provides an intuitive interface for data handling and specifying model structure. PaddlePaddle was originally developed for internal use on Baidu’s deep learning apps.

HP announces machine-learning tool for drag and drop app development

HP has announced Haven OnDemand Combinations, a new tool that combines machine learning APIs and a drag and drop interface for mixing and matching them. The tool is built upon HP’s Haven OnDemand could platform, which has 70 AI APIs and more than 180,000 users. HP says the new tool is the quickest way to add intelligence to apps.

Unreal Engine 4.13 released

Epic has released the latest version of Unreal Engine, bringing over 145 improvements to the game development platform. Major new features include shadow map caching for movable lights, a new live recording feature, Voronoi noise for material creation, new mesh decals and new VR features such as project templates and support for mesh and foliage painting with VR controllers.

Google releases pure JavaScript Closure Compiler

Google’s Closure Compiler is now available in pure JavaScript. Closure Compiler is a JavaScript optimizer, transpiler and type checker. This new version isn’t a rewrite in JavaScript, says Google, but rather compiles the Java source to JS to run under Node.

Bloomberg releases BuckleScript optimising compiler

Bloomberg’s tech arm has announced BuckleScript, a new optimising compiler strongly inspired” by TypeScript. According to Bloomberg, BuckleScript offers an “industrial strength” type system and provides strong type inference, to generate more efficient code. Bloomberg adds that the compiler is at least 10x faster than TypeScript.

HTC invests $5 million in VR start-up Steel Wool

VR gaming start-up Steel Wool Studios has closed a $5 million round of funding, coming entirely from HTC. Steel Wool was one of the early developers for HTC and Valve’s Vive headset, creating the action strategy title Quar: Battle for Gate 18. Steel Wool said the funding does not mean their games will be exclusive to the Vive.

Intel acquiring drone start-up Movidius

Intel is buying Movidius, a start-up that makes computer vision processors used in drones and VR devices. Intel says it wants to combine Movidius’ technology with its RealSense depth-sensing camera tech, covering markets such as VR, AR, drones and digital security cameras. The terms of the deal were not disclosed.

Categories
Languages

So… is HTML really a programming language?

Earlier this year we polled more than 13,000 developers during our biannual Developer Economics survey (updating now), and 11% of those developers told us that HTML is their primary development language – that’s Hypertext Markup Language to the uninitiated. This response immediately begs the question: can HTML really be considered a “programming language” at all, or if we should consign to being a tool for the layout of JavaScript functions?

promo

Which is your favourite programming language? Take the DE survey and be the judge of which language will sit on the throne.

Developers answering our survey were asked to pick from a list of languages, HTML5 was on that list, along with JavaScript and more-traditional languages including C and Java. Most programmers work in more than one language, so perhaps those who selected HTML5 as their primary language really meant that they were JavaScript programmers who used a lot of HTML? It’s a nice thought, but the idea breaks down when look at those additional languages and see that only 13% of those who said their primary language was HTML admitted to also using JavaScript, so how are these people creating applications?

14% said they also use ActionScript, which can also come wrapped in HTML, but 12% of those primarily using HTML said they also program in C/C++, which is a combination we’re unlikely to see in the same project.

HTML was never designed as a programming language – the original 18 tags permitted the most-basic of layout options. The only interesting tag was the hyperlink itself; the revolutionary concept that created the web as we now know it, the rest are trivial. HTML was based, loosely, on SGML, which is another bastard offspring of XML – the eXtensible Markup Language – but the key word across these is “markup”: all three are intended to provide syntactical data to accompany textual information*, not applications as we know them.

But HTML has come a very long way since then, and has capabilities we would normally associate with a development language. Drag and Drop, Geolocation, and Local Storage, are blurring the line between applications and web sites, allowing cross-platform development where the only way to spot the difference is the title bar at the top of the window (and sometimes not even then), and there are a host of applications which bear testament to the fact that HTML can be used to create real applications.

Zero Lines JS is a fine example. A graphical game, requiring the player to navigate their ship between approaching enemies at increasing speed to a suitably-irritating soundtrack. It might not be the next Watch Dogs, or even the next Candy Crush Saga, but it would be hard to deny that it is a real application and one which (as the name infers) is written entirely in HTML with a few Cascading Style Sheets (CSS).

Less gaudy is the aptly named “You Don’t Need JavaScript for That”, which demonstrates various techniques to accomplish programmatical tasks without recourse to programming languages. Examples include a tabbed panel (bringing content to the front based on the selected tab) and an image slideshow, all done entirely in HTML5.

Purists will moan, of course, that these examples don’t make it a “real” programming language, that HTML is nothing more than a markup language made to enrich documents, and there was a time when that was true. Developers aren’t as hierarchal as they used to be, but those closer to the metal still look down on those who’ve traded an intimate knowledge of the hardware for speed of development. C programmers consider objects to be unnecessary fluff, but concur with users of C++ that anything which isn’t run through a compiler is just improper (and that includes Java with its bytecode nonsense). Java programmers consider anything without proper encapsulation to be faking its object orientation, while JavaScript developers see no reason for strong typing, and consider HTML to be a layout tool.

Meanwhile those versed in Assembler look down from their ivory towers, stroke their beards, and concur that when performance really matters they will always get the gig.

But despite being at the bottom of the heap we can see that HTML5 is being used to create applications, and it must therefore be considered a programming language. We might argue whether validating a filled-out form constitutes an application, but when you can crash a spaceship into an oncoming armada then there’s little room for discussion.

At Vision Mobile we’re currently updating our survey, asking developers what language and tools they’re now using, including those who choose to program in HTML. It will be interesting to see if an increasing number think that the layout tool has evolved, or if a momentary fad is passing. Take a look at the survey, and use the feedback from at the end to let us know how you feel about HTML being included in the list of languages, and what you think might end up on that list next time.

* To be accurate, XML is intended to be a framework from which one can derive markup languages, but that’s not really pertinent here.

 

The Developer Economics survey is now Live.
Have your say in which should be the next most popular programming language and you may win amazing prizes and gear. Discover more.

Categories
Languages Platforms Tools

Why JavaScript will win on mobile

javascript will win on mobile

JavaScript is not the world’s most elegant programming language. So much so that one of the world’s top experts on the language wrote a book about “The Good Parts”. The book carries the headline “Unearthing the Excellence in JavaScript” because that excellence is quite deeply buried. Even so, it has rapidly become one of the most popular languages in the world. That popularity is deserved, because despite the flaws in the language, JavaScript gives developers significant advantages that they can’t get with other languages. Some of those advantages were created when browser vendors agreed to standardise on JavaScript (OK, technically ECMAScript) as the language for the web. Others are inherent to the web app programming model and more yet have been created through tooling enhancements. However, despite the fact that native apps are dominating web apps on mobile devices, JavaScript’s advantages are steadily transferring to mobile. Will it eventually dominate there too?

why-javascript-will-win-on-mobile

Popularity not priority

The latest TIOBE Community Index has JavaScript in 6th place amongst all programming languages and rising. The TIOBE method of ranking tends to favour older, more established languages and is not so quick to pick up trends. By contrast, the Redmonk rankings have JavaScript in first place. The Redmonk method is somewhat biased towards languages with strong open source communities but more accurately reflects current interest and trends. Our own Developer Economics surveys have shown that [tweetable]HTML5/JavaScript combination is the second most popular language amongst mobile developers[/tweetable] with 55% using it, just narrowly behind Java (at 57%). However, even if we combine those who prioritise HTML5 and JavaScript (19%), they’re still a long way behind Java (29%) on this metric. It seems likely this is going to shift significantly over the next few years. [What do you think? We have a new survey out, so take the survey and let us know your thoughts]

JavaScript breaking free from the browser

This is not a standard “the web will win” argument. I don’t believe that browser or webview-based apps will eventually dominate on mobile devices. Use will grow but they won’t be the norm. If true open web standards are to dominate in the future then they need to move on from the Document Object Model (DOM). The DOM is a base for building documents, not apps. Of course you can build an app around a platform originally designed for documents but you’re starting from a position of handicap. Look at the modern frameworks that allow you to build fairly performant apps for mobile browsers/webviews: React.js, Famo.us and Ionic. All three share the common feature of touching the DOM as little as possible.

Yes, there’s WebGL (or HTML5 Canvas if you must) too but those are low level graphics APIs. You need large, probably multi-megabyte, frameworks on top to create a good platform for building most apps. That’s not a good fit for the web app programming model, where the latest application code lives on a remote server, particularly not in a mobile environment. It’s true that you could have a hybrid app with a large framework on top of WebGL stored locally and just fetch the application specific code from the server but then why use the browser at all? Why not just JavaScript on top of some other cross-platform framework built for hardware graphics acceleration (hint: Qt has a nice offering here). One with a higher level API so there’s not so much overhead bridging between languages. Perhaps also one that’s less restricted when it comes to accessing device specific functionality.

There are now a couple of really interesting new options that fit this description, React Native and NativeScript. These work in different ways but both build apps with a native UI using JavaScript. Appcelerator’s Ti.Next may also be interesting, although they’ve been talking about it for a couple of years without an actual release yet, so we’ll wait and see.

The JavaScript exception

Here is where Apple has restored JavaScript’s advantage on mobile. A key thing that has prevented most developers from adopting an agile, web-style continuous delivery model on mobile is Apple’s ban on code downloading. Without that iteration is significantly slowed and split testing is much harder to do. This effectively means developers, particularly startups, learn slower. Until very recently, the only ways to get more rapid iteration were to go Android first, or build a hybrid app, since Apple made JavaScript downloaded in a webview an exception to the code downloading rule. In the first case it means moving away from the platform with the most early adopters. Unfortunately in the second case the UX trade-offs are too great, with most developers that went that route for a consumer app failing or switching to native. But in iOS 7 Apple added the JavaScriptCore interface to their own JavaScript runtime and in the latest iOS Developer Program License Agreement they modified the exception to code downloading rules to include JavaScriptCore.

This makes sense from a security perspective. Apple can audit and update their own runtimes, whereas if they allow 3rd party runtimes to download code they have no effective way of monitoring or dealing with security issues. Since JavaScript is Apple’s only scripting option and they can’t allow native code downloading, JavaScript is restored to a privileged position – the only option for those that want to iterate fast. The availability of JavaScriptCore triggered efforts like React Native and NativeScript and the timing of Apple’s relaxation of the code downloading policy has been perfectly timed for their public release.

Will open win?

Web advocates sometimes suggest that the open-standards-based web must eventually win because open always wins in the end. However, Linux is a very clear case where an open ecosystem thrives without a committee agreeing standards. With React Native, Facebook appears to be very rapidly building a developer ecosystem around their open source project. Already having a rapidly growing community around React.js obviously gives them a headstart but the NativeScript team at Telerik are working with Google such that Angular 2.0 should integrate seamlessly. Google are going to support non-DOM environments whether the web standards go in that direction or not. Microsoft and Google might take a long time to agree on the standards they’ll implement in their future browser versions but they’re working together on TypeScript, to make it easier to build complex apps with JavaScript (it turns out compilers are much better than people at spotting type mismatches).

Apple has built some fairly impressive tooling for their new Swift language, particularly the interactive playgrounds. However, Facebook possibly already has a better developer experience with React Native in terms of immediate feedback and rapid cycle times whilst coding. Apple will continue to iterate on that tooling alone, whilst the developer community can now enhance the tooling for these new JavaScript environments. Android may technically be open source but it’s not open in terms of community contribution. Google are enhancing the Android platform and tooling alone. [tweetable]Perhaps it’s really open developer communities that win[/tweetable] and genuine open source based communities can iterate faster than open standards based ones. For these “native UX built with JavaScript” environments to succeed, the platforms don’t have to lose. Apps will still be tailored to the platform look and feel and adopt new platform-specific APIs.

Javascript will win on mobile.

At the moment it looks like the very open JavaScript developer community will win because they get to build apps with native look, feel and performance but a web-style development experience. The closed platforms also win because apps are still being tailored for their captive ecosystems. For now, open web standards lose. It seems likely they can only win if the mobile browser vendors can agree to new standards that enable the creation of apps that genuinely offer an equivalent experience to native ones.

Update: Where we right in our predictions? Here is a latest update on the popularity of Javascript.

What do you use?

Do you think JavaScript will dominate on mobile in the future? Or Java, Objective-C and Swift will continue to lead? What about for the Internet of Things, or on the backend via Node.js? Let us know what you’re building your apps with by taking our survey.

Categories
Tools

Comparison of 4 popular JavaScript MV* frameworks (part 2)

javascript mv*

In the first part of our JavaScript MV* framework comparison we introduced AngularJS, Ember, Backbone.js and the newcomer React, we showed some code examples and discussed their strengths and weaknesses. In this second part we are going to have a look at their market share, community support and estimated growth to help you make the right decision for your SPA.

Javascript frameworks

Market Study

The following table lists the 4 frameworks alongside the year they were introduced, their origin or enduring dependency, their main contributors and an overview of popular sites using them. It’s worth noting that every single one of these frameworks is run by (or mainly used by) one of the big players of the web:

  • Ember is used by Yahoo!
  • Angular powered by Google
  • Backbone is used to realise WordPress.com and is a part time project of Jeremy Ashkenas, currently employed by the New York Times
  • React is introduced and powered by Facebook

While the bare listing clearly illustrates project maturity it does not give any indication about general popularity. Stats generated by web crawlers are usually not very accurate when it comes to back-end frameworks, but in our case – where frameworks are client-side and, needless to say, detected by every web client – those stats can be pretty sound.

Comparing wappalyzer.com with similartech.com and builtwith.com we received significantly different results. To display the results in a more convenient way we recalculated the total numbers to relative percentages. According to builtwith.com, React is used 74 times in the TOP 1 million websites while wappalyzer.com detected 18.582 usages in the entire web for the same framework as of this date. Still, it is possible to get a general idea of the market penetration of these Frameworks. All sources show Angular and Backbone being by far the most used frameworks – similartech.com does not even list the other two since their marketshare is too small to bother. Interesting to note that Backbone.js is used more in the Top 1K sites than in the Top 1M sites according to builtwith.com.

For you as a developer it might be more interesting to have a look at the community built around each Framework as it might reflect the amount and speed of support you will find for your upcoming projects. Therefore it is always a good idea to have a brief look at the few occasions where the community activity is shown. Since every project here is listed on GitHub a brief extraction of their stats should be helpful.

Angular was the winner of our part-1 comparison. It’s no surprise to see Angular again as one of the two most popular frameworks. While it almost reaches Backbone’s popularity it surpasses all competitors from the developer community site: Most stars, most contributors, most watchers, most issues (judge yourself if that’s good news), and a large amount of commits. When it comes to this kind of stats the number of git commits since the initial deployment plays a huge role: Ember, for instance, has the most commits. Impressive! But keep in mind: Ember had six more years to collect these commits compared to React. Taking things into perspective, React has more stars (already) than Ember although it is barely out of its childhood compared to the other almost ancient players.

Despite not being visualised here Stackoverflow.com displays Angular in the best possible light as it counts more than the double amount of posts than Backbone and Ember together and over 65 times more than React!

We do realise this is a snapshot in time and might well be outdated by the time you read this post. Which leads to the following question: Which of those frameworks is worth investing in the (near) future? The question is especially relevant for React as its popular contributor Facebook is well-known for the ability to establish new technologies, be it software (Hadoop) or hardware (open compute). Are we close to witness a new star rising on the MV* Framework horizon?

Google Trends has always been a faithful companion to get an idea of how popular a topic is and, by looking at the development over time, how popular it might be in the future. While different search terms around the same topic might bring different results, you can still get a general idea for each framework. The fact that these terms appear around the same time the frameworks were introduced proves our point as being representative, at least to some extent.

What this graph for sure does is manifesting Angular as the most popular Framework. Moreover, fascinating to note, Backbone’s popularity seems to be stabilized or even decreasing over time. Same can be said by looking at Ember. Are they already over their peak and now losing momentum? While Backbone’s market penetration might already be too deep to just disappear from the market, fate seems uncertain for Ember.

No doubt, the most astonishing trend is React’s. While writing this blogpost, we had to rewrite this section three times in two months:

December 2014: Backbone and Ember are closely followed by React. =>Respect!
January 2015: React catching up and passing by its competitors. => Impressive!
February 2015 (partial data!): React’s popularity outruns Backbone and Ember by far and is the runner-up to Angular. => Speechless!

According to Google Trends, React has risen from zero to a fourth of Angulars popularity within 1.5 years without showing any kind of flattening of their popularity curve. If React keeps up its progress we might see a new rival of the popular Angular at least as far as the View component of the MV* frameworks is concerned.

Categories
Languages Platforms Tools

Comparison of 4 popular JavaScript MV* frameworks (part 1)

javascript mv*

Finding a comprehensive comparison between any kind of JavaScript Frameworks, Libraries or Extensions is not hard these days. Especially when it comes to JavaScript MV* Frameworks, which are used to develop single-page applications (SPAs), and their notorious representatives, i.e. AngularJS, Ember, Backbone.js and newcomer React. A simple Google Search offers a plethora of technical comparisons to choose from.

mv-frameworks

Which are your favorite and worst frameworks? Take the survey, let us know and you can win awesome prizes and gear.

What they don’t usually mention, though, is the overall features those frameworks provide and how they compete for different use cases. Moreover, it is sometimes difficult, if not impossible, to find information on the origins of those Frameworks, i.e. how they have developed in time and, most importantly, how they will develop in the future.

This article is part 1 in a 2-part series, and will focus on comparing key features from some of the leading JavaScript MV*frameworks. In part 2, we’ll give you some insight on market-related qualities, followed by a conclusion.

Features Comparison

To get our comparison started, we will focus on the heavy-weight and most promising features you, as a developer, expect from a JavaScript MV* Framework.

Dynamic UI Binding

Dynamic UI Binding is not just passing data to our View or template at page load. You want to automatically have the View update when the data of the underlying Model changes. That being said, you may want to have a look at the following jsfiddle examples to get an idea of the huge improvement provided by dynamic UI binding over traditional server-side static data binding.

Ember.js:

Ember uses Handlebars as the default templating engine. To update a value, which is bound to the UI, you have to use a specific setter method on your Model while Handlebars takes care of rendering your page. Additionally, Ember offers much more binding options, such as its capability to have your Model in either a one or a two-way binding mode between a View or even another Model.

Angular.js:

In contrast with Ember’s approach, Angular.js allows you to use UI binding at plain object or even property level. At the end of every code execution, $scope.$apply() is run to check whether the value has changed and calls $scope.digest() to update your bindings. This may seem like a possible performance issue at first glance, but bear in mind that it allows you to update more than one binding simultaneously without requiring time-consuming DOM updates after each setter call. So the DOM rendering is triggered only once after you updated as many of the Model’s properties as you wish rather than being triggered after every single value change, like in Ember’s setter approach. Having all the magic happen in $scope.$digest() you don’t need to call your UI-Binding-Buddy yourself and even the $scope.apply() call is handled by Angular automatically (e.g. after events, controller init, http callback, etc).

React:

One of React’s rich UI Features is the straightforward linking of states directly to the UI. Since the UI is thought of as the representation of different states of a React Component, you just have to manage your states with the magical #setState(state, callback) method. The state parameter is passed as an object and will be merged into the internal state reference of your React Component. Meanwhile, React takes care of all the updating and re-rendering of your interface using the render method. The callback parameter from setState is optional and can be registered so you are informed after the UI update.

Reusable Components

While all frameworks provide out-of-the-box functionality, you will inevitably end up with a lot of custom code. Assuming you are developing more than one applications, you would like to be able to reuse that code, right?

Ember.js:
Ember is making use of a widget-based approach called Ember Components. It enables you to write your own ‘application-specific HTML tags’ using a Handlebars layout and the power of Ember’s backend infrastructure. Your custom element can be used in any Handlebars template you want. Keep in mind, though, that this is only possible at View level, while Controller level reuse is not supported by the Framework.

Angular.js:
Similar to Ember, Angular.js provides the ability to create custom HTML tags. Reusable components in Angular are called “directives” and are significantly more powerful than Ember Components. In fact, you will be able to create your own semantic and reusable HTML syntax using those directives. On the other hand, you may also make use of Angular’s extend or mixin system like in Backbone.js and React.

Backbone.js and React:
The way Backbone.js and React solve reusable components is not new, yet it is very reliable. They both use the mixin system for code reuse. You may know this feature already from the dojo toolkit and might remember how powerful mixins can be. Both Backbone and React let you use mixins at view or even controller level, so that your components are not forced to be UI-related and may contain just some utilities or even complex program logic.

Routing

The simplest routing infrastructure a MV* JavaScript Framework can offer is mapping functions to URLs, similar to their server-side relatives (e.g. Grails, Spring, ASP.NET, CodeIgniter). For Single Page Applications (SPAs) a URL is whatever follows the hashtag (or might even be full path assuming HTML5 push-state is enabled). This routing functionality is essential for any self-respecting SPA.

Ember.js:

The routing in Ember.js is quite intuitive, since you do not even need to provide a path for your route, as long as you follow the naming convention. You just provide the View and an optional Model to the route and there is no need for any kind of controller (as exhibited in the Fiddle above), unless you are planning to do some advanced stuff in your application.

Angular.js:

In contrast to Ember’s convention-over-configuration routing mechanism, Angular.js requires a template and even a controller to its router configuration. You have to manage your template and controller manually – but you can do that almost without restrictions.

Backbone.js:

Similar to Angular.js you provide a View with a Template for your route. The actual replacement of the DOM is done manually by instantiating the View and updating the DOM in your container node with the rendered view template. At the end of your routing configuration you just have to tell Backbone to listen for URL changes with the command Backbone.history.start().

Pit Stop – Concluding the Feature Comparison

It is quite unfair to compare React with the likes of Ember, Backbone and Angular. First and foremost, React is new, while the latter are already established frameworks in the MV* universe. Secondly, React is not a framework, but rather a View engine – even though it competes extremely well in terms of features. In fact Facebook explains it better: “React is mostly used as the V in MVC”.

Let’s look again at our JavaScript MV* candidates.

Backbone doesn’t provide UI binding and does a really good job at reusable, components but loses some of its fanciness when it comes to Routing. Ember offers a slick routing mechanism, keeping things clean and simple by introducing naming conventions. Its UI Binding concept and use of Handlebars, which provides you with very nice benefits, is flawless. The only thing Ember lacks is the reuse of components at Controller level.

To conclude, Angular is our winner – so far. The approach of extending HTML with custom syntax, the easy-to-use data binding features combined with the power of mixins or extends and a clear routing mechanism makes Angular more than just a swiss JS-Knife. With its high abstraction level and a bunch of features it may be the choice for a full featured CRUD application – client sided.

Stay tuned to find out more about how our rivals compete in market penetration, community support, their estimated future usage and, of course, our final conclusion to help you back the right horse for your SPA.

 

In the meantime, tell us more about what you love or hate for each framework and you might win cool gear. Take the Developer Economics Survey.