vitepress VS Vue.js

There is a discussion related to naming on GitHub: https://github.com/vuejs/vitepress/discussions/548

> I initially gave VitePress a different name because I wanted to be able to explore a different architecture without worrying about backwards compat. After shipping the vuejs.org with VitePress, I believe VitePress is flexible enough to be a full replacement of current VuePress while offering better DX and better performance.

Given that version 1 landed as "VitePress" they probably decided to keep the name.

> ...

> I think we should ship VitePress stable as VuePress 3, but I am open to potential questions and concerns.

> Pros: Less confusion in the long run. There will be just one officially maintained SSG with better DX, better performance, and customization that fully aligns with standard Vite-based Vue apps.

> Cons: Potential confusion in the short run, since there are probably a lot of tutorials / integrations targeting VuePress 1. Still I think with the recent Vue 3 switch, users won't be surprised with a major upgrade for VuePress.

I was inspired by a great series of blog posts and decided to adapt the approach to my needs. In this blog post, I will go over the solution I used in my VitePress site but you can also check a more basic example in this CodePen.

While researching which static site generator we would use, we had a lot of frameworks to pick up from, but only some addressed our needs. While choosing, we needed it to have a good "default" template, out-of-the-box plugins, and be easy to extend its functionalities. From our research, the one that matched most criteria and felt the easiest to start and progress with was Vitepress.

They are using the default theme of VitePress which is a great tool for building content-centric websites such as documentation

Thankfully, an entire ecosystem of frameworks makes docs sites easy to build and services that make static sites easy to deploy. In this post, you'll learn how to build a docs site with VitePress and deploy it to the internet with Render.

I have a few Jekyll blogs including my personal one and I haven't had to touch the Jekyll part for quite a while (it takes a while to compile). I just write in Obsidian and then Github takes over.

I also maintain two VitePress[1] sites. Once I setup it up (I still use Sublime Text), I do the writing on Obsidian.

What I write and see in Obsidian is good enough that I have just done away with looking at how the site looks after I change/add/edit the text. I sometimes do but just to check build and if the sitemaps are generated, etc. -- routine hygiene.

1. https://vitepress.dev

Consider Nuxt instead of Vuepress/Vitepress. If you want the built-in theme in Vitepress, it's great, but if you want to make your own, using Nuxt with the Content plugin is probably better. I found the strong separation between theme and content to be too great, and if I have a docs SSG site using Vitepress and a webapp SSR site using Nuxt, I can't share themes easily anyway.

At least that was my conclusion starting with Vitepress, and ending up with Nuxt 3.

https://nuxt.com/

https://vitepress.dev/ (they haven't decided if they are going to replace Vuepress or not: https://github.com/vuejs/vitepress/discussions/548)

Another option vitepress

Vuejs

Vue.js is a big favorite for making websites because it's easy to use and fits in well with other stuff. Many people worldwide are using it, and the community keeps growing.

Vue has a thriving ecosystem with a wide range of third-party libraries and plugins available for extending its functionality. These libraries cover everything from state management to routing, making it easy for developers to find solutions to common problems and enhance their development workflow. As of this writing, Vue has 200k GitHub stars.

6. Vue.js

I have got the privilege of working on Vue 2 couple of months ago and its really amazing framework to work with .

Angular is as little innovative for web frameworks as Firefox-ESR is for browsers. It merely keeps copying features from other frameworks - just many years later. It is a chronically outdated framework that always struggles to keep up with its competitors. It would be ok if those were deliberate design decisions, but if the features get copied some day anyway, what is the point? Why not do it the right way from the start?

For example, this update brings us computed properties, an essential feature for any complex performant web application that was made popular by Vue.js 10 years ago [1]. And now in 2023 we get it in Angular, essentially a confirmation by its devs that its lack has always been a design error.

I also cannot understand the "mature" argument. For example, it took five years for documentation on `` to arrive [2]. This is something I'd expect from the side project of a lone programmer, not an enterprise-level framework.

The only upsides of Angular are its "batteries included" approach and the (debatable) default of RXJS, while the downsides are plenty.

[1] https://github.com/vuejs/vue/tree/218557cdec830a629252f4a9e2...

It's down since months. https://github.com/vuejs/vue/issues/11867

{ "user": "vuejs", "repo": "vue", "url": "https://github.com/vuejs/vue", "stars": 201555, "description": "🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.", "topics": [ "javascript", "framework", "vue", "frontend" ], "label": "repository", "commitCount": 3544 }

Vue.js is a progressive open-source MVVM frontend JavaScript framework that is designed to be implemented incrementally since the core library focuses only on the presentation layer. Nevertheless, this framework is used for building UI (user interfaces) and complex single-page applications with modern tools and libraries to support them. It enables you to take advantage of libraries for client-side routing and state management when you need it.