SPAs solved a labor problem I think. It was the reason that front end development grew so fast.
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.
That seems strange to me as being an "old school" developer I have a lot more trouble trying to get a hang of the new front-end stuff than I do learning a different back-end framework.
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.
We use SPAs and a pretty strict typescript/react stack. And I still have to know:
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.
I see this “AWS for everything” Well-Architected stuff everywhere. AWS benefits greatly from inserting itself in between all our architectural layers.
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.
Architects in my company are required to have aws certificates. They can be monkeys but if they can list a dozen of AWS products and put everything there they are given the keys of everything.
You may work at a company that requires fullstack expertise, but there are plenty of other companies where frontend developers are fully insulated from all those cloud technologies. I'm not sure what your point is here tbh.
A friend of mine moved to a company where they use plain Laravel (with just some sprinkles of js using Alpine) and they deploy to heroku. A team of 10 devs, no systems/devops/Infra and he’s fascinated how well things go and how fast they ship stuff compared to where we worked together before (with all the usual react/redux stuff and an elixir backend on kubernetes)
I wouldn’t say modern web dev is simpler, I just think it is more decoupled. This helps with training for & staffing the more specialized roles that emerged.
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.
Not quite what I remember. XMLHttpRequest was invented by Microsoft and used in a outlook webaccess. This was only possible in IE6.
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.
AJAX in early Gmail was a massive improvement. It was mostly hand-coded javascript in a relatively thin page and it was the sweep spot. Today's version of gmail is the most bloated pile of spaghetti framework code imaginable and is far less responsive and usable than the plain HTML version.
People want responsive interfaces, absolutely. Whether the interface is implemented as full page requests to servers or AJAX requests is irrelevant to users.
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.
A lot of dev managers like that they can turn one team into two teams by splitting everyone into front and back end. This makes hiring easier. I cannot emphasize this enough. Easier hiring is a huge deal.
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.
IMO, I think this is a valid question (though asked a bit crudely). To generalize, it's because someone who has done JavaScript programming can point to NodeJS and say, "I'm full stack." Which, while technically true, skates over the reality of NodeJS as a less than ideal backend (see Ryan Dahl and the dawn of Deno). Second, it's more lucrative to bill oneself as "full stack" even if in reality a person isn't. At one point in my career I would have considered myself "full stack". Over time I realized that a "full stack" engineer is a jack-of-all-trades type, which in theory, can be valuable in the right circumstances as an individual doing work alongside non-full-stack engineers. Asking a room full of "full stack" engineers to design and build a product of any complexity above CRUD will naturally lead to a self-sorting of UI/UX and server side engineers.
Exactly. Full stack engineers are sorely needed in every project because they can see the forest from the trees, not because they are experts in everything from botany to carpentry.
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.