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

81–90 of 293 posts

Re: Next.js 12

#81

Post by vaughan »

julenx wrote: post #16
leerob wrote: post #2

Hey everyone, Lee from Vercel here! Happy to answer any questions about Next.js 12. Personally, I'm extremely excited for the new Rust compiler.

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

The Rust compiler is just swc which has been around as another project for ages. Checkout it’s home page. Many people are using it.

Re: Next.js 12

#82

Post by jekude »

habosa wrote: post #64
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…

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 all of the above you could get really great end-to-end integration tests as unit tests that I don't see them taking advantage of

Re: Next.js 12

#83

Post by CGamesPlay »

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?

Re: Next.js 12

#84

Post by gherkinnn »

letmeinhere wrote: post #73
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.

but (at least last I checked and from what I can glean from current docs) Vercel doesn't host databases, or integrate on a network level with the major cloud providers that do, so if you run your "back end" on Vercel you still need a "back back end" from a different provider and are opting into a huge amount of network operations burden to securely connect the two.

Welcome to the Jamstack.

/snark

I'd think of a Next-driven BE as a BE for FE. And since it's co-located, You can share types, validators, utilities, (mental) models, etc. across the same codebase.

A technique that does have its place. Not always. Maybe not even half the time. But cleverer people than me use it to some effect.

Re: Next.js 12

#85

Post by eyelidlessness »

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?

To be fair, some of these updates are more significant than others. This one is probably the biggest since I first tried Next. React Server Components has the potential to make me consider using Next for static (MPA) sites again, which I’d previously written off because of the double payload problem.

Re: Next.js 12

#86

Post by hardwaregeek »

capableweb wrote: post #55
jacobmischka wrote: post #22

Earlier quoted context omitted.

They are two different efforts, started a little while ago, one in Go and one in Rust. I believe esbuild was started first, but they both seem to be maturing rather well lately.

> I believe esbuild was started first That seems incorrect. - "put on github" - evanw committed on Jan 15, 2020 - https://github.com/evanw/esbuild/commit/23c40b1b6a76a8626f1d... - "initial commit" - kdy1 committed on Dec 22, 2017 - https://github.com/swc-project/swc/commit/0f9532dd5d379292cc...

Judging by the commit messages the first esbuild commit seems like Evan moved an existing project onto GitHub while the SWC commit seems like a genuine start. But also pretty unlikely that esbuild was being worked on for 3 years before being put on GitHub so your point still stands.

Re: Next.js 12

#87

Post by matsemann »

ramesh31 wrote: post #54

>Compilation using Rust is 17x faster than Babel and enabled by default using Next.js 12, replacing transforming JavaScript and TypeScript files. I've never, ever felt constrained by Babel performance. Even in massive 100k+ LOC codebases. I have , however, been burned over and over again by introducing native binaries into the build process. We specifically moved off of node-sass to using PostCSS for this very reason…

Hard disagreement here. Seen so many slow builds / hot-reloads over the years. It's draining to work on a project where changing a file takes a couple of seconds to be live in the browser. Almost so that I believe those not complaining about webpack's or babel's speed just don't know what they're missing out on.

Re: Next.js 12

#88

Post by Rauchg »

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.

I think esbuild is a fantastic project as well as a huge inspiration. I'll share two quick thoughts[1] I have on SWC that made it a fantastic choice for Next.js:

1. SWC is designed for extensibility

We were able to use `swc` as a crate[2], without the need to fork the project

This allowed us to effectively (no divergence) and efficiently (no loss in performance) extend it, especially to add syntax and plugin compatibility that is more common in the Next.js ecosystem. We added support for ``, with more React optimizations and Babel plugins coming.

2. We love the Rust ecosystem

It has a stellar, growing community. It has the best long-term performance prospects for us (e.g: absolute control over memory management) and safety. We don't want to be in a position where there's another enticing migration in just a couple years, and we think Rust is a durable non-regrettable choice.

[1] https://twitter.com/rauchg/status/1425520232202792962

[2] https://github.com/padmaia/next.js/blob/cf1d081c5b2f55085ceb...

Re: Next.js 12

#89

Post by rattlesnakedave »

letmeinhere wrote: post #73
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.

but (at least last I checked and from what I can glean from current docs) Vercel doesn't host databases, or integrate on a network level with the major cloud providers that do, so if you run your "back end" on Vercel you still need a "back back end" from a different provider and are opting into a huge amount of network operations burden to securely connect the two.

For this sort of thing I really like fauna (https://fauna.com/). I don't think you really "need" a "backend backend" anymore, and small dev teams are probably better off without them.

Re: Next.js 12

#90

Post by matsemann »

ilovecaching wrote: post #7

Seems like a ton of tools/dependancies/frameworks to do something relatively simple. What is the benefit of this over using Hugo with Go templates?

One benefit is that it's JS. Yes, really. For every Go developer, there are a thousand that know JS.
Post reply on HN