Live data from Hacker News

Next.js 12

nextjs.org

21–30 of 293 posts

Re: Next.js 12

#21
post #9

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

> I guess replacing configuration with code is one way of achieving "zero-configuration".

> 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. Then another competitor appears and shouts "We're so simple compared to X, no config or code needed!", and the cycle repeats.

I think that is missing the point of middlewares. They are not a thing you _have to_ configure before you can even get going (which is what zero-config usually alludes to). Instead middleware is a mechanism for sharing code between different routes.

Now that code might contain functionality that can be eliminated through strong conventions (i.e. always parse JSON instead of having to configure a content-type aware body-parser middleware). But that is a very specific use case and middlewares do a whole lot more than that. So even with goodest faith, I think your point does not land.

Re: Next.js 12

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

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.

Re: Next.js 12

#23
With server component, i really think next.js hybrid app with cordova will achieve high performance even better than native app (like react-native).

Re: Next.js 12

#24
post #17

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…

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

Re: Next.js 12

#25

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…

Re attack vector: the outcome here will just be the same as a vanilla js + html website won't it?

Or are you saying that reverting to that mean takes away some of the security gained from SSR?

Since this is an optional opt in that mirrors current usage it doesn't seem like a bad thing...

Re: Next.js 12

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

It is definitely an awkward design choice, but image services often generate the images on demand, by having one and creating the otherones at request + caching. A static build does not have the capacity to cache images, unless it generates a really large number of them during build!

Re: Next.js 12

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

Agreed on this, I'd much rather do the image optimization at build time and just push it in an /asset folder or similar.

However I assume this isn't done because it doesn't scale well. On my website with 10 images it might work, but what happens when I have 1,000, that doesn't bundle well.

Re: Next.js 12

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

It is definitely an awkward design choice, but image services often generate the images on demand, by having one and creating the otherones at request + caching. A static build does not have the capacity to cache images, unless it generates a really large number of them during build!

Right, this could work for small sites, but not sites with a ton of images.

Re: Next.js 12

#30

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…

> url imports

Aren't they just taking a feather out of Golang's hat?

Post reply on HN