Live data from Hacker News

Next.js 12

nextjs.org

71–80 of 293 posts

Re: Next.js 12

#71

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…

The introduction of Middleware is specifically in alignment with our zero-config principle.

You should be able to open `pages/` and understand exactly the flow of traffic.

You'll open `pages/`, find `_middleware.js` which processes your request first, and then the rest of the routes. No magic, and heavily inspired in successful predecessors like Express.js.

Always open for feedback, let me know if this makes sense!

Re: Next.js 12

#72

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…

[deleted]

Re: Next.js 12

#73
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…

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.

Re: Next.js 12

#74
post #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?

Deno's as well, I suspect there'll be a later version where next runs entirely on Deno.

That's certainly the trajectory I expect from a release that is shifting a lot of tooling to Rust, and focussing heavily on the server-side functionality.

I also expect that's going to be done to benefit Vercel/nextjs's saas offering. Deno's APIs follow the browser APIs so it seems sensible enough to evolve the project in that direction.

Re: Next.js 12

#75
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?

Re: Next.js 12

#76

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

I think one of the biggest issues with node-sass was that it only supported a narrow set of node versions and platforms, which resulted in a lot more compilation from source. I definitely remember fighting with node-gyp and such, and pretty quickly ditched it for dart sass as soon as that was a viable alternative.

Next.js looks like it's shipping binaries for swc for a wide Node range (>=10), on a pretty comprehensive combination of operating systems and architectures:

- android-arm64

- darwin-arm64

- darwin-x64

- linux-arm-gnueabihf

- linux-arm64-gnu

- linux-arm64-musl

- linux-x64-gnu

- linux-x64-musl

- win32-arm64-msvc

- win32-ia32-msvc

- win32-x64-msvc

Unfortunately I don't have access to a system that _doesn't_ have a pre-built binary, so I have no idea what would happen if you tried to install Next.js on an unsupported architecture. That being said, I'd love to see the Next.js team ship a WASM version of SWC for such systems, which should ensure that when there's not a pre-built binary, at least you won't be asked to install a Rust compiler.

Re: Next.js 12

#77

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 disappear in the future.

You'll see us drop a ton of deps and weight in the short term. Watch this space. Thanks for your feedback, I'm on the same page.

Re: Next.js 12

#78
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 would give MongoDB Realm a try, it has all the building blocks you need!

Re: Next.js 12

#79
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…

Tried a couple shots at it

Go Micro (17k stars) https://github.com/asim/go-micro

Micro (10k stars) https://github.com/micro/micro

M3O (1.7k stars) https://m3o.com

Post reply on HN