I feel many experienced developers can agree that what you describe ultimately amounts to the death of high quality software engineering, and that we need to seriously start looking at this like a plague that will consume our craft and burn down our most amazing accomplishments.
I think the solution to this problem is two-fold. First, we try to identify who the specific actors are who are pushing this narrative and try to convince them to stop ruining undergrads. Second, we try to develop learning materials or otherwise put a nice shiny coat of paint onto the old idea of servers doing all the hard work.
If accessibility and career potential were built up around the javascript/everything-on-the-client ecosystem, we could probably paint a similar target around everything-on-the-server as well. I think I could make a better argument for it, at least.
When i started out tinkering with tech in general in the early 2000s people drawn to the internet were still mostly a smaller core of passionate forerunners many of whom subscribed to artistic values like simplicity, beauty and the idea of zen. This began to change with web 2.0 circa 2008.
Both my Mac and my Pc from 2005 are way snappier than todays OSX or Win10. Not as fast but has way less latency.
Today tech education is aimed at highly paid and fancy careers for lots of kids with little passion for engineering or designing who never learned to use a desktop because they just had an iPad - they hardly know that you can copy and paste and almost don't know what a website is outside of walled gardens, i kid you not.
This year had had the most students ever start in tech related fields, and i know from teaching shortly at university that about 95% have not gone into the field because they love to tinker but because it's highly paid or a "cool career".
I know there are still the oldschool "designers and experimenters" out there but it's all about signal to noise. Of course size, complexity, high level modularized abstraction and dependency hell is also an issue, but this probably won't get resolved as 99% of tech people today don't care and don't remember using a computer that didn't have 500ms of latency when closing a window.
> Both my Mac and my Pc from 2005 are way snappier than todays OSX or Win10. Not as fast but has way less latency.
The single most dramatic performance increase I have ever experienced on a computer was with the advent of the SSD.
Load times < 2009 when SSDs became mainstream were atrocious.
When win95 arrived and brought the desktop as we know it to the masses it brought with it some latency that has not been reduced since. Subjectively it has increased, it might just be my patiece that goes shorter, so YMMV.
Yes SSD did bring back some of the lost time, and some more, but the programs don't feel as responsive as in "the old times."
And of course it was used to power porn sites.
To be blunt, I do not care how "new" something is. Newer is not always better, and change is not always good. Churn is not progress. Perhaps those should be the core values that developers need to be "indoctrinated" with, for lack of a better term.
Then again, I'm also probably much older than the average web developer by at least a decade and a half, and saw lots of silly fads come and go.
I think this is the crux of it. It isn't client side or server side rendering, it's simply bad code. Both approaches can be bad if they're poorly engineered. With modern trends we see front end based rendering more prominently, and with that we see a lot of truly terrible implementations. A lot of this is the ease at which you can include a library that does some task for you, but often at the expense of bloating the payload. Good software engineering is hard. It requires effort. It requires more time. It's the antithesis of agile development; moving slowly but being robust. Most companies or side projects aren't willing to choose to build features more robustly if it means cutting the dev speed in half.
I always thought it came with the serverless meme. All those services used to do that cost money, so the decision was made in a lot of places to put the work on the client. New people to the industry maybe haven't connected the dots and think it's for scale when it's really for costs.
An advanced website (or web app) is likely going to have a lot of JS on it already. Should most blogs? Probably not, unless they want interactive demonstrations of concepts, or a commenting system more advanced than what HN has. But beyond that, JS is everywhere.
So at some point, there is JS running on the browser, code that has to be architected and maintained.
So then someone proposes adding another language on the server into the mix, one that will generate HTML and deliver the JS.
The dev experience is, likely, not as good. It is more complicated in a myriad of ways, debugging is harder, and the tech stack is more complicated and more fragile.
And the thing is, good SPAs are really good. But the opposite strategy having every request round trip the server is going to suck in certain cases no matter what the developer does. Something as simple as the site being hosted far away from the user, or there being an above average amount of network latency, is enough to slow down every interaction.
Now all this said, when I'm overseas and suck on 256kbit roaming, HN is about the only site I can use.
The idea of an SPA is only strange in the web dev community. An SPA is equivalent to a native app client - they are long running, stateful processes that communicate with a backend. That architecture has worked for decades, and there are things that you can do as a result of having that stateful process that you simply can’t do with server rendering, like caching response data to share with totally unrelated view components later on in the application. You also get to use a real programming language to design your front end instead of living within a template language, which no one acknowledges as the biggest hack of all time. Template languages exist precisely because HTML is not a sufficient UI tool in all cases.
& what it's serving you in the end doesn't feel like it's heavy lifting in this day & age — a subject line & preview of your first N emails — I think the site could be much more responsive if they had a JS enhanced page (e.g. using it for their predictive text) rather than an SPA.
Page load time is one dimension. We get really hung up on it.
I'm always hazy on the term amortized, but my understanding of it was the opposite — in that, you should try to chunk up as much as possible. If you are using Gmail for a longer period, having to wait for functionality like advanced search or predictive typing is less annoying as the extra time you need to wait is a smaller portion of your session overall. Plus, these things may have lazy loaded by the time you come to use them.
On the other hand, if you just wanted to reference an email quickly — e.g. I often need to dip into email quickly, for example, if I've travelling and have booking confirmations / QR Codes / PNRs etc. in starred messages in the inbox — you'll notice any extra load time so much more.
So to me, feels preferrable to have as small as possible initial load time, then extra functionality progressively loaded in the background.
I do agree for something like Netflix for example that a 'big load up front' is probably preferrable. I'm 'in for the long haul' as I'm going to be watching something that's at least 30minutes up to a feature length film, so a few seconds extra load time is negligble.
I’m having trouble comprehending some of your sentences (there’s some running on going on). So I don’t understand what you mean by “waiting for advanced search” - is that better or worse in the multi page world? I think it’s worse. With an SPA, all of the UI navigation can happen on the client, which is as quick as possible (no server round trip). The actual searching in an SPA would be via an API and you get a nice spinner in the meantime, again with no page load. All smooth UI transitions which indicate to the user what exactly is happening. No blank page while a new page is computed without knowing what exactly is going on.
What I was trying to get at was that there are lots of "optional extras" that seem to get loaded up front at the moment that would be better if they were progressively loaded.
I think you see that a lot with SPAs in a way that you didn't when JS was used to 'progressively enhance' sites rather than for all interactions.
I don't think it's a problem of SPAs by definition — you could engineer an SPA to progressively load what's needed, and make the first load very slimline & then only load additional features while idle or on request, which is why I think GMail is a bad example. For example, I've just tried logging into Gmail in a fresh Firefox window (no cache) that I set to throttle to a "regular 3G" connection speed in the browser. It took literally 30s to load (with one email in the inbox).
Though it's more or less static feature wise, if it weren't for the updated logo you'd never be able to tell it was written within the last decade.
Yes, but a lot of the benefits of SPAs and the libraries needed to work on them accrue to the developers, not the users.
But I suppose you're right that the average developer is their own damn person with their own interests which can only ever partly align with their customer's.
I suppose there are actually three parties, all distinctly interested: the programmer, the employer, and the end user. The programmer wants to get paid and do "good work". The employer is actually a multipart entity: management and investors, each of which have distinct interests. The end user is not a single such person but a mass of individuals, each with a different set of interests.
This is getting messy!
Parents / caregivers / guardians and their charges, who can be further split in to children, teens etc etc.
You simply can’t do that with server rendering (barring hacks like Turbolinks, which are just approximating SPAs).
This is Google we’re talking about.
Does fit the caricature.
I believe there may have been some major changes to the way it did the client-side rendering a few years after it launched. The original version was more ad hoc, since it was pretty much the first time anyone (at Google, at least) had built a real SPA. Later they built tools and libraries, and developed a more systematic way of doing things. (I was at Google during that time period, but never worked on Gmail.)
I think these ferocious views must be coming from the individual - but I do realise not all courses are the same and this student may have actually been (wrongly) taught this way.
I'd bet this doctrine is probably being promulgated by the non-academics at trade schools and boot camps
If you're optimizing for money, rather than good use of system resources, it makes perfect sense.
The underlying platform purveyors unfortunately have the same view, which means that anything before the model before the current model is not supported any more. It probably has an outdated version of the OS. The current OS won't fit. The APIs are changing, and so supporting the old device requires maintaining a separate stream of the code that is backported. Someone has to test it on the old device and OS. And for what? Someone who won't pay.
Looking at twitter links on my aging iPad is a painful experience these days.
Years ago, it was a common conspiracy theory that the hardware manufacturers were forcing obolescence --- and to a certain extent they still are --- but now it seems software developers have outdone the hardware manufacturers without any help from the latter...
Use Privacy Redirect in Firefox/Chrome for iOS if you can.
By 30, you start to allow that they might have a point, but you abstain from saying anything because you remember how it feels. You smirk (privately) at Sarah in Labyrinth instead of identifying with her. "It's not fair. It's not fair." Brat. By 35 you've lost track of how many times you've resisted the urge condescend, and you start to lose the war by degrees.
The best lack all conviction, while the worst
Are full of passionate intensity.
It's not that they're wrong, or they're right. It's that everybody is wrong (and always will be). That excitement at finding a new strategy (which the old cynics point out is merely new to you) is the hope of escape. It's also the hope of changing the narrative so that everybody is on an even footing. You aren't competing with people who have 10 years experience in this (the only people who do are 50 and a mix of short memories and ageism prevents them from taking over).
If 'progress' looks like taking our foot out of one bucket and putting it into another over and over, we're just going to spiral toward the future forever, which is going to be boring and slow. Probably we need more specializations based on problem domains instead of techniques. My exceedingly vague understanding of the history of medicine is that they didn't make much progress either until they did that, and that a lot of people died until they started getting serious about issues. We are 75 years old as an industry. It's time to talk about kicking out the snake oil and cure-all vendors.
Growning up with the constraints of weaker computer hardware helped the Old Guard appreciate performant solutions.
How about people further than 50ms away from your server? Server side tendering gets old quite quick there.
Maybe it's coming from the schools.
I worked with a pair of fresh-outta-U devs who argued vehemently that all computation and bandwidth should be offloaded onto the client whenever possible, because it's the only way to scale.
When I asked about people on mobile with older devices, they preached that anyone who isn't on the latest model, or the one just preceding it, isn't worth targeting.
The ferocity of their views on this was concerning. They acted like I was trying to get people to telnet into our product, and simply couldn't wrap their brains around the idea of performance.
I left, and the company went out of business a couple of months later. Good.