4 posts tagged


Robert C. Martin on Effective Estimation

Ilya Gelman

Estimating projects and tasks in something that many developers have to do all the time. No matter how many times we do that, giving perfect estimates is always hard or close to impossible.

Famous Robert C. Martin (uncle Bob) talks at YOW! 2016 on how to actually estimate projects without lying. This talk is important not just for developers, but also for many project managers.

On Thursdays we post videos that we believe are worth watching and that can make you a better front-end developer. Have such a video to share? Share with us

Estimation   Industry   Video

Why Do Small Frontend Teams Fail?

Boris Dinkevich

In the past few months, a week has not passed without me hearing of another company whose frontend project is late, broken, running way over budget, or just plain grotesquely underperforming. Are managers still unwilling to accept the nightmare that is frontend development in 2016?

First, the background

We run a small frontend consultancy, and apart from building products from scratch, we get called to help companies solve problems with their Angular or React code. Lately, the “problems” part has been growing and growing.

Every company we meet has performance problems, unmanageable code, missed milestones, and developers quitting left and right. Tests and CI? Heh. Half of them have never heard of build tools. Even among the few that appear to be releasing code, the dev managers admit that the only way to meet management’s milestones was to remove huge parts of the planned features.

What the hell is going on?

So we started asking questions and looking around. The surprising thing? It’s the larger companies that are doing fine. They have a clear separation between teams, and having a trained team(s) dedicated to frontend is the norm. It’s the small “agile” companies with 1-3 frontend devs that keep failing miserably.

These small teams usually consist of ex-server devs, just-out-of-school juniors, and a team lead that “has 30% free time and really wants to code.” In most cases they “learned as they went” and never had an experienced frontend developer to oversee the project and its setup and architecture, or provide mentoring. Worse yet, more than one dev manager has relied on a “frontend ninja” who (on closer inspection) turned out to be criminally clueless.

How did this work before?

We had a similar shift about 8 years ago when mobile came to our world, a new complicated technology with its own quirks and knowledge domain. So how are all those smaller companies managing to deal with native mobile? Out of all those companies with failing frontend projects we met, how many had a team of native mobile developers? Zero.

While the idea of taking a server-side Java developer and training him in a week to start building Angular applications seems fine, training the same developer to do Android development sounds ludicrous to management.

native is complicated and outside the scope of our existing expertise. Hell, we wouldn’t even know how to interview or train someone.

And yet, I bet in the office space next door you will find 2-3 developers slaving away on a huge Angular app with only a vague understanding of the “digest loop,” Webpack, Flexbox, or how to set up CI. Oh, and one of them probably spent the last 2 months writing a cool utility—that is available from a common NPM package.

What’s wrong?

Is it that frontend is harder than any other tech? Or maybe that it is as complicated as the others but doesn’t get treated as such?

It appears dev managers are roughly divisible into two groups: the proud and the sad.

The proud remember frontend from their developer days back in 2006. For them it’s a bunch of JavaScript and HTML thrown together in a few hours. Complicated build tools, large frameworks, and an endless amount of 3rd-party libraries are not something they are willing to accept as necessary or hard.

We literally argued with an R&D manager at a mid-sized startup who couldn’t understand why jQuery is not enough—“I built a complicated SPA in 2007 with nothing but jQuery.”

The sad know they are in a rut and don’t know how to fix it. They know that if it is taking 3 times as long to build and the app is still not ready, something must be off. Sadly, they find themselves in an impossible position:

  • “How can I hire a great frontend developer if no one here can interview and assess him?”
  • “We hired someone, but we don’t really know if he is good.”
  • “The really good people don’t want to work as a one-man-team alone.”

Self test

If you are thinking “we understand fully what frontend is and have none of these issues,” then ask yourself:

  • Is your frontend code sitting in the same repository as your backend code?
  • Is your iOS and Android code sitting there as well?

Did you say “Yes” to the first and “No” to the second? Time to ask yourself why.

What happens next?

Will it be months or years before missed deadlines and poor products convince management in smaller companies that frontend is not what it used to be?

When will they come to terms with the idea that frontend should be treated similarly to mobile apps—as a separate project and domain? Or understand that frontend is complicated, and requires a dedicated team of professionals and adequate time?

Until then, we’ll be left with uncomfortable meetings explaining why the Angular & jQuery beast the team has been building (as they learn) over the past 6 months (and that takes 30 seconds to load in Chrome on the latest MacBook) should be rewritten in React in 2 months. If only they’d stop and properly train their team.

Viva la frontend!

Comments on HN


The Definitive Guide to Choosing The Best JS Framework

Boris Dinkevich

To truly compare the available JS frameworks, we have carefully compiled and analysed all the data available online on the subject of JS frameworks. We tested various methods of comparison, and believe we found the most promising metrics when choosing your next framework are: letters and syllables count.

Chart created with Infogr.am

You might note that React is the hands down winner, with Angular2 requiring 70% more effort, both when talking and blogging!

An interesting thing to note: while ranting about jQuery online requires 15% less effort than Angular or Vanilla, when loudly arguing with your co-workers the difficulty becomes virtually the same.


Is React Faster Than AngularJS?

Boris Dinkevich

No. Hard to believe?

Most developers and decision-makers take it for granted that ReactJS offers high performance and incredible speed much better than other frameworks like AngularJS and EmberJS.

It has gotten to the point that no one even questions things like this:


But if you ask yourself where this belief comes from, you might be surprised.

Everyone says it

This doesn’t give us much to argue to with, so we won’t bother.

Virtual DOM

We all understand that DOM manipulation by the browser is slow.

This is where ReactJS came in and introduced the new idea of using a Virtual DOM. By calculating the difference between the future state and the current one, it can minimize the amount of DOM requests.

Intuitively, this sounds like a major performance improvement. But what about the performance impact caused by the massive amounts of JavaScript required to execute this complicated feat?

Or the strange lack of any demonstrable examples of the performance improvements achieved by this feature... except the comparison demos.

We have all seen the demos

This is perhaps the biggest culprit. So let us take a closer look at a few.

React.js Conf 2015 – Hype!

This is perhaps the most watched one. This presentation literally made the crowd go “wow”.

Here is the original demo:

Wow, right?

Let’s not take it at face value though. If we give it a closer look we find something very surprising. The demo’s author seems to neglect one of the most basic speed improvements that can be effected in Angular – “track by”.

Let’s fix that by changing a single line of code:

ng-repeat="(key, db) in databases"


ng-repeat="(key, db) in databases track by key"

Try the result

Surprised? Sadly, AngularJS deserves some blame for that. The most common speed improvement is unfortunately badly documented and not auto-suggested by the framework.

This little change invalidates 95% of comparisons between ReactJS and AngularJS.

Next up: ng-conf: Angular + React

The next most popular presentation contains a similar “wow” moment.

Try it out

Here the issue is different. The comparison is not between rendering but rather between rendering ReactJS Components and rendering and data handling of AngularJS.

ReactJS is being told explicitly which cell changed while AngularJS is left with a generic “something changed” notification – forcing it to recheck everything.

Let’s level the playing field and give both frameworks the same information by using AngularJS’s isolated scope:

$timeout(function() {
  $scope.status.isSearching = false;
  $scope.status.searchResults = ...

Updated to:

setTimeout(function() {
  $scope.status.isSearching = false;
  $scope.status.searchResults = ...

The result? Try it out.

The above can be done on newer versions of angular by using $timeout([func], [timeout], false);

What does all this mean?

It appears that Virtual DOM-based frameworks (and, specifically, ReactJS) offer no demonstrable improvement over “plain” frameworks like AngularJS or EmberJS. The premise that adding ReactJS to AngularJS will magically improve performance is simply not based on factual data.

And while React itself offers a host of other improvements, I could not find any demonstration of the most commonly quoted advantage of speed.

Is React Bad?

No. React is a great framework which we at 500Tech use and love. There are many benefits to choosing ReactJS for your next project. “Speed” should not be one of them.


  • Any demonstrations that show speed boosts resulting from the Virtual DOM are most welcome.
  • Please do your AngularJS performance homework before sending them over.
  • Original presentation for ng-conf Israel
  • Since “fast” is a relative term, AngularJS was used as the comparison base. Both because it solves similar problems as ReactJS and both since it is usually used as the base comparison anyway.
  • While its easy to show that ReactJS is faster than AngularJS in certain cases, it is much harder to show that it is always slower. Over the next week we will release the various samples we wrote to test the speed differences.
  • Thanks Yoni Weisbrod for proof-reading the post.



  • People have sent me links to a number of other demos. All are simply missing ‘track by’.

In theory there is no difference between theory and practice. In practice there is.


Discussion on HackerNews

AngularJS   Industry   Performance   React