DEV Community

Ross Kaffenberger
Ross Kaffenberger

Posted on

Vue.js is omakase

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.

Zenkichi food

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.

Zenkichi front entrance

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.

Zenkichi interior

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 and I'll send you an occasional email about web development with Vue.js

Originally published at

Top comments (17)

ben profile image
Ben Halpern

I'm developing more and more Vue fomo all the time. I've never had a reason to switch or rewrite in Vue, so haven't used it beyond for learning purposes, but I'd like to start something new in the framework.

jakedohm_34 profile image
Jake Dohm

If you ever want to chat about Vue, hack around on something together, or do a Vue stream or anything, feel free to hit me up 😉

ben profile image
Ben Halpern

Definitely, thanks!

rhymes profile image
rhymes • Edited

Vue CLI gives you all the tools you need to play with it:

sergiodxa profile image
Sergio Daniel Xalambrí

This is the things I like the most from Vue.js as a React developer. We need more omakase in React, not only community popular projects as React/Reach Router, but officially supported libs for more things.

pojntfx profile image
Felicitas Pojtinger

Disagree. This diversity and decentralization is the thing that makes React so awesome IMHO. It's UNIX philosphy.

rossta profile image
Ross Kaffenberger

I agree, this would really strengthen the developer experience for React.

rhymes profile image

Great post Ross. I feel the same way about Vue. It's "omasakeiness" is the reason why it has a low entry barrier and that the documentation around is essentially universal because most people use VueJS the same way.

It's also a testament of the amount of thought that Evan You and the team had to put into creating a well designed API and lots of sensible defaults on any layer of the ecosystem.

Last year I was picking up a framework to write an app and I described my choice of Vue like this:

I gravitated towards Vue probably for the same reason I gravitated towards Python many years ago: I don't like complicated things. I like simple technologies that can handle complexity. React didn't attract me much (I have a thing for the underdogs, in life too :D), JSX didn't make sense to me and I fell in love with the "Single File Component" style in Vue and I was sure it could do everything I needed.

Omasake doesn't work all the time but it goes a long way and as you said, if
substitutions are cheap, it can work also for other people as well

rossta profile image
Ross Kaffenberger

Awesome, thanks for sharing. I was excited for React at first, but the cost of getting setup over several projects wore me out a bit. Vue goes a long way to improving the developer experience—a big win in my book.

revskill10 profile image
Truong Hoang Dung • Edited

Rails taught us a very important lesson: Omasake framework is only for one-off project, in which once released, no more maintainance , or too much to maintain.

A well-defined architecture should not depend on framework, or any library, those are implementation layer.

goyo profile image
Grzegorz Ziemonski

Like GitHub! Or Shopify! Or... oh wait.

revskill10 profile image
Truong Hoang Dung

Yes. If you have a team like theirs, nothing is impossible.
If you're a solo dev or small team, NO.

Thread Thread
ukazap profile image
Ukaza Perdana • Edited

Quite the opposite, really. A team of 3 rails devs are doing fine, GitHub didn't start out with hundreds of engineers, YES.

fernalvarez590 profile image
Fernando Alvarez

Beautiful post!

kylegalbraith profile image
Kyle Galbraith

Great post Ross! I haven't used Vue yet but your description of it is spot on with others I have talked to about it. Keep up the great writing.

rossta profile image
Ross Kaffenberger

Thanks for the kind words. I hope you'll decide to give it a try some time!