Just Fucking Use React

1 points by juliethefoxcoon


algernon

I hope this is satire, because I started reading it, and I'm just shaking my head, pitying the fool who might have written it as anything else than satire.

But the web isn't just a collection of fucking pamphlets anymore, you fossil. It's where work gets done, where communities are built, where complex interactions happen. You know, shit that actually does something beyond displaying your "Fucking beautiful button."

The corporate web might be, but that place is vile and reprehensible, and not something I wish my sites to belong to. I build my sites primarily for myself, as an outlet, and secondary, to like-minded folk who close the tab the moment they see one of those atrocious "complex interactions".

I like my fucking beautiful buttons, thankyouverymuch.

This is a call to embrace the tools built by smart motherfuckers to solve the hard problems so you can focus on building your cool shit, not reinventing the goddamn wheel for the 87th time this sprint, you stubborn jackass.

Considering how much of a bloated piece of shit React is, I'd question the validity of this statement, regarding "smart motherfuckers" and "not reinventing the goddamn wheel".

Because you're not just displaying static text from a fucking stone tablet, are you?

But I am displaying static text from a fucking stone tablet! And it's a very solid stone tablet! One that requires no maintenance whatsoever, that has no CVEs, no breaking changes, and doesn't require a fuckton of memory and CPU power to display a fucking checkbox with "complex interactions".

Fuck your complex interactions, by the way.

"But HTML has <details> and <dialog> and forms!" Yeah, and your toddler has crayons. Adorable, but not exactly the tools for designing a fucking skyscraper, are they?

Luckily, I'm not designing a fucking skyscraper. I'm building a cozy home, you capitalism-pilled dumbnut.

What are you gonna build with your pebble, huh? A really impressive fucking paperweight?

Yes. And my paperweight will be functional in 10 years. Whereas your "fortress" will bleed from the inane number of CVEs in the frameworks you used, and two entire teams would have quit by that time because they burned out trying to maintain that shit.

Try building a dashboard with a dozen filters, real-time updates from ten different sources, user preferences that change everything, and collaborative editing where five assholes are mashing keys at once.

Been there, done that, performed an order of magnitude better than with React, and continues to be easier to maintain. Your point?

....and this is where I stopped reading, because it gets exhausting. If this is not satire, I pity the authors.

caius

No.

reidrac

Not sure, was this one that started it? https://programming-motherfucker.com/

(btw, weird to see Zed A. Shaw with that hair)

Which was always a joke, but I guess it was fun because it was true? I don't agree with the language, but fair enough.

All that said... React? I don't know, I guess I'm not that type of person.

sporiff

The fact that this post doesn't acknowledge web components at all is troubling. A great many of the problems raised in this post are already solved by web components. You can achieve encapsulation, reliable styling, event-driven architecture, and persistence all without needing to install a single library, and I truly think this is the path forward for many projects.

It's true that much of what we want to do online cannot (or rather, should not) be achieved using only HTML. There are many use cases where some client-side JavaScript is the best option, but I'm afraid I don't buy into the idea that React is the correct solution for most of these. React is a pretty huge and very opinionated library that often does things in a way that feels somewhat anathema to the browser specification, and at the end of the day the browser has to be authoritative because it is the platform.

React is a good library for building big, complex SPAs. I don't deny this. The bigger question is whether your project should even be a big, complex SPA. For the vast majority of use cases, I don't believe it should. Blogs and marketing sites can be static, with some progressive enhancement. Many apps can be MPAs with more server-side processing and some small enhancements made by JavaScript. The idea that every site needs to be a large client-side JavaScript app is pretty wrong-headed, in my opinion.

adamshaylor

Somehow, abusive language like this shows up most in debates over whether the web is made for only for static or only dynamic content. On this site, it usually comes from the side opposite this one, but it’s distasteful and unproductive, either way.

I suspect the vitriol is a natural consequence of a false dichotomy. There’s a time and a place for JavaScript and data binding tools. Just because you need them doesn’t mean everybody else does; and just because you don’t need them doesn’t mean nobody else does, either. The principle of least power applies on the web as much as anywhere else. Frameworks that emphasize lightweight, static content first and support support server-rendered content and islands of interactivity as needed are headed in the right direction.

emk

Eh, if you have a React-shaped problem, it's not the absolute worst choice. Treating the DOM as a pure function of the state appeals to my inner Haskell programmer, you know?It's better than Ember.js's heroic attempt at managing a GUI.

But:

Now, if you really do need an actual client side UI for a corporate project that needs to be staffed and maintained, the React has decent abstractions and it's boring, which is normally what you want.