Hacker News Reader

Comment by reaperducer | Hacker News Reader

I am not sure when there was a new rule passed in software engineering that said that you shall never use server rendering again and that the client is the only device permitted to render any final views.

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.

View on HN

This narrative has been going hard for the last 6~7 years. For me, it's difficult to pinpoint all the causes of this.

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.

It's cargo-culting. Everyone just follows the herd. Once something gets the scarlet letter of being "old" compared to something "new" (both of which are purely perception), it's really hard to ever get back to using the "old" thing (even if it's performance is better or some other tangible benefit).

I've noticed that this incessant trendchasing is largely confined to web development, although it has spread a lot from there (Electron...)

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 remember back around 1999 reading about a guy who had hand-coded his own http server. It was extremely barebones, no server side processing, just fed out html pages. And it was fast, faster than anything you could pay money for. And secure; since it's functionality was so limited compared to all the other web servers, the attack surface was super small. Fast, safe, reliable.

And of course it was used to power porn sites.

> This narrative has been going hard for the last 6~7 years. For me, it's difficult to pinpoint all the causes of this.

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.

I think that’s certainly influenced this trend. Make the client side do all the hard work and server costs go down. I’m not sure how much that cost is, but I’m guessing it could be substantial.

I think it's not as much narrative as the explosion of the tech field in general.

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.

I was with you until

> 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.

I'm not sure what you mean by mainstream, but SSDs were still pretty niche in 2009 and traditional hard drives have remained to be pretty popular until recently due to the lower cost.

I bought my first 128gb SSD for like 300 I think in 2008.

My first SSD was in 2008, was 64gb SLC for $1000. Still going strong. But yeah, was pretty niche.

SSD improve programs' loading time, they do nothing for the latency of the UI of those programs.

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."

> the death of high quality software engineering

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.

Here's the thing.

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.

It probably wasn’t the first, but the first notable SPA I can think of is Gmail. Do you think that architecture was just decided on by some noobs right out of school? Since it was novel at the time, probably not. That leads me to believe (along with my own anecdotes and observations) that there are real benefits to SPAs. Are there trade offs? Of course. But there are benefits too.

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.

SPAs are a good fit for webmail. They are a bad fit for many other projects.

Was Gmail always an SPA? My recollection is that it was a regular web site when it launched, and went SIA when everyone else did.

Gmail has been a SPA since launch. There were some pre-launch versions that were not, and it has always had a plain HTML fallback mode.

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.)

And 99% of the time all of that is pure YAGNI.

So why are we conflating web apps vs web sites exactly?

Most people who aren’t involved directly with web development just call everything a ‘web page’, or ‘the web’.

Because that’s what everyone else does when saying that the performance characteristics of the two should be evaluated in the same way, e.g. page load time.

there are real benefits to SPAs.

Yes, but a lot of the benefits of SPAs and the libraries needed to work on them accrue to the developers, not the users.

It's funny to think of developers and users as two distinct constituencies with distinct interests. I had thought any good developer, by definition, would do what's best for the user. Therefore the interests of both groups are the same.

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!

The individual end user can also be multiple distinct groups, some simultaneously:

Parents / caregivers / guardians and their charges, who can be further split in to children, teens etc etc.

Some benefits are for developers. And some are for the users. For example, many users, particularly ones who care about the look and feel of things, prefer when there is a smooth transition between screens in response to their actions.

You simply can’t do that with server rendering (barring hacks like Turbolinks, which are just approximating SPAs).

I agree, and I'm more critical of heavy front end Javascript frameworks that are part and parcel of SPAs. Things like the Turbolinks hack you mention, IMO, provide the best user experience, especially fast initial page load. But that can be messy to develop, so we end up with Angular or React which smooth the development issues, but make pages fat and slow for users.

Gmail has a "basic view" that works without JavaScript, just good old fashioned HTML forms and hyperlinks and server-side state.

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.

Sure, SPA is the correct technology for certain applications, but not for every damned website.

> Gmail. Do you think that architecture was just decided on by some noobs right out of school? Since it was novel at the time

This is Google we’re talking about.

Does fit the caricature.

While Outlook Web Access (2000) was earlier, Gmail (2004) and Google Maps (2005) were definitely instrumental in establishing AJAX and the SPA pattern (though the term SPA came much later I think).

Gmail is probably the example that I hold up as an SPA gone awry — on a new machine & T1 broadband you can still get _very_ slow loading times to open the site at all.

& 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.

GMail has gone downhill massivly since it first started. I Can read the entire contents of a mail and go back to inbox and it still shows the email as unread. Closing the gmail tab usually comes up with a prompt saying it's busy and am i sure i want to close tha tab. I would consider it as an example of how not to write a SPA these days

I made a comment elsewhere about page load time not being the only dimension of performance. Page load time’s importance gets amortized across the length of the whole session. You should always try and minimize it, but in an application like Gmail you’ll be using it for minutes at a time. Each subsequent interaction is now quicker because there doesn’t need a page refresh.

Page load time is one dimension. We get really hung up on it.

I agree with your reasoning but not how it applies to Gmail :)

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.

When I said “amortized” in this case, I just mean that the cost of the initial page load is spread out throughout the length of the session. Like you said, if you just want to quickly open an email then close the app, the session time will he short and the page load cost will be a large percentage of the session time.

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.

sorry writing while eating lunch earlier so no doubt could be phrased better :)

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).

Gotcha. React Suspense is trying to be the best of both worlds. It allows you to load code for components on the fly, when they are needed, and not all up front.

If we're comparing things to how they were just a few years ago, Maps has been far worse to me than Gmail lately IMO.

As a current student Compsci student who's done an (introductory) web dev class, may I say I have not been taught this way _at all_. In fact this notion of offloading stuff to the client never came up at all in the class. That's just my experience.

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.

Some, not all but some, new grads hear something from a prof or maybe departmental philosophy, and they will defend it to the death until they see real life for a while.

Compsci education is more focused on theory. Your prof is more likely to come from old-school corporate dev or 90s startups and probably has jaded views towards much of this new stuff like a lot of the passionate "designers and tinkerers" do nowadays

I'd bet this doctrine is probably being promulgated by the non-academics at trade schools and boot camps

In my class we learnt server and client side JS. I feel my prof's approach to webdev was quite modern. It was a very practical class and none of the theory we learnt was actually tested.

It is most likely a result of an echo chamber of students with no or little industry experience. It doesn't help that the younger people generally own client devices with more up-to-date specs.

Also, young people like to cling to new industry trends. It makes sense for them - if they would try to become an expert in something that is decades old, they would have to compete with people with decades of experience, while new tech creates a level playing field for the both the graduates and the veterans. This might also be one of the reasons for why we see such an diarrea of technologies in our industry - coding is mostly done by young people, many of them not more than a couple years into their careers. Pushing for new tech pays off for them.

Unfortunately, the latest model is where the users are who habitually spend money on new stuff and are likely to pay you for anything.

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.

> 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.

Looking at twitter links on my aging iPad is a painful experience these days.

Twitter, where displaying short pieces of text and occasionally images and very occasionally video can require extravagant amounts of processing power that can only be found in the latest hardware and software...

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...

Wirth's Law, 1995 - "software is getting slower more rapidly than hardware is becoming faster", attributed to back to 1987 or so.

- https://en.wikipedia.org/wiki/Wirth's_law

Simply compare with nitter.net to see how the exact same content can easily be presented in a simple, lean, fast way.

https://m.twitter.com or https://nitter.com

Use Privacy Redirect in Firefox/Chrome for iOS if you can.

mobile.twitter.com is also terrible

At 22, you bristle at the thought of someone in their 30's or 40's year old calling you a child, and why does the entire car rental industry agree with these tired old farts? It's not fair.

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.

I am coming to appreciate Jim Highsmith's position (we aren't solving problems, we are resolving paradoxes, but refuse to see).

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.

More focus on Performance and not just Eye Candy would benefit.

Growning up with the constraints of weaker computer hardware helped the Old Guard appreciate performant solutions.

It's coming from the mega cap FANG companies. There never was an organic open source evolution of SPA's or front end JS frameworks because offloading compute to the client is an optimization that only a handful of companies on the planet need.

It very may we’ll be. When I was at CMU (MISM) part of our curriculum discussed distributed systems. Some took it as another tool in the kit, but many came away thinking it was taught to us because it should be how we do things in the field.

> When I asked about people on mobile with older devices

How about people further than 50ms away from your server? Server side tendering gets old quite quick there.

IME latency is much more a problem with shitty (ie most) SPAs that only start loading the data after the scripts are loaded.

You kidding!? SPAs have a significantly worse user experience with high latency, the vast majority of SPA will just display a blank screen if the latency is too great.

Amen! A person near and dear got let go on some really snarky nonsense etc etc. Really stressful. But guess what? 90 days later they canned 2/3rds of everybody else including a whole bunch of the jerks. Their old office is black; not a soul around. They've got big customer and cash flow probs. When we heard this ... straight to the bar for a couple of celebration rounds. Hee hee hee. Meanwhile the person in question got a way better job.

I mean the logic is pretty straightforward, your servers will never have the computing power of all client devices combined, and the slowest part of any webpage is going to be communication between server & client. If you are writing a web app with such intense JS that people can’t run it that is an indictment of that app, not all client side rendering.

The slowest part of any modern webpage is the part where the client (usually a mobile phone) has to download 1MB+ of JavaScript, parse it, execute it, use it to fetch more code and then display it to the user.

But servers are typically fast at serving up html, which the server isn't rendering, only generating. Very fast these days, particularly with proxies and server caching.

Even more-so, it's resources you don't pay for.

The flaw in that logic is assuming that the total amount of work being done is the same for both client-side and server-side rendering.

Reply on news.ycombinator.com