> Next.js now enables you to do data fetching at the component level, all expressed as JSX. By using React Server components, we can simplify things. Special functions like getServerSideProps or getStaticProps are no longer needed. This aligns with the React Hooks model of colocating data fetching with your components. Do you see getServerSideProps and getStaticProps going away in the next release or two ?
How often are they going to change their data fetching APIs?! There's libraries still using getInitialProps (like urql), now deprecated, because getServerSideProps and getStaticProps that were in vogue until now had very different semantics, and they're changing them again? I'm so glad I'm not maintaining the Next project at work anymore, I very much dislike how often it is changing yet it's still very restrictive. T…
Next.js 12
281–290 of 293 posts
Re: Next.js 12
#282Earlier quoted context omitted.
Eh. Perhaps you're looking through rose colored glasses on the days of Rails dominance? I've worked at multiple companies using Rails and not one was simple. Especially when you have 100+ engineers working on different aspects of a massive product. Anecdotal but Rails has a ton of magic to make things work but its only simple if you're product is a super basic CRUD app
I don't think 100s of engineers working on a massive next.js application would be any easier. At scale everything is complex.
Of course. I didn't say Next.js solves the complexity of building a massive product, no framework will prevent complexity at scale. That's my point since this thread seems to put Rails on a pedestal like it was the main thing making products built with Rails simpler compared to other frameworks in other languages when in reality, the product requirements are most likely pretty simple
Re: Next.js 12
#283If Next.js + Vercel is the leader of the production-ready frontend-as-a-service space, why hasn't a similar leader emerged in the backend-as-a-service space? I would love a clean Vercel-like abstraction on top of standard cloud primitives (functions, queues, events, workflows, etc.) with everything wired up nicely and focused on developer experience. It just seems like AWS is so configuration heavy that it is ripe fo…
Why not using Caprover ? That's an open source self hosted PaaS that use Docker and let you configure almost everything through their GUI, as well as checking Logs, easily scale horizontally, spinning up Postgres/Redis/Next cloud or whichever docker images in one click and letting you communicate via different parts of your projects through environment variables set through the GUI.
That way instead of learning a new and likely less advanced framework you can use your favorite and likely more mature and well maintained backend framework and just deploy in a minute with caprover, as long as you can dockerize it it should work, you just have to write a single dockerfile ( they also have a way to not write dockerfiles directly and use their abstraction ).
You take advantage from the backed framework you already know with all its advantages and also benefit from Docker's huge community. Their UI is really good to be honest, you can enable and force https in one click and other goodies like that, DigitalOcean also have a preconfigured Ubuntu droplets with caprover preinstalled to make it even smoother.
Re: Next.js 12
#284Earlier quoted context omitted.
I understand your point, but having worked with Rails and now working on a React + Flask app, Next.js is the closest thing to Rails we have so far. And, having worked on a Rails + React app a few years back, I can safely say that is about as complext as a Next.js full-stack app. I do love Rails and I still think the React + Something on Backend environment is still not there yet (at least not like Rails 4 and 5, whic…
But why do we need a new rails? That's what I don't get. Just because we want to use JavaScript?
Because React is now a standard in the frontend I guess, so people are looking for a way to get that Django/Rails fullstack experience but with React instead of templating language and because it's extra work to write a django/node/rails api and a decoupled JS framework frontend.
Meanwhile everyone is also trying to have a decoupled infrastructure and going with microservices. It's an endless loop I guess.
Re: Next.js 12
#285Next.js reinvents so many things that already exist in PHP (also Python, Ruby). Check out for example what is already possible with Symfony in their docs[0]. Next.js "biggest" release just introduced middleware and html rendering with zero client-side js ! What people like in tools like next.js is not the framework itself but the abstraction over infrastructure, using platforms like vercel. Imagine a platform as chea…
I think that people who like JavaScript are happy with getting the abstractions you mentioned. If building a vercel for PHP was such an obvious idea, I imagine someone would jump on it.
People just like React and the idea of decoupling frontend and backend ( Pretty sure just a few percentage of users use Nextjs with api routes and just use it as Create-React-App with SSG and SSR capabilities ).
I haven't used Vercel that much in production but what does it bring compared to Heroku or cheaper and open source self hosted alternatives like Dokku or even caprover with it's really good UI and can deploy any backend as long as it's Dockerizable ?
Re: Next.js 12
#286> Next.js now enables you to do data fetching at the component level, all expressed as JSX. By using React Server components, we can simplify things. Special functions like getServerSideProps or getStaticProps are no longer needed. This aligns with the React Hooks model of colocating data fetching with your components. Do you see getServerSideProps and getStaticProps going away in the next release or two ?
No, these will not be going away in the near future as far as we can see. React 18 / RSC are still in alpha or experimental stage, and what we shared are just new ways to do data fetching that we are currently exploring.
In fact, component-level data fetching doesn’t conflict with top-level data fetching like gSP and gSSP. Today you can already use gSSP with Suspense-based data fetching together with Next.js 12. It’s just that you normally don’t need to use both, doesn’t mean you can’t :)
Re: Next.js 12
#287If Next.js + Vercel is the leader of the production-ready frontend-as-a-service space, why hasn't a similar leader emerged in the backend-as-a-service space? I would love a clean Vercel-like abstraction on top of standard cloud primitives (functions, queues, events, workflows, etc.) with everything wired up nicely and focused on developer experience. It just seems like AWS is so configuration heavy that it is ripe fo…
I'm the founder of WunderGraph. https://wundergraph.com/ We're doing exactly this. Our philosophy is simple, instead of forcing you into a specific stack, we can "introspect" multiple data sources like GraphQL & REST APIs, MySQL and PostgreSQL, S3 for file storage and OpenID Connect for authentication. This way you can plug and play any of your existing infrastructure and services and turn them into your own private…
[deleted]
Re: Next.js 12
#288If Next.js + Vercel is the leader of the production-ready frontend-as-a-service space, why hasn't a similar leader emerged in the backend-as-a-service space? I would love a clean Vercel-like abstraction on top of standard cloud primitives (functions, queues, events, workflows, etc.) with everything wired up nicely and focused on developer experience. It just seems like AWS is so configuration heavy that it is ripe fo…
1. I'm not sure about this premise: "leader of the production-ready frontend-as-a-service space." They def seem like a good fit for some frontends -- but they're certainly not a good fit for ALL frontends generally. (For example, sufficiently small sites should probably just go with static hosting, and sufficiently dynamic web apps still will want a SPA.) 2. At the end of the day, web backends are just a lot more var…
Backend is probably a lot easier than the frontend, which is why you can see service like hasura and supabase. Backend is a highly patternized work, which is why it can be low to no code, whereas front end as a service is merely just deployment as a service.
Re: Next.js 12
#289Earlier quoted context omitted.
This is a really strong argument. At the end of the day I think it is possible (with iteration) to get the level of abstraction correct for something approaching some semblance of the universality you refer to. I really just want a framework that allows me to: 1) Run locally like Next.js's "npm run dev" 2) Do end-to-end unit tests because the framework provides the abstraction layer 3) Deploy to the cloud via push to…
Check out Amplify! I've heard good things and my limited experience is good so far. (Although running locally isn't the best, unfortunately... but that's always going to be an issue the more you lean on a cloud services.) Deployments are easy. In terms of scalability, it's all massively scalable AWS services under the hood, and it seems relatively easy to "eject" if you ever need to.
Once u have enough experience in AWS tooling world, Amplify is probably the last one you want to use for your product, just so unpolished…..
Re: Next.js 12
#290I'm going to be downvoted to hell for this... but the more I see the level of complexity and amount of engineering going into this, the more I miss Rails and how simple things are there, given most of us are just building CRUD apps anyways.
Because in 21st century, not everyone likes a website with a lower-bar rendering experience… SPA or hybrid rendering is just plain better, but I get the point where time is limited for human being, so if modern frontend is hard to grasp for you, perfectly to stick with old tech. Pretty safe.