I disabled javascript in my browser. Amount of shit loading to read shitty article is insane.

I opened chrome devtools and it was 300 requests and 10MB to read 500 words.

Another news portal 250 requests 7MB to see 300 words.

WTF ?

And they’re fighting with internet traffic by lowering movie quality ?

I just add I have pihole with lots of wildcard filters filtering half of internet and fucking adblocker and those numbers are after those filters.

Are you fucking out of your mind ?

Fucking hypocrites.

@molaram friend told me that the more website tries to load the less relevant content it is and that’s more or less true

hackernews ycombinator
6 requests 58kB

The number of web pages that contain basically static content, and yet only show a blank white page without Javascript is equally insane.

https://motherfuckingwebsite.com/ has it right.

I had some massive forms to build for a job. They wanted an angular application and etc. They needed something that would work in rural areas but still fit the feel of other pages.
I made a few forms with Bootstrap and plain HTML/CSS/JS I served it with Express. It was quite small and quick.
They had spent a whole year developing similar forms on another project in Angular. I did it in a week. I looked at the code and they were designing it with reactive forms and thousands of lines of code. 🙄

Same. Am I the only one who's constantly disappointed when a website isn't roughly as fast as an offline GUI? Is that too much to expect?

I mean nowadays we can have 120+ Hz screens and then we use them for watching almost every fucking website load for seconds.

@molaram I have a project website with some interactive JS widget going on, responsive and shit - less than 18 kB over the wire. It's still possible to put shit together the old way. Just better because no layout tables and this crap.

Btw, 1 MB of JS is already insane IMO, except if we're talking about a complex application, not a webpage.

@VaderNT

https://brutalist-web.design/

Disabling JS goes a bit too far for my taste as it completely cripples most websites -- but uBlock Origin + Privacy Badger helps a lot already.

@bittersweet That's kinda the point - devs are making JS mandatory even on pages where there's nothing that would justify the mere presence of JS.

@Fast-Nop

True. Although I get it.

HTML + CSS is kind of a broken concept even if you want to build a webpage without any business logic in the frontend — building "modular" pages, reusing styling, without any JS framework can be a challenge.

HTML doesn't support nesting, templating, inheritance.

The fucked up class/ID system has led to monstrosities like BEM and smaccs, which are halfassed attempts to fix styling organization; and preprocessed shit like Sass which is a threequarterassed attempt.

The separation of layout, style and function into 3 "languages" is the biggest brainfuck of a mistake made in the history of the web.

The answer would be a lightweight document type with all the backwards compatibility crap removed. Fuck HTML, why not a strict typesafe JSON-like format. Treat each element in it like a struct, and allow both implementations and traits — similar to Rust or Kotlin code.

Then make sure Edge browsers in 2050 support this new standard.

Would be fun if browsers enforced a 20kb limit per page.

I mean, if commodore 64 scene devs can fit things like an Audio DAW or a 3D renderer in 20kb of memory... Who knows what could happen in 20kb of JS.

@bittersweet HTML and CSS aren't broken. What's broken is most frontend devs failing to grasp the simple concept of separating content and styling.

The HTML says WHAT things are, without caring how it looks. That's semantic markup. The CSS in turn gives things a look, depending also on the specific media.

JS in turn is HOW it behaves dynamically (and not for replicating CSS or even HTML functionality).

These three aspects are completely different functionalities, and that's why they are three different languages.

@Fast-Nop

My point is that that separation by layout vs style IS broken.

They aren't separate, a UI element consists of both text, styling and behavior.

If you have an index.html with a user profile div, and a stylesheet.css with some styling for that div, there's nothing preventing a developer from accidentally deleting the styling, or removing the element without cleaning up the related style.

There's no type safety, no hard links, no compiler error saying "you forgot to define padding for this element".

Of course, you often want to propagate a "theme", for which you could use inheritance, preferably a kind of "styling inheritance" using traits.

But there is absolutely a need to package semantics, styling and behavior together, which is why we're increasingly seeing frameworks like Vue, Angular and React define templating systems and "components" or "modules".

@bittersweet There's absolutely NOT the need, on the contrary. Devs deleting files nilly-willy is a nonsense argument because they might as well nuke the whole server.

The UI element in the markup shouldn't even be concerned with styling, that's the gross misunderstanding of crap like Bootstrap that litters the markup with presentational classes.

The whole idea of bunching all in one pot is basically rehashing the bad old days of HTML 3 and the 1990s. Admittedly, many frontend devs never came out of that black hole because they didn't get CSS at all.

The great thing was to SPLIT structure, style and behaviour. That was one of the really good ideas since the end-1990s.

Oh and for unused styles - of course there are tools to detect that even across a whole website recursively. Also, if there's more than around 32k of minified CSS, things have gone wrong. I don't see how anyone would even worry about that tiny amount of code.

@Fast-Nop I fundamentally disagree -- In the backend, one of the worst decisions was MVC, one of the best was DDD.

One groups things by architectural tier, the other by context, by business functionality.

In the backend, it doesn't actually make sense to have all your routes grouped, all your models grouped, all your views grouped. MVC is a tumor on backend development.

You should still have separation of those things on a very small scale, but your project should be structured along the lines of contexts, of "This is account creation", "This is invoicing", "This is preference management".

In my opinion, frontend separation into semantics/style/behavior is nonsense.

The behavior of a button is tied to the button. To have styling in a file with all other styling, and behavior together with all behavior, is pure chaos.

If we could start from scratch, the HTML/CSS/JS divide should not exist. It should be one unified language, which defines unified components.

@bittersweet Well we did have one try like you describe - Flash. Apart from it's notorious security problems, it was also not accessible, and not searchable.

Also, having all styling in one file means that you only write it once, and only download it once with a single handshake overhead. Styles are meant to be re-used across a website. Also, you really can't tell me that "pure chaos" in 32k of declarative CSS is overwhelming anyone.

Plus that styles are cascading, that's why it belongs into one file. Granted, many devs don't get that part of CSS, and you recognise it when they slap classes on every little piece of crap.

Also, what's that button nonsense? You shouldn't even have that many different styles for different buttons.

@bittersweet actually HTML supports templates, check out the <template> tag

I am an avid NoScript enthusiast.