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

31–40 of 293 posts

Re: Next.js 12

#31

Post by dstaley »

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.

One thing to keep in mind is that SWC is a compiler, whereas esbuild is a bundler. SWC has limited bundling capabilities last time I checked, so if you're looking for something to traverse your code and generate a single file (or multiple files at dynamic import boundaries, etc.) esbuild is what you want. Next.js bundles with webpack, so it uses SWC in lieu of Babel (or the TypeScript Compiler).

Re: Next.js 12

#32

Post by mcintyre1994 »

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.

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?

Re: Next.js 12

#33

Post by atoko »

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.

Are there any plans to address Bazel compatibility?

I understand that the Next philosophy is very monolithic but so far I’m having trouble getting it to play nice with build tooling.

Re: Next.js 12

#34

Post by [deleted] »

capableweb wrote: post #24
dntrkv wrote: post #17

Earlier quoted context omitted.

> I guess replacing configuration with code is one way of achieving "zero-configuration". That's a weird thing to have beef with since this approach to middleware is completely inline with Next's zero-config philosophy. They take common patterns in the industry and make them dead simple to use out-of-the-box. In an alternate framework that uses middleware, you would have to manually configure the middleware on whatev…

That code is config. Zero-config would be that those middlewares are enabled by default, so you have to do zero things to enable it. I guess maybe there is a difference in understanding the terminology. I always understood zero-config to be that you'd have to do nothing to get that particular feature, but maybe zero in zero-config is referring to something else.

[deleted]

Re: Next.js 12

#35

Post by theobeers »

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’ve tried both; found that both definitely solve the performance issues that they’re intended to address; and decided that I just prefer using esbuild. As much as I appreciate Rust, the idea that Rust (swc) vs. Go (esbuild) would matter in this context doesn’t make sense to me. The switch to a compiled language is what’s night-and-day.

Re: Next.js 12

#36

Post by joshmanders »

capableweb wrote: post #24
dntrkv wrote: post #17

Earlier quoted context omitted.

> I guess replacing configuration with code is one way of achieving "zero-configuration". That's a weird thing to have beef with since this approach to middleware is completely inline with Next's zero-config philosophy. They take common patterns in the industry and make them dead simple to use out-of-the-box. In an alternate framework that uses middleware, you would have to manually configure the middleware on whatev…

That code is config. Zero-config would be that those middlewares are enabled by default, so you have to do zero things to enable it. I guess maybe there is a difference in understanding the terminology. I always understood zero-config to be that you'd have to do nothing to get that particular feature, but maybe zero in zero-config is referring to something else.

> Zero-config would be that those middlewares are enabled by default

What middlewares? Next has all basic middlewares needed enabled by default. What you're suggesting is that Next ships with every possible middleware that anyone could need, even the special snowflake middleware I want that adds a "foozlebozzle" property to the request context, just to say "We don't require you to do anything" and that's just not possible.

They have made it so you can hook into things and customize if needed, not "you have to now write all your own middleware for everything"

Re: Next.js 12

#37

Post by segphault »

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.bleepingcomputer.com/news/security/52-percent-of... [1]: https://news.ycombinator.com/item?id=28962168

Re: Next.js 12

#38

Post by dntrkv »

capableweb wrote: post #24
dntrkv wrote: post #17

Earlier quoted context omitted.

> I guess replacing configuration with code is one way of achieving "zero-configuration". That's a weird thing to have beef with since this approach to middleware is completely inline with Next's zero-config philosophy. They take common patterns in the industry and make them dead simple to use out-of-the-box. In an alternate framework that uses middleware, you would have to manually configure the middleware on whatev…

That code is config. Zero-config would be that those middlewares are enabled by default, so you have to do zero things to enable it. I guess maybe there is a difference in understanding the terminology. I always understood zero-config to be that you'd have to do nothing to get that particular feature, but maybe zero in zero-config is referring to something else.

That code is your application logic.

Next is a lightweight framework. It doesn't implement authentication for you. It's up to you to implement it, but the scaffolding is there for you to easily do it.

You're arguing against your initial comment:

> Feels like all tooling starts out with "We're simple, no config or code needed!" and eventually ends up so extensible that it's hard to figure out how to even use it.

The point of Next.js is that the framework functionality is minimal. You learn the basic concepts and then build the rest out yourself. If they built all of these middlewares into the framework, then we would be in that state you're complaining about since now you have to learn how to use their specific implementation of that middleware because god knows their implementation won't work for your specific needs.

Next.js takes care of everything but the application code itself. It's a true framework.

Re: Next.js 12

#40

Post by yewenjie »

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.

When can we expect the docs to be updated?
Post reply on HN