It is much faster to train people on a combo js+css framework rather than training someone on backend languages, databases, queues, authentication, scaling + html & css for server side rendering.
But I guess that is just me/generational? Ironically, I feel like there are a lot more job openings for front-end than for back-end now, and I'm much more comfortable on the back-end.
Cloud Tech (AWS) which also includes, lambdas, Iam management, dynamoDB, cdk or serverless, API gateway, S3, secret managers etc.
Add to that list the technologies that often get thrown in for extra monitoring testing etc. Jest or mocha/Chai for unit tests. Dynatrace for monitoring. Kibana or something for logs. Some tool for analytics. Github actions for setting up deployment and CI. Maybe you need redis for intermediate caching, etc.
In addition, before you kind of sort of had an intuition of how the data flowed through your basic stack from the database to the web page. Nowadays who the heck knows what's happening. You'll hit some api gateway endpoint which auths through a random lambda who knows where on what server, then it will go hit the actual lambda that holds the function you want to call which may reach out to a database but get intercepted by the redis cache etc etc etc.
Yes modern web dev is definitely much simpler /s.
There’s nothing stopping companies from using the cloud for its primitives (compute and storage), maybe with managed FOSS services (RDS Postgres). We don’t _need_ to go all in on AWS to build a ‘modern’ web application. Yet somehow much of the industry dances to AWS’ tune on how to architect software.
Users wanted responsive UIs and Gmail showed the power of AJAX in the browser. In the mid-2000s, server power, network latency, and maintaining state were the challenges. The UX was more powerful when the client tracked state, only requested the data it needed, etc.
Things have flipped. SPAs became bloated as abstractions were introduced. Network latency and server power is not an issue anymore. Rendering a bunch of HTML is as quick as rendering JSON.
As a vet of the IE7 days, I love this trend. Leveraging the best of server compute and browsers is going to simplify web app development a LOT.
But Ajax is merely a pattern that was enabled by the ‘dynamic html’ that was made possible by having a DOM and JavaScript. It was possible in Netscape years before IE6. I did a production app with Ajax in 1999, using IE4. Before the term Ajax had been coined.
Bare AJAX itself almost always will perform better than a full page request, but as you layer on additional requirements, frameworks, libraries, etc. that isn't always true.
I think old reddit and new reddit are a great example of this - both are processing the same data and presenting a very similar UX. But at least for me, the relatively javascript light old reddit interface with full page reloads feels much more responsive and usable than the new site.
Ask yourself: Do "people2 prefer looking at "spinners" or more-or-less animated "page loading..." texts?
Waiting time is the issue, the technology is not.
A server generated page that loads fast beats a Framework-generated page hanging every time!
As for technology:
With "classic" server generated pages "people" will know what is going on (browser indication tht page is loading) and they will know what to do (wait a few seconds at most). With frameworks "people" are left out in the cold with no indication what the problem really is and no apparent remedy or path for solution as a page refresh might interfere with state logic or whatnot bringing totally undesired results.
As a secondary effect it also allows for more kingdom expansion. It's much easier to have two teams of five than one team of ten.
That being said, I'd rather manage a team of five good full stack engineers than ten average front/back end engineers. The communication cost of trying to get features out the door with two teams of five is very high.