Hacker News

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.

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.

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.

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.

They could have saved themselves 3MB by converting it to AVIF.

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 means you take responsibility of maintaining the server forever, i.e. dealing with TLS certificates, SSH keys, security updates, OS/package updates, monitoring, reboots when stuck, redeploy when VPS retired, etc. Usually things work fine for a year or two and then stuff starts to get old and need attention and eat your time.

No click-ops that way.

I just did this over at Hetzner and Claude admins it for me so I don't need to learn the CLI or anything, describe the proxying I want, and it setups up a bunch of small side project pages for me.

Obviously it's more than just debouncing. https://tanstack.com/pacer/latest/docs/overview

How does an apps user base affect its build time?

It is fashionable, and Vercel has made a chain of partners that make Next.js/React the only official option to extend SaaS products.

I think the unfortunate truth is the simplest. Web development has long been detached from rationality. People are drawn to complexity like moths to a flame.

I've been on the remix on a previous project, I have to say that Remix was even worse. But that's probably of the setup with vite etc not being correctly done.

Yep this is what's often misunderstood.

We also recently cut our build times in half moving from Webpack to Turbopack on production builds after jumping to NextJS 16. We'd already been using Turbopack in development for a while which yielded massive DX improvements related to performance. Production build times will drop further once Turbopack production build caching is stable.

Webpack -> Turbopack is the smart initial migration. I'd bet Railway went straight from Webpack -> Vite not realising that their real gains sat with the build tooling, not NextJS vs Tanstack.

Yes I'm on turbopack and running the latest version of Nextjs.

Is that because LLMs default to the older pages router? Or are they actually providing a different version of the library optimised in some way for agents?

Turbopack, custom runtime infrastructure on top of AWS Lambda.

Only if they weren't using Turbopack.

Of course it should be mentioned, it's a basic disclaimer.

I don't know the situation now, but a while ago there were a lot of pushback using Next.js because it was not easy to use all features if not hosted on Vercel.

HTMX is great when your web interface is just a representation of a server state.

If web interface is an application backed by a remote state HTMX falls apart.

None of the above. It is a utility (I guess framework maybe) for a feature that was cool in ASP.NET back in 2005. But that is it's charm. It is just JS swapping out the dom for you.

I'm not insanely deep into frontend, I mostly just pick up React and call it a day, but it seems like this is also over-engineered?

I've seen vanilla JS before, and I just know I wouldn't want to do the housekeeping that comes with it. People claim it's less work because it' simpler, but I fully expect myself to rewrite the thing at least twice, only to give up because I have no actual mental model anymore of how it works.

Isn't the main problem that the building blocks the modern web is based on are not a good fit for what we do with it?

CSS is a total mess. HTML is a mess. JS is okay, but is not a high quality language.

We would save so much time and money if we would have a modern base to build on. Sadly this will probably never happen, because company interests will try to corrupt the process and therefore destroy it.

This is my understanding too - tools like react are like microservices - they’re a technical solution to an organisational problem. HTML/css/JavaScript is an imperfect abstraction, so we got bootstrap. Then we got client side frameworks which introduced a build step, and then we got asset bundles, optimisers, linters, validators, tree shakers, package managers, validators for your package managers. All of these monkey patched around the actual problem with more abstractions, and the end result is what we have now.

Not that backend is any better - microservices everywhere, must scale to Facebook traffic even if we only have 10 customers, etc. Saying this as a backend dev

Like using SPAs for classical Web development, and then they rediscover PHP.

It’s mind blowing when you check the generated code, because it goes over 50 elements deep for a simple looking website.

Makes me think that there’s no way this is computationally efficient either.

And underenginered at the same time !

Same reason why 90% of websites have serious UX issues and constant bugs. This and ad frameworks.

I don't think any C compiler has been single pass for the last 20 years. Typescript's analyses are also not that complicated, it's just that the typescript type checker is written in js. Iirc the actual ts -> js part is pretty fast with some of the more recent compilers.

That's not the point...

I disagree - this is an excuse. Even the post we’re commenting in now shows that it’s a series of poor abstractions and bad tooling that takes way too long to do the basics, combined with a language and ecosystem that encourages this behaviour . They saw a 5x speed up by changing tools while still using a JavaScript framework so it’s clearly possible for it to not be complete nonsense.