So called modern web developers are the culprits(unixsheikh.com)
unixsheikh.com
So called modern web developers are the culprits
https://unixsheikh.com/articles/so-called-modern-web-developers-are-the-culprits.html
25 comments
Agreed if you're making a web page.
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.
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.
This article is a waste of time, just spouting the same blind hate for the web that's so common right now.
The logo on this website is 11kb for a 20x20 PNG. Running it through oxipng reduces it to 848 bytes with no difference in quality. It doesn't even need to be an image; the actual emoji would work instead and that would be 4 bytes of data.
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.
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.
"With regard to Rails and Django specifically then that is a matter beyond comprehension. Neither Ruby nor Python should ever have been utilized for web development. They are simply ill-suited because they are too slow."
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.
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.
It feels like most of the SPAs should really just be desktop applications and hopefully with wasm, wgpu, and wasi that can be reduced to a smaller runtime than the current v8 for everything solution. They're not really web pages anyway and trying to get them to convert to static documents doesn't seem like it will go so well considering the "interactive experiences" they provide (using the browser as a cheap GUI framework).
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.
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.
I understand the sentiment. And by all means use WASM for the heavy lifting. But leave the UI to HTML and CSS. It's pretty good.
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.
0 - https://gallery.flutter.dev/#/
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.
0 - https://gallery.flutter.dev/#/
Please consider making your website main content center to wrap around 80 characters in width, or even less. Anything thats less 161 characters is good.
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.
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.
> Please consider making your website main content center to wrap around 80 characters in width, or even less. Anything thats less 161 characters is good.
Also consider using a variable width font. They're much easier for most people to scan.
Also consider using a variable width font. They're much easier for most people to scan.
What an angry blog.
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.
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.
Never underestimate how much people struggle with change.
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.
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.
So here's the thing - I personally struggle to be productive writing javascript, and I really like Golang... So "Even when it is justified, make sure that everything STILL work without JavaScript." Seems like a nice idea - even something to aspire to maybe... But even with sensible extensions to vanilla HTML - like the HTMX framework, you cannot cross the chasm from wabpage to application without JS.
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.
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.
Rich Harris would probably frame this article's take as "traditionalist" — someone who cares about the traditional benefits of the web platform and sees the flaws in modern frameworks. The problem is of course that there are also benefits to modern frameworks for users as well as developers. Rich does a good job finding a middle way through both in this talk:
Have Single-Page Apps Ruined the Web? | Transitional Apps with Rich Harris, NYTimes https://www.youtube.com/watch?v=860d8usGC0o
Have Single-Page Apps Ruined the Web? | Transitional Apps with Rich Harris, NYTimes https://www.youtube.com/watch?v=860d8usGC0o
There is some relatively small merit to this article, web developers should spend as much or more time optimizing as time spent meeting product requirements.
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.
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.
>> Learn how to make a website with just HTML and CSS on the frontend. Only use JavaScript on the frontend for small UI improvement if you must, but make sure that the improvement is truly justified (you need to do proper user testing to know that). Even when it is justified, make sure that everything STILL work without JavaScript.
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.
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.
The flag needs to be removed, this article is spot on. Of course the people who do all these things cannot stand when the truth is spoken.
You missed the most important point here.
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 ;)
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 ;)
I don't fully agree with the article, but I see everyday sites that can be so much faster by making code more optimized. Processors are getting faster and people have more RAM? Nice, let's make web sites heavier removing any optimization. Well, that's the current situation, and it's very sad.
The Web and HTML itself is a living historical document.
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.
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.
> utilizing the technology in harmony with the intend behind it
What a strange, limiting idea. Should we be using this universally deployed, 100% cross platform and permissionless platform to create scientific hypertext documents?
What a strange, limiting idea. Should we be using this universally deployed, 100% cross platform and permissionless platform to create scientific hypertext documents?
agreed. Actually browsers can help in this direction by incorporating a lot of the javascript UI elements into HTML. Most websites look the same anyways nowadays, optimized for mobile, rounded corner buttons, the same animations over and over. Web UI should be enough to replace all the apps in your phone nowadays
> Actually browsers can help in this direction by incorporating a lot of the javascript UI elements into HTML.
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.
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.
With respect, I think this article is largely misguided and seems to come from a general rant-perspective rather than from any coherent reflection of the state of things today.
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.
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.
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.