[HN Gopher] Next.js 12
___________________________________________________________________
Next.js 12
Author : jacobwg
Score : 374 points
Date : 2021-10-26 15:37 UTC (7 hours ago)
(HTM) web link (nextjs.org)
(TXT) w3m dump (nextjs.org)
| yewenjie wrote:
| I like that they have finally provided a fast Webpack
| alternative.
| williamstein wrote:
| Minor correction: They have not provided a fast Webpack
| alternative. Next.js extensively uses Webpack, both for code
| that runs on the frontend and for code on the backend. They
| even hired the lead developer of Webpack. Next.js has very,
| very strongly embraced Webpack. The "Rust Compiler"
| functionality is more an alternative to Babel.
| STRiDEX wrote:
| webpack 5 is still used, SWC would replace babel-loader
| ramesh31 wrote:
| >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'm not completely sure how these Rust binaries will work, but if
| they are in any way less universal than Node, it's going to cause
| problems across dev and CI build environments.
| matsemann wrote:
| Hard disagreement here. Seen so many slow builds / hot-reloads
| over the years. It's draining to work on a project where
| changing a file takes a couple of seconds to be live in the
| browser. Almost so that I believe those not complaining about
| webpack's or babel's speed just don't know what they're missing
| out on.
| eyelidlessness wrote:
| I haven't used SWC extensively, but with ESBuild (written in
| Go) this has been a non-issue for me. I've experienced the pain
| of native bindings in other projects though, it largely depends
| on how resilient the native bindings are to different Node/V8
| APIs across versions.
| vaughan wrote:
| 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.
| dstaley wrote:
| 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.
| acemarke wrote:
| 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.
| dstaley wrote:
| `objdump -T node_modules/@next/swc-linux-x64-gnu/next-
| swc.linux-x64-gnu.node | grep GLIBC_`
|
| Looks like the highest version of `GLIBC` is 2.18, so I
| think you'll be fine!
| acemarke wrote:
| Great, thanks for the info!
|
| Already added a story to investigate the upgrade from
| Next 11 to 12.
| dmix wrote:
| 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.
| inglor wrote:
| It's already used in Deno
| capableweb wrote:
| How does it compare to esbuild? Seems they both want to achieve
| exactly the same thing, but somehow it's two different efforts.
| 0x142857 wrote:
| esbuild is a bundler like webpack, it also does Typescript
| transform but the API is limited, e.g. you can't access the
| ast. Meanwhile swc is a Rust alternative to Babel.
| dstaley wrote:
| 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).
| devongovett wrote:
| If you want a bundler built using SWC as a base today,
| check out Parcel: https://parceljs.org
| Rauchg wrote:
| We are going all in on swcpack (spack) as well. One of the
| benefits of swc-as-platform is the rich ecosystem of
| tooling we will see develop from it. Transforming,
| bundling, prettifying, optimizing... all at peak
| performance.
| Rauchg wrote:
| I think esbuild is a fantastic project as well as a huge
| inspiration. I'll share two quick thoughts[1] I have on SWC
| that made it a fantastic choice _for Next.js_ :
|
| 1. SWC is designed for extensibility
|
| We were able to use `swc` as a crate[2], without the need to
| fork the project
|
| This allowed us to effectively (no divergence) and
| efficiently (no loss in performance) extend it, especially to
| add syntax and plugin compatibility that is more common in
| the Next.js ecosystem. We added support for `<style jsx>`,
| with more React optimizations and Babel plugins coming.
|
| 2. We love the Rust ecosystem
|
| It has a stellar, growing community. It has the best long-
| term performance prospects for us (e.g: absolute control over
| memory management) and safety. We don't want to be in a
| position where there's another enticing migration in just a
| couple years, and we think Rust is a durable non-regrettable
| choice.
|
| [1] https://twitter.com/rauchg/status/1425520232202792962
|
| [2] https://github.com/padmaia/next.js/blob/cf1d081c5b2f55085
| ceb...
| The_rationalist wrote:
| But you could use vite/rollup/esbuild for bundling instead
| of Webpack and SWC for TS and other transforms.
| theobeers wrote:
| 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.
| hajile wrote:
| 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).
| acemarke wrote:
| That's basically what Sucrase.js is:
|
| https://github.com/alangpierce/sucrase
| jacobmischka wrote:
| 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.
| capableweb wrote:
| > I believe esbuild was started first
|
| That seems incorrect.
|
| - "put on github" - evanw committed on Jan 15, 2020 - https
| ://github.com/evanw/esbuild/commit/23c40b1b6a76a8626f1d...
|
| - "initial commit" - kdy1 committed on Dec 22, 2017 -
| https://github.com/swc-
| project/swc/commit/0f9532dd5d379292cc...
| hardwaregeek wrote:
| Judging by the commit messages the first esbuild commit
| seems like Evan moved an existing project onto GitHub
| while the SWC commit seems like a genuine start. But also
| pretty unlikely that esbuild was being worked on for 3
| years before being put on GitHub so your point still
| stands.
| pistoriusp wrote:
| Esbuild doesn't polyfill, it's a bundler that also
| transpiles.
| cjw3 wrote:
| 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/
| XCSme wrote:
| AFAIK ParcelJS also uses it.
| CosmicShadow wrote:
| Some exciting stuff for sure, but the most exciting stuff we
| still have to wait on as it's all experimental until React is
| ready.
|
| Anything that speeds things up and gives us more control is great
| though.
| snarkypixel wrote:
| I was hoping for hosted postgreSQL database support as part of
| Next deployment.
| gherkinnn wrote:
| Vercel does come with a Supabase integration:
| https://vercel.com/integrations/supabase
|
| And from my limited understanding, Supabase is psql with
| extras.
| burggraf wrote:
| 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
| questions.
| snarkypixel wrote:
| I tried supabase and went with another solution because it
| didn't have a good dev/stage/prod system
| burggraf wrote:
| Supabase developer here. We'd love your input on what
| you'd like to see for dev / staging / production. Please
| let us know what you're looking for or the model you're
| interested in.
| o_____________o wrote:
| 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.
| burggraf wrote:
| 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.
| gherkinnn wrote:
| I keep going back to your page. Very interested but lack
| the time and energy to build anything right now.
| mouzogu wrote:
| This is nice as a more opinionated version of create-react-app.
| helps solve some of the problem with the fragmented react
| ecosystem.
|
| It does seem a bit complex though, perhaps something you would
| use on large projects only.
| nickosmark wrote:
| 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 cheap, modern and easy to use
| as vercel but for PHP, basically shared hosting on steroids. Do
| you believe people would still care so much about Next.js in that
| scenario ?
|
| [0] https://symfony.com/doc/current/index.html
| davzie wrote:
| Laravel Forge does exactly this and does it beautifully
| alasano wrote:
| I think that people who like JavaScript are happy with getting
| the abstractions you mentioned.
|
| If building a vercel for PHP was such an obvious idea, I
| imagine someone would jump on it.
| leerob wrote:
| Fun fact, you can actually write PHP function on Vercel :)
|
| https://github.com/juicyfx/vercel-php
| leodriesch wrote:
| I think what is comforting for a lot of people is that they can
| write isomorphic code that mostly automatically works on the
| frontend and backend.
|
| IMO React is also an amazing abstraction and I like writing
| components better than stitching together HTML or other
| template/DSL based systems.
| toddmorey wrote:
| 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.
| sandGorgon wrote:
| > _Next.js now enables you to do data fetching at the component
| level, all expressed as JSX. By using React Server components, we
| can simplify things. Special functions like getServerSideProps or
| getStaticProps are no longer needed. This aligns with the React
| Hooks model of colocating data fetching with your components._
|
| Do you see getServerSideProps and getStaticProps going away in
| the next release or two ?
| midrus wrote:
| 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.
| pandesal wrote:
| Eh. Perhaps you're looking through rose colored glasses on the
| days of Rails dominance? I've worked at multiple companies
| using Rails and not one was simple. Especially when you have
| 100+ engineers working on different aspects of a massive
| product. Anecdotal but Rails has a ton of magic to make things
| work but its only simple if you're product is a super basic
| CRUD app
| ChrisArchitect wrote:
| 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
| pandesal wrote:
| Over-engineering is not exclusive to the JS world. It's just
| in the spotlight nowadays. Rails also just hides its magic
| well because of Ruby and most experienced devs are already
| used to the Rails magic so its simpler compared to the new
| stuff like Next.js.
| qbasic_forever wrote:
| No I had the exact same thought. Are we just re-inventing
| simple server side templating but with incredible new levels of
| complexity and obfuscation?
| techpression wrote:
| I keep thinking the same thing almost every day at work...
| "this is a CRUD app, who let it become this overly complex
| monster (multiple next apps)". Then I remember why;
|
| "Simplicity is a great virtue but it requires hard work to
| achieve it and education to appreciate it. And to make matters
| worse: complexity sells better."
|
| -- Edsger Wybe Dijkstra
| enahs-sf wrote:
| This quote really made my day and embodies my approach to
| software engineering. Thanks for this.
| machiaweliczny wrote:
| I worked with Rails and prefer this. Rails is more complex
| it's just easier to use but harder to understand with all
| that dynamic magic.
| hugocbp wrote:
| I understand your point, but having worked with Rails and now
| working on a React + Flask app, Next.js is the closest thing to
| Rails we have so far.
|
| And, having worked on a Rails + React app a few years back, I
| can safely say that is about as complext as a Next.js full-
| stack app.
|
| I do love Rails and I still think the React + Something on
| Backend environment is still not there yet (at least not like
| Rails 4 and 5, which were the ones I used), but Next.js is
| getting there.
|
| When you factor stuff like Redwook.js and possible Remix.js
| when it gets open-sourced, for me it gets pretty clear that the
| trend now is to try to make the Rails of the JS world.
|
| And I would love that. Honestly, people complain about Node and
| JS, but working in Python/Flask can be just as frustrating.
| Issue for me is more lack of conventions than language.
| Graffur wrote:
| I was looking for a mention of Redwood JS - I assume your
| post has a typo in it.
|
| It's not 1.0 yet but from what I have played with it's the
| backend (PostgreSQL with Prisma, graphql, services) +
| frontend (react with data retrieval components (Cells)). That
| sounds buzz wordy but in practice it works nicely.
| isubasinghe wrote:
| I'm so done with CRUD work, it sucked the soul out of me
| brillout wrote:
| Shameless plug: https://vite-plugin-ssr.com a do-one-thing-do-it-
| well alternative to Next.js which is feature-complete & stable
| (no breaking changes in the foreseeable future).
| mariushn wrote:
| Looks good! Why did you decide to do your own Filesystem
| Routing instead of introducing a dependency to vite-plugin-
| pages, especially as you mention upstream contributions?
| brillout wrote:
| The Filesystem Routing part is like less than 1% of the code;
| it wouldn't be worth it to externalize it in a separate
| library.
| segphault wrote:
| 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
| brundolf wrote:
| Keeping in mind that these are generally build-time/server-side
| dependencies, not client-side dependencies, so size-on-disk
| isn't a very relevant metric
| runjake wrote:
| That seems beside OP's point.
|
| They are speaking of the potential bugs and security
| vulnerabilities all that code might/probably has, given track
| records.
| brundolf wrote:
| They mentioned "weighing in at 504mb", so clarification
| seemed warranted
| [deleted]
| joshmanders wrote:
| Have you ran it in production install mode, because my app
| dockerfile (using alpine base) isn't even that big total.
| sergiomattei wrote:
| I wonder why they don't replace these simple packages like `is-
| string` with Lodash, which has all these functions and more.
|
| Bundle size isn't a problem: they're ES modules, so you can do
| something like `lodash/isString` and import only what you need.
|
| Seems like that would cut down on a lot of dependencies. I'm
| curious why the ecosystem hasn't adopted this or a similar
| approach.
| alexfrydl wrote:
| They're probably dependencies of dependencies. You depend on
| some very useful package and somewhere down the line it
| depends on something written to be platform agnostic in 2012
| when lodash wasn't modular and JavaScript wasn't as mature.
| The ecoystem hasn't adopted a better approach because it
| would require every individual package developer to
| understand the problem, get on board, then update and test
| everything they've written.
| Waterluvian wrote:
| Also tree shaking out the stuff you don't need has never
| worked better. It's pretty trivial with lodash.
| jeswin wrote:
| > I wonder why they don't replace these simple packages like
| `is-string` with Lodash...
|
| As someone who maintains a few dozen packages (public and
| otherwise), lodash has wasted more of my time than any other
| - due to its frequent security issues. It was almost always
| lodash, and I would have to update a dozen packages
| everytime.
|
| Things may have improved; I no longer use lodash anywhere.
| Rauchg wrote:
| 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.
| benatkin wrote:
| How do you review a WebAssembly binary? Are builds
| reproducible? I just found this about Rust:
| https://github.com/rust-lang/rust/labels/A-reproducibility
|
| It would be nice to be able to run them on multiple CIs and
| compare the SHAs.
| segphault wrote:
| > A huge bet we're placing on our Rust compiler is that we'll
| control the supply chain much more tightly.
|
| This is great to hear, thanks for responding. I'm looking
| forward to seeing the Next.js dependency story improve in the
| future as you are able to complete that migration to swc. And
| hopefully Vercel's leadership in this space also encourages
| similar improvements in the broader node and react
| ecosystems.
| r6203 wrote:
| 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...
| throw123123123 wrote:
| 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!
| tevon wrote:
| Right, this could work for small sites, but not sites with a
| ton of images.
| benatkin wrote:
| It's similar to generating compressed files with the build. I
| think it belongs on the web server layer.
|
| Here's an open source, self-hosted one, that should be easy to
| integrate with Next.js:
|
| https://github.com/willnorris/imageproxy
|
| To define a custom one, you need only provide a function:
|
| https://nextjs.org/docs/api-reference/next/image#loader
| rickstanley wrote:
| Maybe I'm missing something, but aren't we able to use
| `next/image` to transform local assets since v10?
| Vinnl wrote:
| The imperative phrase is
|
| > when exporting a static site
|
| i.e. running `next export` to generate a bunch of HTML, JS
| and CSS files that you just serve from a static file server.
| It would be nice if that could generate responsive versions
| of your images too.
|
| See for the feature request:
| https://github.com/vercel/next.js/discussions/19065
| wereHamster wrote:
| I have a system that supports optimized images in SSG that
| doesn't rely on any third-party services. But it requires
| custom config (babel macro plugin), though it only works for
| the most trivial websites.
|
| Let's break it down why its hard. If you want responsive,
| optimized images in a SSG context, without any dependency on
| 3rd party services, your only option is to pre-generate images
| at build time. Fair enough, you can go through all your images
| and pre-generate them at different size and different format.
| You can do that manually, or automate that for example by using
| a babel macro. Let's say you want provide resized images at 4
| different widths, and support jpeg, avif, webp. That means a
| whole lot of CPU that you need to burn during build (even with
| sharp, resizing images takes time), and uses up loads of
| storage (that you need to ship to your static web server). If
| your site has anything but a trivial amount of images, the CPU
| usage will turn your 60 seconds deployment into a 30 minutes
| deployment (or longer), that doesn't scale. You can store the
| generated images in the git repository, but that quickly blows
| up the repository size, so it's not ideal either. You can use a
| cloud storage service to cache the generated images (self-
| hosting that on AWS, GCP or your own blob storage service is
| not difficult) but introduces a dependency on an external
| service.
|
| How do you imagine optimized and responsible images in a SSG
| context to work? I (and pretty sure the Next.js developers as
| well) am curious about any suggestions...
|
| PS. I'm happy to share my babel macro, but as I said, it's only
| usable for the simplest of simple websites.
| CGamesPlay wrote:
| This argument doesn't really make sense.
|
| > That means a whole lot of CPU that you need to burn during
| build
|
| This doesn't makes it hard, and I'd rather spend the CPU once
| than at every edge server on first request.
|
| > uses up loads of storage (that you need to ship to your
| static web server)
|
| Uploading to S3 (for example) is free, and the edge servers
| need to store the images anyways (because they are slow to
| generate as you just mentioned).
|
| > your 60 seconds deployment into a 30 minutes deployment (or
| longer), that doesn't scale.
|
| Says who? It's a static site so it's not being updated every
| 30 minutes, and with some intelligent incremental compilation
| I bet it would remain fast even for the largest sites.
| wereHamster wrote:
| When I said hard, I didn't mean technically. I meant it's
| hard for Next.js to decide how to solve the problem so it
| works for everyone. I'm doubtful if it even makes sense for
| them to try to support every possible use case.
|
| There are solutions available to all of these problems
| today. You can pick the ones which you prefer or fit your
| workflow.
| crocbuzz wrote:
| Just use Gatsby v4 if you want good image support! v4 brings
| Gatsby in-line with Next.js because it introduced runtime SSR
| support like Next.
| wereHamster wrote:
| I assume that Gatsby generates the different widths/formats
| at build time. How well does that scale? Like if you have a
| thousand images, what's the build time like?
| kylemathews wrote:
| We have a job framework that can distribute image
| processing jobs on supported platforms* as well as
| automatically caching subsequent jobs. So it scales easily
| and as most builds don't have that many image changes (if
| any), the impact on warm builds is negligible.
|
| * like Gatsby Cloud
| https://www.gatsbyjs.com/products/cloud/
| tevon wrote:
| 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.
| cyberpsybin wrote:
| Select your enlightened HN comment from below options
|
| JS bad; SPA bad; React bad; Next bad
| toinbis wrote:
| Sad to see a very concise comment revealing arguably the
| deepest and biggest problem of the frontend world - frontend
| architectures naming problem - being downvoted.
| kyleee wrote:
| This is great but im really looking forward to nextjs 13
| kgin wrote:
| At this rate it should be ready in a few weeks
| midrus wrote:
| Best release ever
| leerob wrote:
| 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.
| leotaku wrote:
| 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 execute any
| client-side JS to be fully rendered?
|
| [1]: https://nextjs.org/docs/advanced-features/react-18#react-
| ser...
| k__ wrote:
| Also, does "no client-side JS" also work with Cloudflare
| Workers?
| agrunyan wrote:
| Seems he missed your question, which I'm also curious about.
| krall12 wrote:
| I think it means that any page that only renders server
| components can just push the built html to the browser. If
| there were to be client components, like an upvote button,
| react would be required for that to hydrate the DOM.
|
| It's very similar to what Astro is doing. Only adding the JS
| if it's actually necessary.
| e12e wrote:
| I would assume "no client side js" means "works fine in w3m".
| I'm guessing that's not the case?
| leerob wrote:
| You can read more here on the original RSC announcement:
| https://reactjs.org/blog/2020/12/21/data-fetching-with-
| react.... RSC are still experimental, and as mentioned, this
| demo has some client-side functionality (upvotes).
| leotaku wrote:
| Thank you for your response! However, the linked content
| further seems to support my suspicion that having websites
| without any client-side JS is not in the scope of RSCs. The
| linked RFC, in my opinion, clearly states for it to be
| expected that a client-side framework and React accept and
| handle the streamed React response[1]. So while it may be
| possible to eliminate a lot of client-side JS, at least
| those would always have to be available on the client,
| correct?
|
| I would also like to make it understood that I'm not here
| to bash the Next project, I am simply interested in the
| technology.
|
| [1]: https://github.com/josephsavona/rfcs/blob/server-
| components/...
| robertrbairdii wrote:
| 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
| mcintyre1994 wrote:
| 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?
| leerob wrote:
| 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.
| mrahmadawais wrote:
| Excellent decision!
| mcintyre1994 wrote:
| Awesome!! Thanks for the answer :)
| kylehotchkiss wrote:
| Hey Lee! Loved the new features and your session on edge.
|
| One further-future question - would react server components
| ever be able to execute on the edge or will those always run
| from the datacenter you've deployed to?
|
| And regions - Cloudflare Workers offers 44 regions in North
| America and Vercel currently offers 4. Does your team have any
| plans to add some more edges around the world to bring the
| speed benefits closer to end users?
|
| Thanks to you and your teams incredible hard work on all the
| new features. Next.js has been a blast to use the past 5 years.
| Looking forward to the next 5!
| leerob wrote:
| Yes, the Hacker News demo shown does run at the Edge (using
| Vercel Edge Functions) when deployed. If you self host, it
| would run on your server of choice.
|
| Vercel doesn't have 4 regions, we have 17 :)
| atoko wrote:
| 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.
| leerob wrote:
| We may investigate this more in the future, but nothing
| planned currently.
| vrepsys wrote:
| How about on demand page revalidation* ? I can't find if it's
| part of Next 12.
|
| *
| https://github.com/vercel/next.js/discussions/11552#discussi...
| leerob wrote:
| It is not part of Next.js 12 - still working on it!
| techpression wrote:
| Any chance we'll get a proper official routing mechanic that
| doesn't rely on the file system and magical file names?
| julenx wrote:
| Also excited about the Rust compiler! Apologies if this is far
| from reality, but by looking at recent commits in GH[1] it
| looks as though this has been rushed for a v12 release, so I
| was wondering how much of internal testing has this been going
| through before pushing it to the broader public.
|
| [1] https://github.com/vercel/next.js/commits/canary
| leerob wrote:
| We've been testing SWC for months now, both with early
| community members on canary releases and with Vercel
| customers. Lots of the rushing at the end was for
| minification, which is opt-in because of this. But
| compilation with Rust (replacing Babel) is stable (which is
| why it's on by default).
| julenx wrote:
| Thanks for clarifying, Lee!
| vaughan wrote:
| The Rust compiler is just swc which has been around as
| another project for ages. Checkout it's home page. Many
| people are using it.
| leerob wrote:
| Yeah, Deno is using it as well!
| devongovett wrote:
| And Parcel: https://parceljs.org
| dev-3892 wrote:
| The module federation story was a bit complicated pre-webpack
| 5. Are there plans in the roadmap to further support module
| federation?
| robertoandred wrote:
| Does Next 12 allow for getStaticProps() in _app.js?
| leerob wrote:
| It does not, but with React Server Components, you can
| achieve the same result.
|
| https://nextjs.org/docs/advanced-features/react-18
| throw123123123 wrote:
| Hey Lee. I am not entirely sure how server-side components
| replace the dynamic/static balance next.js is now the market
| standard for.
|
| 1) Do the .server files require any special infrastructure for
| self hosted solutions?
|
| 2) If we move to ISR to a component level, would that mean that
| a page with multiple components will generate a backend-process
| thrash of multiple refreshes? (say 10 components, each with a
| revalidate 1 s)
|
| 3) Is there a good mapping to translate ISR to server side
| components from both UX and infrastructure/implementation?
| leerob wrote:
| 1. No, when self-hosted, server files will just run on your
| server :)
|
| 2. You can use the `keys` prop to prevent that (this is still
| very experimental and the API is not finalized).
|
| 3. We will be sharing more on this soon, but yeah still early
| days.
| svachalek wrote:
| I'm building a custom server (which hopefully now can be
| replaced with middleware?) which I build with tsc:
|
| $ tsc --strict --esModuleInterop --moduleResolution node --jsx
| react --outdir build server.ts
| node_modules/next/dist/server/config-shared.d.ts:1:15 - error
| TS2724: '"next/dist/compiled/webpack/webpack"' has no exported
| member named 'webpack5'. Did you mean 'webpack'?
|
| 1 import type { webpack5 } from
| 'next/dist/compiled/webpack/webpack'; ~~~~~~~~
|
| Probably there's some workaround but the compile error seems
| legit. Is there something I can do about it until I figure out
| middleware?
| yewenjie wrote:
| When can we expect the docs to be updated?
| leerob wrote:
| They are now updated! Sorry for that. The NPM release took a
| bit longer than expected.
| tofuahdude wrote:
| How does middleware work when using a CDN to host the JS
| bundles?
|
| ie what happens when I've already loaded the bundles and am
| transitioning to a page that has different middleware
| requirements?
|
| Is it a client-only middleware implementation? (I want this and
| have implemented a poor man's version in my _app.tsx).
| emadabdulrahim wrote:
| What's the timeline on React Server components? It seems next
| 12 experimental feature of Server component is a very early
| look? Since React 18 is not out yet, and it's not planned to
| have Server component in that release.
| leerob wrote:
| It's available to try today under an experimental flag. React
| 18 is still in alpha. We'd love to hear your feedback!
| meowtimemania wrote:
| Can we still use obscure babel macros with the new Rust
| compiler? And if so, what do you think the future will look
| like for babel macros in a future where most build tooling is
| written in languages like rust/go?
| capableweb wrote:
| > in a future where most build tooling is written in
| languages like rust/go
|
| You really think most of the build tooling will be written in
| other languages than JS? Compilers make sense, they are very
| CPU bound, but otherwise build tooling should also be
| accessible to modify to the developers working in the
| project, not just those who use Rust/Golang. And I'm sure
| we'll still use JS projects for some of the tooling.
| topspin wrote:
| "You really think most of the build tooling will be written
| in other languages than JS?"
|
| Deno is using the same compiler (SWC) so there is data
| point number two on the question. esbuild is another...
| leerob wrote:
| We're working on making it easier for developers to write
| Rust plugins to handle their own transformations.
| leohonexus wrote:
| Is Next.js Live only available if the project is hosted on
| Vercel?
| sudhirj wrote:
| No, it works fine with any static hosting system, like
| S3+CDN, Netlify or others. The API feature (FaaS) needs
| special server handling to run, but they're just Node
| functions, so other systems also add support.
|
| Vercel just has first class support where everything just
| works, but can you host it yourself.
| revskill wrote:
| With server component, i really think next.js hybrid app with
| cordova will achieve high performance even better than native app
| (like react-native).
| yesimahuman wrote:
| Agreed! Next.js works great with this model! I'd recommend
| Capacitor over Cordova (similar but more modern). Here's an
| example: https://github.com/mlynch/nextjs-tailwind-ionic-
| capacitor-st...
| clivestaples wrote:
| Not to sidetrack but how is this better than wrapping
| Rails/Hotwire app in a Capacitor web view? I'm looking for
| reasons to use Next because it seems super cool.
| yesimahuman wrote:
| I am not very familiar with Rails/Hotwire but the biggest
| difference is this would be a static app bundled into your
| app binary, which is an important consideration when
| targeting native mobile. Beyond that I think it's personal
| preference.
| bowlingx wrote:
| Congrats! This is a very exciting release!
| benatkin wrote:
| The production quality for both this and Jamstack Conf a couple
| weeks ago are very high. I really dig the retro graphics and
| music!
| capableweb wrote:
| 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-configuration React framework that
| simplifies your developer experience.
|
| And if you read the beginning, you'd see:
|
| > Middleware enables you to use code over configuration
|
| 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.
| dude187 wrote:
| Anything sold as erasing away reality eventually becomes overly
| complicated, as you inevitably have to work around it to
| address reality
| gr__or wrote:
| > 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.
| OzzyB wrote:
| > url imports
|
| Aren't they just taking a feather out of Golang's hat?
| [deleted]
| ljm wrote:
| 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.
| Rauchg wrote:
| Our _absolute top priority is security_ , hence why it's under
| an experimental flag that _forces you to whitelist the allowed
| domains that you accept URL imports from_.
|
| Not only that, but before the feature goes GA, we plan to
| double down on our Web runtime alignment, and execute URL
| imports exclusively in the context of the browser sandbox
| (e.g.: the V8 Isolate that backs a ServiceWorker).
|
| This is the trajectory that we are taking for most code
| execution at development time, and it's the technique that
| backs nextjs.org/live, which is the version of the dev server
| that runs 100% in the native browser (no VMs!).
|
| URL Imports represent an opportunity to build a system for
| sharing ES modules that's much safer than what folks are doing
| what npm today, in my humble opinion.
| dntrkv wrote:
| > 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 whatever server you are
| using and then attach all the middleware in a single place.
|
| Their approach IS zero-config. You just add a file with your
| middleware function in the corresponding directory and you're
| done.
| capableweb wrote:
| 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]
| joshmanders wrote:
| > 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"
| jeltz wrote:
| Yes, it is a good thing but I do not see how it is zero
| config (and generally I do not think zero config is a
| good thing). Selecting your set of middleware is config.
| dntrkv wrote:
| The zero-config aspect is that in order to add my own
| middleware to my app, I drop in a file with my middleware
| function into a directory and that's it. There is nothing
| else I have to do. Just like if I want to define a new
| API endpoint, I drop in a file in the corresponding
| directory with the endpoint function defined and that's
| it. That's zero config.
|
| They took all the ease of the old PHP approach and made
| it better.
| dntrkv wrote:
| 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.
| Rauchg wrote:
| 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!
| revskill wrote:
| How to compose middleware then ?
| [deleted]
| tevon wrote:
| 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...
| jekude wrote:
| 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 for a Vercel-for-backend to emerge.
|
| Does anyone know of an existing open source framework + hosted
| cloud platform that is a one-stop-shop for writing a production-
| ready backend in the vein of Next.js + Vercel?
| corentin88 wrote:
| What about Firebase? It's not open-source I know, but it brings
| tremendous primitives to backend (cloud functions, database,
| queues (with Google Cloud Tasks), etc.)
| Graffur wrote:
| Others have posted various solutions but I haven't seen Redwood
| mentioned yet. Would that be something you're looking for?
| swyx wrote:
| 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)
| pistoriusp wrote:
| I use pg-boss (https://www.npmjs.com/package/pg-boss) which
| plugs really nicely into Postgres.
|
| It allows you to define task queues or scheduled jobs, and if
| you're already running Postgres you don't have to host any
| other infrastructure!
| city41 wrote:
| As far as I know, Supabase is unique in this space in that
| you really are given a postgres db. You can log into it with
| any postgres client and do just about anything you want.
| Combine that with its "backend as a service" layer of
| niceties and it's a really potent combo.
| vasco wrote:
| 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?
| jekude wrote:
| Current company's infrastructure is currently all on AWS, so
| using Step Functions. However I really _really_ like
| temporal.io's code-first solution (just didn't want to self-
| host).
|
| Perhaps the dust on best practices / tech for workflows or
| sagas just hasn't settled yet to include in a framework like
| the one I am envisioning.
|
| In general I think Supabase is fantastic in terms of the
| interoperability of all of the features they introduce. Just
| waiting on functions (and perhaps events / queues for async
| communication).
| swyx wrote:
| 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-engine-principles
| jekude wrote:
| 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.
| swyx wrote:
| yeah we hear that a bunch. long term we'll host pollers.
| gotcha tho :) thanks for the thoughts
| nsonha wrote:
| I think amplify wants to be this? Also Hasura, not that I used
| or like them.
| mritchie712 wrote:
| Supabase is headed in that direction and already works for most
| simple CRUD like apps.
| melony wrote:
| Supabase is overly SQL heavy.
| swyx wrote:
| can you elaborate on what "overly SQL heavy" even means?
| it's just a postgres db as a service, use as much or as
| little as you want
| jkaplan wrote:
| 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
| varied and complex than web frontends. On the technical side, a
| web frontend is always just bundles of JS, HTML, CSS, that have
| to be transmitted to the client. And functionally, there's a
| relatively large set of common things they pretty much all do
| (routing, serve images, etc.) Therefore, it's relatively simple
| to build an opinionated framework that can still cover a good
| number of situations.
|
| By contrast, a "backend" is really a lot of different things
| (like the four you mention, plus various types of storage and
| caching), which can use many different languages/technologies,
| all working together in different ways. It's hard to conceive
| of a universal "backend" framework that could cover all of that
| complexity.
|
| 3. There are some efforts to do this kind of thing (to some
| extent). Google's Firebase and AWS Amplify are the two that I
| think are closest -- they try to give low-configuration generic
| backend building blocks. (I'm currently using Amplify for a
| project -- still too early to tell. It also works with
| Next.js!) There's also platform-as-a-service options like
| Heroku.
| jekude wrote:
| 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.
| jkaplan wrote:
| Check out Amplify! I've heard good things and my limited
| experience is good so far. (Although running locally isn't
| the best, unfortunately... but that's always going to be an
| issue the more you lean on a cloud services.) Deployments
| are easy. In terms of scalability, it's all massively
| scalable AWS services under the hood, and it seems
| relatively easy to "eject" if you ever need to.
| dragonwriter wrote:
| > 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.
| jkaplan wrote:
| Even completely leaving aside the language/software
| diversity, the point is that the vast majority of web
| "frontends" are really just one thing (rendering the UI and
| responding to inputs) whereas web "backends" are frequently
| not really one thing (1 or more types of storage, 1 or more
| types of computation, responding to requests, perhaps event
| processing and scheduling, etc.)
|
| I did not mean to imply that all, or even most backends are
| more complex than frontends -- only that the problem space
| of backends is larger and more varied (for typical web use
| these days, at least.)
| charesjrdan wrote:
| Not sure I agree with your first point. Next can output
| static sites easily, I've used it for some tiny marketing
| sites recently and I think its fine for small sites. You get
| auto routing, and can use react components without any
| hassle.
|
| And 'sufficiently dynamic web apps still will want a SPA'
| doesn't make much sense to me because you can just use nextjs
| in full SPA mode and its just as 'dynamic' as any react app
| brandonbloom wrote:
| We're working on something like this at Deref:
| https://exo.deref.io/ - The version of our Exo tool that is out
| there now is a local process & docker container orchestrator
| with log viewer etc. We're working on adding support for a rich
| set of component types like functions, queues, workflows, cron
| jobs, etc. Everything would have a nice console GUI, so you
| don't need to be an expert at infrastructure-as-code, yet you'd
| get a version-controlled manifest file that you can use for
| reproducible deployments. We plan to support deployment to your
| own infrastructure or an eventual PaaS platform.
|
| If folks are interested in working on something like this, my
| email address is in my profile. Don't hesitate to reach out.
| habosa wrote:
| Maybe something like https://encore.dev? Looks like a similar
| mindset.
| jekude wrote:
| This certainly is akin to what I had in mind, and looks
| really great. A couple of thoughts:
|
| 1) Ideally the framework is polyglot (Go seems sensible
| though)
|
| 2) I wish they had queues/events that were wired up to
| functions
|
| 3) Not sure if using autoscaling k8s services under the hood
| as opposed to serverless functions is the right choice
|
| 4) A bit too opinionated on DB/Auth (maybe I don't want to
| use Postgres)
|
| 5) With all of the above you could get really great end-to-
| end integration tests as unit tests that I don't see them
| taking advantage of
| Zababa wrote:
| > 4) A bit too opinionated on DB/Auth (maybe I don't want
| to use Postgres)
|
| This feels like a weird criticism considering Next is React
| only.
| jekude wrote:
| I think your criticism of my criticism is fair. Perhaps
| this is somewhere you simply cannot provide a clean
| abstraction and need to be opinionated.
| Zababa wrote:
| I think that's the case. On the other hand, at a very
| large scale you may want to move out from Postgres while
| React can still be fine. I'm not sure if people change
| more often frontend frameworks or databases.
| pscanf wrote:
| I guess https://dapr.io/ could also be considered a
| contender in that space, though the developer experience is
| not as polished as next.js (yet?).
| IceWreck wrote:
| Django + Django rest framework ? A headless CMS ?
| tonyspiro wrote:
| Most of the modern frontend hosting services also push for a
| backend as a service. Whether it be a DBaaS, like Fauna
| https://www.fauna.com, or Headless CMS, like Cosmic
| https://www.cosmicjs.com as it gives you the auto-scaling
| capabilities without the infrastructure time and headache
| (Disclaimer: I'm CEO at Cosmic)
| leodriesch wrote:
| I would suggest render.com and fly.io if you're looking for
| something that has a similar deployment experience to Vercel.
| fillskills wrote:
| +1 for render. Great experience so far building an airbnb
| like marketplace on top of their services
| jonathannorris wrote:
| We are finding that Next.js + Nest.JS to be a really strong
| combo so far.
| kervantas wrote:
| Great choices. I love Nest.
| maccaw wrote:
| I think because the answer here is using Next.js with hosted
| backend solutions like Firebase, Supabase, Pusher, etc.
| jekude wrote:
| The reason I love Next.js + Vercel though is because I don't
| need anything else for the frontend (besides a CMS maybe).
|
| If I have to use:
|
| 1) Pusher for realtime
|
| 2) Supabase for DB
|
| 3) Temporal for workflows
|
| 4) Vercel / Netlify, etc. for functions / cron jobs
|
| My backend becomes primarily a bunch of stuff glued together,
| rather than something cohesive like Next.js
| bluewalt wrote:
| And you end up with tons a network calls and services to
| monitore, logs, manage and pay.
|
| I'd do the exact opposite by default, trying to have the
| most cohesive service, and occasionnaly use some external
| APIs when I can't do the stuff by myself (eg. Stripe)
| AccountAccount1 wrote:
| Nhost.io does functions, database, Graphql API, rate-limiting,
| authentication. Basically everything you need.
| sbacic wrote:
| I'm using Hasura for that right now to handle the API +
| database part. Fairly satisfied with GraphQL API generators so
| far - they get the ball running quickly and take over the
| boring CRUD parts so that I don't have to.
| AccountAccount1 wrote:
| Hasura is at that level of being a full-featured back-end
| platform. I think that the best way to get started with
| Hasura is https://www.nhost.io
| 1023bytes wrote:
| Why not use Hasura Cloud and also support the developers?
| digvalley wrote:
| For me it is because og the pricing model. Free or $99
|
| I'd pay more to get eur datacenter, but not that much
| when I can host it myself for $5 on DO with the same
| performance (for my usage)
|
| Would gladly pay to support them, so I have given them
| feedback on my pereicament
| gavinray wrote:
| Disclaimer: Work at Hasura > "I can host
| it myself for $5 on DO with the same performance (for my
| usage)"
|
| Yeah for sure, I know what you're getting at. Though it's
| not really so much about performance (there is caching)
| -- There's a chunk of functionality that comes with
| Cloud/Enterprise. The majority of this has to do with
| metrics/observability and monitoring tools, or access-
| control tools for teams.
|
| If you check here:
|
| https://hasura.io/docs/latest/graphql/cloud/index.html#ha
| sur...
|
| And look under "Features" and "Security" you can get a
| decent idea of what the differences are between OSS and
| the Cloud product.
|
| There's 2 demographics I think Cloud stands out to --
| those who want convenience ("I don't want to think
| about/manage my own instance"), and those who want an
| integrated APM tool or more security & access-control
| features, or are working on teams/orgs. >
| Would gladly pay to support them, so I have given them
| feedback
|
| This is always neat to hear! I don't blame you, with
| Cloud being $99 there could be potential for some future
| tier to fill the gap between OSS and Cloud. Like "I have
| some weekend projects but nothing I can afford to blow
| $100/mo" on, you know?
|
| I don't know enough (or really anything) about the
| business side though. It could be that $99 might be the
| only number where it starts to make sense to offer this
| sort of thing, based on infra costs/complexity. Or this
| could be the stupid thing I've ever said. I'm not a
| Cloud-Scientist ;^)
| [deleted]
| digvalley wrote:
| Exactly! I really do think a tier is missing. I was very
| excited about hasura cloud when It came. My dream was to
| move all my hasura instances to the platform. However I
| could not defend spending $99/month on each weekend
| projects or small client work just to get my instances to
| europe (US = very high latency). Hopefully a 'hobby-pro'
| tier will come at some point :)
|
| .. oh, and keep up the good work. I really do love the
| product!
| jensneuse wrote:
| I'm the founder of WunderGraph. https://wundergraph.com/ We're
| doing exactly this. Our philosophy is simple, instead of
| forcing you into a specific stack, we can "introspect" multiple
| data sources like GraphQL & REST APIs, MySQL and PostgreSQL, S3
| for file storage and OpenID Connect for authentication.
|
| This way you can plug and play any of your existing
| infrastructure and services and turn them into your own private
| Firebase.
|
| Finally, because we "introspect" all your data sources, we get
| end-to-end type safety. We don't just generate an API for you
| but also a truly type safe client.
|
| Controlling everything from backend to API client allows for a
| lot of optimizations, e.g. the generated client knows if
| authentication is required to fire off a Query and therefore
| waits until the user is authenticated.
|
| If you have any questions or feedback, feel free to join our
| discord: https://wundergraph.com/discord
|
| We're going OSS 100% soon, exciting times ahead..
| billiam wrote:
| If you like the idea of getting developers out of the backend
| plumbing and repair business you might want to check out
| https://stepzen.com (I work there). We agree that APIs and the
| data sources behind them need to be modernized the way that
| companies like Vercel and Netlify are modernizing frontends.
| Our platform is built on top of GraphQL to give developers that
| one-stop shop for any and all data sources; we'll keep your API
| fast and secure. Next week we're going to release a new product
| to make that even easier.
| midrus wrote:
| Google App Engine?
| quantumOctopus wrote:
| I would give MongoDB Realm a try, it has all the building
| blocks you need!
| asim wrote:
| 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
| biggestlou wrote:
| This appears to be a framework and not a hosted backend
| service
| asim wrote:
| We tried https://m3o.dev. It was a pretty hard thing to do
| with limited resources. Some sort of backend hosting will
| make its way back in soon.
| chrisco255 wrote:
| 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.
| jekude wrote:
| Definitely get that it works as a backend as well. I guess I
| am imagining a frontend-agnostic platform that is more
| backend-centric, rather than targeted directly for frontend
| web development.
|
| Ideally I just get an endpoint from my backend-as-a-service
| (Supabase style) I can pop into Vercel as an environment
| variable, and use it as well in my moblile apps, public api,
| etc.
| Abishek_Muthian wrote:
| If you're already using likes of Supabase, Firebase etc.
| then Parse.com (RIP) was that OG BaaS but Facebook acqui-
| killed it. Now it's available as a open-source project and
| is used by several providers to provide BaaS[1].
|
| I had used both proprietary & open-source Parse until 4
| years back for several production applications but has
| since gone back to relational DB(pgSQL), so don't know the
| current status of the ecosystem.
|
| [1] https://parseopensource.github.io/
| mritchie712 wrote:
| Yep, I'm using Vercel + Supabase for a SaaS right now. Easy,
| fast, cheap, and effective.
| letmeinhere wrote:
| 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.
| gherkinnn wrote:
| Welcome to the Jamstack.
|
| /snark
|
| I'd think of a Next-driven BE as a BE for FE. And since
| it's co-located, You can share types, validators,
| utilities, (mental) models, etc. across the same codebase.
|
| A technique that does have its place. Not always. Maybe not
| even half the time. But cleverer people than me use it to
| some effect.
| rattlesnakedave wrote:
| For this sort of thing I really like fauna
| (https://fauna.com/). I don't think you really "need" a
| "backend backend" anymore, and small dev teams are probably
| better off without them.
| chrisco255 wrote:
| Right, they don't host the databases, but they do integrate
| with other database, etc. providers:
| https://vercel.com/integrations
|
| Vercel itself I believe runs on a combination of Google
| Cloud and AWS.
| adam12 wrote:
| You might be able to use GunJS for your database
| (decentralized). https://gun.eco/
| sroussey wrote:
| Check out supabase
|
| https://supabase.io/
| no_wizard wrote:
| 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, much like you can't with Babel (easily
| anyway without some subprocess hacks)
|
| I love Vue, but it's forever married to the Babel parser unless
| Evan moves over to using SWC for compiling SFCs, which would be
| awesome but he has signaled multiple times he doesn't see the Vue
| Compiler ever being rust based, so it would be reliant on the Vue
| core team (though I think this is mainly his work) porting the
| SFC compiler to using SWC underneath.
|
| JSX frameworks won't have this limitation and can get this
| massive speed gains and energy without such work. I could see
| Stencil and SolidJS adapting easily here
|
| Maybe JSX tools just needs some re thinking to get the same SFC
| experience
| GordonS wrote:
| Sorry, "SFC" and "SWC"?
| DaiPlusPlus wrote:
| At least it isn't SWF...
| GordonS wrote:
| Showing my age here, but IIRC, that was the file extension
| used by Flash files?
| simlevesque wrote:
| SWC, a typescript/js compiler: https://swc.rs/
|
| SFC, single file components.
| abledon wrote:
| man... web technologies are not getting simpler are they lol.
| it just keeps gaining more layers and layers
| nightpool wrote:
| I find that React + styled-components in the same file gives me
| almost entirely the same experience as SFC.
| swyx wrote:
| for >10x the javascript weight of Svelte tho :upside down
| smiley:
| davedx wrote:
| How many extent build-systems are there now for JS/TS? It's
| getting insane.
| no_wizard wrote:
| 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 Next.js 12, from
| what I can tell
|
| ESBuild has also grown out of this, but takes a more
| opinionated direction
|
| This isn't the gulp / grunt -> browserify -> webpack / rollup
| churn of the past in my opinion. These kinds of tools are
| much more targeting on being around in the long haul
| acemarke wrote:
| 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
| simlevesque wrote:
| > 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.
| no_wizard wrote:
| `@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...
| simlevesque wrote:
| I was not aware of this, thank you.
| devongovett wrote:
| Next.js still uses webpack. They basically replaced Babel with
| SWC.
| junon wrote:
| > 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.
| no_wizard wrote:
| 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
| junon wrote:
| I never said it supports AST transformations directly. I
| just said they were trivial to do with esbuild.
|
| Our build times remain at 0.5s with pretty extensive source
| transformers in JavaScript plugins in esbuild. This is down
| from 5-8 minutes using rollup.
| no_wizard wrote:
| I'd need a lot more context to understand what you mean
| by "trivial" and "extensive", respectfully
| [deleted]
| ilovecaching wrote:
| Seems like a ton of tools/dependancies/frameworks to do something
| relatively simple. What is the benefit of this over using Hugo
| with Go templates?
| matsemann wrote:
| One benefit is that it's JS. Yes, really. For every Go
| developer, there are a thousand that know JS.
| jjice wrote:
| I'm not sure how extensible Hugo is, but Next allows full
| server side code. From my understanding (which may very well be
| wrong), Hugo is for static site generation.
| waprin wrote:
| The main benefit of NextJS is that it makes it very easy to
| write code once and quickly swap whether it's going to be
| statically generated ahead of time, rendered on the server, or
| rendered dynamically on the client. It also comes with a bunch
| of features you'll likely need for a modern web page like image
| optimization and a really nice PaaS to deploy it to.
| colesantiago wrote:
| Go's templating system is woefully awful.
| IceWreck wrote:
| If you want a fully static site, go with Hugo. Site generation
| is way way faster.
|
| Next offers using React as your templating language as well as
| adding in server side code if you want instead of static site
| generation.
| CGamesPlay wrote:
| I don't want to hate on Next, because I do like using the
| framework, but a new major version every 5 months for the
| lifetime of the project? How does anybody actually develop an
| application when you have to spend so much time keeping your
| framework up to date?
| eyelidlessness wrote:
| To be fair, some of these updates are more significant than
| others. This one is probably the biggest since I first tried
| Next. React Server Components has the potential to make me
| consider using Next for static (MPA) sites again, which I'd
| previously written off because of the double payload problem.
| swyx wrote:
| the major versions are mostly marketing new features. Next has
| been pretty conservative about how it deprecates APIs, i'd
| wager many Next.js 8 apps could just be updated to 12 with no
| change
| gherkinnn wrote:
| Next has proven to be very backwards compatible to me.
|
| Even large steps, like moving from a server to handle routing
| (and i18n) to dynamic routing or that whole SSR business were
| bug chunks, yes. But in the right direction and without blowing
| up in my face. And could be adopted incrementally and in our
| own time.
| Rauchg wrote:
| Stories like this[1] are not uncommon:
|
| > One of our users upgraded from Next.js _2.0-beta_ to _11_ in
| 5 minutes.
|
| > As @timneutkens said in the Q&A, Next.js incrementally
| improving without breaking changes is worth the investment.
|
| If this is not the case, please let us know. We try to be very
| careful around this, and always leave breadcrumbs for easy
| upgrades in the DX if we absolutely must change something to
| move the project forward.
|
| [1] https://twitter.com/rauchg/status/1405241003653484546
| throw123123123 wrote:
| I've done at least 20 upgrades (user since next 1.0) and it
| is getting easier and easier to migrate.
| tunesmith wrote:
| This was not our experience earlier this year. We experienced
| a sequence of breaking changes in various dot-releases that
| led us to not being able to upgrade from 10.0.6 until 11.0.1
| came out. Basically every single release in the 10.1.x and
| 10.2.x lines were unusable for us. We're very cautious about
| upgrading now.
|
| It's part of why I suggested this issue:
|
| https://github.com/vercel/next.js/issues/26827
___________________________________________________________________
(page generated 2021-10-26 23:01 UTC)