Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Next.js 12

nextjs.org

Post reply on HN
Print view View original

121–130 of 293 posts

Re: Next.js 12

#121

Post by jekude »

maccaw wrote: post #104
jekude wrote: post #48

If 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 think because the answer here is using Next.js with hosted backend solutions like Firebase, Supabase, Pusher, etc.

The reason I love Next.js + Vercel though is because I don't need anything else for the frontend (besides a CMS maybe).

If I have to use:

1) Pusher for realtime

2) Supabase for DB

3) Temporal for workflows

4) Vercel / Netlify, etc. for functions / cron jobs

My backend becomes primarily a bunch of stuff glued together, rather than something cohesive like Next.js

Re: Next.js 12

#122

Post by midrus »

I'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.

Re: Next.js 12

#123

Post by pscanf »

jekude wrote: post #82
habosa wrote: post #64

Earlier quoted context omitted.

Maybe something like https://encore.dev ? Looks like a similar mindset.

This certainly is akin to what I had in mind, and looks really great. A couple of thoughts: 1) Ideally the framework is polyglot (Go seems sensible though) 2) I wish they had queues/events that were wired up to functions 3) Not sure if using autoscaling k8s services under the hood as opposed to serverless functions is the right choice 4) A bit too opinionated on DB/Auth (maybe I don't want to use Postgres) 5) With al…

I guess https://dapr.io/ could also be considered a contender in that space, though the developer experience is not as polished as next.js (yet?).

Re: Next.js 12

#124

Post by mcintyre1994 »

leerob wrote: post #113
mcintyre1994 wrote: post #32

Earlier quoted context omitted.

How do you achieve no cold boots on edge functions? Is it the same approach as Cloudflare ( https://blog.cloudflare.com/eliminating-cold-starts-with-clo... ) or something else? Are there any tradeoffs to be aware of with your approach vs theirs if they're different?

Vercel's Edge Functions are built on top of Cloudflare Workers. The runtime is designed for any similar provider, but we've chosen Cloudflare for now because they have an amazing product.

Awesome!! Thanks for the answer :)

Re: Next.js 12

#125

Post by swyx »

CGamesPlay wrote: post #83

I don't want to hate on Next, because I do like using the framework, but a new major version every 5 months for the lifetime of the project? How does anybody actually develop an application when you have to spend so much time keeping your framework up to date?

the major versions are mostly marketing new features. Next has been pretty conservative about how it deprecates APIs, i'd wager many Next.js 8 apps could just be updated to 12 with no change

Re: Next.js 12

#126

Post by Abishek_Muthian »

jekude wrote: post #60
chrisco255 wrote: post #53

Earlier quoted context omitted.

Vercel / Next.js does function as a backend, too. You simply add an api folder and create 'routeName.js' files in there and you've got an endpoint backed by a lambda. And Vercel itself allows you to install backend services such as Redis caching, databases, or queues that you can pull in from those functions.

Definitely get that it works as a backend as well. I guess I am imagining a frontend-agnostic platform that is more backend-centric, rather than targeted directly for frontend web development. Ideally I just get an endpoint from my backend-as-a-service (Supabase style) I can pop into Vercel as an environment variable, and use it as well in my moblile apps, public api, etc.

If you're already using likes of Supabase, Firebase etc. then Parse.com (RIP) was that OG BaaS but Facebook acqui-killed it. Now it's available as a open-source project and is used by several providers to provide BaaS[1].

I had used both proprietary & open-source Parse until 4 years back for several production applications but has since gone back to relational DB(pgSQL), so don't know the current status of the ecosystem.

[1] https://parseopensource.github.io/

Re: Next.js 12

#127

Post by Vinnl »

rickstanley wrote: post #75
r6203 wrote: post #18

I don't get it. It's still not possible to use next/image (without some fancy loader or 3rd party service) when exporting a SSG build. Are people really not using responsive images when exporting a static site? Seems quite ridiculous to rely on some 3rd party service for image optimization when the images could be generated locally when exporting the site...

Maybe I'm missing something, but aren't we able to use `next/image` to transform local assets since v10?

The imperative phrase is

> when exporting a static site

i.e. running `next export` to generate a bunch of HTML, JS and CSS files that you just serve from a static file server. It would be nice if that could generate responsive versions of your images too.

See for the feature request: https://github.com/vercel/next.js/discussions/19065

Re: Next.js 12

#128

Post by segphault »

Rauchg wrote: post #77
segphault wrote: post #37

The install footprint from npm is 302 packages weighing in at 504mb. It includes a lot of superfluous debris, with packages containing single functions like "is-string" and multiple polyfills for functions like object.assign. That's a very large attack surface considering the poor security practices in the npm ecosystem[0] and the growing frequency of attacks on transitive dependencies[1]. [0]: https://www.bleepingco…

A huge bet we're placing on our Rust compiler is that we'll control the supply chain much more tightly. The core infrastructure of the project will ship as an architecture-optimized binary (for local dev) or WebAssembly (for browser dev). In the process, we're being careful and empathetic about the incremental upgrade paths and ecosystem compatibility, so we're shipping a number of packages that'll completely disappe…

> A huge bet we're placing on our Rust compiler is that we'll control the supply chain much more tightly.

This is great to hear, thanks for responding. I'm looking forward to seeing the Next.js dependency story improve in the future as you are able to complete that migration to swc. And hopefully Vercel's leadership in this space also encourages similar improvements in the broader node and react ecosystems.

Re: Next.js 12

#129

Post by julenx »

leerob wrote: post #109
julenx wrote: post #16

Earlier quoted context omitted.

Also excited about the Rust compiler! Apologies if this is far from reality, but by looking at recent commits in GH[1] it looks as though this has been rushed for a v12 release, so I was wondering how much of internal testing has this been going through before pushing it to the broader public. [1] https://github.com/vercel/next.js/commits/canary

We've been testing SWC for months now, both with early community members on canary releases and with Vercel customers. Lots of the rushing at the end was for minification, which is opt-in because of this. But compilation with Rust (replacing Babel) is stable (which is why it's on by default).

Thanks for clarifying, Lee!

Re: Next.js 12

#130

Post by gherkinnn »

CGamesPlay wrote: post #83

I don't want to hate on Next, because I do like using the framework, but a new major version every 5 months for the lifetime of the project? How does anybody actually develop an application when you have to spend so much time keeping your framework up to date?

Next has proven to be very backwards compatible to me.

Even large steps, like moving from a server to handle routing (and i18n) to dynamic routing or that whole SSR business were bug chunks, yes. But in the right direction and without blowing up in my face. And could be adopted incrementally and in our own time.

Post reply on HN