phero
vike
phero | vike | |
---|---|---|
21 | 66 | |
311 | 3,609 | |
0.3% | 3.1% | |
6.5 | 10.0 | |
3 months ago | 5 days ago | |
TypeScript | TypeScript | |
Apache License 2.0 | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
phero
-
Node.js 20 is now available
That's one of the reasons that drove me to create Phero: https://phero.dev
-
Full-Stack TypeScript with tRPC and React
I’m one of the authors of Phero. It’s goal is similar to tRPC: fullstack typesafety between servers and clients.
One difference is syntax: Phero leverages the TS compiler api to generate parsers for your backend functions. It will parse input and output or your api, automatically, based on the types you define for your functions. It will generate a declaration file of your api and generate an RPC style client SDK for your frontend. Another difference is that it aims to be more batteries includes.
[1] https://github.com/phero-hq/phero
Comparison: https://phero.dev/docs/comparisons/tRPC
- Framework for REST API that builds a complete-ish API given a model?
-
Using API routes for large projects
Shameless plug: you could also use https://phero.dev
-
No errors when fetched data is a 'string' even though interface property type should be a number.
Long story short: when fetching data, you should be validating the data, before casting it to a type you’re expecting it to be. There are a lot of different approaches for this, but being the go-author my favorite would be Phero (https://phero.dev). With this, you can build your API in typescript as well, automatically generate a client for your frontend to call the API. Phero will make sure all data is correct in runtime, automatically.
-
Best schema validator for intellisense performance?
For those looking for an alternative: Definitely check out https://phero.dev. As the co-creator I’m totally biased of course, but thanks to its build-step IDE-performance is great 😊👍
-
I've made a big comparison table of nodejs RPC frameworks. Hope you like it ;)
What about Phero? https://phero.dev
- How you make typesafe front/backend API
-
KitaJs Survey - No runtime code, fast as bare metal and top level framework.
Can we add Phero to the list? :) https://github.com/phero-hq/phero
-
If you haven't worked with TypeScript yet it's a good time to get started now. I prepared an intro that covers the most important points to React with TS. Including a few embedded exercises for you to practice.
You can use Phero. You can use it on your backend and frontend. It basically created a typed API from your backend afaik
vike
-
SSRx vs. Vinxi vs. Vike - for SSR with Vite
Here are some collected notes of the distinctions between SSRx, Vinxi and Vike, to share with anyone else searching the web. Since my Google search came up empty, and I had to ask around on Twitter/X and GitHub to find out.
- Vike – Meta Framework Alternative
-
Triplit: Open-source DB that syncs data between server and browser in real-time
We're working on exactly this. You can already do this with Triplit but it's challenging to make an out of the box solution because each framework passes context/data different from server to client differently. There's a cool project called [Vike](https://github.com/vikejs/vike) that generalizes this pattern across SSR'd UI frameworks
-
Can't stand Next JS-- alternatives w/ Vite?
Anyone have experience with https://github.com/vikejs/vike?
-
Waku: The Minimalist React Framework with Server Components
have you seen https://vite-plugin-ssr.com/ ? i've only browsed their docs, but AFAICT their pitch that it's a more DIY approach to a framework, where you keep a lot of control over how things are wired together.
-
The theory versus the practice of “static websites”
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
-
What's the best ISR (and SSR) React frameworks? (looking for NextJS alternative)
Maybe vite-plugin-ssr? It's pretty unopinionated and doesn't get in your way.
-
Next.js App Router Update
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 change 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 fundemetanl 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
-
React Server Side Rendering(SSR)
Now by default, Vite doesn't do SSR. One way to do Vite+SSR is to use vite-plugin-ssr. You can scaffold an example project that does SSR based on some dynamic data:
-
NextJS app router is complete failure, what alternatives do you recommend for react SSR and ISR?
vite-plugin-ssr
What are some alternatives?
protoc-gen-validate - Protocol Buffer Validation - Being replaced by github.com/bufbuild/protovalidate
vite-ssr - Use Vite for server side rendering in Node
withtyped - 🤹 Type-safe RESTful framework for fullstack with all native implementation.
Next.js - The React Framework
telefunc - Remote Functions. Instead of API.
vite-imagetools - Load and transform images using a toolbox :toolbox: of custom import directives!
bash - Unofficial mirror of bash repository. Updated daily.
ts-node - TypeScript execution and REPL for node.js
jest-extended - Additional Jest matchers 🃏💪
vite-plugin-vue2 - Vue2 plugin for Vite
garph - Fullstack GraphQL Framework for TypeScript
nextjs-tailwind-ionic-capacitor-starter - A starting point for building an iOS, Android, and Progressive Web App with Tailwind CSS, React w/ Next.js, Ionic Framework, and Capacitor