Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New React docs pretend SPAs don't exist anymore

wasp-lang.dev

Post reply on HN
Print view View original

131–140 of 225 posts

Re: New React docs pretend SPAs don't exist anymore

#131

Post by roflyear »

dmix wrote: post #39
BiteCode_dev wrote: post #35

So after graphql, micro services, nosql and serverless, the SPA + "libs not framework" crowd join the "woooops!" club. Ignoring the noise is really becoming a key skill to survive as a programmer.

SPAs, microservices, nosql (Redis), and serverless are all still alive and well, they just aren’t a hammer for all problems like (some) people treated them originally. Nerds getting overexcited about new tech is an old story and it will continue to happen indefinitely as much as we like to smug post about it. IDK about GraphQL since I’ve not used it but I’ve read lots of stuff recently about frameworks/ORMs working t…

Graphql is only awful once you introduce abstractions. By itself it's really a great idea and works well.

Re: New React docs pretend SPAs don't exist anymore

#132

Post by roflyear »

eurasiantiger wrote: post #94
BiteCode_dev wrote: post #35

So after graphql, micro services, nosql and serverless, the SPA + "libs not framework" crowd join the "woooops!" club. Ignoring the noise is really becoming a key skill to survive as a programmer.

What are you on about? GraphQL is absolutely essential in enterprise systems.

In my experience it's the poorly implemented abstractions on top of your ORM of choice that make graphql a bad time. It itself is really a great way to do things imo

Re: New React docs pretend SPAs don't exist anymore

#133

Post by mythrwy »

danlugo92 wrote: post #122
nvln wrote: post #96

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…

I develop in react and follow KISS and I don't have any problems whatsoever. Some libraries can be a pain in React Native however, but React web has been smooth sailling for me (following KISS and MVVC).

Ya but for many cases there is a simpler way with less moving pieces.

React just isn't KISS by nature, or maybe it is KISS for a certain style of problems but not others.

It takes too long and has too many steps to do simple things. If all you are doing is simple things using React isn't KISS.

Here's a tinfoil hat crazy conspiracy theory: Facebook released React and promoted it's uptake to slow down any possible competition's development cycle. (I don't _actually_ believe this of course, but sometimes I do kind wonder).

Re: New React docs pretend SPAs don't exist anymore

#134

Post by exabrial »

We’ve switched to JSF with Primefaces and a lighter weight BootStrap component toolkit for internal apps.

Server Side Component Frameworks are probably peak developer productivity, at the small cost that they are not infinitely flexible.

Seems like a worthwhile tradeoff when building internal apps or database driven apps.

Re: New React docs pretend SPAs don't exist anymore

#135

Post by robertoandred »

duncan-donuts wrote: post #97
nvln wrote: post #96

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…

Php doesn’t equal file system routing. Look at Wordpress.

Re: New React docs pretend SPAs don't exist anymore

#136

Post by robertoandred »

BiteCode_dev wrote: post #35

So after graphql, micro services, nosql and serverless, the SPA + "libs not framework" crowd join the "woooops!" club. Ignoring the noise is really becoming a key skill to survive as a programmer.

I don’t think you understand what any of those terms mean.

Re: New React docs pretend SPAs don't exist anymore

#137

Post by robertoandred »

d_runs_far wrote: post #107

Here's my realm: We have a react based "framework" that in the end is zipped up and delivered as a SCORM package to be embedded in a Learning Management System. We use React Router to manage navigation. After a quick scan of the Next docs, all references to routing seem to tie back to server side which is a non starter, as the SCORM is standalone HTML/CSS/JS/Media - that we happen to embellish at run time with some a…

Next doesn’t need a server, you can export to a fully static package. The dynamic server-side features obviously won’t apply, but it otherwise works great.

Re: New React docs pretend SPAs don't exist anymore

#138

Post by Rauchg »

chambers wrote: post #127
synergy20 wrote: post #124

Earlier quoted context omitted.

Vercel's next.js and sveltekit are both SSR first because that's its business needs, which has nothing to do with mine(CSR only case), and Vercel is actively pushing the SSR-can-do-it-all in the open source space, I feel it is very much short-sighted. Just use vuejs which is the only one truly never forces SSR on you if you do not want to have anything to do with it.

Speaking as an engineering manager, vercel’s approach seems to cater to the last market where overengineering and complexity were status symbols that middle management was happy to pay for. When the headcount was free, there weren’t many questions from upper management why basic UIs required so much heavy lifting by (overly) experienced engineers. In the new market, there will be much more scrutiny on costs and the c…

Interestingly, I have the exact opposite bet: “SPAs were a zero interest rate phenomenon”. Putting the burden of compute on clients, and shipping slower apps for the sake of DX and convenience. Customer-first wins.

Looking forward to see how this plays out.

Re: New React docs pretend SPAs don't exist anymore

#139

Post by eurasiantiger »

roflyear wrote: post #132
eurasiantiger wrote: post #94

Earlier quoted context omitted.

What are you on about? GraphQL is absolutely essential in enterprise systems.

In my experience it's the poorly implemented abstractions on top of your ORM of choice that make graphql a bad time. It itself is really a great way to do things imo

Yes, exactly. The typical issue is devs not grokking the mental model of GraphQL and instead just creating more and more extra queries, essentially resolving data piece by piece in the frontend instead of leveraging GraphQL types and adding types, fields and field resolvers as needed so that the frontend can do one query to get all the data it needs.

No wonder it feels like a clunky extra glue layer if it’s being used as one.

Post reply on HN