Graphql/Prisma Subscriptions?

@mojombo “It’s because both of these graphs are useless.” :dart:

Still, I do agree with @maxhodges points that Vue seems like a better match if already reaching for a “dumbed down database” like Prisma. Vue is not dumbed down, though, but it is more of the “more building less configuring” principle.

If I may pollute this Prisma subscriptions thread with another long subjective Vue vs. React opinion, sorry :grimacing::

I know these decisions are made so no need to read the following really. Just food for thoughts.

TL;DR: Vue is more suited for Redwood if ignoring the popularity aspect (which isn’t unimportant).

I’ve worked almost exclusively with Vue and React about 50/50 for the 4 past years. Initiating new projects and jumping into existing ones. I always reach for Vue unless the client values popularity more. Put simply; Vue does everything you need without getting in the way. Fewer hiccups, less learning churn (React projects are like fast-evolving bacteria without a blueprint). In Vue, you build features, not configuring.

I’ve tried building snippets of how to do X feature in Vue or React side-by-side comparison to illustrate the benefits of Vue over React. But the point doesn’t come across that well. So I’ll just insert my own overreaching one-sided conclusions based on experience and take that for what you wish.

Every piece of Vue can be argued for, the templating, the .vue file components, the ecosystem, naming conventions, documentation, typescript support (from 3.0 it works across Vue + Vuex). You can use just the Vue view layer or opt-in for the interconnected state management, routing, and (maybe relevant here) well-crafted boilerplates with defaults that can be overridden without needing to eject (still get upstream updates). The ecosystem is opinionated and made specifically for Vue and therefore works really well. That said, all ecosystem packages are easily opt-in Vue.use(Vuex) :point_left:. Vuex alone is incredibly easy/sensible and reliable at scale. Anything I can do in React I can do in Vue. I am always quicker up and running, less time managing builds, and writing fewer tests with more confidence. When React projects grow, I move slower, whereas Vue lets me move fast at any stage. From project initiation to improving, tailoring, and being at scale.

In React, I found that there is a great effort to maintain a system to keep control. Also, since React is so thin and unopinionated, projects look very different because of the need to configure and sort of build mini-frameworks into React. I typically see way more packages in React projects, which is less necessary with Vue because it gives you atomic interfaces to widespread operations. Here is one example: i.e.:

<input v-model="name" @keyup.enter.prevent="submit()" />

:point_up: that’s two-way data-binding (can also use one-way binding if needing to handle something in-between), it listens for the enter keypress across browsers and submits. Doing this in React would require significantly more code and tests to get it stable. Since form handling is so frequent (especially CRUD sites like redwood), you usually reach for a form library in React (many popular ones). You then integrate it with your state management, and ripple effects start to rise. I think this detail reflects many similar cases. React is lower level, and since you need higher-level operations all the time, you either build them yourself or reach for libs, and would you prefer a community package over a tailor-made framework plugin?

The most important argument for Vue is perhaps its philosophy; it’s a framework + tailor ecosystem for developing complete websites. Whereas React is just a thin view layer made to be inserted into facebooks already thick stack. Again, you can use Vue as a view layer also, so the Vue definition is well suited; “progressive framework.”

If needing a bigger community, more devs to hire, more packages, or wanting to inject a really thin view layer in a big and complicated stack, React may be the better. But except for the argument “more popular,” I think the other points are pretty weak as Vue also is an extensive, stable, and popular framework.

All this said- I’m a bit out of bounds to be recommending Vue instead of React. These decisions have already been made. I just wanted to give my thoughts on this :slight_smile:

1 Like

I enjoy vue.js for the reasons above you mentioned + more that being said there is still a reason why I would pick react.js over vue.js personally.

How much TypeScript support do you need? Currently react.js is the the only js framework that covers that fully, last time I played with vue.js you couldn’t even get typesafety in the templates.

The reason why you still prefer React is Typescript? I can understand that. Vue 3.0 is a complete rewrite to Typescript, it’s now in beta and TS is a first class citizen. As the ecosystem is tailored towards Vue they will also have interconnected TS support, like Vuex 4 is now in alpha and has type safety with Vue 3.

1 Like

it most certainly matters to people who built their product on a framework which got deprecated and is no longer supported because all the development efforts are going into a rewrite to support Hasura, or FaunaDB or Vue instead of React, or whatever needs to be done to fix a bad decisions. Now anyone who has production apps running on the earlier version either has to refactor their whole app, or get left behind. This is exactly what Prisma has done to its community three times now.

For example

My company (Vibely) is looking to migrate away from Prisma because they’re abandoning their current customers with Prisma2 . . . It would be really helpful if there were a migration guide on how to do this. We’re desperate to leave Prisma,

same thread:

I’m also migrating from Prisma 1 to Hasura. Prisma is not stable, they change a lot, and lack some important features…

1 Like

I would think that Twitter chose the most suitable tech they could think of at that time. And demands 15 years ago were different, to say the least.

Knowingly choosing something less ideal with the reasoning that its early stage is like buying a bad car before buying the one you want. Why on earth would you not choose what’s most suited. Definitely there will be tradeoffs but basing the argument of “it doesn’t need to be perfect” is selling Redwood short of it’s potential imo.

There is no reason that redwood can’t be the framework to build the next Twitter or Facebook. But if adding unnecessary limitations like Prisma there will be reasons. And it’s unnecessary as I see it.

Sorry, I may have talked a bit past your point, but I feel like this is relevant to the design decision of Redwood and it was slightly suited as a counter.

here’s a start:

Replace Prisma with Fauna and React with Vue and you’ll have yourself a nice framework!

I’d give RudwoodJS a try.

1 Like