Direct Access to the DOM is Faster than using a Virtual DOM
But, let’s fact is, that’s not how most of code works. If you are writing this kind of application and you are using a library or framework that uses a virtual DOM layer, something is wrong. I would argue you’ve probably chosen the wrong library for what you are trying to do.
Immutable Objects are Necessarily Slower than Mutable Objects
Similarly, for a regular object that isn’t a list, we would create a new object and copy the existing elements into it and then overwrite the items that have changed.
Now, why would we want to go to all of this work? It does seem like it would be faster to just modify the existing object. Right?
But you see, there is this little thing called “change detection” that more than makes up for all of this overhead I just described.
In most of our applications, at some point we want to know if an object has changed, right? If we can’t rely on the fact that we have a new object, we have to do a deep comparison of the two objects until we’ve determined that there is a difference, or we’ve been through the whole list and verified that the nothing has changed.
Once we can rely on objects being immutable, we can use the equals operator (==, or ===) to see if the object has changed. I’m sure you can see that this takes much less time than evaluating an entire object tree, even if you object only has two properties in it that need to be compared.
But let’s step back and look at the bigger picture. In most of the code that I write, what we are really talking about is immutable arrays. Yes there are other non-array places where we would use immutable objects, but my guess is that immutable objects impacts 80% of my code. Get a list of records from the database for example.
The fact of the matter is, every time I access the database, I get a new array back anyhow. Even in the case of retrieving a single record, I still get a new object back.
If I need to delete an element from an array, here again, I’ll end up creating a new object.
In fact, with the exception of modifying a row, or adding a record to the end of a list, just about everything I tend to do with an array ends up being an immutable operation anyhow. By making everything immutable, we are forcing the areas that we aren’t already implementing immutability to be immutable. The point is, in terms of performance the net is an obvious gain both in terms of performance and in terms of consistency.
And, going back to the issue of rendering our data into the DOM, because the change detection is faster, we can determine that a particular component doesn’t need to have the DOM updated quicker rather than re-rendering the entire DOM.
Backwards Compatibility means I can’t upgrade my Development Environment
Continuing on. Remember the conversation I’m referencing was about React and Angular2. And the guy who was making these statements about performance was asserting that he couldn’t upgrade his React environment to use the latest and greatest tool chain because he had to support older browsers. He specifically stated IE6. Now, knowing the site he’s talking about, I doubt we make any money at all from people who run IE6. But, let’s just assume for a second that we do.
So, what you’re telling me…
Bugs and Security Risk
Just this last week I saw a study that said that over a third of the web sites on the Internet were running code that left them venerable to security risk. That is, the code they were running had known security risk. By not upgrading your tools for public facing sites, you are leaving your company at risk. When your site is compromised, do you want to be the one who has to explain to your boss that it is because you refused to upgrade your tools? I sure don’t.
But what about the old browsers?
Well, if you really need to support the old stuff, there are polyfills that you can apply that will let you run the newer stuff in the older browsers. Seems to me you get the best of both worlds. Your customers who are up to date benefit with a better performing, and less buggy web site, and the customers using older browser still get to see something. Are there places where you might still have to make some compromises. Sure. There are a few places. But not enough that you shouldn’t upgrade.
What is the Bigger Problem?
So, how can this happen? How can really smart people make really bad choices like this?
I don’t really know, but I have a few theories.
One is just plain arrogance. Being so sure you are right that you never stop to think you might be wrong.
I have to admit, when I first learned about immutability, I thought it sounded slow too. But, my thinking went along the lines of, “well, much smarter people than me are working on this, they must think it makes sense. I wonder why?” And then I started digging for answers.
So, I would encourage those who are responsible for making decisions to make sure that the people they are listening to can actually back up what they are saying and not just assume they are right because they seem so confident.
- WebForms vs MVC–The War Is Over - September 25th, 2014
- Create A Desktop Application using Angular, Bootstrap and C# - October 15th, 2015
- Are You Doing Angular Right? - November 5th, 2015
- Adventures Working With Angular’s $scope - November 26th, 2015
- Using Gulp to Bundle, Minify, and Cache-bust - January 28th, 2016
- Reactions to React JS and Associated Bits - March 17th, 2016
- An Explanation of the Flux Pattern - March 31st, 2016
- Ext JS 6 by Sencha - The Good, The Bad, The Ugly - April 7th, 2016
- Do This To Increase Your Client Side Web Development Speed - April 21st, 2016
- ES2015 Code Coverage and Jest (React JS Unit Testing) - May 5th, 2016
- 4 Reasons To Drop MVVM - July 27th, 2016
- You Can Start Using Node Today - August 2nd, 2016
- TypeScript and Electron The Right Way - September 6th, 2016