PayloadCMS: Open-Source, Fullstack Next.js Framework

So let me get this straight... PayloadCMS is a framework, for Next.js which is a framework for the React framework.

Yo dawg, i heard you like frameworks!

"Framework" isn't really the best term for them to actually use to describe Payload. Its basically a tool for NextJS developers to quickly build a custom CMS. I'd think of it more like CMS-in-code than a framework.

Yes? I think this is great. IMO our goal should be to enable building higher-level abstractions on lower-level ones.

A common misconception. React is a library.

These are examples for React frameworks: https://react.dev/learn/start-a-new-react-project#production...

Next.js is a React framework.

If Payload is a framework or not is debatable. I think it's more like a data layer around a database for a any js app and an Admin Panel (that uses Next.js now). It might be called a framework for your own Headless CMS, because it is code first. So you basically code the panel and the data structure yourself.

Sure, if the lower level is stable. Nothing in this chain is close to stable.

> React is a library

Can a library have compiler?)

That's an optional step for JSX cross-compilation. It's a language plugin; nothing really to do with frameworks or libraries.

React is arguably quite stable?

React started as a library.. at this point it has server side components, and a world of plugins.

As for anything that has patterns of building with, will argue it's a framework.

RSC was marked stable in Mid 2022 and this major change is still in the process of unfolding through the ecosystem, because of course these things take time. And even though react might be the future, I have a hard time understanding a client side framework that currently becomes more of a server side framework being stable.

By that standard, nothing is stable. New features are added to HTML, the Linux kernel, x86, PHP, etc all the time. In fact, building on top of higher level abstractions can sometime insulate your application from this change too.

React is a FEBEFUIRT - a FrontEnd/BackEnd-Fluid UI RunTime.

React was a library before hooks. Now it is a framework and decides when your code runs, not you. And now it is a terrible framework with server components.

s/framework/abstraction/g

With that said, yep, I do like robust/stable and purposeful abstractions.

React hasn't been a library since they added hooks.

Hooks themselves are just a solution to async code, but the implication was that react was no longer a state-based UI rendering library and became a full blown frontend framework.

They're going further than jsx transpilation[1]

[1] https://react.dev/learn/react-compiler

I think server components have been very badly marketed. They're totally opt-in, so I don't see how this would make React instantly a terrible framework. I for one think they represent a lot of value.

If you don't use them, then React is quite literally no different to you.

A sword is also just a knife. And a Tesla truck is just an electric go-kart.

Hard to call something a full blown front end framework when it doesn’t have routing.

Routing is only important for a single page applications. Frontend frameworks are applicable to normal websites as well, they don't have to be SPAs with routing, caching, etc.

Javascript has a compiler called Babel, which plays a huge role in modern web development. It is in fact a transcompiler, meaning it doesn't turn your javascript into bytecode, it is just transpiling stuff without changing the level of abstraction.

React Compiler is just a babel plugin for automatic performance improvement, memoization specifically, for never perfectly memoized React code.

Can library have compiler? Well why can't it? For example stdlib has a compiler, because C does.

Can you please guide me where this heresy is being spread?

Can you please guide me where this heresy is being spread?

You heard it here first, I'm officially breaking the story wide open.

Nothing in that is actually doing what a compiler does above and beyond what babel, swc and esbuild are capable of.

What they've added is wrapping your code in more memoization functions, basically. All stuff that doesn't fundamentally transform the code, aside from inserting more `useMemo` and the like.

The JSX macro - which is itself already optional but everyone uses it - is just that, a handy macro with implementations available in every common bundler and transpiler out there.

From what you posted in this thread, I can tell with confidence you don't know shit about web development

Hooks solution to async code? Hooks make React full blown forntend framework? Routing only important for single page applications? Yellow gorilla bread butter? Chickity dickity web frontend back single page I understand much