In many cases it's probably not necessary. There's a lot of low hanging simplification fruit available in at least two areas:
• Internal/enterprise apps. Instead of writing a full web app write a desktop app using one of the many new frameworks for it and connect directly to your database. Use views, row level security and other RDBMS features to implement declarative ACL logic, and stored procedures as a thin RPC layer when necessary. Benefits: eliminate the whole web tier, no SQL injection (users log into the db as themselves), no load balancers (client side can fail over between replicas), use non-JS languages over the whole stack without transpilation, give users ultra-low latency UI without lots of work, feed output of your SQL library direct to the UI toolkit, no browser compatibility bugs.
• Eliminate mobile/web duplication. Use Jetpack Compose/Kotlin Multiplatform/Flutter/etc to bring your mobile app to desktop and keep all the frontend codebases synced.
If we assume by frontend you mean exclusively web apps, complexity seems to have come from several places:
1. A desire to use something better than JS (typescript, coffeescript, kotlin, whatever).
2. HTML5/JS's failure to provide a components model leading to it being layered on top with npm, webpack, react, etc.
3. A desire to eliminate state-management related bugs via FP techniques.
4. A much wider recognition that latency is important, causing practices that were once routine to be now officially frowned upon and creating piles of complexity through optimizations.
5. Assumption/desire that websites will work on mobile/tablets, even if a native app exists, causing a lot of work for responsive design.
6. Lack of anyone other than Google incentivized to really improve the platform, causing an explosion of tiny GitHub projects that each seek to solve a micro-problem which then get cobbled together into ad-hoc per app "frameworks". Compare to the Apple stack, the Microsoft stack, the Android stack, the Java standard library etc where a lot more stuff comes out of the box and they try to solve app development end to end.
The question of whether this complexity is necessary is always relative. Many apps have a captive user base who are much more sensitive to feature throughput than looks or how quickly the app loads. Things like server side rendering+rehydration are just a distraction there but they often come along for the ride due to the industries preference for using FAANG freeware over buying platforms that could then be more tuned for the customer need.
• Internal/enterprise apps. Instead of writing a full web app write a desktop app using one of the many new frameworks for it and connect directly to your database. Use views, row level security and other RDBMS features to implement declarative ACL logic, and stored procedures as a thin RPC layer when necessary. Benefits: eliminate the whole web tier, no SQL injection (users log into the db as themselves), no load balancers (client side can fail over between replicas), use non-JS languages over the whole stack without transpilation, give users ultra-low latency UI without lots of work, feed output of your SQL library direct to the UI toolkit, no browser compatibility bugs.
• Eliminate mobile/web duplication. Use Jetpack Compose/Kotlin Multiplatform/Flutter/etc to bring your mobile app to desktop and keep all the frontend codebases synced.
If we assume by frontend you mean exclusively web apps, complexity seems to have come from several places:
1. A desire to use something better than JS (typescript, coffeescript, kotlin, whatever).
2. HTML5/JS's failure to provide a components model leading to it being layered on top with npm, webpack, react, etc.
3. A desire to eliminate state-management related bugs via FP techniques.
4. A much wider recognition that latency is important, causing practices that were once routine to be now officially frowned upon and creating piles of complexity through optimizations.
5. Assumption/desire that websites will work on mobile/tablets, even if a native app exists, causing a lot of work for responsive design.
6. Lack of anyone other than Google incentivized to really improve the platform, causing an explosion of tiny GitHub projects that each seek to solve a micro-problem which then get cobbled together into ad-hoc per app "frameworks". Compare to the Apple stack, the Microsoft stack, the Android stack, the Java standard library etc where a lot more stuff comes out of the box and they try to solve app development end to end.
The question of whether this complexity is necessary is always relative. Many apps have a captive user base who are much more sensitive to feature throughput than looks or how quickly the app loads. Things like server side rendering+rehydration are just a distraction there but they often come along for the ride due to the industries preference for using FAANG freeware over buying platforms that could then be more tuned for the customer need.