Why is modern web development so complicated?

A back end server with this configuration would have a handler layer for IO, business logic layer and data layer.

DI and IoC ensures that the IO layer doesn't know about the data layer as the logic layer takes it as a dependency. The IO layer consumes the logic layer and the logic layer doesn't care/know about that.

Front end is exactly like this. The data source is REST rather than a database. The UI layer is an event source and consumer. The logic layer notifies its consumers (the UI layer) that there has been a change. The rendering library doesn't matter, it's just a mechanism to represent the events it consumes.

The problem in front end is there has been no rational mechanism for DI in the libraries. React relied on the service locator pattern to deliver dependencies so to ensure quality decoupling you would need to have wrapped your components with a million functions.

``` withTheme(withUsers(withSomethingElse(withAnotherThing(Component)) ```

So rather than that, just use a single "service", redux, and forget about DI. Everything can do anything and all your logic is done inside that one thing.

Angular is no better. While they have a nice DI solution, it still relies on concrete implementations rather than abstractions. So your business logic must live within "angular services" and can not simply be "javascript" consumed by a rendering library.

Vue just missed the point entirely.

React context packaged this problem in an ergonomic box and, in my opinion, is a fantastic solution given the constraints. However at this point, the meta in front end programming is so irrational that it boggles my mind.

In the following example, you can see that I have an application which uses React as a renderer. React consumes a package from /platform. The package has no relationship to the presentational layer.

I could run the units in the package inside node or the browser console and it wouldn't care about its rendering library. The "PostStore" class exposes an API which consists of a getter and a stream. React consumes the stream, because it needs to be notified on changes.

https://stackblitz.com/edit/react-ts-biohay?file=gui%2Fapp.t...

Conversely, this loose coupling means that the view renderer is a small portion of the application. I could swap it out for another renderer. Preact, Svelte, whatever.

Front end is a mess.

You can try the polyfill approach. This is generally not recommended as it wastes bandwidth. But since your customers have bandwidth you could go with polyfills. Or just stay stuck in the past with a niche of writing IE11 compatible stuff. That could be career limiting, IE11 is getting as irrelevant as 8.3 FAT filenames.

The reason is rooted in how browsers work.

In native software you can "just" render your data structures directly to the screen. In the browser, barring webgl, you can't render your data structures directly to the screen, instead, you're forced to interact with an imperative browser API to individually manage bespoke UI widgets that store their own state internally and can't understand nor access any of the data structures defined for your business logic. The only option left is to manually update the internal state of the browser UI widgets whenever you update the internal state of your application. Manually keeping the two states in snyc is a real pain, highly bug prone, and a maintenance nightmare. The front-end browser frameworks came along as a way to "auto-sync" the business logic state with the browser ui state.

Something like htm [1] + ES6 modules is the best of both worlds IMO.

State management? Let React/Vue handle it [2]. No need for Redux/Vuex etc

Need to support IE11? Then yeah, I agree, go back to ES5.

[1] https://www.npmjs.com/package/htm#example [2] https://twitter.com/ryanflorence/status/905584958835638272