Comment by Secretmapper | Hacker News Reader

Comment by Secretmapper | Hacker News Reader

Parent Full thread

> Have front end frameworks destroyed the web?

No.

> Basic proper usage of <h1>, <h2>, and <article> tags are nowhere to be found

If you think semantic HTML is somehow more common back in 'ye old days' when frontend frameworks didn't exist, I have a bridge to sell you.

> You have to teach React developers the difference between the <Link> and <a> tag, and how <a> doesn't swap nor replace your page content, it loads an entirely new page.

I suppose this is true, as poor engineers would not understand the difference in abstraction. Is it any different than someone accepting unescaped input in their SQL? Yes, the latter is a lot more destructive.

For such a scathing indictment (destroyed the web) I'd have expected there to be more meat on the article, but the two points above (and SEO/og tags) are the only thing it actually talks about.

It's a silly 'lets put down frontend development, because I want to sell you my WP agency services' post. Frontend is a clown-fiesta you could have at least actually gave it more of a put down, but the criticisms are so transparently thin its somehow less meaty than the site's nonexistent portfolio.

I haven't used React so I had to look this up to realize he's talking about how it repurposes the <link> tag, but I've written HTML since the HTML4 days and "<a> doesn't swap nor replace your page content, it loads an entirely new page" doesn't even sound right to me.

<a href="#something"> always scrolled the page to a different part of the contents, <a href="javascript:something"> always ran javascript without loading an entirely new page, and <a href="something.html" onclick="something"> runs some javascript and won't load a new page if something returns false. That last one even seems purpose built to let you load in content ajax style with a fallback to a standard page load if the user's browser doesn't support it.

It doesn't actually repurpose the <link> tag. In React, all componentes start with upper-case to avoid collision with standard HTML. So the link tag is <Link>. If you typed <link> you would get regular HTML <link>, which thinking about it now, probably confuses a lot of people who know React but not HTML.

You're right, and the thing is React/FE Frameworks doesn't even repurpose the <link> tag. It doesn't replace or edit any native tags.

There are some _libraries_ that _create_ a <Link> tag, which is basically a 'wrapper' that adds its own set of logic, but it's a new tag.

I agree with your larger point about the level of hyperbole here but I do think React boot camps and dreadnaught-weight frameworks has produced a much greater population of web developers who don’t have a basic understanding of core web features like forms, events, etc. than I’ve seen at any point since the 90s.

The downside of being able to share code on the server is also that I’ve seen more developers prone to misunderstanding security boundaries than I’ve seen since the early PHP era.

I mean it's a stake in the ground for a conversation.

React is bad at "static" content. What happens when large portions of your site are cachable and a small but important part is highly dynamic (SPA like). Building that monster in react is a pain in the ass. You end up running a node server, and all the fun that comes with that, just to give a consistent developer experience to your js/front end/ full stack team.

If you go back 10 years the HN community would happily shit all over PHP for its sins. Yet node/react seem to get a pass. I dont see any one screaming about the fact that JSX is the same as PHP mixed in HTML. (and im going to get down voted for that).

React isnt bad, but the web is not a SPA, a lot of it doesn't need to be a SPA. Articles like this are pushing the js community to a reflection point. One in which it can embrace the lessons of the past that it missed and move forward in a better way. NO, isnt the answer... better tools and tooling is.

> React is bad at "static" content

Of course, it's a view library meant for dynamic content, that's the whole point of React. That then people who learned React and try to build other things with it, isn't the fault of React.

If it is such a pain in the ass, why not use an alternative that is less pain in the ass? No one is forced to use React, and if you have a bunch of developers that use React/JSX just because, maybe it's time to have a sit down and talk about alternatives.

> I dont see any one screaming about the fact that JSX is the same as PHP mixed in HTML

Because it's arguably not the same. JSX is syntatic sugar for "functions as views" using built-in JS types. Creating an element is `React.createElement('h1', {}, 'foobar')`, so it's actual JS.

What people did (including myself) back in the day of PHP development was having templates as individual files on disk, parse them as strings and then try to "make them come alive", that paradigm is very different from templates-with-JS.

If anything, what we did with PHP before is much more similar to what VueJS is doing today, with actual "templates", than code-as-views that React/JSX offers.

> but the web is not a SPA, a lot of it doesn't need to be a SPA

Agree, developers tend to learn something and then try to shoehorn it into everything, even when they actually needed a screwdriver instead of a hammer. I'm probably guilty of the same sometimes too, but mostly just for fun and giggles.

But you're right that many of the things we see today as SPAs, don't really have to be SPAs at all in the first place.

> That then people who learned React and try to build other things with it, isn't the fault of React.

The discussions always get muddy here. React, the view library, can't directly be blamed for how people use it, its just a collection of code.

The react codebase does include quite a few features that support using it for more than just basic view rendering of dynamic content though. Hooks support async logic that really doesn't belong in the view layer, context providers get muddy quickly as they can pass around more than serializable state, and with server components react is arguably not even a view library at all.

The problem is ultimately how devs chose to use, and how to promote the use of, react. Given that the codebase also supports those use cases today though, its reasonable to me that people often peg blame on react itself.

>>> If it is such a pain in the ass, why not use an alternative that is less pain in the ass...

If I were building a mostly static site, I can reach for htmx, if I am building a spa (b2b back end) I can grab react.

What happens when you're building something that does BOTH. The tooling isnt really there to support this. You end up with something that isnt good at either and 4 times harder to work with... It feels like we have gone backwards at that point.

> If I were building a mostly static site, I can reach for htmx, if I am building a spa (b2b back end) I can grab react.

https://htmx.org/attributes/hx-boost/

I like clown-fiesta. That's accurate. I've been a clown.

It's about plastering layers of shit on top of something which was never designed to do the job it is doing by people who have no idea what they are doing and selling this as an ideology while sticking your fingers in your ears and hiding from the numerous security problems and smoke coming out.

Personally I avoid the hell out of web applications of any sort these days. HN is the limit of my tolerance. I will go out of my way to find something that is an actual desktop application so I have my data local, my experience local and I don't have to teeter my entire existence on the top of this stack. Please just leave the web for content delivery and put together some apps that aren't shit in native UI frameworks please please please.

Reply on news.ycombinator.com