5 ms·
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
by myth_drannon 5y ago
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
- striking 5y agoI 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 5y agoI’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 5y ago+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.
- Marciplan 5y agoIsnt that what happened to Gatsby oO
- BoumTAC 5y agoisn'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 5y agoNext 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 5y agoMaybe 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.
- aabbcc1241 5y agoPhoenix Liveview shows great idea, but I prefer to develop in typed environment so I'm working on ts-liveview (TSX+SSR+live-update)
- ironmagma 5y agoWhy should Next.js not be used for this use case?
- TechBro8615 5y agoWhy 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 5y agoNot 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.
- stewartmcgown 5y agoin our teams experience NextJS is pretty much a silver bullet for data heavy enterprise apps
- myth_drannon 5y agoCan 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.
- SamBam 5y ago> 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.
- chatmasta 5y agoHe'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.
- koonsolo 5y agoTell 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 5y agoYou hire non hipsters.
- lucis 5y ago"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 https://nextjs.org/docs/basic-features/pages
- koonsolo 5y agoYeah, 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 5y agoWhy 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.
- louissm_it 5y agoI'd argue most Next sites use only client side rendering.
- koonsolo 5y agoSome 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.
- underwater 5y agoIn 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 5y ago[deleted]
- ihuman 5y ago> 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).
- TechBro8615 5y agoThis comment is highly misleading. It implies that SSR vs CSR is an “either or” proposition: > SSR rendering on the other hand... Requests go back to the server... Totally ludicrous. For Next.js, this description of routing and rendering is “Totally” incorrect. I don’t know about other SSR frameworks (except maybe PHP, which does actually work as the parent comment describes), but with Next.js, you get SSR on first page load and CSR on subsequent clicks. Thats the whole point of next/router and the <Link> component. Hovering a <Link> will download (“pre-load”) the tiny JS file required to render the next page. Clicking it will trigger client side rendering, without any new server side page load. The complexity that causes this kind of misunderstanding is the best argument against SSR.
- kgin 5y agoThe great thing about Next.js is that it’s simple to choose exactly how much of a page is ssr. You can have 0% to 100%.