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

351–360 of 574 posts

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

#351

Post by whatsdoom »

yurishimo wrote: post #305
buscoquadnary wrote: post #147

Earlier quoted context omitted.

Step 1: The existing tooling is too clunky, big and a major PITA to work with, Developers spend most of their time fighting their framework and tooling to do simple things. Step 2: Someone gets fed up with this writes a framework that "does things right" and is designed for "simplicity" Step 3: People start loving the new tool because it is so much easier to work with. Step 4: People start to do things the tool wasn'…

> The Wheel of Time turns, and Ages come and pass, leaving memories that become legend. Legend fades to myth, and even myth is long forgotten when the Age that gave it birth comes again. In one Age, called the Web 2.0 Age by some, an Age yet to come, an Age long past, a wind rose above the great mountainous island of FANNG. The wind was not the beginning. There are neither beginnings nor endings to the Wheel of Time.…

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

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

#352

Post by rileyphone »

pjmlp wrote: post #131
rileyphone wrote: post #111

Earlier quoted context omitted.

I think the problem is ES6 classes just aren't very flexible or expressive, compared to systems like Ruby, Smalltalk, or CLOS. For a lot of programmers, half-assed classes are worse than no classes, even when they can help with organizing state and behavior.

They are as expressive as SELF, maybe time to learn how to use them?

Javascript's prototypes are more expressive than its classes, but still come short of Self on a few levels:

1. Self's prototypes support multiple delegation while JS objects only have one prototype (can be fixed with Proxies).

2. Javascript objects lack a universal clone method.

3. Self is entirely message based, while JS is property based.

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

#353

Post by pc86 »

rglover wrote: post #33
pc86 wrote: post #20

Earlier quoted context omitted.

Tangentially related: https://xkcd.com/927/

The number of people who have sent me this exact meme for daring to offer an alternative is quite illuminating of why it's so hard to make progress. Not picking on you, but dogmatic thinking is why OPs article even exists. Don't substitute memes for thinking. Evaluate what I've built on its actual merits.

Respectfully, I don't have the time or interest to, and to be quite honest while I am qualified to implement just about anything you want in vanilla JS, jQuery, [old versions of] Angular, React, or Vue2, I'm very likely not qualified to judge a brand new one on its merits other than just a superficial comparison to the ones I've used before.

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

#354

Post by goatlover »

nightpool wrote: post #120
goatlover wrote: post #66

Earlier quoted context omitted.

Coming from Ruby and Python, I also prefer class components to hooks. I had to deal with hooks enough in Drupal/PHP which is in the process of deprecating them in favor of Symfony classes.

Drupal hooks have nothing to do with React hooks except sharing a name. What would cause you to compare the two?

Drupal hooks are a functional approach to design compared to the OOP approach of Symfony components. As in you use functions to modify/extend existing code instead of inheritance. That's the context of the discussion, not whether they are otherwise similar to React hooks. Anyway, I just tend to think more in terms of making things with classes/objects than with functions.

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

#355

Post by daveguy »

throwaway0asd wrote: post #173
throwaway284534 wrote: post #10

As a developer who’s been working with React since the beta, I can confidently say that the author is speaking the truth. Especially so near the end of the article where they can’t seem to quit React. For all the annoyances of Hooks, they really are a godsend when it comes to composing state. And refs do indeed suck, but they sucked even more with class based components. I can’t tell you how many times I was able to…

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…

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

Then you exactly describe MVC...

> state data in one object,

This is your model.

> save it on each user interaction,

This is your controller.

> and use it only on page refresh.

This is your view.

MVC is a relatively simple concept, and it works well.

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

#356

Post by Swizec »

bobthepanda wrote: post #299
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…

Eh, to some degree you do get a starting point in uni for various things. You’ll learn basic models for systems or databases as part of core requirements. If a web course exists, it’s most likely optional and out of date. Web is certainly a different context, and some people struggle to pick it up. There’s no authoritative book like the C Programming Language, and the web is full of wrong information that sometimes c…

> Web is certainly a different context

I mean it's a thin or fat client talking to a fat or thin data source over a network. "We" have been building systems like that since the 1950's.

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

#357

Post by exclusiv »

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 devs are getting data from the API and creating new structures, transforming it, conditionals everywhere, etc.

It requires way more discipline to ensure that frontend devs aren't recreating the wheel and writing duplicate code as the app and components evolve, and it's worse for larger codebases of course.

They need to build some new component and go - ok I got the data from the API and now I need to do the thing that's already been done by another frontend dev for another component because we've allowed the frontend to be responsible for transforming the data. But if they aren't aware of this, then you get a lot of dupe code.

Just have your backend API provide the contract. Setup resources/transformers as needed on the backend instead of littering the frontend with that logic.

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

#358

Post by azemetre »

dragonwriter wrote: post #326
azemetre wrote: post #186

Earlier quoted context omitted.

Hooks are executed in order as they are defined, isn't that a fundamentally broken design in regards to language spec? I don't have an opinion, just generally curious because it feels very odd that the order of my functions matter.

> Hooks are executed in order as they are defined Hooks are functions, and they are executed in the order called from within the component, which is itself a function, just like any other functions calls from within another function. (The mechanism tracking calls to them and deciding whether the function passed to the hook needs to be called requires them to be called in the same order each time the component is exec…

Thanks for the correction and teaching me something!

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

#359

Post by kayson »

mikeryan wrote: post #263
kayson wrote: post #170

Earlier quoted context omitted.

Can you give me an example? I didn't have that experience. I extended classes for everything and it was super easy. But as I said, I was probably using react in a fairly basic way.

For example you have a button that you want to add a hover effect to. So it's got "onMouseEnter" and "onMouseLeave" handlers that sets a "hovered" state variable to true/false. If you have that functionality in a class component, and want to share it with a new link component, then the React Class way is to create a "withHover" HOC and wrap your link component in it. withHover(LinkComponent) which will have the neces…

Ah got it. I never really had any functionality like that and had few HOCs, so this makes sense. Thanks!

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

#360

Post by tiberriver256 »

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…

Link to the doc?
Post reply on HN