Cutting-edge or standards-based Web programming?

The following article represents my position on using cutting-edge web programming techniques, vs. the techniques that are well established and supported and standard based. I’ll investigate the benefits and merits, as well as weaknesses and risks that come with both approaches. 

Cutting Edge Web Techniques

For some of us, it may feel like the field of web development hasn’t transformed much since its inception. At the end of the day, it still boils down to HTML, CSS, and JavaScript, and what drove the Internet in 90’s, still drives the functionality and look of all websites today. That’s a valid argument, which may still give us an impression that nothing has changed in a very long time. But the feeling is deceiving. There are numerous shifts in the field of web development, and programmers who are learning web coding today, have a rocky road ahead of them.

To illustrate the fact that using cutting-edge techniques can indeed become a challenging and confusing journey, I’ll concentrate on what’s new in the field of Javascript development. The write up below is inspired by the work of Jose Aguinaga, who recently published an article on how it feels to apply the JavaScript skills in 2016 (Aguinaga, J., 2016).

First of all, let’s imagine that you’re a new web developer entering the field of coding today (some of us are). The goal of your task is to get the data from the backend and display it in your HTML web page. Simple right? All you need is to import one library, namely jQuery and the work is done.

Well, not so fast. You will learn that web development community is not using jQuery, they’re using a fresh new Facebook library called React to accomplish such tasks. Why? Well, because jQuery comes with some technical issues, and is no longer considered to be as fancy as it was just a couple of years ago. So you’ll go with the flow and decide to use React.

Only then you realize that using React is not as simple as using jQuery because React needs React DOM to manipulate the HTML DOM. So two libraries instead of one? That’s not a problem; you can easily work with that. However, people who use React tend to describe HTML DOM by using JSX. As a new programmer, you’d be probably be asking: ‘Why? There is nothing wrong with HTML!’.

Well, you can use React without JSX, but JSX makes React a lot more elegant because it feels more like XML. But that is not the end of the story because React needs a Babel library, which doesn’t necessarily have to be used, but if you don’t use it, you won’t be able to transpile your JavaScript towards a particular version of JavaScript. And that means you’d be trapped in using ES5 and won’t be able to use advantages of ECMAScript 2016 (ES7) language. What’s ES7? That “is the seventh edition of the ECMAScript Language Specification and has grown to be one of the world’s most widely used general purpose programming languages. It is best known as the language embedded in web browsers but has also been widely adopted for server and embedded applications.” (International, E., 2016). That said, if you don’t use Babel, you won’t be able to gain the advantage of “Array prototype includes and exponentiation operators” (Grzybek, P., 2016), nor async and await calls, that are the new shiny features introduced in ES7 language. So now, you need to include three libraries just to fetch some data and display it on the page, right?

Nope, it doesn’t end here because it’s recommended to use some package manager (AMD or CommonJs) to do so. What is a package manager? Well, it allows you to describe how JavaScript libraries will cooperate.  So, finally ready to go? Not yet, you may want to bundle your libraries by using Browserify, which allows you to describe dependencies to files that can run in the browser. Browserify was created because most people publish those dependencies in the NPM registry. What is npm? Well, npm “makes it easy for JavaScript developers to share and reuse code and to update the code and check to see if any updates were made to any of the libraries. It also provides and easy way to download those updates when they are made.” (What is npm, 2016). So, it’s like Bower, but better and that is why Bower is fading in popularity. Npm “serves over a billion downloads per week, and that only counts package installations that weren’t already cached. Npm’s growth is truly, without exaggeration, exponential.” (How many npm users are there, 2016).

Now all you need is to use a task manager, such as Grunt, Gulp, Broccoli or Mimosa? No, that’s no longer a ‘standard,’ people don’t even use Makefiles anymore, they wrap everything using Webpack, which is like Browserify on steroids.

One may feel that a lot is going on with React, but diving deeper into what’s new in JavaScript, you’ll see that some developers don’t like React, they prefer EmberJS, Knockout, Polymer, Riot, VueJS, or a Google sponsored Angular framework. But because Angular 1 just switched to a new version Angular 2, they’re moving to Angular 2, which is starting to make waves in the web development circles.

So, is this the end of the story? Not yet, just as we were to conclude the section, Typescript comes to picture. What is TypeScript? Well, “it allows you to start from the same syntax and semantics that millions of JavaScript developers use today, but Typescript enables JavaScript developers to use highly-productive tools and practices like static checking and code refactoring when creating JavaScript applications. TypeScript offers support for the latest and evolving JavaScript features, including those from ECMAScript 2015 and future proposals, like async functions and decorators, to help build robust components.” (Green, B., 2016)

So, let’s recap our journey. In 2016, if you want to get the data from the backend and display it in your HTML web page, you need to know about new web development frameworks and techniques. Some of the ones we’ve mentioned are React, EmberJS, VueJS, Knockout, Polymer, Riot, TypeScript, Angular 1.x and new Angular 2. And you will likely need to be aware of JSX, ECMAScript 2016 (ES7), AMD, CommonJS, Babel, Webpack, Makefiles, Bower, Browserify, Gulp, Grunt, Broccoli, Mimosa and Npm as well.

Please note, that neither jQuery, Angular and npm are no longer something we can bundle under the category of emerging technologies… the list above is an actual reference to what’s emerging…

  • jQuery goes back to August 26, 2006; so it’s over 10 years old and today it’s the most popular JavaScript library in the world, with installation on 65% of the top 10 million highest-trafficked sites on the Web.
  • And the same goes to Npm, which serves over a billion downloads per week. It has been around since January 12, etc.2010 and today npm is the default package manager for the JavaScript runtime environment and the most popular one.
  • And the same goes for Angular :) It’s one of the most popular frameworks today… +300k websites are designed using Angular, including The Guardian, Paypal, Netflix, Vevo, PS3 YouTube,,, etc.  Angular 2, on the other hand, would be an excellent example of emerging technology.

That said, it’s my opinion, that the frameworks (or solutions) of above magnitude shouldn’t be considered as emerging. These are rather well established already, in fact, some of them, such as jQuery might already be on their way out.


Sometimes, the well established, standardized solution is the safest and fastest way of accomplishing the business task. Many times, going with a new and cutting-edge framework comes with a lot of risk, huge learning curve and could become a very costly.


Standards Based / Well Established


Seeing how complicated it may be to use cutting edge techniques, should we simply always settle on well established and standardized solution? It’s hard to say.

To illustrate the fact that using standard based web development framework can become a risk, I’ll paint a fictional business decision where business has to decide between using Angular 1 or Angular 2 in a multi-million dollar project.

Which one to use? A brand new shiny Angular 2 or a well established Angular 1?




Angular 1 has standardized web application structure and provided everyone with a future template of how client-side apps should be developed. Thousands of companies and millions of developers are using Angular 1.x in their projects. There is an excellent support for the product. Any issue that may be encountered can easily be resolved with the help of Angular 1, and its very vibrant community. That said, Angular 1 seems like an obvious choice.


The problem with Angular 1 is related to it’s aging code base; that dates back to 2009. Right now the development community is looking at the Shadow DOM and ES7 modules, things that didn’t exist in 2009. And that means, that designing the application with Angular 1 may come with risks, mostly because by the time our fictional business releases their multi-million dollar application, Angular 2 will most likely be already established and most companies will move away from Angular 1. It could resolve in a possible rewrite of the application shortly after its general release (assuming it takes well over a year to develop).

Another important thing to consider is the learning curve and time that it takes to code an Angular 1 application. Angular 2 uses the Simple Cognitive Model that isn’t present in Angular 1, thus In Angular 1 many concepts come with a steep learning curve. It could prove to be a problem, as newly hired programmers would likely spend days learning about all of the different concepts of Angular 1, such as a controller, factory, service, provider, directive, transclusion, module, etc.

In Angular 2, the motivation seems to be a simple cognitive model, where all concepts were considerably simplified, forms and validation were changed, as well, and entire Angular 2 is entirely component based now.




Let’s start with disadvantages first. Angular 2 was announced in 2014. In 2015 it went to Alpha, and in December 2015 it reached the beta stage. The general and final release of Angular 2 was published in September 2016, less than two months ago. Going with a platform as untested as Angular 2 is, would come with many risks, mainly due to lack of support and non-existent community. Inability to fix the issues in a new platform could become very costly.


In Google’s words, they are already migrating several large projects into Angular 2, for example, AdWords, Fiber, etc. which provides us with a certain confidence when it comes to Google’s own trust of the tool.

Angular 2 parked itself on top of web standards (ECMAScript standard) instead of the old way where Angular 1 was generating a standard of its own. For example, with Angular2 we don’t need things like transclusion because that’s what the Shadow DOM does. And it provides it natively. Note: The Shadow DOM denotes the ability of the browser to include a subtree of DOM elements into the rendering of a document. In Angular 2, ES6 modules replace Angular Modules and thus Angular 2 is pushing for TypeScript. TypeScript is an extension of ECMAScript (TypeScript = ES6 + Types + Annotations). TypeScript being actually from Microsoft it also means Angular 2 will likely get more traction in the future and will become very popular. The bottom line, Angular 2 wants to play nice as the web evolves.

But there are other pros, such as licensing, where Angular 2 is MIT licensed, meaning that Angular 2 and all its connected libraries, code snippets and examples are already moved to one of the best licensing models, the MIT license.

Additionally, the Angular 2 is designed from the ground-up for mobile and optimized for memory efficiency and fewer CPU cycles, which could be beneficial when a business decides to move their application to mobile devices.

And finally, we come to performance. The speed of the application is, of course, imperative. Angular2 in alpha was already 5x faster than Angular 1. Angular 2 in beta was already 5-10 times faster than Angular 2. Recently the Meteor team did a front-end frameworks performance shoot-out and Angular 2 came out first, overtaking React and every other framework.




While in most of the cases, well established, the standardized solution is always a safe bet and the best choice. Sometimes, such as in the case of our fictional Angular 1 vs. Angular 2 business decision, going with a new cutting-edge framework and programming technique can come with so many benefits, that they outweigh the associated risks.  In this case, we’ve learned that not only Angular 2 is a lot speedier and plays a lot better with web standards used by all browsers. But it is also generally easier to code with and train for. Additionally, the rewrite between Angular 2 and 2.x would be marginally less costly exercise as compared to rewrite between two major versions (going from Angular 1 to Angular 2). Thus going with Angular 1 could end up being an expensive exercise and Angular 2 would likely win the race.





Jarosciak, J. (2016) Angular 1.x or angular 2 – what to select for your next project?. Available at: (Accessed: 6 November 2016).

Aguinaga, J. (2016) How it feels to learn JavaScript in 2016. Available at: (Accessed: 6 November 2016).

Build with react JS (2016) Available at: (Accessed: 6 November 2016).

International, E. (2016) ECMAScript® 2016 Language Specification. Available at: (Accessed: 6 November 2016).

What is npm? (2016) Available at: (Accessed: 6 November 2016).

Grzybek, P. (2016) What’s new in ECMAScript 2016 (ES7). Available at: (Accessed: 6 November 2016).

How many npm users are there? (2016) Available at: (Accessed: 6 November 2016).

Web development (2016) in Wikipedia. Available at: (Accessed: 6 November 2016).

Comparison with other Frameworks – vue.js (2016) Available at: (Accessed: 6 November 2016).

Green, B. (2016) TypeScript – JavaScript that scales. Available at: (Accessed: 6 November 2016).

Iffland, D. (2016) Angular 2 final released, adopts semantic Versioning. Available at: (Accessed: 6 November 2016).

HTML: The markup language (an HTML language reference) (no date) Available at: (Accessed: 6 November 2016).

Bresnehan, J.— (2014) Diving into Webpack – web design weekly. Available at: (Accessed: 6 November 2016).

Toronto (2016) The case for using angular 2 on a new project. Available at: (Accessed: 6 November 2016).

Andrews, J. (2016) What is gulp.js used for?. Available at: (Accessed: 6 November 2016).

Facebook Comments