🔍Search
📚 Docs Menu
🌱 Get Started

FAQ

Help & Business Inquiries

Project

Technical

How can I reach out for help?

On:

  • Discord to get help from the community.

    There aren't any rules: you can post what you want. That said, questions sometime don't get any answers on Discord, so we recommend reading the #help-guide channel to increase your chance of receiving valuable assistance. Also, consider giving back by helping others!

  • GitHub Discussions to get help from the Vike team.

    On GitHub it's best you follow these rules. If you post high-quality questions (see the #help-guide channel on Discord) then you'll most likely get a response from the Vike team.

  • GitHub Issues to report a bug, or request a feature.

How can I reach out for business inquiries?

Contact brillout:

Don't reach out on Twitter as it has shown to be unreliable.

Don't privately contact brillout for getting help unless you're a sponsor, see How can I reach out for help?

I can't achieve what I want, can I get help?

Yes, and you can use GitHub Discussions to get help from the Vike team, see How can I reach out for help?

If it turns out that your issue is caused by a Vike flaw, we will consider it a blocker on Vike's side and prioritize resolving it accordingly.

In general, Vike aims to be highly flexible and resolving blockers is important to us, ideally by design and at the very least by providing help.

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 scenarios.

Consider, for example, the use case of some of Vike sponsors:

  • Alignable (social network), using a bespoke React integration with their Ruby on Rails backend. (Sponsoring brillout, the creator of Vike.)
  • Contra (freelance market), large codebase (>150 routes) with a bespoke React rendering strategy and GraphQL integration using Relay. (Sponsoring brillout.)
  • Ecosia (search engine), migrating their entire frontend from Nuxt to Vike for a substantial performance increase. (Sponsoring vikejs.)
  • Burda (publishing house with online newspapers reaching half of the German population), migrating their fragmented tech stacks of multiple and diverse online newspapers into one unified bespoke framework using Vike and Solid. (Sponsoring brillout.)

Can I use Vike to achieve what I want?

Vike prides itself on being a highly adaptable frontend framework. See for example the use case of some of Vike sponsors.

Vike supports all common use cases:

A common source of blockers are bugs; Vike is also unique because we quickly fix bugs and, to this date, we have been able to fix all bugs. We value clean abstractions and correctness, which significantly reduces potential bugs.

Beyond common use cases, Vike has been designed from the ground up to be flexible, so that it can fit special needs. You can use Vike to Build Your Own Framework.

If you have a use case you aren't sure you can implement with Vike then feel free to reach out.

In general, Vike aims to be as less blocking as possible. If you run into a blocker then don't hesitate to reach out.

Will Vike survive?

We are a group of passionate developers; working on Vike is the thrill of a lifetime and there is no reason for us to stop.

We're making significant progress on being able to financially sustain ourselves.

Without relying on investor money, but through sponsorships and upcoming innovative open source business models. Independence is paramount for keeping Vike a community-driven project with transparent interests that are well aligned with its users.

As a company, you can secure Vike's future by sponsoring.

How can I contribute/support Vike?

Contributions in forms of code or sponsoring are much welcome.

What are these cryptic JavaScript errors?

Many cryptic errors come from CJS/ESM issues around npm packages that contain invalid JavaScript code, see workaround at Broken npm package.

We meticulously craft Vike's error messages to be clear and helpful, but error messages from other tools aren't under our control. If any Vike error message isn't clear, let us know, and we'll make it clearer.

Why is CSS leaked to other pages?

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: the CSS of all previous pages cumulate.

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` applies to all pages. */
section {
  font-size: 0.8em;
}

Narrow down the CSS selector instead:

/* /pages/terms/style.css */
 
/* ✅ Good: the CSS selector `#terms section` only applies to the 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 wonder why Vite doesn't remove the <style> tags of the previous page, consider that removing CSS is problematic during the transient state upon page navigation (as it would lead to FOUC because there isn't any transaction primitive for DOM manipulation).

Why are there a lot of HTTP requests in dev?

In development, you may observe a lot of HTTP requests fetching many 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.