Have front end frameworks destroyed the web?(gdnetwork.co)
gdnetwork.co
Have front end frameworks destroyed the web?
https://www.gdnetwork.co/blog/have-frontend-frameworks-destroyed-the-web
39 comments
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. 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.
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.
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.
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/
https://htmx.org/attributes/hx-boost/
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.
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 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" 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.
<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" 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.
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 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.
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.
No they haven't but they have destroyed usability, my laptop battery and left a lot of brain damaged people who are incapable of seeing when a simple solution for a problem will do.
Case in point, a number of years ago I built a static web page for delivering software distribution for an SME. This is hosted in S3 on cloudfront. It is one HTML page, one image and one CSS file. There is a bit of plain DOM javascript which pulls the software versions out of metadata files on the CDN and updates a SPAN in the page. Someone came along and couldn't work it out so rewrote the whole fucking thing with AngularJS. It looks the same. There was no benefit to doing this. It was just that's how we do things. The first page hit is 220k. I don't even know how they managed to do that.
Case in point, a number of years ago I built a static web page for delivering software distribution for an SME. This is hosted in S3 on cloudfront. It is one HTML page, one image and one CSS file. There is a bit of plain DOM javascript which pulls the software versions out of metadata files on the CDN and updates a SPAN in the page. Someone came along and couldn't work it out so rewrote the whole fucking thing with AngularJS. It looks the same. There was no benefit to doing this. It was just that's how we do things. The first page hit is 220k. I don't even know how they managed to do that.
> a lot a lot of brain damaged people
It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.
It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.
I've heard this a lot over the years but I disagree entirely. It's a matter of self motivation. I started on BASIC in 1981. They taught us Pascal at university. I moved to C on Unix and eventually into embedded C. Then back out to C++ and then more recently Go.
What I tend to see from the FE developers I've worked with is someone told them this was a gold mine and they did a code camp to get where they did. There is no care, consideration or self motivation past getting paid thus the understanding is limited only to the direct thing that needs to be done via whatever means it can be done quickly.
If it's a means to an end, then you do not learn. You have to enjoy and care for what you do and cultivate it.
What I tend to see from the FE developers I've worked with is someone told them this was a gold mine and they did a code camp to get where they did. There is no care, consideration or self motivation past getting paid thus the understanding is limited only to the direct thing that needs to be done via whatever means it can be done quickly.
If it's a means to an end, then you do not learn. You have to enjoy and care for what you do and cultivate it.
I've heard this a lot over the years but I disagree entirely.
It's a quote from a semi-humorous essay by Dijkstra from 1975. The essay is basically Dijkstra making fun of all the popular programming languages and technologies of the time and pointing out how they all suck.
It's a quote from a semi-humorous essay by Dijkstra from 1975. The essay is basically Dijkstra making fun of all the popular programming languages and technologies of the time and pointing out how they all suck.
Disagree.
I started with Commodore 64 basic, then progressed to PASCAL, 'C', C++, this and that ... finally landing on the "Python" tile on that particular board game.
I won't say I'm a virtuoso, or aLawful Good Paladin Programmer weilding patterns or clean code, or whatever, but by and large BASIC's influence on my tinkering is down to the ways I don't do things.
It's a harmful perception.
As the great Yoda says, "you must unlearn what you have learned", but that doesn't mean that you are "mentally mutilated" by something. It's only if you stop learning and growing, that's where there real harm is.
I started with Commodore 64 basic, then progressed to PASCAL, 'C', C++, this and that ... finally landing on the "Python" tile on that particular board game.
I won't say I'm a virtuoso, or aLawful Good Paladin Programmer weilding patterns or clean code, or whatever, but by and large BASIC's influence on my tinkering is down to the ways I don't do things.
It's a harmful perception.
As the great Yoda says, "you must unlearn what you have learned", but that doesn't mean that you are "mentally mutilated" by something. It's only if you stop learning and growing, that's where there real harm is.
So many flaws with this article, hard to know where to start. So many unsubstantiated arguments.
It jumps from React devs not knowing meta tags and links, to oddly hyping WordPress and trying to sideline actual solutions like Next and SvelteKit.
The article could have explored concepts like server-side rendering, addressing SEO and performance issues inherent to client-side rendering.
It jumps from React devs not knowing meta tags and links, to oddly hyping WordPress and trying to sideline actual solutions like Next and SvelteKit.
The article could have explored concepts like server-side rendering, addressing SEO and performance issues inherent to client-side rendering.
I've been working with WordPress recently and I found this article amusing, given that Wordpress's next Gen editor (Gutenberg) uses React. In order to implement the design I was given, I needed to create some custom blocks, which need to be created using React.
That is true, but React in WordPress functions more like an enhancer than the whole thing. But I am part of the group of people who think bringing React in is likely the wrong call.
No, I guess. It's a bit of a ramble, but the article seems to put the blame rather at devs who don't understand the environment in which they operate. And even then the consequences seem rather insignificant.
A toxic article full of untruths and generalisations.
> 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.
This is more of a complaint about JavaScript than "frameworks". Any default browser behaviour can be prevented, so when you click an `<a>` and it does the same thing as a `<button>`, a lot of devs will think "I'm done here". They need to be educated on accessibility and why it matters.
Sometimes the economics of a project make spending the time to make your advertising microsite that'll be live for 3 months not really worth making WGAC 3.0 compliant, sorry, welcome to the real world.
> But, and it's a tough pill to swallow for many… WordPress. It gets you from 0 to 97% in an instant, and the last remaining 3% is offered by some plugin, or a minimum amount of code knowledge.
facepalm
> 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.
This is more of a complaint about JavaScript than "frameworks". Any default browser behaviour can be prevented, so when you click an `<a>` and it does the same thing as a `<button>`, a lot of devs will think "I'm done here". They need to be educated on accessibility and why it matters.
Sometimes the economics of a project make spending the time to make your advertising microsite that'll be live for 3 months not really worth making WGAC 3.0 compliant, sorry, welcome to the real world.
> But, and it's a tough pill to swallow for many… WordPress. It gets you from 0 to 97% in an instant, and the last remaining 3% is offered by some plugin, or a minimum amount of code knowledge.
facepalm
>"Learning something lower-level than X = knowledge on X, except Twitter."
cute joke.
cute joke.
No
>Basic proper usage of <h1>, <h2>, and <article> tags are nowhere to be found, making screen reader's job difficult (in fairness, however, accessibility has always been complicated).
I've asked here before about HTML5 semantic tags[1], and the consensus seems to be they're worthless. H tags may be useful, but HTML5 sectioning algorithm allow for multiple H1's for example seems to be generally seen as an error. There are so many valid users for <article> that it can't be used to find the actual article on the page. And the best use case of <section>, in my opinion, is a section without a heading, the exact sort of thing that nobody wants to allow and will tell you to just a div instead despite the fact divs don't have a label tag for them different from <figure> (also used wrong all the time) and <table>.
>It gets you from 0 to 97% in an instant
Exactly. Front end frameworks can't have ruined the web, because without them, there is no web.
If Wordpress runs over half the web and we get rid of it because it's shitty and buggy, we're getting rid of half the web.
The alternative to no <a> isn't <a>, it's nothing. Websites that aren't accessible to everyone are still accessible to some people at least.
>using ENV variables instead of putting them in a file
Thanks for reminding me. It didn't even cross my mind this was a bad practice since I have define( 'DB_HOST', 'localhost' ); on mine!
1. https://news.ycombinator.com/item?id=38521579
I've asked here before about HTML5 semantic tags[1], and the consensus seems to be they're worthless. H tags may be useful, but HTML5 sectioning algorithm allow for multiple H1's for example seems to be generally seen as an error. There are so many valid users for <article> that it can't be used to find the actual article on the page. And the best use case of <section>, in my opinion, is a section without a heading, the exact sort of thing that nobody wants to allow and will tell you to just a div instead despite the fact divs don't have a label tag for them different from <figure> (also used wrong all the time) and <table>.
>It gets you from 0 to 97% in an instant
Exactly. Front end frameworks can't have ruined the web, because without them, there is no web.
If Wordpress runs over half the web and we get rid of it because it's shitty and buggy, we're getting rid of half the web.
The alternative to no <a> isn't <a>, it's nothing. Websites that aren't accessible to everyone are still accessible to some people at least.
>using ENV variables instead of putting them in a file
Thanks for reminding me. It didn't even cross my mind this was a bad practice since I have define( 'DB_HOST', 'localhost' ); on mine!
1. https://news.ycombinator.com/item?id=38521579
> Exactly. Front end frameworks can't have ruined the web, because without them, there is no web.
What does this mean exactly? We had the web long before we had frontend frameworks and there are still plenty of sites today that run without a frontend framework doing all the rendering.
What does this mean exactly? We had the web long before we had frontend frameworks and there are still plenty of sites today that run without a frontend framework doing all the rendering.
This means that there is only something to complain about because it exists.
If React devs who don't know HTML had spent their time learning HTML instead of making React websites, we wouldn't have as many websites in first place to complain about them.
If React devs who don't know HTML had spent their time learning HTML instead of making React websites, we wouldn't have as many websites in first place to complain about them.
They've certainly served to massively reduce browser choice.
totally, React with a basic requirement of Babel to function and Webpack with ability to throw megabytes of crap at the user without understanding what you are doing and what it implies (like barrel files pulling in all the dependency tree of a module, or having runtime functions like "extend" in 150 versions in the same bundle) – all of that resulted in layers of complexity few engineers are willing to learn about.
This article makes incredibly poor arguments to support the title. "destroyed the web" is such a massive stretch - I remember pre-javascript internet and I remember pre-css internet, coded my first HTML page in 1995. Even early JS certainly didn't give us a fraction of the capabilities we have today.
There are many problems with javascript development, just as there are different problems with using other languages. But let's not pretend the web would be better without React or other SPA frameworks.
There are many problems with javascript development, just as there are different problems with using other languages. But let's not pretend the web would be better without React or other SPA frameworks.
are you using mobile web at all? I mean if you have an iPhone 15 then I guess you are having a good time. But "React" Internet is hostile to users and is damaging to business. Take a read – https://infrequently.org/2024/01/performance-inequality-gap-...
Admittedly, I'm not a huge user of mobile web (I'm not an iPhone user either, I'm still using a Pixel 4a).
However, I am absolutely not going to defend extremely heavy javascript content either. There needs to be a balance, and as your linked article mentions it will vary a lot depending on the demographics of the audience.
The original article though was not a good critique of any of that (your linked article is much better).
Even so a lot of work has been done to counter a bunch of the problems with doing everything with React. SSR while not a panacea, goes some distance to solving the problem.
However, I am absolutely not going to defend extremely heavy javascript content either. There needs to be a balance, and as your linked article mentions it will vary a lot depending on the demographics of the audience.
The original article though was not a good critique of any of that (your linked article is much better).
Even so a lot of work has been done to counter a bunch of the problems with doing everything with React. SSR while not a panacea, goes some distance to solving the problem.
all of this for the fake promise of "easiness to reason about" and "great DX". Which is not even remotely true, it’s MORE DIFFICULT to reason about and the DX of putting together these layers of badly configured stuff is anything but "good".
What's your solution to the "complexity" you're referring to?
My personal solution is to use the platform – modern JS and CSS are great.
The complexity is sometimes required, but in most web projects, these tools are actively harming the user, and also the long term maintainability, they eat into the business bottom line as well.
If I need to, I can stitch the files together, mangle variables, manipulate the AST or whatever I need to produce a bundle and my tiny script that I invoke with `make` will still be less than 1/10 of average config files for the mainstream tooling.
I made an experiment for years – write the code for the thing I‘d use a dependency for – sample an image size, build a "data model" abstraction, your own reactivity, a build script, backup solution, a cron job, release script etc. etc. etc. and instead of pulling my hair out I learned something useful each time and I can come back to a working and documented code that’s easy to improve and has a straightforward call stack.
The complexity is sometimes required, but in most web projects, these tools are actively harming the user, and also the long term maintainability, they eat into the business bottom line as well.
If I need to, I can stitch the files together, mangle variables, manipulate the AST or whatever I need to produce a bundle and my tiny script that I invoke with `make` will still be less than 1/10 of average config files for the mainstream tooling.
I made an experiment for years – write the code for the thing I‘d use a dependency for – sample an image size, build a "data model" abstraction, your own reactivity, a build script, backup solution, a cron job, release script etc. etc. etc. and instead of pulling my hair out I learned something useful each time and I can come back to a working and documented code that’s easy to improve and has a straightforward call stack.
There are plenty of ways a site can be built with less complexity. Going to the extreme, write any interactive code in plain old JS and ship it along with your HTML and CSS.
You could use a bundling step if you prefer, its pretty trivial to setup a basic bundler that wraps up multiple JS files. Heck, writing everything in TS and outputting a single file would do the trick.
You could use a bundling step if you prefer, its pretty trivial to setup a basic bundler that wraps up multiple JS files. Heck, writing everything in TS and outputting a single file would do the trick.
also, my solution is to be the engineer who understands these layers and gets a job to look into them – and it pains me to see that in 95% of the cases people just used whatever was lying on the table and not thought for a second they could go on MDN and find out there is a native API for their purpose.
No.
And if anything, WordPress did contribute to the current state. The article presents WordPress as a solution.
The few good WP devs and WP hosts are hard to find and expensive (rightly so). They sit amongst a sea of cheap labor, terrible hacks and grifters looking to vendor-lock you.
If anything, "a static HTML with some CSS" is a start of a solution. Not a MySQL backed hodgepodge of legacy PHP and proprietary addons. And also not yet another frontend framework.
And if anything, WordPress did contribute to the current state. The article presents WordPress as a solution.
The few good WP devs and WP hosts are hard to find and expensive (rightly so). They sit amongst a sea of cheap labor, terrible hacks and grifters looking to vendor-lock you.
If anything, "a static HTML with some CSS" is a start of a solution. Not a MySQL backed hodgepodge of legacy PHP and proprietary addons. And also not yet another frontend framework.
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.