javascript framework

Why Do You Use Frameworks?

Nicole Sullivan asked. People said:

  • 🐦... for the same reason that I buy ingredients rather than growing/raising all of my own food.
  • 🐦 I write too many bugs without them.
  • 🐦 Avoiding bikeshedding.
  • 🐦 ... to solve problems that are adjacent to, but distinct from, the problem I'm trying to solve at hand.
  • 🐦 Because to create the same functionality would require a much larger team
  • 🐦 I want to be able to focus on building the product rather than the tools.
  • 🐦 it’s easier to pick a framework and point to docs than teach and document your own solution.
  • 🐦 faster development
  • 🐦 They have typically solved the problems and in a better way than my first version or even fifth version will be.

(more…)

A Minimal JavaScript Setup

Some people prefer to write JavaScript with React. For others, it’s Vue or jQuery. For others still, it is their own set of tools or a completely blank document. Some setups are minimal, some allow you to get things done quickly, and some are crazy powerful, allowing you to build complex and maintainable applications. Every setup has advantages and disadvantages, but positives usually outweigh negatives when it comes to popular frameworks verified and vetted by an active community.

React and Vue are powerful JavaScript frameworks. Of course they are — that’s why both are trending so high in overall usage. But what is it that makes those, and other frameworks, so powerful? Is it the speed? Portability to other platforms like native desktop and mobile? Support of the huge community?

(more…)

The “Developer Experience” Bait-and-Switch

Alex Russell describes his thoughts on the current state of JavaScript and how we might sometimes put a ton of focus on the ease-of-use of development at the expense of user experience. So, for example, we might pick a massive framework to make development easier and faster but then that might have an enormous impact on the user.

Alex describes it as substituting “developer value for user value.”

The “developer experience” bait-and-switch works by appealing to the listener’s parochial interests as developers or managers, claiming supremacy in one category in order to remove others from the conversation. The swap is executed by implying that by making things better for developers, users will eventually benefit equivalently. The unstated agreement is that developers share all of the same goals with the same intensity as end users and even managers. This is not true.

Here’s the kicker, though:

JavaScript is the web’s CO2. We need some of it, but too much puts the entire ecosystem at risk. Those who emit the most are furthest from suffering the consequences — until the ecosystem collapses. The web will not succeed in the markets and form-factors where computing is headed unless we get JS emissions under control.

By that standard, it could also stand to reason that the work we put into “design systems” falls into this trap. But there is something to be said about achieving ease of use on this front: a more consistent codebase is probably a very good thing for accessibility, UX consistency, etc. etc.

So, although I agree with Alex’s premise here, I’m not entirely sure I agree wholeheartedly on this subject.

icon-anchoricon-closeicon-emailicon-linkicon-logo-staricon-menuicon-nav-guideicon-searchicon-staricon-tag