Have front end frameworks destroyed the web?
gdnetwork.co
gdnetwork.co
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.
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.
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.
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 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.
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.
<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.
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.
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.
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.
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.
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.
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.
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.
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.
(Disclaimer: I don't like Frameworks, though I think vanilla web development could be much better)
> 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
cute joke.
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!
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.
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.
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.
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 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.
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.
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.