Front End Development Blog

Google Is Taking a Big Step to Kill Off Flash for Good

STARTING TOMORROW, GOOGLE’S Chrome browser will automatically pause web ads that use Flash.

That means that videos and animations in ads using Adobe’s Flash technology will no longer autoplay in the world’s most-used browser. Ads using HTML5, on the other hand, will continue to work.

The decision, first revealed in June on Google+, is the latest nail in Flash’s coffin, which is great news for the web: Flash is a bloated, insecure battery hog, and it deserves to die.

Fortunately, Google doesn’t appear to be the only organization that feels that way. Last month, Mozilla blocked Flash from running on its Firefox browser until Adobe released a new version that fixed some particularly egregious security problems that were revealed in a leak of security company Hacking Team’s internal documents. Facebook’s chief security officer Alex Stamos also recently called on browser makers to stop supporting Flash altogether. In anticipation of that development, Facebook has slowly been replacing its own videos with HTML5-based alternatives.

Advertisers have been the big pro-Flash holdouts, but Amazon has said that it will no longer accept Flash advertisement on its network of sites. Google’s move to pause Flash ads is even bigger; it could be just the push the industry needs to finally move on to better technologies.

Posted by: Klint Finley


  • Flash is finally leaving us.
    Published by: Aaron Smith - Date: 2018-08-29

The problem with Angular

In the last six months or so I talked to several prospective clients that had a problem finding front-end consultants in order to help their dev teams get a grip on their Angular projects.

Although there are front-enders that are enthusiastic about Angular, I have the feeling that their number is surprisingly low for a major framework. I expected Angular to gain more traction than it has.

Angular is aimed at corporate IT departments rather than front-enders, many of whom are turned off by its peculiar coding style, its emulation of an HTML templating system that belongs on the server instead of in the browser, and its serious and fundamental performance issues.

I’d say Angular is mostly being used by people from a Java background because its coding style is aimed at them. Unfortunately they aren’t trained to recognise Angular’s performance problems.

I have doubts about Angular 1.x’s suitability for modern web development. If one is uncharitably inclined, one could describe it as a front-end framework by non-front-enders for non-front-enders.

The proposed radical Angular 2.0 rewrite aims to make it more palatable to front-enders, but I doubt they’re interested in yet another MVC framework. In addition, the rewrite will likely alienate Angular’s current target audience.

If you want to know why I think all of this I’m afraid you’re going to have to read this long article in its entirety.

Angular Server Pages

I feel that Angular’s fundamental proposition blurs the line between front end and back end. Take a look at this demo code example that I pulled straight from the horse’s mouth:

<div ng-controller="TodoController">
<span>{{remaining()}} of {{todos.length}} remaining</span>
[ <a href="" ng-click="archive()">archive</a> ]
<ul class="unstyled">
<li ng-repeat="todo in todos">
<input type="checkbox" ng-model="todo.done">
<span class="done-{{todo.done}}">{{todo.text}}</span>
<form ng-submit="addTodo()">
<input type="text" ng-model="todoText" size="30"
placeholder="add new todo here">
<input class="btn-primary" type="submit" value="add">

This code reminds me of a simple server-side scripting language such as JSP or ASP that’s used to fill HTML templates with database content. These languages have their place in the web development stack — but on the server, not in the browser.

Last month I gave a workshop at a large Dutch company. Their huge, sprawling website uses various widgets and design patterns that do the same job but aren’t derived from a common codebase but are copy-pasted throughout the site. This is clearly an undesirable situation.

They turned to Angular to solve this problem by including centralised widgets wherever they are needed. Although templating is the correct solution, doing it in the browser is fundamentally wrong. The cost of application maintenance should not be offloaded onto all their users’s browsers (we’re talking millions of hits per month here) — especially not the mobile ones. This job belongs on the server.

Strictly speaking this is not a problem with Angular, but with this particular company’s implementation of Angular. However, it’s logical that Angular, of all JavaScript frameworks, gives rise to this problem. Its JSP-like qualities are designed to allow, even encourage, such behaviour.

Angular’s target audience

Angular is aimed at large enterprise IT back-enders and managers who are confused by JavaScript’s insane proliferation of tools. In an excellent article, Andrew Austin makes the case for Angular in enterprise IT:

There are many positives about the AngularJS team all working for Google. For one, having one commercial entity control the framework can often be a positive because it completely avoids infighting between political factions. In the open source world, this infighting can be public and nasty, detracting for the team's purpose of building great software.

Enterprise IT managers want well-maintained code backed by a large company so that they don’t have to worry about a sudden lack of support. In addition, Google has a good name in web technology, so if they push a JavaScript library it must be good ... right?

Enterprise IT managers also like the fact that Angular closely mirrors the preferences of their back-end developers. I had an illuminating Twitter conversation with Joe Pearson of, who told me that they had recently switched to Angular, mostly for the sake of their Java developers. Angular used a type of code structuring that was well-suited to them, though not to their front-enders. From my clients I also got the impression that their Java developers decided to use Angular.

In other words, in addition to appealing to their managers, Angular appeals to Java developers. The framework ties in with their conceptions of proper application structure. None of this is an accident. Google aims to conquer the enterprise market, and Angular is one of its tools.

Many front-enders, on the other hand, who have worked with JavaScript and browsers for years and have developed their own coding style, tend to have their doubts about Angular.

In itself this is not a problem: people should just use whatever framework ties in with their coding style. Unfortunately Angular’s issues go much deeper.

Performance problems

Take another look at the Angular demo code:

<div ng-controller="TodoController">
<span>{{remaining()}} of {{todos.length}} remaining</span>
[ <a href="" ng-click="archive()">archive</a> ]
<ul class="unstyled">
<li ng-repeat="todo in todos">
<input type="checkbox" ng-model="todo.done">
<span class="done-{{todo.done}}">{{todo.text}}</span>
<form ng-submit="addTodo()">
<input type="text" ng-model="todoText" size="30"
placeholder="add new todo here">
<input class="btn-primary" type="submit" value="add">

All code snippets in {{}} are Angular instructions. The problem is that there is no way for Angular to discover these instructions except by parsing the entire DOM, including all text nodes and attribute values — a very expensive process if there ever was one, especially on mobile.

Although it is not necessarily lethal for overall performance, parsing the entire DOM at load time is an issue that should be addressed. Unfortunately this neglect of performance seems to be representative of Angular as a whole.

This test report by the Filament Group is not very flattering to Angular. Although the authors are extremely careful to note that test results for a large, complex app may be more positive, the Angular version of their simple test app did not perform well. Neither did the Ember one; only Backbone stood out.

Steven Czerwinksi provides interesting details:

Each update spent a lot of time creating and destroying DOM elements. If the new view has a different number of lines, or any line has a different number of words, Angular’s ng-repeat directive will create or destroy DOM elements accordingly. This turned out to be quite expensive.

Although the article shows how to address this problem fairly simply, what worries me is that this non-performant mode is Angular's default. Front-end framework defaults should use established front-end best practices. Angular’s don’t.

Even Google seems to agree there’s a problem. The Angular criticism that resonates most with me comes from the What’s wrong with Angular.js article by Daniel Steigerwald:

Google does not use Angular in production for their flag apps like Gmail or Gplus.

Ouch. Thou shalt eat thy own dogfood.

These problems are undetectable to an average back-ender with little front-end knowledge. The framework works as advertised, it comes from a company that has quite a reputation in front-end technology, so the average back-ender will understandably assume that this is how things ought to be done on the front end.

The Angular way

The biggest problem for many front-enders seems to be that Angular forces you to work in one specific way. The Software Improvement Group published a report that states (my emphasis):

Using AngularJS provides developers with a number of advantages. [...] These advantages have contributed to the increased popularity of AngularJS and lead to higher productivity when used within AngularJS’ constraints.

The report lists this issue as a pro, not as a con. In a self-admittedly opinionated rundown of JS frameworks, Henrik Joreteg is more negative:

Picking Angular means you’re learning Angular the framework instead of how to solve problems in JavaScript. [...] I’ve got developers who’s primary skill is Angular, not necessarily JavaScript.

Because of the need to learn the Angular way of doing things, the framework has a steep learning curve. Ben Nadel, who is an Angular fan, and not a detractor, visualises it here.

In other words, Angular requires you to spend a lot of time to teach yourself the Angular way of doing things. Some will like that, but others will see it as an extra investment and pass on the framework.

What went wrong?

Why all these problems? What’s wrong with Angular? Rob Eisenberg provides an explanation:

When AngularJS was first created, almost five years ago, it was not originally intended for developers. It was a tool targeted more at designers who needed to quickly build persistent HTML forms. Over time it has changed to accommodate a variety of scenarios and developers have picked it up and used it to build more and more complex applications.

See this Hacker News thread for more Angular history.

I don’t think that a rapid-prototyping framework should be used for complex, enterprise-level production code.

But there’s more. The same article gives another cause for concern:

While Angular can be used to build mobile apps, it wasn't designed with them in mind. This includes everything from the fundamental performance issues I've already mentioned to missing capabilities of its router, the inability to cache pre-compiled views and even lackluster touch support.

That a five-year-old framework is insufficiently mobile-optimised is understandable. Mobile simply wasn’t an issue back in 2010.

However, it’s not 2010 we should be looking at, but 2012. As far as I can remember, Google started pushing Angular in mid-2012. (That date is supported by this July 2012 article, which I think is one of the earliest to mention Angular.)

At that time, it was already clear that Android was going to be crucial for Google’s future, so it would make sense that the tool you push supports your future platform ... wouldn’t it?

I wonder what Google was thinking when it pushed a framework that wasn’t originally intended to assist developers, contained serious DOM performance problems, and wasn’t optimised to support its own mobile platform.

Right hand, meet left hand.

Angular and front end

Don’t get me wrong: there are front-enders who are enthusiastic about Angular. Module repositories and best practices sites exist.

My point is that I expected far more front-enders to embrace Angular. I have the feeling their number is surprisingly low — see also the problems my clients had with finding good front-end Angular consultants. Why is that the case?

Part of the answer is the possibility that Angular was designed to cater to the tastes of Java developers over JavaScript developers. That would turn off front-enders. Still, coding style is not language-exclusive, so this is not the whole answer.

A more important reason may be pushback from the JavaScript community. Angular has evoked some serious criticism. Alexey Migutsky summarises it best:

Angular.js is "good enough" for [the] majority of projects, but it is not good enough for professional web app development, [that is, an app] which is maintainable in [the] long run, performant in all reasonably modern browsers, has a smooth UX and is mobile-friendly.

I think he’s on to something. The long litany of complaints I summarised in this article, especially the performance issues, makes me doubt Angular 1.x’s suitability for modern front-end engineering. Angular either is a framework created by non-front-enders for non-front-enders, or it does an amazingly good job of hiding its front-end credentials.

That’s why I think Andrew Austin, who was quoted at the start of this article, is wrong when he states:

Compared to hiring jQuery developers, hiring AngularJS developers may be more difficult for an organization. [...] But don't worry, with each passing day more and more JavaScript developers are discovering AngularJS and they are using it to build real applications. [...] Rather than hiring developers with AngularJS experience, it may be easiest to train your existing team or hire JavaScript generalists interested in learning AngularJS.

For a front-ender, who’s used to doing things in a certain way, moving to the Angular way may be painful. In addition, they reject the performance issues that Angular causes. Angular insufficiently caters to frond-end sensibilities, so many front-enders tend to ignore it.

Back-enders do not have these problems. They have no preconceived notion of how front-end code is supposed to work, and aren’t trained to recognise Angular’s performance problems.

This is aggravated by a problem my Dutch client mentioned: in general, front-enders tend to dislike the enterprise because it’s perceived as boring — which is shorthand for corporate IT processes, endless meetings, taking weeks for solving simple problems, and so on. That thins the pool of available front-end Angular developers and consultants even more.

That’s why most Angular developers come from the back-end, particularly from Java. As far as I know this situation where a front-end framework is supported mostly by non-front-enders is unique.

Angular 2.0

The Angular team is not deaf to the complaints and concerns summarised here. In October it announced Angular 2.0, which would be a radical departure from 1.x. Angular users would have to re-code their sites in order to be able to deploy the new version.

It’s easy to understand why such a radical change is necessary. Giving Angular a serious performance boost requires ditching the {{}} DOM parsing at load time. In order to do so the syntax will have to change, and that will have serious consequences for the development process. I’d say Angular 2.0 will require developers to embed less application logic in their HTML templates, and more in their scripts.

I think that this radical rewrite is mostly aimed at front-enders, who will get much more performance and a coding style that is more in line with what we’ve come to expect of JavaScript frameworks.

However, this will come at the cost of alienating its biggest group of adopters. Enterprise IT opted for Angular exactly to be spared such sudden, critical changes. Adopting Angular 2.0 would require them to allocate massive amounts of budget to rewriting code that already works. Also, I wonder how people from a Java background will like new coding style.

For these reasons I think many enterprise users will stick with 1.x and ignore 2.0. Of course, Google will eventually stop supporting 1.x. Thus I think Google’s attempt at cracking the front-end enterprise nut with Angular is going to fail over the next two to three years.

While the enterprise IT defection could be offset by an influx of front-enders, Angular has meanwhile acquired a bad reputation among them. Besides, yet another MVC framework is not what the front-end world needs right now.

Despite its serious technical problems Angular 1.x is a success especially among corporate developers with a Java background. The 2.0 rewrite is aimed at front-end developers, but may not reach them, and in addition will turn off Angular’s current following. I don’t think Angular will survive the rewrite.

Posted by: Peter-Paul Koch

WebRTC, Online Code Editor Team Up for Real-Time Coding

It’s still going to be some time before WebRTC technology starts to deliver cool apps, but even today developers are quickly moving from the realm of cool WebRTC experiments, like the Mozilla/Google phone call demo, to useful apps like Codassium.

WebRTC is a proposed standard — currently being refined by the W3C — with the goal of providing a web-based set of tools that any device can use to share audio, video and data in real time. It’s still in the early stages, but WebRTC has the potential to supplant Skype, Flash and many native apps with web-based alternatives that work on any device.

Codassium uses WebRTC to bring together WebRTC-based video chat and Mozilla’s Ace code editor. The result is what Wreally Studios, creators of Codassium, call “a better way to conduct remote interviews.” Of course Codassium could be used for more than just interviews — think code reviews, remote pair programming or even just discussing code with remote employees.

To use Codassium you’ll need to be using a web browser that supports WebRTC — recent versions of Firefox and Chrome will both work. Head on over to Codassium, click the Start button and allow the site to access your camera and microphone. Once the video chat and Ace editor load, just click the Invite button and send the resulting link to the person you’d like to work with.

Posted by: Scott Gilbertson

Experimental CSS Shaders Bring Photoshop Filters to the Web

Chrome’s experimental Canary channel and Safari’s WebKit nightly builds both now support all of the Photoshop-inspired blend modes for CSS Shaders, part of

Adobe’s effort to bring Photoshop-style filter tools to the web.

To see the new blend modes in action, grab a copy of the latest Chrome Canary or WebKit nightly builds, enable the CSS Shaders option in about:flags and point your browser to Adobe’s sample code over on Codepen. Previously, CSS Shaders required a special build of WebKit [Update: As Adobe’s Alan Greenblatt points out in the comments, CSS shader support has been in Chrome stable since v25 (you still need to enable the flag). But if you want to play around with these new blend modes then you’ll need Canary (or a WebKit nightly).]

The new blend mode support is part of Adobe’s CSS Shaders proposal, which recently became part of the W3C’s CSS Filter Effects specification. There are two types of shaders in the spec, CSS fragment shaders, which provide features similar to what Photoshop’s blending modes offer, and CSS vertex shaders, which handle the 3D animation filters we’ve showcased in the past.

The blending modes currently available include all the familiar options you’ll find in Adobe Photoshop, such as multiply, screen, overlay, luminosity and other photographer favorites.

For more details and links to the corresponding specs, be sure to check out this post from Max Vujovic, who is working on the CSS Filters implementation in WebKit and Blink.

As the CSS Filter Effects specification progresses through the standardization process (and stabilizes), hopefully other browsers will add support as well.

Posted By: Scott Gilbertson

Web services are dead -- long live REST

Remember the heyday of Web services, when we were always just one specification away from perfect interoperability? Ultimately, that towering stack of protocols collapsed under its own weight. SOAP and XML generally are ridiculously verbose protocols that began with a commitment to simplicity and gave way to mind-numbing levels of complexity. Add to that the service repository mess: UDDI died an ignominious death, and OASIS's S-RAMP committee can't even create a website that isn't all broken links.

Interoperability Nirvana remains out of reach. What do we have instead? We have the registry called "the freaking Internet." Services are registered as URL handlers, and we execute against them. The XML transmission format was replaced by the format that your browser and mobile devices all learned to speak: JavaScript Object Notation. REST plus JSON over HTTP/HTTPS is the new Web services -- strangely, it's more interoperable without an explicit specification. Instead we make it work like the Internet, and DNS is your service registry.

We use JQuery/JavaScript/JSON for our UIs nowadays. We can even use Node.js for our business logic. Databases like Couchbase 2.0 and MongoDB speak JavaScript and JSON (or a direct derivative) natively. The beauty of this as an architecture is that we can drop entire layers of object binding and data transformation from our code.

By: Andrew C. Oliver


  • Plus the page won't refresh
    Published by: Aaron Smith - Date: 2015-04-17
  • This comment has been removed by the author.
    Published by: Aaron Smith - Date: 2015-04-17
  • I love REST APIs. Great article.
    Published by: web presence - Date: 2015-04-16

Responsive Web Design

"Responsive web design is the most common One Web approach. The approach uses CSS media queries to modify the presentation of a website based on the size of the device display. The number of responsive sites is rapidly increasing, from the Boston Globe to Disney to Indochino.

A key advantage of this approach is that designers can use a single template for all devices, and just use CSS to determine how content is rendered on different screen sizes. Plus, those designers can still work in HTML and CSS, technologies they’re already familiar with. Additionally, there’s a growing number of responsive-friendly, open-source toolkits like Bootstrap or Foundation which help simplify the process of building responsive sites.

On the other hand, there are few shortcuts to a sound responsive design. To go responsive, organizations often have to undertake a complete site rebuild.

The design and testing phase can be quite fussy, as it can be difficult to customize the user experience for every possible device or context. We’ve all seen responsive site layouts that look like a bunch of puzzle pieces that don’t quite fit together. Responsive web design works best in combination with a mobile-first approach, where the mobile use case is prioritized during development. Progressive enhancement is then used to address tablet and desktop use cases.

Performance can also be a bugbear for responsive sites. At Mobify, we recently completed an analysis of 15 popular responsive e-commerce sites. Among these sites, the home pages loaded an average of 87 resources and 1.9 MB of data. Some responsive pages were as big as 15MB.

The numbers are that high because a responsive approach covers all devices. Your user is only using one device, but they have to wait for all of the page elements and resources to load before they can use it. Put simply, performance affects your bottom line. On smartphones, the conversion rate drops by an extra 3.5 percent when users have to wait just one second. By the three second mark, 57 percent of users will have left your site completely.

While responsive design is fast becoming the de facto standard, it also creates new challenges for online businesses, including how to handle images, how to optimize mobile performance and often means sites need to be rebuilt from the ground up with a mobile first approach."

Posted by:


  • comment here
    Published by: web presence - Date: 2015-04-16