> Fast-forward a couple of decades and we’re building highly interactive, component-based, state-driven, design-system-heavy applications

Are we actually, in fact, if we're being honest?

I haven't seen anything like that. 99.9% of applications I interact with are just a series of simple CRUD operations. Sometimes they add unnecessary complexity and flashiness and of course there are some games and such, but when it comes to actual business apps they all just boil down to updating text records in a database at a human pace.

I am genuinely interested to hear examples of these "highly interactive" web apps others are building I keep hearing about but never seeing.

> Are we, in fact, if we're being honest?

Obviously, yes.

> I haven't seen anything like that. 99.9% of applications I interact with are just simple CRUD apps.

Irrelevant. Being CRUD is completely orthogonal to whether the WebApps are interactive or not.

Look at Gmail. You can hand wave over it and claim it's a CRUD app. However, no one in their right mind would try to deny the app is a "highly interactive, component-based, state-driven, design-system-heavy applications".

Also, it's silly to pretend that SPA-type apps are only justified if you check each box in the buzzword bingo card. One of the primary selling points of designing SPA or non-static lage, SPA-like WebApps is performance. Meaning, you are able to put together a highly performant web page if you do not require full page reloads each time anyone clicks on something, if you can easily implement optimistic logic in components, and if you can update only a subset of components when you receive a response from a request.

I recommend discovering the concept of perceived performance and afterwards you read through common patterns and strategies to optimize perceived performance. After you do that, go through a though experiment where you start off with an old timey dynamic HTML/server-side rendered WebApp and consider the challenge of achieving the same type of improvements in user experience, or even doing the same tricks. You'll quickly arrive at the same conclusions at the whole world around you already arrived at.

I totally agree, maybe 1 in 100 web pages actually NEED any of the code they run. Mostly it's reinventing the wheel. Where a flat site with fixed HTML and pretty CSS would be fine, they add a splash page so they can show a logo, they'll break navigation and reimplement the browser inside the page with JS so you can't use the back button, they'll style everything on the fly when nothing is dynamic, etc. Nonsense.

> 99.9% of applications I interact with are just a series of simple CRUD operations.

The vast majority of web apps out there could be implemented as REST systems (in the real, Fielding, HATEOAS sense, not the JSON-over-HTTP sense).

There are a few out there which need to be web apps, but those are relatively rare.

Easy. It's just about any react/angular/vue based site written these days. Take GMail, Jira, your health insurance portal, TurboTax, and a littany of other sites.

Practically every one of these uses components, internal state, and design systems to make the site highly interactive, just about every "web app" falls into this category.

I feel exactly the same way as you, and I get flashbacks to every time someone talks about the new framework on the block that serves to fix a problem that 0.1% have, while making things worse for the other 99.9%.

It really depends on what you call CRUD, but for instance, in the past, I've had frontends hiding the crud behind more "friendly" gestures. For instance, a write such as rescheduling a sale could be done with drag&drop, reads would feed a local store of events/sales that could be browsed either as a workweek panel of which sales are happening, or as a monthly calendar aggregating sales and showing which day is a "hot" day and which day is quiet and needs more blockbusters to drive sales. Add in search features, graphs of forecasted sales and a news feed on the sales a specific user was managing.

It's not that complex or fancy compared to what can be found in b2c, but it's not just a crud where users are directly tasked to update values in fields either. And yes, it could have been a crud, but I believe our users would have been worse off.

It's all the buzzwords to justify the overcomplexity of web frontends.

I work on exactly this kind of app, and it’s open source: https://github.com/mickael-kerjean/filestash.

It’s a Dropbox-like file manager that instead of owning your data integrates with your existing storage, authentication, and authorization systems. Under the hood, there’s a lot going on, very recently I added plugins to handle various kind of file types that are not typically handled by browser, we're talking > 100 kind of file types handled entirely in the browser for niches like astronomy, data engineering, GIS, 3D models, dev and even embroidery patterns

> I haven't seen anything like that. 99.9% of applications I interact with are just a series of simple CRUD operations.

The painful reality is that this is true, but only at work.

There is so much that you use written in web technologies that are no CRUD. Some of that is Electron apps like VS Code and some of it is applications packaged in docker containers. Almost all of this non-work and non-CRUD stuff is open source. If you aren't writing code outside of work, where its only CRUD, your perspective of the universe is about 2mm wide. That is where the Dunning-Kruger starts to set in and why all this shit gets reinvented every couple of years. Its easy to think that: 1) you are awesome and 2) the world is painful when your perspective of the universe is only 2mm wide.

For everybody else, these things that most developers complain about really aren't painful enough to warrant any call to action because there are other things that bring substantially greater pain.