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

251–260 of 293 posts

Re: Next.js 12

#251

Post by Graffur »

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…

Others have posted various solutions but I haven't seen Redwood mentioned yet. Would that be something you're looking for?

Re: Next.js 12

#252

Post by toinbis »

cyberpsybin wrote: post #68

Select your enlightened HN comment from below options JS bad; SPA bad; React bad; Next bad

Sad to see a very concise comment revealing arguably the deepest and biggest problem of the frontend world - frontend architectures naming problem - being downvoted.

Re: Next.js 12

#253

Post by no_wizard »

junon wrote: post #216
no_wizard wrote: post #166

Earlier quoted context omitted.

ESBuild does not support any AST transforms directly You can add it, via plugins, but its a serious limitation for a project like Next.js which require's these types of transforms You also end up with diminishing returns with the more plugins in you add to esbuild, and I imagine its worse with js plugins than it is with go based ones, none the less, you have zero access to it directly

I never said it supports AST transformations directly. I just said they were trivial to do with esbuild. Our build times remain at 0.5s with pretty extensive source transformers in JavaScript plugins in esbuild. This is down from 5-8 minutes using rollup.

I'd need a lot more context to understand what you mean by "trivial" and "extensive", respectfully

Re: Next.js 12

#254

Post by Graffur »

hugocbp wrote: post #245
midrus wrote: post #122

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.

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…

I was looking for a mention of Redwood JS - I assume your post has a typo in it.

It's not 1.0 yet but from what I have played with it's the backend (PostgreSQL with Prisma, graphql, services) + frontend (react with data retrieval components (Cells)). That sounds buzz wordy but in practice it works nicely.

Re: Next.js 12

#255

Post by Rauchg »

tunesmith wrote: post #225
Rauchg wrote: post #137

Earlier quoted context omitted.

Stories like this[1] are not uncommon: > One of our users upgraded from Next.js 2.0-beta to 11 in 5 minutes. > As @timneutkens said in the Q&A, Next.js incrementally improving without breaking changes is worth the investment. If this is not the case, please let us know. We try to be very careful around this, and always leave breadcrumbs for easy upgrades in the DX if we absolutely must change something to move the pr…

This was not our experience earlier this year. We experienced a sequence of breaking changes in various dot-releases that led us to not being able to upgrade from 10.0.6 until 11.0.1 came out. Basically every single release in the 10.1.x and 10.2.x lines were unusable for us. We're very cautious about upgrading now. It's part of why I suggested this issue: https://github.com/vercel/next.js/issues/26827

Thanks for the feedback. I’ll bring this to the team

Re: Next.js 12

#256

Post by 1_player »

dude187 wrote: post #9
capableweb wrote: post #3

Nice, a completely new attack-vector: https://nextjs.org/blog/next-12#url-imports Documentation still not there, so can't check if they actually compare any checksums or anything. They also introduce their own `next.lock` which supposedly new tooling have to built around as well. Versioning management? What, we don't need that for where we're going. Finally it's fun to see it ending with: > We set out to build a zero…

Anything sold as erasing away reality eventually becomes overly complicated, as you inevitably have to work around it to address reality

Commonly known as: leaky abstraction.

Re: Next.js 12

#257

Post by nicoburns »

capableweb wrote: post #15
dmix wrote: post #10

The big innovation here seems to be https://swc.rs/ If it works as advertised this is going to be great for a ton of JS/TS projects. Particularly having a 20x typescript compiler boost when running large test suites would be great. Maintaining 5-8 different babel related projects in packages.json is also annoying and often buggy. Looking forward to see where else this gets adopted and it's stability.

How does it compare to esbuild? Seems they both want to achieve exactly the same thing, but somehow it's two different efforts.

It's pretty similar, but esbuild is still a bit more mature.

Re: Next.js 12

#258

Post by 1_player »

sandGorgon wrote: post #211

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

The JS ecosystem and the pace of change it's forcing on people with deadlines is ridiculous.

/rant

Re: Next.js 12

#259

Post by 1_player »

toinbis wrote: post #252
cyberpsybin wrote: post #68

Select your enlightened HN comment from below options JS bad; SPA bad; React bad; Next bad

Sad to see a very concise comment revealing arguably the deepest and biggest problem of the frontend world - frontend architectures naming problem - being downvoted.

I agree with OP, but it is not constructive. Please let's not turn HN into Reddit.

Re: Next.js 12

#260

Post by findjashua »

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…

Postgraphile, Hasura, Supabase etc might be of interest to you
Post reply on HN