Poked around the code a little bit, it doesn't seem that it is intended to be able to drop into another project and then use as a custom form builder for that project. Any plans for something like this? A lot of the infrastructure and framework (next/js) seem heavily built into the codebase. I would have to use supabase?
If you're working towards something that developers can drop in, take a look at https://heyform.net/. If not, then it's still nice to be able to have some freedom on the deployment.
Hello! Name is Mat, been in and out of Detroit based startups for a while. Looking for both leadership or IC positions. Open to new tech and other languages!
We’ve moved companies off of Braze already, but we still need to add multi-channel support. We’ll likely add it in the future unless customer needs materially change.
I will have to give this article a more full read rather than just a skim, but...
I am left with such confusion as to how React/Next arrived at this solution. `useEffect` didn't run on the server when doing SSR, great, easy enough to understand. Now several common hooks don't run on the server because they are considered interactive? And it isn't that they won't run, their initial pass in most cases doesn't do anything, it is that Next now yells at you for having a `useState` hook in a "Server Component".
I would like to write a component, not have to think about where it is running in most cases, and go on with my day. I mostly use React for large SPAs and have adopted Next for doing SSR on the few pages that I needed it for (SEO, etc).
Vercel is how, and Next.js is like a trojan horse at this point.
As much as the React team tries to push back on it, Vercel marketing has become synonymous with React's direction.
Most people do not need a single thing that Vercel/Next.js thought leaders are trying to shove down their throats.
Unless you're competing with Facebook for SEO rankings (good luck) the 1KB you saved by not shipping an un-interactive component down the wire is nothing.
They're actively pushing a set of best practices that align with their hosting model and building a moat around said hosting
—
Also despite the intentionally confusing wording, Server Side Rendering does work with Client Components!
There are literally *hundreds* of posts where people are unaware of that because the directive chosen by the React team was "use client"... which naturally leads people to believe "use client" will opt out of SSR.
—
To me that choice, and not allowing a project wide disabling of it, were the last straw that took it from innocent misalignment to intentional.
By having the thought leaders sell these heavily server involved features they've create a situation where technically you can move your Next.JS project anywhere... there's just a scary (for those who don't know better) laundry list of things that won't work unless a given provider goes out of their way to enable it.
They get to play both sides: Next.JS works anywhere (as long as you ignore a bunch if features that we sell as being very important to making a good site)
Do you have terms that you prefer (to Server/Client split)? I agree they're confusing but I haven't seen any proposal that would address the issues with them without introducing other issues.
That is also my issue with NextJS -- it is utterly confusing trying to figure out what they mean when they say "server" or "client". Are they talking about the backend server and what client do they mean? These words become extremely confusing when you might be developing a full stack feature or service that has multiple clients, a backend API, etc...
> I would like to write a component, not have to think about where it is running in most cases
you can keep doing this, just put "use client" in the file, Next will SSR them just like it used to. (SSR is an "emulated client" in this model. admittedly, the naming is a bit confusing)
but for some things, you want a guarantee that it only runs on the server, and then you can use server components :) i believe this is also why useState & friends are disallowed there -- they fundamentally don't make sense for stuff that'll only ever run server-side.
We are looking for Senior/Staff level Software Engineers to come join us in building out an awesome platform to help millions of people break free from opioid addiction. Last year we closed our Series A and are rapidly growing.
Our stack: React, React Native, NodeJS and run on GCP
We are looking for Senior/Staff level Software Engineers to come join us in building out an awesome platform to help millions of people break free from opioid addiction. Last year we closed our Series A and are rapidly growing.
Our stack: React, React Native, NodeJS and run on GCP
Dictionary.com | Senior Front End and Back End Engineers | Full-time | Remote (US)
Dictionary.com (Also Thesaurus.com) are looking to build the next phase of educational tools around English Vocabulary for all levels of learning. We are looking for Senior NodeJS and React engineers to join us! We are currently distributed between Oakland, CA and Detroit, MI, with the majority being in Oakland.
