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.

Ross Kaffenberger

Originally published at rossta.net.

Vue.js is omakase was originally published in Vue Curious on Medium, where people are continuing the conversation by highlighting and responding to this story.

Mostly, because it’s so darn fun

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 that 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 for this, 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:

1. Detect property addition, e.g., vm.b = 2
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 Vue.js was created so explicitly in the name of developer happiness, 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 it’s 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.

Ross Kaffenberger

Seven Reasons to learn Vue.js in 2019 was originally published in Vue Curious on Medium, where people are continuing the conversation by highlighting and responding to this story.