Hacker Newsnew | past | comments | ask | show | jobs | submit | brillout's commentslogin

Author of Vike (unaffiliated with Vite) here. Questions welcome.


Hi, I'm brillout the creator of Vike.

Questions welcome!


I agree and, as the author of vite-plugin-ssr[1], that's what I recommend to my users: go for static whenever you can.

I think it's something every web developer should be aware of. Static is indeed a lot simpler than dynamic.

I've wrote more about it over here[2] (SSG = static, SSR = dynamic).

[1] https://vite-plugin-ssr.com

[2] https://vite-plugin-ssr.com/pre-rendering


Also have a look at https://vite-plugin-ssr.com/ (author here).

VPS is slightly lower level which gives you a lot more control: integrate with your existing Node.js backend (use any backend framework you want), deploy anywhere, use any React alternative (Solid, Preact, ...) and any data fetching tool (e.g. Relay can't really be used with Next.js).

The flip side is that you've to write a little bit more glue code. Although this will be alleviated by a lot with projects such as Bati[0], Stem[1], and vike-react (see Vike Rebranding[2]).

VPS also cares a ton about details, such as hooks for full control over i18n (use any i18n strategy you want), better Base URL support (VPS supports setting a different base for your server and your CDN), automatic deploy synchronisation, domain-driven file structure, polished and helpful error messages (especially the next upcoming release), ...

Detailed comparison with Next.js: [3].

If you run into any blocker then it's quickly fixed (or at least a workaround is proposed).

It supports not only SSR and pre-rendering, but also SPA in case you don't need SSR. It's going to support RSC but doesn't yet (RSC isn't ready for production).

Because it's lower level and because it's decoupled from React everything is designed in an agnostic way and with meticulous care. In other words: vite-plugin-ssr is becoming a robust foundation. There are breaking changes coming for the v1 release but beyond that chances are that there won't be any breaking changes for years in a row.

In a nutshell: vite-plugin-ssr takes care of the frontend and only the frontend. You keep control over your architecture. (Whereas frameworks tend to put themselves right in the middle of your architecture restricting you in fundamental ways.)

Last but not least: it's powered by Vite which means blazing fast HMR.

[0] https://batijs.github.io

[1] https://stemjs.com/

[2] https://github.com/brillout/vite-plugin-ssr/issues/736

[3] https://vite-plugin-ssr.com/nextjs-comparison



Interestingly, Vite itself is written in a slow interpreted language (JavaScript/TypeScript) while using compilers that are written in fast native languages such as ESBuild (written in Go).

It's a nice showcase of successfully applying the strategy of focusing on hotpath performance instead of blindly making every line of code "fast".

Also, Vite being written in JavaScript is much friendlier to the ecosystem. I myself made many PRs to Vite which I would have done much less if it involved a more complex language.

Shameless plug: I'm the author of https://vite-plugin-ssr.com which is a Next.js/Nuxt alternative but with a "do-one-thing-do-it-well architecture"[1].

[1]: https://vite-plugin-ssr.com/architecture#do-one-thing-do-it-...


Seems like you may appreciate https://vite-plugin-ssr.com/ (I'm its author).


I love vite-plugin-ssr. Thanks for making it.


Nice. I was going to use Next for my current project, but may give your solution a try instead!


Open alternative to Next.js: https://vite-plugin-ssr.com/ (I'm its author).

Open:

- Choose any UI framework you want (React/Vue/Solid/...)

- A lot more flexible than Next.js (e.g. i18n and base assets configuration are fundamentally more flexible)

- Keep architectural control (vite-plugin-ssr is more like a library and doesn't put itself in the middle of your stack)

- Use your favorite tools. And manually integrate them with vite-plugin-ssr (for full control without surprises).

- Deploy anywhere (and easily integrate with your existing server/deploy strategy)

- Open roadmap

- Ecosystem friendly

The upcoming "V1 Design" has been meticulously designed to be simple yet powerful. Once nested layouts, single route files, and typesafe links are implemented vite-plugin-ssr will be pretty much feature complete.

Note that, with vite-plugin-ssr, you implement your own renderer, which may or may not be something you want/need/like to do. Built-in renderers are coming and you’ll then get a zero-config DX like Next.js (minus extras like image processing as we believe they should be separate libraries).

Web dev isn't a zero sum game - a vibrant and healthy ecosystem of competing tools can co-exist. (I'm close to be able to make a living with sponsors.)

Vision is to make a truly open and collaborative foundation for meta frameworks.

Let me know if you have any questions.


Next.js pseudo-alternatives are usually subpar, because they misunderstand Next.js approach and implement a very simplified vision of it (eg they can't even tell the difference between client-side rendered SPA and HTML export). This one doesn't seem to fall in this trap, from the documentation it seems a very well thought library. Great work!


Even though you go on explaining what you mean by "open", seeing that the common definition is "open (source)", I'd go for a different qualifier.


It's available under MIT License hosted on GitHub. Am I missing something?

https://github.com/brillout/vite-plugin-ssr/blob/main/LICENS...


I think parent means that both Next.js and vite-plugin-ssr are open source, so "open(-source)" isn't a differentiator.

I agree although we think we can keep the word "open" and make it clear that we're takling about being a "open framework" (and not only open source).


Yea, we've plans to improve communicating that. (Although we do plan to stick to the word "open".)


Astro is a whole different thing really. I don't think vite-plugin-ssr users would want to use Astro and also vice-versa to some degree.


Hmm. It seems like the big differences between the two are:

1) Astro is either all-SSG or all-SSR, while VPS is mix-and-match

2) Astro uses `.astro` templates by default, while VPS uses `.js` by default

3) Astro comes out-of-the-box with Typescript, Sass, etc., while VPS requires more configuration (by design)

Other than that, they seem to have fairly similar project structures and use-cases... Or am I misunderstanding?


VPS is tailored for users who like/want/need control. If you care about control, Astro isn't a good fit. E.g. you won't be able to use Astro with React Server Components. And many other subtleties that, in the end, sum up to a fundamentally different tool.


I agree and that's why vite-plugin-ssr sponsorship https://github.com/sponsors/brillout plays a central role here: eventually, there will be enough sponsors to make vite-plugin-ssr a self-sustainable project a la Vue. It's a virtuous cycle and you can expect the number of sponsors to increase.

A more conservative answer is that vite-plugin-ssr is actually already fairly stable: only minor adaptations are required upon new Vite major releases. Do-one-thing-do-it-well tools stabilize quickly, that's one fundamental architectural advantage. Now the DX status quo is continuously evolving/improving and vite-plugin-ssr has to keep up (when not leading the way e.g. with Route Functions :-)). But, in the worst case scenario, you'll be stuck with non-modern DX while you'll be able to upgrade React/Vue/... independently of vite-plugin-ssr until you migrate away.

A more personal answer is that I love doing it, so expect me around ;-).


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: