From, with love.
Subscribe now

The Value of Frameworks

Hi everyone,

Last week I came across another article touting the benefits of React. It listed things like better modularity, easier debugging, and easier testing. I don't doubt any of these claims, but I'm often disappointed when I read articles like this because they frequently don't distinguish between the value of using a framework vs. the value of using a specific framework. (And yes, you may define React as a "library" rather than a "framework", but React tends to bring along the Flux-style architecture with it, so introducing React tends to introduce some sort of framework).

Well-written frameworks share common characteristics: they encourage modularity (writing a bunch of small things instead of one big thing), which leads to easier debugging and testing because the modules are loosely coupled; they encourage uniformity by prescribing how you should do certain things, which reduces errors and makes writing tests easier; they frequently come with some type of tooling that helps end users to work with the framework.

That means you get a lot of benefit when you move from not using any framework to using a framework, just by virtue of using the framework. Frameworks organize things, and almost by definition, organized things are going to make your life easier. If introducing React (or, two years ago, Backbone), forced you to impose an organization on your code, then you will undoubtedly see some tremendous benefits. But those benefits are not unique to the framework, they're unique to using any framework.

When you're trying to make a case for using a specific framework, and you find yourself using some pretty generic terms to describe the benefits, you should ask yourself if you've done enough research. Different frameworks do have specific benefits, such as making a particular use case easier, or requiring less code to do something. If you want to do an honest job, make sure you're able to separate out the benefits of using any framework from the benefits of using this specific framework.

Be well.

JavaScript WeeklySponsor: The O’Reilly Fluent Conference
Subscribers receive $200+ off with discount code NCZ20 (extended until 12/31)

Recommended Links

BFF @ SoundCloud (article)
In a world that's increasing moving to microservices with queries, it's worth asking yourself if you really want your front-end to be managing all that information. This article introduces the concept of backends for front-ends (BFFs), proposing that an intermediate server that can sanitize and aggregate APIs specifically for front-ends makes front-end development faster and easier. This is an approach I really like and frequently recommend.

Why I'm Excited About Native CSS Variables (article)
If you've ever thought that CSS variables are not useful given preprocessors, this article is for you. It explains just how different CSS variables are from the drop-in replacement text that variables in preprocessors use.

Where to start? (article)
Is progressive enhancement only for old browsers? Jeremy Keith (correctly) points out that you're missing the point with that line of thinking. Server-side rendering isn't a fallback for older browsers, client-side rendering is an enhancement for new browsers. With several examples of successes, this article shows how progressive enhancement is still beneficial to web application developers, even in the area of "progressive apps."

Recommended Book

The first edition of Adaptive Web Design was one of my favorite books about progressive enhancement, and this second edition follows well in its footsteps. Written by progressive enhancement champion and long-time web developer Aaron Gustafson, this book captures the essence of why progressive enhancement has survived every evolutionary step of the web and why many keep coming back to it after trying to "be more modern." Adaptive Web Design covers the latest HTML5 technologies and gently guides you through how to create performant, beautiful web sites that will work on the largest number of browsers and for the largest number of people. It's a short read that I wish as longer, and I can't recommend it enough.

Recently on NCZOnline

Why I'm not using your open source project
When you think of open source software, you might think of a few specific projects depending on your area of interest. If you work on web applications, the term "open source" might conjure up visions of Apache or Node.js; if you're into big data, then perhaps Hadoop comes to mind; if you care a lot...

Hidden performance implications of Object.defineProperty()
I've recently been working on a project to port Espree[1], the parser that powers ESLint[2], to use Acorn[3]. In so doing, I ran into an interesting performance problem related Object.defineProperty(). It seems that any call to Object.defineProperty() has a nontrivial negative affect on performance in V8 (both Node.js and Chrome). An investigation led to some...

ECMAScript 6 destructuring gotcha
With all of the new syntax in ECMAScript 6, you're bound to periodically find something that is confusing (likely as you're hunting down an error). Recently, I've seen an uptick in the reporting of a specific type of error as it relates to destructuring assignment[1] using object patterns. Destructuring basics Before you can understand the...


Love this newsletter? Hate it? Have suggestions for how to make it better? When you subscribe to the newsletter, you can just reply to send in feedback.
Copyright © 2015 Nicholas C. Zakas, All rights reserved.

unsubscribe from this list    update subscription preferences