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

191–200 of 293 posts

Re: Next.js 12

#191

Post by acemarke »

no_wizard wrote: post #183
davedx wrote: post #160

Earlier quoted context omitted.

How many extent build-systems are there now for JS/TS? It's getting insane.

Realistically? Just Babel, SWC, ESBuild, and TypeScript's own compiler. I'm not really aware of anything else with serious momentum, or isn't simply built upon one of these projects, SWC itself if I recall correctly was built to address speed problems with Babel The other speed bottleneck I've found is postcss, which SWC is also trying to address with their own new CSS parser, which is the CSS parser they extended in…

There's an interesting-looking build tool called Bun. Not sure if it's actually released yet, but the development tweets by the author look very promising:

https://twitter.com/jarredsumner/status/1390084458724741121

> Early benchmark from a new JavaScript bundler. It transpiles JSX files: > - 3x faster than esbuild > - 94x faster than swc > - 197x faster than babel

Re: Next.js 12

#192

Post by burggraf »

o_____________o wrote: post #176
burggraf wrote: post #153

Earlier quoted context omitted.

Supabase developer here. Supabase gives you full PostgreSQL access as well as a REST api interface (Postgrest) with integrated authentication (based on GoTrue), S3-based storage also integrated to authentication and integrated with your PostgreSQL instance, an easy dashboard interface and a bunch more. There’s a generous free tier and a hosted option that’s ready to scale immediately. Let us know if you have any more…

You guys should advertise the Postgres+Postgrest thing more prominently, I've been looking through your materials this morning and the Postgrest part wasn't clear. I would have been more apt to choose Supabase immediately since it seems like I wouldn't encounter vendor lock in, which was the main concern.

It's considered our "API", which is part of the "Firebase Alternative" marketing idea, but your point is duly noted and I'll pass it on to our devrel guys. Thanks.

Re: Next.js 12

#193

Post by hajile »

theobeers wrote: post #35
capableweb wrote: post #15

Earlier quoted context omitted.

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.

I wonder if it's the compiled code entirely or also the architecture. Babel has a notoriously flexible design with tons of extensions reaching in and messing with things.

I'd bet that you could probably get close to 2x the performance if you stripped it down to the same feature set (it would still be 2-3x slower, but a dramatic improvement).

Re: Next.js 12

#194

Post by ChrisArchitect »

midrus wrote: post #122

I'm going to be downvoted to hell for this... but the more I see the level of complexity and amount of engineering going into this, the more I miss Rails and how simple things are there, given most of us are just building CRUD apps anyways.

No downvote - it definitely is crazy complex, or at least intimidating for anyone from the 'before times' of Rails (myself included). Everything is taken over by engineers and so is now over-engineered and feels totally geared towards developers developers developers and a weird obsession with performance.

And all the new features including server side rendering give me whiplash

Re: Next.js 12

#195

Post by cjw3 »

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.

We use this for TypeScript development at my company. Using swc for transpilation reduces build time from ~10s (small-ish codebase) to near instant. We can then wrap it in entr [1] to get live API reloading for free.

For type checking, you can run the TypeScript compiler in another window in watch mode, or just rely on editor warnings until the code hits CI.

[1]: https://eradman.com/entrproject/

Re: Next.js 12

#196

Post by dragonwriter »

jkaplan wrote: post #189
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…

1. I'm not sure about this premise: "leader of the production-ready frontend-as-a-service space." They def seem like a good fit for some frontends -- but they're certainly not a good fit for ALL frontends generally. (For example, sufficiently small sites should probably just go with static hosting, and sufficiently dynamic web apps still will want a SPA.) 2. At the end of the day, web backends are just a lot more var…

> At the end of the day, web backends are just a lot more varied and complex than web frontends.

> No, they aren't. On the technical side, a web frontend is always just bundles of JS, HTML, CSS, that have to be transmitted to the client.

First, that's factually untrue; web front-ends can contain a wide array of things beyond those three (WASM, content in formats other than HTML that is read and used by the JS/WASM, etc.)

Second, on a similar level of reductionism, web backends are just bundles of bytes that need to be deployed on servers.

Re: Next.js 12

#197

Post by acemarke »

hajile wrote: post #193
theobeers wrote: post #35

Earlier quoted context omitted.

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.

I wonder if it's the compiled code entirely or also the architecture. Babel has a notoriously flexible design with tons of extensions reaching in and messing with things. I'd bet that you could probably get close to 2x the performance if you stripped it down to the same feature set (it would still be 2-3x slower, but a dramatic improvement).

That's basically what Sucrase.js is:

https://github.com/alangpierce/sucrase

Re: Next.js 12

#198

Post by toddmorey »

nickosmark wrote: post #172

Next.js reinvents so many things that already exist in PHP (also Python, Ruby). Check out for example what is already possible with Symfony in their docs[0]. Next.js "biggest" release just introduced middleware and html rendering with zero client-side js ! What people like in tools like next.js is not the framework itself but the abstraction over infrastructure, using platforms like vercel. Imagine a platform as chea…

Symphony itself brought quite a few concepts from Rails to the PHP community. You can call the flow of ideas across communities "reinvention" but I think it's super healthy.

The web platform has had been an oddity in asking you to entirely switch languages when moving between backend development and frontend development. I think one of the most appealing pieces of these Javascript frameworks is that you can build everything in one common language. (You can—but don't have to.)

Fine-grained developer control of when data is fetched, when components are rendered, how they are rendered, and where they are rendered (server vs client) becomes a really welcome advancement.

Re: Next.js 12

#199

Post by jekude »

jkaplan wrote: post #189
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…

1. I'm not sure about this premise: "leader of the production-ready frontend-as-a-service space." They def seem like a good fit for some frontends -- but they're certainly not a good fit for ALL frontends generally. (For example, sufficiently small sites should probably just go with static hosting, and sufficiently dynamic web apps still will want a SPA.) 2. At the end of the day, web backends are just a lot more var…

This is a really strong argument. At the end of the day I think it is possible (with iteration) to get the level of abstraction correct for something approaching some semblance of the universality you refer to.

I really just want a framework that allows me to:

1) Run locally like Next.js's "npm run dev"

2) Do end-to-end unit tests because the framework provides the abstraction layer

3) Deploy to the cloud via push to Github and have it run exactly the same as (1), but do it at scale (deploy to serverless functions, use actual SQS Queues, Eventbridge, etc.)

Of course the core would a developer experience like Vercel, Stripe, etc.

Re: Next.js 12

#200

Post by mrahmadawais »

leerob wrote: post #113
mcintyre1994 wrote: post #32

Earlier quoted context omitted.

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?

Vercel's Edge Functions are built on top of Cloudflare Workers. The runtime is designed for any similar provider, but we've chosen Cloudflare for now because they have an amazing product.

Excellent decision!
Post reply on HN