QUIC is not quick enough over fast internet

Industry will do absolutely anything, except making lightweight sites.

We had instant internet in the late 90s, if you were lucky enough to have a fast connection. The pages were small and there were barely any javascript. You can still find such fast loading lightweight pages today and the experience is almost surreal.

It feels like the page has completely loaded before you even released the mousebutton.

If only the user experience were better it might have been tolerable but we didn't get that either.

I am currently de-javascripting a React app of some project I am working on.

It's a blast. It's faster and way more resilient. No more state desync between frontend and backend.

I admit there is a minimum of javascript (currently a few hundred lines) for convenience.

I'll add a bit more to add the illusion this is still a SPA.

I'll kill about 40k lines of React that way and about 20k lines of Kotlin.

I'll have to rewrite about 30k lines of backend code though.

Still, I love it.

Nature is healing. Love to see it.

Lightweight sites don't make for shinny CVs.

Even on the backend, now the golden goose is to sell microservices, via headless SaaS products connected via APIs, that certainly is going to perform.

https://macharchitecture.com/

However if those are the shovels people are going to buy, then those are the ones we have to stockpile, so is the IT world.

My feeling is that the microservice fad has passed… for now. But I’m sure it’ll be resurrected in a few years with a different name.

Nah, it is only really taking off now in enterprise consulting, with products going SaaS and what used to extension points via libraries, is now only possible via Webhooks and API calls, that naturally have to be done somewhere, either microservices or serverless.

Honestly I used to be on the strict noscript JavaScript hate train.

But if your site works fast. Loads fast. With _a little_ JS that actually improves the functionality+usability in? I think that's completely fine. Minimal JS for the win.

When I was finishing university I bought into the framework-based web-development hype. I thought that "enterprise" web-development has to be done this way. So I got some experience by migrating my homepage to a static VUE.JS version. Binding view and state by passing the variables name as a sting felt off, extending the build env seemed unnecessary complex and everything was slow and has to be done a certain way. But since everyone is using this, this must be right I thought.

I got over this view and just finished the new version of my page. Raw HTML with some static-site-generator templating. The HTML size went down 90%, the JS usage went down 97% and build time is now 2s instead of 20s. The user experience is better and i get 30% more hits since the new version.

The web could be so nice of we used less of it.

Absolutely.

I want the basic functionality to work without JS.

But we have a working application and users are not hating it and used to it.

We rely on modals heavily. And for that I added (custom) JS. It's way simpler than alternatives and some things we do are not even possible without JS/WASM (via JS apis to manipulate the DOM) today.

I am pragmatic.

But as you mentioned it, personally I also use NoScript a lot and if a site refuses to load without JS it's a hard sell to me if I don't know it already.

What do you use that good javascipt for? And what is the excessive stuff that causes slowness and bloat? I'm not a web programmer, just curious.

Building a new app at work using Web Components and WebSockets for dynamism. I’m using Bulma for CSS, which is still about 300KiB. However, the site loads instantly. I’m not using a Javascript framework or bundler or any of that (not even npm!), just vanilla Javascript. It’s a dream to program and I love not having the complexity of a framework taking up space in my brain.

Example of an almost instant webpage today: https://www.mcmaster.com/

And users clearly appreciate it. I was going over some bolt types with a design guy at my workplace yesterday for a project and his first instinct is to pull up the McMaster-Carr site to see what was possible. I don't know if we even order from them, since we pass through purchasing folks, but the site is just brilliantly simple and elegant.

Two examples that come up a lot for me:

1. filtering a drop down list by typing rather than scrolling through lots of options to pick one 2. Rearranging items with drag and drop

The excessive stuff is requiring a whole lot of scripts and resources to load before you display a simple page of information.

My rule of thumb is to render HTML where the state actually lives.

In a huge majority of cases I come across that is on the server. Some things really are client-side only though, think temporary state responding to user interactions.

Either way I also try really hard to make sure the UI is at least functional without JS. There are times that isn't possible, but those are pretty rare in my experience.

My personal projects are all server rendered HTML. My blog (a statically rendered Hugo site) has no JS at all, my project (Rails and server rendered HTML) has minimal JS that adds some nice to have stuff but nothing else (it works with no JS). I know they're my sites, but the experience is just so much better than most of the rest of the web. We've lost so much.

I've come across quite a few job postings in the last could weeks looking for senior engineers with experience migrating monoliths to micro services. Not sure if the fad is still here or if those companies are just slow to get onboard.

There are still good uses for micro services. Specific services can gain a lot from it, the list of those types of services/apps is pretty short in my experience though.

Tried that on my website (bittich.be), it's only 20ish kb gzipped. I could have done better if I didn't use tailwind css :(

Someone did an analysis of that site on tiktok or YouTube. It's using some tricks to speed things up, like preloading the html for the next page on hover and then replacing the shell of the page on click. So pre-rendering and prefetching. Pretty simple to do and effective apparently.

Doesn't the combo box input field already do this?

Choose the right tool for the job. Every engineering decision is a trade-off. No one blames the hammer when it's used to insert a screw into a wall either.

SPA frameworks like Vue, React and Angular are ideal for web apps. Web apps and web sites are very different. For web apps, initial page load doesn't matter a lot and business requirements are often complex. For websites it's exactly the opposite. So if all you need is a static website with little to no interactivity, why did you choose a framework?

I have two websites written in JS that render entirely server-side. They are blazing fast, minimal in size and reach 100/100 scores on all criteria with Lighthouse. On top of that they're highly interactive, no build step required to publish a new article.

yes it has for early adopters but there are still lots of dinosaurs out there just now trying it out.

rewritten in next.js https://x.com/rauchg/status/1848033867145572654

You are right, it does.

A better example would be dynamically loading the list of options where it is very long and loading the entire list would make the page size much larger.

Check out mcmaster.com for an example of a highly optimized website using JS strictly to improve performance.

you should add a page to your website found at /trippin

A hammer to insert a screw into the wall could be a shrewd way to bore a hole with a bigger gauge if you're missing a drill.

Not sure to understand what you meant