Google cares a lot about the mobile web.
Though the web giant can arguably be faulted for underinvesting in HTML5 for years, the company is more than making up for it now. The tech giant is doubling down with missionary zeal to convert would-be app heathens like India’s Flipkart back to the web, not to mention serious efforts to dramatically improve mobile web performance.
See also: How Good Developers Deal With Bad Code
Given Google’s now-obvious concern for the mobile web, should we trust its view on the JavaScript frameworks used to build mobile web apps? Because at least one representative Googler, Paul Lewis from the Chrome Developer Relations team, thinks the developer benefits of JavaScript frameworks are outweighed by poor user experience.
The problem with this view, according to Ember.js co-founder Tom Dale, is that it’s wrong.
Making Developers Happy At Users’ Expense
The hot issue in app development seems to be whether app publishers should be building native apps versus web apps. There are great reasons for both, and there are signs that things like (framework) React Native are so fantastic that the whole debate may go away.
However, the heart of the debate between Lewis and Dale is about developers leaning on frameworks, versus building on the web stack without a framework safety net.
Lewis, for his part, acknowledges that there are significant developer benefits that come from JavaScript frameworks like Ember.js or Angular.js, Google’s homegrown framework. They’re fun, he says, and they help developers build a minimum viable product extra fast, among other reasons.
The problem, however, is that they may impose a significant performance hit, a definite no-no, especially in an environment with spotty network connectivity and relatively underpowered devices.
But this isn’t merely a matter of performance degradation for the end-user, though that can be significant. In Lewis’ experience, frameworks are suboptimal because they impose hits on latency, bandwidth, CPU usage (battery draining), memory usage, and more.
It’s also not a straightforward win for developers. They must learn the framework, then relearn it when it changes—or learn an entirely new one when the cool new framework hits the web.
Making Users Happy Because Developers Are Happy
Dale—with whom I used to work at Strobe, an HTML5 company acquired by Facebook—wades in and takes issue with a number of Lewis' contentions.
His primary argument: “Frameworks let you manage the complexity of your application as it and the team building it grows over time.”
That is, the bigger and more complex an app becomes, the harder it will be for that single developer to keep up with changing features. The issue dramatically worsens once new developers join the project. “Many developers have worked on a project where the complexity of the codebase swelled to be so great that every new feature felt like a slog," he said. "Frameworks exist to help tame that complexity.”
If you’re just building an app for a quick-and-dirty demo, Dale continues, coding without the benefit of a framework’s guidance isn’t an issue.
But when you’re building for the long haul, a framework can be critical, and can ultimately help end users. “The more productive the developer is, the more bugs they can fix, features they can add, slow code they can profile,” Dale said.
Finding Middle Ground
Dale’s long-term view doesn’t necessarily hold up, according to Microsoft developer evangelist Christian Heilmann. Apps and business priorities change.
But Lewis’ opinion may not hold up either, argues Paravel lead developer Dave Rupert: “[I]n client services if I deliver a site that is super fast but impossible to maintain, I have failed at my job.”
The correct answer is probably that both Dale and Lewis are right. And wrong. As ever, it depends on the app and it depends on the developer. However, Lewis finishes with one statement that seems right, regardless of whether you’re pro- or anti-framework: “Investing in knowledge of the web platform itself is the best long-term bet.”
Using a framework is probably a good idea, but it’s an even better idea for developers to ensure they’re savvy about what the frameworks are trying to abstract.
