In some sense, I feel like the big frontend frameworks are very useful for large apps but they became the default for even the most basic interactions. Now some developers are realizing that for their basic needs it is simpler to go back to the basics. For ambitious SPAs I still think something like React or Vue is the way to go.

> In some sense, I feel like the big frontend frameworks are very useful for large apps but they became the default for even the most basic interactions.

Exactly, I'm using react at work when working on a huge web app and jquery at home for my little side projects. It's so nice not having a build step for my side projects. While at the same time it's really nice not using jquery in a project with dozens of developers.

Yup. I find that most cases of "JavaScript fatigue" are really cases of "I want tools custom tailored to my use case, but don't want to do the legwork to figure out what they are".

The only thing wrong with jQuery is that it's perfectly fine until it isn't. Conversely, if you'll never need React's power you don't need it's complexity either.

React's (or other SPA frameworks like Vue's) complexity is much higher than it should have is probably because of the tooling (Babel, Webpack, NPM etc) and additional build process required even for a simple hello world app. That coupled with the rapid revision of the underlying ECMAScript standard and the race by developers and framework authors to adopt them causing further chaos.

Another issue was the rapid deprecation of age old JQuery plugins and the lack of equivalent plugins in the React landscape causing confusion whether you should build it yourself or not etc. I had hoped WebComponents somehow got standardized as the underlying architecture for SPAs, just so that the plugin/widgets wont get fragmented further, but it looks like it wont be happening anytime soon.

> React's (or other SPA frameworks like Vue's) complexity is much higher than it should have is probably because of the tooling (Babel, Webpack, NPM etc) and additional build process required even for a simple hello world app.

I wouldn't frame it as excess complexity, I would frame it as power. My problem is not writing simple hello world apps, it's writing and maintaining very large production applications with 5 other developers. Two years ago I took a week to really learn the tooling stack and it's paid dividends ever since.

We are 10 developers just using vanilla Javascript here. No mess, and a joy to work with. We use good old design patterns like observer, proxy, composite and so on. We also use inheritance and template literals a lot.

The key is good documentation, having an onboard plan for new developers, keeping things stupid simple and stop being bleeding edge. We want our code base to just work, so we can focus more on new features and less on maintenance.

I'm planning on writing a deeper blog post this year about why and how we feel is a good structured simple way to do frontend development. I believe there are several frustrated frontend developers out there that just want to make their life easier but currently all the arguments they find just favor 'React'....

Our whole Javascript codebase is 50k + lines. But the clients only fetch what is needed.

> joy to work with

Color me skeptical. React is quite literally the only framework I've ever found to be enjoyable (and maintainable).

> React's (or other SPA frameworks like Vue's) complexity is much higher than it should have is probably because of the tooling (Babel, Webpack, NPM etc) and additional build process required even for a simple hello world app.

This is false or misleading. There is complexity, yes, but those tools abstract it away and simplify everything. Then they have configs with great documentation for when you need to deviate from a default or add a plugin. Next, these things are pre-configured for you. "More complex than it should be" is when you try to reinvent the power of these tools for literally no coherent reason.

> "I want tools custom tailored to my use case, but don't want to do the legwork to figure out what they are"

I feel this quite often. It doesn't help that the tools move so quickly that once you develop a kind of gut feel for what frameworks work in what situations its already changed and you get a bunch of "lol [X] was 2 years ago we're all on [Y] now".

Dunno, but it wouldn't surprise me. The resemblence between tables and flexboxes is also quite funny. We took 20 years from declaring the structure of table-like markup in a table to declaring it in CSS with a flexbox.

Cool, but things like this have a marginal positive effect for developers, at the cost of having to learn yet another thing, and making it harder and harder to make a reasonable webpage.

Wait till you take a look at CSS grid

https://css-tricks.com/snippets/css/complete-guide-grid/

Basically a table but instead of HTML elements, using CSS properties? I loathe how "let's move the concept from one separation layer into another one, or better yet - let's mix the concepts together in the same separation layer" is becoming the next big thing recently.

CSS Grid does the opposite of what you claim – it fixes the mixing of concepts that previously tied HTML elements to their layout, not make it worse.

table, td, tr, etc are perfectly valid and semantic HTML elements. Are HTML5's footer and header elements broken as well, shall we expect "footer-" and "header-" CSS properties in 5 years?

I have no idea why you keep bringing up <table>. It is totally unlike CSS Grid and completely unrelated in every way.

CSS Grid is for layout, not tabular data. It allows you to move the presentation of your elements around at different breakpoints regardless of your markup structure.

In general I recommend understanding a feature before you spout off nonsense about it.

> I have no idea why you keep bringing up <table>. It is totally unlike CSS Grid and completely unrelated in every way.

I disagree. Conceptually, it is exactly how you would do layout in the old days. This still works, btw, it's just considered bad practice.

It's a bit like saying that a kitchen knife is totally unlike a dagger and completely unrelated in every way, because the former is for slicing food and the latter for stabbing.

I'd say it's more like comparing a horse to a car:

Horses were never really "vehicles." We just misappropriated them that way, because they just happen to be big and move around and we can sit on them. Cars are purpose-made to be vehicles for humans.

If a designer shows you their wireframes with their grid lines drawn on top of it, I don't think many people would think "ah! so it's like in a science paper when they're printing the raw data from their experimental results in tabular form."

The fact that some web developers consider them alike is a historical accident.

I think the fact that, in order to "move fast and break things", we left behind the standards development process, is the saddest part. It's totally true that the standards processes (W3C) often got bogged down or lead us astray. Freedom to experiment is good as well.

But the fact that we have become dependent on frameworks that solely exist in JavaScript and external tooling, created by mainly large organizations, using techniques that work around the basic browser behavior, had me worried for a long time. I say that as someone who has been building websites and web applications since around 1997.

The flip side of this is, without all that experimentation being done by people outside of the standard process, perhaps discoveries like this one (how to do something similar using essentially standard tech) wouldn't be found. And the progress we made before the latest round of shadow and/or virtual DOM and SPA applications is what enabled us to get to the point where we could fully conceptualize them.

So there you have the interplay between the community, industry, de facto and formal standards in a nutshell. There is good and bad, especially when you are in the middle of massive technology shifts.

I for one welcome rolling some of the advancements that we have discovered into formal standards that become built into and fully supported by browser vendors. I welcome a return to "how can we simplify" where we've gotten to and roll that into the standard realm more.

And personally, if we can simplify the use of external tooling as much as possible... I think that would be a huge boon. That tooling is, I believe, going to be extremely brittle over the long run and is a risk factor.

I wish the framework developer the best of luck and thank them for looking back at what we could already do in an attempt to simplify!

Btw, I think that what I am talking about is basically the process of "exnovation" [1].

[1] https://en.m.wikipedia.org/wiki/Exnovation