What Is React: A Visual Introduction for Beginners

That doesn't make them wrong when they say "hey this super simple site doesn't need to be in react" but at the same time it also misses the use case(s) for react and other frameworks when they rant on the topic more generally.

If all you need is a static site landing page that changes once a year, sure use something else, plain ol html, css, and JS will do wonders. But when you want to build an entire application and experienece for consumers, React is exceptional.

Web applications always have state and side effects, there's no escaping it. If you squint and tilt your head, ReactJS is like a pure function given the environment. React lets you model your view around your state and takes statefulness as a given and doesn't try to obfuscate it away.

As you say, its far easier to leverage FP ideas in a react application. Most react components can be pure. State can be modeled with all the fun FP tools and ideas. At the end of the day, React clearly delineates the stateful from the stateless and lets you easily model both relative to each other in a ergonomic manner.

I think it’s a bit different - they are so popular mostly because of the massive crowds of front end devs cargo culting static websites into SPAs.

And then maybe because of the many cases where they’re applied to replace jquery or a few js sprinkles with unnecessarily complicated SPAs. This is where stimulusjs + turbo or similar could solve the problem with 10% of the effort and complexity.

Then, maybe in third place or further, because there are more cases for SPAs than 10 or so years ago.

I've got plenty of React & front-end experience and vastly prefer a thin library on top of the DOM than something like React, also for large applications. React is ok if all goes well, but when you have to debug or profile something, all the complexity behind the scenes occludes what you are looking for. Most of the time, people want JSX so you need a transpiler. Also keeping up with changes in new React releases seems like a lot of lost time.

I've been building [1] without a transpiler and just a 600 lines template library (see [2]), and it has been such a breath of fresh air. The fact that there is so little code between you and the browser makes it very easy to see what is going on. Call stacks of max around 15 frames.

It sounds like you are comparing React to jquery code without components, and I justed wanted to highlight that DOM APIs have evolved since those days, and that you don't need a library like React to structure your code.

React has popularized good ideas in front-end development, like components, but I think the complexity cost of a virtual DOM is often underestimated.

1: https://github.com/vector-im/hydrogen-web/ 2: https://github.com/vector-im/hydrogen-web/blob/master/src/pl...

The fact remains client side JS frameworks did not grow organically from the open source community. They had to be pushed into the dev mindspace by the mega-caps tech cos to offload processing power to the client. For the vast majority of companies (all but a handful), front end frameworks hold an org back.

I’ve had this unpopular opinion for several years, and have yet to meet/work with a startup who didn’t regret choosing Angular/React/etc.

From my point of view, React and JavaScript improvements in later versions have made frontend development more tolerable and even interesting.

I love HN, but I would really be wary of taking too much front end type commentary seriously as it comes from HN comments.

Now sometimes the comments are GREAT, that's not to say it is all bad, but other times the comments on front end topics on HN is like walking into a meeting with a bunch of managers and non front end focused folks who got together to list their gripes ;) In those cases I often don't say anything because the ranting is on and nobody really cares.

Edit: This was longer but I decided I didn't want to go that far down the meta rabbit hole.

I think most people are happy or content with React - but honestly, it doesn't matter. Nearly every job listing I've seen or applied to asked for React experience (if the position asked for frontend skills). It's so ubiquitous in the coastal US tech industry that if you want to be a frontend dev, you're limiting your career choices by refusing to learn it.

At first it seemed a bit complicated, but looking back at the stack I left behind in 2015 (LAMP, numerous JS libraries, Bootstrap, some Ruby was starting to creep in), it actually is a little more consolidated.

I guess I should bookmark my comment and check back in a year from now in case I am still using React and see how my thoughts change by then!

So, you should consider that there is some benefit which outweighs the complains

UPDATE: original line came out wrong. and was flat out incorrect

Also, it makes webpages a pain to scrape, consumes more RAM and CPU, and recursive module dependencies can become a huge attack surface.

Install Node, run `npx create-react-app my-site` and you're all configured.

Sorry if this doesnt make sense. I am mostly backend/servers.

Or you could just shift your backend expectations and adapt to the different needs. If you're doing an SPA because you want an app-like experience and very decisively not a website-like experience, your backend should be as simple and stupid as possible and not force you into a model like MVC; you shift much of the complexity to the frontend when you go from website to SPA. You know, like it would if you're writing a desktop app or a mobile app that uses an API. Because it's an application, not a website.

You could pull the 99.999% number out of wherever, but the truth is that many things we used to do as websites are better off as apps. My bank's website is better off as an app, the social networks I use work better as apps. Hacker news doesn't. Blogs don't. Online newspapers don't. It all depends on the amount of interactiveness needed and how much better the experience is with access to real-time information streaming and quick UI responses based on things other than data loads.

And as dreadful as Javascript dependency hell is, it's objectively better than Python dependency hell since it's had a passable package manager for much longer than Python (and even then, most Python devs still don't use or even know of Poetry) so the ecosystem is better aligned to modern software development expectations. You're just used to one variation of hell, and don't want to learn a new one.

Try to understand modern frontend needs before assuming newer frameworks are shit at everything and that everything related to it sucks. They might be shit at the specific thing you're doing, and some lessons seem to have been forgotten when things were redesigned.

What hasn't changed however, is how most software development sucks, and the fashionable things that were done under terrible standards (devs and/or management) have changed, but are still done by the same terrible standards so you still have shit results.

> VueJS is the only framework that allows you to progressively enhance something like a Flask based website in the most natural jQuery-like way.

No. You're just allergic to build tools because you have not enough knowledge of them. Probably because, from what I've been led to believe from your comment, most of your experience seems to be with Python. All your described problems ultimately stem from there.

You can, but you probably shouldn’t (outside of prototyping). It requires you to both ship the template compiler to the client, and to perform the template compilation on the client, on every single page load (vs serving a cached, pre-compiled JS file).

If you want to sprinkle JS onto an otherwise server rendered page, you’re better off with something like Alpine.js [1]

[1] https://github.com/alpinejs/alpine