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

421–430 of 574 posts

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

#421

Post by forgetfreeman »

kristopolous wrote: post #232
bobthepanda wrote: post #211

Earlier quoted context omitted.

People can write bad things in every language. "It takes a lot of skill to write Java in any language." is a pithy quote for a reason. The issue is usually frontend pedagogy or the lack of it. Maybe things have changed but when I graduated undergrad CS in 2017 the extent of frontend being taught in my school by professors was "hand write some HTML, maybe some PHP if you're lucky". I've never met anyone who learned fr…

woah woah hold on there young one This isn't that. My hostile working definition of a framework is something that . breaks core assumptions about a language or system . limits what a user is permitted to do . increases complexities by adding new abstractions . has non-specific specifications by using unclear and imprecise language At the end you are hardly writing software. Instead you're deep into a world of new abs…

This is easily the most accurate description of what a frameworks are and the consequences of their adoption I have come across in my 25 years of experience in industry. A not so minor quibble: I think most end users of frameworks approach framework selection with good intentions, likely from a position of naivete, rather than from some sociopathic desire to build a bunker for themselves in their workplace. This of course doesn't change the outcomes.

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

#422

Post by [deleted] »

exclusiv wrote: post #357
corytheboyd wrote: post #190

I've worked in a few roughly-the-same-size (~50 engineers) web development shops. It's always the same. Doesn't matter if it's React, Angular, Class based components, Functional components with hooks, Just Some HTML, PHP, Rails views, etc. The frontend just collects the cruft of a product organization changing course very frequently. There are always a dozen half-finished fix-the-world ideas conflicting with each oth…

> 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…

[deleted]

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

#423

Post by edgyquant »

exclusiv wrote: post #411
cercatrova wrote: post #400

Earlier quoted context omitted.

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

True and I like GraphQL but in many cases your UI needs data in a way that isn't available on your existing endpoints. Ex: summary data / aggregations for reports or analytics. Or simple things like fullName on a user entity, a displayAddress, a display greeting based on their user group, you get the idea. You can do all of this on the frontend but it just becomes messier. This is what I'm referring to. So you still…

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

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

#424

Post by edgyquant »

jrochkind1 wrote: post #258
erikpukinskis wrote: post #243

Earlier quoted context omitted.

If we’re talking about class-based components then I agree with you. React doesn’t do much… maybe some performance benefits, and maybe you can avoid some complex DOM manipulation here and there, but with the extra abstraction required that all might be a wash. But with functional components I think React gives you something substantially more debuggable than an object instance with random method calls that manipulate…

I'm not sure if I'm following, are you saying that class-based components (whether React or not) could be characterized as "an object instance with random method calls that manipulate the DOM", and thus React functional components offer an advantage to them?

Iirc correctly the hooks in functional react are classes under the hood (maybe I’m wrong and it’s functions, been awhile.) The advantage functional react has over class based is reusability. You could reuse classes before and functions within them but it gets harry keeping a clean architecture.

With functional components you can write hooks that allow you to reuse all state logic between components.

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

#425

Post by forgetfreeman »

ipaddr wrote: post #216
frosted-flakes wrote: post #175

Earlier quoted context omitted.

React doesn't change frequently though, that's the point. And it has always had excellent backwards compatibility. Class components are still fully supported, for example.

React changes best practices every few years prompting many rewrites.

One has to question the sanity of a rewrite launched for the sake of notional orthodoxy. If it ain't broke...

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

#426

Post by cercatrova »

edgyquant wrote: post #420
cercatrova wrote: post #400

Earlier quoted context omitted.

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

This is why I dislike graphql especially with react. It’s gets set up as a half assed ORM (but without joins!) and then all but the most senior of engineers end up using it as your application state which slows the whole app to crawl forcing a big rewrite. Using an orm and building a proper data model in your code using a store like redis takes very little additional time (especially with sequelize!) and it has the b…

Not sure I understand because I use GraphQL with an ORM, Prisma with Postgres and Pothos which converts the Prisma schema into GraphQL types. It even has the ability to use Redis as a store. So we get all the features of an ORM and also typesafe queries.

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

#427

Post by edgyquant »

valand wrote: post #300
Swizec wrote: post #285

Earlier quoted context omitted.

> Maybe things have changed but when I graduated undergrad CS in 2017 the extent of frontend being taught in my school by professors was "hand write some HTML, maybe some PHP if you're lucky" Here's a secret nobody told you: You don't need to learn frontend specifics. All the same lessons from business software engineering apply. I not-graduated comp sci in 2012 and have been building webapps since before jQuery was…

Preach! Data modelling and managing complexity (or I prefer to say knowledge organization) is a prerequisites for every software program ever. I'd add one more: System design. Basically dealing with many asynchronous moving parts, managing entities' lifetime, separating and categorizing domain/data, and understanding what-is-important-to-whom. It is a knowledge that's applicable whether you are programming a kernel s…

Yep and nowhere seems to teach this in practice other than job sites. I’m building a team right now with two mid level engineers and a junior. They’re great and I couldn’t ask for better guys to be clear; but your point stands.

They don’t understand this (subsystems architecture and the the living data model.) It’s like they think I have a giant list of existing solutions to every problem that they haven’t memorized yet so when hit with a problem needing a subsystem they were basically useless until I slowly started teaching it to them. I’m talking Ivy League kids with degrees I only ever dreamed of getting. There brains just aren’t trained to architect systems the way I expected junior/mid level engineers to be as a self taught engineer.

Also the data model stuff has been a real painpoint for me. We were set up with graphql and Postgres so of course the MVP forwent any working data store other than react states.

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

#428

Post by vore »

chrisco255 wrote: post #311
vore wrote: post #94

Earlier quoted context omitted.

Why not? Having to manually manage the dependency array is tedious: in fact, not specifying a required dependency is a logic error anyway, so having the compiler do it is basically preferred in all cases.

Because the dependencies for hooks have to do with re-rendering the component or recomputing the value, not with the usage of the dependencies themselves. That cannot be inferred by the framework without taking a one-size-fits-all approach that probably fits no one particularly well.

Huh? react-hooks/exhaustive-deps does exactly that: it statically infers dependencies and is very noisy if you forget one, and the React team recommends that you always have it on. In fact, the React docs have this to say, right in the documentation for useEffect (https://reactjs.org/docs/hooks-reference.html#conditionally-...):

    The array of dependencies is not passed as arguments to the effect function. Conceptually, though, that’s what they represent: every value referenced inside the effect function should also appear in the dependencies array. In the future, a sufficiently advanced compiler could create this array automatically.

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

#429

Post by tomphoolery »

dpweb wrote: post #239
corytheboyd wrote: post #190

I've worked in a few roughly-the-same-size (~50 engineers) web development shops. It's always the same. Doesn't matter if it's React, Angular, Class based components, Functional components with hooks, Just Some HTML, PHP, Rails views, etc. The frontend just collects the cruft of a product organization changing course very frequently. There are always a dozen half-finished fix-the-world ideas conflicting with each oth…

I'm trying to select a good framework and coming from long before react, having a tough time finding why shouldn't use just custom elements with no framework. Which is already built in. customElements.define('my-element', class MyElement extends HTMLElement { ... }) I can manage state within the component, app state in window.state. Coding up a simple reactivity is really pretty straight forward. Now, for this featur…

Last time I used them, web components were incredibly slow. They were so slow to render, after using maybe 2 or 3 of them I realized why nobody is trying to build apps this way. Just isn't there yet. Probably won't be until HTML Imports are merged with JS Imports.
Post reply on HN