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

551–560 of 574 posts

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

#551

Post by collyw »

awinter-py wrote: post #222
collyw wrote: post #45

Does anyone do server side rendering these days? I fail to see the point in SPA apps for the majority of web apps. At my work we have an ancient Dojo frontend and a newer react one being build. Its a few list views that the user can filter and a few forms with validation. It's a ridiculous amount of complexity to avoid loading a page. I could do almost everything for half the effort with server side HTML from Django…

yeah django's approach to forms is not the worst thinking of forms as a model that can be rendered is really valuable IMO. most UXes would be 10x easier to write if we had better standardization around the 'schema to UX' step 'form first UX' would also reduce the work of building cross-platform apps guessing django is ramping up on its AJAX, but I think a real forms standard would need to understand AJAX -- users are…

Yes, we are trying to move over to FastAPI, which looks reasonable, but I struggle with the fact that there is no one source of truth for models.

Is there anywhere good to find out what I have been missing out on having not kept up to date with Djano for the last few years? I really miss using it and am looking for a job using it again.

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

#552

Post by bigDinosaur »

wiredearp wrote: post #500
bigDinosaur wrote: post #480

Earlier quoted context omitted.

Classes in JS are just functions anyway, and functions can have state. Saving the state of a function is a different thing, but of course JS allows that, too. Why is it weird?

Class instances are objects and it's the objects that have state. Functions can only abuse themselves as objects to store state. function johnson() { johnson.state = {}; } This is however shared state and the state will be reset whenever the function is called a second time. So what you normally do with a function is to pass the state via arguments and now the same function can work with different states. React could…

As far as I know, hooks use closures to store state, and that's neither abuse nor weird. Am I missing something?

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

#553

Post by fennecfoxy »

cercatrova wrote: post #400
exclusiv wrote: post #357

Earlier quoted context omitted.

> Some part of your organizations chaos is going to reflect in code, and honestly I'd rather it be in a big ball of frontend than in the data models, infrastructure, etc. I disagree. I like my frontend to be as dumb as possible. It gets data and reacts to it as simple as possible. Seen too many frontends with a lot of data logic and it becomes extremely brittle, harder to test. These are the ones where the frontend d…

That's why I like GraphQL, you get exactly the data you request, no transformation necessary.

I love GQL, but making things optional by default in the schema was the stupidest decision they could've made.

Also the issue with GQL is that FE devs love to copy+paste giant queries that just get everything because it's "convenient", or build up a query while building/testing something and then go on to use that query, including fields that don't eventually get used in the final work.

What GQL->consumer ecosystem really needs is something that can check if a field is ever actually accessed in the code or not, something TS/compilation-wise would work. That way the query can be narrowed down to what's actually used in code.

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

#554

Post by JLuterek »

exclusiv wrote: post #442
edgyquant wrote: post #423

Earlier quoted context omitted.

Graphql fans will attempt to convince you the way you’re querying data is wrong. You can do triggers if needed but graphql to me seems like a solution to internal enterprise data wrangling ootb. I don’t see the benefit of using it over an orm when you add in multiple databases, a working data store, etc

Yeah I'm not entirely sold on GraphQL but I think it shines in some cases. Ex: you are building on top of third party ecommerce software. You need to add more data to the Cart entity because you have a custom module/plugin/etc. You write a graphql resolver, extend the schema and the Cart type. You can use the existing built-in endpoint to query your new data. So it's nice to be able to extend a framework and data acc…

GraphQL was designed to solve a singular problem, slow mobile internet speeds. Now that mobile internet (5G) is faster then some wired home connections I'm worried that GraphQL will die off. It's a solution that no longer has a problem. Though it is a cool tech.

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

#555

Post by collyw »

reducesuffering wrote: post #101
collyw wrote: post #45

Does anyone do server side rendering these days? I fail to see the point in SPA apps for the majority of web apps. At my work we have an ancient Dojo frontend and a newer react one being build. Its a few list views that the user can filter and a few forms with validation. It's a ridiculous amount of complexity to avoid loading a page. I could do almost everything for half the effort with server side HTML from Django…

> Does anyone do server side rendering these days? Yes, in React, with Next.js. I'm going to have to dynamically create html and attach event handlers based on data either way. Much rather do it all in Typescript than remember Django templates DSL and still do javascript, for the result of worse UI's, poor 3p library support, and awful state management between frontend and backend.

Django temples are pretty simple. They are basically HTML with a a few constructs that you can put variables or loops in. Way simpler than React and Typescript.

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

#557

Post by gwn7 »

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.

You are not alone.

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

#558

Post by whatsdoom »

yurishimo wrote: post #391
whatsdoom wrote: post #351

Earlier quoted context omitted.

In case you don't know. This is a variation of the first paragraph of the Wheel of Time book series by Robert Jordan. Each book opens with a variation of this same paragraph

I’m well aware of the origins of the quote :)

Just wanted to make sure, it wasn't clear to me if you just liked their modifications or you weren't familiar with the quote at all :)

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

#559

Post by dtagames »

rk06 wrote: post #456
dtagames wrote: post #114

Earlier quoted context omitted.

Yes and I'm surprised no one has mentioned Lit or bare metal web components in this convo. I'm starting a large TS project at the AAA game studio where I work (my day job, not DTA) and it wasn't hard to choose to avoid React or Vue or Angular. Lit is the anti-framework because it isn't a framework. Once you remove all the cruft, you can spend a lot more time writing the code that you want to write and, doing so in th…

Because lit is too bare metal to qualify as a js framework. Does it have good solutions for router or state management? Last time i checked: No. That is why it is not discussed that much. If you need to write components, then lit may work for you, but whoever wants to ise those components would prefer a js framework. Also, lit is from Google. which makes it worse as Angular is from Google as well

Lit is just syntactic sugar for bare metal stuff that is W3C standards based. There isn't any vendor lock-in and won't be "upgrading" your Lit because they told you to.

You are right on components for other people -- but if all the components are for you or your company, ones you handcraft w/ Lit will be lighter weight and easier to write and fix.

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

#560

Post by awinter-py »

collyw wrote: post #551
awinter-py wrote: post #222

Earlier quoted context omitted.

yeah django's approach to forms is not the worst thinking of forms as a model that can be rendered is really valuable IMO. most UXes would be 10x easier to write if we had better standardization around the 'schema to UX' step 'form first UX' would also reduce the work of building cross-platform apps guessing django is ramping up on its AJAX, but I think a real forms standard would need to understand AJAX -- users are…

Yes, we are trying to move over to FastAPI, which looks reasonable, but I struggle with the fact that there is no one source of truth for models. Is there anywhere good to find out what I have been missing out on having not kept up to date with Djano for the last few years? I really miss using it and am looking for a job using it again.

I'm on fastapi with my current project -- I love the powerful type support for interfaces.

I'm using tortoise as my ORM; it feels like sqlmodels is worth exploring as an alternative -- sqlmodels is designed to integrate well with pydantic (so you DRY in messages) and with sqlalchemy (so you get their migration support).

I'm not sure if there's a fastapi / pydantic tool for generating form UX, but it might be doable to write one if not. (though styling could be tricky).

I notice myself still spending a lot of time writing basic CRUD routes. I don't know if this is a tools issue or just unavoidable.

I'm open to a tool like postgraphile to automate API on top of a DB schema, but I'm worried about the loss of control over messages, RBAC, and query design. I wish there were a python tool for mostly-declarative API route stubs -- would be simple to customize, and the purely-declarative routes could be shipped off to a postgraphile-like tool in the future.

I wish fastapi had better auth built in, but then again I wish this about django too -- I feel like I'm endlessly shopping for a third-party user auth server and haven't found it yet. Auth + admin were a huge investment at the beginning of my project, and in retrospect feels wasted.

Post reply on HN