[HN Gopher] Next.js 11
___________________________________________________________________
Next.js 11
Author : jacobwg
Score : 233 points
Date : 2021-06-15 16:06 UTC (6 hours ago)
(HTM) web link (nextjs.org)
(TXT) w3m dump (nextjs.org)
| mvanaltvorst wrote:
| Great to see reduced cumulative layout shift in image tags!
| Next.js seems to be the only modern JS framework with
| accessibility by default. Still wishing i18n would work with
| `next export`, though.
| rawtxapp wrote:
| For the interested they are having a conference right now [1].
|
| 1: https://www.youtube.com/watch?v=ze8ycxc1UzE
| andrewmcwatters wrote:
| > Since Next.js 10, we've been obsessed with further improving
| the developer experience of Next.js. In 10.1 and 10.2 we improved
| startup time by up to 24% and shaved off another 40% of
| processing time for changes through React Fast Refresh. You've
| been getting these amazing speed improvements just by keeping
| Next.js updated.
|
| I know they think this is good marketing, but it absolutely does
| not inspire confidence. Why was it so slow to begin with? Why
| would someone who's never used Next.js want to use it after
| reading this?
|
| Too many JavaScript projects talk about how much faster they're
| getting or how "blazing" fast they are. I don't think these
| people know what "fast" is.
| TechBro8615 wrote:
| So basically your argument is:
|
| - JavaScript is too slow
|
| - Too many JavaScript projects try to not be slow
|
| Am I getting this right?
| smt88 wrote:
| Most of the time savings of a modern JS framework are in
| thinking/coding/researching phases, not "waiting for my build
| to finish". Even for a big site, startup time is not important
| at all if you have hot reloading.
| noahtallen wrote:
| I disagree, start up time is still very useful to improve if
| developers only interact with your project maybe once a week.
| It's also very handy if you're doing CD, as your entire build
| pipeline will finish more quickly, which makes reverts and
| deploys faster. It's also good for quick bug fixes, where
| something needs to be fixed as quickly as possible. It can
| make a big difference on big sites, from like 10 minutes to 1
| or 2 minutes.
| todd3834 wrote:
| Do you feel the same way when Apple releases a new chip that is
| X% faster? For many people: complete + iteration > optimized
| with less functionality
| wicked_gazelle wrote:
| Amazing work on these built-in/opt-in performance, accessibility,
| UX and DX features!
| hyuuu wrote:
| what is the next.js sanctioned way to handle css in js?
| williamstein wrote:
| I think it's explained here: https://nextjs.org/docs/basic-
| features/built-in-css-support
|
| Basically strong encouragement and support for CSS modules, but
| some other escape hatches and approaches are supported.
| vincentmarle wrote:
| I've only very recently heard of Next.js, what is the ideal use
| case for it?
| dbbk wrote:
| If you have a simple marketing or brochure site, and want to
| use React, it's pretty much a no brainer.
|
| Anything more complicated eg a dashboard app, you're going to
| be fighting it a lot.
| thesandlord wrote:
| I do not agree with that assessment at all. Next.js is great
| for making SPAs and full web apps. I've made three
| (profitable) projects with Next.js and never felt like I had
| to fight it
| gherkinnn wrote:
| The key is being page-based. If you can use the browser and
| URLs as a state machine for your application, Next is
| excellent. Its dynamic routing is a breeze to work with.
|
| However, if you build an application where that browser-as-
| state-machine doesn't hold up, you're better off somewhere
| else.
| thesandlord wrote:
| Yeah, you have to follow their design pattern /
| scaffolding very closely. The tradeoff is less
| flexibility for faster dev cycles.
| steve_adams_86 wrote:
| Likewise, I've found it great at allowing you to embed
| complex logic into dumb content.
|
| What we needed was convention to deliver static content
| easily without needing to build it ourselves. But we also
| needed it to stay out of the way of our business logic.
| Overall, Next has done a stellar job of that. It allows us
| to build the stuff that matters to us while leaving what
| Next is great at to Next and its maintainers.
|
| The vercel platform has also been great for us when staging
| deployments. It's a little slow, but the integration and
| ease of use again lets us focus on our own business. I
| don't care to build out staging infrastructure for mostly
| static content. It's well within everyone's ability on this
| team, but it's time consuming in investment and
| maintenance. Recouping that cost is what Next has been
| great for, from end to end.
| dbbk wrote:
| Really? I've made multiple attempts and always get stuck as
| soon as you have nested layouts or routes, which dashboards
| nearly always do (with master/detail views for instance).
| dfabulich wrote:
| "Nested layouts" just sounds like nested React
| components.
|
| React is kinda weird... you have to do subcomponents the
| "React way" and I think a lot of folks struggle with
| that; it can feel like fighting. But I don't think Next
| makes that any easier or harder.
|
| I don't know what you mean by "nested routes." Routes are
| just URLs that map to files. You can create a directory
| with files, and, uh, subdirectories with files, if you
| want...?
| jamil7 wrote:
| I'm guessing they mean pieces of state based on urls,
| like which tab is active here or is a modal open or
| closed kind of thing.
| dbbk wrote:
| In Next, every route blows away the DOM and starts over.
| You can't have nested routes like you can in React
| Router, where say you have different layout shells for
| logged out / logged in views, and then master/detail
| views where you navigate down a hierarchical navigation.
| ranza wrote:
| Well you sort of can. Just have a [view].js file, where
| the view variable will be the component. So you can have
| {view === 'details' && <Details />}
| tablef wrote:
| Do you have any public project template repos?
| steve_adams_86 wrote:
| It's a fairly guard-railed, easy to deploy, React-based static
| site generator with dynamic content capabilities as well. It's
| generally great software. My team uses it for
| https://instantdomainsearch.com and we get good performance and
| developer experience overall.
|
| To me it feels like the React "happy path" at the moment if you
| need a static or partially dynamic site/web application. I
| suppose the ideal use case is essentially any site you want to
| serve statically but maintain with React. This could be a blog,
| graphic design portfolio, or even a small store. It makes it
| easy for us to embed our React-based search application inside
| of a site with static content beside it that's easy to maintain
| and create.
|
| Yeah, we could do this without next, but it provides some
| convention and well-made tools that generally make the job
| easier.
| vincentmarle wrote:
| Cool, I'm a big fan of instantdomainsearch (it's my goto
| domain search tool) and had no idea how you can lookup the
| domains that fast. Is it fair to say that Next.js is a big
| part of that performance?
| steve_adams_86 wrote:
| Next.js isn't a significant part of the run time
| performance of actual searching - that's fast because of a
| lot of custom infrastructure, data pre-processing, and
| client side code.
|
| Next mostly makes it so pulling the site down and loading
| the page is snappier without us having to try particularly
| hard to get it that way. It isn't totally effortless -
| we've got some tailored pieces in our pipeline, but Next
| "off the shelf" does an excellent job already, and the work
| they've done makes customizations easy to implement and
| maintain.
|
| I'm glad to hear you like it! Seriously, it makes it way
| more interesting knowing people are enjoying it. Every
| little tweak and improvement to performance is worth it
| when people are getting something out of it.
| bradhilton wrote:
| I also really like instantdomainsearch.com. I don't have
| any specific feedback, but thank you for your team's
| work!
| steve_adams_86 wrote:
| You're welcome!
| notjustanymike wrote:
| I've only ever used Gatsby with this, how does it compare?
| steve_adams_86 wrote:
| Good question.
|
| Our migration was fairly direct. We did it in around a week
| with some cleanup in the following week. There were
| analogous conventions throughout just about the entire
| migration, so they're very similar.
|
| One thing we liked was better TypeScript support. We're big
| on types and proper support, and most of our company is
| based on TypeScript and Rust. Gatsby can use TS, but you
| need to set it up and we came across the odd hiccup in the
| tooling. Next supports this off the shelf and so far, it
| shows. We haven't had any issues with compilation anywhere
| in the pipeline or other tooling.
|
| The way Next handles dynamic pages is different, and in my
| opinion nicer. It also supports something they call
| incremental static generation which allows pages to be
| served statically, but incrementally updated as dependent
| data changes. For example, you know the team in the lead
| will be the same for thousands of requests, so you might as
| well serve that statically until the leading team changes.
| Next will manage that content update for you while serving
| the content statically for as long as possible. When we
| migrated, Gatsby didn't support this feature.
|
| Next handles pages differently in general. It maps your
| directory structure under /src/pages, so that
| /src/pages/hello-world.tsx will be yourwebsite.com/hello-
| world. It allows for dynamic content using a convention in
| which file names can represent a variable, where
| src/pages/foo/[bar].tsx will make it so [bar] is a variable
| in the query intercepted by getServerSideProps when you
| visit yourwebsite.com/foo/whatever.
|
| Otherwise I think the main snag we had with Gatsby was that
| the team was slower to address issues, introduced bugs more
| frequently, and we began to see that it was impeding our
| progress. Our software was working independently of Gatsby
| and wasn't the issue, and no matter how closely we worked
| with the maintainers, we couldn't move the needle on any
| blocking issues. With Next it has been a much different
| story. Issues are unblocked routinely and the maintainers
| seem much more engaged and productive.
|
| There's more, but those are the main differences that come
| to mind.
| 48309248302 wrote:
| > Gatsby can use TS, but you need to set it up
|
| I'm not sure how long ago you tried Gatsby, but
| TypeScript doesn't require setup anymore. Just change the
| file extensions to .tsx/.ts and it works. It also does
| incremental builds.
|
| Gatsby handles pages in src/pages the same way except it
| doesn't use placeholders in the filenames. You generate
| dynamic pages by writing a function. Check out these
| videos.
|
| https://egghead.io/courses/why-gatsby-uses-
| graphql-1c319a1c
| steve_adams_86 wrote:
| Right, graphql - I'm not sure how I forgot about that. We
| really disliked this part of Gatsby, but I know some
| people really like it. I can't criticize it really - it
| probably comes down to preference.
|
| I guess it's been longer than I thought! Incremental
| builds wasn't even on the roadmap when we migrated.
| unknown_error wrote:
| We're using it to build a headless Jamstack (headless CMS
| backend, React frontend).
|
| Next.js makes the frontend a lot nicer to work with, especially
| if you want to deploy to a serverless config. Out of the box,
| it handles things like:
|
| * Data pre-fetching (Next talks to the CMS during _build_
| instead of via a clientside request during load), then inlines
| the JSON response into the page so the React components have
| access to their initial load data (like the first page in a
| gallery, or the first set of blog posts) as soon as the page
| loads. No AJAX required. It 's FAST for visitors.
|
| * Handles page routing (like /blog/my-post or /products/24453)
| by mapping CMS entries into page templates
|
| * Makes the developer experience a lot nicer, with
| preconfigured but extensible webpack, sass, tailwinds etc.
| support. Also extends the create-react-app dev server to
| support all the next features so you can get a good preview of
| how something works before you build for production
|
| * Adds a bunch of optimizations (CSS, web fonts, tree-shaking)
| for faster performance
|
| * Has optional modules you can use (authentication, ecommerce,
| AMP, etc.)
|
| * It renders React + the data into straight HTML+CSS (again,
| fast) and that means some React components also work without
| Javascript enabled
|
| Additionally, if you host on Vercel*, you get some additional
| features:
|
| * Automatic image optimizations (auto-generated srcsets, webp,
| blurry lazy loads, etc. on the CDN)
|
| * Incremental static regeneration: A backend server monitors
| the CMS for changes every X seconds, then rebuilds only the
| affected page (in a few seconds) instead of the whole project
|
| * Complex rewrite rules that would normally be difficult with a
| static site. Not as powerful as .htaccess or Varnish rules, but
| good enough for simple cases
|
| In general, the upside is that it turns React from a feature
| library to a more fully-featured web app framework. Still not
| as powerful as Angular, but hits that sweet spot where you can
| easily spin up a website with Next.js in a few minutes, and not
| have to worry about scaffolding or be overwhelmed by having to
| get a PhD in Angular before you can start using it.
|
| The downside is that its primary maintainer, Vercel, also runs
| a hosting service. There is an inherent conflict of interest
| there because some Next.js are Vercel-only, and these are NOT
| clearly labeled in the docs. You just have to find out, upon
| deployment, that some features just invisibly break with no
| error or warning if you try to self-host or host elsewhere.
| Everything magically works on Vercel, but it's a crapshoot
| anywhere else. And it's only getting worse as they keep
| iterating features like next/image or Next Live but only with
| Vercel support.
|
| Edit: Sorry about the formatting. I don't know what formatting
| engine HackerNews uses but it's awkward.
| gherkinnn wrote:
| As Next ambiguously puts it: "The React Framework for
| Production" [0]
|
| It's excellent for building page-based sites and apps and comes
| with lots of nifty features that just seem to work. And, the
| most part, it's just out of your way.
|
| Regarding the ideal use, I'd say any project that benefits
| greatly from (partially) pre-rendered content and statically
| generated pages is best served by Next and its data fetching
| [1]. I can't think of a FE-based solution that is anywhere near
| as good. It's also the only sane way to work with the insanity
| that is JAM stack [2].
|
| Whatever you do, it's a safe bet.
|
| 0 - https://nextjs.org
|
| 1 - https://nextjs.org/docs/basic-features/data-fetching
|
| 2 - https://jamstack.org
| blowski wrote:
| Worth adding that Next is to React what Nuxt is to Vue,
| though if you don't know what Nuxt is, that won't help.
| gherkinnn wrote:
| And what Svelte Kit is to Svelte. ;)
| anichhangani wrote:
| sounds similar to aspnet razor pages. is it?
| RobertKerans wrote:
| Looking at the razor pages overview & that seems a very
| reasonable comparison (now you mention that, see PHP, in
| the form of "just chuck a few files on a server that
| understands them and off you go, dynamic website")
| timomeh wrote:
| This whole conference could have been an email.
| dbbk wrote:
| Well to be fair at least it was only 20 minutes. But yes, I
| don't really see the point in the whole Apple-like video
| production.
| williamstein wrote:
| The interesting and useful part of the conference (to me) was
| the live video chat and Q/A with the 7 devs after the polished
| video, which is still going on right now.
| TechBro8615 wrote:
| That sounds cool! But on their YouTube I only see the 24
| minute keynote. Do you have a link to this Q/A?
| styfle wrote:
| https://www.youtube.com/watch?v=ANikp1R8zX8
| damsta wrote:
| Really solid release, congrats to the team and contributors!
|
| P.S. I have noticed that you put a markdown link as `src` prop
| value in the first `Script` example.
| r6203 wrote:
| Still no option to export a static site when using next/image
| without relying on 3rd party services, right?
|
| The only option that comes to my mind is using Vercel to host the
| site but then every image is transformed on demand which results
| in horrendous loading times.
|
| Is this really how ,,everyone" uses Next when exporting static
| sites?
| ismayilzadan wrote:
| Not sure if this would fit into your use case, but in my use
| case, I have custom js code which runs at the build time and
| downloads/compresses/resizes all the required images into
| node.js file system. Then, next/image serves them as it would
| from local static image source. The drawback is I have really
| long build/export times.
| _fat_santa wrote:
| The lack of official solution eventually made me ditch in favor
| of Gatsby. Granted it was a large change but I found that the
| way Gatsby handled images was just better than how Next.js
| handled them.
| leerob wrote:
| We're working on this!
| https://twitter.com/rauchg/status/1402613436081528836
| quaffapint wrote:
| That's why I removed next/image and ended up using
| https://github.com/cyrilwanner/next-optimized-images
|
| That lets you export the images pre-optimized for different
| sizes/etc. You can then do a normal next export.
| lucas_codes wrote:
| Unfortunately it doesn't seem to be maintained anymore.
| steve_adams_86 wrote:
| This works well for us too. It doesn't have all the
| conveniences of next/image, but it lets you get closer to
| more reliable and better performance in our experience. Yes
| you need to understand what you're doing a little better, but
| it isn't rocket science.
| nickdandakis wrote:
| Also disappointed by this. Vercel has increasingly been putting
| out more features that are tucked behind a vendor-lock.
|
| - `next export` when using `next/image` doesn't have a sane
| default
|
| - Running a custom server means no deploying to Vercel. I
| understand that one the most, since Vercel has decided to lean
| on serverless
|
| - Next.js Live can only run on Vercel
|
| I still reach for Next.js + React first when starting a new web
| project, but have since replaced Vercel with Render because
| more times than not, I need to run something that just doesn't
| work on serverless. Been a user and fan since v1.0.0, and have
| only just started noticing some features that go against the
| "sane defaults, config available" ethos that seems to be core
| to the team.
|
| No hate, just observations.
| rawtxapp wrote:
| >Running a custom server means no deploying to Vercel. I
| understand that one the most, since Vercel has decided to
| lean on serverless
|
| For those who want simple serverless deployment, but don't
| want to vendor lock in with Vercel, checkout serverless-
| next.js, it makes deploying to aws lambda@edge directly a
| breeze, it's awesome![1].
|
| 1: https://github.com/serverless-nextjs/serverless-next.js
| blowski wrote:
| Does it work with Amplify?
| leerob wrote:
| This is not entirely accurate. First, we are working on
| build-time image optimization, it just wasn't our first
| priority
| (https://twitter.com/rauchg/status/1402613436081528836).
| Second, the vast majority of Next.js applications do not need
| a custom server.
|
| Finally, Next.js Live is two parts - the soon open-source dev
| engine, and the collaboration features. The first will be
| open-source, always. The second can be any platform (like
| Vercel) with the ability to sync and store your code edits.
| [deleted]
| myth_drannon wrote:
| I see Next.js being pushed into areas where is shouldn't be used.
| And I mean like data heavy enterprise web apps. Probably in a
| year or two these projects will collapse under the heavy
| maintenance burden and will start seeing a lot of unearned
| negativity towards Next.JS
| TechBro8615 wrote:
| Why shouldn't Next.js be used in "data heavy enterprise web
| apps?" Keep in mind that it's trivial to write code that only
| executes during CSR: if (typeof window !== "undefined") {
| fetchExpensiveExternalData(); }
| tmp_anon_22 wrote:
| Not OP but i'll take a stab at this. Many frameworks struggle
| to allow you to utilize a small subset of their features at
| full utility without producing additional overhead from
| features you aren't even using.
|
| Further frameworks can be deceptive by making complex problem
| sets seem easy to deal with but later involve complex
| refactoring over time as the problem set is better understood
| and evidently less trivial for your organizations particular
| wants and needs.
|
| These problems aren't highlighting any implicit fault of
| next.js. Just predicting incorrect ways developers will use
| it and suffer from. There is an argument to be made these
| problems would be made less severe if they were approached
| from the ground up without a framework and what opinions it
| brings.
|
| Also FWIW I like next.js the project a lot. Hopefully Vercel
| proves a good steward for it.
| koonsolo wrote:
| Tell me about it.
|
| Some of my colleagues are pushing hard for it. It seems like
| nice tech, but when you build an enterprise web app behind a
| login page, I see no need for server side rendering.
|
| Our users open up the app in the morning, work on it a whole
| day, and do the same thing the next day.
|
| I absolutely see no point in trying to optimize this with
| server side rendering.
|
| But it seems some front-enders want to use the latest best
| thing, even when it's not really necessary.
|
| But what do you do? Do you make these developers unhappy
| because they are not using the latest cool thing, or do you
| make them happy but end up with an inferior solution?
|
| Oh boy, these youngsters... ;)
| midrus wrote:
| You hire non hipsters.
| lucis wrote:
| "Next.js has two forms of pre-rendering: Static Generation
| and Server-side Rendering. The difference is in when it
| generates the HTML for a page."
|
| https://nextjs.org/docs/basic-features/pages
| koonsolo wrote:
| Yeah, so why would you need a custom web server when you do
| CSR?
|
| Edit: next.js is a web server, right? Because how else can
| it do SSR?
| louissm_it wrote:
| Why would you need a custom web server to run Next.js in
| CSR mode?
|
| Edit: Unintentional sarcastic reply from my side, it was
| a good question.
| lucasmullens wrote:
| You can disable SSR and still use Next.js. Most people don't
| use Next.js because of SSR, they use it because it's easy to
| use and has an amazing developer environment. SSR works out
| of the box usually so it's a nice perk.
|
| If you're using React, Next.js is a pretty excellent choice
| for pretty much any website.
|
| Appeal to Tradition is just as much a logical fallacy as
| Appeal to Novelty.
| louissm_it wrote:
| I'd argue most Next sites use only client side rendering.
| koonsolo wrote:
| So using the export function? Or do they still run the
| next.js server without having the real benefit of it?
|
| In other words: what is the benefit of next.js when you
| only do CSR?
| crooked-v wrote:
| It's easier, faster, and has more default features than
| setting up Webpack by yourself.
| louissm_it wrote:
| Great question! If you're interested, I'd recommend
| reading up a bit on all the different rendering and
| deployment modes Next offers with and without
| Vercel/Netlify.
|
| If you use Next.js only for CSR, as I'm sure most people
| do, the benefits are great defaults, easy upgrades,
| fantastic routing, page prefetching, and easy upgrading
| to any of the other rendering modes if you ever need
| them.
|
| You don't run any kind of server if you just use CSR -
| you bundle your code and push it to anywhere you'd push
| your normal React SPA (CDN, Vercel, Netlify, etc). I you
| decide you need to server side render or pre render a
| page, you can of course run a full node server - but the
| far easier route is to use the Vercel/Netlify lambda
| functions(which work out of the box with Next).
|
| I find thinking of Next pages as separate little apps
| composing the same layout component to be far more
| maintainable than the more traditional SPA single layout
| swapping the contents to simulate a page transition.
| stewartmcgown wrote:
| in our teams experience NextJS is pretty much a silver bullet
| for data heavy enterprise apps
| myth_drannon wrote:
| Can you elaborate? My understanding is that SSR and NextJS
| are good for SEO and low powered devices with a slow
| connection. You load the content before the interactive js
| ...etc. Why would enterprise apps care about SEO, slow
| connection speeds. If it's data heavy, it means you still
| need to fetch data from db before you return html, so SSR is
| pointless.
| brailsafe wrote:
| In many cases SSR is automatically better, including the
| ones you're talking about, because page rendering errors
| get thrown in an environment you have more control over, as
| well as faster devices rendering your already fast pages
| even faster. In my experience, enterprise work stations are
| clunky abominations, and if you can save someone some ram
| and battery why not? It also gives you a platform for
| building other kinds of non-gated apps that inherit the
| same benefits.
|
| You might think you have control over the environment
| someone accesses the app in, but you don't, at least not
| entirely, and why not just make it as easy as possible to
| get their work done however they want?
|
| Of course, this doesn't make your thing automatically
| better all around. That's a design and implementation
| problem. But you do potentially help everyone by starting
| at the bottom
| koonsolo wrote:
| Round trip to the server to compose your HTML feels less
| responsive. Else you could just do it in PHP anyway.
| azangru wrote:
| > you could just do it in PHP
|
| That's two languages: javascript and php. Many frontend
| developers would prefer to just work with one --
| javascript.
| SamBam wrote:
| > If it's data heavy, it means you still need to fetch data
| from db before you return html, so SSR is pointless.
|
| I'm very confused by this statement. Maybe I'm just being
| slow. If you want to fetch data from the db before
| returning html, then SSR is exactly what you want.
| koonsolo wrote:
| When you do a proper REST call, your data is always going
| to be smaller than your html+data.
|
| If you don't show it, you don't need to query it.
| chatmasta wrote:
| He's not wrong in some cases. If bandwidth cost from
| Next->Client exceeds cost from DataSource->Client, then
| you want to opt out of SSR, to avoid
| DataSource->Next->Client in favor of direct
| DataSource->Client during CSR.
|
| Example: Next deployed to AWS (metered bandwidth), with
| DataSource deployed to colocation (unmetered bandwidth).
| Page fetches 1GB CSV from DataSource in order to render
| an HTML Table. In this case, you likely prefer the client
| to fetch directly from DataSource and render the HTML
| table during CSR. An exception might be if you care about
| the table for SEO purposes (e.g. structured data) - but
| in that case, you should find a way to fetch the first 10
| rows instead of 1GB.
|
| It's a fairly niche use-case, though, and it's easy to
| opt out of SSR for specific code/requests (check if
| window is defined) or pages (use Next getServerProps vs.
| getStaticProps).
|
| As an aside... this convoluted scenario highlights one
| criticism I have with Next.js: It is NOT a friendly
| mental model for junior engineers. You cannot write a
| robust Next app without a thorough understanding of the
| HTTP request lifecycle, network architectures, closures,
| database/HTTP pools, caching, cookies, etc. If you stay
| within the lines, you can avoid worrying about most of
| this stuff, but it's impossible to fully grok Next
| without a strong background in web fundamentals. If I
| were advising a beginner on the best stack for practicing
| React, I would suggest starting with create-react-app,
| even though I think Next is ultimately the best
| production framework.
| azangru wrote:
| > low powered devices with a slow connection
|
| Some would argue that React in general isn't a good fit for
| low-powered devices with a slow connection, because of its
| bundle size, long first input delay and a rather high cost
| of heavy javascript usage during re-rendering.
| Marciplan wrote:
| Isnt that what happened to Gatsby oO
| BoumTAC wrote:
| isn't that what happened with every js framework ?
|
| 99% of all js project would have been better with an old
| school framework (Rails/Symfony/Django/laravel, and any other
| framework I forgot the name)
| jstummbillig wrote:
| Next excels in frontend grease, a place where the ssr
| frameworks do not venture.
|
| I so agree that next is not the ultimate answer. Still
| waiting for the absolute best of both worlds.
| CraigJPerry wrote:
| Maybe something like Phoenix liveview? (or htmx /
| livewire / hotwire/ etc.)
|
| Write SSR, but have the ability to render partials and
| swap html chunks into the DOM directly rather than
| running json through a CSR library.
|
| You still get client originated events (user clicks a
| button) or server originated events, e.g. server wants to
| proactively push a change - at least for liveview and
| htmx.
| ironmagma wrote:
| Why should Next.js not be used for this use case?
| striking wrote:
| I use it without SSR, just because it's a well-known and very
| well-maintained set of configs. Having to upgrade webpack et
| al. up major versions sucks.
| dinkleberg wrote:
| I'm doing the same, it is the easiest out of the box react
| setup I've encountered.
|
| The nice thing is on a current project I found there was one
| view where SSR made my life a lot easier and since everything
| was in place for it all I had to do was chuck in an extra
| function.
| MrSaints wrote:
| +1 for this. The great thing is you still have the option to
| incrementally opt for SSR and/or enriching statically
| generated pages with build-time data.
| koonsolo wrote:
| Some people here seem confused why SSR is not the optimal
| solution for heavy web apps, so let me explain.
|
| Such web apps can be downloaded to the client the first time
| you open the page, and after that (basically every day),
| caching strategy makes sure you don't have to download that
| thing again.
|
| Which means you only need to transfer pure data at that point,
| and you can have a very responsive web page.
|
| SSR rendering on the other hand, you will get some kind of PHP
| website (OK, this is exaggerated, but you get the point).
| Requests go back to the server, and the server renders the
| page. Totally ludicrous.
|
| SSR: for landing pages, SEO optimization, showing the same page
| to a lot of users, etc.
|
| CSR: for heavy apps that you use regularly, basically "real"
| applications, not web pages.
| ihuman wrote:
| > SSR rendering on the other hand, you will get some kind of
| PHP website (OK, this is exaggerated, but you get the point).
| Requests go back to the server, and the server renders the
| page. Totally ludicrous.
|
| NextJS only renders (or gets the static HTML) and sends you
| the HTML for the first page you navigate to. When you click a
| link on that page, it just sends you the data (and JS if
| needed).
| underwater wrote:
| In theory, yes. But is anyone actually effectively writing
| apps in that way? I can't think of a single good example I've
| seen in the wild.
|
| Most of the time the app is either large and sprawling,
| updated frequently, or XHR fetches are written in an
| inefficient way. All of these nullify the benefits from the
| model of having cached application code. For example if
| you're waiting for your JS app to initialise, then fetching
| XHR in a serial way you're probably slower than an SSR page
| that is sending a data blob down inline.
|
| I'd say SSR is a good rule of thumb, and the few people who
| build SPAs who can make use of this will know when to break
| that rule.
| [deleted]
| chris_engel wrote:
| Partial hydration would have been a game changer in performance
| of nextJS based websites.
|
| I am a bit perplexed about the new "live" feature. Its just so
| far away from the framework business (poof, now its an IDE), I
| have no words for it...
| ludamad wrote:
| As far as I know, it looks like an experiment with Vercel more
| than anything. It seems the majority of the IDE development has
| interest beyond this, and this is a framework that wants to be
| first-class (I could be off on the latter part)
| eyelidlessness wrote:
| For partial hydration, take a look at:
|
| - Astro[1]
|
| - Microsite[2] (disclosure: I was just added as an
| owner/maintainer today! But Astro is definitely currently more
| mature)
|
| - next-super-performance[3]
|
| - Marko[4]
|
| 1: https://astro.build
|
| 2: https://github.com/natemoo-re/microsite
|
| 3: https://github.com/LukasBombach/next-super-performance
|
| 4: https://markojs.com/
| midrus wrote:
| To me this is just the conflict of interest just kicking in.
| Next is not built as rails, Django, Vue, etc... Next is a part
| of their business.
|
| Don't believe it? Just look at the telemetry "feature". Try to
| disable it...something that should be just a config in
| next.config.js is a convoluted trap which will only disable it
| on your machine and you need to remember to disable it
| everywhere, etc...
|
| As with Facebook (well, not that bad, but still...).Next isn't
| free.
| steve_adams_86 wrote:
| I agree. I was a little disappointed to see resources going
| towards this. It feels like they're seeking ways to create
| vendor lock-in, which my team fairly aggressively avoids. Next
| has generally been great about this, and part of the initial
| appeal. It's just React components inside of an easy-to-
| understand framework.
|
| This, though - my instinct is to stay away from it, personally.
| It doesn't seem to be their wheelhouse and it doesn't
| necessarily make Next.js better.
| STRiDEX wrote:
| I think the real lock in is with serverless deployments. Its
| currently pretty hard to deploy nextjs to aws lambda on your
| own.
|
| I thought they would announce a vercel@edge product since
| they made everything work with webassembly. Maybe later?
| JMTQp8lwXL wrote:
| Vercel being a profitable entity is what encourages them to
| continue supporting Next.js. It's a fine line. The product
| has to be built in a way for free users to easily pick it up
| without any immediate, tightly-coupled unavoidable lock-in.
| Safe to say, if you're depending on Next, you do want Vercel
| to win.
| steve_adams_86 wrote:
| Great point, and you're right - I do want to see them
| succeed. I suppose I just hope success doesn't end up
| impeding the framework. As it is we happily pay for staging
| on their infrastructure, so we don't have any issues with
| supporting their efforts monetarily. Hopefully that
| clarifies my concern better.
| leerob wrote:
| Next.js Live will have a completely redesigned open-source
| dev server, which anyone can use to create collaboration
| features on top - no lock in.
|
| This server has been overhauled to run entirely in the
| browser, using technology like ES Modules, Service Workers,
| and WebAssembly.
| chatmasta wrote:
| I had this same reaction to next/image. I see where they're
| going with it though. They're obviously prioritizing
| e-commerce publishers because they tend to have high traffic,
| semi-static content, and a clear business use case for fast
| websites. They are also the most likely to pay Vercel to host
| their sites.
|
| As long as features like next/image and "live" remain opt-in
| and don't otherwise affect build/dev times, I have no problem
| with Vercel targeting a lucrative market. Anyone who relies
| on Next should want Vercel to be a long-lasting company.
|
| Besides, this is the first release of "live" - I can see this
| workflow becoming appealing to marketing and design teams.
| It's good practice to separate your marketing website from
| your application, so why not use "live" to enable non-devs to
| edit it? That's what Jamstack is all about - empowering the
| marketing/copywriting/product teams to edit content in real
| time. Maybe "live" is simply the next logical step of
| Jamstack - teams of non-devs editing the code and design of
| websites as easily as they can edit their content.
|
| Developers should be all for that, even if they aren't the
| target audience of the live features. Reducing friction
| between dev and non-dev is a win for everybody. Marketers are
| happy because they can edit content without waiting on
| devs/deploys, and devs are happy because they talked the non-
| devs out of using WordPress, and got to build a new site with
| a hot technology.
|
| I wonder if Vercel considers Automattic a competitor. The
| "percent of the web" stat is a juicy KPI to compete for.
| cwales95 wrote:
| I personally can't see any benefit of allowing non-devs
| near code. Personally, any time I've seen clients / non-
| devs near code (or non-content / admin / HTML / CSS type
| things) that's when things go bad and I have have to fix
| things.
|
| I'd be interested to see how this would work in practice
| but I'm skeptical at the moment.
| PaywallBuster wrote:
| Do they maintain old releases? for how long?
|
| can't find any information about it
| thangngoc89 wrote:
| They don't. Next.js uses the same release methods of React.js.
| If the previous major version doesn't give you any warnings,
| you can upgrade without any modifications. You can check
| upgrade guide here: https://nextjs.org/docs/upgrading
| yepthatsreality wrote:
| No one maintains anything in JS world. You just upgrade or hop
| to the next framework. The ES spec I believe discusses
| backwards compatibility but that only applies at the language
| level.
|
| It wouldn't be the cool hip framework if it had to commit
| resources to older versions.
| throwthere wrote:
| You're not wrong but there's probably a nicer way to say it.
| yepthatsreality wrote:
| Honestly it's the last line that gets me the downvotes (oh
| no downvotes!) and this was intended. I think being brash
| about it is a good way to take a look at where the world
| can improve.
| juancampa wrote:
| Nodejs, arguably a big part of the "JS-world", has LTS
| https://nodejs.org/en/about/releases/
| trutannus wrote:
| This is node itself, not libraries or frameworks.
| yepthatsreality wrote:
| You're downvoted because Node is considered a framework.
| So while you're not technically correct, I think your
| response is still valid as "I caught your drift".
| codetheweb wrote:
| Really happy to see blur placeholders and automatic dimension
| detection of local sources being added to the Image component.
| dang wrote:
| Related ongoing thread:
|
| _Next.js Live: Code in the Browser with ESM, ServiceWorkers,
| Replicache, and WASM_ -
| https://news.ycombinator.com/item?id=27517440 - June 2021 (23
| comments)
___________________________________________________________________
(page generated 2021-06-15 23:01 UTC)