Angular, Custom Elements and performance

or, my gripes with a boatload of articles ;)

This blogpost is going to be a work in progress for some time. I will finish it, within a few weeks, but after that, I probably will be updating it every now and then, as some new "insight" is conquering the web.

We as developers tend to put out loads and loads of "new insights" and "progress report". Those are very nice, but at the same time, we seem to forget about the big picture. When I have read an article, often I have this nagging feeling that there is something off with whatever is the content of it. Sometimes I know/see it when I'm reading. Sometimes it occurs later to me. I seldom react to those articles with my findings. Why you might ask, well, as I found out, people don't like it when you attend them to the points they missed. Or they just dismiss it without even really considering the value of what you bring to the table. At the same time, you get pointed at as the 'bad person'

Ok, back to the core of this article. The other day I was reading an blog that compared the performance of Angular, with Custom Elements. (one of my first gripes was they confused those with Polymer. Those are actually 2 very different things!)
What happened was that there was some discussion on this blog, and If I had seen it. Yes, I had seen it, and I put out a couple of my observations in a nice list. (hmm, we seem to like lists too ;))

After I had done that, I pondered that this was the gazillion-nth article that rubbed me. Got me thinking, and I decided to write it out. This blog is mostly me putting down the points that are missed in most articles, and blog posts.

I like analogies. So I will be drawing quite a few in the remainder. I will make an overview of a few subjects, and list the things that in my opinion are off with those!

Components.

First of I'll start with components. I like those. they are the brick and mortar of a developer. Right? they are the cornerstone of all we do! We like to draw comparisons with Lego blocks:

(this images originates here, and I think it's way cool!)

Every block is a small component. If a component( or module) fails, you can quickly exchange it for something else. Ok, after being out in production for a year, it turns out, the component in the lower right corner approximately 50 centimeter from both the floor and the wall is giving heaps of issues.  I wish you good luck with quickly exchanging that.
If an application grows, exchanging parts(components, modules, libraries, frameworks) becomes increasingly more complex. Even if you app is designed to allow this.

components are only part of the equation. Sure you need them. It is the same as building in the real world. You need components. And just an d in the real world, you can't start without them. Also, just as in the real world, once they come in, all you have is an inventory of components. Then you can start building. But wait, what goes where? Oh, it turns out we need a plan!
Something real world builders would call a blueprint (I will come back to this!). This blueprint outlines where all components should go, and more important, how they interconnect.
Imagine houses would be build the same way most software is getting build. While every component might have undergone heavy testing, I still would fear operating light-switches! (not to mention what happens in the toilet!)

Performance (as in speed!)

Then there is performance. We have this desire to make sure all out parts will be done under 4Ms, otherwise our users might experience jank (note, I'm not going to say you should ignore performance. It is a very important metric!) 

Thing is, its also very relative, and also subject to your blueprint. If you are building a maze, you probably will want to slow down things. If you are building a shopping mall, you want people to be able to enter as fast as possible. If you are building a house, the speed of entering it is way lower on the agenda. If you are building a rocket, because your are literally doing a moonshot, the speed on how fast you can enter is of basically no concern at all. 

And then there are loads of articles comparing light-switches. I like those articles. But lets keep some perspective. Do I really care how fast I can turn the light on in my room? And if so, is the switch indeed the limiting factor? It's all subject to perspective. If I'm entering a toilet, I need  good light right now. If I'm enting a conference room where I will be for a few hours, I don't mind if it takes a minute or 2 for the light too become optimal. (as a side-note, I do need feedback that I switched on the light, so I know I did just that)

100% of the articles on performance are missing perspective. That is alright, but loads of people are following the advice in there blindly. That is not the gist of the article. In all cases you need to ponder all aspects of a solution. There is no single "right" way. 

X versus Y

Those are the worst kind. Most cases there are apples and oranges being compared. Yeah, both are like sphere shaped, and you can hold them in your hand.

(unknown origin)

Unless you are comparing them on their quality to target cans, your comparison is not gong to make sense. In this context you will find, it's more a matter of taste, as they will equally get the job done!

The point I'm trying to make is that most comparisons are dropping the ball. they go in deeply and discuss the kind of juice they make. I like both, Apple and orange. with a slight preference towards orange. But if I'm thirsty, I will grab whatever is available. Even things that are neither!
Oh wait, does that matter if you job is throwing cans?

Thing is, you can only make a comparison if you set out a strict set of requirements. And then compare your candidates for those requirements. Oh, and try to set real-world requirements. And give the perspective and frame you use to compare.

Whining

Yeah, Ok, I do see the irony on a whining subhead in a blog that's basically just doing that!
Nevertheless, There seems to be an irresistible need to do this. What do I mean, you ask? Well, I'm not going to pinpoint, but we all have read (or heard of) things like javascript fatigue, and/or the complexity of a modern toolchain. And about all the expectations "they" bestow upon us. If you have never felt like that as a developer, you are probably not around long enough.(sidenote: see, I just felt into that trap myself!) Also, in most cases, the "they" I mentioned before, is just you. Yes, you, the one reading this! (sidenote: Set aside some time to think about that!)  But then you realise, you are the one that picks what's important to your app. You are the only one that has the right perspective. You are the specialist that can pick the tools that are just right for you and the job.
So instead of writing articles whining about "too much choice", "everything is so complex now!", grow a pair, and choose. Oh, and help out to reduce the thing you are whining about. Too much choice? Create a better solution(yeah, irony again!) Too complex? write a tutorial, or even better, take a look at the thing and try to make it less complex.
Or at least, be honest in your writings. State that's it your viewpoint. Explain why you feel that way.  Put in the context you are coming from. You are probably not even wrong!

Oh, and take the words of Rev. John A. Hardon to heart:

Another person’s good reputation belongs to him, and we may not do it injury by revealing, without proportionately grave reason, what we know is true about him. 

Detraction is consequently a sin against justice because it deprives a man or woman of what they ordinarily value more than riches. Socrates’ statement that the way to gain a good reputation is to endeavour to be what you desire to appear highlights the effort required to acquire a good name. All of this, more even than accumulated wealth, can be destroyed by a single criminal act of detraction.

The seriousness of the sin committed will mainly derive from the gravity of the fault or limitation disclosed. But it will also depend on the dignity of the person detracted and the harm done to him and others by revealing something that is hidden and whose disclosure lowers (if it does not ruin) his standing in the public eye.(source..)

I'm not a religious man. But the above quote and most of the linked article are representing a value that in my eye's is bigger than a single belief system, and a cornerstone on how we should try to treat each other.

Closure

And now you expect me to talk about JS closures, right? Wrong! While I was just walking the dogs, it appeared to me I forgot to bring closure to this. Like as in a moral, or as a sort of conclusion. I don't really have one. I'm not on some moral high grounds, having all the wisdom. Far from that.
But as far as it goes, I think I'm trying to say if you put out a blog/article/message, try to make it a positive one. Make sure it adds value. Live and let live. Do it with passion, and love.
Make sure your assumptions are true, oh and list them!


That's it for today. Will revisit it in the coming time a couple of times,

If you disagree or feel I missed out something, please inform me. I like to chat with you about it. If you are right(subjective I know ;)), I promise, I will adapt this blog accordingly!

He said, while stumbling away, looking for a place to store his soapbox.