As someone involved in hiring, this is what Bootcamps and Universities are teaching, and what companies are looking for: backend spits JSON, frontend consumes it using React.
Rendering HTML on the server is not really "the default" anymore as it was 10 year ago: it's more of an optimization for when your React site is slow, and it's a black box to most people. Even static websites are "strange tech" to new graduates outside the HN bubble.
Also, developers hate mixing tech. You mentioned an "interactive map" in your example. This can be made with React or something like that, right? The issue is that a lot of developers will want to use React for everything else on the page, because they think it's "icky" to use other kinds of tech in other parts of the website. They sorta have a point (the "microfrontends" discussion was a thing a couple years ago), but on the other hand they're not considering the tradeoffs.
Also, the frontend is officially the centre of the application on medium sized companies (50+ devs). It's way easier to add new code to the frontend and spin another microservice than to coordinate between multiple teams of backend engineers.
I'm not saying this is good or bad, btw. It's just how it is.
EDIT: One thing that really bothers me that people fresh in the industry don't really believe that websites were faster 10 or 20 years ago, so I don't really see any light at the end of the tunnel. Sure we can do new things on the web, but what was already possible before has been made slower by our collective refusal to "use the right tool for the job". Even the frontend tooling today is very heavy and slow, and I'm in a 2020 MBP. I don't think we progressed much. React is an amazing idea (and the implementation is great), but the community has become too dogmatic.
A few years ago when teaching at a previous coding bootcamp that started with FE JavaScript, I remember my surprise when well-performing students got through 3 months or so of it and were confused and very impressed when I showed them how an <a> tag worked, since they had only been aware of (jQuery) JavaScript powered pages. When you are stuck just doing JS powered SPAs, an <a> tag seems like advanced technology!
I ended up at a new school creating a new curriculum. This approach is where we "recapitulate the evolution of the web", so we start with SSGs & server-side programming (Python/Django), then only at the end cover SPAs and React.JS -- since, as you mentioned, that's still the main skillset that companies are new devs for.
Almost every JS app I have seen uses a tags though. Even if they are just links to # pages. With most router libraries you can even use real paths and it works all on the front end. Sounds like you found one anecdotal case that didn't know this.
Maybe I wasn't clear -- What I meant to say is that the curriculum barely covered <a> tags, but instead started just with JS DOM manipulation, which meant students were using document.location on click events since they weren't taught anything else. This isn't a criticism of JS best practices, instead it's a criticism of how it's taught, specifically in this curriculum that's sold as a white-label curriculum and used by MANY bootcamps across the US. It might even be the most popular coding bootcamp curriculum in the country. It's possible they've improved it since I was teaching it, but definitely it was not the case a few years ago!
Exactly. And sometimes they're not even taught it! But since they also weren't taught the foundations, they also won't know how to "ask" questions. So they end up searching for "how do go to another page using Javascript", which will obviously yield results with window.location.
It definitely happens. I've seen some internship/junior interview tests where candidates use javascript's window.open or window.location to link to some fixed destination rather than just using an anchor tag.
>The issue is that a lot of developers will want to use React for everything else on the page, because they think it's "icky" to use other kinds of tech in other parts of the website.
It is though. I work on an app thats 80% react and 20% rails SSR and when working on anything, seeing that an area that needs change is written with SSR makes the job 10x harder as you have to come up with alternative methods to get it working or just rewrite it in react. When everything is react everything is quite easy and you can pass around data and update things without a refresh easily.
> seeing that an area that needs change is written with SSR makes the job 10x harder as you have to come up with alternative methods to get it working or just rewrite it in react
Without details it's hard to know what you mean. Do you have an example?
It feels more like the SSR part was not the right tool for the job in this case (or maybe it was from the speed point of view and not development). Your point seems to be that react is better than SSR and not that mixing technologies is bad.
Thanks for the response, very informative, I feel it explains a lot of what I was confused about.
So maybe a simplified view for me is: massive adoption of JS + frameworks, cookie cutter development, no point learning anything else when you have the golden hammer.
I actually thought you still did learn HTML and stuff before the digging into the frameworks.
But maybe it is analogous to learning assembler before python, i.e out of fashion and not needed to get the job done.
In this context what seems like the simpler and more suitable solution to me (static HTML+some minimal JS) might not be on the map for most modern web developers. What they do is overkill but it is what they know and it gets the job done.
One thing I love about Svelte/Sapper is that it can be used for both the server-side rendering and the interactive map. And it doesn't feel like an afterthought - idiomatic usage leads to server-side rendered html with progressive enhancement of JS.
Oof. Yeah, I am now very glad I got out of that game, does not sound like a nice place.
SPAs were for a specific, narrow, set of use cases where it really didn't make a lot of sense to even have a backend...
Companies don't really have the incentive to build good software, though. Fads and cargo cult 'lets use this popular BS' tend to catch on more when the name of the game isn't software, rather its about pandering to a job market. Outside of sudden and painful corrections that market seems to promote bad engineering, probably because it costs more over time to maintain and thus creates more demand in a 'negative' positive feedback loop...
Trying to legislate it back in by pointing out that most sites are hot piles over garbage that are unusable by anyone with any sort of impediment (physical, technological) seems like a nice idea, I don't see much growth in that area anyways so perhaps it is time for strict law enforcement...
Rendering HTML on the server is not really "the default" anymore as it was 10 year ago: it's more of an optimization for when your React site is slow, and it's a black box to most people. Even static websites are "strange tech" to new graduates outside the HN bubble.
Also, developers hate mixing tech. You mentioned an "interactive map" in your example. This can be made with React or something like that, right? The issue is that a lot of developers will want to use React for everything else on the page, because they think it's "icky" to use other kinds of tech in other parts of the website. They sorta have a point (the "microfrontends" discussion was a thing a couple years ago), but on the other hand they're not considering the tradeoffs.
Also, the frontend is officially the centre of the application on medium sized companies (50+ devs). It's way easier to add new code to the frontend and spin another microservice than to coordinate between multiple teams of backend engineers.
I'm not saying this is good or bad, btw. It's just how it is.
EDIT: One thing that really bothers me that people fresh in the industry don't really believe that websites were faster 10 or 20 years ago, so I don't really see any light at the end of the tunnel. Sure we can do new things on the web, but what was already possible before has been made slower by our collective refusal to "use the right tool for the job". Even the frontend tooling today is very heavy and slow, and I'm in a 2020 MBP. I don't think we progressed much. React is an amazing idea (and the implementation is great), but the community has become too dogmatic.