DEV Community: Ross Kaffenberger

These Rails apps are overpacking their JavaScript bundles

Ross Kaffenberger — Tue, 22 Sep 2020 01:57:35 +0000

Originally published at rossta.net

You might think dividing your JavaScript into multiple bundles will help improve page load performance. When done incorrectly with Webpacker, it's possible to make things worse.

This mistake appears relatively common. As I'll share in this post, I've discovered several of my favorite Rails applications are making browsers download and parse more JavaScript than necessary even while attempting to send less.

I believe Rails developers may think the mechanics of packaging JavaScript for the browsers work similarly in Webpacker as it does with the Rails asset pipeline. This assumption is fraught with peril!

As we'll see, Webpacker is a very different beast than the Rails asset pipeline. We need a different mental model to understand how it works. We should also follow a few basic guidelines to deliver JavaScript correctly and avoid falling victim to "bundle bloat."

First, let's take a little safari and see what we can do to help a few companies correct their Webpacker usage out in the wild.

Help me help them: My aim in highlighting these apps is to educate, not criticize!

If you know anyone who works at any of the following companies, please share this post or ask them to reach out to me at ross at rossta dot net.

Case study: Podia

Podia is a fantastic service that provides content creators with a platform to sell digital content, including e-books, online courses, and webinars.

We can tell Podia uses Webpacker to bundle assets because it renders a Webpacker manifest at https://app.podia.com/packs/manifest.json:

{
  "admin/ui.css": "/packs/css/admin/ui-59291053.css",
  "admin/ui.js": "/packs/js/admin/ui-931ad01f76a9c8b4c1af.js",
  "admin/ui.js.map": "/packs/js/admin/ui-931ad01f76a9c8b4c1af.js.map",
  "application.js": "/packs/js/application-42b89cd8ec22763d95ae.js",
  "application.js.map": "/packs/js/application-42b89cd8ec22763d95ae.js.map",
//...

The manifest contains URLs to many Webpacker "packs," also described as entry points in the webpack docs.

When I visit the public-facing storefront, my browser downloads the following "packs" from the Podia CDN:

/packs/js/storefront/index-1d9e9c36f5f9ab7056d1.js
/packs/js/storefront/current_time_ago-0c5c682d173647ef3199.js
/packs/js/storefront/messaging-60ddf6567eb7b74a1083.js

By splitting JavaScript up across multiple files on this page, I believe Podia intends to deliver only required JavaScript to the client's browser. For example, there's no need to send JavaScript for the CMS UI to the public-facing storefront page.

As we said earlier, the intent here is good.

The problem

On closer look, though, something doesn't seem quite right. The payloads for these individual packs are, in fact, rather large.

Take the "storefront/current_time_ago.js" bundle. It transfers as 73KB gzipped and comes out to 396KB of parsed JavaScript.

Does Podia's "storefront/current_time_ago" functionality need to be nearly 400KB?

If so, I'd be shocked. I imagine this pack's primary responsibility is similar to the tiny jQuery plugin timeago, which claims a 2KB size. As a comparison, a bundled version of react-dom module parses at around ~150KB.

Something's not right here.

Exploring source maps

I don't work at Podia, so I can't use my favorite tool, the webpack-bundle-analyzer, to peek inside the bundled JavaScript; this requires access to source code.

But, there's another trick we can use. We can find out what's happening inside these bundles from Podia's source maps.

It's like magic.

Source maps are included in production by default with Webpacker. You can find the URLs to source maps in the Webpacker manifest file, as shown above.

If you're curious about why source maps in production are enabled by default in Webpacker, you may be interested in this GitHub issue thread.

Another place to find the URL to a source map is in the corresponding source file's last line:

//# sourceMappingURL=application-42b89cd8ec22763d95ae.js.map

We can analyze Podia's publicly available source maps using source-map-explorer. It can provide a visualization of all the modules bundled on this page. Here's an example:

Podia storefront editor

Here's a screenshot of the source-map-explorer treemap for the three Webpacker packs rendered on the storefront editor page, with my annotations for emphasis:

You can see the three JavaScript bundles in purple, blue, and orange, and with each, you can see included modules such as actioncable, stimulus, moment.js, core-js, and cableready.

Here's the problem: some modules appear twice on the same page!

Two bundles include both moment.js and all the 100+ moment-locale modules. That means the browser has to download and parse moment.js (52KB) and moment-locales (326KB) twice on the same page!

Same for actioncable, cableready, stimulus, and core-js.

In an attempt to deliver less JavaScript to the browser with page-specific bundles, they've ended up with even bigger payloads. Podia is "overpacking", and it's resulting in the redundant module problem.

More case studies

It's not just Podia. I've recently discovered several other Rails applications with the same problem.

Funny or Die

I'm always up for a laugh, but you know what's not funny? Duplicate jquery on the Funny or Die home page.

That's an extra 80KB and, I would presume, a potential source of bugs for jquery plugins that assume only one instance of $ in the page scope.

Dribbble

I'm whistling the Dribbble profile page for multiple infractions, including duplicate instances of vue and axios. They could reduce their total payload size by up to 150KB.

Teachable

The course page on Teachable must love jquery and lodash. They're both bundled twice across the three Webpacker packs rendered on this page.

Drizly

It's raining JavaScript at Drizly! The product search page renders three packs, each of which includes instances material-ui, react, and lodash, among others. If Drizly were to introduce React hooks, I am relatively sure multiple instances of React will cause issues if they haven't already.

Strava's activity feed

As an endurance athlete in my spare time, I use Strava almost daily, where the activity feed forces me to render four instances of react! Strava could reduce their activity feed payloads by a whopping 500KB by getting rid of their duplicated modules.

Analyzing JavaScript usage

Another tool I recommend is bundle-wizard, which can be used to find unused JavaScript modules on page load.

$ npx -p puppeteer -p bundle-wizard bundle-wizard --interact

This tool turns the source-map-explorer into a heatmap representing code coverage across the bundled modules from high (green) to low (red).

Here are the source maps from the Strava activity feed visualized again with bundle-wizard coverage heatmap:

See all that red? Those extra React modules are unused on page load.

Measuring end user performance

We can also see whether Google's Lighthouse performance auditing tool would back these findings.

Lighthouse is an open-source, automated tool that can perform web page audits for performance, accessibility, among other quality indicators. You can generate a Lighthouse report for almost any page you can access on the web through Chrome DevTools or a Firefox extension.

I generated this Lighthouse report for my Strava dashboard:

The page scores 23/100 based on Lighthouse's performance metric scoring rubric, and, by far, the biggest opportunity for improving page load performance is to remove unused JavaScript.

This much is clear: JavaScript bloat is hampering the performance of these Rails apps.

Why the redundant modules?

It should be clear by now some Rails apps using Webpacker are bundling some modules unnecessarily across multiple bundles on a single page. As a result:

JavaScript payloads are larger—not smaller—causing increased download and parse times for the end user
Logic may assume "singleton" behavior or touch global concerns leading to confounding bugs

So why is this happening?

These Rails applications aren't intentionally bundling all this extra JavaScript. The fact that they are splitting up their bundles indicates they are attempting to be selective about what JavaScript is delivered on a given page.

Wait, so we can't split code into multiple bundles without duplicating modules in Webpacker?

Let's be clear that the practice of code-splitting isn't wrong; it's a recommended best practice for improving page load performance.

The problem with these examples is in the execution; it's not happening the way webpack expects.

Consider Cookpad.com. It's a Rails app that renders numerous Webpacker bundles on its home page, yet no modules are duplicated:

When it comes to Webpacker, the Cookpad recipe is top-notch.

A new mental model

The redundant module problem highlights that although the Rails asset pipeline and webpack solve the same general problem, they do so in fundamentally different ways.

Webpack is a module bundler.

The asset pipeline is a file concatenator.

The asset pipeline builds a list of what the developer explicitly requires. Think of it as a stack. "What you see is what you get."

Webpack, on the other hand, recursively parses the import statements in all the dependencies within a single pack, such as app/javascript/packs/application.js, like a directed graph.

Webpack will include all imported modules in the output, ensuring that no import is included in the same bundle twice.

If that's true, why are there multiple instances modules in Podia's output, for example?

The reason: each pack is a separate dependency graph.

Consider this illustration of an imaginary project with multiple packs. One pack imports moment explicitly, and the other pack imports a made-up timeago plugin that depends on moment.

See that the moment package is imported in both packs. There is an explicit import in the first pack, and an implicit import via timeago in the other.

So splitting your code into multiple packs can lead to this problem if you don't configure webpack properly.

What we want is a way to split code up into smaller pieces without all the overhead and potential bugs. It turns out, webpack was initially created to address precisely this: code-splitting.

It's just done differently than you expect.

The Webpacker Packing Checklist

Now that we know what the problem is and how to diagnose it, what can we do about it?

The key to addressing this kind of Webpacker code bloat is to keep all dependencies in the same dependency graph.

Below, I summarize the steps I would take to help these companies, which you can apply in your applications. These steps are iterative; you need not complete all these actions to begin seeing benefits.

Step 1: Start with one entry point per page

Webpack recommends one entry point per page. From the webpack docs:

As a rule of thumb: Use precisely one entry point for each HTML document.

That's how webpack assumes your application will work out-of-the-box. Practically speaking, that means there would be only one usage of javascript_pack_tag per page:

<%= javascript_pack_tag "application" %>

For the companies described in this post, that would mean consolidating those separate packs into one on a page. Rendering multiple entry points on a single page correctly requires additional configuration. We'll get to that, but "one pack per page" is how I recommend starting.

Does this mean you have to put all your JavaScript in one pack? No, but:

Step 2: Keep the number of packs small

Don't split your JavaScript into a ton of little packs/entry points unless you understand the tradeoffs, and you're comfortable with webpack.

For smaller applications, just an "application.js" may be well worth the tradeoff of having an application that's easier to maintain over the added cost of learning how to best split up JS code with webpack with little performance gain.

Think of packs as the entry points to distinct experiences rather than page-specific bundles.

For Podia, this could be one pack for the public-facing storefront, one for the storefront editor, one for the customer dashboard. Maybe an employee admin area pack. That's it.

Render one pack per page?... Keep the number of packs small? ... these bundles could get huge!

Ok, now we've come to webpack's sweet spot:

Step 3: Use dynamic imports

Webpack has several automated features for code-splitting that will never be supported in the Rails asset pipeline. The primary example of this is dynamic imports.

Dynamic imports allow you to define split points in code rather than by configuration or multiple entry points. Note the import() function syntax:

// Contrived examples

// Import page-specific chunks
if (currentPage === 'storefront') {
  import('../src/pages/storefront')
}

// Import progressive enhancement chunks
if (document.querySelector('[data-timeago]').length) {
  import('../src/initializer/current_time_ago')
}

// Import bigger on-demand chunks following user interaction
document.addEventListener('[data-open-trix-editor]', 'click', () => {
  import('../src/components/trix_editor')
})

In the example above, the imported modules are not separate packs. They are modules included in the same dependency graph but compiled as separate files. Webpack will load dynamic imports asynchronously at runtime.

Dynamic imports allow you to divide your "packs" into smaller pieces while avoiding the redundant module problem.

Does this mean import every little module in little dynamic chunks? No. Measure, experiment. Consider the tradeoffs with handling asynchronous code loading. Timebox your efforts

Step 4: Go further with splitChunks, but only when you're ready

For a more powerful combination, use page-specific dynamic imports combined with the splitChunks configuration API to split out bundles for vendor code that can be shared across packs. In other words, browsers wouldn't have to pay the cost of re-downloading bundles containing moment.js, lodash.js, etc., across multiple pages with a warm cache.

Beware, though; this technique is a bit more advanced. It requires the use of separate Rails helpers, javascript_packs_with_chunks_tag and stylesheet_packs_with_chunks_tag, which will output multiple bundles produced from a single pack and these helpers should only be used once during the page render. It may take some reading up on the webpack docs and some experimentation with the chunking logic to achieve optimal results.

Check out the open-source Forem application (formerly dev.to) for an excellent example of how to do "splitChunks."

Summing up

Webpack can be a bit confusing to understand at first. Webpacker goes a long way toward providing that "conceptual compression" to get developers up-and-running on Rails. Unfortunately, Webpacker doesn't yet offer all the guard rails required to avoid problems like overpacking. As we've seen, some Rails apps are using Webpacker with an asset-pipeline mindset.

Embracing new tools may mean a little more investment, along with letting go of the way we used to do things.

Apply the Webpacker Packing Checklist to ensure a good experience for clients who desire faster webpages and developers who want fewer bugs.

The webpack plugin I can't live without

Ross Kaffenberger — Thu, 28 May 2020 12:55:19 +0000

Originally published at rossta.net

Photo by NeONBRAND on Unsplash

tl;dr Install the webpack-bundle-analyzer to visualize what's included in your webpack bundles and debug common problems.

Does webpack feel still a bit scary? Maybe a bit too magical? Too much of WTF is going on here?

It felt that way for me once. I was struggling to switch from Sprockets to Webpacker in a large Rails app. With Sprockets, I could require a jQuery plugin through a magic comment (the require directive), and it would "Just Work."

Such was not the case when I first started using webpack; ever seen an error like on the console?

'Uncaught TypeError: $(...).fancybox is not a function'

Yeah, you and me both.

Then one day, it all clicked for me.

My main problem was I didn't have a good mental model how webpack worked. To form that mental model, I researched dozens of articles, watched numerous screencasts, and read a lot of source code. One thing helped "flip the switch" more than anything else: understanding the product of a webpack build, the output.

It was right there in front of me the whole time.

Now you might call me crazy to say, "you should read the source of your bundled output," even assuming we're talking about the unminified/unobfuscated development build, so I'm not going to tell you to go do that. (Not without some guidance; let's save that for a future project).

But you can use a tool right now to visualize what's in your bundle. And that could be enough to make all the difference in helping you understand, at least at a high level, how webpack does its thing.

Introducing the webpack-bundle-analyzer

But, there is something else you can do that requires a lot less work: you can use the webpack-bundle-analyzer. You can probably get it up-and-running in less time than it takes to read this article.

Curious about or need help with webpack? I may be able to help! I'm developing a course for webpack on Rails and I frequently write about it on this blog.

Subscribe to my newsletter to get updates.

The webpack-bundle-analyzer is a tool that you can use to visualize the contents of a webpack build. It parses the "stats" output of a webpack build and constructs an interactive Voronoi treemap using the FoamTree library.

It might look a little something like this:

Funny story, this wasn't the first time I've come across Voronoi diagrams. The hands-down best Computer Science class I took at NYU was Heuristics with Dennis Shasha in which we learned algorithms for approximating solutions to NP-hard problems and applied them to compete in automated 2-player competitive battles including a gravitation Voronoi game. My source code is up on GitHub somewhere useful to no one else, serving mostly as a reminder I can accomplish big things under challenging constraints.

The analyzer will represent multiple bundles as distinct colors with relative sizes:

Individual modules are displayed in their relative sizes. Hover over bundles and modules to view statistics. Click or scroll to zoom in:

Use the slide-out menu on the left to toggle the gzipped and parsed ("un"-gzipped) bundles:

Highlight modules that match a search phrase, like "react":

Are you using Moment.js? It might be including translations for all its locales by default at enormous cost. Consider using only the locales you need.

Key questions

Here are just some examples of questions the webpack-bundle-analyzer can help answer:

Why is this bundle so large?

What are the relative sizes of each bundle in the webpack build?

What are the relative sizes of each module in the webpack build?

Where is my business logic bundled?

Are the modules I expect included?

Are any modules included more than once?

Are there modules I expect to be excluded?

Which third-party libraries are bundled?

Which bundle contains $MODULE_NAME?

Is tree-shaking* working?

WTF is in this bundle?

Glossary alert "Tree shaking" is jargon for dead code elimination: the process of removing unreferenced code from your build. Webpack will perform tree shaking when running in "production" mode which is enabled when building assets using rake assets:precompile or via ./bin/webpack with RAILS_ENV=production and NODE_ENV=production. I'll share more about how to take full advantage of tree shaking in future posts.

In short, webpack-bundle-analyzer graphs what is happening in your build. It can help you debug unexpected behavior or optimize your build output to reduce bundle size. All that, in service of better user experience!

Installation

The webpack-bundle-analyzer is distributed as an NPM package. To install via yarn:

yarn add --dev webpack-bundle-analyzer

Since this tool is typically only useful for local development, we add it to devDependencies using the --dev flag.

Usage

To use the webpack-bundler-analyzer, you can either integrate it as a plugin to your Webpacker configuration or you use a two-step command line process.

Typically, it makes the most sense to analyze the output of production builds since they will be what's delivered t the client and may contain several optimizations that will make the output differ significantly from the development build. Analyzing the development build can still be useful for additional context when debugging.

Though the instructions are tailored to a Rails project using Webpacker, you could adapt them to any webpack project.

When the analyzer is run, it will launch a local webserver; visit http://locahost:8888 to view the treemap. The port is configurable, and you'll need to hit Ctrl+C to stop the server.

Option 1: Analyze JSON from command line

The webpack-bundle-analyzer package ships with a command-line interface (CLI) that can ingest a webpack JSON stats file. In other words, it's a two-step process in which we generate a webpack build that's outputs build stats to a JSON file and then run the webpack-bundle-analyzer CLI to analyze the build stats and the output bundles generated in the build:

In a Rails project, we might typically first run the webpack build:

bin/webpack --profile --json > tmp/webpack-stats.json

Then we would analyze the output with the command webpack-bundle-analyzer [stats file] [output directory]:

npx webpack-bundle-analyzer tmp/webpack-stats.json public/packs

npx is a separate command-line interface that is installed along with node. It will look for the command you specify in your locally installed node_modules. In other words, this replaces ./bin/node_modules/webpack-bundle-analyzer ....
Get this: with npx, the package script you're trying to run doesn't even need to be installed! Yes, that's right: if you want, you can skip yarn add webpack-bundle-analyzer. Use npx webpack-bundler-analyzer as if it's installed globally. npx will search your locally installed packages and will look up the package on the remote npm registry when not found locally. Pretty cool!

Since I don't want to type all that out every time, I put those commands in the scripts section of my package.json:

// package.json
{
  // ...
  "scripts": {
    "webpack:analyze": "yarn webpack:build_json && yarn webpack:analyze_json",
    "webpack:build_json": "RAILS_ENV=${RAILS_ENV:-production} NODE_ENV=${NODE_ENV:-production} bin/webpack --profile --json > tmp/webpack-stats.json",
    "webpack:analyze_json": "webpack-bundle-analyzer tmp/webpack-stats.json public/packs"
  }
}

To analyze the build using these npm scripts, run:

yarn webpack:analyze

You could instead write this as a rake tasks as follows:

namespace :webpack do
  desc "Analyze the webpack build"
  task :analyze => [:build_json, :analyze_json]

  task :build_json do
    system "RAILS_ENV=#{ENV.fetch('RAILS_ENV', 'production')} \
     NODE_ENV=#{ENV.fetch('NODE_ENV', 'production')} \
     bin/webpack --profile --json > tmp/webpack-stats.json"
  end

  task :analyze_json do
    system "npx webpack-bundle-analyzer tmp/webpack-stats.json public/packs"
  rescue Interrupt
  end
end

To analyze the build using these rake tasks, run:

rake webpack:analyze

Option 2: Integrated setup

Instead of using separate scripts to trigger the bundle analyzer, you can instead incorporate the webpack-bundle-analyzer into your webpack configuration. Doing so runs the webpack-bundle-analyzer localhost server as a side effect of running the build command.

Below, we'll look at how you can integrate the analyzer into a Rails using Webpacker.

// config/webpack/environment.js
const { environment } = require('@rails/webpacker')

if (process.env.WEBPACK_ANALYZE === 'true') {
  const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin
  environment.plugins.append('BundleAnalyzerPlugin', new BundleAnalyzerPlugin())
}

module.exports = environment

Note that the plugin is incorporated into the webpack config only with the environment variable WEBPACK_ANALYZE=true, so it is only added to the configuration as an opt-in feature.

To visualize the production build, run this command instead:

WEBPACK_ANALYZE=true RAILS_ENV=production NODE_ENV=production ./bin/webpack

You could even run the analyzer server alongside your webpack-dev server with WEBPACK_ANALYZE=true ./bin/webpack-dev-server to get instant feedback. Keep in mind that the bundle analysis while in development mode will yield different results from the production build.

Rails template

For your convenience, I packaged this changeset as a Rails template on railsbytes.com.

You can preview this template at https://railsbytes.com/public/templates/Xo5sYr. To use the template, skip the steps above and run the following command:

rails app:template LOCATION="https://railsbytes.com/script/Xo5sYr"

What's next?

So you've set up the webpack-bundle-analyzer and started understanding what's happening in your webpack bundles, what now? You may have noticed some things you don't like. In future posts, I'll be examining how you can deal with the excesses, including:

Replacing libraries with built-in browser functionality or smaller packages
Taking full advantage of tree-shaking with imports
Using webpack to filter out unnecessary imports
The "right way" to split bundles for multi-page applications
Code-splitting with dynamic imports

Until then, here are some more resources you can use:

25 reasons to switch to Webpack(er)

Ross Kaffenberger — Fri, 06 Mar 2020 00:14:27 +0000

Originally published at rossta.net

Photo by Alice Donovan Rouse on Unsplash

I've been getting this question lately from Rails developers in some form or another:

Is Webpack and Webpacker worth the hassle?

It's a good question, but my short answer is yes.

Given the sharp rise of mindshare in the JavaScript community in recent years, there has been a great deal of innovation in tooling, development experience, and optimization for frontend development.

Rails was once at the forefront—the Rails asset pipeline was a huge leap forward when it was released—but it hasn't kept up in this department. Outsourcing JavaScript and CSS dependency management and asset bundling is smart economics at this point.

In this post, I will elaborate on why I think think it's a good idea to make the switch. But this will assume some prerequisites; in other words, we'll first consider why you might NOT want to switch and instead stick with the Rails asset pipeline.

Subscribe to my newsletter to get help with using Webpack on Rails

Why not switch?

Here are a few reasons why Webpack and Webpacker might not be a good fit for you.

You don't have the right application

If your application doesn't use much JavaScript, it's probably not worth the switch. Do you spend less than 5-10% of your development time working on JavaScript? Your app might not warrant a heavier tool like Webpack.
You don't have the time

I'll be the first to admit that adopting Webpack for the first time requires patience. Things work differently than with Sprockets. You may need to invest time learning a new paradigm. Webpack and NPM dependencies are upgraded at a rapid pace, so you need to keep up with upgrades. You might also have to understand how JavaScript modules work—good news, those skills are transferrable.
You don't have the right mindset

Yes, Webpack is complex. Plenty of developers love to complain about this fact. If you think you're one of those developers, you probably won't enjoy the process of adopting Webpack. A lot of frustration can be eased through education. Make sure you've got a positive attitude going in.

All that said, given a little time, the need, and the right mindset, you'll be successful upgrading to Webpacker. Here's a list of ways you'll benefit.

1. Webpacker is the future of Rails

Webpacker is now the default JavaScript compiler for new Rails apps. Rails 6 apps will still include both Sprockets for managing CSS and images, but JavaScript dependencies are meant to be bundled by Webpacker. The Rails defaults fall in line with how Basecamp builds web applications and it may benefit your team to "go with the herd" to stay closer to Rails edge and attract candidates who are looking to work with more advanced tools.

2. Sprockets is dead; Long live Sprockets

Sprockets development may have slowed in recent years, but it's not going away anytime soon. Sprockets version 4 was recently released, thanks to hard work led by Richard Schneeman. The default Rails setup encourages developers to use both Webpacker (for JavaScript compilation) and Sprockets (for CSS and images) side-by-side.

The ability to use both compilers in the same application is a real advantage for teams making the switch; this opens the door to an iterative migration which may be desirable to de-risk the transition.

3. It will change the way you write JavaScript for the better

Prior to Rails support for Webpack through Webpacker, most of the Rails apps I've worked on or seen either directly on GitHub or implicitly through tutorials or presentations, have fallen into one of the following categories:

jQuery spaghetti
Bespoke module implementation
Combination of 1. and 2.

What's wrong with this approach?

Accidentally leaking JavaScript into the global scope
Difficult to share code
Order-dependence when requiring code
Very difficult to understand the implicit dependency graph
Very difficult to load code asynchronously

Writing your JavaScript source code within a module system allows you to take advantage of module scope within each file, i.e. no accidental leaking of code into the global scope. No more bespoke module implementations.

4. Enjoy the power of ES modules

There seems to be little doubt now that ES modules are the future of JavaScript. As the new EcmaScript standard, eventually, we'll be able to use ES modules in browser and server-side runtimes, like Node.js. With support for both synchronous and asynchronous imports, they may eventually phase out early module specifications, like CommonJS and AMD altogether.

Of note, ES modules employ live bindings, meaning when an exported module changes a value, it can be read in the importing module. In addition to being useful potentially for application logic, this feature allows ES modules to support cyclic dependencies.

For more on how ES modules work, check out this cartoon deep dive.

5. $JAVASCRIPT_FRAMEWORK not required

Contrary to popular belief, you don't need to use a popular frontend framework, React, Vue, Angular, or Svelte, to take advantage of what Webpack has to offer. It works just great with "vanilla JS" or even jQuery-based apps.

Personally, I don't believe single page applications are worth the extra effort and complexity for the majority of CRUD-based apps—the Rails sweet-spot. Employing "JavaScript sprinkles" still makes a lot of sense in 2020 and Webpack should be considered an advantage.

6. Take advantage of alternative file structures

Webpack opens the door to a great deal of customization of how JavaScript source files are structured. Perhaps the most popular JavaScript framework, React.js, introduced us to JSX, which allows developers to challenge the old notion of separation of concerns to write HTML-like JavaScript code to co-locate HTML and JavaScript source for components.

Vue.js is famous, in part, for its support for Single File Components, which allows developers to co-locate HTML, CSS, and JavaScript as separate portions of a single file.

Example:

<template>
  <div>Hello, {{ name }}!</div>
</template>

<script>
export default {
  data() {
    return {
      name: "World"
    }
  }
}
</script>

<style scoped>
div {
  background-color: aliceblue;
  padding: 1em;
  font-size: 2em;
  text-align: center;
}
</style>

This is not (to my knowledge) an approach that would be easily handled in the Rails asset pipeline.

7. You'll have a better way to manage dependencies

I've always found Rails "asset gems" to be a major pain. In most cases, you can replace your asset gems with Node Package Manager, or NPM, dependencies.

NPM has become the primary repository for distributing open-source JavaScript packages. Although originally designed for packages intended to be used with the Node.js runtime, over time, it has also become the default for browser-based packages. This means that both libraries that run on Node.js, like Webpack, and libraries in the browser, like React, Vue, and jQuery, can all be distributed over NPM. Using NPM is a huge improvement over the typical for sharing JavaScript and other assets for the Rails asset pipeline. One big point of friction with the latter approach is having to maintain both a Ruby version along with the version of the packaged assets. This technique has always felt cumbersome and bolted on.

It's worth mentioning that you can still try managing assets via NPM and make them available to the Rails asset pipeline by adding node_modules to the Sprockets load path. Again, this approach is cumbersome and can potentially adversely affect build times depending on scope.

8. Stop using jQuery plugins (if you want)

One benefit of jQuery plugins prior to the adoption of modules is that it provided a means to add functionality without polluting the global scope. With a proper module system, as you'd get with Webpack, you need not attach functionality to the jQuery instance to reference it across the application.

Consider the touch-responsive carousel plugin Flickity. In the Rails asset pipeline, you might use it as follows:

//= require flickty

$(function () {
  $('.main-carousel').flickity({
    contain: true
  });
})

Flickity is also intended to work without jQuery meaning you can implement the Flickity module in a Webpack environment:

import Flickity from 'flickity'

document.addEventListener('DOMContentLoaded', () => {
  const elem = document.querySelector('.main-carousel');
  const flkty = new Flickity(elem, {
    contain: true
  });
})

You can leave the jQuery out of this interaction altogether.

9. Compile ES2015+ syntax to ES5 with Babel

CoffeeScript was popular when it was first introduced because it offered a cleaner, Ruby-ish syntax. Many of these ideas and more have made there way into recent versions of EcmaScript. I love writing JavaScript in ES syntax even more than I loved CoffeeScript.

Here's a shortlist of just some of the great ways the language is evolving:

ES2015+ is a superset of ES5, so all your current ES5 code is also ES2015+ code
Replace var with scope-constrained let/const https://exploringjs.com/es6/ch_variables.html
Destructuring, Replace arguments with ...rest parameters, https://exploringjs.com/es6/ch_destructuring.html
Replace apply() and concat() with (...) spread operator
Replace constructors with classes https://exploringjs.com/es6/ch_classes.html
Arrow functions https://exploringjs.com/es6/ch_arrow-functions.html
New OOP features https://exploringjs.com/es6/ch_oop-besides-classes.html
Replace function expressions in object literals to method definitions https://exploringjs.com/es6/ch_oop-besides-classes.html#sec_new-features-obj-literals
New array and string methods, new number and Math features
New primitive type Symbol https://exploringjs.com/es6/ch_symbols.html#sec_overview-symbols
Template literals https://exploringjs.com/es6/ch_template-literals.html
Generators https://exploringjs.com/es6/ch_generators.html
Proper Maps and Sets https://exploringjs.com/es6/ch_maps-sets.html
for-of loop https://exploringjs.com/es6/ch_for-of.html
Promises https://exploringjs.com/es6/ch_promises.html
Proxies, for metaprogramming https://exploringjs.com/es6/ch_proxies.html

10. Opt-in/out of experimental ES features

The Babel integration allows developers to take advantage of next-level and experimental EcmaScript syntax.

async/await https://exploringjs.com/es2016-es2017/ch_async-functions.html
decorators https://www.simplethread.com/understanding-js-decorators/, https://www.sitepoint.com/javascript-decorators-what-they-are/
spread operator for object literals https://exploringjs.com/es2018-es2019/ch_rest-spread-properties.html

11. Target specific browser versions

Imagine how great it would be if you could code-ify your application's supported browsers? Well, with Webpacker, you can.

Babel integrates with a package called browserlist which allows projects to codify the browsers they wish to target with their transpiled code. Developers set their version lists using queries, which can target specific browser versions or use semantics like last 2 versions to avoid updating versions manually. Browserslist uses data provided by Can I Use to determine browser support for newer frontend APIs.

Now we can write future JS syntax:

const array = [1, 2, 3];
const [first, second] = array;

Babel will compile it for Edge 16:

const array = [1, 2, 3];
const first = array[0],
      second = array[1];

Browserlist: https://github.com/browserslist/browserslist

12. Polyfill newer browser APIs

Building on number 11, Webpacker's use of @babel/preset-env to makes it possible to specify more easily what new JavaScript APIs to polyfill automatically.

It works by inserting this code at the top of your dependency graph:

import 'core-js/stable'

If chrome 71 is targeted, then this will get replaced with:

import "core-js/modules/es.array.unscopables.flat"
import "core-js/modules/es.array.unscopables.flat-map"
import "core-js/modules/es.object.from-entries"
import "core-js/modules/web.immediate"

Now you can start removing those conditionals you've been adding to test for browser support.

13. Use TypeScript

TypeScript has gained in popularity in recent years.

It brings static-typing to frontend development, allowing developers to catch errors more easily and productivity gains via integrations with supporting JavaScript IDEs, like VS Code. It's even possible to adopt TypeScript iteratively; as a superset of plain JavaScript, any valid JavaScript program is a valid TypeScript program. Webpacker provides an installer to make it easier to add to your Rails project.

14. Unlock powerful new tools

The Webpack compilation and build process provide a large number of hooks to allow behavior modification at nearly any stage. Here is a shortlist of ways you can extend Webpack to meet the needs of your system:

Unit testing through the Rails asset pipeline has always felt like jumping through hoops; now take your pick of JavaScript unit testing tools like Mocha or Jest.
Integrate with eslint to standardize code style and syntax and automate fixes
Add a plugin to analyze the size and contents of your bundles, e.g. WebpackBundlerAnalyzer
Add a loader to parse your Rails i18n yaml files and provide them as JSON to your Webpack JavaScript modules
Add a plugin to produce "unfingerprinted" clones of your bundles, as with https://github.com/alexspeller/non-stupid-digest-assets

One of my favorite Webpack-friendly addons is Storybook. It's a newer tool that allows developers to build components in isolation from the Rails server. This is a great way to represent your UI in various states all in one place without having to mess with real data in your development environment.

15. Modify source code programmatically

Webpack provides some configuration options that make it easy to modify the output of a module. For example, to "provide" the jQuery import to all modules in your source files, you can add the ProvidePlugin.

This really becomes important if you're attempting to upgrade a legacy Rails app to Webpack. Many older jQuery plugins, for example, assume jQuery is available in the global scope. The ProvidePlugin configured as follows will instruct Webpack to "shim" legacy modules with a require('jquery') statement if necessary:

// config/webpack/environment.js

const webpack = require('webpack');

const {environment} = require('@rails/webpacker');

environment.plugins.append(
  'jquery', // arbitrary name
   new webpack.ProvidePlugin({
    $: 'jquery',
    jQuery: 'jquery',
    'window.jQuery': 'jquery'
   }),
);

module.exports = environment;

Documentation: https://webpack.js.org/guides/shimming/

16. You can still "require_tree" and then some

Sprockets comes with a few conveniences for including files in your asset bundles including require_tree. Similarly, Webpack also has a function for including multiple files in a single statement: require.context. Though more verbose, it's also more powerful. It provides a file filter option, say if you only want to import .svg files. You can also operate on the return value.

Syntax:

require.context(directory, useSubdirectories = true, regExp = /^\.\/.*$/, mode = 'sync');

Example: require all the test files in the current and nested directories.

require.context('.', true, /\.test\.js$/);

Example: import all the default exports in the current directory and re-export as named modules

const requireModule = require.context('.', false, /.js$/)

context.keys().forEach(filename => {
  const moduleConfig = requireModule(filename)

  // Get PascalCase name of module from filename
  const moduleName = upperFirst(
    camelCase(
      filename.replace(/\.\//, '').replace(/\.\w+$/, '')
    )
  )

  export {[moduleName]: moduleConfig.default}
})

Documentation: https://webpack.js.org/guides/dependency-management/#requirecontext

17. Automatic static code splitting

In Sprockets, a common technique to reduce bundle size and improve cacheability is to move all the vendor code into a separate bundle:

<!-- app/views/layouts.application.html.erb -->
<%= javascript_include_tag "vendor" %>
<%= javascript_include_tag "application" %>

One headache with this approach is having to manually account divvy up the bundles and take great care to avoid load order issues or omitting key dependencies.

Since Webpack statically analyzes your source code to build its dependency graph(s), it can also be configured to automatically create separate bundles for vendored and application code. This means, from a single "pack", Webpack will produce the vendor and application bundles for you, along with the Webpack runtime. Webpacker helpers and config can be used as follows to enable this behavior.

// config/webpack/environment.js

const { environment } = require('@rails/webpacker')

environment.splitChunks()

module.exports = environment

<!-- app/views/layouts/application.html.erb -->

<%= javascript_packs_with_chunks_tag "application" %>
<!--
<script src="/packs/vendor-16838bab065ae1e314.chunk.js"></script>
<script src="/packs/application~runtime-16838bab065ae1e314.chunk.js"></script>
<script src="/packs/application-1016838bab065ae1e314.chunk.js"></script>
!>

No more manual code splitting.

Documentation: https://webpack.js.org/plugins/split-chunks-plugin/

18. Automatic dynamic code splitting

An even better option to split your JavaScript code over multiple files is to use "dynamic imports". This approach requires absolutely zero config changes. It is the very reason that Webpack's creator made Webpack in the first place.

When Webpack detects a dynamic import function, like the following, in your application code, it will create a separate bundle for that import and load it asynchronously when that code is executed in the browser.

import('pdfjs/webpack').then(({default: pdfjs}) => { // async import!
  pdfjs.getDocument('https://example.com/some.pdf')  // ...
})

This technique can help reduce initial download size, help avoid loading JavaScript code unnecessarily, and potentially improve time-to-interactive metric.

19. Use state-of-the-art CSS processing

If you've used Rails long enough, there's a good chance you've adopted SASS or SCSS and you may love it. That's fine! Webpacker supports SASS/SCSS by default. That said, Webpacker also integrates with a newer tool called PostCSS.

PostCSS, relatively new on the scene, allows developers to transform CSS with JavaScript. It's a pluggable tool that can be configured to enable various capabilities; Webpack configures PostCSS to apply some fixes for flexbox bugs and to use a preset-env plugin to polyfill newer CSS capabilities for older browsers, similarly to @babel/preset-env does for JavaScript.

One of my favorite PostCSS plugins is PurgeCSS, which lets you delete unused CSS by comparing your CSS with your HTML markup and/or templates. Such a tool is invaluable when adopting a framework like TailwindCSS, which provides a ton of utility classes, many of which you're unlikely to use in production code.

20. Get asset compilation out of the Rails developer server

With Sprockets in development, automatic compilation and recompilation of static assets is handled through the Rails server. This can become a bottleneck with the ruby process doing double-duty. With the webpack-dev-server, however, asset compilation moves into a separate process so asset compilation can occur independently of the Rails server responding to requests.

The webpack-dev-server is a simple Node.js web server that watches for file changes in your source code directory, triggers Webpack to recompile when changes are detected, and serves the compiles assets from memory. It can also, via websocket listener automatically inserted in the browser, autoreload the development browser window when autocompilation completes, if desired.

21. Update code in development without reloading the page

Imagine being able to replace the implementation of a JavaScript module in the browser without having to reload the page. That's Hot Module Replacement (HMR). Not only does this allow for near-instant updates of only code that's changed, but application and DOM state is retained, meaning there's no need for extra clicks and typing to achieve the desired UI state. There are some gotchas to be aware of when using this tool, but generally speaking, it's a powerful way to speed up development.

Documentation: https://webpack.js.org/concepts/hot-module-replacement/

22. Take advantage of source map options

Given your JavaScript and CSS source code may be written in one form but compiled to another in development and production, source maps can help fill the gap. Most evergreen browsers support the loading and rendering of source maps in the browser dev tools to allow developers to link the code that's loaded in the browser to the code that lives in your source. It's a really good tool to have in your toolbelt.

Sprockets recently brought source maps to the Rails asset pipeline. In Webpack, they've been there since its early days and they're highly customizable; there are over twenty types of source maps supported in Webpack meaning there's a strategy for almost every use case. One reason for this much variety is that source maps must be generated as a separate file from your ass bundles so there's a build performance cost. You can save time with the tradeoff of fidelity.

The main point is with Webpack you've got a ton of choice.

WTF is a source map? https://schneems.com/2017/11/14/wtf-is-a-source-map/
Guide to source maps in sprockets: https://github.com/rails/sprockets/blob/master/guides/source_maps.md
Webpack source map documentation: https://webpack.js.org/configuration/devtool/

23. Implement performance budgets

The first rule of optimization is "Measure first". When it comes to optimizing frontend performance, the first developer I look to for advice is Addy Osmani.

One of his key strategies for measuring frontend performance is "performance budgeting" and how this relates to "time-to-interactive" (TTI). The thinking is you may be able to put a value on the TTI experienced by users of your application and that value is closely correlated with the amount of JavaScript you force your users' browsers to download and execute. By limiting the payload size of the initial download, you may be able to improve TTI.

What does this have to do with Webpack? Not only does Webpack make it easier to split up your bundles, as we saw with the code splitting sections above, but it also provides built-in support for performance budgets. You can customize Webpack to print a warning or even raise an error if any bundle exceeds the configured maxEntryPointSize.

Start performance budgeting https://addyosmani.com/blog/performance-budgets/
Cost of JavaScript 2019 https://medium.com/@addyosmani/the-cost-of-javascript-in-2018-7d8950fbb5d4

24. Peek inside the bundles

One of my favorite tools for debugging Webpack is the webpack-bundler-analyzer. Add this to your build and it will generate an interactive treemap that visualizes the relative size and contents of all your bundles. Wondering how much lodash is adding to your overall bundle size? Use the bundle analyzer tool. Think there's a bug in with one of your dependencies or in your Webpack output? The bundle analyzer may help you identify it.

Project https://github.com/webpack-contrib/webpack-bundle-analyzer

25. Shaking the tree

I'd be remiss if I didn't mention one of the favorite JavaScript bundle buzzwords, tree shaking. All this means is that Webpack has the ability to remove unused code from your build when certain conditions are met. This typically means that the module(s) in question is an ES module, that Babel is configured to handle ES modules, and that there are no side effects from importing the module.

A good use case for tree shaking is lodash. When loaded in its entirety, the library adds around 75 kb to the resulting asset bundle.

import _ from 'lodash' // OR

import {map, uniq, tail} from 'lodash'

The following approach allows Webpack to limit the resulting file size:

import map from 'lodash/map'
import uniq from 'lodash/uniq'
import tail from 'lodash/tail'

Lessons on tree-shaking Lodash with Webpack and Babel https://www.azavea.com/blog/2019/03/07/lessons-on-tree-shaking-lodash/

Wrapping up

There it is. I hope this has been a good introduction to some exciting possiblities and use cases for adopting Webpack in your Rails app via Webpacker. Like I said earlier, there is a tradeoff that comes with the overhead of managing many smaller JavaScript dependencies along with overcoming the "barrier to entry" in getting up to speed with how Webpack works.

I, for one, feel the tradeoffs have been worthwhile.

A guide to NPM version constraints for Rubyists

Ross Kaffenberger — Wed, 29 Jan 2020 21:06:44 +0000

Originally published at rossta.net

In this post, I want to answer the following question for Rubyists:

What do the tilde ~ and caret ^ designations mean for version constraints in a package.json file?

To answer this question, we'll compare how Rubyists declare Ruby project dependencies in a Gemfile with conventions used to declare NPM module dependencies in a package.json file.

Of note, some projects use both Gemfile and package.json. For example, a newly created Rails 6 application will have generated a package.json file because, by default, it ships with Webpack and related NPM dependencies to compile JavaScript assets.

It might include a section like this:

"dependencies": {
  "@rails/ujs": "^6.0.0",
  "@rails/webpacker": "~4.2.1",
},

If you're a Rubyist and the version syntax looks odd, then this post is for you.

Version constraints in Gemfile

Like the Gemfile, package.json has a convention to specify version constraints. Both Ruby and NPM dependencies usually follow SemVer, which will format a constraint as major.minor.patch, i.e. the declaration "webpack": "4.41.2" indicates Webpack major version 4, minor version 41, and patch version 2.

Where they differ is in the use of special characters to declare acceptable ranges. Let's refresh the conventions used in the Gemfile.

To lock a gem dependency to an exact version, we would declare the gem's name and its version as follows:

gem "devise", "4.7.1"

A more optimistic constraint would be to provide an open-ended range that will install or update to a version of the gem that satisfies the range.

gem "devise", ">= 4.7"

To limit the upper end of the range, say, to allow minor updates up to the next major version:

gem "devise", ">= 4.7", "< 5"

This format has a shorthand notation, the squiggly arrow ~>, or the pessimistic version constraint.

gem "devise", "~> 4.7"

The upper-end of the range is determined by the smallest level of the declared constraint. For example,

"~> 4.7.1" matches ">= 4.7.1", "< 4.8.0"
"~> 4.7" matches ">= 4.7.0", "< 5.0.0"
"~> 4" matches ">= 4.0.0", "< 5.0.0"

To specify "no constraint", simply omit the version argument.

gem "devise"

For more info, check out the guide on RubyGems.

Version constraints in package.json

NPM conventions provide similar flexibility with alternate syntax.

Let's consider a package.json file that declares @rails/webpacker as a dependency, the following would enforce an exact version:

"@rails/webpacker": "4.2.1",

As with the Gemfile, comparison operators can be used as in the following examples:

">=4.2.1" matches greater or equal to 4.2.1
">4.2.1" matches greater than 4.2.1
">=4.2.1 <5" matches greater or equal to 4.2.1 and less than 5
"<5" matches less than 5

NPM supports alternate syntaxes for specifying ranges, including, but not limited to, caret ^ and tilde ~.

Tilde ranges

NPM ~ is like Gemfile ~>

Tilde ranges for NPM are equivalent to Ruby's pessimistic version constraint, the squiggly arrow ~>. In other words, the upper-end of the range is determined by the smallest level of the declared constraint:

"~4.2.1" matches ">= 4.2.1 <4.3.0"
"~4.2" matches ">= 4.2.0 <5.0.0"
"~4" matches ">= 4.0.0 <5.0.0"

Caret ranges

NPM ^ is like Gemfile ~> x.0 for versions 1 and up and ~> 0.x.0 for versions less than 1 and greater than 0.0.1

Caret ranges are another take on pessimistic version constraints that do not have a shorthand equivalent in Ruby, i.e., to my knowledge, they're a special breed. They allow patch and minor updates for versions >1.0.0, patch updates for versions <1.0.0 >=0.1.0, and no updates for versions <0.1.0 (except preleases, e.g. 0.0.3-beta). My understanding is that the caret is the answer for traditional SemVer, i.e., there will be breaking changes prior to 0.1.0, there may be breaking changes between minor versions prior to 1.0.0, and there may only be breaking changes between major versions above 1.0.0. Examples:

"^4.2.1" matches ">=4.2.1 <5.0.0" or "~4.2"
"^0.2.2" matches ">=0.2.2 <0.3.0" or "~0.2.2"
"^0.0.2" matches ">=0.0.2 <0.0.3"

Bonus syntax in package.json

NPM also supports hyphen ranges and x-ranges, neither of which have Gemfile equivalents as well.

Hyphen ranges

NPM hyphen-ranges are like separate comparison operators in a Gemfile

For hyphen ranges, range inclusivity is tied to specificity of the declared versions:

"4.2.1 - 5.4.2" matches ">=4.2.1 <=5.4.2"
"4.2 - 5.4.2" matches ">=4.2.0 <=5.4.2"
"4.2 - 5" matches ">=4.2.0 <=6.0.0"

X-ranges

NPM x-ranges behave like Gemfile ~> with exceptions

X-ranges are mostly self-explanatory as the x denotes any value:

"4.2.x" matches "~4.2.0" matches ">= 4.2.0 <4.3.0"
"4.x" matches "~4.0" matches ">= 4.0.0 <5.0.0"
"4.x.x" matches "4.x"

A partial version range is treated as an x-range:

"4.2" matches "4.2.x"
"4" matches "4.x.x"
"" matches "*" matches any version

Conclusion

For Rubyists out there who needed an introduction to NPM version constraints, I hope this was a helpful guide, or perhaps, a future cheatsheet.

Mostly I wrote this for myself because I tend to forget 😅.

What new/upcoming Web API(s) are you most excited about? Why?

Ross Kaffenberger — Tue, 28 Jan 2020 13:16:36 +0000

One of my favorite pages to explore on MDN is the directory of Web APIs. I barely know what many of them are, but it's interesting to learn about and test out newly available browser features and what may be lurking on the horizon.

A couple relatively new features are the MutationObserver and IntersectionObserver. I've used both to solve different problems in recent projects of mine: to be notified when an element is added to the DOM asynchronously (mutation) or to be notified when an element comes enters the viewport (intersection).

What WebAPI captures your interest?

What programming language(s) do you want to learn in 2020?

Ross Kaffenberger — Sun, 26 Jan 2020 13:56:34 +0000

I’m not sure if this counts as a new language, but I want to learn TypeScript this year. I’ve used JavaScript my entire career and now I’m finally curious to see for myself what all the hype is about.

What are your thoughts on how open source maintainers solicit for financial support?

Ross Kaffenberger — Sat, 25 Jan 2020 14:52:59 +0000

3 ways Webpack surprises web developers

Ross Kaffenberger — Fri, 17 Jan 2020 22:52:18 +0000

Originally published at rossta.net

When I first started working with Webpack, I didn't realize how under-prepared I was. I was tasked with integrating Webpack into a large Rails app and I made a lot of mistakes along the way. I assumed how things should behave based on my previous experience with the Rails asset pipeline. Many of these assumptions turned out to be wrong. This was frustrating and humbling.

And after spending the last month answering Webpack questions on StackOverflow, I've come across plenty of folks going through some of the same mental hurdles I've experienced. I came away with some perspective on what about Webpack most commonly trips up developers.

The intended audience for this post has a general notion of "why use Webpack" or "why use an asset bundler", but for more on that, I recommend The Many Jobs of JS Build Tools and Webpack from Nothing: What problem are we solving?. For a rigorous technical overview of the project, I suggest the Webpack docs; they have gotten quite good.

For this post, we're going to look at three common surprises web developers face when learning Webpack: why using global variables doesn't behave the way you might think, how Webpack treats everything as a JavaScript module, and the big learning curve for configuring Webpack effectively.

1. Global variables are not your friend

I learned to program using script tags and html files loaded directly in the browser. I tied everything together with global variables. It was great.

And for better or worse, every Rails I've worked on, and it's been dozens over the years, has relied on global variables and script tag snippets to make things work. Here is a basic example:

<!-- app/view/posts/index.html.erb -->
<%= @posts.each do |post| %>
  <!-- ... -->
<% end %>
<a href="#" class="button--show-more">Show more</a>

<script>
  $('.button--show-more').click(function() {
    MyApp.fetchPosts() // etc...
  })

  // MyApp and $ are global variables
</script>

This approach is typical with old-school bundlers like the Rails asset pipeline because they concatenate JavaScript dependencies in the global scope. This, despite the general notion that global variables are bad. Notably, the Rails asset pipeline came into existence before the rise of Node.js and, subsequently, formal JavaScript modules, and it never adapted. Many prefer this way of doing things. I still lean on global variables now and then.

Things work differently in Webpack. It does not expose its bundled modules to the global scope by default. To reference code in another module, it expects explicit imports that reference that module's explicit exports. The scope in which modules are evaluated is local, not global, i.e., the contents of each file are wrapped in a function.

Things are trickier if we expect to access bundled JavaScript from HTML, like MyApp.fetchPosts() above. Options include manually attaching variables to the global scope, e.g. window.$ = require('jquery') or modify the Webpack configuration to "expose" variables globally, as is demonstrated in this StackOverflow post (and many others).

This serves as an illustration of how a legacy practice would be swimming upstream in a Webpacker-enabled app: it takes effort.

But why?

Webpack is a module bundler

Webpack describes itself as "a static module bundler for modern JavaScript applications". For developers used to unfettered access to JavaScript global scope, the switch to working in a modular system comes as a surprise. I argue that adopting Webpack effectively means understanding JavaScript modules.

So what then is a JavaScript module?

For a fantastic introduction to JavaScript modules, I suggest Preethi Kasireddy's Javascript Modules: A Beginner's Guide on freeCodeCamp. I'll attempt to summarize.

Generally speaking, a JavaScript module is a self-contained, reusable piece of code. This definition though is inadequate to capture the behavior of various flavors of JavaScript modules, ranging from simple patterns to formal systems supported by common JavaScript runtimes.

In recent years, several popular JavaScript module definitions have become widely adopted, each with their own characteristics, including CommonJS, Asynchronous Module Definition (AMD), and EcmaScript (ES) Modules to name a few.

Webpack can be configured to recognize any of these module formats.

Webpack transpiles your application's source files into JavaScript modules the browser can understand. It adds code to your bundle to tie these modules together. This has implications for how developers write code which means the old-school patterns that worked with the Rails asset pipeline may not work in the Webpack context.

Avoid legacy code if you can

Some of the most frequent Webpack issues that pop up on StackOverflow highlight this disparity between the context in which Webpack works best and the context for which legacy code was written.

Consider any jQuery plugin in your app that's more than a few years old; any one of them may not play nice with Webpack. The plugin system in a way is a relic of the pre-module era; attaching to a global variable was the easy way to reuse and reference functionality across the app.

Many jQuery plugins (or many legacy plugins in general) have been written without awareness of JavaScript modules and assume execution within the global scope. Be ready to weigh the tradeoff of learning how to configure Webpack to play nicely with legacy code or replace it with something else altogether.

In Webpack, global variables are not your friend, my friend.

2. Webpack treats everything as a JavaScript module

Webpack is so committed to its "module bundler" role it treats other static assets, including CSS, images, fonts, etc., as JavaScript modules too.

Say what?

When I first learned this about Webpack, I was totally confused: How does Webpack produce stylesheets out of JS? How would I reference the an image tag's src for bundled images? What does it mean to import an image module in JavaScript?

It helps to understand that Webpack must be configured, typically with loaders or plugins, to handle different various files types as modules. How Webpack processes various file types as output depends which loaders are used.

Many projects integrate with Babel to process JavaScript files written with ES2015+ syntax. CSS files might be bundled as JavaScript Blob objects that are dynamically inserted in the DOM; otherwise it can be extracted into a CSS stylesheet a side-effect of module compilation.

Webpack only needs one JavaScript file in your source code as an entry point to produce a dependency graph of all the JavaScript, CSS, images, fonts, svg, etc. that you intend to bundle as static assets for the browser.

An interesting consequence of Webpack putting JavaScript first is there only needs to be one entry point to produce both a JavaScript and a CSS bundle. In the Rails asset pipeline, the JavaScript and CSS source code is kept completely separate:

app/assets
├── javascripts
│   └── application.js   # produces js bundle
└── stylesheets
    └── application.css  # produces css bundle

In Webpack everything hangs off the javascript entry point, or "packs". So assuming you have statements like import 'styles.css' somewhere in your JavaScript dependency graph, both application.js and application.css bundles will be produced.

app/javascript
└── packs
    └── application.js   # produces both js and css bundles

The mixing of CSS bundled in JavaScript and treated as JavaScript modules has isn't strictly necessary, but it most certainly a mental leap for the uninitiated.

3. Webpack configuration is extreme pluggable

There's a reason Webpack configuration has such a high barrier to entry: Webpack is the ultimate delegator.

Coming from Rails, which famously values "convention over configuration", the ergonomics of setting up a Webpack configuration cause discomfort. It aims to be extremely flexible and extensible; to that end, it succeeds superbly. To serve this goal, Webpack provides a large array of configuration options. On top of that, most Webpack configurations bring in a number of loader and plugins, each of which have their own configuration requirements.

Faced having to learn Webpack, Babel, PostCSS, not to mention, Webpacker's abstractions around Webpack, it's no wonder we're intimidated. That's a lot to wrap your head around.

One of Webpacker's goals, in a similar fashion to create-react-app and the vue-cli, is to provide a Webpack config with sane defaults, i.e. the "convention". Depending on your project's needs, these "out-of-the-box" setups may get you quite far. Unfortunately, for any non-trivial modification, like getting a large legacy library to work with global variables or optimizing your build time by splitting out vendor dependencies, developers must be prepared to dive into the documentation and search for answers far and wide on StackOverflow and Medium.

4. Bonus: Webpack is a powerful tool

I've grown to love Webpack and, I admit, this appreciation was hard-earned. As I've gotten over the initial hurdles of making my Webpack config work for my projects, I've come to value a number of Webpack's benefits, including optimizing bundle size through tree-shaking, code splitting via asynchronous dynamic imports and the split chunks plugin and support for preloading and prefetching. All of these features are virtually non-existent in the Rails asset pipeline.

These major strengths of Webpack all boil down to improving user experience: using it effectively can help improve metrics like Time-to-Interactive and First Contentful Paint. These things matter and are ever more crucial as we lean more heavily on client-side code build rich interfaces delivered across a widening array of devices and networks.

Webpack receives a fair number of criticisms regarding its complexity and some of its surprising traits, like the ones I highlighted here. To be fair, Webpack aims to solve a complex problem and solves it quite well. Other asset bundlers are worth your consideration, but, arguably, no other bundler has been as successful.

As we saw in the recent announcement from @dhh and the release of Rails 6 last year, Webpack is now the default JavaScript compiler for Rails. Looks like Rails developers will be looking to adopt Webpack in their applications, though as we've seen today, they may be in for a few surprises.

Importing images with Webpack(er)

Ross Kaffenberger — Thu, 19 Dec 2019 22:46:14 +0000

Originally published at rossta.net

Webpack isn't just for JavaScript. You can bundle images with it too. Webpacker makes it relatively easy to work with images, but it is admittedly confusing at first: Images in JavaScript?

In this post, we'll demonstrate how to reference Webpacker images from your JavaScript, CSS, and Rails views. The following examples were created using Rails 6 and Webpacker 4, but may work with other versions as well. Pre-requisites for working with Webpacker in a Rails project also include yarn.

Folder structure

First, where should you put your images? It doesn't matter. The easiest place to start is under your app/javascript folder, the default source path for Webpacker, such as app/javascript/images.

For the rest of this guide, we'll assume the following directory structure and files:

app/javascript
├── components
│   └── Taco.js
├── css
│   ├── main.css
├── images
│   ├── burritos.jpg
│   ├── guacamole.jpg
│   └── tacos.jpg
└── packs
    └── application.js

Isn't weird to put images and css in a folder called "javascript"? Depends. If you consider, from Webpack's perspective, everything is a JavaScript module, it may not be so strange. Otherwise, it's possible to rename app/javascript or place your images elsewhere. More on that below.

Images in JS

To reference an image from JavaScript in your Webpacker build, simply import it like any other module. React is not required for this to work ;)

// app/javascripts/components/Taco.js
import TacoImage from '../images/tacos.jpg'

export default function({ title }) {
  return `
  <div>
    <h1>${title}</h1>
    <p><img src=${TacoImage} alt="Tacos, yum" /></p>
  </div>
  `
}

In the example above, Webpack will import TacoImage as a url to the file. In other words, an "image module" in Webpack exports a single default value, a string, representing the location of the file. Based on the default Webpacker configuration, the filename will look something like /packs/media/images/tacos-abcd1234.jpg.

Importing a image also works if you're using "CSS in JS" to style a React component.

import React from 'react'

import TacoImage from '../images/tacos.jpg'

const styles = {
  backgroundImage: `url(${TacoImage})`,
}

export default function ({ title }) {
  return (
    <div style={styles}>
      {title}!
    </div>
  )
}

Interested to learn more about Webpack on Rails? I'm creating a course.

Subscribe to rossta.net to get updates.

Images in CSS

In Sprockets, when referencing images in CSS, you would use a special image-url() helper. In Webpack, simply use the standard url() expression in CSS with a relative path.

/* app/javascript/css/main.css */
.burritos {
  background-image: url("../images/burritos.jpg");
}

The output for the style rule will, again, look something like background-image: url(/packs/media/images/burritos-efgh5678.jpg);. This technique will also work for image paths in CSS Modules.

Images in CSS within NPM modules

One tricky bit worth mentioning is bundling images referenced in SCSS within an imported NPM module. For example, many jQuery plugins bundle their own SCSS and image assets. When Webpack processes this vendored CSS, you may see an error like the following, like in this question on StackOverflow:

Module not found: Error: Can't resolve '../img/controls.png'

The problem is the path does not resolve properly relative to the output for this vendored SCSS. From the Webpacker docs:

Since Sass/libsass does not provide url rewriting, all linked assets must be relative to the output. Add the missing url rewriting using the resolve-url-loader. Place it directly after the sass-loader in the loader chain.

To fix this, you may need to get your hands dirty with some Webpacker configuration. Add the resolve-url-loader and configure in config/webpack/environment.js:

yarn add resolve-url-loader

// config/webpack/environment.js
const { environment } = require('@rails/webpacker')

// resolve-url-loader must be used before sass-loader
environment.loaders.get('sass').use.splice(-1, 0, {
  loader: 'resolve-url-loader'
})

This loader rule, inserted in the loader pipeline for SASS/SCSS files, will ensure the proper url is written to the CSS output by Webpack.

Images in Rails views

You may be accustomed to <%= image_tag 'tacos.jpg' %> to reference a image bundled in the Rails asset pipeline. Webpack has a similar tag:

<!-- app/views/lunches/index.html.erb -->

<%= image_pack_tag 'media/images/guacamole.jpg' %>

Note, since Webpacker 4, the prefix media/ is necessary and the remaining path represents the location from your Webpack source path.

There's a catch. This change may result in the following error:

Webpacker::Manifest::MissingEntryError in Lunches#index
Showing /path/to/project/app/views/lunches/index.html.erb where line #4 raised:

Webpacker can't find media/images/guacamole.jpg in /path/to/project/public/packs/manifest.json.

The guacamole.jpg image was not found by Rails, but, if we were to try rendering the tacos.jpg image in our template, i.e, <%= image_pack_tag 'media/images/tacos.jpg %>, the taco image would happily render. What gives?

Your Rails app is not being selective about cuisine. The difference is, we earlier imported the tacos.jpg image in Webpack, but not guacamole.jpg.

One way to fix this issue is to import the guacamole.jpg image somewhere in your Webpack dependency graph. It's not necessary to grab a reference to the imported variable because we only care about the side effect of emitting the file for Rails to reference in the view.

import '../images/guacamole.jpg'

Another way to fix this issue is to import all images in the app/javascript/images directory. Webpack provides a special function to import many files in a directory in one expression: require.context. You might add this to your application.js pack:

// app/javascript/packs/application.js

require.context('../images', true)

This expression will recursively require all the files in the images directory. As a result, we can now render guacamole.jpg in a Rails view.

Note: I only recommend using require.context for your images if you need to render them in your Rails views; require.context is NOT necessary to import images into JS files like your React components, as illustrated earlier.

Reconfiguring

If you don't feel comfortable with app/javascript as the source directory for images, you can either rename the source path or add to the set of resolved paths.

To rename app/javascript, rename the directory and tell Rails about it in config/webpacker.yml

default: &default
  source_path: app/frontend

To add to the set of resolved paths where Webpack should look for assets besides in app/javascript:

default: &default
  resolved_paths:
    - app/assets

Diving Deeper

I have to admit, a few years ago, when I first heard about Webpack, I was super-confused. I understood it to be a JavaScript module bundler. How on Earth does it handles images?

The short answer, of course, is it depends. Generally, Webpack will treat everything it can understand as a JavaScript module. To help Webpack understand images, projects would add a "loader" (or loaders) to the Webpack configuration. A suitable loader would know how to handle an image file and output a representation of something, like an inlined base64 string, that can be manipulated in JavaScript.

To help Webpack understand images, svg files, and fonts in your Rails project, Webpacker adds the file-loader package. This package will emit the imported file as a side effect of the build and return a path to the file as the module contents.

For more on how Webpack works with images, check out the asset management docs.

I also put together a sample Rails 6 Webpacker demo project on GitHub for more context:

Overpacking: A Common Webpacker Mistake

Ross Kaffenberger — Thu, 05 Dec 2019 22:52:00 +0000

Originally published at rossta.net

I recently encountered a Rails app at work that was spending nearly seven minutes precompiling assets:

I looked in the Gemfile and found the project was using Webpacker. My spidey sense started to tingle.

I've seen this before.

Leaning on prior experience, I found the problem, moved some files around, and pushed a branch with the fix up to CI.

The build step dropped from nearly seven minutes to less than one. Big improvement! When I heard from the team, the fix also greatly improved the local development experience; before, re-compiling Webpack assets on page refreshes would take a painfully long time.

So what were the changes?

A Common Problem

First, let's take a step back. If you're new to Webpack and Webpacker for Rails, chances are you may be making some simple mistakes.

I know this because I was once in your shoes struggling to learn how Webpack works. I've also spent a lot of time helping others on my team, on StackOverflow, and via rails/webpacker Github issues.

One of the most frequently-reported issues I've seen is slow build times. This is often coupled with high memory and CPU usage. For Heroku users on small dynos, resource-intensive asset precompilation can lead to failed deploys.

More often than not, the root cause is a simple oversight in directory structure—a mistake I call "overpacking".

Overpacking explained

Here's the layout of the app/javascript directory in the Rails app before I introduced the fix:

rake assets:precompile — 6:56

app/
  javascript/
    packs/
      application.js
      components/     # lots of files
      images/         # lots of files
      stylesheets/    # lots of files
      ...

Here's what the project looked like building in under a minute:

rake assets:precompile — 0:44

app/
  javascript/
    components/
    images/
    stylesheets/
    ...
    packs/
      application.js    # just one file in packs/

See the difference?

The primary change here was moving everything except application.js outside of the packs directory under app/javascript. (To make this work properly, I also had to update some relative paths in import statements.)

Webpack Entry Points

So why did this matter?

Webpack needs at least one entry point to build the dependency graph for produce the JavaScript and CSS bundles and static assets (images, fonts, etc).

The Webpacker project refers to entries as packs.

"Entry" is listed as the first key concept on Webpack's documentation site: https://webpack.js.org/concepts/#entry.

Webpack will build a separate dependency graph for every entry specified in its configuration. The more entry points you provide, the more dependency graphs Webpack has to build.

Since Webpack*er*, by default, treats every file in the packs directory as a separate entry, it will build a separate dependency graph for every file located there.

That also means, for every file in the packs directory, there will be at least one, possibly more, files emitted as output in the public directory during precompilation. If you're not linking to these files anywhere in your app, then they don't need to be emitted as output. For a large project, that could be lot of unnecessary work.

Here's a case where Rails tries to make things easier for you—by auto-configuring entry files—while also making it easier to shoot yourself in the foot.

A Simple Rule

Is your Webpacker compilation taking forever? You may be overpacking.

If any file in Webpacker's "packs" directory does not also have a corresponding javascript_pack_tag in your application, then you're overpacking.

Be good to yourself and your development and deployment experience by being very intentional about what files you put in your "packs" directory.

Don't overpack. At best, this is wasteful; at worst, this is a productivity killer.

Interested to learn more about Webpack on Rails? I'm creating a course.

Subscribe to rossta.net to get updates.

Cover photo by Brandless on Unsplash

Vue.js is omakase

Ross Kaffenberger — Wed, 09 Jan 2019 04:06:53 +0000

I'm borrowing from David Heinemeier Hansson here. Six years ago, he wrote Rails is omakase to capture his notion of what makes a delicious software framework: it is heavily curated and borne of experience. I think of Vue.js the same way.

Here's an excerpt from DHH's post:

There are lots of à la carte software environments in this world... I want this for my ORM, I want that for my template language, and let's finish it off with this routing library... It's a very popular way of consuming software. Rails is not that. Rails is omakase. A team of chefs picked out the ingredients, designed the APIs, and arranged the order of consumption on your behalf according to their idea of what would make for a tasty full-stack framework. The menu can be both personal and quirky. It isn't designed to appeal to the taste of everyone, everywhere.

I love this metaphor, because a) Rails, including all its API choices and baggage, has treated me very well throughout my career in tech, and b) I love me some agedashi tofu.

What does this have to do with Vue? I believe Vue's growing popularity is partly due to its highly selective maintainers and that the recommended ingredients, though not to everyone's taste, are well-suited to most projects, big and small.

Enjoy a multiple-course meal

Vue articulates many courses making up the full meal for a frontend framework. These days, developers have come to expect a robust API to build components and a fast implementation built on top of a virtual dom. However, Vue.js doesn't stop there. For Vue developers, the framework and its ecosystem provide adequate if not excellent implementations of orthogonal dependencies that solve problems many non-trivial apps eventually need.

The offering includes the Vue Router, Vuex for state management, and the Vue test utils for unit testing. Through the Vue CLI, developers also get sensible defaults in Webpack configuration for hot module replacement, code-splitting, tree-shaking, efficient long-term caching, while having access to pre-configured opt-ins for TypeScript, Progressive Web Apps, ESLint, and multiple test runners.

There is great comfort in knowing that the Vue team is behind these projects and they complement one another appropriately in my Vue.js applications.

Substitutions cost little extra

So you may not agree with everything on the menu. That's fine! Many of the defaults are easily changed through configuration or add-ons. Want to use Redux? No problem! Class-style syntax? The customer is always right. Don't like mustache-style curly braces in templates? You can change it! Maybe you can't stand the fact that Vue has templates at all and would prefer to use JavaScript. Well, that's ok too; add another Babel plugin, and you can write Vue components with JSX inside of render functions a lot like React.

As another example, let's talk about Webpack. I think it is a fantastic piece of software. I've spent months learning how it works. I have given a conference talk about it. However, usually, most of us, myself included, don’t want to maintain a custom configuration from project to project when we have deadlines to meet. The Vue CLI defaults are just fine. Still need to customize? Vue provides an API to extend the base configuration while making it easier to upgrade to take advantage of framework-supported improvements. There's also nothing stopping you from ditching Webpack for Parcel or Rollup or whatever other transpiler or module bundler you prefer.

An opinionated chef

The core team consistently shows restraint in decided what features and improvements to fold into the framework. For example, much has been made of Vue's choice to avoid class syntax for components as the default, e.g. this issue on GitHub. There are excellent reasons for this decision, one of which is for Vue to work without a build environment. As a feature, this makes Vue incredibly easy to get up-and-running, for beginners learning the framework or for seasoned developers trying out a quick prototype. "It will fail," some said. I suppose that remains to be seen, but after several years of arguing, the framework continues to thrive.

A consistent experience for all customers

Scott Molinari made this comment on a previous post of mine:

once the usage of the API is down pat, anyone and everyone who knows Vue is basically doing the same thing. This also means the need for best practices are held to a minimum and both of these advantages mean cognitive load over time is reduced. i.e. when you dig into someone else’s component, you understand it quickly. This all in turn means Vue code is more robust and in the end, it’s of higher quality.

This point is especially important for both beginners and experienced developers alike. One of the significant tradeoffs to cobbling libraries together is that it can be harder to transition into new projects or unfamiliar parts of a large codebase. This approach may pay off for the right teams. In most cases, those tradeoffs aren't worth it to me because I place much value on consistency.

When my late wife and I lived in New York City, our favorite restaurant was Zenkichi. The cuisine is Japanese brasserie, but the experience is so much more. If you make it to the Williamsburg neighborhood in Brooklyn, you should try it.

It's housed in a small building with a wooden exterior and no discernable markings. Located near the East River in the Williamsburg of Brooklyn, it's easy to miss from the outside.

The interior is dark, romantic, hand-crafted. Each table upstairs is like a small private dining room with a pull-down curtain and a small buzzer to summon the wait staff.

Everytime we ate there, we chose the omakase menu. We left all the decision-making up to the chef. It's difficult at first to place that kind of trust in someone else's judgment. Giving up control is uncomfortable. However, this led to some delightful discoveries. Of course, not all the courses were to our liking. Nevertheless, we loved the experience.

The chef’s menu need not be reserved for special occasions in web development. With Vue.js, we have a framework that gives us all the ingredients we need to jump into building outstanding user interfaces. It also makes it relatively easy to swap out menu items to suit your preferences. So it would seem you can have your cake and eat it too? Just another reason why I find Vue.js so fulfilling.

Did you like this post? Subscribe to my newsletter on rossta.net and I'll send you an occasional email about web development with Vue.js

Originally published at rossta.net.

Seven reasons to learn Vue.js in 2019

Ross Kaffenberger — Tue, 01 Jan 2019 13:00:09 +0000

I love building applications in Vue.js and here's why I think the future is looking bright for the framework and its community.

1. No build step required

A critical aspect of the Vue philosophy is it be easy to get started. Unlike some other popular frameworks, it's not necessary to use a complex build tool like Webpack to build an application with it. Just include a script tag pointing to the latest release for development or production, and you have access to the Vue runtime.

<script src="https://cdn.jsdelivr.net/npm/vue@2.5.21/dist/vue.js"></script>

Having a low barrier to entry makes Vue a worthy consideration as a first JS framework to learn.

2. A world-class command line interface

Of course, many developers are looking for advanced development features like ES or TypeScript transpilation, hot module replacement, and tree-shaking, made possible by build tools. Vue has you covered there as well.

npm install -g @vue/cli
vue create my-project

This past year, the Vue core team re-wrote their command line interface from the ground up, resulting in Vue CLI 3. It's designed in such a way to promote best practices and a full-featured default Webpack configuration that should be easier to extend without making it difficult to upgrade, i.e., "no need to eject." Vue CLI provides a ton of useful additional features, including an interactive project initialization wizard (available through the terminal or a web-based UI), a plugin system to support generators and configuration for community add-ons, and the ability to specify alternative build targets, like web components or as libraries.

3. Friendly learning curve

A common criticism I hear about Vue is that its API has a larger surface area than some other popular frameworks and I agree up to a point (depending on the framework). Ironically, another thing I hear over and over is Vue is easy to learn. Though subjective and anecdotal, this has held for folks I've heard from regardless of previous experience with JavaScript frameworks and JavaScript in general.

One reason, I believe, is that Vue is a "progressive JavaScript framework."

No need to learn the whole API to get started with Vue, no need to learn a new syntax like JSX; only basic HTML, CSS, and JS knowledge is required to get started.

4. A solid ecosystem

Before Vue, I've gotten frustrated with the fractured nature of learning best practices beyond the basics. What client-side router should I use? Which data management/Flux implementation should I use? How do I test my components? How should I configure my build system? Over time, answering these questions has gotten easier, depending on the community, but I've liked Vue's approach since the start.

Vue provides official support for several essential add-ons, including vue-router for client-side routing, vuex for managing state, vue-test-utils for unit testing components, the vue-devtools browser extension for debugging, Vue CLI as described earlier. None of these tools are required Vue can work quite well with alternatives for these libraries, like redux or mobx instead of vuex, or another router. The critical point is that the community assists developers by supporting a set of very good recommended defaults, something that a backend framework like Ruby on Rails has traditionally done very well.

5. The Vue instance

The most potent aspect Vue is its reactivity system. We can tap into it through the Vue instance.

new Vue({
  el: "#app",
})

This invocation is how every Vue application is initialized. It also creates a fully-reactive root component of the application. A Vue instance can also be used as an event bus or for tracking dependency changes separately from the application component tree, say, as an implementation detail of a Vue plugin.

Vue's reactivity system is beautiful in its simplicity. Playing with the Vue instance is an excellent way to understanding how the reactivity system works and level up one's Vue, and JavaScript, skills in general.

6. Vue 3 lands this year

Speaking of Vue's reactivity system, Vue 3 is expected to ship this year. Among some architectural and performance improvements and minor API changes, Vue 3 provides a new Proxy-based implementation of its reactivity system.

The Proxy-based system solves some of the known caveats with Vue change detection:

In Vue 2, Vue cannot:

Detect property addition, e.g., vm.b = 2
Detect array modification through indexing or modifying length, e.g., arr[0] = 2

The workound: use Vue.set, e.g., Vue.set(vm, 'b', 2)

Vue 3 Proxy-based reactivity makes these annoying issues go away.

7. An amazing community

Since I've started using Vue, I've been fortunate to learn from a variety of Vue developers through forums, on Twitter and GitHub, and at local meetups. Vue has a distributed, hard-working core team, who are continually improving the framework without over-burdening developers with a bunch of fringe features or painful upgrades. The Vue forums is a great way to get insight from experts on tricky issues. Vue conferences, like VueConf.us and Vue Amsterdam, a great way to connect with other members of the community and attend more in-depth workshops, are already taking place all over the world. There's also Vue Vixens, an organization that provides safe environments for people who identify as women to learn Vue.js.

Bonus. It's just plain fun

I got my start in web development just as the Ruby and the Rails framework was taking off. One thing I have always loved about Ruby is creator Yukihiro Matsumoto's explicit (and, dare I say, audacious) goal of inventing a language optimized for developer happiness.

I get these same feelings when I build interfaces with Vue.js. I was spending less time wrestling with configuration and APIs and more time building and having fun doing it.

While I don't know that Vue.js was created so explicitly in the name of developer happiness, for, it has and continues to be fulfilling to that end. It's something I hear from many others who've taken time to learn the framework and probably the most important reason I'll recommend Vue.js in 2019.

So what are you waiting for? Best of luck with your Vue.js journey in the coming year.

Did you like this post? Subscribe to my newsletter on rossta.net and I'll send you an occasional email about web development with Vue.js