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

161–170 of 293 posts

Re: Next.js 12

#161

Post by swyx »

jekude wrote: post #152
swyx wrote: post #143

Earlier quoted context omitted.

ah nice! make sure to fill out our waitlist if you want our managed service: https://temporal.io/cloud meanwhile if you like workflows as code and want to stay in the AWS world what about AWS SWF? our CEO used to be tech lead of that and it shares similar ideas. yeah we are hoping to establish what best practice/architecture for workflows looks like. Feedback/questions welcome: https://docs.temporal.io/blog/workflow-…

am an ex-AWS engineer who worked on a service team that depends on SWF and also on one that depends on Step Functions. IMO the serverless-ness (?) of Step Functions and not having to manage pollers like SWF is huge.

yeah we hear that a bunch. long term we'll host pollers. gotcha tho :) thanks for the thoughts

Re: Next.js 12

#162

Post by acemarke »

dstaley wrote: post #76
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…

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

I actually upgraded my team's Jest config to use https://github.com/Brooooooklyn/swc-node a few weeks ago. However, our Jenkins CI agents run RHEL7, and neither of the Linux binary targets would run. The `x64-gnu` binary needed a `GLIBC_2_23` symbol when only 2.18 was available, and the `x64-musl` binary had no `musl-libc` on the machine. I don't own the Jenkins agents, so I couldn't install other deps myself.

I ended up building `musl-libc` from source on another RHEL7 agent, committed the `.so` to our repo, and added that to the `LD_LIBRARY_PATH` in our Jenkinsfile, and actually got that working.

I did see some mentions that Rust could build to target an older GLibc ( https://kobzol.github.io/rust/ci/2021/05/07/building-rust-bi... ), so I'm curious if Next is going to use copies of SWC built that way for better compat or if it will require more workarounds on my part.

I can definitely see shipping a WASM version as a great workaround to those sorts of compat issues.

Re: Next.js 12

#163

Post by no_wizard »

simlevesque wrote: post #155
no_wizard wrote: post #136

This is really amazing, is the end result here that they are ultimately opting out of webpack in favor of SWC? It also compiles modules and such. Will have to take a look at the underlying infrastructure here! Interestingly I think that’s the major win of SWC over esbuild: you get a Babel like plug-in ecosystem for AST transformations and such. Downside: there currently isn’t a way to run asynchronous transforms, muc…

> I love Vue, but it’s forever married to the Babel parser That's not true... I use Vue's SFC without Babel using vite.

`@vue/compiler-sfc` which powers the vite Vue 3 SFC plugin (`@vitejs/vue`) has a dependency on the `@babel/parser` package[0]

That's the dependency I am speaking to here

[0]: https://github.com/vuejs/vue-next/blob/master/packages/compi...

Re: Next.js 12

#165

Post by robertrbairdii »

leotaku wrote: post #115
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.

I'm personally curious how the Next is able to achieve the claim of "zero client-side JavaScript" mentioned here[1] using react server components? It just doesn't seem to make sense to me, and the HN clone example and my barebones test project also clearly still load about 74.2 KB of JavaScript. Is the claim supposed to mean that the server components won't require additional JS, or maybe that they won't need to exec…

From my understanding from watching the keynote earlier today, the reason that demo has JS is that repo opted in to have client side code to handle the upvote functionality. If it didn't require that interactivity it could be shipped with no client side JS. The client side js code is defined in the component files ending in .client.js

https://github.com/vercel/next-rsc-demo/tree/main/components

Re: Next.js 12

#166

Post by no_wizard »

junon wrote: post #159
no_wizard wrote: post #136

This is really amazing, is the end result here that they are ultimately opting out of webpack in favor of SWC? It also compiles modules and such. Will have to take a look at the underlying infrastructure here! Interestingly I think that’s the major win of SWC over esbuild: you get a Babel like plug-in ecosystem for AST transformations and such. Downside: there currently isn’t a way to run asynchronous transforms, muc…

> you get a Babel like plug-in ecosystem for AST transformations and such This is trivial to do with esbuild, for what it's worth.

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

Re: Next.js 12

#167

Post by vaughan »

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…

SWC uses napi-rs to talk to N-API. NAPI-RS's convention is to ship binaries as npm packages which should avoid a lot of the pain which came from having to download pre-compiled files from a file server. Compiling other platforms shouldn't be necessary, but if it is it will be slightly more difficult than using traditional gyp or cmake. You would have to setup a Rust toolchain, but after thats its relatively easy.

Re: Next.js 12

#168

Post by AccountAccount1 »

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…

Nhost.io does functions, database, Graphql API, rate-limiting, authentication. Basically everything you need.

Re: Next.js 12

#169

Post by vasco »

swyx wrote: post #119
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…

https://supabase.io has: - Postgres DB (+ admin panel + realtime sync + search + workflows) - Auth - Storage - Functions (beta) (disclosure: am small angel investor) its interesting that you consider workflows a "standard cloud primitive". what do you currently use? (i work on a workflow engine myself)

Does anyone in a larger company (say 100+ devs) have experience with supabase (or similar tool) real world projects to increase rate of experimentation before "graduating" services to more standard supported infrastructure that is using standardized monitoring etc?

Re: Next.js 12

#170

Post by k__ »

leotaku wrote: post #115
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.

I'm personally curious how the Next is able to achieve the claim of "zero client-side JavaScript" mentioned here[1] using react server components? It just doesn't seem to make sense to me, and the HN clone example and my barebones test project also clearly still load about 74.2 KB of JavaScript. Is the claim supposed to mean that the server components won't require additional JS, or maybe that they won't need to exec…

Also, does "no client-side JS" also work with Cloudflare Workers?
Post reply on HN