Does anyone else feel that the complexity of the full-stack frameworks is getting untenable? 1. There is a significant gap between dev and production environments. (See #2 why this is critical) 2. The production build times are super high 3. ES modules are great, but the JS ecosystem being a bundle of small libraries, getting them all to play nice is hard. 4. I occasionally get X is included twice errors that are pai…
Late last year I listened to talk on nextjs and I was floored by its design. I still can’t get over that the JS community has embraced file system routing and server rendered stuff. I honestly think I’m taking crazy pills because I could have replaced “nextjs” with “PHP” in most places and it would still make sense. I have been in software for about a decade and I think I’m experiencing my first complete cycle of “wh…
New React docs pretend SPAs don't exist anymore
211–220 of 225 posts
Re: New React docs pretend SPAs don't exist anymore
#212All our application lives behind an authentication except login pages. I still cannot grasp how would I use Nextjs in only SPA mode. Not everything needs to be SSR, I don't want to spare resources, just want to deploy it to S3, put cloudfront infront of it, let 404 requests return index.html and I can use the URLs without #. SSR should not be a must the docs should reflect that. There is no way I'm paying Vercel 20$…
I never understood where the idea came from that if pages are authenticated, then SSR isn't needed. Maybe because people think the only benefit is SEO. The biggest benefit is performance. SSR is still great to have behind authenticated pages, to improve load times. eg multiple tabs, continuing sessions, etc. There are countless examples of sites that usr SSR + CSR + Auth - Netflix, Github...
If you are building web apps that live behind auth, it's a no brainer to use CSR. It's easy to deploy, cheaper to host and serve, not harder than SSR to develop. The cons about performance can be solved using code splitting. Moreover with proper caching, the app loads instantly.
Are there new age alternative CRA that provides a scalable project architecture like Next.js provides. Maybe it can come with basic libraries like react-router, react-query, pre installed and Vite pre configured.
Re: New React docs pretend SPAs don't exist anymore
#213Earlier quoted context omitted.
Sorry what JS? With aforementioned Apache Struts there's no need for JS to render anything. But if one wishes, JS can be added, of course (e.g. for DHTML stuff). To avoid render blocking there are "defer" and "async" attributes.
I have 8 years of PHP experience. Let me explain to you. While you can build a static website with Apache Struts or PHP, you must add javascript if you want to build complex sites anyway, for example: Facebook, Twitter, Tiktok,... In the past, everyone used jQuery, but jQuery and ajax can't build complex sites. You will end up with too many Ajax + dynamic elements + bad practices and can't maintain them if you use jQ…
Re: New React docs pretend SPAs don't exist anymore
#214But… they don’t, really. “SPAs” are just a corruption of the web brought about by people who obsess over replacing end user operating systems with HTML+CSS+JavaScript. Most actual users would be just as happy to install a real native application.
Re: New React docs pretend SPAs don't exist anymore
#215Does anyone else feel that the complexity of the full-stack frameworks is getting untenable? 1. There is a significant gap between dev and production environments. (See #2 why this is critical) 2. The production build times are super high 3. ES modules are great, but the JS ecosystem being a bundle of small libraries, getting them all to play nice is hard. 4. I occasionally get X is included twice errors that are pai…
Late last year I listened to talk on nextjs and I was floored by its design. I still can’t get over that the JS community has embraced file system routing and server rendered stuff. I honestly think I’m taking crazy pills because I could have replaced “nextjs” with “PHP” in most places and it would still make sense. I have been in software for about a decade and I think I’m experiencing my first complete cycle of “wh…
Re: New React docs pretend SPAs don't exist anymore
#216Earlier quoted context omitted.
Late last year I listened to talk on nextjs and I was floored by its design. I still can’t get over that the JS community has embraced file system routing and server rendered stuff. I honestly think I’m taking crazy pills because I could have replaced “nextjs” with “PHP” in most places and it would still make sense. I have been in software for about a decade and I think I’m experiencing my first complete cycle of “wh…
Noob here. What's wrong with file system routing?
Re: New React docs pretend SPAs don't exist anymore
#217I just want to say, as a developer that just wants to get stuff done, I'm so annoyed by frameworks needing a meta framework, etc, etc. I want something as simple as CRA to be enough.
Re: New React docs pretend SPAs don't exist anymore
#218Interesting that CRA isn’t mentioned anymore. Someone opened an issue to discuss this: https://github.com/facebook/create-react-app/issues/13072
Re: New React docs pretend SPAs don't exist anymore
#219Earlier quoted context omitted.
You should really check out modern REST APIs. Again, as an example, Directus supports doing everything you just said over both REST and GraphQL. There are many others that do too, and lots of libraries out there to make it easy to add that capability to your own endpoints in Node or.net or whatever. You may also want to take a look at HATEOAS and JSON:API and similar. REST-like APIs have long had feature parity with…
Yeah just seems like a different interface than GraphQL, but it's basically the same thing as GraphQL. So at this point, is it just "we don't like GraphQL" or something? I don't see the reason to have to homebrew this for most things when GraphQL has a fairly sane standard. GraphQL is still over HTTP. You can actually even just use the concepts in the backend (and maybe Directus does??) and hide it from the user, if…
Yes.
But not without reason.
GraphQL departs from web standards and semantics in order to solve a problem that doesn't really exist in most APIs.
You incur a cost in using it, some of which I've outlined but there are many others, such as working against the browser's native caching capabilities, e-tags, etc...
This cost would be worth paying if GraphQL brought new and valuable capabilities, but as I've discussed, it doesn't really do that.
With REST endpoints, you have to really reason about entities and URL structure to design it properly. It's not easy, but it shouldn't be - it's meant to be a long-lived API contract based on document location, so you should spend time reasoning about the design.
GraphQL, in my experience (much like SOAP/WSDL) encourages lazy API development with the GetWidgetsByColorForArthurOnSunday() type functions. It requires additional libraries and tooling and a whole additional layer of complexity. It works against long-standing native browser functionality, and in many cases is just a solution in search of a problem since for most popular API consumption there's a client-side library that abstracts away details like transport.
Also, I personally dislike it because I can't use my preferred data mutation strategy, JSON-PATCH [1].
Re: New React docs pretend SPAs don't exist anymore
#220But… they don’t, really. “SPAs” are just a corruption of the web brought about by people who obsess over replacing end user operating systems with HTML+CSS+JavaScript. Most actual users would be just as happy to install a real native application.
Kind of true the doom came from IE/MS.