If it's not satire, I think it's misguided in places. Saying that Ruby/Python are too slow for web development and that it should be done it Go instead is a very naive point of view, that focuses too much on the technology rather than the problem being solved. It blasts past the use of fonts and big (high quality?) images saying people don't care, but with no evidence for that.
There are also some odd points made, like the points about single page apps. SPAs have the potential to make more granular HTTP requests like the author is advocating for than what is possible with full page reloads. I also think it's a strong bias of engineers to consider HTTP to be the user experience, it's not.
There's good stuff in here, but a lot of it boils down to: think about your UX, consider what the best tools are for the job, don't follow hype without consideration. Unfortunately most of the examples and extrapolation from these starting points is fairly naive.
However there are lots of us writing applications which are delivered by browser. With that lens you're completely wrong. Then I do want to send json from the backend and have lots of behaviour in the frontend viewing that in different ways.
So basically it's the differences between web pages and applications.
Truth is that there aren't many other sensible ways to deliver applications any more. All big companies still have windows machines - but MS broke all of the ways of writing applications on windows so going to the browser makes sense and you get some cross platform ability - plus you get to move it to the cloud.
I don't know if this is an argument that modern web developers are to blame because they do things like this, or if it shows the author isn't very aware of how to make a small website and his arguments should be taken with a dose of skepticism.
Either way, please, if the author is reading, optimize your images.
In what alternate reality does the author live ? Or in what alternate reality do I live ? Because in more than 20 years, in all web projects I've worked, the backend language (be it python, php, java, whatever) has never been the bottleneck. Granted, I've not worked in Google-scale evironments, but saying any web development should be done in Go is incredibly misleading. And I have nothing against Go, I quite like it actually.
Would possibly be nicer to ship for the new "java platform" that wasm is slowly recreating even for software that's not currently written as web apps.
Every attempt at running a canvas-driven UI I've seen are dreadful. Flutter, probably the most prominent example, can't even get scrolling right. And then crashes on Safari [0]. This is only scrolling. There's so much else.
I am very aware that I can resize my browser window to make this adjustment myself. Buf if your content is not meant to be viewed in "full screen width", do not allow it to overflow in that way. If you mean to have your content viewed in "full screen width", consider reading about line length readability issues. Also consider why scientific journals publish in the two-column format.
Regarding the content of your page. To what developer does your guidelines truly apply? To what real life setting does it give good advice? Most web development nowadays is not centered around publishing documents and or the occasional blog, but rather something more akin to applications and programs. Why is it that way? Because the web wanted to produce rich experiences for users. It became something that it was not meant for in the start. And now __it is__ that. Declaring that it is still what it started out as is simply false.
Don't get me wrong though. I perfectly see the appeal of making webpages usable in something like lynx, and have even made the effort to reach that goal in real life environments. But that is not what the "web" is for nowadays, it's something far less nerdy and appealing to us.
Also consider using a variable width font. They're much easier for most people to scan.
It does contain nuggets of truth, but like 4chan of old, it takes sifting through a lot of poison getting there. Is it worth it?
You don't convince people by hurling shit at them.
These rants are trendy, I’m excited by what can be done in the browser now.
If websites were really so bloated and heavy and unusable I think they would naturally suffer for it, the problem is overstated - at least from the perspective of the average user.
I see this as an argument about operating systems, and the need and impossibility of agreeing on a universal one. In real life Chrome/Firefox is where my most important apps are "installed", operate, and get used. That's not going to happen without JS and modern "web" design.
Have Single-Page Apps Ruined the Web? | Transitional Apps with Rich Harris, NYTimes https://www.youtube.com/watch?v=860d8usGC0o
But web developers don’t typically define requirements, like which and how many tracking services need to be implemented or how many social network integrations are needed.
Functionally a site should work and be accessible without JavaScript. A website should use minimal semantic HTML. A website should not require hundreds of kilobytes of CSS. That’s all realistic.
But to imply that web developers define what exactly ends up on a web page is idealistic.
Is this article really from 2021? Maybe if you write a static blog this will work, but man, the browser is the new OS. No way we are dropping Javascript just because some luddites want us to.
I started with RoR, also still using jQuery for "small UI improvement", and RoR has a default way to do it without boilerplate code.
But real world is not the developer's world. There's also the End user !
They want interactive , single page experience. That's the fact.
So the price to pay is what you described. Persuade and blame end user first ;)
If you want to write good Websites, go through the last 25 years of browser history using Wine and try to write something which covers all of them.
It's not that difficult, and then you'll be ready to write actual accessible and compatible HTML.
What a strange, limiting idea. Should we be using this universally deployed, 100% cross platform and permissionless platform to create scientific hypertext documents?
Unfortunately, none of the browsers want to or can do that. Chrome is mostly interested in fire and motion, and the other browsers can only do so much to keep up with it.
And while attempts like https://open-ui.org/ are admirable, we'll never see it in the browser.
Apart from the contradictory things it says (e.g. "Don't use a CDN" then "Use caching!" and "Don't load everything at once - use links" then "Don't make user redownload everything if they click a linkl"), there are some ideas that need challenging.
Also the general tone of this article is pretty poor (calling people "fools", "idiots" etc) - please treat each other with respect!
Single-Page Apps & JSON
Modern frameworks support lazy-loading. The entire thing is not loaded at once. Small individual HTTP requests are sent on-demand to request the required parts of the site as they are needed.
Sending a single JSON response to the browser via a fetch() will many times be significantly smaller & faster in terms of payload/bandwidth than doing an entire page reload since you do not need to reload the HTML, the CSS, the images, the favicon, the scripts etc then re-layout and re-render the entire thing when you could have just got a 500 byte JSON payload back and updated the existing page in real-time. Often it is an API you are working with - pretty much everything I have worked on in the past 5-10 years has had just normal API endpoints as "the backend" and your web frontend talks to those endpoints in the same way as any other API client would.
There are also alternatives to JSON that are easily usable and higher performance (in terms of parsing and payload size), e.g. gRPC.
Server Side form validation
I think it is generally agreed that real-time validation of input fields is a net-win for users - HTML5 allows for basic validation to happen "natively" in the browser anyway, but lightweight javascript validation is going to run in <1ms, and even a server fetch() behind the scenes while you are typing is not going to be noticeable.
The alternative of leaving the entire thing to be validated on the server after submit might work for small forms with perhaps 3 or 4 fields, but the user experience for a larger form (e.g. tax return etc) that takes a long time to fill in will benefit hugely from real-time validation as the user is entering data. There are also a11y (i.e. screen readers etc) problems of just doing a page reload, rather than something dynamic.
Javascript will not stop tab from working in a form, unless you go out of your way as a developer to do so. I am not aware of any common frameworks in use today (React, Angular etc) that break taborder.
Google Analytics/Server-side data
The days of your site running on a single server are long, long, long gone. You no longer have a single apache log you can parse to get realistic usage information. While I do not question that Google Analytics et al are potentially dubious, some sort of client-side data collection framework is a logical approach when running a highly-distributed app across many physical servers, particularly if you are using XaaS solutions such as AppEngine etc where you don't get any server logs to process.
Anti-framework rhetoric
I think being anti-framework is unhelpful. Using frameworks is not a "click a shiny button and everything is done for you" (as hinted at elsewhere on this person's site) - for things like react and angular, they provide a framework for writing modular, well-encapsulated software that works efficiently.
Without frameworks and everyone doing things their own way, you'll end up with longer development cycles leading to lower-quality software riddled with subtle bugs (e.g. my own personal war-story was a favicon getting cached that introduced a subtle user-session bug that allowed people to view other user's data - this was from way way waaaay before React, Angular and even RoR was on the scene, and we were using a home-made solution). You don't get these kind of bugs so much now because the framework is written once by smart people and then exercised and tested much much more than any homemade approach ever could be, just due to sheer numbers. Bugs will be found and fixed before your own project even started.
Programming languages being slow
Python is not fast I agree (and I have minimal direct experience of Ruby), but in the realm of web dev, any server side calculation is going to be waaaaay faster than the network RTT likely by many orders of magnitude. Add in to that slow database queries, and the choice of backend language is kinda meaningless. I would not expect the average backend web application to be doing any hard-core calculations that would benefit from a lower-level language - most are just acting as a facade or adaptor to other backend services or some slow & bloated database.
tl;dr summary
I think that there is a perception among various people who scoff at web development as this trivial thing and that front end engineers aren't needed, and that they only exist to add javascript complexity that does nothing and that 100% of a websites functionality can be handled with plain HTML + HTTP Forms.
The reality (IMO) is that the browser is the "new OS" and that for most consumer & business software, running in the browser is the obvious choice. Like it or loathe it, this appears to be the current approach.
Sure we could go back to something akin to early 1980s or 1990s user interfaces (and indeed some of the web-based software I use regularly at work uses some of those "engineer designed" plain HTML + forms approaches and they are fine), but we have to think about the usability and accessibility (plain HTML does not guarantee that a website is accessible - it might meet the letter of the law, but in spirit it can be sorely lacking) of our user interfaces for all of the people who use our software now (be they young or old, technically savvy or barely used a computer before): many will consider a raw Times New Roman HTML page as jarring and technically "scary", and those that rely on accessibility tech will suffer greatly.
