Comment by miyuru
15 hours ago
I just tried their domains page it took 10.8MB of data and took 2s for the DOM to be ready.
page actually took 17s to fully render with multiple shift changes.
all to render a domain search bar similar to google home page.
There are some easy optimizations wins for this page but none of the top ones are framework related. Maybe with the faster build times they can easily optimize images and 3rd party dependencies. As someone else pointed out, nearly half that data is unoptimized images.
For the curious, google's current homepage is a 200kb payload all in, or about 50 times smaller.
Who remembers sprite sheets? Does that give my age away?
I did an optimization pass for a client once where I got rid of a ton of the sprites but didn't have the energy to redo it all, so it just had huge sections that were blank.
Super snappy loading afterwards though.
Yes, good times! With http2/3 they don't really matter anymore though, you get similar benefits from request pipelining.
1 reply →
web dev is a sewer
All my projects are server rendered with jinja/minijinja, bootstrap, jQuery, and htmx when I need a little bit of SPA behavior on forms.
No builds, just static <script src= tags. Very fast and easy. I'll never recommend anything else.
I'm coming back to Django after a decade of experience with it post-0.96 and having moved to Next.js a few years ago. Going from 1,700 dependencies to 65 total with Django + Wagtail + HTMX.
When I am given the choice to pick a stack, it is classical Java and .NET Web frameworks, with minimal JavaScript.
On hobby projects same script approach without any kind of build step.
Sounds more difficult then modern web frameworks. We've all done this for little projects, but anything with users or development teams, your method is DOA.
Eh, there’s tradeoffs. They’re real. But I’ve done plenty of this on teams back in the day before all these frameworks and it can absolutely work. It may even be easier now with JS modules.
I disagree, most webapps, like 99.9% I would say, are just forms, links, and pages. Meaning, they can be done with 0 reactivity and that is the most simple and straightforward way to do it.
Less code is basically always better, so if you can skip the huge amounts of JS and orchestration required by modern web frameworks, then it will be easy. People are out here using React to render static pages. It's very overkill.
1 reply →
With C#'s Blazor templating, you can ditch all JS logic, and use raw C# for all front-end logic, and have it all be transparently server rendered similar to how Phoenix has LiveView.
I also have experimented with HTMX and Django, and that seems to be a nice combination.
Everything is AJAX again.
I've a C# fanboy, but Blazor's DX just isn't very good compared to say Vite.
There are many conditions under which the hot reload just straight up crashes out regularly.
1 reply →
Dear lord. It's actually laggy for me to scroll on that page.
same here and I'm using a beefy MacBook (Apple M4 Max, 64gb ram). something is wrong with the front end code. there are a lot of animations, so my hunch would be that something goes wrong there.
Moore said computers get twice as fast every 18 months. Web devs took that as a challenge.
2 replies →
The 3.57MB background PNG is hilarious [0]
[0] https://railway.com/dots-oxipng.png
I got it down to 1.03MB by just switching the png to palette encoding mode.
Ha! I normally wouldn’t find it quite so hilarious, but it’s a stylistically pixelated image. There’s just too much irony packed in there to not chuckle.
It's more halftone (might not be the correct term), not pixelated
There might be more irony in saying it's stylized pixels without realizing that the style of the image can't be replicated with blocks of the same size but I dunno, I'm not Alanis Morissette
They could have saved themselves 3MB by converting it to AVIF.