The Cost of Frameworks Recap
A classic blog-and-forth, my favorite form of internet discussion.
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.
… 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
… 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?