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.
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
… 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?
Funny, my experience with Javascript frameworks is that most the time they minimize performance and maintainability.
When a framework forces the developer to to abuse best practices, such as using private variables to support an inheritance model that doesn’t fit Javascript (ExtJS), or forces the developer to spill business logic into the DOM (AngularJS) or vice versa (ExtJS again), things tend to get messy, bloated, and confusing.
Off the shelf frameworks excel only when they are used for their specific niche. Anywhere else, they become more trouble than they’re worth. Extreme care must be taken when choosing a framework for this reason; rarely will frameworks get the scrutinizing they deserve.
I think this will change for the better with precompilers though; allowing portions of code to use one methodology that compiles down to halfway decent Javascript means there’s less paradigm switching and more separation of concerns.
Care to expand on this? I’m curious what makes you say that.
@Agop (guess I can’t reply to replies directly?):
Angular (as well as Ember and Polymer) encourage putting application logic in the DOM.
This is a time-saver when the DOM interaction is trivial, but I imagine (honestly I can’t speak from experience; I’m a novice with Angular) this can get more difficult to manage when more than DOM elements depend on a property, or mutate a property; personally I want my application model behind a Javascript interface, not a DOM state.
I read discussions like this and wonder why all the good developers I know tend to be so dogmatic. Does anyone else remember the VI vs eMacs wars?
I think Dave has it right.
Frameworks exist for a reason. For those of us with large and long-lived websites and large teams comprised of developers with widely varying skill levels, frameworks are a godsend. They promote consistency of the codebase and allow low-level developers to create responsive pages that work reliably across most platforms.
If I worked in a shop with a small band of talented coders that built small whizzy websites with short shelf-lives, my needs would be completely different and frameworks wouldn’t be that helpful.
Many of the “pundits” in our field are free-lancers or work for small agencies that do cutting-edge work – I think their perspective a bit skewed.
The vast majority of coders work in mid- to large size organizations, and are so exhausted by the politics and inertia of our organizations that the last thing we want to do is blog about our experiences at the end of our work days. Especially since most of the blogs are written by people who look down their noses at us because we don’t code everything from scratch.
I agree with most of what you wrote but I don’t think you can pigeonhole developers. There’s skewed perspectives everywhere.
Among other reasons, the people who know how to do this stuff well tend to write about it and share at the solutions they’ve learned. Less informed developers read those blogs and articles and assume whatever they’re doing must be the status quo.
Or like you mentioned, the blind leading the blind: some blogger writes about his experiences using a huge framework on a small project, just as a trial balloon. So what ends up happening is the massive frameworks are being used on smaller projects by people who don’t know any better. Rinse and repeat.
And the worst case… the Internet has also taken on sort of a copy-and-paste mentality over the years. Some people want quick solutions. The use case doesn’t matter. Give the mom and pop an enterprise framework, what the hell… if it works for Oracle, it’ll work here. So if developer X needs to do a particular thing, someone’s Stack Exchange Angular solution is only a couple lines, maybe I should use that. Whether it’s overkill or “just enough”, it works. There’s a lot of that. (Case in point: WordPress is popular because of it’s copy-and-paste mentality and despite the fact it’s a really bad dev environment. )
I’ve written Angular apps to replace (and then extend) vanilla JS apps, and man, things have gone from thousands of lines to just a few hundred. If your Angular apps are not maintainable, then you’re just doing it wrong – and doing it in vanilla JS will not somehow make things better.
And when you build a vanilla JS app, you’re still using a framework! Except, instead of using a framework used by many thousands of other people, you’re using a framework used by just a few people – and in some cases, just one person – you.
Even in this contrived TodoMVC example, take a look at the vanilla JS implementation. Yup, looks like a framework to me! Is it faster in this specific situation? Sure! But will it be faster in a significantly more complex application? Good luck finding out, because you’d have to write that mess of an application first to test it!
I’m not here to speak either against or for the use of frameworks, but in my experience they do carry a significant cost.
We have a very data-intensive page that loads, processes and renders in about 20ms. Adding a single Kendo UI dropdown to the page added 40ms (and 80ms for two), but a custom CSS-based dropdown had zero impact. 20ms is fast enough that you can re-render the entire page without users even noticing.
Our page started out using Knockout and rendered in about 800-1000ms. We tried different frameworks but none could deliver times below 200ms.
Using a simple JS template and hand-written logic is not for the faint of heart, but it does pay off. If the application or site demands performance above all, I’d say there is no way around it.
Although the technical performance of a framework is interesting, I find other aspects of a framework far more interesting, being its lifespan and the available knowledge pool.
Angular is pretty cool, and yes, if you do it right it may help you build a complex application in a somewhat controller manner. But hey, 3 years from now, nobody is using Angular anymore, and it will be the new legacy.
Don’t get me wrong, I know that one would have the same problem with any framework, or when not using a framework. I’m just responding to the perceived benefit that a framework allows the creation of long-lived applications. Maybe so, but the framework itself will not be long-lived, and neither will knowledge about it.
I have no solution for it, just spotting the problem. Part of my work includes still offering support for applications built in frameworks thought to be future-proof once. You can’t find a soul to support them, even if they have knowledge, they prefer new projects, rightfully so.
I think one the main issues with abandoning frameworks is teams. I don’t think anyone would disagree with you and say that frameworks don’t have performance issues. But most teams that work on longer term projects have turnover. Due to this, having a framework to fallback on when introducing new team members is crucial. Remember the first time you had to work with Ember/React/Angular? Imagine that same experience with no documentation. It’s not that it’s impossible, it just raises the bar of difficulty to place that most teams can’t justify. As mentioned by others, it also really depends on the expertise of the developers on your team. If you a three tiered team (junior, mid, and senior), then it is going to be nearly impossible to train new junior devs on your custom build without a lot of frustration.
This topic (standpoint) always seems to evoke passionate debate and I think the thing to keep in mind is that there is not just one answer, neither side is “right” nor “wrong”.
My opinion is that is it all depends on the project, business needs and (in some respects) the team. The divide between these factors is up to you as the technology professional to balance correctly such that each receive the maximum benefit… and there in lies the rub.
The final thought on the subject I’d like to mention is the often indistinguishable line between framework and library; they are often used interchangeably. A framework is something that pretty much ties you into working in a specific way, whereas a host of libraries can be brought together to create the framework you want that will be most effective for the project you are working on .
I totally agree with the point that once you pass a certain complexity you end up creating your own “Frankenframework”. In this case it totally makes sense to use an established framework where the thinking has been done for you.
The biggest problem I see is developers wanting particular features from different frameworks and mixing and matching, e.g. using Angular but jQuery for Ajax and animation. This really affects load times.
Definitely. The mixing and matching of different frameworks (that is, code that more or less defines how code will be written overall, not the library functions that provides features without dictating coding style) creates more of a mess than if no outside framework was used.