FAQ

Project

Technical

Can I use Vike in production?

Yes. Many companies, from small startups to large corporations, are using Vike in production in a wide range of diverse scenarios.

Consider, for example, some of Vike sponsors:

Will Vike survive?

Yes. While predicting the future is difficult, we are confident Vike will stand the test of time. We are a group of passionate developers: for us, working on Vike is the thrill of a liftime and there is no reason for us to stop.

We're making significant progress on being able to financially sustain ourselfes. (Through sponsorships and upcoming innovative open-source business models, without relying on investor money, making Vike financially independent which is paramount in the long-term.) As a company, you can secure Vike's future by sponsoring.

Can I use Vike to achieve what I want?

Vike prides itself on being a highly, if not the most, adaptable frontend framework. See for example the use case of these companies.

Vike supports all common use cases:

A common source of blockers with other frontend frameworks are bugs. Vike is unique in that regard because we quickly fix bugs. We highly value clean abstractions and correctness and we believe that's why, to this date, we have been able to fix all bugs.

Vike has been designed from the ground up to be extensible, so that you can Build Your Own Framework.

If you have a use case you believe you cannot achieve with Vike, then let us know.

How can I contribute and/or support?

Contributions in forms of code and/or sponsoring are much welcome.

Can I reach out for help?

Yes, you can reach out on Discord and GitHub. If you use GitHub Discussions, then you'll always get an answer from a Vike team member.

What are these cryptic JavaScript errors?

Many cryptic errors come from CJS/ESM issues around npm packages that distribute invalid code, for a solution see Broken npm package.

There is, unfortunately, not much we can do beyond pushing tools to address CJS/ESM issues which we repeatedly do.

Why is CSS leaked to other pages?

With Client Routing, when navigating from one page to another, the CSS of the previous page isn't removed. This means that any CSS loaded by the previous page will also apply to the next page. In other words: CSS cumulates upon page navigation.

For example:

// /pages/terms/+Page.jsx
 
import './style.css'
 
export const Page = () => (
  <div id="#terms">
    <h1>Terms of Service</h1>
    <section>
      {/* ... */}
    </section>
  </div>
)
/* /pages/terms/style.css */
 
/* ❌ Bad: the CSS selector `section` can apply to any page */
section {
  font-size: 0.8em;
}

Narrow down the CSS selector instead:

/* /pages/terms/style.css */
 
/* ✅ Good: the CSS selector `#terms section` only applies to our terms page */
#terms section {
  font-size: 0.8em;
}

If you use Vue with .vue files, then Vue already scopes the CSS for you: the CSS you define in a .vue file is guaranteed to apply only to the component defined in that .vue file.

If you use React or Solid, then we recommend using inline styles and/or a CSS-in-JS library (or Tailwind), while minimizing CSS files. Inline style aren't global and, therefore, aren't leaky.

CSS is injected by Vite in the form of <style> tags. If you're curious why Vite doesn't remove old <style> tags, consider that removing CSS is problematic during the transient state upon page navigation. (It would lead to FOUC because there is no transaction primitive for DOM manipulation.) In general, regardless of Vite's behavior, it's a good practice to narrow down CSS selectors.

Why are there a lot of HTTP requests in dev?

In development, you may observe a lot of HTTP requests fetching a lot JavaScript files. That's because Vite does lazy transpiling.

While it's true that doing a lot of HTTP requests slows down page load (and optimizing that aspect is on Vite's radar), Vite's lazy transpiling approach enables unparalleled development speed.