A Tale of Client Side Framework Performance

Jeremy Wagner measured some performance differences between React and vanilla JavaScript. While I’m not surprised that running your code on bare metal code is faster than a framework, it’s interesting to see some exact numbers.

React and ReactDOM total about 120 KiB of minified JavaScript, which definitely contributes to slow startup time. When client-side rendering in React is relied upon entirely, it churns. Even if you render components on the server and hydrate them on the client, it still churns because component hydration is computationally expensive.

If it sounds like I have a grudge against React, then I must confess that I really like its componentization model. It makes organizing code easier. I think JSX is great. Server rendering is also cool—even if that’s just how we say “send HTML over the network” these days.

Even with server-side rendering, React and other virtual DOM frameworks add loading time because they need to load more code and hydrate the page before it’s interactive.

A vanilla addEventListener callback performs about 40 times faster (!) than an event handled in a React component. React’s overhead worth when you have a lot of complex state, not “simple state” like menu toggles.

Read the full article on CSS-Tricks.









Unlearning

| 1 min read

As developers, we often talk about the importance of learning. Learning is so important to us, that it’s worth persuing ways to improve the way we learn.

One way to become a better learner is to master the reverse: unlearning. Not the ability to completely forget, but the ability to set something aside for a brief moment.

When we learn a new language, framework, or tool, it’s hard not to dismiss new ideas based on our existing opinions. It’s the mental baggage we carry along all day.

What we’ve established as antipatterns in tool X’s, might be shiny tool Y’s bread & butter. That doesn’t mean we should dismiss tool Y. Ideas on their own are rarely good or bad, they need to be evaluated in a certain context.

Read more


Builders and architects

| on stitcher.io

My colleague Brent wrote a food-for-thought post about two different kinds of programmers: builders & architects.

The first ones, the builders, are the programmers who get things done. […] On the other hand there are architects. They are concerned about sturdy and structurally sound code. […]

These two types of programmers seem like opposites. They themselves look at the other group and often think exactly that. They have a different way of handling the same problems. The other group’s solutions are so different, they can’t possibly be right, or so it seems.

Builders often find architects too rigid and conservative. They follow the rules for the sake of following them, without any practical benefit. Architects in turn, think of builders as careless, too focused on results, instead of thinking about long-term maintainability.

Different programmers aside, “build vs. architect” is the eternal internal conflict when I want to make decisions. Striking a balance between “getting things done” and “getting things right” is tough.

Read the entire, beautifully illustrated post on stitcher.io.