Starting a project from scratch without any legacy constraints can be nerve-wracking, but it can also be nerve-wracking. Unrestricted freedom to build apps can lead to a lot of wasted time researching and evaluating tools, which ultimately distracts from the actual work. Even if you make the best choice, you will always reconsider your backup plan. This is the “paradox of choice.”
Shared in this issue – all industry standard tools in the Vue ecosystem.
Package manager
There are 3 popular tools for working with external packages:
npmyarnpnpm
npmOld and slow. yarnIt’s faster and a solid choice. But overall, pnpmbest of all, it’s extremely fast and space-saving. pnpmUse each piece of code in many places without requiring extra copies. Additionally, pnpmmonorepo setup with minimal configuration is natively supported.
Personal suggestion: Package manager is preferredpnpm
Build tools
It should come as no surprise that Vite is recommended here. Vite uses native ES modules to achieve lightning-fast server startup. Vite has built-in support for hot module replacement, and also optimizes production builds through Rollup, ensuring small and fast loading packages. Additionally, the Vite is much easier to configure than other spare wheel options. Finally, Vite gets bonus points for being frame-agnostic.
Personal recommendation: Preferred choice of build toolsVite
Vue version
Vue 2 documentation still ranks highly in search engines and Stackoverflow, which can be a headache if we have to choose between versions. But fans, please remember that Vue 2 is no longer open source maintained, and Vue 3 is now a long-term supported version. Vue 3 has all the benefits of previous versions, but with a different syntax that takes advantage of the compositional API.
Personal suggestion: For the Vue version, give priority to Vue 3
SFC (Single File Component)
Keeping all the building blocks of a component in the same location is a major feature of Vue, SFC = template + style + script. If you think a component is getting stinky and long, then it’s better to split it into subcomponents. We can still use different files for each section, but please don’t.
Personal suggestion: give priority to SFC
routing
Vue has an official routing module that is deeply integrated with the Vue kernel, which makes building SPA (Single Page Application) a breeze.
Some great features include nested and dynamic routing, modular component-based configuration, routing parameters, transition effects, links with automatically active CSS classes, HTML5 historymode or hash mode, and customizable scrolling behavior.
Vue Router doesn’t get the publicity and credit it deserves due to the lack of alternatives, but it is indeed an extremely powerful and full-featured library.
Personal suggestion: give priority to Vue Router
Status management
This can be a bit of a head-scratcher, as Vuex was the official recommendation for years before Pinia replaced it. Pinia was written from scratch and integrates seamlessly with Vue 3’s compositional API architecture. Pinia is now the official recommendation for state management.
The only real alternative to Pinia is to use a custom composed function to save our state. This may be a good solution for mini-Apps, but since Pinia follows the same architecture, has a small footprint, enhanced performance, and development tool support, it is highly recommended.
Personal suggestion: use Pinia first
data request
Native fetchhas gained significant browser support and is considered a replacement for the popular axios library. VueUse also provides useFetchhooks with more advanced configuration options.
But here’s what I highly recommend vue-query. It simplifies data requests using a declarative syntax and elegantly handles a host of repetitive tasks, such as loading and error states, pagination, filtering, sorting, and caching.
Personal suggestion: For data requests, choose Vue Query first.
Component Marketing
I’m sure there are other options, but Storybook dominates to the point where all others are out of my mind. The real question is whether Storybook is worth the hype.
Personally, I do like using it to develop components individually. Storybook is faster and lets me understand every dependency of my components. Additionally, it can be a great form of documentation.
Personal suggestion: For component documentation, Storybook is preferred.
test
The test questions could be an article in themselves. I’m going to focus on the types of testing that I think are critical for any app unit testing, e2e (end-to-end testing), and visual testing.
unit test
All advice so far comes from my personal experience. So Jest is what I should recommend in this section. It’s a powerful and reliable test runner and I’m very happy with it.
But there’s one tool I haven’t had a chance to test yet. Vitest is a Vite-powered test runner with Jest-compatible syntax, and everyone I know supports it. So I have to choose it as recommendation.
Personal suggestion: Prioritize Vitest for unit testing
End-to-end testing
With Cypress, not only is it the most popular option, but the latest versions put a lot of effort into stability and eliminating instability. Apart from being the most developer-friendly tool, it also makes it the best choice for e2e testing.
Another option is Playwright, which might be faster overall, but the adoption and ecosystem aren’t big enough for me to be trusted in my pipeline.
Personal suggestion: For end-to-end testing, Cypress is preferred
Visual testing
It’s hard to decide. I’m currently using Applitools and I understand very well the importance of a good visual test suite. Although, conflict resolution in multi-user environments is extremely painful and can definitely be improved.
My advice would definitely be to have a visual test suite, and I promise I’ll come back with a specific tool when my workflow stops giving me a headache.
Personal advice: Just be happy
UI framework
I can’t even remember the last good experience I had with a UI framework. And maybe it’s not in the Vue world. There are many choices, but also many questions. Configuration hell, bloated implementations, poor performance, memory leaks, and more. That’s why I currently recommend a custom implementation on top of a headless component library. In the Vue world, this means shadcn-vue is built on top of radix-vue. This is not a library that we can install and start using right away. We need to work on adapting it to our style guide, and to me, that’s a good thing.
For the record, if you want a UI library out of the box, several popular options include, but are not limited to:
- Vuetify
- Element UI
- Quasar Framework
Personal suggestion: UI framework preferentially choose shadcn-vue and radix-vue
static type
Needless to say, this topic is more controversial than I imagined. I know that TS can be easily abused and take away the joy of programming, but I think if TS is used properly, it can enhance our primary role as programmers reading code. Critical Thinking and TSLint are highly recommended.
Personal suggestion: give priority to TS for static types
IDE (Integrated Development Environment)
There are two equally popular choices: IntelliJ and VSCode. IntelliJ is not free, but Vue is supported out of the box, while VSCode is free and open source but requires additional configuration. If you prefer VSCode, be sure to install Volar and the TypeScript Vue Plugin (Volar) to enhance your development experience.
Personal suggestion: IDE gives priority to IntelliJ or VSCode
API documentation
Swagger is by far the most popular choice. It is based on the OpenAPI specification, making it easy to share API documentation with other developers. It’s a mature and well-supported project with a large community behind it.
Personal suggestion: For API documentation, Swagger is preferred
Conclusion
These are my personal suggestions for using Vue to build scalable apps in 2024. As you may have noticed, for the most part I like to stick to industry standards. I thought this would create synergy with other tools, and their popularity would make it easier to find bugs on StackOverflow. For example, deviating from the standard, such as implementing your own lightweight routing, may seem like a good idea at first, but in the long run it will definitely cause more problems than it solves.