The Cost of Frameworks Recap

A classic blog-and-forth, my favorite form of internet discussion.

Paul Lewis does some research on the performance of differnet frameworks, pitting each of their TodoMVC versions against one another:

For me the results are pretty clear: there appears to be a pretty hefty tax to using Frameworks on mobile, especially compared to writing vanilla JavaScript.

Tom Dale:

Most critics miss the key [value to using a framework]: frameworks let you manage the complexity of your application as it and the team building it grows over time. All of the other stuff is just gravy.

and

... my hypothesis is that, for apps of any complexity, the ones that start off “vanilla” will accrete their own Frankenframework that performs similarly to, if not worse than, an off-the-shelf framework

Dave Rupert:

... the interesting discussion to be had from Tom’s post is: Are we trying to make lightweight sites that WORK FAST or maintainable sites WORK FOR YEARS?

My take: yes, maximum performance and maximum developer comfort are a bit at odds. It's a dance as old as time. The river runs slower when you dam it, but hey you get some electricity. OK enough metaphors.

More baby bear porridge from Zach Leatherman, and a hopefull call for benchmark-pushing competeition:

If you decide to spend valuable kilobytes on a framework, fortunately there are plenty of frameworks to choose from. Just like DOM libraries used to compete on selector engine performance, the onus is on framework authors to compete against each other on initial render performance.

Another thing I'd add: this uncached time-to-glass stuff is a good metric; perhaps the most important metric. But measuring performance after that is pretty important too. Who is winning the "clickin' around and doing stuff" performance race?