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

React I love you, but you're bringing me down

marmelab.com

Post reply on HN
Print view View original

481–490 of 574 posts

Re: React I love you, but you're bringing me down

#481

Post by edgyquant »

cercatrova wrote: post #477
edgyquant wrote: post #476

Earlier quoted context omitted.

How can the client most efficiently query data from a sql database without joins? Surely there are cases this would be needed to speedup grabbing of data?

Any ORM will handle getting data with joins just fine when it constructs the SQL. Or you can write your own SQL with joins to pass along to the query. If you mean GraphQL doesn't have joins, I'm not sure in what use case that would matter when you're declaratively asking the server for some data, not hand constructing SQL. What would you need joins in? You mean like this example [0]? [0] https://stackoverflow.com/que…

Right so, again, what exactly is the purpose of graphql?

It seems to be a replacement for an ORM that then needs an ORM. So it’s a replacement for passing JSON objects around except it’s just doing that with a dash of esotericism.

What can graphql do that an ORM can’t?

Re: React I love you, but you're bringing me down

#482

Post by cercatrova »

edgyquant wrote: post #481
cercatrova wrote: post #477

Earlier quoted context omitted.

Any ORM will handle getting data with joins just fine when it constructs the SQL. Or you can write your own SQL with joins to pass along to the query. If you mean GraphQL doesn't have joins, I'm not sure in what use case that would matter when you're declaratively asking the server for some data, not hand constructing SQL. What would you need joins in? You mean like this example [0]? [0] https://stackoverflow.com/que…

Right so, again, what exactly is the purpose of graphql? It seems to be a replacement for an ORM that then needs an ORM. So it’s a replacement for passing JSON objects around except it’s just doing that with a dash of esotericism. What can graphql do that an ORM can’t?

You're mixing up server side and client side. The point of GraphQL is to make a client request only what data it needs rather than making X different REST calls then combining and filtering them in the client side. That's it, that's the entire purpose. (If you then ask, why not have REST calls that give specific pieces of information, ie have sorts and filters within the query parameters, and be able to take a table and ask for specific columns in that table, then congratulations, you've reinvented GraphQL.)

You can then implement a server which, given a GraphQL query, turns it into the data that's expected. The client doesn't care how you implement that. You can write raw SQL, use an ORM, whatever. Since people don't want to reinvent the wheel they use libraries like Apollo Server, but again you can do it all by hand if you really want to.

Have you actually used GraphQL? This is all explained within the first 15 minutes of any GraphQL tutorial.

Re: React I love you, but you're bringing me down

#483

Post by cercatrova »

rob-olmos wrote: post #478
cercatrova wrote: post #474

Earlier quoted context omitted.

GraphQL is for the client to efficiently query data, it is not supposed to be used as a SQL replacement on the server side. If people are using it for a server side query language, that is not what its benefit is.

IIRC in the Gatsby framework it has a built-in GraphQL parser for server-side developers to query data from Gatsby plugins, which can be things like data stores, other APIs, or even a mixture and blended together.

In a way, that's using the server as a client for other servers, ie it would be the same as a server sending a REST request to another server asking for data. What I mean is nowhere should there be GraphQL between a server and a database, because that doesn't make any sense, just use an ORM.

Re: React I love you, but you're bringing me down

#484

Post by edgyquant »

nonethewiser wrote: post #46

I must be the only person in the world who likes class components in React. Sure, it's often overkill and a functional component does the same thing with less code. Use a functional component in these cases. But if you're doing something more complicated then stop treating class components like the fucking devil. They have their place.

I used to be the same when I switched jobs and had to start doing functional. I now disagree that there are ever instances a class is needed. You can use hooks to encapsulate and reuse state, contexts, etc

Re: React I love you, but you're bringing me down

#485

Post by sph »

narrator wrote: post #138
yamtaddle wrote: post #86

Earlier quoted context omitted.

Nope, I'm with you. React inventing a half-baked, partial re-implementation of objects/classes (in a language that already has them!) with super-weird declaration syntax & runtime behavior, just to avoid telling their userbase "Ok you will have to use classes sometimes, for certain functionality", was when I started looking around, because they were clearly out of real problems to solve that were sufficiently good-lo…

The cycle of javascript libraries: * SHOW HN: UberTinyUltra.js Here's my new super light-weight 4k Javascript Library! * How I switched to UberTinyUltra.js from PopularFramework.js and simplified my life! * SuperCoolStartup switches to UberTinyUltra.js * How I built my unicorn on UberTinyUltra.js * UberTinyUltra.js 2.0 now with a compiler, classes, typesafety and a C++ like turing complete template language to take o…

I still remember the Parcel or Prettier saga. The first, the no-configuration bundler, the other, the no-configuration opinionated code formatter.

Then, for their next big major release, the big feature was adding configuration to make it even more powerful!

I haven't used them in a while so my memory might be hazy, but this is exactly the phenomenon you've described. I wonder if it's insecurity or trying to please the crowd that simple niche tools in the frontend end up being configurability behemoths. There's always a time in a JS library where someone decides to rewrite the whole thing and add plugin support, and that's the time that library goes to shit.

Over long enough time you get Webpack, with more knobs than the Linux kernel, and cycles back to a version that tries to be smart and not require any configuration anymore, like 1.0 did.

Re: React I love you, but you're bringing me down

#486

Post by the_gipsy »

bot41 wrote: post #297
postalrat wrote: post #160

Earlier quoted context omitted.

Depends on what you mean by global state. You don't have access to a single pool of global variables. You only have access to what you put there and what you've been given.

Is it that they are global state to react but not to the programmer or his/her code?

It's that they are not shared like globals.

Re: React I love you, but you're bringing me down

#487

Post by the_gipsy »

fabian2k wrote: post #168
bluefirebrand wrote: post #84

Earlier quoted context omitted.

> To me one of the biggest issue is that almost everyone is deeply afraid of prop drilling. Prop Drilling is considered an anti-pattern for good reason. It very quickly turns your project into an absolute mess, making it impossible to determine where props are coming from and where data is actually set. Keeping that clean is one of the most important things you can do in a frontend codebase imo.

That doesn't make sense, props are easily to follow and they only flow in one direction from parent to children. Excessively deep component structures are a problem, but not only because of the excessive prop drilling they cause.

Except when props are callbacks, e.g. probably a useState combo.

Re: React I love you, but you're bringing me down

#488

Post by sph »

not_kurt_godel wrote: post #462
pdntspa wrote: post #337

Earlier quoted context omitted.

> We had an experienced-but-batshit-crazy dev create a React site with approximately 250,000 LOC to support 3 forms Holy moly. I've seen some bloat but that takes the cake.

They essentially created a unique type for every. single. variable. I'm talking like, if you needed string constant for an error message on Input 1 on Form 3, there was an ErrorLoadingMessageForInput1OnForm3 type declared for that instead of defining it as a string. The types were never reused - like if you had the same error message on Form 2, there'd be a separate ErrorLoadingMessageForInput1OnForm2 type for the sa…

That's not code written by an experienced dev like you said.

They might have worked long enough to think they're experienced, but this is proof they're just terrible if not a complete hack that's in the wrong line of business.

Re: React I love you, but you're bringing me down

#489

Post by ux-app »

ebiester wrote: post #273
throwaway0asd wrote: post #173

Earlier quoted context omitted.

I just use vanilla JS on the front-end just like I do with Node. I have never understood why people find state management challenging. I suppose its because they are stuck in a framework or MVC mindset where everything is a separate component and each must have separate state models that must be referenced frequently and independently. I just put all my state data in one object, save it on each user interaction, and…

Frameworks enable ecosystems. Ecosystems enable reusable components. The more you deviate from one of the set of common conventions, often enforced by frameworks, the more you have to build on your own. The larger your project gets, and the more developers who need to understand your code, and the more developers you need to hire and get onboarded quickly, the more that those extra rules start to make sense. And once…

I'll take Libraries over Frameworks every time.

Re: React I love you, but you're bringing me down

#490

Post by halfjoking »

cercatrova wrote: post #482
edgyquant wrote: post #481

Earlier quoted context omitted.

Right so, again, what exactly is the purpose of graphql? It seems to be a replacement for an ORM that then needs an ORM. So it’s a replacement for passing JSON objects around except it’s just doing that with a dash of esotericism. What can graphql do that an ORM can’t?

You're mixing up server side and client side. The point of GraphQL is to make a client request only what data it needs rather than making X different REST calls then combining and filtering them in the client side. That's it, that's the entire purpose. (If you then ask, why not have REST calls that give specific pieces of information, ie have sorts and filters within the query parameters, and be able to take a table…

So if front-end devs get everything they need client side, what’s the point of having backend devs?

https://imgflip.com/i/6u4obk

Post reply on HN